Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Quel doctype faut-il utiliser dans un e‑mail ?

Le doctype est la toute première ligne de n’importe quel document HTML. Mais savez-vous quel doctype utiliser et pourquoi ? Voici ma tentative d’expliquer tout ce qu’il faut savoir sur les doctypes pour des e‑mails HTML.

Lire la suite de « Quel doctype faut-il utiliser dans un e‑mail ? »

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Le démineur dans un e‑mail

Réalisé par Camille Palu de TABLE TR TD, ce démineur dans un e‑mail fonctionne vraiment (avec décompte du temps, écran de victoire…). Comme beaucoup d’e-mails interactifs, ça utilise principalement des cases à cocher, et ça ne fonctionne quasiment que dans Apple Mail. Mais c’est quand même un belle démo technique.

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Gmail va supporter la balise <style>, les media queries, les classes et plein d’autres trucs

La nouvelle secoue la communauté des développeurs et designers d’e-mails depuis hier : Google va supporter le Responsive Design « plus tard ce mois-ci ». Ça signifie support des balises <style>, des media queries, des attributs class et id en HTML. Google a mis en ligne des pages pour expliquer le support de CSS, et aussi une liste des media queries et propriétés CSS supportées.

Et la liste est particulièrement intéressante, avec notamment des propriétés CSS avancées comme background-blend-mode, columns, mix-blend-mode, object-fit, object-position, …

C’est vraiment une excellente nouvelle, et un immense bouleversement dans le monde de l’intégration d’e-mails. Certains annoncent déjà la fin de l’utilisation des styles en ligne (au profit uniquement de la balise <style>) et des méthodes fluide/hybride ou la technique des Fab Four. Mais je ne pense pas, car il reste encore un paquet de clients e-mails ne supportant ni les balises <style>, ni les media queries. (Coucou le nouvel Outlook.com !)

Mes principales interrogations à l’heure actuelle sont les suivantes :

  • Quelles versions de Gmail seront concernées ? L’annonce de Google indique que ça concerne « Gmail et Inbox by Gmail ». Mais j’expliquais le mois dernier que le support de CSS dans Gmail est bien plus nuancé que ça. Est-ce que ça concernera aussi les versions de Google Apps for Work et les comptes tiers dans Gmail sur Android ?
  • Quid du support des valeurs en CSS ? Est-ce qu’on pourra toujours utiliser calc(), linear-gradient(), etc. Est-ce qu’on aura également toujours le support de sélecteurs comme :hover, :first-child, etc. ?

Réponse d’ici deux semaines.

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

All the Slender Ladies

Dans la dernière vidéo de Feminist Frequency, Anita Sarkeesian aborde la représentation du corps des femmes dans les jeux vidéo :

Quand la majorité des femmes qui peuplent les mondes de ces jeux sont conçues à partir du même moule étroit, le problème n’est pas juste ce qu’on voit dans ces jeux. C’est ce qu’on ne voit pas. Le fait que des femmes rondes, ou des femmes avec des corps de différentes formes, ne soient jamais présentes dans ces mondes renforce l’idée fausse que ces femmes ont moins de valeur, sont moins dignes de reconnaissance, que les femmes dont les corps s’approchent le plus des standards culturels de beauté.

Les exemples utilisés dans la vidéo sont tous édifiants. Mais je crois que celui qui m’a le plus marqué est celui de Street Fighter, probablement parce que je m’étais habitué à voir ça sans me poser de question depuis que je suis tout petit.

street-fighter-femfreq

Weird Browsers

Vu sur Twitter (via Marie) : Niels Leenheer, le créateur de HTML5test.com, donne une conférence sur les navigateurs présents sur des appareils exotiques (télévisions, liseuses, consoles de jeux, appareils photo numériques, micro-ondes, …). J’adore ce sujet (que j’ai pour coutume d’appeler « intégration de l’extrême »). Sa fausse démo de contrôle d’un navigateur à base de gestes (à 17:35) est particulièrement marquante. Sa comparaison des largeurs de viewports sur TV et consoles est aussi très intéressante. Et j’ai aussi appris que, tout comme sur l’Apple TV, il n’y a pas de navigateur par défaut sur Android TV.

