HTeuMeuLeu

Depuis un peu plus d’un an, j’habite à la campagne. Le vacarme du ramassage des poubelles au réveil a été remplacé par le chant des oies et le meuglement des vaches. En contrepartie, j’ai dû troquer ma connexion ADSL citadine à 10 Mbits/s contre une connexion ADSL de campagne à 2 Mbit/s.

2 Mbit/s, c’est quand même pas mal. J’ai découvert le web avec une connexion 56 K, et j’ai grandi avec une connexion ADSL à 512 Kbit/s. À 2 Mbit/s, je peux télécharger presque 1 Go en une heure. (Avec une connexion 56 K, il m’aurait fallu plus de 2,5 jours.) C’est une connexion suffisante pour surfer sur le web dans des conditions convenables. Mais il y a quand même quelques inconvénients. Par exemple, dès que je veux regarder une vidéo en streaming. En dehors de Youtube et Vimeo, la plupart des lecteurs vidéo du web sont absolument atroces pour ma connexion. Par exemple ce matin, j’ai voulu regarder une vidéo chez Polygon vantant les graphismes d’un nouveau jeu Star Wars.

Voici ce que j’ai vu.

Autant dire que je ne trouve pas ces graphismes folichons. En forçant manuellement la vidéo en qualité élevée, j’étais déjà plus emballé. Mais j’ai du attendre près d’une minute pour que le lecteur ait téléchargé une dizaine de secondes. J’ai donc rapidement abandonné le visionnage de cette vidéo.

Là où ça se gâte, c’est quand la télévision (via ADSL) est allumée. Je passe alors d’un débit de 2 Mbits/s à 0,2 Mbits/s. Ça devient alors un tout autre monde. À 0,2 Mbit/s, il me faut environ quarante secondes pour charge une page d’un mégaoctet. Le web presque tout entier devient alors très, très lent. Quand il se charge. À 0,2 Mbits/s, n’importe quelle interface reposant lourdement sur du JavaScript devient tout simplement inutilisable. L’écran de chargement de Gmail me semble interminable. Je maudis les sites utilisant des polices personnalisées en CSS, car je suis condamné à regarder des pages sans aucun texte pendant qu’elles se chargent.

Je rencontre aussi parfois des surprises. Par exemple, le soir où Apple annonce le langage Swift et que je veux voir par simple curiosité à quoi ça ressemble, j’essaye de télécharger le livre de présentation sur iBooks.

« 2 heures » de téléchargement restant pour 308 Ko. Ça fait beaucoup. J’ai compris un peu plus tard pourquoi c’était si long. Au même moment, ma Wii U avait décidé de se mettre à jour. 2 Mbits/s moins la télé moins le téléchargement d’une mise à jour pour la Wii U égale plus grand chose pour le web.

Alors face à ça, je m’adapte. Je laisse des pages se charger en arrière-plan, et j’y retourne cinq minutes plus tard, en espérant que tout soit bien chargé. Mais là encore, je maudis certains sites qui forcent le rafraichissement des pages en utilisant une <meta http-equiv="refresh">. Je maudis aussi les sites qui utilisent un scroll infini plutôt qu’une pagination, parce que ça signifie que je suis condamné à regarder des contenus se charger, plutôt que de passer directement à la page suivante en arrière-plan. Et je maudis aussi les sites qui utilisent des scripts de lazyload pour des images (qui permettent de ne déclencher le chargement des images qu’une fois que l’utilisateur a scrollé jusqu’à leur niveau). Avec ma connexion de campagne, ça signifie que je dois encore une fois attendre devant mon écran que ces contenus se chargent.

Mais tout ça est en passe de changer ! En fin d’année dernière, j’ai découvert qu’Orange avait installé une antenne 4G à trois kilomètres de chez moi. Je suis alors aussitôt passé chez Sosh. J’avais pris un téléphone du boulot pour tester le débit en 4G. J’ai hurlé de joie en voyant le premier résultat sur SpeedTest.

Malheureusement, mon iPhone 5 ne supporte pas la 4G française (à part sur les fréquences de Bouygues Telecom). Mais rien qu’en 3G+, j’ai déjà un débit dépassant les 8 Mbit/s. C’est déjà un grand pas en avant pour moi pour le moment. Et je changerais peut-être de téléphone dans le courant de l’année pour profiter de la 4G.

Alors pourquoi je raconte tout ça ? Parce que ça me fait beaucoup réfléchir sur les statistiques de débit que je peux lire et parfois communiquer à mes clients. Juste parce que j’ai une connexion théorique de 2 Mbit/s ne signifie pas que j’ai ces 2 Mbit/s de disponibles pour surfer sur le web. Même quand ma télévision n’est pas allumée, je suis quasiment en permanence sur Spotify, qui pompe forcément une partie de mon débit.

