HTeuMeuLeu

Il y a deux semaines, bluetouff chez reflets.info a découvert que
SFR modifie le source HTML des pages que vous visitez en 3G. « Soit », me suis-je dit. Si la pratique est condamnable de la part d’un FAI, elle n’en reste pas moins assez proche de ce que peut faire un navigateur proxy comme Opera Mini ou bientôt Chrome sur Android.

Puis ce week-end, j’ai lu le guide sur l’intégration d’email marketing chez Mailchimp. Je suis resté scotché devant ce paragraphe (page 35 dans la version PDF) :

Si possible, testez vos e-mails lors de leur envoi avec différents FAI. Différents serveurs d’e-mails altérerons votre message avant qu’il n’arrive dans la boîte de réception de votre destinataire. Par exemple, certains FAI utilisent des serveurs d’e-mails qui retireront tout contenu sous une ligne dans votre e-mail qui commence par un point (on sait, c’est bizarre). Nous avons été surpris de voir à quel point un e-mail pouvait avoir un rendu différent sous Outlook 2003, mais reçu via Comcast, Bellsouth et Earthlink.

« Pfiou », me suis-je dit. J’ai bien de la chance de ne jamais avoir rencontré ce genre de problème.

Et puis c’est arrivé. Hier. Un e-mail, tout ce qu’il y a de plus classique, intégré par mes soins, livré dans les temps. Et une heure plus tard, un mail de retour du client. « Mon collègue a un rendu bizarre sur son téléphone », avec une capture d’écran de l’application Mail sous iOS, et effectivement un rendu étrange. Différentes images, censées être sur fond blanc avec du texte dessus, ont une couleur de fond différente.

« Impossible« , me suis-je dit. Je revérifie tout de mon côté. Mes tranches, mes images, mon code. Rien. Je regarde la capture d’écran qui prouve pourtant bien l’existence d’un problème. Et puis je m’arrête sur la barre de statut d’iOS, qui indique fièrement : « Orange 3G ».

« Non », me suis-je dit. Ça ne peut quand même pas être ça. Je teste alors sur mon iPhone, chez SFR, en 3G. Rien. J’envoie l’e-mail à tous mes collègues afin de tester sur différents appareils et différentes connexions. Et là, ça y est, miracle, le bug est apparu. Et effectivement, sur une connexion Orange, en 3G, les images sont dégradées.

J’ai donc fait ce que toute personne saine d’esprit ferait dans ce cas là : un tableau avec pleins d’images de différentes tonalités de gris dans différents formats (JPG à 100%, GIF, PNG 8 bits, et un simple background HTML comme témoin). J’ai testé, via la connexion partagée de mon collègue depuis son iPhone sur mon Macbook ou sur mon iPhone.

Et le résultat est sans appel.

Les trois formats d’images sont recompressés. Mais le GIF est recompressé de manière absolument horrible, à tel point que ça saute aux yeux. Même le blanc n’est plus blanc.

J’ai fait différents tests sur des images GIF, dans différents modes d’enregistrement, avec une palette de couleurs plus ou moins élevée, pour essayer de comprendre ce qui déclenchait cette recompression. Et je n’ai pas la réponse.

D’après mes tests, ça ne dépend pas :

• De la dimension des images. Certaines images plus grandes que d’autres n’ont pas eu d’effet visible lors de la recompression par Orange.
• Du poids des images. Certaines images de 3 Ko ont été sauvagement recompressées alors que pas d’autres de 8 Ko.
• De la palette de couleurs. Certaines images forcées à une palette de 16 couleurs sont encore recompressées de manière visibles. D’autres avec 32 couleurs, pas.

Je pense que le principal coupable est donc l’outil de compression GIF utilisé par Orange, et qu’il n’y a pas malheureusement pas grand chose à faire pour éviter ça. Le problème semble connu puisqu’il avait déjà été remonté dans un article de 2011.

Une solution consisterait alors à utiliser le format PNG (8 ou 24 bits) plutôt que du GIF. Sauf que malheureusement d’anciens logiciels mails, comme Lotus Notes 6 et 7, ne supportent pas du tout le format PNG et affichent des images cassées à la place.