Essayer de comprendre le support de CSS de Gmail

« Est-ce que ça fonctionne dans Gmail ? » est une question récurrente dans le monde de l’intégration d’e‑mails. Mais la réponse dépend vraiment de la version de Gmail que vous utilisez. Et ça peut être difficile à comprendre car il y a plein de facteurs à prendre en compte. Voici ce que je pense avoir compris jusqu’à présent.

Lire la suite de « Essayer de comprendre le support de CSS de Gmail »

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Accessibility in Email

Mark Robbins a commencé à écrire une série d’article sur l’accessibilité dans les e-mails. Il y a pour l’instant une introduction et un article sur la sémantique. Mark a également donné une conférence sur l’accessibilité lors d’un meetup Email On Acid Insights en début de mois. C’est un sujet important, et c’est bien qu’on commence à entendre parler comme ça.

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Tout le monde sera bientôt sur le nouvel Outlook.com

Lu sur Twitter : d’après un tweet du compte @Outlook concernant le nouvel Outlook.com, « tout le monde aura migré d’ici la fin de l’été au plus tard ». Soit d’ici le 21 septembre. Aux États-Unis, tous les comptes sont passés au nouvel Outlook.com depuis la fin de l’an dernier. En France, les nouveaux comptes y sont par défaut depuis quelques mois. En mars dernier, je notais quelques points à savoir sur la nouvelle version d’Outlook.com.

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

« Thinking Outside the <table> » à The Email Design Conference 2016

Le mois dernier, j’ai eu l’honneur de donner une conférence à The Email Design Conference de Londres intitulée « Thinking Outside the <table> ». C’est un mélange de certains de mes précédents articles, comme Super Mail Forward, Flexbox dans un e‑mail ou la technique des Fab Four, mais avec une nouvelle narration et de nouveaux contenus.

J’ai publié mes slides bruts en anglais. Et voici une retranscription en français de ma conférence (une version en anglais est aussi disponible ici).


Je suis un intégrateur Web mais j’intègre aussi des e‑mails. La question qu’on me pose le plus souvent quand je dis ça à d’autres intégrateurs est « Comment va ta santé mentale ? ». Probablement parce qu’ils pensent à leur dégoût de devoir encore utiliser des tableaux pour faire de la mise en page, d’avoir à écrire des styles en ligne et autres bizarreries propres aux e‑mails. Mais je me suis toujours dit qu’il y avait bien plus à faire si on arrivait à dépasser ces premières impressions.

Aujourd’hui, je veux vous présenter trois exemples de choses que j’ai fait dans l’année passée qui illustrent ce qu’il peut se passer quand vous commencez à « penser en dehors de la <table> ».

Thinking Outside the table

Lire la suite de « « Thinking Outside the <table> » à The Email Design Conference 2016 »

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

HTML, CSS et JavaScript

Je conserve ici ce slide de Heydon Pickering sur HTML, CSS et JavaScript parce qu’il est presque parfait.

CSS - JS - HTML

J’aurais juste laissé CSS au dessus de HTML, et ça aurait été l’illustration parfaite pour répondre à tous ceux qui cherchent à construire des « applications robustes » toutes en JavaScript. À mettre en contraste avec cet autre slide posté en janvier dernier.

La pyramide alimentaire du Web

La différence entre un développeur junior et un développeur senior

Vu sur Twitter, ce tweet de Vicky Harp :

Un utilisateur réclame une fonctionnalité déjà existante dans le produit.
— Le développeur junior : « lol, idiot d’utilisateur »
— Le développeur avancé : « Fermé – Résolu »
— Le développeur senior : Ouvre un bug d’utilisabilité.

C’est tellement bien résumé.

Est-ce qu’un e‑mail doit avoir le même rendu partout ?

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Réinventer la roue