Ça me fait réfléchir aussi, parce que les bonnes pratiques de report de chargement de fichiers se révèlent en fait être un enfer avec un petit débit.

Et puis ça me fait réfléchir, parce que la connexion la plus rapide avec laquelle j’ai accès au web est désormais sur mon téléphone. J’utilise quasiment en permanence cette connexion partagée depuis mon téléphone sur mon ordinateur. Si mon forfait n’était pas limité en téléchargement (à 3 Go), j’aurais probablement déjà résilié mon abonnement ADSL.

 

En août dernier, j’expliquais comment Gmail supporte bien la balise <style> et les media queries. Pas grand chose n’a changé du côté de Gmail depuis. Mais il s’avère que la compréhension collective des filtres opérés par Gmail a, elle, plutôt bien évolué. Quelques jours après la publication de mon précédent article, l’excellent FreshInbox a publié deux articles qui ont complètement changé ma compréhension de Gmail.

Dans le premier article, « Gmail supporte la balise <style>… en quelque sorte », Justin Khoo explique que simplement en ajoutant un sélecteur universel * devant une règle CSS, celle-ci ne sera pas supprimé. Dans mon précédent article, j’écrivais :

Malheureusement, Gmail supprime toute règle CSS contenant des pseudo-sélecteurs comme :first-child ou :nth-child().

C’est totalement faux ! Grâce à cette bidouille de sélecteur universel, on peut tout à fait utiliser des pseudo-classes. Si on prend par exemple le code suivant :

* div:first-child { background:red; }
* div:nth-child(2) { background:blue; }

Il sera transformé par Gmail ainsi :

div.m1479b618d2293d85 * div:first-child { background:red; }
div.m1479b618d2293d85 * div:nth-child(2) { background:blue; }

C’est déjà un grand pas en avant ! Mais ça signifie aussi qu’on peut aussi utiliser un sélecteur d’attributs. Et c’est là où les choses deviennent vraiment intéressantes.

Dans un article publié quelques jours après, Justin Khoo explique comment rendre un e-mail interactif dans Gmail en utilisant le sélecteur d’attributs. Grâce à la présence du sélecteur *, il utilise une règle avec la pseudo-classe :hover.

* [lang~="x-divbox"]:hover{
	background-color: green !important;
	color: white;
}

Comme Gmail supprime toute classe du code HTML, il détourne malicieusement l’attribut lang (qui lui n’est pas supprimé) pour cibler un élément en CSS. Est-ce que c’est sale ? Oui. Est-ce que ça fonctionne ? Oui.

Et c’est là où j’ai compris un truc. Le problème de Gmail, ce n’est pas son support de CSS, mais son support de HTML. En supprimant des attributs HTML de notre code, Gmail complique l’utilisation de CSS.

J’ai alors fait quelques tests afin de déterminer si d’autres attributs que lang ne pouvaient être utilisés, l’objectif étant de trouver un attribut qui puisse être utilisé à des fins de styles, mais sans incidence sur le rendu utilisateur. Malheureusement, Gmail supprime les attributs id, class ou data-*. Par contre, Gmail conserve les attributs title, alt, lang, mais aussi les attributs ARIA comme aria-labelledby.

J’ai rapidement écartés les attributs title et alt qui se retrouvent visibles facilement dans un navigateur. Et je reste alors partagé entre les attributs lang et aria-labelledby. D’après mes tests, une utilisation détournée de l’un ou de l’autre n’a pas d’incidence avec VoiceOver sous OS X. Cependant, un récent article d’Adrian Roselli met en garde contre l’utilisation détournée de l’attribut lang.

J’ai alors une préférence pour l’utilisation de aria-labelledby. Je suppose que si un lecteur d’écran ne trouve pas d’élément avec l’identifiant correspondant, il ignorera purement et simplement l’attribut (c’est bien ce qui se passe dans VoiceOver).

Voici un exemple de code fonctionnel dans Gmail avec cet attribut.

<div class="toto" aria-labelledby="toto">
	Ceci est un test.
</div>

.toto, * [aria-labelledby="toto"] { background:red; }

Ce code sera transformé comme ci-dessous par Gmail.

div.m1479b618d2293d85 .toto,div.m1479b618d2293d85 * [aria-labelledby="toto"]{background:red}

J’ai découvert chez Khoi Vinh ce sketch de Tommy Johnagin qui aide sa mère à installer iTunes. J’ai ri tout haut à ce passage :

