HTeuMeuLeu

Ce week-end, j’ai regardé un chouette documentaire sur Arte intitulé « Mission Curiosity, le grand défi sur Mars« . J’ai particulièrement bien aimé ce passage où les ingénieurs de la NASA testent le parachute qui servira à ralentir la chute de Curiosity sur Mars.

http://www.youtube.com/watch?v=35zHMwFAg3E&rel=0

Il ne doit pas y avoir beaucoup de métiers où des mecs se réjouissent autant d’avoir détruit un parachute qui vaut surement plusieurs dizaines de milliers de dollars.

Mais ça m’a forcément rappelé mon métier d’intégrateur. Cette frustration de ne pas réussir à reproduire un bug qu’on m’a envoyé. « Chez moi ça marche, alors essaye de vider ton cache, remettre le zoom par défaut du navigateur, désactiver tous les plugins, redémarrer, ou je sais pas, moi, formate Windows… « . Ça sonne souvent comme une excuse de développeur pour ne pas s’embêter à creuser le problème, mais je vous assure que c’est compliqué.

Si coder c’est 90% de débuggage et 10% d’écriture de bugs, alors tester c’est 10% du temps passé à s’assurer que ça marche dans les bons cas, et les 90% restants à essayer de faire planter son code coûte que coûte.

Il y a quelques mois, Brent Simmons écrivait un superbe article rendant hommage à son testeur préféré :

Durant ma récente conférence à AltWWDC, on m’a demandé ce qui faisait une bonne personne en Assurance Qualité. Je crois que j’ai répondu « l’acharnement ». Ce qui dans mon propre lexique est une éloge.

Voici le truc concernant Nick : il est convaincu qu’il y a un autre bug. Et il va continuer à chercher jusqu’à ce qu’il le trouve. Et, une fois qu’il l’aura trouvé, il sera convaincu qu’il y a un autre bug.

Il utilise plusieurs doigts (j’aime imaginer qu’il a une main coupée qu’il garde au chaud juste pour ça) et il passe un appel et remarque le moindre pixel décalé. Puis il écrit de bons rapports de bugs avec les étapes pour le reproduire, souvent des captures d’écran, et parfois même avec une vidéo.

Voilà ce qui fait une bonne personne en Assurance Qualité. Les meilleurs sont de macabres personnages qui se réjouissent de torturer des développeurs, mais qui sont aussitôt pardonnés par la concision et la précision de leurs rapports de bugs.

Il y a dix jours, je suis tombé via Twitter sur la carte des navigateurs Internet sur le site de L’Express. Ça m’a paru étrange, car les statistiques présentées ne ressemblent pas du tout à ce que j’avais en tête pour ces derniers mois. L’Express attribue la carte au site BoredPanda, qui lui-même attribue la carte à un utilisateur de DeviantArt, qui lui-même attribue la carte aux données de StatCounter, datées de 2012.

Les statistiques des navigateurs sont en général à prendre avec de très grosses pincettes, en particulier lorsqu’elles viennent de StatCounter. Néanmoins, elles permettent quand même d’entrevoir certaines tendances mondiales sur le marché des navigateurs. L’année dernière, StatCounter avait publié une vidéo présentant l’évolution du marché des navigateurs par pays de 2008 à 2012. J’adore ce genre de visualisation. En regardant de plus près l’évolution des statistiques par pays depuis la publication de cette vidéo, je me suis rendu compte d’un changement assez impressionnant qui s’est produit au cours de l’année passée. J’ai donc pris des captures d’écran des cartes de StatCounter des soixante derniers mois, et voici le résultat.

http://www.youtube.com/watch?v=6utpNh_MFtU&rel=0

En cinq ans, on est passé d’une planète toute bleue (sous Internet Explorer) à une planète toute verte (sous Chrome). Ça fait déjà un moment que StatCounter annonce que Chrome est le navigateur le plus utilisé au monde (déjà en 2011, puis à nouveau en 2012). Les données globales de NetMarketShare sont loin de corroborer cette information. Pourtant, j’ai de mon côté bien constaté une prise de première position flagrante par Chrome ces derniers mois sur des sites de clients.

Plus je fais mon bonhomme de chemin en tant qu’intégrateur, et plus je me rends compte qu’une différence majeure entre un intégrateur débutant et un intégrateur avec un peu plus de bouteille réside dans la confiance accordée à du code externe. Là où un intégrateur débutant va concevoir un site comme un assemblage de plugins et de bouts de codes trouvés sur le net, un intégrateur expérimenté s’en méfiera comme de la peste, à la limite du syndrome NIH. Plus j’avance et plus je me rends compte que la plupart du temps, il n’y a pas besoin de plugin pour faire quelque chose. Au contraire.

