HTeuMeuLeu

A Blind Legend est un jeu d’action-aventure audio jouable sur mobile.

Il s’appuie sur les sons binauraux permettant de se repérer dans un environnement en 3 dimensions uniquement par le biais de l’audio, et l’écran tactile du mobile pour contrôler le héros.

Ce jeu est créé par les lyonnais de DOWiNO, et il est en financement participatif sur Ulule depuis un peu plus d’un mois. Il ne reste plus que deux jours pour les aider à financer 22 % du montant total.

Je trouve que c’est vraiment un beau projet, et j’ai participé à son financement sans hésitation. Les développeurs ont sorti une démo du concept de jeu audio (pour Windows ou OS X), et ça m’a conforté dans mon premier ressenti. Je suis fasciné par l’idée de jouer à des jeux à l’aveugle depuis que j’ai lu les histoires de ce canadien qui a fini Zelda : Ocarina Of Time ou cet américain qui a fini Oddworld : L’exode d’Abe.

J’espère que le financement arrivera à son but, et que peut-être vous aussi vous participerez à cette belle aventure.

 

En mai dernier, j’avais retweeté cette comparaison que j’aime beaucoup (traduite par mes soins) :

Une interface utilisateur, c’est comme une blague. Si vous devez l’expliquer, c’est qu’elle n’est pas si bonne.

La citation a été reprise en français (sans mention de l’auteur original, tant pis), mais avec une légère déformation au passage :

Une interface utilisateur, c’est comme une blague, s’il faut l’expliquer c’est qu’elle n’est pas bonne.

Cette déperdition dans la traduction a généré quelques débats intéressants ici ou là. Et si je suis le premier à détester les explications pour utiliser une porte et à préférer l’apprentissage par le design, je sais aussi reconnaître que la complexité est parfois nécessaire.

Prenons par exemple le tableau de bord d’un Airbus A380.

Au premier abord, pour le néophyte que je suis, cette interface me paraît atrocement compliquée. Mais c’est peut-être parce que je n’y connais absolument rien en aviation. Et cette interface est destinée à être utilisée par des professionnels, ayant suivi des années de formations spécifiques. En soi, c’est plutôt rassurant de se dire que l’interface d’un appareil servant à transporter 800 personnes dans les airs est incompréhensible pour le premier venu.

Je pourrais en dire de même pour les interfaces des logiciels de traders ou même l’interface de World of Warcraft. Mais ces remarques sur les interfaces sont aussi valables pour les blagues.

Voici une de mes blagues préférées découverte ces dernières années (catégorisée dans les « blagues de papas »).

— Call me a taxi.
— OK. You’re a taxi.

Au risque de passer pour un idiot, je n’avais pas compris cette blague à sa première lecture. Mais dès que je l’ai comprise, j’ai trouvé ça drôle. C’est une bonne blague. La même chose est valable pour la blague anglophone suivante, lue chez Bruce Lawson :

Jean-Pierre : Toc-toc.
Armand : Qui est là ?
Jean-Pierre : Loste.
Armand : Loste qui ?
Jean-Pierre : Oui, malheureusement.

J’ai dû chercher des explications pour comprendre cette blague. Ça ne signifie pas que c’est une mauvaise blague. Maintenant que je la comprends, je l’apprécie beaucoup.

Une interface utilisateur, c’est comme une blague. Certaines blagues sont compréhensibles instantanément. D’autres nécessitent des explications pour être comprises par des gens comme moi qui pourront ensuite la trouver drôle. Mais ça ne suffit pas pour déterminer si une interface est bonne ou pas.

J’ai aussi regardé récemment Tim’s Vermeer, un documentaire produit par Penn & Teller (les magiciens). Ils suivent un de leurs amis informaticiens, Tim Jenison, qui s’est mis en tête de reproduire La Leçon de musique de Vermeer.

Je ne connaissais pas Vermeer plus que ça, mais il est soupçonné d’utiliser un système de projection et d’optique afin de reproduire des scènes avec un rendu précis et réaliste.

Ça m’a fait bizarre, parce que ça m’a rappelé certaines techniques employées au début du millénaire pour reproduire des pages web au pixel près (rires), où l’on superposait une maquette en JPG au dessus d’une page web pour s’assurer de bien respecter le travail du gentil graphiste web (à la main ou avec des outils comme Pixel Perfect).