Elle m’a appelé une heure après. « J’ai téléchargé une chanson. Est-ce que c’est censé s’ouvrir dans Microsoft Works ? » Non, maman. Non, ce n’est pas censé s’ouvrir dans Microsoft Works. Je ne sais même pas comment tu as fait pour que cela se produise. Je ne suis pas suffisamment intelligent pour être suffisamment bête pour revenir à l’envers et comprendre le nombre de choses que tu as fait de travers pour ouvrir une chanson dans Microsoft Works. Bill Gates ne pouvait pas ouvrir une chanson dans Microsoft Works. Le nombre de fois où ton ordinateur a du te dire « Êtes-vous sûr ? ». Et en toute confiance : « Oui ! Pourquoi est-ce que tu continues à demander ? ». L’ordinateur doit se dire « je ne pense pas que nous sommes censés être là Madame ».

J’aime beaucoup l’expression « être suffisamment intelligent pour être suffisamment bête ». Aussi je ne sais pas si c’est une erreur ou du génie, mais le sketch en question dans son album s’intitule « Mom Itunes ». Je penche pour la seconde option.

En décembre dernier, j’ai lancé la troisième édition de 24 jours de web, « le calendrier de l’avent des gens qui font le web d’après ». J’ai déjà donné quelques détails sur l’intégration du site. J’avais aussi écrit un compte rendu de l’édition 2012, mais rien sur l’édition 2013. Voici quelques remarques personnelles sur cette dernière édition et sur le projet en général.

Lire la suite de « Retour sur 24 jours de web, édition 2014 »

Les attentats perpétrés ce mercredi 7 janvier à Paris m’ont laissé sans voix. Je n’ai aucune idée de comment réagir face à ce genre de situation. Je regarde les chaînes d’infos en boucle. Je lis et relis des articles sur tous les sites d’information ressassant les mêmes informations. Comme si j’avais besoin de me rappeler que c’était bien arrivé.

Néanmoins, je trouve un certain réconfort à observer des rassemblements, un peu partout dans le monde ou en ligne, souvent derrière le slogan « Je suis Charlie ». Mais je n’ose pas prononcer ce slogan pour autant. Parce que si je suis pour la liberté d’expression, je n’ai jamais œuvré pour sa défense. Je n’ai jamais acheté le moindre exemplaire de Charlie Hebdo. Et je ne me suis encore moins battu pour pouvoir librement publier mes idées.

Charlie, oui. Et des journalistes, dessinateurs, et policiers assurant leur protection sont morts pour ça. Je n’ai pas le millionième de courage et de valeurs que ces gens avaient.

Ce matin, je lis que le site français d’Apple arbore fièrement une bannière avec le slogan « Je suis Charlie ». Et ça me met hors de moi.

Il y a une page Wikipédia recensant quelques exemples de censures opérées par Apple. Le plus approprié à vous donner est le suivant :

En décembre 2009, Apple a banni une application de dessins humoristiques appelée NewsToons par le dessinateur Mark Fiore, sur les motifs qu’elle « ridiculisait des personnalités publiques ».

En avril 2010, Fiore a gagné le prix Pulitzer pour ses dessins satiriques politiques, rentrant dans l’Histoire comme le tout premier dessinateur publié uniquement sur Internet à gagner le prestigieux prix journalistique. Suite à un tollé général après que l’affaire ait fait grand bruit au lendemain de sa récompense, Apple a demandé à Fiore de resoumettre son application, et elle a cette fois-ci été acceptée.

Fiore déclara : « Bien sûr, mon application a été approuvée. Mais que se passe-t-il pour quelqu’un qui n’a pas gagné un Pulitzer et qui fait peut-être une meilleure application politique que la mienne ? Est-ce qu’il faut une frénésie médiatique pour qu’une application avec du contenu politique soit approuvée ? »

Cet exemple date d’il y a quelques années, et il avait fait grand bruit dans la presse généraliste. Mais il ne se passe pas une semaine sans que je ne lise un exemple du même genre. Encore ce matin, justement, je suis tombé sur ce tweet :

Notre application iOS a été rejetée de l’App Store parce qu’un lien de support va sur le web vers une FAQ où nous mentionnons que nous avons une application disponible sur Android.

Alors, non, Apple, tu n’es pas Charlie. Tu œuvres au quotidien contre la liberté d’expression pour défendre tes intérêts commerciaux. Je comprends que tu sois ému par ces attentats et que tu souhaites apporter ton soutien. Mais dans ce cas, il est peut-être temps de revoir ta politique de revue des contenus afin de défendre la liberté d’expression plutôt que la brider.