Récemment un collègue est tombé sur une page d’un site client qui déclenchait une action au bout d’une seconde. Il est resté bloqué deux secondes en lisant le code car le code JavaScript utilisait une fonction doTimeout, et pas la fonction native en JavaScript setTimeout. Il s’avère que doTimeout est un plugin jQuery dont la baseline est « Comme setTimeout, mais en mieux« . Et par mieux, ça veut surtout dire que ça fait exactement la même chose que la fonction setTimeout, mais avec une syntaxe proche de jQuery, avec la possibilité de chaîner les fonctions. C’est bien, mais dans 99% des cas ce n’est pas utile, et ça ne l’était certainement pas dans ce cas précis. Et pourtant ça a été appelé sur cette page, avec le Ko et la requête HTTP supplémentaire que ça impose. Ce n’est pas beaucoup 1 Ko. Mais 1 Ko pour écrire en jQuery ce qui aurait pu s’écrire en une ligne de JavaScript, c’est beaucoup.

Ça m’a rappelé mes premières années, quand on parlait de DHTML, de Scriptaculous, de Prototype, mais pas encore de Mootools ou jQuery. J’avais fini l’intégration d’un site. Le chef de projet commence à recetter, et tout de suite m’interpelle.

Le chef de projet : Les sous-menus ne fonctionnent pas.
Moi : Euh… Quels sous-menu ?

Je n’étais pas au courant qu’il devait y avoir des sous-menus. Ça n’avait été spécifié nulle part. Et apparemment, ce n’était pas utile parce que le directeur technique avait dit qu’il y en avait des tout fait très bien. Me voilà donc en urgence en train d’essayer d’installer un sous-menu, avec des compétences en JavaScript alors proches du néant. Je galère, je tâtonne, et puis je finis par avoir quelque chose de fonctionnel. Mais ça n’avait rien de qualitatif (dans la mesure où l’on peut quantifier la qualité d’une intégration). Et surtout j’avais l’impression de n’avoir rien appris. Oui, je savais désormais mettre en place un menu avec cette bibliothèque JavaScript en particulier. Mais ça ne m’aidait pas plus à comprendre le fonctionnement de base de JavaScript et du parcours du DOM.

Un an plus tard, après avoir fait quelques pas supplémentaires en JavaScript, je devais à nouveau intégrer un menu supplémentaire. Et cette fois-ci, j’ai décidé de me lancer, avec mon code HTML et Mootools. Et là j’ai réalisé à quel point la mise en place d’un tel menu était ridiculement facile (en particulier avec un framework de parcours de DOM qui évite du code un peu verbeux). En quelques lignes, j’avais reproduit le fonctionnement que j’avais eu du mal à obtenir un an plus tôt. Et c’était un sentiment enivrant de liberté, un peu comme faire du vélo pour la première fois sans roulettes. Et aussi l’impression d’avoir perdu un temps à courir après le bon plugin ou la bonne bibliothèque qui fait exactement ce qu’on recherche, alors que le faire de zéro demandait autant voire moins de temps pour un enrichissement personnel bien plus grand.

Loin de moi l’idée de vouloir bannir strictement tout code tiers, il est important de réaliser que les problèmes résolus par des plugins n’ont souvent pas grand chose à voir avec les problèmes que vous essayez de résoudre.

Parmi les détails qui font ou défont l’expérience utilisateur d’un site web, je suis convaincu que le chargement d’une page joue un rôle très important. Bien sûr, il faut que votre site se charge rapidement. Mais même en se chargeant rapidement, certains détails peuvent trahir le manque d’attention porté à l’intégration d’un site.

Voici un exemple sur lequel je suis tombé ce week-end. Il s’agit d’un simple article sur Fast Company. Voici une vidéo du chargement sur mon iPad mini.

http://www.youtube.com/watch?v=9dSZ_24g_Ok&hl=fr_FR&version=3&rel=0

Avec un poids total de près de 2 Mo et plus de 150 requêtes, cette page n’est clairement pas un modèle d’optimisation. Un test sur WebPageTest confirme qu’il y a du travail. Mais au delà d’une recherche de performance pure et dure, voici ce qui m’intéresse côté expérience utilisateur.

