Tour d'horizon du 'responsive' dans le monde de l'e-mail

Ce n’est pas un mystère, il existe une véritable envie de la part des développeurs de réaliser des e-mails ‘responsive’. On a en effet à présent en main toutes les technologies qui permettent de rendre les contenus web adaptables, et c’est frustrant de se sentir limité sur les clients mail, qui évoluent plus lentement que les navigateurs web. Mais il existe des solutions. Alors…

Comment accomplir l’impossible sans vous perdre dans la jungle des clients mails.

clientsMail
[separator type=”” size=”” icon=”star”]

Le marché / Analyse
[row] [one_third] [counter count=”72″ title=”personnes sur 100″] [/one_third] [two_third] Ces dernières années, avec l’explosion du marché des smartphones et tablettes, les utilisateurs d’internet sont connectés en permanence, dans la rue, au travail, ou dans les transports en commun. Ayant de moins en moins de temps libre, cette dernière est une plage horaire qu’ils aiment optimiser en traitant leurs e-mails. Selon le SNCD, le Syndicat National de la Communication Directe, en 2013, sur la totalité des utilisateurs, 72% lisent leurs e-mails sur leur smartphone. [/two_third] [/row] [separator type=”invisible” size=”big” icon=”star”] C’est la raison essentielle pour laquelle les e-mails doivent être accessibles sur tous les supports, et être adaptés à la navigation au doigt.
Les utilisateurs sont de plus en plus exigeants, et, à mon sens, ils manquent de plus en plus de temps dans leur vie, et reçoivent énormément de sollicitations de toutes sortes, alors ils ‘filtrent’. On sait tous que le taux d’ouverture des e-mails est très bas : 23% en BtoB, et 29% BtoC ( analyse sur l’e-mail marketing publiée en 2013 par Mail Metrics).
Les emails sont souvent supprimés avant même d’être lus (Je plaide coupable !). Cela devient très difficile d’intéresser suffisamment les utilisateurs pour qu’ils ouvrent le précieux mail.
Mais si par chance, vous avez passé cette étape avec succès grâce à un titre accrocheur, et qu’une fois l’e-mail ouvert, l’utilisateur se retrouve face à quelque chose d’illisible sur son portable, c’est perdu. L’utilisateur n’aura aucune envie de lire cet e-mail. Il le supprime.
[separator type=”” size=”” icon=”star”]
Le code / Premières solutions et problématiques
2 options très simples et assez évidentes nous viennent à l’esprit rapidement :

– Un email classique archi simple optimisé pour le mobile avec des blocs les uns en dessous des autres, aucun colonage, des gros boutons et un design simple.

.. le code donnerait quelque-chose dans cet esprit :
simplecode
Mais si ce type de mail passera très bien sur les portables, il paraitra inadapté aux plus grands écrans (on n’a pas forcément envie d’avoir un bouton énorme quand on est sur desktop, on peut avoir envie d’un design un peu plus élaboré, et les lignes peuvent devenir trop longues et impossible à lire).
– Un email intermédiaire, reposant toujours sur l’utilisation de dimensions en pourcentages. Même principe que l’exemple précédent, mais ici on aura un design un peu plus élaboré, l’utilisation de colonnes sera possible par exemple :
simplecode2
Cela parait une solution simple et idéale, si ce n’est qu’avec ce genre de méthode les blocs de textes vont encore, comme dans le premier exemple, subir des changements énormes sur les très grands écrans ou sur les étroits écrans de smartphones. Les très longues lignes ou très courtes lignes deviennent vite illisibles, et l’apparence générale va en pâtir. Même chose pour les images, qui vont passer du trop grand au trop petit. Ce genre de mail passera mieux sur les tablettes, de taille moyenne, que sur les desktop et les portables.
Les deux solutions ci-dessus sont simples, et rapides à mettre en place, mais l’expérience utilisateur est loin d’être optimale. Il y aura toujours une part des utilisateurs qui sera lésée. [separator type=”” size=”” icon=”star”]

Concentrons-nous un peu plus sur le code / Tricks

J’ai fais plusieurs tests, lu beaucoup d’articles et de sujets de forum, et j’ai trouvé une solution, qui permet de faire fonctionner les emails à peu près partout. Il faudrait faire une sorte de compromis entre leurs deux options ci-dessus, en construisant un email à la fois fluide et adaptable, reposant sur l’utilisation de @mediaqueries et de quelques petites astuces, avec un design taillé pour les mobiles, une version plus adaptée au desktop, et un design fluide responsive pour les tablettes et les desktop. C’est la meilleure solution, mais pour l’instant ça reste un compromis.
Il faut savoir que tous les clients mails ne savent pas lire les @mediaqueries (Suivez ce lien pour en avoir une vue d’ensemble), ou provoquent d’autres problèmes. Si la version desktop de Gmail conserve bien les styles contenus dans la balise ‘head’ (contrairement à la légende répandue sur le web), la version mobile elle, supprime tout style contenu dans la balise. Idem pour Android… il faut donc les ajouter en inline, sur chaque élément html. Le problème, c’est qu’il est impossible d’ajouter les @mediaqueries en inline.

 La solution que je vous propose c’est de construire un mail avec deux colonnes qui passerait sur une seule colonne pour la version mobile.