Le mois dernier, j’ai été missionné par le Père Noël pour trouver une poupée « Elsa Chantant » pour ma filleule. Après une recherche sur Google, j’ai rapidement décidé de passer commande sur le site de Toys“R”Us (qui m’assurait d’être livré dans les temps, vu que je ne m’y prenais pas du tout à la bourre…). Je n’avais jamais passé de commande sur le site, et j’ai été très agréablement surpris par la simplicité et la facilité d’achat sur le site. En effet, dès la page panier, le site de Toys“R”Us propose un bouton « Acheter avec Paypal » qui me redirige directement vers Paypal. Je n’ai alors eu qu’à me connecter à mon compte Paypal, et toutes mes coordonnées ont été récupérées. J’ai ainsi pu passer une commande sans avoir à me créer de compte chez Toys“R”Us, ce qui est vraiment pratique dans ce genre de cas où je ne compte pas refaire d’achat.

À ce moment précis, j’étais un client totalement satisfait. Mais je ne sais pas si je peux en dire autant pour tout ce qui a suivi ma commande, hors du site, à travers les différents e‑mails reçus. Et en y repensant, j’ai l’impression que mon expérience est assez représentative de ce qui se passe pour un client après une commande en ligne. Cet article n’a donc rien du tout de personnel contre Toys“R”Us. Je tenais plutôt à partager quelques remarques et réflexions.

Lire la suite de « L’expérience après une commande »

Pour la troisième année consécutive, mon mois de décembre est rythmé par 24 jours de web (le « calendrier de l’avent des gens qui font le web d’après » dont j’avais parlé ici en 2012 et 2013). Le mois dernier, j’ai un peu retravaillé l’intégration du site, en particulier la page d’accueil et sa vue en calendrier. Voici des détails sur quelques points sur lesquels j’ai porté mon attention pour cette mise à jour.

Lire la suite de « Quelques détails sur l’intégration de 24 jours de web »

L’équipe de Inbox (le nouveau client mail de Gmail) participe à un AMA sur Reddit. À la question « Prévoyez-vous de supporter des e-mails responsive ? », Jason Cornwell (Lead Designer) répond :

Nous sommes intéressé pour supporter les media queries mais nous devons être sûrs de faire les choses correctement. Nos changements l’an dernier pour afficher les images par défaut dans Gmail étaient similaires : il y avait une tonne de travail compliqué lié à la sécurité qui devait se faire en coulisse avant que nous puissions rendre cette fonctionnalité en apparence simple sûre pour tout le monde. Vous pouvez en lire plus sur ce lancement ici : http://goo.gl/pJavzw

Après la récente regression de l’application Gmail sur Android 5, voici enfin un signe d’espoir de changement positif.

Comme je le craignais le mois dernier, la mise à jour d’Android 5.0 (Lollipop) force tous les utilisateurs de l’application E-mail à utiliser Gmail. L’icône de l’application E-mail est toujours présente dans le système, mais l’application n’affiche plus qu’un message invitant à basculer sur Gmail (merci à @YannDecoopman pour la capture d’écran). Cette modification ne concerne pas les précédentes versions d’Android (vous pouvez donc continuer à utiliser Gmail 5 et l’application E-mail sur Android 4.4).

Comme évoqué précédemment : c’est une très mauvaise nouvelle. Pour s’en convaincre, il suffit de comparer le support de CSS entre Android 4 et Gmail dans le gros tableau récapitulatif de CampaignMonitor. Pas de <style> dans le <head>, donc pas de media queries, et pas non plus de propriétés display et position. Ça signifie aussi que si vous vous basiez sur des bibliothèques toutes faites, comme Ink (de Zurb), vos e-mails s’afficheront comme ça pour tout le monde sur Android 5.

Le seul point positif, c’est que l’adoption des nouvelles versions d’Android est habituellement très très lente. Au 3 novembre 2014, seuls 30,2 % des utilisateurs de Google Play sont sur Android 4.4 (KitKat), sorti le 4 novembre 2013.

Dans la série « tout peut changer du jour au lendemain », cette semaine Yahoo.com a décidé d’arrêter de supporter la propriété display:none lorsqu’elle est appliquée directement en ligne via l’attribut style d’une balise HTML. C’est Mark Robbins qui l’a remonté sur les forums de Litmus. La propriété n’est cependant pas filtrée si elle est utilisée dans une balise <style> dans le <head>, ou si elle a comme valeur block. Ce changement ne concerne que le webmail desktop de Yahoo, et pas par exemple l’application mobile sur iOS.

Le mois dernier, je suis tombé via Twitter sur cette excellente conférence TED de Maysoon Zayid, une comédienne atteinte de paralysie cérébrale qui raconte son parcours face au ressenti de son handicap. C’est vraiment l’une des meilleures conférences TED que j’ai regardé ces dernières années. Voici quelques morceaux choisis :

S’il y avait des Jeux Olympiques de l’Oppression, je gagnerais la médaille d’or. Je suis Palestinienne, Musulmane, je suis une femme, je suis invalide, et je vis dans le New Jersey. […]

J’ai eu une bourse pour l’Université d’État d’Arizona, parce que je remplissais chacun des quotas. […]

