Un exemple d’infographie vide de sens

Ce midi je suis tombé sur cette infographie dans l’édition du jour du 20 minutes :

Les loyers des étudiants

Je suis bien resté cinq minutes à chercher le sens et l’intérêt de cette infographie, et surtout quelle information j’étais censé en retirer. Et je n’ai pas trouvé de réponse. Sébastien Desbenoit appelle ça une VIDANJ : « Visualisation de Données Accompagnant un Néant Journalistique. » J’aime bien cet acronyme.

Mais surtout j’adore cette infographie. Mais pas dans le bon sens du terme. Voici quelques points que j’ai relevé :

  • La représentation sous forme de carte géographique laisse penser qu’on chercher ici à comparer les prix des loyers entre les différentes villes. Sauf qu’on ne compare pas toujours les mêmes surfaces, ce qui rend la lecture vraiment compliquée. 
  • Chaque ville est représentée par deux barres représentant un loyer minimum et loyer maximum. Mais les surfaces choisies pour la comparaison sont bien étrange. À Lille, on compare un 30 m² et un 35 m². Il n’y a vraiment pas de plus petit loyer qu’un 30 m² ni plus grand qu’un 35 m² à Lille ?
  • Les sommes inscrites sur la carte semblent toutes avoir été arrondies, sauf le loyer maximum à Strasbourg qui est de 583 €. Ces trois euros ont-il une importance ? Ou alors c’est vraiment un coup de bol que toutes les autres moyennes tombaient juste à la dizaine ?

Tout ça m’a fait repensé à une conférence que j’avais adoré, d’Irene Ros à la Take Off Conference à Lille en janvier dernier : Responsible use of data visualization. Et en particulier cet exemple (à 18 min) :

Comparaison du chiffre d'affaires et des dépenses publicitaires entre Coca-Cola et Pepsi Cola

Un autre exemple rigolo, c’est de mal représenter des données. Tout le monde aime les infographies. Mais ici c’est un peu une véritable boucherie d’infographie.

Ils comparent le chiffre d’affaire annuel et les dépenses publicitaires entre Coca-Cola et Pepsi Cola. Et ils utilisent des camemberts pour ça. Il n’y a aucune raison à ça. Ça veut dire quoi 35,2 milliards de dollars… d’une capsule ? Et il n’y a aucune relation entre la taille des deux données comparées. Remarquez comme les 1,1 milliards de dollars sont plus gros que les 35,2 milliards de dollars. Et je ne suis pas sûr s’il faut que je regarde l’espace vide ou alors l’espace plein.

Ce qu’ils auraient dû faire, c’est plutôt ça.

Non seulement maintenant vous pouvez vraiment comparer visuellement les deux sociétés. Mais vous pouvez aussi comparer les deux catégories. C’est probablement plus important que de voir une capsule en 3D.

Le feriez-vous dans la vraie vie ?

Hier, j’ai vu chez Badsender cet exemple édifiant de newsletter :

Un titre de presse avec la même « Une » chaque jour ! Ok ou Ko ?

Chaque jour, l’objet de la newsletter envoyée par Libération est invariablement le même : « Le point de l’actualité du + DATE + au matin ».

Pourquoi ce qui est impensable avec la version papier du quotidien devient possible avec l’email ? Pourtant, la newsletter de Libération génère probablement un traffic considérable sur son site internet. Un traffic indispensable à la monétisation digitale du quotidien. Alors pourquoi ne pas optimiser ? Pourquoi cette paresse ?

C’est complètement fou. Le premier contact que n’importe quel abonné aura avec cette newsletter, la première information qui sera lue, chaque matin, sera totalement dénuée d’intérêt. (C’est aussi utile qu’un fichier appelé « style.css« .) Jamais un grand quotidien national n’irait occuper la plus grande partie de sa une avec la date du jour dans « la vraie vie ».

C’est le genre de pratique qui me rend fou, un peu comme les popups bloquantes à l’arrivée sur un site vous demandant vos coordonnées, un like ou un ticket restaurant, à votre bon coeur. Jamais un commerçant dans « la vraie vie » n’irait vous demander vos coordonnées dès votre entrée dans sa boutique. Il y a un temps pour tout.

Cela me rappelle certains exemples donnés par Charles de UXUI dans son article sur 24 jours de web, « Les concepteurs de sites internet ne sont pas (tous) des utilisateurs comme les autres » :

Une bannière publicitaire pour la gendarmerie sur le site de La Redoute ? Le concepteur salue un placement ambitieux, l’utilisateur se demande s’il existe un rapport entre le manteau qu’il venait chercher et ce gendarme qui lui sourit (et qui ne porte même pas de manteau.)

Les gendarmes à St Tropez... Ah non, La Redoute.

Vous imaginez rentrer dans une boutique de prêt à porter dans « la vraie vie » et être accueilli par une escouade de gendarmerie, présente pour recruter ? Ce serait fou.

Et je ne parle même pas des sites qui bloquent activement leurs utilisateurs sur des critères purement physiques, brillamment recensés sur WTF Mobile Web :

WTF Mobile Web

Feeling emasculated.
Come back when you have a bigger screen.

Vous imaginez rentrer quelque part dans « la vraie vie » et vous faire gentiment éjecter parce que vous êtes trop petit, trop grand, pas « bien comme il faut » ? Non merci.

Google avait magnifiquement illustré tout ça dans cette vidéo il y a deux ans :

Google Analytics In Real Life - Online Checkout

En plus de respecter la loi des titres de Betteridge, « Le feriez-vous dans la vraie vie ? » est une bonne question à se poser lors de la conception d’un site web. Parce qu’au cas où il serait nécessaire de le rappeler : le web, c’est aussi « la vraie vie ».

Bonne chance, Firefox OS

Hier, Mozilla a annoncé la sortie officielle de Firefox OS ainsi que les premiers smartphones officiels à destination du grand public. Le ZTE Open est disponible dès aujourd’hui en Espagne chez Telefónica pour 69€. Le Alcatel One Touch Fire sera dévoilé plus en détail le 11 juillet en Pologne chez Deutsche Telecom.

