« Of course, but maybe… »

Le dernier spectacle de Louis C.K., Oh My God, est vente en ligne sur son site pour cinq dollars. J’ai un amour inconditionnel pour Louis C.K. et ce spectacle est excellent. En particulier ce sketch, « Of course, but maybe… ».

http://www.youtube.com/watch?v=kKXIlufI0ow

Tout le monde a une rivalité dans son cerveau entre des pensées positives et négatives. Idéalement les pensées positives l’emportent. Moi, j’ai toujours les deux. Il y a le truc auquel je crois, le bon truc, et puis il y a ce truc. Je n’y crois pas forcément, mais c’est quand même là. C’est toujours ce truc, et ce truc. C’est devenu une catégorie dans mon esprit que j’appelle « Bien sûr, mais peut-être… ». Je vais vous donner un exemple.

Bien sûr, bien sûr, les enfants allergiques aux noix doivent être protégés. Bien sûr ! Nous devons isoler leur nourriture des noix, avoir leurs médicaments disponibles à tout moment. Et n’importe qui fabrique ou sert de la nourriture doit être au courant des allergies aux noix mortelles. Bien sûr ! Mais peut-être… peut-être que si toucher une noix vous tue, vous êtes censés mourir.

Bien sûr que non, bien sûr que non ! J’ai un neveu qui a ce problème. Je serais dévasté si quoi que ce soit lui arrivait. Mais peut-être… peut-être que si on ferme tous les yeux pendant un an, on en aura fini avec les allergies aux noix pour toujours… Non, bien sûr que non !

Bien sûr, si vous allez combattre dans un autre pays et que vous vous faites tirer dessus, c’est une horrible tragédie. Bien sûr, bien sûr ! Mais peut-être… peut-être que si vous prenez un arme et que vous allez dans un autre pays, et que vous vous faites tirer dessus, ce n’est pas si bizarre. Peut-être que si vous vous faites tirer dessus par le type sur qui vous étiez juste en train de tirer, c’est un tout petit peu votre faute.

Bien sûr, bien sûr, l’esclavage est la pire chose qui ait jamais existé. Bien sûr ! À chaque fois que c’est arrivé ! Les noirs en Amérique, les juifs en Égypte, à chaque fois que c’est arrivé, c’était quelque chose d’horrible. Bien sûr ! Mais peut-être… peut-être que n’importe quel accomplissement incroyable humain dans toute l’Histoire a été fait par des esclaves. Le moindre truc où vous vous dites « Mais comment ont-ils construit ces pyramides ? ». Ils ont juste balancé de la mort et de la souffrance humaine jusqu’à ce que ce soit fini.  Comment avons-nous traversé le pays avec des voies ferrées aussi rapidement ? On a juste balancé des chinois dans des caves et tout fait sauter sans se préoccuper de ce qui allait leur arriver. Il n’y a aucune limite à ce que vous pouvez faire quand vous n’avez rien à secouer d’un certain groupe de personnes. Vous pouvez faire tout ce que vous voulez ! C’est de là que vient la grandeur de l’espèce humaine, nous sommes des personnes merdiques.

Même aujourd’hui [en sortant son smartphone], comment avons nous ces merveilleuses technologies miniatures ? Parce que dans les entreprises où ils font ça les employés sautent du putain de toit parce que c’est un cauchemar là-bas. Vous avez le choix pourtant. Vous pouvez avoir des bougies et être un peu plus gentil les uns avec les autres. Ou alors laissez quelqu’un souffrir incommensurablement très loin d’ici pour que vous puissiez laisser un commentaire méchant sur Youtube pendant que vous faites caca.

La réponse universelle à toutes les questions que vous pouvez vous poser en intégration

Ça dépend.
(Marche aussi comme résumé des trois jours de conférences et ateliers de Paris Web 2013)

Un bon retour en intégration