Tim’s Vermeer est disponible en import chez Amazon.fr, et la bande-annonce est visible sur son site officiel ou sur Youtube.

Le week-end dernier, j’ai enfin regardé The Crowd Work Tour de Todd Barry. Le principe : pas de sketchs, pas de blagues préparées. Todd arrive chaque soir sur scène les mains dans les poches, et il commence à discuter avec certaines personnes du public. C’est au final très plaisant et plutôt drôle. Et c’est disponible pour seulement 5$ dans une version sans DRM chez Louis CK. (Si vous n’avez jamais rien acheté chez Louis CK, faites-le, c’est une très bonne expérience).

J’aime bien ce spectacle, parce que ça corrobore l’idée que la personne la plus intéressante lors d’une représentation n’est pas forcément celle qui est sur scène. Ça me fait penser à la « quête de sens » de Sud Web 2013.

En préparant ma conférence pour Sud Web 2014, je suis tombé sur une excellente citation de Donald Rumsfeld, ancien Secrétaire à la Défense des États-Unis d’Amérique. Il répondait en 2002 aux reproches de journalistes sur le manque de preuves de possession d’armes de destruction massive par le gouvernement Irakien.

Il y a des connaissances connues; ce sont les choses que nous savons que nous savons. Nous savons aussi qu’il y a des méconnaissances connues; c’est à dire que nous savons qu’il y a des choses que nous ne savons pas. Mais il y a aussi des inconnues inconnues, celles que nous ne savons pas que nous ne savons pas.

Ça lui a valu un Foot in Mouth Award. Mais j’ai trouvé que ça collait parfaitement à la description de mon métier d’intégrateur et la façon dont j’aborde ma veille.

Tout d’abord, il y a les choses que je sais que je sais. Par exemple, je connais les positionnements flottants en CSS, et je sais m’en servir. Ensuite, il y a les choses que je sais que ne sais pas. Par exemple, je sais qu’il existe des polices d’icônes, mais je ne sais pas m’en servir car je n’ai jamais eu l’occasion d’en utiliser sur aucun de mes projets. Enfin, il y a les choses que je ne sais même pas que je ne sais pas. Je ne peux pas vous donner d’exemple, puisque par définition, je ne sais pas ce que je ne sais pas.

Le but pour moi dans ma veille quotidienne est de réduire au maximum cette zone « d’inconnues inconnues ». Le métier d’intégrateur devient de plus en plus complexe et diversifié. Il y a deux ans, déjà, j’écrivais qu’une maîtrise complète de l’intégration n’est plus possible. Du coup, l’objectif pour moi est d’avoir une vision suffisamment large pour qu’à chaque choix que je doive faire lors d’une intégration, j’ai un maximum de cartes en main pour m’assurer de faire le bon choix.

Mario Kart 8 est sorti, et j’ai pu m’en délecter une bonne partie du week-end. J’adore certaines nouveautés, comme les portions de circuits sur des routes anti-gravité. Je m’accommode de certains changements, comme le fait qu’on ne puisse plus maintenir un objet à l’arrière de son kart et prendre un autre objet en même temps. Mais il y a un changement qui m’insupporte déjà plus que tout.

À la fin de chaque course en mode Grand Prix, il y a un écran de menu qui permet  de passer à la course suivante, de voir le replay de la course, ou de quitter la partie. Voici un aperçu de ces écrans dans les précédentes versions de Mario Kart (respectivement Mario Kart Double Dash, Mario Kart Wii, Mario Kart DS, et Mario Kart 7).

Et voici maintenant le même écran dans Mario Kart 8.

Nintendo a choisi de mettre le bouton vers le replay en premier, et le bouton vers la course suivante en second. Résultat : je me trompe régulièrement en appuyant par réflexe sur le bouton de validation dès la fin d’une course et je me tape donc le replay au lieu de passer à la course suivante.

C’est vraiment le genre de changement que je déteste dans une interface. 95 % du temps, je vais choisir d’accéder à la course suivante. Les 5 % restants seront partagés entre l’envie de revoir la course si vraiment il s’est passé un truc exceptionnel, ou de quitter la partie si je me suis complètement planté. Du coup, j’ai le sentiment que Nintendo me force à utiliser son nouveau système de replay Mario Kart TV, au détriment du jeu en lui même.