Je suis tombé récemment sur cet article initialement intitulé « Quand ne devrait-on pas utiliser WordPress ? ». J’ai d’abord cru à un article satirique, puis j’ai vite réalisé que l’auteur était sérieux. Parmi les arguments avancés pour justifier une utilisation systématique de WordPress, j’ai sursauté sur le suivant.

  • Il ne sert à rien de réinventer la roue.

Non merci ! Trop occupés

C’est un argument que je n’aime pas trop, mais que j’ai déjà entendu de la part de clients. Pour commencer, je n’aime pas la comparaison avec la roue. Je ne suis pas un travailleur à la chaîne qui assemble des pneus. Je suis intégrateur. Je me vois plus comme un artisan que comme un ouvrier sur une chaîne de montage.

Alors prenons une autre métaphore. Par exemple, la cuisine. Si vous allez dans un supermarché, vous trouverez certainement de quoi vous nourrir jusqu’à la fin de vos jours sans avoir jamais à cuisiner. Plats préparés, surgelés, conserves. Rien de telle qu’une bonne ratatouille surgelée, non ? Non ? Non ?

Mais alors, à quoi bon réinventer la ratatouille ?

Le premier argument qui me vient à l’esprit, c’est bien entendu la qualité. En cuisinant moi même une ratatouille, je connais la qualité de mes ingrédients.

Le second argument, c’est la facilité de personnalisation. Vous n’aimez pas les poivrons ? Aucun problème, je vous fait une ratatouille sans poivron.

Le dernier argument, c’est le plaisir. Découper soi même amoureusement ses aubergines, courgettes et tomates, et les faire revenir langoureusement à la poêle, c’est quand même autre chose que jeter un sachet plastique surgelé dans le micro-onde.

La ratatouille du film ratatouille, cuisinée par… Rémy

Le parallèle avec l’intégration, ou même le développement au sens large, n’est pas bien difficile à faire. Je suis un codeur dans l’âme. J’aime savoir comment fonctionne quelque chose avant de l’utiliser. J’ai besoin de m’assurer de la qualité de ce que j’utilise. J’aime aussi concevoir des pages et interfaces sur mesure, correspondant à un besoin précis. Et j’éprouve beaucoup de plaisir à faire tout ça, même si ça nécessite que j’y passe beaucoup de temps ou que j’y laisse quelques cheveux.

De la même manière que je pourrais me contenter de manger du surgelé tous les soirs, je pourrais me contenter de claquer du WordPress sur tous mes projets. Mais j’y perdrais surement vite goût.

Toute la subtilité de mon métier réside alors mon propre jugement de ma capacité à réinventer la ratatouille. Si on est vendredi à dix-sept heures et qu’il faut impérativement que je livre une page avec un carousel en 3D pour dans trente minutes, il y a des chances pour que je me jette sur la première bibliothèque faisant ça proprement que je trouverais.

Et ça ne signifie pas non plus que je vais systématiquement réessayer de réinventer la roue. J’aurais peu d’intérêts à créer mon propre pré-processeur CSS, mon propre langage de programmation, mon propre système d’exploitation, etc.

Pour citer Carl Sagan (dans un moment de télévision tel qu’on ne ferait plus de nos jours) :

Si vous souhaitez faire une tarte aux pommes à partir de zéro, vous devez d’abord inventer l’univers.

La semaine dernière, je suis tombé sur cet autre article intitulé « Je sais comment programmer, mais je ne sais pas quoi programmer ». Ce passage m’a apporté un autre argument pour réinventer la roue :

Dans la communauté du logiciel, l’attitude générale est de ne pas réinventer la roue. C’est presque mal perçu si vous réécrivez une bibliothèque quand une option mature et stable existe. Si c’est une bonne règle en général, les débutants ne devraient pas avoir peur de réinventer la roue. Quand c’est fait pour apprendre et pour s’entraîner, c’est très bien de faire une roue. C’est une partie importante de l’apprentissage. Par exemple, écrivez votre propre version de ls, mv, wget ou cowsay. Si vous souhaitez partir sur un jeu, alors faites un clone de Pong, Tetris ou Space Invaders. Vous n’avez pas besoin de reprendre toutes leurs fonctionnalités ou d’en faire une réplique exacte, mais vous démarrez avec votre objectif et une feuille blanche, et vous faites en sorte d’y arriver.