Une partie de mon travail consiste à gérer les retours de mes collègues ou clients lorsque j’ai mal fait mon travail, ou lorsqu’un cas auquel je n’avais pas pensé se produit. C’est quelque chose de tout à fait sain. Je suis d’ailleurs bien plus rassuré d’avoir des retours après des tests sur une intégration, plutôt qu’aucun retour du tout. Sauf que mon enthousiasme pour gérer un retour est directement proportionnel à la qualité des renseignements fournis par son expéditeur.

Et malheureusement, il m’arrive de recevoir ce genre d’e-mails.

ASAP

Si vous envoyez ce genre de message, ou si vous pensez qu’il s’agit d’une façon appropriée de vous adresser à un autre être humain par courrier électronique, alors félicitations, vous venez de vous qualifier pour le titre de « La Pire Personne Au Monde », juste entre les prêtres pédophiles et les mamans qui congèlent leurs bébés.

Parce qu’un tel message n’aide personne. Il y a de grandes chances pour que le site ait été testé en bonne et due forme « SUR MAC » lors de son intégration. Et si la possibilité d’un bug sur une page en particulier n’est pas à exclure, « LE SITE NE MARCHE PAS » n’aide pas beaucoup à savoir ce qui cloche exactement. Et le « CORRIGEZ ASAP » ne m’incite pas vraiment à avoir de l’empathie pour ce problème qui vous semble si urgent.

Voici les informations que j’aime voir figurer lorsqu’on me remonte un bug en intégration.

  1. Assurez-vous que le problème ne vienne pas de vous. Pensez à rafraîchir le cache de votre navigateur, et vérifiez que celui-ci est configuré avec le niveau de zoom par défaut. (S’il est important de prévoir que son site s’affiche correctement selon différents niveaux de zoom, vous obtiendrez bien plus de respect de la part de vos intégrateurs en leur précisant que le problème survient à un certain niveau de zoom).
  2. Précisez de quoi vous parlez. S’il s’agit d’un problème sur une fiche produit, je veux savoir quel produit. Si c’est un problème lors d’un paiement, je veux savoir quel moyen de paiement. (Et si c’est un cheval, je veux savoir dans quelle course.) N’hésitez surtout pas à mettre une URL directement dans votre message de retour. C’est ça de temps en moins passé à rechercher est le problème pour chercher comment résoudre le problème.
  3. Précisez votre environnement de test : système d’exploitation, navigateur, appareil. Il n’est pas nécessaire de vérifier vous-même si le problème se produit sur plusieurs de ces critères. Dites-moi juste sur quoi vous avez testé, et je me charge du reste.
  4. Faites une capture d’écran. Rien de mieux qu’une capture d’écran pour comprendre un problème, plutôt que d’essayer de décrire en cinq paragraphes avec un jargon différent du mien (« il y a un décalage sur le drop sous le calque dans le push FD »). Et ne m’envoyez pas simplement une capture du bout de la page qui saute. Une capture d’écran complète de tout votre système peut me permettre d’identifier certains éléments extérieurs qui ont pu déclencher ce bug (« Oh, un plugin Skype. »).
  5. Précisez comment reproduire le bug. Si le bug n’apparaît qu’après une suite d’actions, précisez quelles actions vous avez effectué. Comme dans le cas précédent, une vidéo d’enregistrement de votre écran peut valoir mieux qu’un long discours pour des cas complexes.
  6. Priorisez. Si vous insistez pour m’envoyer une liste de cinquante retours par e-mails, alors indiquez moi ce que vous souhaiteriez voir résolu en priorité. (Et, non, désolé, mais tout mettre en priorité haute, ce n’est pas prioriser).

Merci d’avance !

Le mythe de l’éditeur WYSIWYG

Google a lancé hier soir Google Web Designer, un logiciel Mac et Windows permettant de créer des « designs attirants et interactifs basés sur HTML5 et des animations qui peuvent tourner sur n’importe quels appareils« . La promesse de Google Web Designer est alléchante, mais c’est en ouvrant le logiciel pour la première fois ou en lisant le centre d’aide de Google que l’on comprend mieux à quoi est destiné exactement ce logiciel.