C’est un grand événement pour Mozilla, et peut-être pour l’avenir du web tout entier. Et pourtant, j’ai toujours du mal à croire en Firefox OS. Il y a à mon avis deux façons de voir Firefox OS.

Il y a quelques mois, je parlais de Firefox OS autour de la citation « Vous pouvez mourir en héros ou vivre suffisamment longtemps pour vous voir devenir le méchant ». Les choses ne se sont pas améliorées depuis, et Firefox OS ressemble de plus en plus aux méchants Apple et Google que certains membres de Mozilla se délectent de critiquer. Pour lancer Firefox OS, Mozilla s’est associé à Foxconn, cette usine « d’animaux » et d’enfants, comme Apple et Google. Sur le marketplace de Firefox OS, les applications web sont soumises à validation, comme sur l’App Store ou Google Play. Et puisqu’il est basé entièrement sur des applications web tournant sur le moteur de rendu Gecko de Mozilla, Firefox OS interdit de facto à tout autre fabricant de navigateur de s’installer sur son système. De la part de Mozilla qui a lutté des années contre le monopole de Microsoft, ça fait tâche.

J’entends aussi souvent répété l’argument de l’ouverture de Firefox OS qui suffirait à assurer le succès du système, comme ça a été le cas pour Firefox. Selon moi, si Firefox a été un succès, c’est parce que c’était un bon produit. De ce que j’ai pu voir jusqu’à présent de Firefox OS, ou essayer via le simulateur ou le Geeksphone Peak acheté au boulot, Firefox OS n’est pas (encore) un bon produit. Le fait que l’application Mail n’arrive pas (encore) à afficher correctement un mail HTML n’y est peut-être pas pour rien. (Pour un OS dont le point fort est censé être son moteur de rendu web, ça fait un peu tâche quand même.)

Mais ce n’est surement pas la bonne façon de voir Firefox OS. Comme le rappelait hier Christian Heilmann (développeur évangéliste chez Mozilla), l’objectif de Mozilla est aussi de proposer un accès au web à des marchés émergents. Et c’est là où je commence à reprendre foi en Firefox OS. Il y a aujourd’hui 2,5 milliards de personnes ayant accès à Internet. Ça signifie qu’il y a encore 4,5 milliards de personnes à inviter à nous rejoindre. En octobre dernier, la CNN titrait « L’Afrique n’est pas juste un continent mobile-first, c’est mobile-only » :

Il y a plus de gens en Afrique qui ont un téléphone mobile que de gens ayant accès à l’électricité.

La perspective que Mozilla arrive à s’imposer dans ces pays, offrant un accès au web à encore plus de monde me semble bien plus excitante que toute autre paluchage devant des spécifications techniques ou des technologies web en cours de standardisation. Et c’est pour ça que même si j’ai du mal à croire en Firefox OS, j’espère de tout coeur que Mozilla réussira sa mission.

Alors bienvenue au monde et bonne chance, Firefox OS.

L’importance d’un intégrateur

La semaine dernière, j’ai lu l’avis de Nicolas Hoffmann sur le livre Projet Responsive Web Design sorti récemment chez Eyrolles. J’ai beaucoup aimé :

Ce livre confirme une fois de plus ce que je constate (et je ne suis pas le seul) depuis plusieurs années : l’intégrateur (ou le développeur front-end) devient une pièce majeure de l’équipe Web. J’avais déjà écrit « de l’intégrateur au développeur front-end… » sur OpenWeb, ce livre appuie et explique très bien cet état de fait, à travers le Responsive Web Design donc.

Pas plus tard que ce matin, je travaillais à l’intégration sur un projet en Responsive Web Design, et je peux vous assurer que la personne vers qui tous les acteurs se tournent durant ces projets, c’est l’intégrateur et pas un autre. Le rôle est vraiment central.

Aujourd’hui, sur le blog de DarkLg, Pourquoi un (bon) intégrateur est indispensable à tout projet web :

Voici quelques raisons pour lesquelles je pense qu’un bon intégrateur est indispensable à tout projet web :

  • Il est souvent le premier technicien sur le site, et est donc le premier à constater des erreurs de conception, ou des éléments qui ne pourront pas être administrables.
  • Il fera la différence entre une erreur de DA et une subtilité à mettre en place.
  • Il saura optimiser les performances Front-End de vos sites.

J’aime beaucoup ces deux articles. Alors oui, les intégrateurs parlent aux intégrateurs, et nos avis sont forcément un peu biaisés. Mais ces discours sur l’importance et l’indispensabilité de l’intégrateur (et intégratrice) me parlent beaucoup.

Ces derniers mois, j’ai travaillé sur la refonte de l’espace client d’une marque. J’ai travaillé principalement avec les développeurs, les directeurs et chefs de projet techniques, mais aussi de manière plus ou moins directement avec les responsables marketing et communication. C’est une « petite » équipe d’une vingtaine de personnes, qui travaille sur des projets web depuis des années. Et pourtant, avant ce projet, ils n’avaient jamais travaillé avec des intégrateurs. Jamais jamais. Auparavant, les développeurs s’occupaient tant bien que mal de bidouiller du HTML et du CSS pour arriver à quelque chose d’à peu près ressemblant aux maquettes. Ça peut paraître totalement fou quand on travaille en agence, où le métier d’ intégrateur est plutôt bien rentré dans les mœurs. Mais ce n’est pourtant pas la première fois ces dernières années que j’ai eu l’occasion d’évangéliser le rôle de l’intégrateur auprès de grandes marques, aux processus très lourds et bien rodés. Et à chaque fois, ça a été la même réaction : une bouffée d’air frais. Finis les aller-retours incessants avec les équipes créa pour changer un s sur une maquette. Finies les journées entières perdues par les développeurs à essayer de comprendre les méandres d’Internet Explorer.

Mais cela semble évident. Un bon intégrateur fera du bon boulot en intégration, tout comme un bon référenceur fera du bon boulot en référencement, ou un bon webdesigner fera du bon boulot en coloriage.