Il y a quelques années, j’ai donné des cours d’intégration web dans une école supérieure de Lille. L’expérience fut particulièrement enrichissante, mais j’ai arrêté au bout de deux ans pour pas mal de raisons. Et parmi ces raisons, il y a le fait que je me suis rendu compte à l’époque qu’enseigner l’intégration, c’est incroyablement difficile.

Cela fait partie des sujets que j’ai abordés vendredi dernier lors de ma conférence à Sud Web. J’ai eu le droit à pas mal de questions, et notamment une de Delphine : est-ce que les cours que je donnais sont disponibles quelque part, et sinon quelles ressources utiliser pour enseigner l’intégration ?

Je me suis tout de suite revu me poser exactement cette deuxième question quelques années auparavant, malheureusement sans y trouver de réponse satisfaisante. Dans un milieu où le partage de nos savoirs est si important, il semblerait que les ressources de cours destinés aux débutants et orientés sur la qualité et les bonnes pratiques soient plutôt rares. Et c’est ainsi qu’est né l’envie d’animer un atelier avec Delphine le lendemain à Sud Web sur ce sujet : comment enseigner l’intégration web ? Romy nous a rejoint pour l’occasion, ainsi qu’une bonne vingtaine de participants pour en discuter pendant une heure et demie.

Voici un résumé des grands points que j’ai retenus de ces échanges :

• Plus que la technique, il faut que les étudiants comprennent et retiennent les grands principes du web : accessibilité, interopérabilité, maintenabilité, référencement, standards du web, sémantique.
• Les étudiants ont besoin d’un projet concret pour motiver l’apprentissage. Lister la centaine de balises HTML5 n’a aucun intérêt en soi. Les grands principes théoriques doivent être distillés à petite dose, au bon moment, et toujours appuyés par un scénario pratique, qui peut partir d’un cas simple pour ensuite se complexifier.
• Les étudiants doivent apprendre à apprendre. Ils doivent devenir autonomes face à un problème. La recherche d’autorité quand on débute est importante (comme dans le cas de l’apprentissage d’un élève artisan avec son maître). Mais il faut aussi apprendre à peser les pours et les contres de chaque solution, et apprendre de ses erreurs.
• On manque aujourd’hui de ressources et d’outils destinés à des cours pour débutants. Un outil conçu spécialement pour l’apprentissage (comme un Bootstrap destiné uniquement à ça), ou un éditeur visuel adapté. L’idée d’avoir des tests automatisés permettant d’avoir un résultat clair à atteindre, un peu comme lors d’un Coding Dojo, a été suggérée.
• L’enseignement de l’intégration dépends fortement du format et de la fréquence des cours, ainsi que du profil des étudiants. On n’approfondira pas de la même manière si l’on n’a qu’une heure de cours par mois face à des étudiants hétérogènes que si l’on a huit heures par semaine avec des étudiants développeurs.

Si cet atelier n’a abouti à rien de concret, il me fait beaucoup réfléchir, et me donne vraiment envie de chercher comment améliorer cette situation.

En attendant, j’aimerais beaucoup avoir les retours d’enseignants ou d’étudiants en intégration web. Comment enseignez-vous l’intégration web ? Ou comment avez-vous appris l’intégration web ? N’hésitez pas à partager vos réponses sur votre blog ou dans les commentaires ci-dessous…

Il y a du nouveau sur le webmail mobile de La Poste et son interprétation des media queries depuis mon précédent article. Mais ce n’est pas mieux pour autant.

Précédemment, je remarquais que le webmail mobile de La Poste supprimait systématiquement la première media query au sein d’une balise <style>, mais tout en conservant quand même les règles à l’intérieur de cette media query. J’ai remarqué cette semaine que ce problème avait été corrigé. La première media query n’est donc plus supprimée.

Mais, parce que forcément il y a un mais, celle-ci est désormais préfixée par le préfixe ajouté automatiquement par La Poste. Ainsi le code suivant…

.toto { background:red; }
.tutu { background:blue; }