Google Web Designer est une application web avancée construite avec HTML5 qui vous permet de concevoir et construire des publicités en HTML5 et d’autres contenus web en utilisant une interface visuelle et une interface de code intégrés.

Google Web Designer n’est donc pas un outil conçu pour créer des sites web. (Comme le disait Hajim El Attab sur Twitter, Google Ad Designer aurait été un nom plus approprié.) Pourtant, Google Web Designer me laisse le même goût amer qu’à chaque nouvel outil soit disant pensé pour la conception web. Je pense évidemment au dégoûtant Adobe Muse, ou encore à iAd Producer d’Apple (qui a au moins le mérite d’avoir un nom explicite sur sa finalité), mais aussi aux dinosaures du genre (Dreamweaver, Frontpage, iWeb). Ces logiciels s’évertuent tous à perpétuer le mythe de l’éditeur magique pour le web, et je trouve ça assez malsain.

Intégrer une page web, c’est résoudre des problèmes. Ces problèmes concernent l’adaptation d’une création graphique, l’accessibilité et l’interoperabilité d’une page, la maintenabilité du code, et la performance. Et bien sûr tout cela doit être fait dans un temps raisonnable.

Les éditeurs WYSIWYG comme Google Web Designer ou Adobe Muse ne se préoccupent que d’un seul point : la création graphique. C’est une vocation louable, mais qui se fait au sacrifice de tous les autres aspects de la conception web. Google Web Designer n’a donc aucun scrupule à générer une bannière de près de 100 Ko, puisque le seul problème que Google essaye de résoudre c’est d’arriver à ressortir graphiquement la même chose que ce qui a été fait dans l’éditeur. Et tant pis si la même bannière codée à la main aurait été dix fois plus légère.

Quand j’intègre une page web, je vais me poser des centaines de questions. Par exemple, pour du texte dans une police exotique : est-ce que j’utilise une police CSS ? (et toutes les questions qui vont avec : est-ce que cette police est utilisée ailleurs sur le site ? est-ce que le poids de la page actuelle permet de s’engraisser de la lourdeur d’une police CSS ? est-ce qu’on a la licence de droit d’utilisation de cette police sur le web ? est-ce que les coûts de cette licence rentrent dans le budget du projet ?), ou est-ce que j’utilise une image ? (et dans ce cas : plutôt un GIF, un JPG, un PNG, du SVG ? quels navigateurs doivent être supportés ? que se passe-t-il pour les autres navigateurs ?). Et ça, c’est juste un petit éventail de questions qui me traversent l’esprit à chaque fois que je fais face à une police exotique. J’ai tout un tas de questions à me poser face à n’importe quel composant d’interface. Et ce à chaque nouveau projet, peu importe combien de fois j’ai déjà intégré un élément similaire auparavant, parce que le web évolue vite, et c’est tant mieux.

Je ne pense pas que créer une interface qui permette de résoudre ces problèmes soit impossible. Mais la complexité de ces problèmes rendrait une telle interface aussi complexe que les problèmes qu’on essaie de contourner. Et même si ça peut être difficile à avaler pour certains, je suis convaincu que la complexité de HTML et CSS est un bien nécessaire.

 

Concours : gagnez 1 exemplaire de « Intégration Web »

Il y a deux ans, j’ai organisé un concours sur ce blog. À l’époque, j’étais plein de bonne volonté et je m’imaginais refaire des concours régulièrement. Et puis en fait j’ai trouvé ça pas super amusant à organiser, et donc j’ai abandonné l’idée. Et puis j’ai réfléchi à comment rendre ce genre de concours un peu plus utile et moins futile. Et nous voilà.

En partenariat avec Eyrolles, voici un nouveau concours pour gagner un exemplaire du livre « Intégration Web : les bonnes pratiques » par Corinne Schillinger.