Je n’ai pu faire des tests que chez SFR et Orange (Sosh). Mais si vous souhaitez savoir si votre opérateur compresse comme un sagouin les images à votre place, je vous invite à tester cette page et à partager vos captures d’écran dans les commentaires.

Sur le web, c’est à mon avis une mauvaise idée d’établir un lien entre le positionnement de son site, sa cible de communication, et des notions techniques de support en intégration. Bien souvent, ça sert d’excuse pour faire son travail d’intégrateur pauvrement. « Le site ne fonctionne pas sur Windows Phone, mais c’est ok, ce n’est pas notre cible. » Ou « Le site fait 3 Mo mais c’est ok, notre cible a une bonne connexion. »

Je pense que la cible du web est le mieux résumée par Tim Berners Lee (ici lors de la cérémonie d’ouverture des Jeux Olympiques de Londres en 2012).

Le web c’est pour tout le monde. Cela signifie qu’en tant qu’intégrateur, en tant que concepteur web, vous devez faire en sorte que votre site soit accessible au plus grand nombre. Bien sûr, c’est une vision idéaliste. C’est la cible à atteindre. Mais le contexte d’un projet et ses contraintes, comme par exemple le temps consacré à l’intégration, fait qu’on n’y arrivera pas toujours. Mais parfois, les modifications les plus simples peuvent avoir des conséquences inattendues.

En décembre dernier, Chris Zacharias racontait une anecdote comme je les aime sur son travail d’optimisation sur Youtube.

Il y a trois ans, quand j’étais développeur web chez Youtube, l’un des ingénieurs séniors a commencé à se plaindre du poids trop élevé de la page de lecture d’une vidéo. La page gonflait jusqu’à 1,2 Mo et des douzaines de requêtes. Cet ingénieur s’exclamait ouvertement « Si ils peuvent écrire un clone complet de Quake en moins de 100 Ko, on n’a aucune excuse pour ça ! ». Étant donné que j’étais d’accord avec lui et que j’étais content de trouver un nouveau projet, j’ai décidé de défendre cette cause et de faire passer la page de lecture de vidéo à moins de 100 Ko. Dans la navette pour chez moi ce soir là, j’ai codé un prototype. J’ai décidé de limiter les fonctionnalités à un header basique, le lecteur vidéo, cinq vidéos associées, un bouton de partage, un bouton de favoris, et dix commentaires chargés en AJAX. J’ai appelé ce projet « Feather« .

Même avec aussi peu de fonctionnalités, la page pesait déjà 250 Ko. J’ai creusé dans le code et j’ai réalisé que nos outils d’optimisation (comme Closure compiler) étaient incapables d’exclure du code qui n’était pas utilisé dans la page elle-même (ce qui serait une attente injuste pour un tel outil dans ces circonstances). Le seul moyen de réduire le code encore plus était d’optimiser à la main les CSS, JavaScript et sprites d’images. Après trois jours pénibles, je suis parvenu à une solution bien plus maigre. Mais je n’étais toujours pas sous les 100 Ko. Alors qu’on venait de finir d’écrire le lecteur vidéo en HTML5, j’ai décidé de l’utiliser plutôt que le lecteur bien plus lourd en Flash. Bam ! 98 Ko et seulement 14 requêtes. J’ai parsemé le code de contrôles de surveillance basiques, et j’ai lancé cette version pour une fraction de notre trafic.

Après une semaine de collecte de données, les chiffres nous sont parvenus… Et ils étaient déconcertants. La moyenne totale de la latence de la page sous Feather avait augmenté. J’avais diminué le poids de la page et le nombre de requêtes à un dixième de ce qu’il y avait avant, et d’une manière ou d’une autre, les chiffres montraient que les vidéos mettaient plus longtemps à se charger sous Feather. Ce n’était pas possible. En creusant dans les chiffres un peu plus et après de nombreux tests répétés, ça n’avait aucun sens. J’allais abandonner le projet, ma vision du monde totalement brisée, quand mon collègue a découvert la réponse : la géographie.

