Oui le potentiel de blagues douteuses va être très élevé avec un sujet sur les polices de caractères.
Pourtant ce n’est pas un sujet léger et il ne fait pas rire les concepteurs d’email. Gérer de la typographie dans les newsletters met régulièrement les intégrateurs de mauvais caractère.
Doit-on forcement faire l’usage de la force avec la police ? C’est un vrai problème de “fonts” ! Bon OK j’arrête, concentrons-nous un peu.
Polices système
Ce sont celles installées et disponibles sur le terminal (ordinateur ou mobile).
Dans notre cas, l’important est de se positionner du côté de l’utilisateur : la personne qui va consulter les emails. Les polices présentes sur son terminal ne sont pas forcement les mêmes que celles présentes sur la machine qui a permis de créer l’email (celle du designer et/ou de l’intégrateur).
Il y a une forte dépendance au système d’exploitation (d’où l’appellation « police système »). Si l’on est sur un OS Apple ou Windows nous n’aurons pas les mêmes polices par défaut. C’est notamment lié à de la propriété intellectuelle, du droit d’auteur et des licences d’utilisation.
Un exemple de cette différence : un utilisateur ayant un device Apple aura un très bon support de Helvetica, alors que sur Windows ce ne sera pas le cas. La police de caractère visuellement la plus ressemblante (ceci va faire pleurer bon nombre de designers) sera Arial. Police de caractère qui n’est autre qu’un clone commandée par Microsoft.
C’est pas gagné cette histoire.
Déclaration de police
L’exemple précédent permet de comprendre l’utilité de définir plusieurs polices pour un même contenu. C’est ce que l’on appelle la fonts stack (empilement de police).
Pour un élément donné (un titre par exemple), on définit un ensemble ordonné de polices de caractère qui ont un dessin proche.
Selon l’environnement de l’utilisateur, celui-ci aura un affichage avec la police qui correspond. La font stack est souvent définie par typologie de police (sans serif, serif, cursive, monospace,…) mais d’autres critères peuvent entrer en jeu.
Là normalement vous comprenez qu’il va falloir commencer à faire des étirements et s’assouplir. Oui, le rendu de nos emails va être légèrement différent selon le contexte de nos utilisateurs.
La sécurité et le contrôle avant tout avec un “Web-safe font stack”
L’usage conjoint de polices système et de fonts stack permet de définir des ensembles dit « web-safe ». C’est à dire que ce sera supporté dans la plus grande partie des usages web (dont email).
Besoin d'aide ?
Lire du contenu ne fait pas tout. Le mieux, c’est d’en parler avec nous.
Pour mon titre, si je veux une police sans empattement (sans serif) alors je vais pouvoir énumérer dans l’ordre de mes préférences les polices :
font-family: "Roboto", "Calibri", Helvetica, Arial, Sans-serif;Si je suis sur Windows et que j’ai installé Roboto, alors j’aurai bien la Roboto affichée pour mes titres dans l’email. Si Roboto n’est pas installée, ce sera Calibri et si j’ai une version ancienne de Windows, alors ce sera Arial. Pour un utilisateur Apple ce sera Helvetica et pour les personnes sur une distribution de Linux ce sera Sans-serif.
- Avantage : on garantie le résultat affiché chez l’utilisateur.
- Inconvénient : le choix est restreint car dépendant des environnements utilisateurs.
Intégrer la police (Embed Web font)
Comment faire pour utiliser la police de ma charte graphique avec un choix aussi restreint ?
Il existe des solutions techniques afin de pouvoir intégrer des polices “custom”. C’est à dire des polices non présentes chez l’utilisateur et de les afficher en rendu dans les emails. Cela nécessite de faire appel dans le code HTML et CSS de votre email à une ressource hébergée qui correspond à la police de votre choix.
Toute fois il y a trois limitations principales à cela :
- Il faut être sûr de disposer de la licence (droit d’auteur) et de pouvoir la diffuser. Il sera de votre responsabilité de l’héberger sur un serveur pour qu’elle soit disponible. Si votre police est disponible sur Google fonts ou autre service similaire ça vous déchargera de la responsabilité. Mais lisez bien les licences tout de même car oui elles sont précisées sur Google fonts et Open Source ne signifie pas gratuit ou sans attribution.
- Tous les clients emails ne supporteront pas ces techniques (coucou Outlook). Il faut donc prévoir un fallback (solution de repli qui reviendra à choisir une police système en substitut dans votre font-stack).
- Corolaire du point précédent. Il faut que la police de substitution ait un dessin proche de la police d’origine pour ne pas générer d’effet de dégradation trop disgracieux (taille, graisse, crénage…). Voici deux exemples de polices qui ne se substituent pas bien : Smooch Sans et Open Sans
Il faut bien connaitre l’environnement d’ouverture de sa base avant de mettre en place une telle solution. Et surtout être conscient que ça ne pourra pas marcher pour 100% des cas (seulement 36.36%) et donc une fois de plus être très souple concernant le rendu de vos emails (continuer vos étirements matinaux).
Ouais d’accord, mais c’est qui LePatron dans le cas d’un outil de création d’email ?
Est-ce que l’email builder de Badsender (aka LePatron) peut intégrer des polices différentes dans les templates. Bien sûr !
Vous le savez, notre mot d’ordre c’est de faire du sur-mesure. De s’adapter à vos besoins afin d’avoir un template qui garantisse l’intégrité de votre charte graphique.
Par contre, avoir une liste d’une dizaine de polices différentes à disposition dans un email builder prônant une approche design system me semble être une mauvaise idée. D’autant plus si le template doit être utilisé par beaucoup de personnes différentes. Les emails produits auront un rendu différent d’un utilisateur à un autre selon les choix de typo qui seront faits. Cela va à l’inverse d’une démarche d’industrialisation de sa production d’emails et de la cohérence d’un design system.
Maintenant si c’est vraiment ce que vous souhaitez, cela reste faisable. Ce n’est juste pas recommandable du point de vue de l’identité de marque 😉
Conclusion
Faire des emails n’est pas une chose aussi simple qu’il n’y parait. Il faut prendre en compte une multitude de contextes d’usage. C’est valable pour le responsive et les background-image comme pour les polices personnalisées. Il existe toujours une solution, mais aucune qui ne puisse garantir un rendu 100% applicable à tous les clients emails. Si vous êtes du style control freak ou pixel perfect, il va falloir apprendre à lâcher prise.