Pour gagner, il suffit de faire un don en ligne à l’Unicef, et de m’envoyer une copie du bon de commande reçu lors du don (exemple) à l’adresse concours@hteumeuleu.fr. Le don doit avoir été réalisé après le 30 septembre 2013 à 13h37. Le montant du don est totalement libre. C’est un concours de rapidité. Le premier justificatif que je reçois a gagné.

Les résultats seront annoncés demain.

Bonne chance !

L’écran tactile de l’iPhone 5 est 2,5x plus rapide que ceux d’appareils Android

VentureBeat rapporte des tests réalisés par la société Agawi sur la qualité des écrans tactiles :

Dans leur premier test de référence TouchMarks, l’iPhone 5 répond au toucher en une moyenne de 55 millisecondes, contre 85 millisecondes pour l’iPhone 4. L’appareil Android qui s’en approche le plus est le Samsung Galaxy S4, à 114 millisecondes.

« Apple écrase la concurrence », déclare Peter Relan, président de Agawi. « Il y a toute cette autre dimension de réactivité à laquelle Agawi fait attention. »

Agawi a étudié l’iPhone 5 et l’a comparé à des smartphones tactiles Android comme le Moto X de Google, le HTC One, et le Samsung Galaxy S4. Il a aussi été comparé au Nokia Lumia 928 sous Windows Phone, qui a été mesuré à 117 millisecondes.

L’iPhone 4, sorti en juin 2010, a un meilleur écran tactile que n’importe quel smartphone concurrent sorti en 2013. Ça explique surement pourquoi je trouve toujours Android lent, quelque soit l’appareil testé.

Les créatifs et les costards-cravates

Jeffrey Zeldman et Mike Monteiro, dans le dernier épisode du podcast The Big Web Show (à 4′) :

Monteiro : J’adore le mot créativité. Je pense être quelqu’un de créatif. Je pense que tu es quelqu’un de créatif. Je pense que ma mère est quelqu’un de créatif. Je pense que la créativité est importante, quelque soit votre métier. Mais je ne suis pas un créatif. Je suis designer. C’est mon métier.
Zeldman : Si tu étais là où j’étais quand je bossais dans la publicité, on t’aurait appelé créatif. Parce que c’est ce qui te sépare des costards-cravates. Mais crois moi même les gens du marketing n’aimaient pas non plus être appelés « costards-cravates ».
Monteiro : Les deux titres sont méprisants. Ça suppose que les costards-cravates n’ont aucune créativité en eux, et ça suppose que les « créatifs » n’ont aucun sens des affaires. C’est doublement destructeur. Je veux que ces deux parties aient à la fois un sens des affaires et de la créativité. Et ils l’ont, et je pense que ça doit être reconnu. Les designers qui ont le plus de succès ont un très bon sens des affaires.

J’adore le mot créatif utilisé en tant qu’adjectif.
Je déteste le mot créatif utilisé en tant que nom commun.

Idées pré-conçues

Ce week-end, l’authenticité du million de fans de la page de soutien au bijoutier de nice a été largement remise en question, notamment sur le blog de Sébastien Musset ou même par l’AFP. Jusqu’à ce que l’agence KRDS contredise les contradicteurs en allant vérifier les données à leur source.

Ça m’a rappelé un passage de l’avant dernier podcast de John Gruber (vers 2h16), où il parle des rumeurs de la montre intelligente de Samsung :

VentureBeat a de soit-disant images de la montre intelligente de Samsung qui doit être annoncée dans trois jours. Je pense qu’ils se sont fait piégés. Et je ne plaisante pas. Je ne vais même pas en parler sur Daring Fireball. Je ne vais pas le faire.

Ça fait partie des choses dont j’ai peur : que quelqu’un d’autre se fasse piéger par une plaisanterie, que ça tombe pile dans mes cordes, que ça suive mes idées préconçues, et que je me jette dedans aussi, que j’en fasse une boutade, et puis qu’on se rende compte que toute l’histoire était fausse.