Mais ce qui est important, et qui me semble encore assez nouveau dans les mentalités, c’est qu’un bon intégrateur joue un rôle crucial dans la qualité globale d’un projet web, en pouvant apporter des conseils avisés sur toutes les facettes d’un projet, dès sa conception.

L’intégration, ce n’est pas l’exécution du webdesign. Et si vous vous trouvez dans une salle de réunion pour un projet web sans aucun intégrateur, vous êtes sur la mauvaise voie.

Indice visuel

Hier matin, j’ai eu la surprise en arrivant au boulot de suivre un véhicule roulant à contre-sens. Ce n’est pas la première fois que ça m’arrive à cet endroit précis. Je me suis même déjà retrouvé nez à nez devant un véhicule roulant à contre-sens (je l’ai joué à la dégonfle au volant de ma Twingo, le conducteur en face a tout de suite vu à qui il avait affaire). Voici la rue en question, suite à des récents travaux.

Ne vous fiez pas au ciel bleu, ça reste dans le Nord

Il s’agit à la base d’une route à quatre voies, dont deux réservées aux bus. Puis il y a un passage piéton et une intersection avec des pavés. Puis la route est réduite à trois voies, avec plus qu’une seule voie de bus. Puis la route est à nouveau réduite à deux voies. Voici un plan reconstitué par mes soins.

A chaque fois, le problème s’est passé au passage de l’intersection, du point A au point B sur mon illustration. Plutôt que de continuer tout droit, le véhicule au point A se décale d’une voie pour se retrouver alors au point B, à contre-sens. Le marquage au sol est pourtant assez clair

J’ai moi-même eu un moment d’hésitation la première fois que j’ai emprunté cette nouvelle route. Et je pense que ces erreurs sont facilitées par trois indices visuels :

  1. Les pavés de l’intersection créent une discontinuité du marquage au sol, ce qui permet de vite s’y perdre.
  2. Il y a un arrêt de bus situé juste après l’intersection et le changement de voie. Le marquage au sol de l’arrêt de bus est fort, et peut laisser croire qu’il s’agit encore de la voie de bus présente auparavant.
  3. Lorsqu’on est à contre-sens (au point B), on est pile en face de la route sur laquelle on se trouvera quelques dizaines de mètres plus loin après le dernier rétrécissement de voies (au point C). Du coup, si on voit un véhicule au loin, on est tenté de croire qu’on est sur la bonne voie.

Pour éviter ça, je pense qu’un simple panneau indiquant le nombre et le sens des voies suffirait (même si du coup ça fait un peu porte de Norman et que ça ne résout pas vraiment le problème de base de cette route).

Cette petite tranche de vie m’a rappelé un article vu le mois dernier sur Twitter, « Opodo : le bouton qui fâche« , rapportant un test utilisateur :

Lors de ce test nous avons demandé aux participants de réserver le voyage de leur choix. Vous allez voir dans la vidéo ci-dessous une utilisatrice qui filtre les résultats en utilisant certains critères (destination, durée, budget…) mais une action inattendue se produit :

Opodo : le bouton qui fâche

Après avoir cliqué sur le bouton « Supprimer tous les critères » (00:35) l’utilisatrice ne comprend pas pourquoi ses choix se sont effacés. Le libellé du bouton est pourtant clair, alors pourquoi cette erreur ?

Dans cet exemple, comme dans mon exemple de contre-sens, il s’agit d’une erreur particulièrement grossière. Et pourtant, si elle se produit, ce n’est pas parce que les gens sont particulièrement idiots, mais bien parce qu’il y a un problème de design.

Répétition

Le langage HTML.

L’optimisation pour le SEO.

Le protocole HTTP.

Une feuille de styles CSS.

Le format PDF.

Le format GIF.

Le format TIFF.

Le référentiel RGAA.

Je n’aime pas beaucoup me répéter. Alors à chaque fois que j’emploie une des expressions ci-dessus, je grince un peu des dents. (Et c’est pire en anglais.)

L’après Photoshop

Il y a eu un sacré paquet d’articles sur l’utilisation de Photoshop pour le web ces derniers mois. À l’heure où l’on est supposé épouser une diversité incroyable d’appareils, je suis convaincu que le design sous Photoshop n’a plus vraiment sa place.

Je crois que les discussions ont commencé suite à cet excellent article de Brad Frost en janvier dernier sur « L’ère post-PSD » :

Tout au long de ma carrière, j’ai vu des graphistes immensément talentueux perdre une montagne de temps à créer des maquettes complètes de ce à quoi un site web pouvait ressembler. On pousse des pixels, on sue sur des détails, les pages sont imprimées, accrochées sur des murs, et présentées à des clients. Les clients braillent leurs retours, les graphistes exécutent. Ils répètent cette danse jusqu’à ce que tout le monde soit content (ou jusqu’à ce que personne n’en ait plus rien à faire, ce qui arrive plus souvent que vous ne le croiriez). Et seulement à ce moment ces sacro-saintes maquettes sont transmises (ou plutôt balancées) aux développeurs pour les construire.

C’est un processus de plus en plus pathétique qui a de moins en moins de sens dans ce monde et cette époque multi-appareils. Je ne plaide pas pour abandonner complètement Photoshop et faire du design uniquement dans le navigateur (ils sont où déjà les modes de fusion dans les outils de développement de Chrome ?) mais plutôt pour une meilleure compréhension de comment utiliser Photoshop pour du web design moderne.

Je pense que « pathétique » est le bon mot. On vient de passer les vingt dernières années à tenter de faire du print sur le web. Il est temps que ça change.

Afin de palier aux faiblesses techniques de Photoshop, certains prêchent l’utilisation d’autres logiciels, comme Sketch par exemple. C’est déjà un bon premier pas pour s’éloigner du Bitmap de Photoshop vers du vectoriel, plus proche de la nature du web. Mais à chaque fois, la réaction d’une partie de la petite communauté de Directeurs Artistiques sur Twitter est la même : « Comment osez-vous nous imposer un logiciel pour faire du design ? Nous on ne vient pas vous dire dans quel logiciel travailler. » C’est touchant, mais c’est pourtant exactement ce qui se passe.

