deniscope

Introduction

Smart Match est une nouvelle technologie qui permet de rendre le contenu d'un email dynamique.

Description technique

La technique consiste à cacher des images subtilement dans le contenu des emails. Ces images seront contactées par le client mail mais ne retourneront pas de contenu (code HTTP 204: No Content), elles devront avoir une url contenant des paramètres définissant le coté dynamique du contenu (par exemple l'identifiant d'une commande ou la référence d'un formulaire). Lorsque le serveur servant les images décide de changer le contenu de l'email, il n'a qu'à retourner un contenu valide par image, il grillera alors les allumettes "Match" car ces images seront mises en Cache par le client email. Correctement disposées avec des attributs CSS adaptés, les images peuvent recouvrir une partie du contenu, en ajouter, rendre des boutons inactifs ou même ajouter des informations.

Exemple: Validation d'une demande

Imaginez un accusé de réception pour une demande quelconque. Vous recevriez un email dans le début pourrait ressembler à ça: Une fois la commande acceptée (ou refusée), l'email deviendrez: Code de l'email:

<div style="background: url('http://izzyway.com/background/pending.gif') no-repeat top right;">
   <img src = "http://izzyway.com/background/ribbon.php?id=123" style = "float: right; margin: 0; padding: 0;z-index:100;" alt = "" title = "" />
   <img src = "http://izzyway.com/background/msg.php?id=123" style = "margin:0 0 0 44px;" alt = "" title = "" />
   <div>
      <p>Nous accusons de votre demande. </p>
</div></div>

Aussi longtemps qu'il est nécessaire l'image nommée ici background/ribbon.php retournera "204 No Content", une fois la demande effectivement validée (ou refusée), le serveur retournera le contenu de l'image avec biensur le code 200. L'image background/msg.php agira de la même façon mais avec un contenu donnant des informations complémentaires sur la validation de la demande.

Autres applications possibles

1. Griser des boutons (en positionnant une image transparente au dessus)
2. Suivi de livraison de commande (une image par ligne dans un tableau d'information)
3. Information sur l'ouverture de l'email (pour le cas de liste d'email)
4. et bien d'autres...

Tests

Smart Match a été testé avec gmail, yahoo, hotmail, et d'autres clients emails lourds (pas Outlook je l'avoue), cela fonctionne super bien.

Conclusion

Plus qu'une nouvelle technologie, Smart Match est un algorithme habile pour rendre dynamique le contenu d'un email. Le point crucial de la technique est la gestion du Cache du client email, une fois l'image utilisée, elle sera mise en Cache (elle sera "grillée" comme une allumette) et ne pourra alors plus être utilisé pour changer le contenu de l'email. Le résultat est bluffant, les images changent dès l'ouverture de l'email et le contenu semble vraiment changer.

Aujourd'hui javascript est un langage incontournable pour la construction d'un site web même modeste. De plus en plus utilisé, possédant une grosse communauté de développeurs, javascript a le vent en poupe et on trouve maintenant de nombreux frameworks l'utilisant. Et pourtant. Pourtant, si on regarde quelques années en arrière, javascript était déjà présent dans les pages internet. Plutôt alors réservé aux développeurs expérimentés, il était souvent délaissé au profit de technologies lourdes (java ou flash) pour rendre "dynamique" une page. L'internet grandissant, les navigateurs ont également évolué. Ce qui prenait plusieurs kilos de lignes de code javascript avant, peut aujourd'hui s’exécuter en quelques instructions. Cela a pris du temps, le marketing aidant, on a même pu nommer les différentes périodes de cette évolution (DHTML, Ajax, Web2.0...) et petit à petit des choses se sont mises en place. Ces choses vont toutes dans le même sens : une mise en œuvre plus rapide et plus soignée du modèle MVC (Model View Controler).

Aujourd'hui toujours, javascript a beaucoup de mal à trouver sa place dans le système MVC. Trop souvent employé pour le 'V', heureusement rarement pour le 'M', il ne devrait apparaitre que dans le 'C', et encore. La prochaine grande évolution du web ne semble laisser que peu de place à un langage tel que javascript. Déjà HTML5/CSS3 remplacent avantageusement certains frameworks d'animation d'éléments visuels. Combien de temps faudra-t-il au web pour pouvoir se passer de javascript ?

La grande force d'un langage client puissant et d'une "bidouillabilité" exceptionnelle est qu'elle permet de faire une foultitude de choses d'une foultitude de manières. Mais le développement du web est aussi (et avant tout) un milieu réservé à des professionnels. Avec l’essor de l'internet mobile, les périphériques se multiplient et donc les clients web qui poussent vers une normalité des pratiques car il est toujours plus facile d'interpréter une norme selon ses spécificités (petit écran, tactile, noir et blanc...) plutôt que de compiler un code souvent complexe pour finalement seulement se rapprocher du comportement voulu. C'est pourquoi, même s'il sera toujours amusant à utiliser, le javascript devrait, en toute logique, disparaitre peu à peu de nos clients web.

Izzyway est en pleine réfection et, pour l'occasion, il s'est muni d'un fil RSS à cette adresse: http://feed.izzyway.com. A vos agrégateurs...

Faute de frappe

J'avoue avoir hésité à publier ce secret car il n'est vraiment pas extraordinaire. Que se passe t'il lorsqu'une propriété d'un tag est mal écrite? Comme nous pouvons le voir sur le résultat browsershot et grâce au test 6, une fois encore, cela dépend des navigateurs.

Le test 6 comporte une série de tag (un par ligne) avec, à chaque fois, une façon différente d'écrire la couleur de fond.

Ce secret n'est pas si extravagant que cela car tout le monde se doute bien que devant une faute d'écriture de tag, les navigateurs se rattrapent un peu aux branches et font ce qu'ils peuvent pour rentre le tag au mieux. Et c'est exactement ce qui se passe là. La plupart des navigateurs ignorent simplement la propriété mal écrite alors que d'autre essai autant que faire se peut d'évaluer une valeur (pour cette propriété).

Un petit plus tout de même pour ce secret, lié à la dernière ligne du test 6. Cette ligne définit deux fois la même propriété pour changer la couleur de fond: <div style = "background: green" style = "background: blue" />. On peut noter ici qu'aucun des navigateurs testés ne prend la seconde valeur, toutes les dernières lignes sont vertes (ouais, c'est pas évident sur l'image mais vous me faites confiance hein?).

J'ai récemment écrit une méthode pour faire un cercle en javascript et CSS:

/**
 * Draw a circle in the given color and Element
 * @param radius radius of the circle
 * @param color color of the circle 
 * @param id id of the Element where the circle will be drawed 
 **/
function drawCircle(radius, color, id){
    var circle = document.getElementById(id);
    if (!circle) return;
    circle.style.width  = (2 * radius) + 'px';
    circle.style.height = (2 * radius) + 'px';
    var index = 0;
    for (index = 0; index < (2 * radius); index ++){
        var line = document.createElement('p');
        line.appendChild(document.createTextNode(' ')); 
        line.style.border = 'none';
        line.style.borderSpacing = '0px';
        line.style.padding = '0px';
        line.style.height = '1px';
        line.style.fontSize = '0px';
        line.style.backgroundColor = color;
        var r = Math.abs(radius - index);
        var width = 2 * Math.round(Math.sqrt(radius * radius - r * r));
        line.style.margin = '0px ' +  (radius - width / 2) +
                            'px 0px ' + (radius - width / 2) + 'px';
        line.style.width = width + 'px';
        circle.appendChild(line);
    }
}

Comme un exemple vaut toujours mieux que mille explications. En voici un:

<div id = "circle"></div>
<script>
      drawCircle(100,  'magenta', 'circle');
</script>

Ce qui donne:

L'utilité de la chose est limitée j'en conviens.

Mise à jour: J'ai reçu des milliers de plaintes me disant que ceci n'est pas un cercle mais un disque. Force m'est de constater que vous avez raison. Voici donc une méthode avec l'exemple qui va bien pour créer un cercle (cette fois).

/**
 * Draw a circle in the given color and Element
 * @param radius radius of the circle
 * @param color color of the circle 
 * @param id id of the Element where the circle will be drawed 
 **/
function drawCircle(radius, color, id){
    var circle = document.getElementById(id);
    if (!circle) return;
    circle.style.width  = (2 * radius) + 'px';
    circle.style.height = (2 * radius) + 'px';
    var index = 0;
    for (index = 0; index < (2 * radius); index ++){
        var line = document.createElement('p');
        line.appendChild(document.createTextNode(' '));
        line.style.borderLeft = 'solid 1px '+color;
        line.style.borderRight = 'solid 1px '+color;
        line.style.borderTop = 'none';
        line.style.borderBottom = 'none';
        line.style.borderSpacing = '0px';
        line.style.padding = '0px';
        line.style.height = '1px';
        line.style.fontSize = '0px';
        var r = Math.abs(radius - index);
        var width = 2 * Math.round(Math.sqrt(radius * radius - r * r));
        line.style.margin = '0px ' +  (radius - width / 2) +
                            'px 0px ' + (radius - width / 2) + 'px';
        line.style.width = width + 'px';
        circle.appendChild(line);
    }
}

Voici l'exemple:

<div id = "circle2"></div>
<script>
      drawCircle(100,  'magenta', 'circle2');
</script>

Ce qui donne:

L'utilité en n'est pas vraiment accrue.

Une livre sinon rien

Lorsqu'un navigateur communique avec un serveur, ils utilisent des codes pour être sûr de bien se comprendre. Ces codes sont naturellement les mêmes pour tous et ne permettre guère l'improvisation. Il n'en reste pour autant pas moins qu'une requête HTTP (car c'est bien de cela qu'on parle) peut être constitué d'une entête et de données. En règle général et sauf contre ordre, les navigateurs affiches les données quelques soient le code envoyé.

Pour illustrer ces communications, j'ai créé une petite page test avec les principaux codes HTTP. Comme le montre le détail de la page test ci dessous, chaque code est appelé deux fois. La première fois (à gauche) avec peu de donnée, la seconde (à droite) avec plus de 512 octets de donnée, les deux pages affichant un carré vert.

Alors pourquoi cette limite des 512 octets? Et bien c'est là que réside le secret (et le jeu de mot foireux du titre également). Si vous regardez de plus près le résultat donné par le site broswershots (ci dessus), le navigateur Internet Explorer réagit différemment aux réponses HTTP en fonction du nombre d'octet envoyé. J'avoue que même si vous pouvez cliquer sur l'image des résultats pour zoomer, la chose n'est pas flagrante, c'est pourquoi, dans ma grande mansuétude, j'ajoute une copie d'écran (ci-dessous) d'une partie de la page test sous Internet Explorer. Encore une fois, Internet Explorer se démarque des autres navigateurs par un comportement que je n'arrive pas vraiment à comprendre. Concrètement, Internet Explorer n'interprète les données envoyées seulement si elles sont assez nombreuses...

Vous avez une explication?

No comment

S'il y a quelque chose dont les bloggeurs sont friands, c'est bien des commentaires. Mais cela n'a rien à voir avec notre sujet, je ne parlerais pas des commentaires de blog (même si je les apprécie) mais bel et bien des commentaires HTML.

Un commentaire HTML débute par les caractères "<!--" et termine par "-->", voilà pour la théorie.

Comme je suis joueur, j'ai essayé plusieurs autres façons d'écrire des commentaires sur cette page test. Lorsque le carré rouge apparait, c'est que le commentaire n'est pas pris en compte.

Les tests sont les suivants:

Comme vous pouvez le constater sur l'image des résultats ci-dessus (toujours obtenus grâce au service en ligne BrowserShots), les commentaires HTML n'ont pas toujours le comportement auquel on s'attend.

Si vous oubliez de refermer votre commentaire, ou si vous le fermez mal (selon les navigateurs), il sera automatiquement fermé au prochain caractère supérieur (>) de votre page. Pour reprendre une expression des expressions régulières, on pourrait dire que les commentaires HTML sont "non greedy" (ou "lazy"). C'est à dire que si le tag de fermeture (-->) n'est pas trouvé, le navigateur fermera "au plus tôt" le commentaire, en l'occurrence au prochain caractère supérieur (>).

Cela laisse sans voix non? (ou plutôt sans commentaire).

Il ne vous a surement pas échappé qu’izzyway était un peu partout dans ce site. Je n’ai pourtant pas réussi à garder les services que j’avais mis en place il y a deux ans. Il y a une telle pollution dans les envois d’email que les emails envoyés à cette époque n’arrivaient jamais à destination, bloqués par un serveur zélé qui les considérait comme SPAM.

Aujourd’hui izzyway existe toujours et propose des services un peu moins sophistiqués mais rigolos tout de même (pour ceux qui ont de l’humour).

• Server Information : Cette page résume les principales informations qu’un serveur peut utiliser quand vous, client, vous le contactez. Sinon vous pouvez toujours utiliser BrowserHawk qui est bien plus exhautif.
• Navigation introspection : Ce service énumère les différents objets fournis par votre navigateur, il détaille également les méthodes et les propriétés. Cela peut être utile pour comparer les différents navigateurs.
• Broken links : Ce service permet de lister les liens défectueux d’un site ou d’une page. Exactement ce que propose aussi Link checker en somme.
• HTTP Method: Le service, que je trouve le plus marrant, permet de créer une requête http et de l‘exécuter. La requête sera exécuter du serveur (free) et la réponse sera alors affichée sans aucune modification (même les chunks apparaissent tels quels).

Le site est en anglais car j'adore me la péter.

J’ajouterais sans doute, au fil du temps, des nouveaux services.