1. Au bout d’une seconde, le HTML est bien chargé et le <title> de la page s’affiche dans l’onglet du navigateur. C’est plutôt rassurant pour l’internaute et ça confirme que la page est bien en train de charger, et que le serveur n’est pas en rade.
2. Il faut ensuite attendre la troisième seconde avant de voir quelque chose s’afficher à l’écran. Mais tout ce que l’on peut voir, ce sont des couleurs de fond qui laissent imaginer la présence de texte. Parce que le site utilise des polices « non-standard » appelées en CSS, aucun texte ne sera affiché tant qu’elles ne sont pas chargées. Et parce que le site en charge 25 (oui, vingt-cinq), il va falloir patienter un petit moment avant de pouvoir lire quoi que ce soit. Ce qui est dommage, puisque si le site utilisait des polices standard, je pourrais déjà être en train de lire l’article pendant que le reste de la page se charge.
3. À quatre secondes, je vois apparaître le logo du site et la catégorie de l’article (« Technology »). Mais surtout, je vois un énorme encart avec une barre de chargement apparaître en haut de l’écran. Si j’avais déjà commencé à scroller dans la page, ça provoquerait un énorme saut, me faisant perdre le fil de ma lecture. Mais bon heureusement, comme je ne peux toujours rien lire, je reste bien sagement en haut de page en attendant que ça charge.
4. Au bout de six secondes, alléluia, les polices sont chargées. Je peux enfin commencer à lire l’article pour lequel j’étais venu à la base. À noter au passage que le chargement des polices déclenchera un changement de taille dans les hauteurs de ligne, provoquant à nouveau un saut dans le défilement de la page.
5. À sept secondes, alors que je commençais enfin à lire l’introduction de mon article, voilà que le bandeau en haut de page a décidé de s’agrandir, comme ça, sans intervention de ma part. Au passage, ça fait donc à nouveau sauter le défilement de la page, me faisant perdre le fil de ma lecture.
6. À huit secondes, le bandeau en haut de page reprend sa taille initiale, provoquant à nouveau un saut dans le défilement et mon désespoir de pouvoir enfin commencer à lire cet article.
7. À neuf secondes, le fameux contenu du bandeau de haut de page s’affiche. Et il s’agit d’une image. Une simple image, qui m’a empêché de commencer ma lecture.
8. À dix secondes, une publicité s’affiche sur la droite, détournant un instant mon regard avant que je ne puisse reprendre ma lecture.
9. Au bout de quinze secondes, la page est totalement chargée. Je veux enfin commencer à réellement lire cet article, ou utiliser la fonctionnalité « Lecteur » de Safari pour avoir un contenu bien mis en page et adapté à la lecture sur tablette.

C’est plutôt atroce, non ? Et encore, c’est pourtant un large progrès comparé à six mois plus tôt. Quand j’ai écrit « Ta page charge. Ce n’est pas sale.« , le site masquait totalement l’affichage de la page pendant son chargement. Cet exemple semble peut-être exagéré, mais je pense qu’il assez emblématique de ce que l’on rencontre de plus en plus.

Voici quelques observations pour améliorer l’expérience du chargement de son site :

1. Évitez les polices CSS. C’est le parfait exemple de « c’est joli, mais si… » (en l’occurrence, c’est joli, mais si on est venu pour lire ?). Au pire, si vraiment vous n’aimez pas vos utilisateurs et que vous aimez être pris pour un artiste, limitez-vous à une police. Mais rappelez-vous que vous êtes là pour faire du web, pas du print. Les polices CSS sont de véritables plaies pour l’expérience utilisateur.
2. Fixez les tailles de ce qui peut l’être. Je n’ai pas poussé en détail pour connaître les raisons du saut de l’image de l’article de Fast Company à la septième seconde. Mais peu importe la raison, c’est une mauvaise raison.
3. Générez côté serveur ce qui peut l’être. L’image en question de Fast Company aurait sans doute pu être générée d’emblée dans le HTML de la page, évitant ainsi un chargement supplémentaire en JavaScript. J’ai déjà vu des sites marchands qui changeaient côté client les prix des produits. Par pitié ne faites pas ça.

La semaine dernière, Raphaël Goetter implorait sur son blog la mort d’IE8 :

Nous sommes en juillet 2013 et Internet Explorer 11 va sortir dans quelques jours, plein de promesses.

En attendant, son arrière-grand-père IE8 continue à être très prisé dans certains milieux (et je ne parle même pas de IE6 !).

Juste pour vous faire baver un peu, voici une petite liste non exhaustive des fonctionnalités (propriétés, valeurs et fonctions) CSS3 que l’on pourra employer à tour de bras dès que IE8 ne figurera plus dans nos cahiers des charges.

Je suis tout à fait d’accord dans l’idée de voir décéder IE8. Par contre, de mon point de vue, je ne souhaite pas nécessairement voir IE8 mourir pour pouvoir utiliser de nouvelles propriétés. Avec un principe de dégradation gracieuse, on peut déjà utiliser depuis un bon moment en production des media queries, box-shadow, transforms, border-radius, opacity, et j’en passe.

J’aime bien la philosophie de Kévin Rocher sur le support des anciennes versions d’IE (lue sur le blog de son stagiaire) : « fuck ie6, ie7 vaguement navigable, ie8 navigable. ie9 propre. » À moins de ne chercher à faire du pixel perfect, IE8 n’est plus vraiment un problème.

Pour moi, la disparition d’IE8 serait une bonne chose car IE8 est le dernier survivant d’une espèce de navigateurs en voie de disparition : les navigateurs liés au système rarement mis à jour et avec une adoption très très lente. D’un côté, il y a les navigateurs non liés au système, comme Chrome et Firefox, qui eux seront mis à jour toutes les six semaines. Et de l’autre côté, il y a les navigateurs liés au système comme Internet Explorer et Safari, mais qui dans le premier cas a droit à des mises à jour automatique, et dans le second profite de l’adoption très rapide des dernières versions de l’OS.

Si on reprend les chiffres douteux de StatCounter, ça signifie qu’aujourd’hui, 80% des navigateurs utilisés en France ont moins d’un an. Ça a de quoi donner foi au futur du web et du métier d’intégrateur.