En travaillant sous Photoshop, vous imposez à toute votre chaîne de production d’en faire autant. Parce que le format PSD est une véritable abomination, Adobe s’assure à chaque mise à jour qu’il reste inutilisable de manière fiable sous tout autre logiciel (coucou les dossiers de calques qui sautent dans Pixelmator ou Gimp). Photoshop est aussi un outil particulièrement atroce à utiliser pour de l’intégration. Certains plugins comme CSS Hat ou Slicy (anciennement Layer Cake) tentent de rendre la tâche moins pénible, on est encore loin d’un véritable outil pensé pour de l’intégration. Et même si des logiciels comme Sketch améliorent cette situation, je ne suis pas sûr que remplacer Photoshop par un autre logiciel propriétaire ne soit la solution.

J’aime bien la vision de Ryan Singer abordée lors d’une séance Play by Play sur le prototypage d’interface : « Photoshop est juste un outil — de la même manière qu’un croquis — pour retirer le doute sur une idée. »

Que ce soit pour de l’intégration ou du design, j’utilise Photoshop ou Pixelmator comme si j’étais dans une épreuve de Fort Boyard : une fois rentré, mon but est d’en sortir le plus rapidement possible avec la réponse à ce que je suis venu chercher.

Il y a quelques années on faisait des sites complets en Flash. Aujourd’hui on maquette encore des sites complets sous Photoshop. Il est temps que ça change. Comme dans le cas des pré-processeurs, je pense que le problème n’est pas l’outil qu’on utilise, mais ce qu’on en fait. L’après Photoshop n’arrivera qu’une fois qu’on se sera débarrassé de cette vision print du web.

« Arrêtez de dessiner des poissons morts »

Je regarde beaucoup de conférences, et il y a des tas de gens que j’admire vraiment. Et puis il y a Bret Victor. Comme le disait Irene Ros à TakeOffConf à Lille en janvier dernier, « aucune conférence ne devrait se passer sans citer Bret Victor ». J’avais été bluffé par sa conférence « Inventing on principle » l’année dernière. Cette semaine, une nouvelle vidéo d’une de ses conférences au SIGGRAPH de San Francisco en mai 2012 a été mise en ligne : « Arrêtez de dessiner des poissons morts ».

This is not a fish

Ceci est ce que Magritte appelle « la trahison des images ». Ceci n’est pas un poisson. C’est une image d’un poisson. C’est une représentation visuelle d’un poisson. Si j’avais dessiné ça sur papier, ce serait une plutôt bonne représentation d’un poisson. Si vous ouvriez un livre que vous tombiez sur ce dessin, vous vous diriez « oui, il y a une image d’un poisson dans mon livre ». Ça capture toute la « poissonitude » que l’on peut capturer à travers un media papier. Mais ceci n’est pas du papier, c’est un nouveau média. Et dans ce média, c’est une très mauvaise représentation d’un poisson. Ça ne ressemble pas du tout à un poisson.

Les poissons sont tout le temps en train de bouger. Si vous regardez un poisson, il fera surement des aller-retour, il bougera son corps d’avant en arrière, remuant sa queue. Les poissons sont tout le temps en mouvement. Dans un média où nous nous attendons à voir du mouvement là où il y a du mouvement, ceci ne ressemble pas du tout à un poisson vivant. C’est une bonne image pour un poisson mort. Et si vous voulez dessiner un poisson mort, Photoshop est un super outil. Tout ce que vous allez dessiner dans Photoshop sera complètement mort, totalement statique, pas du tout en mouvement.

Mais je ne veux pas dessiner un poisson mort, je veux dessiner un poisson vivant.

Le parallèle avec le web n’est pas trop difficile à faire. Et c’est ainsi qu’il commence à animer son poisson sur son interface faite-maison avec deux iPad reliés en Bluetooth. Les différents concepts d’interface qu’il présente font vraiment toujours autant envie. Surtout, il argumente avec précision pourquoi, d’après lui, taper du code n’est pas adapté pour faire de l’animation.

La deuxième raison pour laquelle je pense que coder est inapproprié pour créer des arts graphiques vient de la relation entre un langage et la compréhension visuelle. Du code, c’est du langage. Nous codons dans des langages de programmation. Nous pensons de manière linguistique lorsque nous codons.

Dans une large mesure, la seule raison pour laquelle des artistes créent des arts graphiques est pour exprimer quelque chose qu’ils ne peuvent pas exprimer avec un langage. Les artistes dessinent parce qu’ils veulent transmettre quelque chose qu’ils ne peuvent pas décrire. Les mots « nuit étoilée » ne décrivent pas « La nuit étoilée« .

Si je suis un fervent défenseur de la conception web la plus proche possible d’un navigateur, je suis tout à fait d’accord que du code n’est pas le bon outil pour de la création graphique. Nous sommes dans un état d’esprit différent lorsque nous codons et lorsque nous sommes devant une toile vide sous Photoshop.

Sa conclusion est précise et ambitieuse :

La principale chose que je veux que vous retiriez de cette conférence, c’est de l’insatisfaction.

Je veux que vous rentriez chez vous, que vous ouvriez Photoshop et que vous ressentiez que vous dessinez des poissons morts. Je veux que vous ressentiez à quel point tout ce que vous dessinez est plat, statique et sans vie. Quand vous créez des animations, je veux que vous ressentiez à quel point c’est froid et mort, comment vous ne pouvez pas jouer avec. Je veux que vous ressentiez tout ce qui nous manque, en utilisant ce média pour simuler d’autres médias. En définitive, je veux que vous ayez des standards plus élevés pour ce média.

Je ne peux qu’acquiescer.

L’expérience d’un premier achat

Il y a un an et demi, j’ai acheté ma première voiture. Je n’avais jamais eu besoin d’un véhicule auparavant. J’habitais sur Lille et les transports en commun me permettaient de me rendre à mon travail et d’être indépendant 95 % du temps. Et puis j’ai déménagé à 50 Km de mon lieu de travail. À moi les joies du TER, de ses retards quotidiens, de ses grèves trimestrielles et de l’angoisse constante d’arriver en retard le matin et de ne pas pouvoir rentrer chez moi le soir. Alors j’ai décidé d’acheter une voiture.