Quand nous avons visualisé les données géographiquement et les avons comparé par région, il y avait une augmentation disproportionnée du trafic d’endroits l’Asie du Sud, l’Amérique du Sud, l’Afrique et même des régions isolées de Sibérie. Et quelques enquêtes supplémentaires ont révélé que, dans ces endroits, le temps moyen de chargement d’une page sous Feather était de plus de deux minutes ! Cela signifiait qu’une page classique de vidéo, à plus d’un méga-octet, prenait plus de vingt minutes pour se charger ! C’était la sanction infligée avant même que le flux vidéo n’ait la chance d’afficher la première image. En conséquence, des populations entières ne pouvaient simplement pas utiliser Youtube car c’était trop long pour voir quoi que ce soit. Avec Feather, même s’il fallait plus de deux minutes pour afficher la première image d’une vidéo, regarder une vidéo était devenu une vraie possibilité. En une semaine, l’existence de Feather s’est propagé dans ces zones géographiques et nos chiffres ont été complètement faussés en conséquence. De nombreuses personnes qui ne pouvaient pas utiliser Youtube auparavant en avaient soudainement la possibilité.

Grâce à Feather, j’ai appris une leçon précieuse sur l’état du web à travers le reste du monde. Nombre d’entre nous avons la chance de vivre dans des régions avec un bon débit, mais il y a encore de larges portions du monde pour qui ce n’est pas le cas. En gardant notre code client petit et léger, vous pouvez littéralement ouvrir votre produit à de nouveaux marchés.

Si vous bloquez activement l’accès à votre site sur mobile ou pour des vieilles versions de navigateur, ou si votre page fait plus de 5 Mo, vous risquez effectivement de vous rendre compte que votre audience n’utilise pas de mobile et a une bonne connexion. Mais ça ne signifie pas que c’est le cas de votre cible.

Cette semaine, j’ai lu deux articles qui m’ont rappelé que malgré les louanges qu’on peut faire à l’ergonomie d’un iPhone, ça reste un appareil compliqué à utiliser.

D’abord il y a eu cet article « d’utilisabilité de couloir » de Jonathan Rentzsch, « Ma mère essaye un iPhone » :

Je lui ai demandé d’appuyer sur l’icône de Mail. Encore une fois, elle s’est retrouvée bloquée à cause de ses mouvements réfléchis, et elle a accidentellement déclenché le mode de réarrangement des icônes. Les Apps ne voulaient plus se lancer et elle n’a aucune idée de comment réparer ça. […]

Comme beaucoup de gens (la plupart ?), elle ne comprend pas ce qu’est une URL. Donc je suis allé sur Google pour elle, et je me suis dépatouillé pour naviguer sur Google News (google.com le cache désormais sous leur bouton hamburger). Elle utilise Google News sur son Mac, donc je voulais lui montrer que les mêmes informations sont disponibles sur l’iPhone. Je voulais qu’elle voit quelque chose qui lui soit familier.

Elle a immédiatement été contrariée en tapant sur le lien d’un titre qui a ouvert la page dans un nouvel onglet. Sa page de Google News a été mise au second plan et la page du Los Angeles Times est apparue au premier plan. Comme il s’agissait d’une nouvelle page, le bouton précédent n’était pas activé. Elle était perdue pour revenir en arrière, ne remarquant pas le bouton méconnaissable des onglets qui détenait la clé de son retour.

Et puis il y a eu cet excellent article chez Sam et Max, Il ne faut pas prendre des gens pour des cons mais ne jamais oublier qu’ils en sont :

Il y a 5 ans, on prenait les interfaces Apple comme modèle de simplicité. Et c’est toujours vrai. Sauf que maintenant ça ne suffit plus : il existe une bonne part des utilisateurs d’iPhone qui ne savent pas :

• Faire autre chose que Tel + SMS + Facebook.
• Installer une app.
• Copier / coller.
• Savoir où ils sont (sur une app native, externe au téléphone, sur un site internet…). En fait ils ne savent pas ce qu’est une app.

Pour toutes ces actions, ces gens demandent à quelqu’un d’autre de les aider. C’est comme ça que fonctionne l’humanité : je ne sais pas réparer ma voiture, je demande à un garagiste. Sauf que la voiture a mis près d’un siècle à s’installer dans les foyers, traversant lentement les couches sociales.

Internet s’est imposé partout, et à tout le monde, en 30 ans.