Les gens avec des handicaps constituent la plus grande minorité au monde, et nous sommes les plus sous-représentés dans le spectacle. […]

En l’écoutant, ça m’a rappelé un sketch de Louis C.K. (qui avait fait le tour du web en image) :

J’ai lu quelque chose dans le journal qui m’a vraiment embrouillé l’autre jour. Ça disait que 80 % des habitants de New York sont des minorités…

Est-ce qu’on ne devrait pas arrêter de les appeler « minorités » quand elles représentent 80 % de la population ? C’est vraiment une attitude de blanc, vous voyez. Vous pourriez emmener un homme blanc en Afrique, et il vous dirait « Regarde toutes les minorités qu’ils ont ici ! ».

Cela m’amène à un projet qui m’occupe actuellement. J’ai commencé à travailler sur le lancement d’un nouveau site pour un client. J’ai regardé les statistiques d’un autre site du même client, et voici ce que j’ai vu :

Position	Navigateurs	Pages vues
1.	Microsoft Internet Explorer 11	12,8%
2.	Mobile Safari 7.0	10,3%
3.	Microsoft Internet Explorer 9	8,2%
4.	Microsoft Internet Explorer 10	6,6%
5.	Google Chrome 36.0	5,4%
6.	Microsoft Internet Explorer 8	5,3%
7.	None	4,4%
8.	Android Browser 4.0	3,7%
9.	Google Chrome 37.0	3,3%
10.	Mozilla Firefox 31.0	2,9%
11.	Google Chrome 32.0	2,0%
12.	Google Chrome 35.0	2,0%
13.	Safari (unknown version)	2,0%
14.	Google Chrome 31.0	1,7%
15.	Mozilla Firefox 30.0	1,6%
16.	Google Chrome 33.0	1,5%
17.	Mobile Safari 6.0	1,5%
18.	Mozilla Firefox 26.0	1,4%
19.	Mozilla Firefox 32.0	1,4%
20.	Google Chrome 34.0	1,0%

Regardez toutes ces minorités ! Aucune version de navigateur ne dépasse les 13 % d’utilisation. Même constat avec les différentes résolutions d’écran, où la plus courante (1024×768) ne représente que 14,3 % d’utilisation. Et tout ça, c’est sur près de deux millions de pages vues le mois dernier.

Je me suis toujours intéressé de près aux statistiques des navigateurs. Et ça me fascine toujours autant de voir à quel point, en à peine dix ans, nous sommes passés d’un marché monopolistique composé majoritairement d’utilisateurs d’Internet Explorer 6 sous Windows XP en 1024×768, à un marché composé d’un ensemble de minorités.

En juin dernier, Fiona Taylor Gorringe soulevait une question intéressante sur son blog : « 3 % des utilisateurs naviguent avec IE9 et 14 % des utilisateurs ont un handicap. Pourquoi on ne se préoccupe seulement que des premiers ? ». Je ne dirais pas qu’on se préoccupe « seulement » des vieux navigateurs et jamais des utilisateurs avec un handicap. Mais j’ai clairement bien plus de demande explicite pour ces premiers que ces derniers. C’est un peu une « attitude de blanc » appliquée au web. Mais les minorités sur le web ne sont plus forcément celles qu’on croit.

Cette semaine, Google a fait deux annonces importantes en rapport à ses clients mail.

La première, c’est que Gmail 5.0 supportera n’importe quel compte POP, IMAP ou Exchange. L’application sera disponible sur Android 5.0 à partir du 3 novembre prochain sur certains appareils. Il semblerait que Google en profite pour pousser les utilisateurs de l’application Mail native d’Android à migrer vers l’application Gmail (en témoigne cette capture d’écran issue de ce fil de discussion chez Litmus). Si c’est le cas, c’est une très mauvaise nouvelle, car l’application Mail d’Android propose un excellent support de CSS (styles dans le <head>, media queries, …), alors que Gmail est exactement l’inverse.

L’autre nouveauté de la semaine, c’est Google Inbox, une « nouvelle boîte de réception » réservée aux comptes Google, avec un client webmail, une application iOS, une application Android et un plugin Chrome. Malheureusement, le support de CSS est exactement celui de Gmail (et donc, pas terrible, si vous avez bien lu le paragraphe précédent).

Si l’optimisation de vos e-mails pour mobile repose uniquement sur des media queries, je ne saurais que trop vous conseiller de changer ça rapidement.