Il s’avère que Jeff Atwood avait écrit sur ce thème en 2009 :

« Ne réinventez pas la roue » devrait être utilisée comme un appel aux armes pour s’enrichir de toutes les solutions existantes, et pas comme une matraque pour affaiblir ceux qui voudraient légitimement construire quelque chose de mieux ou améliorer ce qui existe déjà. De ma propre expérience, malheureusement, c’est plus souvent ce dernier cas que le premier.

Donc, non, vous ne devriez pas réinventer la roue. À moins que vous ne prévoyiez d’en savoir plus sur les roues.

Les métiers du Web nécessitent un constant réapprentissage (« Les bonnes pratiques d’aujourd’hui seront les mauvaises pratiques de demain », disais-je il y a quatre ans). Réinventer la roue, c’est aussi une façon de s’assurer de rester dans la course plutôt que de regarder la roue tourner.

Le nouveau benchmark

Lu le mois dernier : ce commentaire sur Hacker News (via Twitter) en réaction à un test du dernier Macbook.

J’ai trouvé cette affirmation intéressante :

« Les nouvelles spécifications vous offrent une meilleure performance, mais aussi une meilleure durée de vie de la batterie avec, selon Apple, 10 heures de navigation web ou 11 heures de lecture de films iTunes. »

La lecture de films était autrefois considérée comme un test de facto de la rigoureuse autonomie qu’un ordinateur pouvait avoir. Les DVD tournoyant et les disques durs ont été remplacés par des SSD, et le décodage de vidéo avec accélération matérielle a remplacé l’utilisation maximale de votre processeur.

En revanche, la navigation web était autrefois considérée comme une utilisation légère de batterie. Récupérer du contenu réseau en mémoire, analyser du HTML de base, etc. Maintenant, avec JavaScript partout et la complexification grimpante des pages web, la navigation web est devenue l’une des choses les plus coûteuses que vous pouvez faire, en ce qui concerne l’autonomie. À vrai dire, sur mon Macbook Pro, maintenant qu’OS X indique quels processus consomment le plus d’énergie, les navigateurs web comme Safari et Chrome sont les seules choses que je vois apparaître dans les « Applications consommant beaucoup d’énergie ».

Je n’avais jamais vu les choses sous cet angle, mais le web est effectivement devenu un nouveau benchmark de facto.

Accessible Email

Je l’avais posté sur Twitter en mars dernier, mais je le reposte ici parce que c’est important. Accessible Email est un outil gratuit en ligne permettant de vérifier l’accessibilité de vos newsletters.

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

How bigdog is revolutionizing marketing with interactive email

Campaign Monitor a publié en octobre dernier un article sur les dessous d’e-mails interactifs, et notamment celui-ci de PRET A MANGER que j’avais déjà repéré. J’adore voir le brouillon qui a servi à la conception initiale.

Un brouillon d'e-mail griffonné sur papier

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Lessons learned while protecting Gmail

Google a publié les slides et la vidéo d’une conférence de Elie Bursztein (« Anti-spam and Abuse Research Lead » sur Gmail). C’est hyper-hyper intéressant. J’ai relevé notamment les quelques points suivants :

  • « Quand vous changez votre système et que vous déployez un correctif, n’en déployez pas qu’un à la fois. Déployez en plusieurs à la fois, comme ça c’est plus difficile pour [des hackers] de voir ce qui a changé. »
  • La sécurité est déployée sur l’ensemble des clients mail de Google (y compris les vieilles versions de Gmail)
  • En moyenne, entre 1 et 5 failles XSS sont corrigées par trimestre. Pour la première fois au premier semestre 2015, aucune faille XSS n’a été corrigée.
  • Google récompense ceux qui remontent des failles. En 2010, les récompenses étaient sous la barre des 5000$. Aujourd’hui, les failles étant plus rares, les récompenses tournent autour de 25000$.
  • Parmi les key challenges de 2016, Elie évoque les « media queries ».

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Ce qu’il faut savoir sur la nouvelle version d’Outlook.com