Je plaide coupable de beaucoup trop facilement de me jeter sur de fausses informations qui suivent mes idées préconçues (comme quand Yahoo Québec explique que les employés de Google ont droit à un petit coin spécial pour se masturber, sans préciser que « l’information » vient de The Daily Mash, site satirique). Mais ça me rend triste de me dire à quel point une information erronée circule facilement.

Apple n’a pas l’air d’aimer les sites responsive

Dans les dernières vidéos officielles d’iOS 7, Apple présente quelques nouveautés de Safari. Rien de bien folichon. Mais j’ai été très surpris de voir qu’à chaque vidéo, à chaque capture d’écran, Apple présente volontairement des sites desktop affichés sur iPhone.

Pas responsive

Apple présente quelques sites n’ayant pas de version mobile, comme Traveller, Outside Online, National Geographic. Mais surtout, Apple présente les versions desktop des sites du Washington Post, Pitchfork, Lonely Planet, Elle Decor, alors que chacun de ses sites dispose d’une version mobile sur laquelle on est automatiquement redirigée quand on s’y connecte depuis un iPhone.

Si c’était un argument fort pour le tout premier iPhone en 2007 (« ce n’est pas un bébé navigateur », dixit Steve Jobs), ça en devient presque ridicule alors que les nouvelles pages de l’iPhone 5c et 5s fonctionnent très mal sur iOS à cause de leur horrible défilement.

La sécurité passe aussi par la qualité

Ce soir, j’ai voulu consulter l’état de mon compte en banque personnel au Crédit Agricole. Je ne sais pas si c’est comme ça dans toutes les banques, mais le Crédit Agricole a cette bizarrerie d’être segmenté selon votre département, où chaque département est considéré comme une entité différente. Quand j’habitais en Picardie et que j’étais au Crédit Agricole Nord Est, je me rendais sur www.ca-nord-est.fr pour consulter mes comptes. Maintenant que j’habite dans le Nord, je suis au Crédit Agricole Nord de France, et je dois me rendre sur le site www.ca-norddefrance.fr (on remarquera que « norddefrance » n’est pas séparé par des tirets, contrairement à « nord-est »). Je trouverais ça plus simple de pouvoir me connecter directement sur le site www.credit-agricole.fr, mais ce site ne sert qu’à faire une redirection sur les sites annexes.

Or donc, en voulant aller consulter l’état de mon compte ce soir, je me suis rendu sur www.ca-norddefrance.fr. Et j’ai tout de suite été interpellé par un message bien mis en avant sur la page d’accueil.

Menace de sécurité

Menace de sécurité
Un virus particulièrement agressif est actuellement actif sur internet. Il s’attaque aux ordinateurs personnels et aux téléphones mobiles. Il permet à des escrocs d’effectuer des virements à partir de vos comptes.

Malgré le titre de l’onglet pas vraiment bien rédigé (« Alerte sécurité virus »), le vocabulaire utilisé est particulièrement effrayant ! « Menace », « virus », « agressif », « escrocs » ! Je ne suis pas sûr que la police utilisée corresponde à la gravité du message. Mais je décide quand même de découvrir de quoi il s’agit en cliquant sur le très peu explicite « En savoir + ».

Fenêtre pop-up bloquée

Pas de chance pour moi, la page a voulu ouvrir la fenêtre en pop-up, qui s’est retrouvée automatiquement bloquée par mon navigateur (Chrome, dans sa configuration par défaut vis-à-vis des pop-ups). La gravité annoncée de la situation ne vaut pas la pénibilité d’ouvrir une fenêtre en pop-up. Je décide alors de passer mon chemin pour le moment.

En cliquant sur le bouton « Accédez à vos comptes » sur la page d’accueil, je suis redirigé vers le domaine www.cr867-comete-g2-enligne.credit-agricole.fr, qui me permet de m’authentifier.

AUTH