Le problème, c’est que j’y connais rien en automobile. J’écoutais attentivement les conseils de mon entourage, mais chacun y allait de sa propre expérience se contre-disant les unes des autres. « Avec les kilomètres que tu vas faire, il te faut un diesel ! » « Prends plutôt une essence, c’est moins cher et de toute façon le carburant est quasiment au même prix. » « Achète français, ça coûte moins cher à l’entretien. » « Achète japonais, ils font les meilleurs moteurs et ça demande moins d’entretien. »

Je n’avais pas la moindre idée de ce qui pouvait être important d’avoir dans une voiture, mais j’avais quelques contraintes. Je souhaitais un véhicule pour une utilisation occasionnelle, environ une fois par semaine. Je n’avais pas de budget précis en tête, mais je souhaitais pouvoir payer cash, sans faire de prêt. J’en avais aussi besoin assez rapidement, mais je n’avais pas beaucoup de temps à y consacrer. Et surtout, je devais pouvoir me rendre facilement seul chez le concessionnaire de la voiture de mes rêves. C’est bête, mais quand on n’a pas de voiture, c’est tout de suite très compliqué de se rendre chez des concessionnaires placés à l’extérieur des agglomérations.

Alors j’ai acheté ce petit bolide.

Twingo

Oui, une Twingo. Je peux désormais me vanter d’avoir une voiture de ministre.

Au début, tout allait bien. Ma Twingo et moi vivions un amour fou. Elle me convenait très bien pour une utilisation hebdomadaire. Et puis petit à petit, j’ai commencé à l’utiliser un peu plus, et à prendre le train moins souvent. Et puis la SNCF a enchaîné les retards, grèves et autres perturbations, et j’en ai eu marre. Et j’ai fini par prendre la route tous les jours, et ne plus jamais prendre le train.

Et là, forcément, la Twingo n’est pas forcément la voiture idéale pour avaler 100 Km d’autoroute par jour. Alors je recherche actuellement une nouvelle voiture. Une voiture plus confortable, dans laquelle je serais prêt à passer deux heures par jour. Et puis bien équipée, où je pourrais facilement relier mon téléphone pour y écouter ma musique, des podcasts, etc. Si j’ai toujours des tas de questions qui me trottent à l’esprit, l’expérience de mon premier achat me permet d’aborder ce deuxième achat beaucoup plus sereinement.

Si je vous parle de tout ça, c’est parce que cette expérience de premier achat a fait écho à celle que peuvent avoir des clients en recherche d’un tout premier site web. Si j’essaie de guider mes prospects en leur expliquant les avantages et inconvénients de telle ou telle solution, j’ai forcément un point de vue biaisé sur la question. Alors si vous êtes entrepreneur, que vous avez besoin d’un site pour votre société, que vous n’y connaissez rien au web, quels seront vos critères d’achat ? Le prix ? Le ressenti des premiers rendez-vous ? La taille de l’agence web ? Le langage serveur ou le CMS utilisé ? Comment faire le tri entre les conseils de vos amis et ceux des différentes agences que vous avez pu rencontrer ?

Je n’ai pas de réponse universelle, mais en me basant sur ma propre expérience d’achat d’un premier véhicule, je conseille aujourd’hui souvent de ne pas dépenser tout son budget. Si vous n’y connaissez rien au web, il y a de fortes chances pour que les besoins que vous imaginez aujourd’hui soient très différents des besoins que vous aurez dans un an, après avoir eu déjà un peu d’expérience dans la mise à jour de votre site.

La théorie du McDonald’s

Je viens de le poster sur Twitter, mais je le reposte ici parce que j’aime vraiment beaucoup cette Théorie du McDonald’s de Jon Bell.

J’utilise un truc avec mes collègues quand on essaye de décider où manger le midi et quand personne n’a d’idée. Je suggère d’aller au McDonald’s.

Quelque chose d’intéressant se produit alors. Tout le monde tombe d’accord sur le fait qu’on ne peut pas aller au McDonald’s, et de meilleures suggestions de déjeuners émergent. Magie !

C’est comme si nous avions brisé la glace avec la pire idée possible, et maintenant que la discussion a commencé, les gens deviennent soudainement créatifs. J’appelle ça la théorie du McDonald’s : les gens sont inspirés à trouver de bonnes idées pour écarter les mauvaises.

C’est une technique que j’utilise beaucoup au travail. Les projets démarrent de différentes façons. Parfois on vous donne un brief formel. Parfois vous entendez une rumeur de quelque chose qui pourrait arriver et vous commencez à y réfléchir à l’avance. D’autres fois vous avez muri une idée pendant des mois ou des années avant de la partager avec votre équipe. Il n’y a aucun processus défini pour du travail créatif, mais j’en viens à croire que tous les comportements créatifs partagent une chose : le deuxième pas est plus facile que le premier. Toujours.

C’est tout ce que j’aime.

HTML5, CSS3 et les technologies qui fonctionnent

Il y a quelques jours, j’ai lu via le blog de Kaelig cet article sur le recrutement de développeurs front-end :

2) Ne me demandez pas de connaître XHTML/HTML4.1/HTML5

Les balises sont définies en HTML. A moins que vous n’ayez besoin d’un balisage pouvant être parsé en XML pour une raison ou une autre, me demande de connaître XHTML revient à dire : « je spamme de mots-clés pour être sûr de dégoter la bonne personne ».

Une meilleure façon de le dire serait : « Nous nous attendons à ce que vous connaissiez HTML, à utiliser ses balises de manière efficace, et d’avoir une bonne compréhension de la sémantique derrière chaque balise ».

Protip : ne laissez personne vous dire qu’il connaît HTML5 si tout ce qu’il sait se limite à l’utilisation du doctype.

Il y a quelques jours, j’ai aussi vu passé ce tweet de Benoît Meunier citant une interview de Judy Ramey (elle même citant Danny Hillis) :

Les choses qu’on appelle « technologies » sont les choses qui ne fonctionnent pas encore. Personne ne parle de la technologie d’interrupteurs d’éclairage.