J’ai réalisé que l’iPhone était un appareil compliqué à utiliser en configurant mon iPhone 5 pour la première fois en novembre dernier. J’avais le souvenir d’une étape super simple lorsque j’avais configuré mon iPhone 3GS pour la première fois trois ans plus tôt. Pénible, certes, car il fallait à l’époque obligatoirement brancher son iPhone à un ordinateur avec iTunes installé. Mais de mémoire, c’était simple. Là, j’ai dû passer au travers de nombreux écrans de configuration pour tous les services d’Apple apparus entre 2008 et 2012.

« Souhaitez-vous activer les services de localisation ? » Euh, j’en sais rien, je suppose. Pourquoi ne pas le faire ? « Souhaitez-vous activer iCloud ? » Bah, j’imagine, oui, vu que c’est l’un des principaux services mis en avant par Apple. « Souhaitez-vous activer ‘localiser mon iPhone’ ? » Un service pour localiser mon iPhone en cas de perte ou de vol, ça a l’air bien ! Pourquoi je ne l’activerais pas ? Quelle est la contre-partie ? Pourquoi quelqu’un répondrais non ? « Souhaitez-vous activer Siri ? » Alors là vous plaisantez ! C’est la fonctionnalité de l’iPhone mise en avant dans toutes les pubs depuis l’iPhone 4S, et vous me demandez si je veux l’activer ?

Je me suis senti submergé par toutes ces questions auxquelles je n’avais qu’une seule et même réponse : « je m’en fiche, laissez-moi utiliser mon putain de téléphone ». Je n’ose pas imaginer le ressenti d’un utilisateur lambda.

L’une des tâches les plus difficiles de la conception web est de convaincre vos interlocuteurs de changer, même si vos préconisations sont les plus nobles au monde. C’est en particulier vrai à mon avis dès que ça touche à des domaines non visuels et dont les avantages d’un changement sont plus difficilement mesurables : intégration, développement, accessibilité, référencement… Parfois cette aversion au changement est seulement suggérée, parfois elle est clairement prononcée à voix haute.

Et si on remplaçait nos boutons J’aime par des liens de partage et que ça n’augmentait pas l’engagement sur les réseaux sociaux ? Et si on rendait notre site accessible sur mobile mais qu’il n’était pas vraiment optimisé ? Et si on laissait afficher notre page se charger mais que ça faisait moins joli ? Et si on inversait ces flèches pour imbéciles mais que ça n’augmentait pas nos conversions ?

Tout cela me rappelle cette caricature de Joel Pett parue dans le journal USA Today en 2009.

Cette nuit, Google a annoncé la fermeture de Google Reader à partir du 1er juillet prochain, dans le cadre d’un « nettoyage de printemps ». Je me fichais pas mal des fermetures des précédents services de Google (Buzz, Video, iGoogle). Mais là, ça me fait tout drôle. Google Reader est un service que j’utilise, et surtout que j’aime utiliser, chaque jour depuis 2006. Je ne doute pas que j’arriverais à retrouver rapidement une alternative.

Mais cette annonce est pour moi assez représentative du Google de 2013.
Froide, sèche, sans appel.

Dans mon esprit, Google Reader fait figure des symboles du Google innovant du milieu des années 2000. Google Maps, Google Docs, Gmail… Bien sûr, ces services avaient pour unique but de rassembler davantage de données sur leurs utilisateurs. Mais ces services répondaient à un besoin.

2013. Le gros projet de l’année pour Google est Google Glass. Des lunettes connectées qui permettront à Google de vous suivre partout, 24 heures sur 24, et d’enregistrer tout ce que vous voyez, tout ce que vous dites, tout ce que vous faites. Pour quel gain pour l’utilisateur ? La possibilité d’avoir les mains libres en prenant une photo. Mon côté geek aimerait être emballé, mais j’ai vraiment du mal.

En 2011, dans une célèbre interview, Eric Schmidt expliquait que le but de Google est « de se rapprocher de la limite du glauque, mais sans jamais la dépasser« . Je ne saurais pas dire exactement quand c’est arrivé (peut-être avec Chrome, peut-être avec Android), mais j’ai le sentiment que Google est bien au-delà de cette limite. Google Glass, Google Shoes, Google Cars… Ces services hurlent : « Comment peut-on récupérer plus d’informations sur des êtres humains à leur insu ? ».

Ce n’est pas forcément nouveau chez Google, mais désormais ça me saute aux yeux.