L’URL utilisée n’est franchement pas rassurante, et j’ai un peu de mal à repérer le domaine « credit-agricole.fr » pour m’assurer que je suis bien sur le site de ma banque. Le titre de la page HTML (« AUTH ») et l’absence de favicon dans l’onglet du navigateur n’aident pas à me rassurer. Mais avec l’habitude, je sais que je suis bien sur le site de ma banque. Je vais donc pouvoir me connecter pour consulter mes comptes. Sauf qu’un message rappelant l’alerte sécurité attire à nouveau mon attention.

Alerte sécurité

Le Crédit Agricole accorde une grande attention à la sécurité de ses sites Internet. En tant qu’utilisateur, vous avez également un rôle important et actif à jouer pour assurer la sécurité des informations qui vous concernent. Consultez ci-dessous les RECOMMANDATIONS de SECURITE à respect :

« En tant qu’utilisateur », j’ai un rôle important à jouer pour assurer ma propre sécurité ? Je suis tout ouïe ! Je clique donc sur Nos recommandations. Là, j’ai droit à une fenêtre qui s’ouvre en pop-up (qui n’a cette fois-ci pas été bloquée par mon navigateur), sur cette page. C’est « l’espace sécurité » du site du Crédit Agricole Nord de France, qui vise à m’éduquer sur de bonnes pratiques pour assurer ma sécurité. Sauf que je ne retrouve aucune mention sur cette page de l’alerte sécurité qui m’a fait si peur. Je décide donc de fermer la fenêtre.

En revenant sur la page pour m’identifier à mon compte, je décide de cliquer sur le premier bandeau jaune tout en haut de la page. Là, je suis redirigé vers une page du « Guide sécurité » sur le domaine www.credit-agricole.fr, à l’adresse www.credit-agricole.fr/guidesecurite/Attention-malware-s-installant-sur.html. Le nom de la page HTML attise particulièrement ma curiosité : « Attention-malware-s-installant-sur ». Sur quoi ? Vite ! Dites, moi ! Je commence donc la lecture de la page, et je souris en voyant le titre de la page.

Titre mal intégré

Le design du site n’a clairement pas été prévu pour un titre aussi long. Résultat, le titre passe sur deux lignes, pour un rendu plus qu’amateur. Pour une page censée me rassurer sur la sécurité de mon compte, c’est raté. Je poursuis quand même la lecture des explications sur l’origine de la menace.

Et je commence à comprendre de quoi il s’agit en lisant les explications suivantes.

Android wins

Les « escrocs » envoient de faux SMS invitant à installer une application au format « .apk », l’extension des applications sur Android. Cela signifie qu’en tant qu’utilisateur d’iOS, je n’ai pas du tout à me soucier de cette alerte. [Insérez ici une blague sur Android et la sécurité]. Le choix d’une capture d’écran du SMS sous iOS me semble alors particulièrement malvenu. Et surtout, nulle part dans l’article il n’est fait mention d’Android ou d’iOS. Le Crédit Agricole parle uniquement et vaguement de « smartphone », ne cherchant pas du tout à rassurer les clients non concernés.

J’ai donc finalement pu oublier tout ça pour consulter tranquillement mes comptes. Mais un message lu dans mes pérégrinations me trotte à l’esprit.

En tant qu’utilisateur, vous avez également un rôle important et actif à jouer pour assurer la sécurité des informations qui vous concernent.

C’est vrai. Et c’est très important d’éduquer ses clients sur la sécurité des informations transmises en ligne et hors ligne.

Mais je pense que l’éducation sur la sécurité, ça passe aussi par une conception de qualité. En ne montrant que peu d’attention pour le choix de ses textes sur le web (comme le « En savoir + » ou le « AUTH » en titre de page), des URL farfelues, des pratiques du web d’un autre siècle (comme l’ouverture de fenêtre en pop-ups), le Crédit Agricole éduque ses clients à s’attendre à un service médiocre. (Ne me lancez même pas sur l’application iOS du Crédit Agricole). Les clients du Crédit Agricole ne sont donc pas surpris de recevoir une demande d’installation d’application sur leur smartphone par SMS. Ils ne seront pas non plus surpris ni méfiants de voir que la dite application est mal fichue, et que sa charte graphique est clairement falsifiée. Parce que c’est ce que le Crédit Agricole conditionne ses utilisateurs à accepter.