La semaine dernière se sont déroulées les conférences de Paris Web. Cet événement tient une place toute particulière dans mon coeur parce que c’est là-bas, il y a à peine deux ans, que j’ai donné mon tout premier lightning talk en public. Depuis, j’ai poursuivi mon petit bonhomme de chemin en tant qu’orateur, de la Kiwi Party l’an dernier à Sud Web en mai dernier. Cette année, j’ai eu l’immense honneur d’être retenu pour donner une conférence de cinquante minutes sur l’intégration d’e-mails à Paris Web. C’était à la fois la conférence la plus importante que j’ai pu donner, mais aussi celle qui m’a le plus déçu. Voici mon retour d’expérience sur ma conférence à Paris Web 2014.

On me traite souvent de masochiste parce que je parle d’intégration d’e-mails. J’ai même ouvert un blog sur le sujet. Mais l’intégration d’e-mails est au coeur de presque chaque projet web (de newsletters commerciales à un e-mail de mot de passe oublié pour l’admin d’un blog). Et pourtant, l’intégration d’e-mails est considérée comme un sujet anecdotique, presque tabou, et que personne ne prend réellement au sérieux. J’avais déjà proposé une conférence sur le sujet à Paris Web en 2013, en vain. N’ayant pas particulièrement d’autre sujet en tête ou me tenant à coeur cette année, j’ai re-proposé la même chose. Et j’ai été retenu.

J’étais alors particulièrement enthousiaste. « Ça y est », me suis-je dit, je vais enfin pouvoir mettre au grand jour tous les problèmes qui entourent l’intégration d’e-mails. Et avec un public comme celui de Paris Web, composé de représentants de tous horizons (W3C, fabricants de navigateurs, grosses boîtes en tout genre), c’est l’occasion idéale pour tenter de faire prendre conscience du problème, et quitte à rêver encore un peu plus, pour initialiser un changement. J’étais d’autant plus ravi quand lors de l’annonce du programme des conférences Paris Web, j’ai découvert que j’aurais l’honneur d’être dans la plus grande salle. C’est le coup de projecteur rêvé pour tenter de faire quelque chose.

J’ai donc commencé petit à petit en juin dernier à rassembler mes notes, mes idées, les horreurs que je peux rencontrer parfois en intégrant ou en recevant des e-mails. Et puis je me suis réellement lancé dans la préparation de ma présentation en septembre dernier. Et c’est à partir de là que ça s’est gâté. Fin septembre, j’ai reçu un e-mail d’un membre de l’équipe de Paris Web m’informant que l’oratrice prévue en même temps que moi ne pouvait plus venir. Ils ont réussi à trouver un remplaçant, mais comme il est anglophone, il faudra qu’il occupe la plus grande salle, qui est équipée pour une traduction audio simultanée. « Crotte », me suis-je dit. Et comme si ça ne suffisait pas, l’orateur en question n’est autre que Vitaly Friedman, le papa de Smashing Magazine, qui venait parler de bonnes pratiques du responsive. « Double crotte », me suis-je dit. Non seulement j’étais relégué dans la plus petite salle. Mais en plus j’allais avoir en face de moi une immense star internationale pour parler d’un sujet autrement plus attrayant que l’intégration d’e-mails.

J’ai poursuivi la préparation de ma présentation, en restant sur mon idée principale de faire une conférence pas trop technique, visant surtout à sensibiliser sur le sujet et toutes ses problématiques. J’ai aussi essayé de rendre ça un minimum divertissant, en y ajoutant des extraits d’un de mes films préférés (j’ai dépensé sans compter). Je me dit toujours que quitte à prendre cinquante minutes à des gens, autant essayer de leur faire passer un moment agréable. Au moins, même s’ils n’apprennent rien, ils ne trouveront pas ça complètement nul.

La première répétition devant mes collègues lundi dernier fut pénible. Je n’étais clairement pas prêt. Et surtout, je tenais tout juste une trentaine de minutes. J’ai passé les deux jours qu’il me restait à retravailler tout ça. Au total, j’ai dû passer l’équivalent de six jours (soit une bonne quarantaine d’heures) à préparer cette conférence.

Le jour J arriva. En parcourant mes slides tout seul dans ma chambre d’hôtel le matin même, je me suis senti prêt. Je tenais la conférence que j’avais envie de donner. J’étais planifié pour passer en deuxième l’après-midi. J’ai choisi d’assister à la conférence me précédant dans la même salle. Autant dire que je n’ai rien suivi. Je repassais mes slides en boucle dans ma tête. Et puis je commençais petit à petit à stresser. La plus petite salle dans laquelle je me trouvais n’était finalement pas si petite. En regardant le public autour de moi, ça faisait quand même beaucoup de monde. « Est-ce que ces gens resterons pour ma conférence ? », me demandais-je. J’ai rapidement eu la réponse. Une fois la conférence terminée, la salle s’est vidée. Je suis monté sur scène pour tout préparer et vérifier que tout fonctionne bien. Et je contemplais la salle désespérément vide. « On attends encore une minute et tu peux commencer », m’a lancé un membre de l’équipe de Paris Web. « Ah ? Mais on attends pas qu’il y ait plus de monde ? En une minute il n’y aura pas beaucoup plus de monde ! » ai-je pensé naïvement. J’ai compté, et on devait à peine être une soixantaine. Je m’attendais à ce que Paris Web soit l’événement où je parle devant le plus de spectateur. C’est en fait devenu l’événement où j’ai parlé avec le moins de spectateur. Je ne me suis pas laissé décourager pour autant, et j’ai lancé mon premier slide. (Non sans ironie, j’avais prévu de démarrer ma conférence en expliquant que l’intégration d’e-mails est un sujet qui fait fuir les intégrateurs.)

