Le nombre de consultations d’email sur mobile ne cesse d’augmenter. Il est donc important d’adapter leur design pour garantir un bon affichage sur desktop et mobile. Voyons par l’exemple comment y parvenir.
Introduction
Les articles concernant les emails responsives fleurissent sur la toile. Ce besoin se fait de plus en plus grand, car nous avons maintenant toutes les technologies nécessaires pour y répondre.
Cet article n’a pas pour but de vous convaincre des atouts des emails responsives, mais de vous expliquer comment les intégrer.
Néanmoins, quelques chiffres récents sont intéressants à connaître :
- depuis un an, le nombre d’emails lus sur mobile est plus important que sur webmail ou client email
- 19 % d’emails envoyés sur une adresse @gmail.com sont lus sur le webmail Gmail
- 47 % d’emails lus le sont sur mobile ;
- le taux d’ouverture d’emails sur Gmail est de 3,38 %.
Source : Mobile Opens Hit Record High of 47%
Préparation du terrain
Le mieux est de partir d’un exemple concret avec la production récente pour un de nos clients, Belambra. Cet email rassemble une bonne partie des besoins en technique d’email responsive.
Comme tout email, il est important de définir dès le départ les cibles des tests. Si nous connaissons bien les destinataires, nous pouvons nous baser sur les précédentes statistiques des ouvertures d’emails.
Pour notre exemple, l’email devra fonctionner sur :
- Outlook 2010
- IPhone (mobile)
- Android 4.x (mobile)
- Gmail (IE >= 8, Firefox, Chrome)
- Yahoo (IE >= 8, Firefox, Chrome)
- Hotmail (IE >= 8, Firefox, Chrome)
Je vous conseille de bien vous documenter aussi, il y a une très bonne série de huit articles sur Campaign Monitor dont les quatre premiers sont déjà traduits sur www.pompage.net.
Tester au fur et à mesure
Cela ne sert à rien de produire l’email en une seule fois et de ne pas le tester au fur et à mesure. Un bon conseil étant d’utiliser une plateforme de tests en ligne. Il existe plusieurs offres, payantes en général. De notre côté, nous avons choisi Litmus qui permet de tester notre email sur la plupart de nos cibles.
Pour donner un exemple du temps gagné : Il y a eu 20 essais d’email avant que l’email soit finalisé. Il faut compter 5 minutes avec Litmus pour avoir un aperçu sur chaque client mail et 20 minutes si nous allions vérifier sur toutes les autres une par une. Au total nous gagnons 2020 – 520 = 300 minutes soit 5h ! Sans compter la disponibilité de machines virtuelles de tests pour les rendus Outlook, le prix des licences, …
Enfin de la technique
Tout d’abord, inutile de chercher à faire du mobile first, c’est impossible à l’heure actuelle. Seuls les clients mail sur mobile savent interpréter les media queries.
Pour commencer correctement, vous pouvez utiliser le template de Campaign Monitor modifié par Eric Gideon (https://gist.github.com/egid/5208136).
Media queries et email
Les media queries fonctionnent très bien dans l’email à partir du moment où nous prenons quelques précautions. En effet, Yahoo va nous poser quelques soucis. Il va supprimer les références aux media queries tout en laissant les sélecteurs CSS des media queries dans notre email.
Si dans notre CSS nous avons :
td.contenuSimple { width:480px; }
@media only screen and (max-device-width: 480px) {
td.contenuSimple { width:100% !important; }
}Sur Yahoo! nous obtiendrons :
td.contenuSimple { width:480px; }
td.contenuSimple { width:100% !important; }Afin d’éviter que notre colonne fasse 100% de largeur sur Yahoo, nous allons devoir créer nos sélecteurs CSS de façon un peu différente.
Du coup nous allons faire ceci :
td.contenuSimple { width:480px; }
@media only screen and (max-device-width: 480px) {
td[class=contenuSimple] { width:100% !important; }
}
Et Yahoo n’interprétera que :
td.contenuSimple { width:480px; }En effet, il ne sait pas gérer les sélecteurs d’attributs pour l’instant. Cette méthode sera sûrement à revoir à l’avenir.
Remplacement d’image
Sur mobile, les images contenues dans un email ne sont pas forcément les mêmes que celles affichées dans le même email sur desktop (tailles différentes, texte plus gros, …). Nous avons donc besoin de remplacer l’image de la version desktop.
Dans notre exemple, nous souhaitons ceci (les dimensions ont été réduites de moitié) :
Sur Desktop
Sur mobile
Pour réaliser le remplacement, nous allons simplement cacher l’image d’origine et appliquer la version mobile en background avec des dimensions fixes, ex :
@media only screen and (max-device-width: 480px) {
td[class="headercell"] img { display: none; }
td[class="headercell"] a {
background-image: url(header-mobile.png);
width: 320px !important;
height: 253px !important;
display: block;
}
}
…
Gabarit en colonnes
Les gabarits multi-colonnes deviennent souvent des templates d’une colonne sur mobile. Pour arriver à cela il n’y pas beaucoup de solutions.
Voilà ce que nous souhaitons obtenir dans notre exemple :
Sur desktop
Sur mobile
Dans notre exemple le code HTML va ressembler à ça :
| Colonne 1 |
| Colonne 2 |
Nous avons donc deux tableaux dans une cellule qui ont chacun un attribut align. En desktop, nous aurons bien deux colonnes et sur mobile, s’il n’y a pas suffisamment de place, le deuxième tableau passera en dessous.
L’instruction mso-table-lspace:0pt; mso-table-rspace:0pt; sert à corriger un bug sur Outlook qui rajoute des marges sur les tableaux.
Conclusion
Sur le temps de production d’un email responsive, il faut compter le double d’un email classique pour vos premiers, un peu moins une fois l’expérience acquise. Mais cela dépend énormément du nombre de plateformes ciblées.
Avec du recul, la difficulté n’est pas d’avoir un email qui s’affiche bien sur iPhone, mais qu’il ait toujours un bon rendu sur Outlook.