L’an dernier, Microsoft a annoncé son intention de remplacer son webmail Outlook.com par une version équivalente à son autre webmail Office 365. Le mois dernier, Microsoft a précisé que cette nouvelle version d’Outlook.com était en cours de déploiement partout dans le monde. Si cette nouvelle version n’est pas encore déployée pour tous les comptes Outlook en France, vous devriez pouvoir y accéder en vous créant un nouveau compte @outlook.fr dès aujourd’hui.

La nouvelle version 2016 d'Outlook.com

Je teste régulièrement mes intégrations d’e‑mails sur ce webmail (et sa version Office 365) depuis un an. Voici un petit compte-rendu de mes observations, et des bonnes et mauvaises nouvelles que ce webmail apporte.

Lire la suite de « Ce qu’il faut savoir sur la nouvelle version d’Outlook.com »

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

Le positionnement absolu dans un e‑mail

Mark Robbins a partagé une technique très intéressante pour simuler du positionnement absolu dans un e‑mail, la propriété position:absolute étant filtrée un peu partout. En résumé : en utilisant des margin dans des éléments à taille nulle (avec un max-width:0; max-height:0), on arrive au même résultat.

Cet article est une archive du blog précédemment hébergé sur emails.hteumeuleu.fr.

« Bobbie had a Nickel »

Vu sur Twitter, un long article sur Marissa Mayer et Yahoo, avec notamment cette anecdote invraisemblable.

Près de 4000 employés de Yahoo étaient assis et attendaient que Marissa Mayer arrive pour s’expliquer. […]

Mayer pris une grande respiration. Elle salua tout le monde. Elle leur rappela la confidentialité de cette réunion. Elle déclara avoir parcouru leurs questions, et qu’elle avait quelque chose qu’elle voulait leur lire. Elle tenait un livre dans ses mains. Un livre pour enfant. « Bobbie had a Nickel ».

Elle commença à lire.

« Bobbie avait un nickel rien que pour lui. Devait-il acheter des bonbons ou un cône glacé ? »

Mayer leva le livre, pour montrer aux employés les illustrations.

« Devait-il acheter une pipe à bulles ? Ou un bateau en bois ? »

Une autre illustration.

« Peut-être, quand même, qu’un petit camion serait mieux que tout ! »

Les employés présents dans la salle échangeaient des regards. À leurs bureaux, les employés à distance devenaient embrouillés.

Que faisait Mayer ?

Elle continua à lire.

« Bobbie s’assit et se demanda, Bobbie s’assit et pensa. Quelle pourrait être la meilleure chose qu’un nickel puisse acheter ? »

Mayer sembla sauter quelques pages. Elle lu, avec un peu d’agitation dans sa voix :

« Il pourrait s’acheter un sac de fèves ou une toupie. Il pourrait s’acheter un moulin à vent à offrir à son petit frère. Ou devrait-il s’acheter, se demande Bobbie, une petite boîte à crayons ? »

Mayer semblait lire avec une réelle frustration maintenant, comme si toute la colère et confusion de la salle s’en irait si tout le monde comprenait l’histoire qu’elle lisait à voix haute.

« Bobbie pensa, et soudain une idée brillante lui vint », Mayer lu, atteignant la dernière page du livre.

« Il dépensa son nickel comme ça… »

Mayer leva le livre pour montrer sa dernière illustration. C’était un dessin d’un petit garçon roux à cheval sur un manège.

Quasiment personne ne pouvait voir la page.

Personne ne compris ce que Mayer essayait de dire. […]

C’est quand Mayer est montée sur scène, s’est assise sur sa chaise, et leur a lu un livre pour enfant, en leur montrant les illustrations comme si elle était une maîtresse d’école et qu’ils avaient tous six ans. Plus tard, elle expliqua qu’elle avait lu ce livre parce qu’elle voulait dire que ce qui comptait le plus dans la vie était les expériences, et que son expérience chez Yahoo était fantastique jusque là.