Finalement, tout s’est bien passé. J’ai avalé mes 188 slides les uns après les autres. J’ai entendu les gens rire. Je pense en avoir entendu d’autres pleurer en découvrant certaines horreurs. Je n’ai pas eu l’impression de trop bafouiller. Je n’ai pas eu de trou de mémoire. Tout s’est bien passé.

Et puis est arrivée l’obligatoire séance de questions-réponses. Et c’est là qu’est intervenu Daniel Glazman, co-président du groupe de travail sur CSS au W3C. Secrètement, j’espérais qu’il soit présent. À la fin de ma conférence, j’évoquais une réunion de travail du W3C sur l’intégration d’e-mails qu’il avait dirigé en 2007. J’espérais qu’il puisse partager son expérience, et pourquoi pas raviver la flamme pour tenter de relancer quelque chose sur le sujet. Sauf que le discours qu’il a tenu m’a littéralement refroidi. Il a expliqué que les équipes de Microsoft qui travaillent sur le moteur de rendu d’Outlook sont totalement distinctes de celles qui travaillent sur le moteur de rendu d’Internet Explorer. Et les équipes d’Outlook n’ont strictement rien à cirer de la qualité de leur moteur de rendu HTML. Et le W3C n’a aucune légitimité à débattre sur des spécifications liées aux e-mails. Aussi, je suis bien gentil avec ma conférence et mon petit blog sur l’intégration d’e-mails, mais si je veux que les choses changent, il faut absolument que j’écrive en anglais et que je participe au groupe communautaire du W3C. « Soit », ai-je pensé. Je ne suis pas convaincu que les équipes du webmail de La Poste lisent souvent ce genre de ressources… « Merci d’avoir passé six jours pour rien à préparer tout ça. Tu peux rentrer chez toi avec l’assurance que rien ne bougera dans les dix prochaines années » ai-je retranscrit dans ma tête.

Une salle presque vide. Une ambition réduite au néant. Voilà comment ça s’est terminé. Peut-être que je m’étais un peu trop monté la tête, peut-être que je m’étais mis trop de pression, en m’imaginant que j’arriverais faire à bouger les choses… Ou peut-être pas.

Les vidéos de toutes les conférences de Paris Web ont été rendues disponibles en ligne dès le jour même. (Au passage j’en profite pour féliciter toute l’équipe de Paris Web qui réalise un travail colossal et profondément utile, tout ça bénévolement.) À ma grande surprise, ma conférence est en train de vivre une deuxième vie sur le web. Sur le site de Livestream, elle affiche déjà 1891 vues (soit la troisième plus vue après les lightning talks et l’excellente conférence de Christophe Porteneuve sur JavaScript). Et puis surtout, sur Twitter ou ailleurs, j’ai reçu des commentaires très positifs. Et notamment des remarques inattendues comme celle de PinGoo sur mon blog dédié à l’intégration d’e-mails :

Pour info, [ta conférence] a fait pas mal réfléchir nos chefs de projets sur le temps que l’on passait à vouloir faire du pixel perfect sur nos newsletters. Merci !

Il ne m’était même pas venu à l’esprit que des chefs de projet puissent être intéressés par ma conférence (et aussi que des boîtes vendent encore du pixel perfect, mais ça c’est une autre histoire).

Et puis pas plus tard que ce matin, j’ai vu passé ce tweet de David Rousset, évangéliste HTML5 chez Microsoft :

Grâce à l’excellente conf à Paris Web de HTeuMeuLeu, nous allons peut-être enfin améliorer nos newsletters Microsoft !

Bon, à choisir, je préférerais que Microsoft améliore le moteur de rendu HTML d’Outlook. Mais c’est déjà un bon début. Et peut-être que finalement je n’aurais pas fait tout ça pour rien…

Cette semaine j’ai eu la chance de donner à Paris Web une conférence sur l’intégration d’e-mails intitulée « Comment sortir l’intégration d’e-mails de la préhistoire ». La vidéo est disponible en ligne, et j’ai publié mes slides annotés.