@media only screen and (max-width:600px) {
	.toto { background:white; }
	.tutu { background:black; }
}

@media only screen and (min-width:320px) {
	.toto { color:white; }
	.tutu { color:black; }
}

… sera transformé par le webmail mobile de La Poste en :

.wrapper_h8ufTw .toto { background:red; }
.wrapper_h8ufTw .tutu { background:blue; }

.wrapper_h8ufTw @media only screen and (max-width:600px) {
	.toto { background:white; }
	.wrapper_h8ufTw .tutu { background:black; }
.wrapper_h8ufTw }

@media only screen and (min-width:320px) {
	.toto { color:white; }
	.wrapper_h8ufTw .tutu { color:black; }

Autrement dit, les règles contenues dans la première media query ne fonctionneront pas sur le webmail mobile de La Poste. Pour palier à ça, ma recommandation du précédent article fonctionne toujours : ajoutez systématiquement une media query avec une règle factice avant vos vraies déclarations :

@media only screen and (max-width:0) { 
	body { margin:0; } 
}

Au passage, j’ai remarqué deux autres points sur l’interprétation des styles par le webmail mobile de La Poste :

• Si un bloc de styles se termine par une media query, l’accolade fermante de celle-ci sera supprimée (cf exemple ci-dessus).
• La première règle suivant une media query ne sera pas préfixée.

Mozilla a sorti hier Firefox 29, avec plein de nouveautés, dont l’interface Australis présentée en août 2011. Pour l’occasion, la page d’atterrissage après téléchargement arbore un nouveau slogan : « Engagé pour vous, votre vie privée et le Web ouvert ».

Curieux de voir comment la page était construite (en particulier le guide interactif des nouvelles fonctionnalités), j’inspecte le code source. Et là, à ma grande surprise, je découvre que la page inclut le script de Google Analytics, et que tous les clics au sein de la page sont trackés, et les données envoyées à Google. Je relève cette contradiction avec le slogan de la page sur Twitter. Et rapidement, mon tweet est retweeté en grand nombre. Et @clochix aura la bonne idée de remonter cette incohérence sur Bugzilla.

Mais les réponses apportées par les membres de la communauté Mozilla seront à l’encontre de mes attentes. La discussion est très rapidement close, et on y explique que l’utilisation de Google Analytics fait partie de la politique de respect de la vie privée sur les sites de Mozilla. Chris More, responsable de l’équipe des sites de Mozilla, invite au téléchargement d’une extension pour bloquer Google Analytics. Et David Bruant, contributeur Mozilla, invite à poursuivre la discussion dans un groupe Google.

À ce stade, voici l’image qui me vient à l’esprit d’un Mozillien typique :

Le problème, ce n’est pas l’utilisation de Google Analytics. C’est un excellent outil, et je suis le premier à m’en servir, et à le proposer à mes clients. Par contre, je sais pertinemment qu’en utilisant ce service de Google, j’expose mes visiteurs à fournir un peu plus de données sur eux à Google, sans leur consentement.
Et puis pour être honnête, la décision d’utiliser Google Analytics chez Mozilla semble avoir été murement balancée, en désactivant notamment l’exploitation des données envoyées avec Google et ses tiers. Et l’inclusion du code de suivi en lui-même est aussi faite proprement, avec l’utilisation de la fonction _anonymizeIp() qui « supprime le dernier octet de l’adresse IP avant son stockage » chez Google.

Le problème, c’est, de mon point de vue, de se vanter de s’engager pour la privée de ses utilisateurs d’un côté, et d’avoir une relation de plus en plus dépendante à Google de l’autre. Parce qu’il ne s’agit pas que de Google Analytics. Mozilla dépends financièrement de Google. C’est une relation idyllique : Google paye Mozilla 300 millions de dollars par an, et Mozilla renvoie tous ses utilisateurs sur une recherche Google par défaut pour y cliquer sur des publicités AdWords. Sur le marché des navigateurs, Mozilla a pour mission de vendre du temps de cerveau disponible à Google en quelque sorte. Et Google, en terme de vie privée, c’est le mal absolu.

J’utilise des tas de services Google. Mais en les utilisant, je sais pertinemment que c’est au détriment de ma vie privée. Ainsi, je n’ai absolument aucune confiance en Google en ce qui concerne la protection de mes informations personnelles.

Alors pourquoi est-ce que je devrais faire confiance à Mozilla ?

Mozilla s’est construit en menant une lutte acharnée contre le monopole de Microsoft au début des années 2000. Ils ont fait un travail remarquable qui a permis d’arriver aujourd’hui à un marché et une concurrence saine entre les navigateurs desktop. Mais aujourd’hui, la société monopolistique qui fait peur à tout le monde, ce n’est plus Microsoft. Ce n’est pas Apple, qui n’a jamais eu le moindre monopole. Non, c’est Google, qui grâce à son monopole dans le domaine de la recherche, s’impose partout ailleurs.

Cette année, le contrat de trois ans signé entre Google et Mozilla en 2011 arrive à son terme. Nulle doute qu’il sera reconduit, pour un montant probablement encore plus élevé que le précédent (sachant que Google donne trois fois plus d’argent à Apple qu’à Mozilla pour être le moteur de recherche par défaut). Mozilla a le pouvoir incroyable de faire trembler le monopole de Google en refusant un nouvel accord. Mozilla pourrait alors être plus crédible à mes yeux pour parler de respect de vie privée.

Francisco Tolmasky, ancien développeur dans l’équipe de Safari sur iPhone chez Apple, raconte des anecdotes sur Steve Jobs :

M. Jobs était connu pour s’imposer autant qu’il le pouvait. Une personne de l’équipe de design de l’iPhone s’appelait aussi Steve, ce qui causait une certaine confusion dans les réunions. M. Jobs a cherché à changer ça.

« À un moment, Steve Jobs était vraiment frustré à cause de ça et a dit « Devine quoi, à partir de maintenant tu seras Margaret » », expliqua M. Tolmasky. À partir de ce moment là, les membres de l’équipe s’adressèrent à Steve le designer comme Margaret.

Autrement dit, Steve Jobs avait un petit côté Dr. Cox.

Jolie trouvaille vue cette semaine sur Twitter : l’application E-mail par défaut d’Android (aussi connue sous le nom de « pas Gmail, l’autre ») affiche le contenu de la balise <title> dans les notifications du système.

J’ai réussi à reproduire ce problème facilement sur une Nexus 7 sous Android 4.4.2. Cela ne concerne que cette application, et que l’affichage en notification. Ce texte n’est retrouvable nulle part ailleurs une fois dans l’application.

Veillez à avoir un contenu de <title> pertinent pour éviter d’afficher un « Document sans titre » ou « Responsive template ».

Cette semaine, j’ai eu la tristesse d’apprendre la fermeture de Five Simple Steps, un éditeur de sympathiques livres numériques sur la conception web. Ça m’embête d’autant plus que j’avais plein de leurs livres sur ma liste de choses à acheter un jour. Heureusement, certains auteurs ont déjà franchi le cap pour remettre à disposition leur livre ailleurs, et ce parfois désormais gratuitement. Voici une liste où trouver les titres initialement publiés par Five Simple Steps (bien aidé par la liste démarrée par Nick Bramwell et iTunes Link Maker).

A Pocket Guide

• Colour Accessibility, de Geri Coady, 5 $ (2,68 € chez Amazon ou 1,49 € sur iTunes)
• Combining Typefaces, de Tim Brown, 1,49 € (chez Amazon ou sur iTunes)
• Creating Symbol Fonts, de Brian Suda, 3 $ (2,68 € chez Amazon ou 1,49 € sur iTunes)
• CSS Animations, de Val Head, payez ce que vous voulez (2,68 € chez Amazon ou 1,49 € sur iTunes)
• CSS3 Layout Modules, de Rachel Andrew, 3 $ (2,68 € chez Amazon ou 1,49 € sur iTunes)
• Design Evolution, de Josh Long
• Experiments for Designers, de Colin McFarland (pas encore disponible)
• Front-end Style Guides, de Anna Debenham, 2 £ (1,49 € chez Amazon ou sur iTunes)
• HTML Email, de Andy Croll (2,68 € chez Amazon ou 1,49 € sur iTunes)
• International User Research, de Chui Chui Tan, 2,75 £ (2,68 € chez Amazon ou 1,49 € sur iTunes)
• Interviewing for Research, de Andrew Travers (2,68 € chez Amazon ou 1,49 € sur iTunes)
• Psychology for Designers, de Joe Leech, 2,75 £ (ou 1,49 € chez Amazon ou sur iTunes)
• The Craft of Words. Part One : Macrocopy, de The Standardistas (2,68 € chez Amazon ou 1,49 € sur iTunes)
• The Craft of Words. Part Two : Microcopy, de The Standardistas (2,68 € chez Amazon ou 1,49 € sur iTunes)
• Usability of Web Photos, de James Chudley (2,68 € chez Amazon et 1,49 € sur iTunes)
• Web Performance, de Andy Davies, 2,75 £

Practical Guides

• Designing for the Web, de Mark Boulton, gratuit (ou 4,99 € chez Amazon ou sur iTunes)
• Designing the Invisible, de Robert Mills
• Designing with Data, de Brian Suda, 25 $ (ou 7,21 € chez Amazon ou 4,99 € sur iTunes)
• Information Architecture, de Donna Spencer (7,21 € chez Amazon ou 4,99 € sur iTunes)
• Managing Web Projects, de Breandán Knowlton
• Web App Success, de Dan Zambonini, gratuit

Specials

• Hardboiled Web Design, de Andy Clarke, 12,90 €
• The Icon Handbook, de Jon Hicks, 10 £

Si vous repérez les quatre livres manquants, n’hésitez pas à me faire signe sur Twitter ou dans les commentaires.

Contrairement à d’autres webmails, la version classique d’Outlook.com ne se débrouille pas trop mal quand il s’agit de préfixer les règles CSS contenues dans un e-mail. Par défaut, toutes les règles CSS seront préfixées d’une classe .ExternalClass, et tous les noms de classes ou d’identifiants seront préfixés par ecx. Ainsi le code suivant :

.toto { background:red; }
.tutu { background:blue; }

@media only screen and (max-width:600px) {
	table[class="toto"] { background:white; }
	table[class="tutu"] { background:black; }
}

… sera transformé en…

.ExternalClass .ecxtoto { background:red; }
.ExternalClass .ecxtutu { background:blue; }

@media only screen and (max-width:600px) {
	.ExternalClass table[class="ecxtoto"] { background:white; }
	.ExternalClass table[class="ecxtutu"] { background:black; }
}

La classe .ExternalClass est alors judicieusement apposée sur une <div> contenant l’e-mail, et tout fonctionne comme si rien ne s’était passé. Jusqu’ici tout va bien, et on a presque envie de remercier les développeurs de chez Microsoft d’avoir fait correctement leur travail. Là où ça se gâte, c’est dans la version web mobile d’Outlook.com.

La version web mobile d’Outlook.com procède exactement au même renommage et préfixage des règles CSS que la version classique du webmail. Sauf que les développeurs ont oublié d’ajouter la classe .ExternalClass quelque part dans l’interface. Cela signifie que plus aucune de vos règles CSS n’est applicable. Si vous souhaitez optimiser des e-mails pour mobile pour Outlook.com, il est donc impératif de jouer uniquement avec des styles en ligne.

D’un coup, comme ça, on n’a plus tout à fait la même sympathie pour les développeurs de chez Microsoft.

Les statistiques des webmails et applications mail sont à prendre avec de très grosses pincettes. Quand vous tombez sur des infographies comme celle-ci ou celle-ci, il est important de comprendre comment ces données sont mesurées.

Pour mesurer son audience sur un site web, c’est facile. Il suffit d’installer un outil adéquat côté serveur (comme AWStats), ou d’utiliser un outil côté client (comme Google Analytics). Dans un e-mail, c’est plus compliqué car on ne peut ni accéder aux statistiques serveur de son fichier HTML une fois expédié, ni utiliser JavaScript. Ainsi, pour mesurer l’audience d’un e-mail, on va utiliser un mouchard, un fichier hébergé sur un serveur auquel on a accès, avec un ou plusieurs paramètres permettant d’enregistrer les informations qu’on souhaite obtenir.  La plupart du temps, on utilise simplement une image.

Le problème de cette méthode, c’est qu’on va comptabiliser uniquement les webmails et applications mail affichant les images (par défaut, ou après une action utilisateur). Facebook utilise  une balise <bgsound> en complément pour tenter d’atténuer le problème (notamment sur Outlook). Mais ce problème est particulièrement frappant quand on consulte des statistiques comme celles de Email Client Market Share, la petite page de données mises à jour par Litmus. Les trois versions d’Apple Mail, qui affiche par défaut les images, se retrouvent dans le top 5.

Et surtout, on remarque un bond spectaculaire dans l’utilisation de Gmail entre novembre 2013 (3,02 % de parts de marché) et janvier 2014 (9,5 % de parts de marché). L’explication est simple : en décembre 2013, Gmail a activé l’affichage des images par défaut.

En janvier 2014, le Journal du Net a publié un classement des webmails préférés des français (où par « préférés » ils voulaient surement dire « les plus utilisés »). On retrouve donc dans l’ordre le webmail d’Orange,  Outlook.com, Gmail, SFR, Yahoo (suivis de, non cités dans l’article original, La Poste et Free). Ces chiffres viennent d’une étude Médiamétrie réalisée en novembre 2013. Pour obtenir ces chiffres, Médiamétrie a réalisé ce qu’ils appellent une «mesure panel». Ils ont recrutés 22 000 panélistes représentatifs de la population française, leur ont fait installé un logiciel enregistrant leur navigation web, puis ils ont traités et redressés les données. Cette méthodologie peut laisser perplexe quand à sa fiabilité, mais même s’il ne faut pas prendre ces chiffres pour argent comptant, ça permet quand même d’avoir une petite idée du marché français.

Sur la version mobile du webmail de La Poste, il y a un bug important dans leur analyse des styles, et plus particulièrement des media queries. Peu importe le contenu de votre balise <style>, la première media query sera toujours supprimée. Et pire, les règles à l’intérieur de cette media query seront conservées, sauf la première qui elle sera totalement ignorée.

Concrètement, cela signifie que le code suivant…

.toto { background:red; }
.tutu { background:blue; }

@media only screen and (max-width:600px) {
	.toto { background:white; }
	.tutu { background:black; }
}

@media only screen and (min-width:320px) {
	.toto { color:white; }
	.tutu { color:black; }
}

… sera transformé par le webmail mobile de La Poste en :

.wrapper_h8ufTw .toto { background:red; }
.wrapper_h8ufTw .tutu { background:blue; }
.wrapper_h8ufTw .tutu { background:black; }
.wrapper_h8ufTw }