Si j’évite au maximum de parler de « HTML5 » ou de « CSS3 » avec mes clients, je plaide coupable d’une utilisation parfois abusive de certains termes un peu fourre-tout. Par contre, je me rends compte que plus le temps passe, moins j’utilise ces termes pour désigner les choses « qui fonctionnent ».

Box-shadow ? C’est du CSS. Les animations et transitions ? Du CSS. Les filtres et shaders ? Du CSS3 !

C’est très subjectif. Mais j’ai l’impression que dans le langage courant, HTML et CSS désignent tout ce qui fonctionne, alors que HTML5 et CSS3 désignent ce qui ne fonctionne pas encore.

Une licorne en intégration

Devinette ! Quel est le point commun entre les morceaux de code suivants ?

<!--[if IE 10]><html class="ie10"><![endif]-->
<!--[if IE 9]><html class="ie9"><![endif]-->
<!--[if IE 8]><html class="ie8"><![endif]-->
<!--[if IE 7]><html class="ie7"><![endif]-->
<!--[if !IE]>--><html><!--<![endif]-->
-webkit-border-radius:5px;
-moz-border-radius:5px;
-o-border-radius:5px;
-ms-border-radius:5px;
border-radius:5px;

Bon, à part le côté répétitif lourdingue, vous ne voyez pas ?

Ils contiennent tous les deux une licorne, une créature légendaire, inspirée du mélange d’autres créatures, elles, bien vivantes.

Dans le premier exemple, la ligne <!--[if IE 10]><html class="ie10"><![endif]--> n’a jamais existé. Microsoft a abandonné le support des commentaires conditionnels dans Internet Explorer 10, et ce dès la deuxième Platform Preview.

Dans le deuxième exemple, les lignes -o-border-radius:5px; et -ms-border-radius:5px; n’ont elles non plus jamais existé. Microsoft et Opera ont tous les deux supporté la propriété sans préfixe.

Pourtant, je tire ces exemples de code légendaire de sites récents, codés par de vrais intégrateurs, dans la vraie vie. Le premier exemple est un bon rappel que dans le métier d’intégrateur, la veille fait partie intégrante de notre travail. Et le deuxième exemple est un bon rappel qu’il n’y a jamais de bonne pratique universelle (et, non, désolé, ajouter tous les préfixes possibles pour toutes les propriétés ça n’a jamais vraiment été une bonne idée).

Ton dogme c’est de la merde

Je me rends compte que je n’ai pas écrit d’articles depuis le début du mois. C’est en partie dû au fait que j’ai pas mal de travail. Mais je réalise que c’est peut-être aussi en partie dû à certaines réactions lues suite à certains de mes précédents articles.

Le mois dernier, Marie Guillaumet a écrit un excellent article chez Les Intégristes intitulé L’intégration web, cette leçon d’humilité. (Si vous ne l’avez pas encore lu, vraiment, allez-y.) Ce paragraphe a particulièrement retenu mon attention :

Le problème, ces dernières années, c’est que tout ce qui se dit sur la Toile à propos des méthodes de développement front-end est relayé sur Twitter et a tendance à être pris pour argent comptant. À chaque jour son nouveau messie. Pour peu que le messie en question ait beaucoup de followers, peu de voix s’élèveront alors pour remettre sa parole divine en question : « Si lui, si elle le dit, c’est qu’ils doivent avoir raison ! ».

Le mois dernier également, Christophe Andrieu a publié une réponse, elle aussi pleine de bon sens (même si je ne suis pas d’accord avec tout), à mon article sur la cible, intitulée Intégrateur dans la vraie vie. Là encore, un commentaire de Kaelig a résonné en moi :

Pour avoir été à la conférence “Responsive Day Out” il y a un mois à Brighton, où les Jeremy Keith et autres gourous du web “bien fait et responsive” parlaient de leur expérience, j’avoue qu’à la fin de la journée je commençais à en avoir assez des beaux discours qui se rapportaient à dire “si votre contenu n’est pas accessible sous Lynx, allez vous faire en…er, vous êtes juste mauvais”.

N’oubliez jamais que ces gens sont ceux qui crient le plus fort dans une foule de développeurs, pas forcément ceux qui sont les plus pertinents. D’ailleurs nombre d’entre eux n’ont jamais participé à des projets d’envergure, ou encore cachent qu’ils acceptent aussi des boulots alimentaires afin de ne pas écorner leur image d’experts.

Je ne peux pas m’empêcher de me sentir visé quand on parle de « beaucoup de followers » ou de « ceux qui crient le plus fort ».

J’ai actuellement 5469 followers sur Twitter. Ce chiffre me fait bouillir la cervelle quand j’y pense. Bien sûr, ce n’est rien à côté des trente-six millions de followers de la directrice de création de Polaroid. Mais pour un compte personnel d’intégrateur, où je parle quasiment exclusivement d’intégration, parti de zéro il y a tout juste trois ans, ça me laisse abasourdi.

Du coup, ça donne de l’écho à tout ce que je dis. Le moindre de mes articles fera plusieurs centaines voire plusieurs milliers de vues, même le plus débile (2807 vues depuis sa parution). Et puis j’ai des avis tranchés. J’écris sur des sujets qui me passionnent, des sujets qui me prennent aux tripes, des sujets qui me font réagir de manière viscérale.

En combinant les deux paragraphes précédents, je comprends que je puisse passer pour un « ayatollah » (ou pour Abraham Simpson).

Hier, je suis tombé sur cet article, « There is No Right Way to Develop Software« , dénonçant les gourous prétendant que leur façon de travailler est la seule et unique façon véritable de travailler. Et puis une recherche sur l’avant-dernière phrase de cet article, « Strong opinions, weakly held » m’a mené à ce fantastique article du même nom de Jeff Atwood en 2008. Il répond à certaines critiques vis-à-vis de son blog et de sa supposée autorité. Il commence par reprendre deux slides d’introduction d’une conférence.

Qu’est-ce que j’ai fait ?

Je n’ai pas de société.
Je n’ai pas participé au lancement d’une startup importante.
Je n’ai pas créé un framework ou un standard.
Je n’ai pas gagné beaucoup d’argent.