L’app Android Gmail supporte seulement le CSS inline, intégré au html. Pas de médiaqueries, et pas de CSS externe. Vous pouvez aussi oublier le CSS dans la balise head, comme je vous l’ai dit plus haut.
gmail.com supprime plusieurs choses, à commencer par les balises html5 et les attributs comme les classes et id. Il ne laisse passer que du CSS inline et un tout petit panel de CSS dans la balise ‘head’.
iOS et Mac OS X mail supportent les media queries et le css. Ce sont les meilleurs de tous pour les mails.
Android autorise donc seulement le CSS inline, et ignore tout le reste. Alors si on reprend les exemples de code que j’ai donné précédemment, au lieu de mettre les styles dans la balise ‘head’, on va les ajouter en inline pour que notre e-mail s’affiche correctement sur android.
jj
Ensuite, on va s’occuper de Gmail. La cible prioritaire sera les plus grands écrans. Il va nous falloir contourner le problème des @mediaqueries. Gmail supporte le CSS inline, et un tout petit peu de CSS dans le ‘head’. Mais attention aux sélecteurs, il va falloir ruser. En effet, on ne pourra y placer aucune classe, et aucune ID. Il faudra utiliser uniquement les sélecteurs natifs. Toute la finesse sera dans l’utilisation judicieuse des sélecteurs de structure : les descendants, les adjacents, et les enfants, comme dans l’exemple ci-dessous:
yy
Cette façon de faire est rarement utilisée, il faut bien le reconnaitre, nous avons plutôt tendance à user de class et d’ID. Si cette méthode vous est étrangère, je vous conseille de lire ce très bon billet : Sélecteurs adjacents.
Grâce à ça, on va avoir du style dans la balise head qui sera lu par gmail, mais pas par Android, qui lira les styles inline. On va pouvoir pointer plus précisément les clients mails avec ce genre de technique, sans @mediaqueries.
Pour les clients mails modernes, comme mail.app sur iOS et Mac OS X, vous allez pouvoir utiliser des @mediaqueries, et tous les sélecteurs que vous voulez. Attention, les styles que nous avons écrits pour Gmail vont s’appliquer, il faudra donc les écraser avec une @mediaquery.
hh
Ce n’est certainement pas la meilleure méthode, comme je vous l’ai dit c’est un compromis. Pour l’instant cette méthode fonctionne plutôt pas mal, mais le fait d’utiliser plusieurs niveaux d’écrasement des styles va vous obliger à bien réfléchir à la structure html.
[separator type=”” size=”” icon=”star”]

Conclusion / Conseils

On peut se demander s’il est mieux d’adapter le mail pour qu’il soit lisible correctement sur les clients mails utilisés par notre public cible, ou bien si il faut pousser l’exercice à rendre le mail lisible partout. On est tenté de vouloir le rendre lisible partout, mais c’est pour l’instant impossible. Pour l’instant, c’est uniquement un “presque”. Ce qui est sûr, c’est que construire un e-mail devient de plus en plus complexe.
Pour nous aider, il existe des plateformes qui vont permettre de tester le rendu de notre e-mail sur les différents clients mail, comme « Litmus » ou « E-mail on Acid » par exemple, mais la plupart sont payantes. Il est toutefois clair que sans ces plateformes, tester le rendu sur tous les devices et sur tous les clients mails devient mission presque impossible (à moins d’avoir plein d’amis, mais alors vraiment plein d’amis, qui utilisent plein de clients mails différents sur plein de devices différents…), et surtout très chronophage. A ce jour, je n’ai pas trouvé de plateforme qui propose le même service gratuitement. J’avoue que Litmus est très tentant… mais cher. Certains professionnels y verront certainement un bon investissement qui leur fera gagner un temps considérable.
J’ai relevé également « Preview my e-mail », qui est, lui aussi, payant.
Peut-être qu’une bonne idée serait de construire un template responsive de base, qu’on adapterait au besoin, histoire d’éviter de refaire tout le travail à chaque e-mail.
Il existe certainement plein de templates de ce genre disponibles sur le web. Je pourrai écrire un sujet dans quelques temps à ce propos.
//Cet article est évidement évolutif.
Emmanuelle GUYOT / UX-Scientist