Voici en complément plein de liens et ressources sur les différents sujets abordés (dans l’ordre abordé lors de ma conférence).

Lire la suite de « « Comment sortir l’intégration d’e-mails de la préhistoire » à Paris Web 2014 »

On m’a récemment rappelé sur Twitter une pratique qui m’exaspère au plus haut point ces derniers temps. Sur certains sites, le clic secondaire sur des liens est rendu inutilisable. C’est le cas par exemple sur Factornews (j’aime beaucoup Factornews, notamment quand ils font des jeux de mots comme à la fin de cet article).

Dans la première zone d’actualités du site, chaque encart d’actualité est entièrement cliquable. Mais si j’utilise le clic de la molette de ma souris (pour ouvrir le lien dans un nouvel onglet), il ne se passe strictement rien. Si je maintiens appuyé la touche majuscule de mon clavier (pour ouvrir le lien dans une nouvelle fenêtre), mon raccourci sera ignoré et le lien sera ouvert dans la fenêtre courante.

Si le clic se comporte comme ça, c’est parce que ce n’est pas un vrai lien HTML. Ici, pour chaque actualité, seul le titre de l’actualité est dans une balise <a>. Le clic sur le reste de la zone est géré via JavaScript. La volonté de rendre toute la zone cliquable est fortement louable, mais l’annulation du comportement natif d’un navigateur engendrée nuit fortement à l’utilisabilité. Je rencontre ce genre de problèmes régulièrement sur d’autres sites comme Le Bon Coin ou LEGO Ideas.

Ce problème d’intégration est vieux comme le monde. Prenons par exemple le code HTML suivant.

<article class="item">
	<h1><a href="/faire-un-lien-sur-toute-une-zone-en-css">Faire un lien sur toute une zone en CSS</a></h1>
	<p>On m'a récemment rappelé sur Twitter une pratique qui m'exaspère au plus haut point ces derniers temps…</p>
</article>

En XHTML ou en HTML4, une balise <a> ne pouvait contenir que des éléments inline. Du coup, l’utilisation de JavaScript (voire de jQuery) était fortement recommandée pour résoudre ce problème. Aujourd’hui, les quelques lignes suivantes suffiraient à rendre toute la zone cliquable pour tous les éléments .item sur notre page.

document.addEventListener('DOMContentLoaded', function() {
	var items = document.querySelectorAll('.item');
	for(var i=0; i < items.length; i++) {
		var item = items[i];
		item.addEventListener('click', function() {
			var url = this.getElementsByTagName('a');
			if(url.length > 0)
				url = url[0];
			window.location = url;
		});
	}
});

Mais cette solution est à l’origine des problèmes d’utilisabilité qui m’exaspèrent tant.

La spécification HTML5 a changé la donne, et on peut désormais englober dans un <a> n’importe quel élément. On pourrait alors simplement englober tout notre .item d’une balise <a>. Mais ce n’est pas forcément une bonne idée, en particulier pour le référencement où il serait préférable de conserver un contenu texte court et pertinent.

Heureusement, une solution est possible en CSS. En utilisant un pseudo-élément ::before ou ::after, on peut le positionner en absolu par rapport au conteneur principal parent et faire en sorte qu’il occupe tout l’espace. Il faudra bien s’assurer que le conteneur parent en question (.item) ait lui aussi un positionnement non statique afin de restreindre le pseudo-élément du lien. Le code suivant fait alors l’affaire.

.item {
	position:relative;
}

.item a:before {
	content:'';
	position:absolute;
	left:0;
	right:0;
	top:0;
	bottom:0;
	background-color:rgba(0,0,0,0);
}

Ça fonctionne bien dans Chrome, Firefox, Safari et Opera. Pour Internet Explorer (9 et plus), il est nécessaire d’ajouter un fond transparent afin que la zone soit cliquable même au-dessus des autres éléments.

L’inconvénient de cette solution est qu’elle ne s’applique pas sur IE8. Même si le pseudo-élément est bien créé, celui-ci restera non cliquable sous les autres éléments de la zone. Mais si vous pouvez vous permettre d’avoir un fonctionnement dégradé gracieusement sur IE8, cette solution me semble assez élégante.

La première mise à jour avec du contenu téléchargeable de Mario Kart 8 est sortie aujourd’hui. La meilleure partie de cette mise à jour pour moi est la suivante, annoncée en début de mois :

L’ordre du menu suivant chaque course sera modifié en « Course suivante, suivi par « Voir les temps forts ».

Non seulement ils ont corrigé ce problème, mais surtout ils choisissent de le mettre en avant comme l’une des « fonctionnalités conçues pour améliorer l’expérience de conduite des joueurs ».

Le bon design, c’est aussi apprendre et corriger ses erreurs.