RIEN.

Il n’y absolument aucune raison pour laquelle vous devriez m’écouter.

Mais d’une manière ou d’une autre, j’ai 75 000 abonnés à mon flux RSS et plus de 50 000 pages vues par jour.

C’est un mystère pour moi, également.

Puis il enchaine :

L’autorité dans notre domaine est une chose étrange. L’autorité perçue l’est encore plus.

Je me suis toujours vu comme rien de plus qu’un amateur débutant à la recherche d’illuminations. Ce blog est ma tentative d’inviter d’autres personnes à faire ce voyage. C’est devenu un voyage assez populaire au passage, ce qui a subtilement altéré la nature du voyage et ma façon de l’aborder, mais le but reste le même.

Ça me trouble considérablement d’entendre que des gens me voient comme un expert ou une autorité, et non pas un camarade amateur.

Je n’aurais pas pu mieux décrire mon ressenti.

Tout ceci m’amène au titre de cet article, et à un autre excellent article lu le mois dernier, intitulé « Your Dogma is Bullshit« .

Chacune de nos perspectives se développe au cours du temps à travers les expériences de nos propres vies. La probabilité pour que les expériences d’une personne correspondent à celles d’une autre personne est quasiment nulle. Donc quelles garanties vous avez quand je dis « vous ne devriez pas utiliser Bootstrap » que j’y regarde de votre perspective ? Aucune, non ?

Même si je faisais de mon mieux pour voir de votre point de vue, le fait que nous ayons tous les deux suivis des chemins très différents — même si nous sommes arrivés au même point — signifie que je ne serais jamais capable de me mettre à votre place et de voir les choses comme vous les voyez. Sans comprendre le contexte, il n’y a aucun moyen pour moi d’avoir une telle prétention, peu importe à quel point j’essaye.

Donc si je ne peux pas prétendre savoir ce qu’il y a de mieux pour vous — et vous pour moi — comment savez-vous que ce que je raconte en ce moment même ce n’est pas de la foutaise également ? Je veux dire, j’ai commencé par une déclaration très large, comment savez-vous que j’ai raison ? Malheureusement vous ne pouvez pas le savoir. Et ce simple fait approuve ma déclaration — ou l’inverse, c’est à vous de décider. La totalité de cet article est un débat digne de l’oeuf ou la poule. Il n’y a aucun moyen pour qui que ce soit de prétendre qu’il est ou pas correct si ce n’est pour soi-même. Et c’est ça qui est génial !

Maintenant que vous remettez en cause mon dogme (et aussi peut-être ma santé mentale), vous commencerez à remettre en question les dogmes de tout le monde également, y compris les vôtres. Donc quand vous croyez que quelque chose est le meilleur — ou le pire — vous vous demandez, « comparé à quoi ? ». Comparé à vos propres expériences ? Aux miennes ? Et pourquoi pas comparé aux expériences de la prochaine personne que vous allez croiser ? Ou de la dernière personne que vous avez croisé ? Il n’y a aucun moyen de savoir, donc il n’y a aucun moyen de définir absolument ce qui est le meilleur, le pire, ou n’importe quoi entre les deux.

Est-ce que vous devez arrêter de faire des ombres portées dans tous vos designs ? Est-ce que vous devez arrêter d’utiliser Photoshop pour faire du web ? Est-ce que vous devez bannir tout texte en haut de casse ?

Peu importe. Ça dépend. Du projet, du contexte, de votre personnalité. Ces questions n’attendent pas une Vérité en réponse. Et ceux qui les posent n’ont probablement pas la prétention de la détenir.

La froideur du support numérique, et la nature souvent passionnée de nos métiers, fait qu’on est amené à réagir de manière viscérale. Mais ne vous trompez pas : si vous dénoncez ce que vous percevez comme un dogme par des conclusions tirées de vos propres expériences, vous serez à votre tour perçu comme un ayatollah.

Il y a deux ans, lors de l’affaire DSK, je me souviens avoir entendu un journaliste faire la déclaration suivante :

Dans un procés, il y a toujours trois parties : l’accusation, la défense, et la Vérité.

Je suis heureux d’avoir un blog personnel où je peux m’exprimer librement. Je ne prétends pas énoncer la Vérité. Mais juste à défendre les points de vues nés de mes propres expériences. Certains ressentiront ça comme des accusations. Je ne m’attends pas à faire l’unanimité. Mais si d’autres trouvent dans mes propos un écho à certaines de leurs expériences, et que ça leur permet d’avancer, alors je suis flatté d’y participer.

La nature du web

La semaine dernière, j’ai lu chez A List Apart un article qui m’a énormément plu de Kevin Goldman, Material Honesty on the Web. L’auteur s’interroge sur « l’honnêteté » d’une page web qui ne respecte pas la nature même du web. Il commence par rappeler les matériaux du web :

Les matériaux du web se rangent bien en trois catégories.

  1. La base : HTTP, URL et HTML
  2. Le style : CSS
  3. La décoration : « raster graphics » (du graphisme à base de pixels)

Ce n’est pas la première fois que je parle de matériau du web, mais je pense que cette notion est particulièrement importante. J’avais bien aimé la conférence de John Gruber, Apple and the Open Web, qui décrivait les fondamentaux du web comme « les deux HT : HTTP et HTML ». Mais la description me semble plus complète et bien répartie.

Il continue ensuite en décrivant chacun de ces matériaux et ce qu’il considère comme une utilisation honnête. Il est parfois un chouilla extrémiste sur certains sujets (tu sais que c’est extrémiste quand même moi je dis que c’est extrémiste), comme lorsqu’il dit « qu’un effet de lumière comme une ombre portée est malhonnête […] car il n’y a pas de source de lumière dans un écran numérique qui induit cet effet« . Mais il utilise l’exemple d’une brosse à chiotte pour compenser (tu sais que c’est un bon article quand on cite en exemple de design une brosse à chiotte). J’ai particulièrement retenu ce passage sur « la base » (où il cite un autre excellent article de septembre dernier chez A List Apart) :