@media only screen and (min-width:320px) {
	.toto { color:white; }
	.wrapper_h8ufTw .tutu { color:black; }
.wrapper_h8ufTw }

Cela peut s’avérer très problématique, car on se retrouve avec des règles appliquées par défaut alors qu’elles devaient l’être uniquement dans une media query. (Vous apprécierez au passage le préfixage buggé évoqué précédemment.)

Pour éviter cela, on peut insérer une première media query, en prenant le soin d’ajouter quand même à l’intérieur une règle (sinon la media query sera ignorée, et le bug quand même présent). Attention, comme ce bug est bien spécifique au webmail de La Poste, cela signifie que cette media query sera interprétée par d’autres applications ou webmails. Il est donc impératif d’ajouter un code bidon qui n’aura pas d’impact sur les autres. On peut par exemple cibler un max-width:0.

En reprenant le code de l’exemple initial, on obtient alors le code suivant :

.toto { background:red; }
.tutu { background:blue; }

@media only screen and (max-width:0) { 
	body { margin:0; } 
} 

@media only screen and (max-width:600px) {
	.toto { background:white; }
	.tutu { background:black; }
}

@media only screen and (min-width:320px) {
	.toto { color:white; }
	.tutu { color:black; }
}

Le code final transformé par La Poste sera alors :

.wrapper_h8ufTw .toto { background:red; }
.wrapper_h8ufTw .tutu { background:blue; }

@media only screen and (max-width:600px) {
	.toto { background:white; }
	.wrapper_h8ufTw .tutu { background:black; }
.wrapper_h8ufTw }

@media only screen and (min-width:320px) {
	.toto { color:white; }
	.wrapper_h8ufTw .tutu { color:black; }
.wrapper_h8ufTw }