Peut-être qu’en ayant des services de qualité irréprochable, ce que j’estime être en droit d’attendre d’un établissement bancaire, les utilisateurs seraient plus méfiants face à des applications d’escroquerie médiocres.

Coast

Opera présente Coast, un navigateur sur iPad (et donc restreint à l’UIWebView et au moteur WebKit d’Apple). L’interface est bien polie avec de jolies animations un peu partout. J’ai fait une vidéo de quelques minutes du navigateur. J’adore l’utilisation d’une couleur propre au site détectée automatiquement avec la favicon au milieu pendant le chargement.

Coast (le navigateur d'Opera sur iPad)

Comment décider quels champs de formulaire supprimer

Sur le blog de l’agence Sud Africaine Flow Interactive :

Nous voyons souvent des équipes marketing demander des tas d’information pendant une inscription. « Comment avez-vous entendu parler de nous ? » « Quel est votre titre ? » (J’ai vu une liste de titre qui incluait non seulement monsieur, madame et mademoiselle mais aussi son altesse royale et amiral. Je ne plaisante pas.)

J’apprécie que les gens du marketing veulent savoir ces choses pour les aider à faire leur travail. Mais ajouter ces champs vous coûtera des utilisateurs. Voici donc un guide pratique pour décider de quels champs vous devez vous séparer…

Comment décider quels champs de formulaire supprimer

Fuck You.

Brad Frost, sur son blog :

Nous avons l’air de trous du cul.

La prochaine fois que vous vous trouvez intentionnellement en train de priver quelqu’un d’une expérience — pour acquérir une connaissance, compléter une tâche, pour faire quelque chose en ligne qui pourrait rendre leur vie ne serait-ce qu’un tout petit peu meilleure — imaginez vous debout devant cette personne dans la vraie vie, la regardant droit dans les yeux, puis fermement et sans le moindre doute, luire dire « Va te faire foutre. ».

Tout va très vite maintenant

Au cours de ces derniers mois, j’ai pris conscience d’un changement important en intégration : tout va très vite maintenant. Très, très vite. C’est quelque chose que je vois au jour le jour en faisant de la veille. Il ne se passe plus une semaine sans que je ne découvre une nouvelle propriété CSS fraîchement sortie des spécifications du W3C (bonjour :nth-match(), merci Kaelig) ou un nouvel outil pour concevoir du web (hello Sketch Mirror). Mais c’est surtout quelque chose qui a désormais un impact direct sur un projet web.

Prenons un petit projet web qui dure environ trois mois, entre la signature du projet et sa mise en ligne. (C’est optimiste, mais réaliste si votre client sait ce qu’il veut). En trois mois, vous aurez deux ou trois nouvelles versions de Firefox et Chrome. Ça signifie qu’entre le moment où vous commencez à concevoir votre projet, puis l’intégrez, puis le mettez en ligne, vous aurez deux à trois versions de navigateur de différence. Mais deux ou trois versions, ce n’est peut-être pas encore suffisant pour avoir des fonctionnalités radicalement différentes et impactantes.

Alors prenons un plus gros projet, qui durera environ un an. (Ce n’est probablement pas une bonne idée de démarrer un projet web en sachant d’emblée qu’il va durer aussi longtemps, mais ça peut aussi arriver par accident, par erreur d’estimation.) En un an, vous aurez environ huit nouvelles versions de Firefox et Chrome, une nouvelle version d’Internet Explorer et de Safari, une mise à jour majeure d’iOS, d’Android, de Windows, et d’OS X. C’est comme un paysage technologique totalement différent, apparu en un an. Ça ne signifie pas nécessairement une adoption aussi rapide auprès des utilisateurs.

Mais ça signifie que si vous faites un projet web prévu pour durer, vous avez grandement intérêt à vous projeter sur les futures versions de navigateur et d’en profiter pleinement. Je n’ai plus aucun scrupule à utiliser des animations ou des transitions CSS, du box-sizing ou des box-shadow, tant que ça respecte une dégradation gracieuse.

À la recherche d’un bug

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.

Le parachute de Curiosity

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.

D’un leader à un autre

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.

D'Internet Explorer à Chrome

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.

Il n’y a pas besoin de plugin pour ça

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.

Comment se charge votre page ?

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.

Chargement d'un article sur Fastcompany.com

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.

Après IE8

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.

Rappeler les bases

Le mois dernier j’ai eu la chance de séjourner à New York City. Au hasard de mes trajets en métro, je suis resté bloqué sur cette publicité :

You've got to hug and kiss your kids. Words aren't enough.

 

Vous devez serrer dans vos bras et embrasser vos enfants.
Les mots ne suffisent pas. 

Ça m’a semblé bizarre. Je n’ai pas d’enfants, mais cela m’a semblé être une évidence, un comportement des plus basiques à adopter. Bien sûr que vous devez faire des câlins et embrasser vos enfants. Il se trouve que cette publicité fait partie d’une campagne de 2008, « 10 façons d’être un super papa« , incitant d’autres comportements « basiques », comme écouter son enfant, manger ensemble, passer du temps ensemble… Cependant, je conçois que la vie de parent ne doit pas être toujours facile, et que ces rappels peuvent être utiles.

En parlant de rappel utile, je suis retombé ce week-end sur cet excellent article de Dustin Curtis sur les crash aériens, « Pilotez l’avion« . Il revient notamment sur les explications du crash du vol Air France 447 en plein océan atlantique en 2009 :

Peu après que le problème initial de capteur de vitesse ait été résolu par les systèmes anti-gel inclus dans l’avion, l’AF447 était un avion parfaitement opérationnel. Chaque instrument fonctionnait parfaitement. Il volait à une altitude sans danger. Si les pilotes avaient appuyé sur quelques boutons pour ré-activer le pilote automatique, tout le monde à bord aurait survécu. Mais ils ne l’ont pas fait. L’un des co-pilotes a fait une seule erreur absurde, pendant quatre minutes et vingt-trois secondes, qui a fait chuter l’avion.

Ce genre de défaillance humaine est plutôt courante; ce genre d’en apparence stupides décisions impossibles sont faites tout le temps dans des situations catastrophiques. J’ai déjà vu la panique s’installer quand les serveurs d’une startup sont tombés, par exemple, amenant les ingénieurs à passer à côté de choses simples dans leur confusion. J’ai déjà senti cette force écrasante quand j’ai fait de grosses erreurs.

À chaque fois que je lis ou vis l’une de ces situations, je me souviens d’une histoire que j’ai lue dans The Checklist Manifesto sur les listes de vérification en cas de panne moteur sur un avion Cessna à un seul moteur. La liste comporte six étapes cruciales, comme par exemple s’assurer que les vannes de carburant sont ouvertes et que la pompe du réservoir de secours est activée. Mais la première est fascinante. C’est simplement pilotez l’avion.  Dans la confusion causée par la perte d’un moteur, les pilotent paniquent souvent et oublient les choses les plus évidentes qu’ils devraient faire. Ça semble totalement inutile, mais cette étape assure la meilleure chance de survivre.

Je suis parfois surpris de certains commentaires sur des articles rappelant des bases, évoquant parfois la tristesse d’avoir à rappeler ces bases, parfois une pointe de condescendance, mais parfois tournant limite au lynchage public.

Plus je travaille en tant qu’intégrateur ou plus généralement en temps que concepteur web, et plus je réalise à quel point il est indispensable de rappeler les bases, que ce soit avec des clients néophytes ou des collègues avertis, et que ce soit dans des moments calmes en pré-conception ou dans des moments d’urgence une fois un site en production.