L’article de Paul Robert Lloyd, The Web Aesthetic, pose la base.

Le web pourrait presque être considéré comme un matériau composite, constitué de HTTP (le « comment »), des URL (le « où »), et de HTML (le « quoi »). Omettez n’importe lequel de ces ingrédients et vous n’êtes plus en train de faire du web.

Faites ce que vous voulez par dessus, mais si ces protocoles n’existent pas, ce n’est pas du web. Ce n’est pas honnête.

Par exemple, un site en Flash qui n’a pas ces matériaux fondamentaux ne se chargera pas sur de nombreux appareils populaires. Puisque des URL honnêtes pour chaque page n’existent pas en Flash, ce sont vraiment des pages malhonnêtes qui sont difficiles à lier, pas partageables de manière prévisible, et difficiles à naviguer à cause du bouton précédent du navigateur qui peut produire des résultats inattendus. Certains robots de recherche peuvent indexer du contenu en Flash, mais comme ce n’est pas livré avec du HTML honnête, des tas de problèmes de SEO, d’accessibilité et de maintenance font surface. Ce n’est pas un secret que des interactions pauvrement prévues peuvent être malhonnêtes pour exactement les mêmes raisons.

Le concept important décrit ici, c’est de construire son site « par dessus » cette couche de matériau. L’inverse, ce serait de concevoir son site indépendamment de ces matériaux, par exemple dans Photoshop, et de construire son site par dessus cette couche fictive.

Et tout cela m’amène à vous inviter à lire un autre excellent article, publié il y a plus d’un an par Nicolas Hoffmann, qui parle Du web au naturel, du web « bio » :

Il est une chose dont j’ai l’intime conviction en matière de développement et d’intégration web, c’est qu’il faut rester le plus proche possible du fonctionnement naturel des divers éléments ainsi que de la simplicité.

J’ai la même conviction, que ce soit du chargement d’une page à des faux contrôles de formulaires. Concevoir un site autour de son design, chercher à tout prix à avoir le contrôle de son design sur le web, ce n’est pas faire preuve d’intelligence. C’est montrer qu’on n’a rien compris au web.

Le web est une plate-forme stupide, dans le sens où vous pouvez faire tout et n’importe quoi. Essayez de faire une application de 3 Go sur iOS, et Apple vous remettra dans « le droit chemin ». Essayez de faire une page web de 65 Mo, et personne ne viendra vous en empêcher. Encore une fois, la maxime « Juste parce que vous pouvez le faire ne signifie pas que vous devez le faire » est à garder à l’esprit. En particulier à l’approche de ce que j’appelle le troisième âge du web.

 

 

La compression d’images par les opérateurs

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.

Orange modifie vos couleurs

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.

La cible

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).

"This is for Everyone", Tim Berners Lee 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.

Un iPhone, c’est compliqué

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.

Et si on créait de meilleurs sites pour rien ?

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.

Et si on faisait un site meilleur pour rien ?

Google ferme Google Reader

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.

Google Reader

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.

Un pré-processeur est un outil

Il y a une résurgence d’articles récemment sur les pré-processeurs CSS :

J’avais déjà donné mon avis sur le sujet l’année dernière dans mon manifeste du CSS pur et dur. Il se trouve que depuis cet article, j’ai eu l’occasion de travailler sur un projet utilisant Sass. Mon avis n’a pas vraiment changé, mais mes craintes ont un peu changé de cible.

Le problème, ce ne sont pas les pré-processeurs en eux-même. Mais comme le dit très bien Roy Tomeij chez The Sass Way :

Sass ne crée pas du mauvais code. Ce sont les mauvais développeurs qui le font.

J’en parlais déjà l’année dernière, selon moi, la qualité d’une intégration se mesure sur trois objectifs (dans l’ordre) : l’internaute, le projet et moi. Le problème à mon avis, c’est qu’un pré-processeur incite à se concentrer totalement sur le dernier point (mon petit nombril d’intégrateur) en oubliant totalement le premier (l’internaute). Et le risque, c’est d’oublier totalement pourquoi on fait une intégration et de générer du code bouffi comme celui-ci :

a.icon-listen-bl:hover,
.event-related .box-title a:hover,
.category-related .box-title a:hover,
.readmore a:hover,
.footer a:hover,
.pagination a:hover,
.news a:hover,
.latest-tweet .date a:hover,
.feature .box-header .title a:hover,
.caption .title a:hover,
.full-agenda-link a:hover,
.article a:hover,
.medialib-nav a:hover,
.timeline-months a:hover,
.Timeline .feature .box-footer a:hover,
a.icon-listen-bl:active,
.event-related .box-title a:active,
.category-related .box-title a:active,
.readmore a:active,
.footer a:active,
.pagination a:active,
.news a:active,
.latest-tweet .date a:active,
.feature .box-header .title a:active,
.caption .title a:active,
.full-agenda-link a:active,
.article a:active,
.medialib-nav a:active,
.timeline-months a:active,
.Timeline .feature .box-footer a:active,
a.icon-listen-bl:focus,
.event-related .box-title a:focus,
.category-related .box-title a:focus,
.readmore a:focus,
.footer a:focus,
.pagination a:focus,
.news a:focus,
.latest-tweet .date a:focus,
.feature .box-header .title a:focus,
.caption .title a:focus,
.full-agenda-link a:focus,
.article a:focus,
.medialib-nav a:focus,
.timeline-months a:focus,
.Timeline .feature .box-footer a:focus {
text-decoration: underline;
}

Aucun humain sain d’esprit n’aurait écrit manuellement ce code, bouffi et rempli de sélecteurs peu efficaces.

Un pré-processeur est un outil. Au même titre que votre système d’exploitation, votre IDE, vos bibliothèques CSS ou JavaScript préférées, ce sont des outils.

Si vous utilisez une visseuse électrique et que vous abîmez tous vos pas de vis, il y a des chances pour que soit vous utilisez une mauvaise visseuse, soit vous ne savez pas vous en servir. Un pré-processeur n’est pas un mauvais outil.

Mais comme on dit dans l’informatique : PEBKAC.