HTeuMeuLeu

En voyant le nouveau site de Firefox OS, je ne peux que faire ce constat qui dure depuis trop d’années maintenant : chez Mozilla, ils sont nuls en zoologie. 

J’ai lu ce matin (via Openweb) un article très complet sur le persuasive marketing chez Gargarismes Ergonomiques. J’ai bien aimé ce passage :

Le persuasive design se base sur la théorie de l’engagement de Kiesler : vous agissez et pensez en fonction de vos actes antérieurs (“seuls vos actes vous engagent”). Ainsi, pour engager une personne vers un comportement final (p.ex. acheter l’intégrale de Mozart), on va lui faire réaliser des actes intermédiaires et préparatoires, les moins coûteux possible en termes d’effort (p.ex. l’inciter à poster un commentaire sur son attachement à Mozart directement sur le site web). On cherche ici l’acte le plus à-même de le prédisposer à en faire un plus coûteux (p.ex. recommander à un ami un CD de Mozart), pour finalement atteindre le comportement visé (p.ex. acheter un CD voire l’intégrale de Mozart).

Et oui, pour amener une personne à faire quelque chose, on pense souvent qu’il s’agit d’une question d’argument, de sensibilisation voire de formation. Détrompez-vous ! Voilà le 1er enseignement clé du persuasive design : pour vous persuader de quelque chose, la question n’est pas de savoir quels arguments on va pouvoir vous asséner mais bien de choisir ce que l’on va pouvoir vous faire faire. L’idée est de vous propulser dans une boucle engageante à travers divers comportements de prime abord anodins. Un simple “oui”, un simple “clic” est engageant.

Ça m’a fait sourire, parce que c’est exactement ce que fait le site Upworthy, un site qui rassemble les contenus viraux du moment. Quand vous accédez à une page du site pour la première fois, vous aurez droit à une popup plein écran de ce genre :

Luttez contre l’intimidation et la discrimination
Personne ne devrait faire face à de la discrimination en fonction de sa race, son orientation sexuelle, ou son apparence physique.
Je suis d’accord / Non, merci

Ce genre de popup intrusive à l’arrivée sur un site est particulièrement détestable. Mais le message proposé par le site est tellement évident qu’on ne peut qu’avoir envie de cliquer sur « Je suis d’accord », même si notre intention sous-jacente est de fermer cette popup. Sauf qu’en cliquant sur ce bouton, on aura droit à la suite du message :

Après vous avoir posé une question évidente, le site Upworthy vous invite à vous inscrire à leur newsletter. C’est l’un des plus vieux tours au monde. Un passant vous demande l’heure, et puis vous demande une petite pièce pour dépanner. Vous vous êtes déjà engagé dans une action. Vous pouvez y mettre un terme, ou alors poursuivre dans une action que vous n’auriez sans doute pas fait sans cette première question. Vu comment Upworthy teste 25 titres par article pour voir lequel marche le mieux, il y a des chances pour que cette popup marche bien pour eux.

Mais d’après moi, ce genre de pratique est à classer parmi les dark patterns : « un type d’interface utilisateur qui a été soigneusement conçue pour inciter les utilisateurs à faire des choses, comme souscrire à une garantie lors de leur achat ou s’inscrire pour un abonnement récurrent ». Ça marche, mais c’est à utiliser avec grande précaution.

J’ai l’impression que certains concepteurs web considèrent que le chargement d’une page web est un vilain processus qu’il faut absolument cacher aux yeux des gentils utilisateurs. J’avais été surpris de voir ça il y a quelques mois sur la version mobile du site de Fast Company. Mais ce n’est pas un cas isolé. Et il suffit encore une fois d’aller sur Awwwards (un site qui répertorie les mauvaises pratiques du web) pour s’en rendre compte (pim, pam, poum, …). Dans chacun de ces cas, il ne s’agit pas d’attendre le chargement de différents modules d’une application web complexe. Il s’agit juste de masquer aux utilisateurs l’effroyable réalité du chargement d’une page web.

Cher concepteur web,

Ta page charge. Ce n’est pas sale.

Au contraire : sur le web, c’est une excellente chose. Avant même que votre page web ne soit totalement chargée, l’internaute va pouvoir en prendre le contrôle. Il va pouvoir commencer à lire votre article, commencer à regarder les produits de votre page liste, etc.

Et, magie du web, en tant qu’intégrateur, vous n’avez strictement rien à faire pour qu’une page se charge progressivement. Le navigateur se charge lui-même de télécharger au fur et à mesure les ressources nécessaires afin de proposer le plus rapidement possible une page utilisable.

A l’inverse, ça signifie que pour masquer le chargement d’une page aux yeux d’un utilisateur, vous allez devoir travailler activement pour ça. Vous allez devoir maquetter votre écran de chargement, l’intégrer, développer un script qui l’affiche tant que la page n’est pas totalement chargée. (Ironie du sort : vous alourdissez votre page pour afficher un chargement parce qu’elle est trop lourde parce que vous l’avez alourdie avec votre chargement…) N’avez-vous vraiment rien de mieux à faire ?

Le chargement d’une page web, ce n’est pas sale. C’est naturel. C’est beau. Et c’est l’un des gros avantages du web.

Hier j’ai essayé l’application météo Haze sur iOS. L’interface est jolie tout plein. Sauf qu’avant d’y accéder, je dois subir près de 10 écrans d’explications sur son fonctionnement. C’est une pratique de plus en plus courante dans les interfaces tactiles basées sur des gestes. Mais comme pour un panneau « Pousser » sur une porte de Norman, si j’ai besoin d’un manuel d’instruction de dix pages pour savoir quel temps il fera demain, c’est qu’il y a comme un léger problème de conception.

En décembre dernier, Max Rudberg avait rédigé un excellent article à ce sujet, intitulé « Si vous voyez un guide pas à pas, c’est qu’ils se sont plantés » :

Ces applications ont choisi de réduire les détails pour arriver à une interface minimaliste. Mais dans le processus, l’interface est devenue plus difficile à utiliser. Malheureusement un guide pas à pas est un moyen plutôt peu élégant d’expliquer les fonctionnalités principales d’une application. Ça peut être un obstacle frustrant avant de plonger dans une application, et vous devez vous souvenir de toutes ces nouvelles façons de l’utiliser une fois dedans.

J’avais rencontré le problème avec Clear sur iOS. Après son installation, j’ai suivi attentivement les 8 étapes de leur didacticiel, et puis je me suis amusé à créé quelques listes et quelques tâches. Puis quelques semaines sont passées, et quand j’ai voulu réutiliser l’application, j’avais tout oublié. Je bidouillais, je glissais des doigts de gauche à droite, je tirais de tous les côtés. Je finissais par retrouver comment ça marchait. Mais c’était clairement pénible. Et ce n’est pas la première fois que ça m’arrive.

Il y a quelques années, j’ai joué à No More Heroes sur Wii. Dans le jeu, les combats se basent ostensiblement sur des mouvements à réaliser avec des combinaisons de touches. Le déroulement du jeu permet d’apprendre facilement et progressivement ces différents mouvements. Je me suis bien amusé pendant une à deux semaines, puis j’ai lâché le jeu. Quand j’ai voulu m’y remettre un mois plus tard, j’avais tout oublié. Je me sentais perdu. Je me sentais stupide. J’ai remis le nez dans le manuel papier du jeu. Puis j’ai fini par abandonner, définitivement.

Et puis il y a aussi le problème de la découvrabilité des actions réalisables avec une interface gestuelle. En novembre dernier, Jakob Nielsen publiait un article incendiaire à l’encontre de Windows 8 :

Une des idées les plus prometteuses de Windows est l’utilisation avancée de commandes génériques sous la forme de ce qu’ils appellent des « charmes ». Les charmes sont un ensemble d’icônes qui glissent de la droite de l’écran après un mouvement de glissement depuis le coin droit (sur une tablette) ou après avoir pointé la souris vers le coin en haut à droite de l’écran (sur un ordinateur). […]

En pratique, les charmes marchent mal — en tout cas pour les nouveaux utilisateurs. Le vieil adage « out of sight, out of mind » s’avère particulièrement vrai. Parce que les charmes sont cachés, nos utilisateurs oublient d’y faire appel, même quand ils en ont besoin. Dans des applications comme Epicurious, qui inclue un rappel visible de la fonctionnalité de recherche, les utilisateurs effectuent des recherches beaucoup plus souvent.

L’année dernière, j’étais tombé sur ce post sur Reddit :

Mon jeu préféré sur iOS : essayer de toucher le bouton retour sans toucher à la barre de notification.

Jouant moi-même régulièrement à ce « jeu », ça m’a fait sourire. Et puis j’ai lu le premier commentaire, et là ma vie a changé.

Glisse ton doigt sur la bannière de la droite vers la gauche et ça la fera disparaître.

Je ne sais pas comment j’étais censé deviner ça. J’ai peut-être raté un écran d’explication. Mais une indication visuelle, comme une petite croix à droite de la notification, pour la faire disparaître aurait sûrement été plus efficace.

John Gruber a trouvé à mon avis la bonne comparaison pour les interfaces gestuelles :

Je ne dis pas que ce sont de mauvais gestes. Mais ce sont comme des raccourcis clavier sur Mac. Pour n’importe quelles actions pour lesquelles vous vous attendez à ce que des gens normaux trouvent et utilisent, il doit y avoir un moyen visuel de les trouver. Vous pouvez ajouter un raccourci clavier que les utilisateurs experts mémoriseront, mais vous ne pouvez pas avoir uniquement un raccourci clavier. C’est la même chose avec les gestes.

L’année dernière à Sud Web, Bruce Lawson (responsable des relations avec les développeurs chez Opera) expliquait les dangers d’une monoculture web :

Les gens ont dit : « C’est votre propre faute, parce que vous, Opera, Mozilla et Microsoft n’avez pas innové suffisamment rapidement. Si on n’avait qu’un seul moteur de rendu, l’innovation serait plus rapide. »

C’est complètement fou. IE6 nous a prouvé que c’était fou.

La semaine dernière, Opera a annoncé son intention de passer toutes ses versions de navigateur (bureau, mobile et proxy) sous WebKit. La raison évoquée est purement stratégique : Opera a 300 millions d’utilisateurs dans le monde, dont 230 millions sur mobile. Pour ne pas perdre de parts de marché dans ce monde hautement concurrentiel et déjà largement dominé par des navigateurs WebKit, Opera est prêt à sacrifier Presto, son propre moteur de rendu.

Le mois dernier, j’écrivais sur la mono-culture WebKit :

La perspective d’une mono-culture WebKit semble de plus en plus réaliste. Mais ce n’est vraiment pas quelque chose dont on peut se réjouir. Et encore moins quelque chose que l’on devrait souhaiter.

Ça y est, on y est. D’ici la fin de l’année et le passage effectif d’Opera sous WebKit, plus de 95% des internautes mobiles seront sous WebKit.

Des dizaines d’articles ont été écrits sur le sujet, certains voyant ça comme une bonne nouvelle, d’autres pas. Je pense que ce commentaire chez Hacker News (lu via @nitot) résume bien la situation :

Le problème d’avoir un standard défini par une implémentation est que ça rend presque impossible d’avoir une autre implémentation.

C’est bien si on se met d’accord ici et maintenant en 2013 pour dire que WebKit est le seul moteur de rendu dont nous aurons à tout jamais besoin.

Ça ne semble pas un bon pari à faire. Opera était mieux sur certains points sur mobile que des navigateurs WebKit, à part pour les sites WebKit-only cassés. Ça ne va pas s’améliorer maintenant.

Le problème des débats sur la mono-culture, c’est qu’on ne sait pas comment l’avenir va se dérouler. Peut-être que réunir Apple, Google, Nokia, RIM et désormais Opera autour d’un même projet va permettre un web encore plus innovant. Dave Methvin, de jQuery, semble plutôt pessimiste à ce sujet :

Opera a soumis son premier patch à WebKit afin d’envoyer clairement son intention de ne pas s’éloigner du développement du moteur de rendu. Mais encore une fois, l’âge de ce bug souligne un des problèmes de WebKit. Il a fallu cinq ans et demi pour faire une correction d’une demi-ligne ! Maintenant pour un premier commit, c’est une bonne chose pour l’équipe d’Opera puisque ça leur permet d’avoir un ressenti du système et d’écrire quelques lignes supplémentaires de tests unitaires. Mais cinq ans ? Pourquoi si longtemps pour un bug aussi trivial ?

Parce que corriger des bugs ne fait pas la une.

C’est à mon avis la peur la plus raisonnable à avoir de WebKit. En 2001, IE6 a attiré les développeurs avec son moteur de rendu flambant neuf et pleins de nouveautés futuristes comme ActiveX. Aujourd’hui, WebKit adopte un peu la même stratégie en cherchant avant tout à être le premier à implémenter des fonctionnalités, et tant pis pour les bugs.

Le risque, pour nous, pauvres intégrateurs, est alors de se réveiller trop tard, et de devoir attendre à nouveau dix ans pour se détacher de la mono-culture WebKit.

Récemment, j’ai grincé des dents en tombant sur une maquette avec des boutons contenant des flèches pointant vers l’extérieur. Ça n’est pas nouveau, et il suffit d’aller sur Awwwards (le « prestige » du web design) pour se rendre compte que cette pratique est répandue comme la peste au quatorzième siècle.

C’est l’une des premières choses abordées dans l’excellent livre sur l’ergonomie et l’utilisabilité de Steve Krug, « Don’t make me think » (horriblement traduit dans une première édition par « Je ne veux pas chercher« ).

Un de mes exemples préférés est la boîte de recherche sur drkoop.com (le site de santé de C. Everett Koop).

A chaque fois que je l’utilise, je dois réfléchir, parce que le bouton qui exécute la recherche ne ressemble pas à un bouton. Pourtant celui-ci présente deux excellents indices visuels : il contient le mot « Rechercher », qui est l’un des deux labels parfaits pour un bouton de recherche, et c’est la seule chose qui se trouve à proximité du champs de recherche.

Il y a même une petite icône triangulaire, qui est l’une des conventions sur le web pour inciter à « cliquer ici ». Mais la flèche pointe à l’opposé du texte, comme si elle pointait vers quelque chose d’autre, alors que la convention voudrait qu’elle pointe vers le texte cliquable.

Bouger la flèche vers la gauche suffirait pour éliminer le point d’interrogation au-dessus de ma tête.

Cela me fait penser à ce proverbe chinois et ce passage dans Le fabuleux destin d’Amélie Poulain :

Monsieur, quand le doigt montre le ciel, l’imbécile regarde le doigt !

Vos utilisateurs ne sont pas des imbéciles. Évitez de les forcer à se comporter comme tels.

Jason Fried (de 37signals) a mis en exergue un bel exemple de design itératif avec la Porsche 911 qui fête son cinquantenaire.

A défaut d’avoir une Porsche, voici d’autres exemples qui me viennent à l’esprit quand je pense à du design itératif.

 

J’ai lu beaucoup de critiques à l’encontre d’Apple sur le design « inchangé » de l’iPhone. Si vous comparez d’un modèle au suivant, les changements ne sont pas forcément flagrants. Mais si vous comparez le premier iPhone à l’iPhone 5, les différences sont flagrantes.

Cela m’amène à parler de la parabole du bateau de Thésée. Dixit Wikipédia :

D’après la légende grecque, rapportée par Plutarque, Thésée serait parti d’Athènes combattre le Minotaure. À son retour, vainqueur, son bateau fut préservé par les Athéniens : ils retiraient les planches usées et les remplaçaient – de sorte que le bateau resplendissait encore des siècles plus tard. Alors, deux points de vue s’opposèrent : les uns disaient que ce bateau était le même, les autres que l’entretien en avait fait un tout autre bateau. Le problème est de savoir si le changement de matière implique un changement d’identité, ou si l’identité serait conservée par la forme, ou encore d’une autre façon ?

Il y a une autre question, corollaire : si on avait gardé les planches du bateau et qu’avec, on en avait reconstruit un autre, lequel serait le vrai bateau ?

Pour les uns, le bateau de Thésée n’aurait pu rester identique à lui-même que s’il était resté à quai, constamment entretenu, et dans ce cas, même si aucune pièce d’origine ne subsistait du bateau d’origine, c’est bien ce bateau-là qui aurait été le témoin de l’aventure de Thésée.

C’est terrifiant de concevoir quelque chose de manière itérative, d’ajuster, d’adapter, d’améliorer, sans jamais avoir de finalité. Pourtant, c’est la meilleure façon de s’approcher du meilleur. Et le web est probablement la meilleure plate-forme pour mettre ça en pratique.

En ce moment, je lis « A Theory of fun for game design » de Raph Koster. Dans les premiers chapitres du livre, l’auteur détaille le fonctionnement de notre cerveau. J’ai particulièrement aimé l’explication suivante :

Il ne faut pas sous-estimer le désir d’apprendre de notre cerveau. Si vous mettez quelqu’un dans une chambre de privation sensorielle, il deviendra malheureux très rapidement. Le cerveau raffole d’être stimulé. À tout moment, le cerveau cherche à essayer d’apprendre quelque chose, à essayer d’intégrer des informations sur sa vision du monde. Il est insatiable de cette façon.

Ça m’a tout de suite rappelé un excellent article lu l’année dernière sur « l’endroit le plus silencieux au monde« .

Le plus long que quelqu’un ait survécu dans la chambre anéchoïque des laboratoires Orfield au sud de Minneapolis est 45 minutes.

Elle absorbe les sons à 99,99 % et détient le record mondial Guinness de la pièce la plus silencieuse au monde. Mais si vous y restez trop longtemps vous pourriez commencer à halluciner. […]

Quand c’est calme, vos oreilles s’adaptent. Plus la pièce est silencieuse, plus vous entendrez des choses. Vous entendrez votre coeur battre, parfois vous pourrez entendre vos poumons, ou les gargouillis de votre estomac bruyamment.

Dans une chambre anéchoïque, vous devenez le son.

Et c’est une expérience vraiment déroutante. M. Orfield explique que c’est si déconcertant que s’asseoir devient une obligation.

Il dit : « La façon dont vous vous orientez est grâce aux sons que vous entendez en marchant. Dans une chambre anéchoïque, vous n’avez aucun indice. Vous retirez les indices perceptifs qui vous permettent d’être en équilibre et de bouger. Si vous restez là pendant une demi-heure, vous devez vous asseoir. »

En décembre dernier, j’ai lancé le site 24 jours de web, « le calendrier de l’avent des gens qui font le web d’après ». Voici quelques remarques personnelles sur ce projet.

C’est peut-être le phénomène de Baader-Meinhof, mais le moins qu’on puisse dire, c’est qu’il y a eu un paquet de calendriers de l’avent autour du web cette année. Entre 24 ways, Performance Calendar, UXmas, ou The Christmas Experiments, il y avait de quoi lire.

Je pensais que ce serait facile comme projet. Un appel à auteurs et association en novembre, un thème WordPress à créer, et hop début décembre tout est prêt et on n’en parle plus. Oh, comme j’étais naïf.

Le dimanche 28 octobre, j’ai contacté quatorze personnes que j’apprécie, que je connais dans la vraie vie ou pas, afin de les solliciter pour écrire un article. Cela m’a permis d’avoir déjà un premier aperçu du ressenti du projet. Quand j’ai reçu la réponse de Benoît Meunier dans l’après-midi, je savais que j’étais sur la bonne voie.

Certaines propositions doivent être longuement réfléchies. D’autres, comme la tienne, pas du tout.

Rémi, ce sera avec joie.

Sur ces quatorze premiers contacts, seuls deux n’ont pas donné suite, faute de disponibilité ou d’inspiration sur le moment.

Le 29 octobre, j’ai publié un appel pour chercher des volontaires pour écrire un article pour le site, et aussi pour trouver une association. Le message a été très bien relayé sur Twitter. Au total, j’ai reçu 34 propositions d’articles. Ça faisait super plaisir ! Mais ça m’embêtait de rejeter dix articles. J’ai écarté trois sujets que j’estimais pas assez aboutis, ou alors en décalage avec l’orientation « conception web » du site. Et j’ai donc retenu 31 articles. Ça tombe bien, ça me permettais de tenir tous les jours jusque fin décembre. Sauf qu’en fait il n’y a eu que 29 articles. Malgré de nombreuses relances de ma part, je n’ai eu absolument aucune nouvelle d’un des auteurs dont j’avais accepté l’article. Et concernant l’autre, j’ai eu la surprise de découvrir un article/tutoriel proposant un résultat copié/collé d’un autre article francophone. J’ai essayé de discuter avec l’auteur et de proposer un autre sujet, mais les échanges étaient houleux. J’ai préféré ne pas insister.

Avant le lancement, j’ai eu la chance d’avoir une proposition d’Agnès et de l’association les zCorrecteurs pour relire et corriger l’intégralité des articles. Je ne sais pas comment j’aurais fait sans eux. Non seulement ils ont pris le temps de corriger les fautes d’orthographe et d’adapter certaines tournures de phrases, mais aussi de commenter chaque article avec des règles simples pour éviter de refaire les mêmes fautes. Exemple :

« lâcher du leste »
leste = agile (adj.)
lest = truc lourd qui sert à alourdir les montgolfières et ce genre de choses.

Le premier décembre, le site a été lancé dès minuit. Et les visites ont commencé à affluer. 662 le premier jour, 759 le deuxième, 2249 le troisième (merci aux trolls dans les commentaires), 1432 le quatrième, etc. Le lancement du site s’est très bien passé. Mais c’est après que ça s’est gâté.

Je m’étais fixé un planning d’ordre de passage, sans critère particulier. Mais au premier décembre, je n’avais pas encore relu tous les articles. J’étais donc particulièrement en retard. Et je devais désormais coordonner les relectures orthographiques, les mises en pages des articles dans WordPress, les réponses diverses aux mails que je recevais, etc. Durant tout le mois de décembre, j’ai passé mes midis et mes soirées à assurer le bon déroulement du site, alors que je m’attendais à avoir tout fini début décembre.

Et comme si ça ne suffisait pas, il n’y avait quasiment aucun don sur le site. J’avais souhaité ajouter au site un aspect caritatif en incitant sur chaque page à faire un don pour une association ayant répondu à mon appel. Je me disais que quitte à avoir un site avec potentiellement un peu d’audience, autant en faire profiter quelqu’un. Sauf que ce n’est pas aussi facile que ça. Le 22 décembre, l’association avait récolté tout juste 300€. C’est bien. Et je me dis que c’est toujours mieux que rien. Mais avec 11 000 visiteurs uniques, 23 000 visites et 55 000 pages vues à cette date, ça faisait quand même vraiment peu.

J’étais un peu démoralisé. Mais j’ai continué. J’ai insisté. J’ai relancé lourdement les appels aux dons sur Twitter, même si je n’aime pas ça. Et j’ai créé une version epub de tous les articles, disponible au téléchargement pour tout don effectué. Et ça a pas trop mal marché.

Au total, le site a permis à l’association de réinsertion professionnelle L’Abri de récolter plus de 650€ (après la commission de Paypal). Et ça, c’est chouette.

Au total, depuis le premier décembre jusqu’à aujourd’hui, le site a accueilli 14 883 visiteurs uniques pour 31 959 visites et 73 643 pages vues. Et ça aussi, c’est vraiment chouette.

Alors je ne sais pas encore si je relancerais le site cette année. Mais au cas où, en guise de note personnelle à moi-même, voici trois points que j’aimerais améliorer :

• Gérer tout tout seul, c’est un peu difficile. Dieu merci j’ai eu l’aide des zCorrecteurs pour la relecture. Mais je pense qu’une aide supplémentaire pour la mise en place des articles sous WordPress ne serait pas de refus. 
• Je pense qu’avec 14 000 visiteurs, on aurait du pouvoir récolter plus de 1000€ pour une association. L’incitation aux dons doit donc être améliorée. Peut-être qu’il faudrait mettre en place un système où l’article du jour ne serait publié qu’à partir de x euros donnés. Peut-être qu’il faudrait créer une boutique avec des produits dérivés sur le thème du web. Peut-être qu’il faudrait trouver un partenaire prêt à faire un don en échange de publicité.
• Les articles publiés la dernière semaine ont été deux fois moins vus que les autres. C’est la faute des congés et des jours fériés de cette semaine, ou peut-être d’une fatigue du calendrier qui s’éternise au delà de 24 jours. Mais du coup, ce n’est pas cool pour les auteurs des très bons articles publiés cette semaine là. Je pense qu’il faut limiter le nombre d’articles à vingt-quatre.

Si vous avez des remarques ou des suggestions, n’hésitez vraiment pas à m’en faire part dans les commentaires ou par mail.

J’en profite pour remercier encore tous les auteurs, tous les donateurs, les zCorrecteurs et tous les lecteurs qui ont permis de rendre ce projet vivant.

Je suis intégrateur.

Je suis aussi entrepreneur, co-gérant, patron, concepteur, ergonome, développeur, blogueur, twitteur, concubin, collègue, ami, frère, fils, tonton, parrain, …

Par contre, je ne suis pas directeur technique, développeur côté client, ingénieur côté client, junior, senior, expert, gourou, ninja, star, …

Le terme qui me correspond le mieux, et avec lequel je me présente auprès de mes clients, c’est intégrateur. Ce n’est pas forcément le titre le plus explicite pour des personnes ne travaillant pas dans le web. Ce n’est pas non plus le titre le plus précis. Ce n’est certainement pas le titre le plus élogieux ou le plus fanfaronnant. Mais c’est le titre qui représente aujourd’hui le mieux mon métier. C’est un mot simple, court, humble.

Je suis intégrateur. Ce n’est pas un hasard si j’apporte un certain attachement à cette sémantique.

Hier, j’ai publié une blague sur Twitter :

Alicia Keys est Directrice de Création chez Blackberry. Will.i.am est DC chez Intel. Et Lady Gaga est DC chez Polaroid. (l’article chez The Verge)

Et après on se demande pourquoi je pouffe de rire quand on me présente un DC ou un DA dans une agence web.

C’est le genre de chose qui me fait rire. Ça me fait rire que mes collègues DA aient le même titre que Lady Gaga chez Polaroid. Je n’ai pas fait une blague atroce sur le physique de quelqu’un. J’ai fait un commentaire sarcastique sur le fait que le graphiste qui a réalisé les maquettes sur lesquelles je travaille en ce moment a le même titre que Will.i.am chez Intel.

Mais apparemment, ça a suffit pour lancer un débat sur Twitter toute la matinée sur le bien-fondé du titre de directeur artistique. Les habituels vieux de la vieille se sont insurgés, préférant croire à une méconnaissance de ma part (laissant alors place au tout aussi habituel « tu n’es qu’un intégrateur, tu n’as pas le droit de parler de ça »). Les plus compréhensifs se sont adaptés, reconnaissant que les termes de Directeur Artistique n’avaient plus beaucoup de sens.

C’est le problème avec les noms de métiers. Les instituteurs(trices) deviennent des professeurs des écoles. Les hommes/femmes de ménage deviennent des technicien(ne)s de surface. Les caissier(e)s deviennent des hôte(sse)s de caisse. Les noms changent, mais les métiers demeurent.

Il y a quinze ans, j’aurais volontiers adopté le titre de webmaster. Puis le nom a été utilisé à tort et à travers, usurpé, et vidé de sons sens. Ça n’enlève rien au métier qui se cache derrière. Mais soyons sérieux, travailler dans le web aujourd’hui et se faire appeler webmaster laisse place à un léger rictus.

Je ne serais peut-être pas intégrateur toute ma vie. Non pas que je n’aime pas ce métier. Je l’adore. Mais peut-être qu’un jour, Justin Bieber sera nommé intégrateur chez Apple. Et Carly Rae Jepsen sera intégratrice chez Facebook. Ce jour là, comptez sur moi pour faire des commentaires caustiques sur ces ambassadeurs improbables. Ce jour là, ce sera aussi surement l’occasion pour moi de prendre du recul sur mon métier, son intitulé et son sens.

Ces derniers mois, j’ai eu la chance de travailler à plusieurs reprises sur l’intégration d’e-mails responsive. C’est un sujet particulièrement intéressant qui rapproche des technologies préhistoriques (mise en page en tableaux, support CSS archaïque) avec des concepts modernes (du responsive design). C’est un peu comme si un scientifique fou décidait de resusciter des dinosaures.

Comment savoir quoi que ce soit sur un écosystème disparu ? et par conséquent, comment affirmer qu’on peut le contrôler ? Je veux dire, vous avez des plantes dans ce bâtiment qui sont vénéneuses et vous les avez choisies parce qu’elles étaient jolies. Mais ce sont des organismes vivants et agressifs qui n’ont aucune idée du siècle où ils sont et qui vont se défendre avec violence si nécessaire.
Dr. Ellie Sattler, Jurassic Park

Les logiciels mails sont un peu comme les dinosaures de Jurassic Park. Ils n’ont pas la moindre idée du siècle où ils sont. Par exemple, savez-vous quel moteur de rendu utilise Outlook 2003 ? Allez, faites une supposition. IE5 ? IE6 ? IE7 ? IE8 ? IE9 ? Félicitations, quoi que vous ayez répondu, vous avez gagné. Outlook 2003 utilise le moteur de rendu de la version d’Internet Explorer présente lors de son installation. Cela signifie que si vous installez Outlook 2003 avec IE6, que vous mettez à jour IE6 vers IE8, Outlook 2003 sera toujours sous IE6. Outlook 2003 est condamné à rester tout seul dans sa propre bulle pour le restant de son existence. (Merci au passage aux gens d’Email On Acid de se casser la tête pour essayer de comprendre ce genre d’horreurs).

Pas étonnant donc, que des logiciels comme Outlook puissent se comporter violemment si on essaye de leur donner du code un peu élaboré. Comme j’aime bien raconter des histoires de bugs, en voici un bien particulier sur lequel je suis tombé.

J’ai travaillé sur l’intégration d’un gabarit d’e-mail responsive pour la newsletter mensuelle d’un client. La newsletter est particulièrement longue, avec la présentation de plusieurs articles récents (avec une photo et un court extrait), des actualités et enfin la présentation de deux produits comme ci-dessous.

Dans la version mobile, les deux produits doivent simplement se retrouver les uns sous les autres. Facile, non ? Si c’est le b.a.-ba de l’intégration responsive pour un site, il faut déjà ruser un peu en utilisant des tableaux flottants (<table align="left">) pour le produit de gauche, le séparateur entre les deux produits et le produit de droite. Mais ce n’est pas la partie qui m’a posé le plus de problème. Et je suis rapidement arrivé à faire une intégration qui fonctionne sur l’ensemble des navigateurs, et sur les principaux logiciels mails mobiles.

Et puis, grâce à Email On Acid (ceci n’est pas un article sponsorisé), j’ai testé le rendu sur Outlook. Et là, c’est le drame. Sur Outlook 2007 et 2010 (qui utilisent le moteur de rendu de Word, normal), mes deux produits sont l’un en dessous de l’autre. J’ai beau réduire les tailles de mes tableaux, essayer d’ajuster le tout en laissant plus de marge, ça ne passe pas. Chaque test, chaque modification de dimension dans le code HTML nécessite que j’édite mon code, que je fasse une archive, que je l’uploade sur Email On Acid, que j’attende le résultat de la capture générée sur Outlook. Autrement dit, la démarche est longue et pénible. Et puis en lisant tous les précieux conseils glanés sur le web, j’ai trouvé ce qui pourrait être la solution. C’est particulièrement sale, mais à ce stade je n’avais plus rien à perdre. Et ça a marché. A priori, il s’agit d’un comportement « normal » du moteur de rendu de Word.

Voici la marche à suivre en quatre étapes, toutes nécessaires :

1. Ajoutez un bgcolor avec une couleur de fond sur tous les <td> des tableaux flottants
2. Ajoutez une bordure d’un pixel de la même couleur sur les tableaux en question
3. Diminuez la taille des tableaux de 2px pour s’ajuster suite à l’ajout de la bordure. Jusque là, vous me direz, il n’y a rien de trop sale. Mais attention accrochez-vous bien, car c’est maintenant qu’on va vraiment faire de la magie.
4. Entourez le contenu du premier <td> de chaque tableau flottant avec une balise de paragraphe. Stylez ce paragraphe avec les propriétés mso-table-lspace:0;mso-table-rspace:0;

Et moi qui trouvais ça crade d’ajouter un display:inline pour corriger les problèmes de marge sur des flottants sur IE6.

Mais youpi ! Désormais tout fonctionnait. L’intégration était terminée et la newsletter a pu être envoyée dans les temps. L’humanité était hors de danger !

Mais ça, c’était sans compter la newsletter suivante. Le mois suivant, tout fier de moi et de mon gabarit responsive, je m’apprêtais à intégrer cette nouvelle édition sur ce gabarit en deux temps trois mouvements. Tout se passait bien, jusqu’à ce que je teste sur Outlook 2007 et 2010. Une nouvelle fois, les deux produits se retrouvaient l’un après l’autre. « Attendez c’est pas possible, j’ai déjà passé des plombes à blinder ce gabarit », me suis-je dit. C’est parti pour un nouveau retroussage de manches et des tests à gogo. A l’ancienne, j’essaie d’épurer mon code au maximum pour n’avoir que les produits et essayer d’identifier le problème. Avec seulement les produits, tout passe bien. Je rajoute alors le footer de l’e-mail et une actualité au-dessus. Ça passe. Je rajoute encore d’autres extraits d’articles. Ça passe. Je rajoute le header du mail. Ça passe. Je rajoute le texte d’introduction. Ça ne passe plus.

« Petite futée. »

« Ce n’est quand même pas ce petit texte d’intro en haut qui fait tout péter dans le bas de mon mail. » J’essaie de comprendre, je cherche un logique à tout ça, je teste, je reteste, je déteste (la terre entière). Au fil de mes lectures, je finis par tomber sur cet article qui décrit une fonctionnalité bien étrange d’Outlook 2007 et 2010.

Dans Outlook 2007 et 2010, le moteur de rendu de Word insère une balise <br /> à chaque fois qu’il détecte « une limite de texte » (ce qui correspond a peu près à un saut de page). D’après Email On Acid, ces limites de textes apparaissent environ tous les 23,7 pouces (soit environ 1790 px). Et bah le voilà, mon problème. J’en arrive cependant à la 6ème étape du débogage : « Mais comment est-ce que ça a pu marcher dans la première newsletter ? ». Et bien ma deuxième newsletter est un chouilla plus longue que la précédente. Du coup, Outlook insère un <br />, mais cette fois-ci en plein milieu de mes blocs produits. La solution adoptée est simple : éviter d’avoir un tableau qui englobe tout l’e-mail, et diviser son code en plusieurs tableaux les uns en dessous des autres. Youpi, cette fois-ci tout fonctionne !

Je peux désormais fièrement prendre un peu de recul sur mon code. Et tel le professeur Ian Malcolm, je ne peux que faire le constat suivant :

C’est vraiment un gros tas de merde.

Ce matin, j’ai lu avec stupeur cet article de Jeremy Kahn, « Je suis pour la mono-culture WebKit » :

Imaginez si Firefox passait à WebKit : ça libérerait des tonnes de temps passé à corriger des bugs de Firefox. Ne vous méprenez pas, un monde sans bugs spécifiques à certains navigateurs est une chimère. Mais standardiser sur un seul moteur de rendu ferait avancer d’un grand pas l’unification du web.

Vous ne serez pas surpris si je vous dis que Jeremy Kahn travaille chez Google. Mais je suis toujours aussi surpris de voir que l’argument en faveur d’un seul moteur de rendu trouve une audience.

Le débat n’est pas nouveau, et j’y avais longuement contribué il y a deux ans avec mon article sur le pixel perfect. Plus récemment, sur Branch, j’expliquais mon point de vue.

S’accorder sur un moteur de rendu unique, c’est comme souhaiter une dictature. Ça peut être bien si le dictateur en question est sympa et oeuvre pour le bien de tous. Mais l’Histoire nous prouve que ce n’est jamais le cas.

S’accorder sur un moteur de rendu unique, c’est choisir un bénéfice à court terme (ne plus avoir à se casser la tête avec plusieurs moteurs de rendu), au détriment de bénéfices au long terme (avoir des navigateurs toujours plus performants et plus complets).

J’aime beaucoup la conclusion de l’article de ce cher Kahn :

La compétition est bonne et nécessaire, mais pas pour tout. J’adorerais voir les fabricants de navigateurs se concentrer sur la compétition pour des fonctionnalités qui bénéficient à l’utilisateur, plutôt que sur leur propre interprétation des standards du W3C.

J’aurais tendance à dire que les navigateurs sont finis. Et même si les quelques nouveautés d’interface bien pensées apparues ces dernières années sont les bienvenues, la vraie différenciation se fait justement sur le moteur de rendu et le moteur d’exécution JavaScript. C’est là le nerf de la guerre. Je ne pense pas qu’un traducteur ou un lecteur PDF intégré soit un argument suffisant pour des vrais gens pour s’imposer la difficile tâche de changer de navigateur. Par contre, un navigateur deux fois plus rapide à afficher une page web, ça peut valoir le coup.

Opera a récemment présenté un projet de navigateur mobile sous WebKit. Mozilla en a fait de même l’année dernière en présentant Firefox Junior. Même Microsoft utilise WebKit pour Outlook 2011 sous Mac. Dans le web mobile, WebKit bénéficie déjà d’un monopole important entre Safari sous iOS et Chrome sur Android.

La perspective d’une mono-culture WebKit semble de plus en plus réaliste. Mais ce n’est vraiment pas quelque chose dont on peut se réjouir. Et encore moins quelque chose que l’on devrait souhaiter.

Vendredi, Aaron Swartz, 26 ans, s’est donné la mort. Je ne vais pas mentir : je n’avais jamais entendu son nom avant d’apprendre la nouvelle. Mais il se trouve que je connaissais malgré moi son travail. A 14 ans, il co-écrit la spécification RSS 1.0. A 19 ans, il créé la société Infogami qui sera rapidement fusionnée avec Reddit, dont il deviendra alors un des co-gérants.

Depuis juillet 2011, Aaron Swartz était poursuivi par la Court Fédérale des États-Unis pour avoir téléchargé 4 millions d’écrits académiques du JSTOR via de simples curl sur une connexion publique du MIT. Bien que les plaintes du JSTOR furent abandonnées, il fut persécuté par le procureur du Massachusetts. Il risquait 35 ans d’emprisonnement.

En lisant tous les articles qui fleurissent à son sujet, j’ai particulièrement aimé l’anecdote suivante où il explique comment il a réussi à rejoindre le groupe de travail RDF du W3C à l’âge de 14 ans.

D’abord j’ai demandé aux membres du groupe si je pouvais les rejoindre. Ils ont dit non. Mais je voulais vraiment être dans ce groupe de travail, donc j’ai essayé de trouver un autre moyen. J’ai lu les règles du W3C, qui était l’organisme de standardisation qui dirigeait ce groupe de travail. Les règles stipulaient que s’ils pouvaient rejeter n’importe quelle demande provenant d’un individu, si un organisme qui était membre officiel du W3C demandait d’ajouter quelqu’un dans un groupe de travail, ils ne pouvaient pas refuser. Alors j’ai parcouru la liste des organismes membres du W3C, j’ai trouvé celui qui me semblait le plus amical, et je leur ai demandé s’ils pouvaient me faire rejoindre le groupe de travail. Ils l’ont fait.

 

Quand j’étais petit, j’aimais bien lire les bandes dessinées Gaston Lagaffe. En particulier, j’aimais beaucoup un gag récurrent dans lequel Gaston cherche un déguisement pour le bal costumé.

Dans son emballement créatif, Gaston oublie à chaque fois le but initial de son déguisement, à savoir d’aller au bal, et s’interroge : « Oui… mais si on danse ? ».

C’est exactement ce qui m’est venu à l’esprit hier en découvrant la tablette IdeaCentre Horizon 27″ de Lenovo. En particulier, regardez à 0:49 dans la vidéo de présentation la gentille maman de famille qui transporte la tablette.

Du haut de ses vingt-sept pouces, la tablette de Lenovo pèse plus de 7,7 Kg. (En comparaison, un iPad mini pèse 308 g, un iPad 652 g, un Macbook pro 15″ 2,02 Kg, et un iMac 27″ 9,54 Kg.) Je peux imaginer l’intérêt d’un écran tactile d’ordinateur de bureau de cette taille. Je peux aussi imaginer l’intérêt d’une table tactile fixe de cette taille. Mais une tablette transportable, sérieusement ? Il semblerait que personne ne se soit dit « C’est bien… mais si on la transporte ? ».

Cette phrase de Gaston, j’y pense aussi souvent quand je reçois des maquettes pas tout à fait finies de graphistes débutants. « Il est joli ton formulaire qui rentre pile poile dans la zone de ton visuel… mais si on fait une erreur ? » Dans son emballement créatif, le graphiste avait oublié le but initial de son formulaire, à savoir valider des données saisies par l’utilisateur pour ensuite les enregistrer.

Le travail d’un graphiste web, mais aussi de tout concepteur web en général, c’est de penser. Et plus précisément de penser à tout. Il est joli ce _______, mais si _______ ?

Le mois dernier, j’ai regardé l’excellente conférence de Marcin Wichary à Fronteers 2012 intitulée « The biggest devils in the smallest details » (45 minutes, plus des questions/réponses). Marcin est développeur chez Google et travaille principalement dans l’équipe des doodles. Au cours de cette conférence, il revient sur plein de doodles réalisés ces dernières années avec des détails vraiment intéressants (et une bonne blague sur IE à la treizième minute).

Mais surtout, il présente un outil maison pour générer les animations des doodles (dont il avait déjà parlé chez Smashing Magazine) : le crushinator.

Voici le doodle qu’on avait pour la fête nationale. Il y a quelques années, on voulait faire un doodle pour Rude Goldberg, mais son anniversaire était le jour de la fête nationale.  Alors on s’est dit « Et si on faisait un doodle tandem », une machine très patriotique à la Rube Goldberg ? Voilà ce que ça a donné !

C’est une jolie petite animation qui marche vraiment bien. Mais réfléchissez-y. Comment feriez-vous pour mettre ça sur la homepage de Google de façon à ce que tout le monde en profite ? Vous avez quelques options :

• Vous pouvez mettre un GIF animé. Mais les GIFs animés sont plutôt bizarres. Ils ne sont pas très jolis et vous ne savez pas vraiment ce qu’il se passe avec eux. Vous ne pouvez pas les arrêter, vous ne savez pas quand ils se chargent exactement, à chaque image, et parfois ils sont longs à charger.
• Une vidéo en HTML5, Flash ou sur Youtube. Flash et Youtube sont plutôt cools mais assez lourds et ne marcheraient pas sur iOS.
• Une vidéo en HTML5, à l’inverse, ne marcherait pas sur tous les navigateurs.
• Des images individuelles : beaucoup de latence, beaucoup de bande-passante.
• Des animations CSS3 : on pourrait imaginer recréer tout ça en CSS avec des transformations et ce genre de choses. Mais ça ne marcherait pas sur les vieux navigateurs non plus.

Donc on a inventé notre propre truc, qu’on a appelé « crushinator ». (C’est une référence à Futurama.) La façon dont ça fonctionne est essentiellement que ça regarde chaque image et la compare à la suivante. Et ça créé un sprite à partir de la différence entre ces images.

J’avais adoré le doodle en hommage à Martha Graham, et j’étais bluffé par le sprite utilisé. C’est vraiment très intéressant de désormais savoir comment ça a été fait.

480×320, 1024×768 et 1280×720. Ah ah, comme je suis drôle. Cette blague est tellement vieille qu’à l’époque on rêvait avec du 640×480 sur des gros CRT 12″.

Bref, c’est à nouveau ce moment de l’année. Plutôt que de vous parler de statistiques de navigateurs et de vous rappeler à quel point c’est une époque extraordinaire pour être développeur web, j’ai envie de partager avec vous mes trois résolutions d’intégrateur pour l’année 2013.

1. Ne plus utiliser jQuery. jQuery fait typiquement partie de ces bonnes pratiques d’hier devenues des mauvaises pratiques aujourd’hui. jQuery a été créé en 2006 pour faciliter le parcours du DOM, faire des requêtes asynchrones et faire des animations, le tout avec une même syntaxe pour différents navigateurs. Sept ans plus tard, les problématiques sont radicalement différentes. Et à l’heure des sites mobiles et du responsive design, ce n’est vraiment plus acceptable d’inclure une bibliothèque JavaScript de 80 Ko. Si je veux parcourir le DOM ou faire des requêtes asynchrones, j’utiliserais du JavaScript vanilla. Si je veux faire des animations, j’utiliserais CSS.
2. Utiliser les préfixes correctement. L’année dernière, la mauvaise utilisation et la mauvaise implémentation des préfixes navigateurs avaient fait beaucoup de bruit. Si des efforts ont été faits du côté des navigateurs et du W3C pour accélérer les processus de standardisation et rapidement abandonner les propriétés préfixées en Recommandation Candidate, j’ai le sentiment qu’il y a encore du travail à faire chez nous, les intégrateurs. En particulier, il est important de garder en tête que les propriétés CSS préfixées restent des propriétés expérimentales. En utilisant des propriétés CSS préfixées, vous signez un contrat implicite avec les visiteurs de votre site vous engageant à garantir une bonne utilisation de ces préfixes, et ce au cours du temps. Si la base consiste à utiliser les préfixes de l’ensemble des moteurs de rendu (-o-, -webkit-, -moz-, -ms, etc.), il est aussi indispensable de laisser tomber ces préfixes dès que possible. C’est déjà le cas par exemple pour les propriétés border-radius et box-shadow. Mais c’est aussi le cas de pleins d’autres propriétés (transform, transition, animation, etc.) depuis Firefox 16, Opera 12.5, IE10 et prochainement Chrome. A moins de devoir supporter des vieilleries comme Firefox 3.6 ou Safari 4, vous pouvez commencer à faire un petit ménage dans vos préfixes. En 2013, correctement utiliser les préfixes navigateurs signifie d’également s’occuper de leur suppression dès qu’ils ne sont plus nécessaires.
3. Écrire et partager. J’ai lancé ce blog en juillet 2010, mais je me suis vraiment mis à écrire régulièrement à partir d’octobre 2011. En 2012, j’ai écrit 164 articles (contre 108 en 2011 et 17 en 2010). Je n’ai vraiment aucune prétention avec ce blog. Mais ceci est mon blog personnel, et c’est vraiment chouette d’avoir un espace personnel où s’exprimer librement. C’est vraiment très formateur, que ce soit dans la simple gestion d’un site personnel, mais aussi dans l’écriture, la formalisation de mes idées, et la prise de recul sur mon métier.
   En 2013, je souhaite continuer à partager mes découvertes, mes anecdotes et mes sautes d’humeur. Mais surtout, j’espère que vous en ferez autant.
   On a la chance d’avoir une communauté web francophone assez grande. Malheureusement, celle-ci n’est pas toujours très active. On a de chouettes sites comme Le Train de 13h37, Openweb, Webdesign Friday, Les Intégristes ou encore des blogs personnels que j’aime beaucoup comme ceux de Nicolas Hoffmann, Raphaël Goetter ou Kaelig (qui malheureusement se met à écrire en anglais). Mais ces lectures francophones restent anecdotiques par rapport à la masse d’articles anglophones intéressants mis en avant chaque jour sur Reddit ou Hacker News. En décembre, j’ai lancé 24 jours de web dans le but de rassembler un peu cette communauté web francophone, et ça a plutôt bien marché. J’espère lire plus d’articles en français cette année.

Comme toutes résolutions, je vais peut-être craquer et il y aura sans doute des exceptions. Mais j’espère que celles-ci pourront vous inspirer à définir vos propres résolutions de concepteurs web, et qui sait, peut-être les partager sur votre propre blog. (Vous voyez ce que je viens de faire ?)

J’ai un peu du mal avec les redesigns non sollicités. Un redesign non sollicité, c’est quand un individu lambda décide de reconcevoir un objet, un outil, une fonctionnalité ou l’identité d’une marque célèbre. Plus ou moins récemment, j’ai à l’esprit l’identité de Microsoft, un concept d’UI pour Windows, l’identité et le redesign de Wikipédia, un redesign du New York Times, d’American Airlines, ou encore le redesign de Craigslist paru chez Wired en 2009. Le site Uninvited Redesigns en rassemble un bon paquet.

De nombreux articles ont déjà été écrits concernant les redesigns non sollicités, mais je crois que c’est Khoi Vinh (du NYTimes) qui résume le mieux mon avis :

Les redesigns non sollicités sont formidables et amusants et utiles, et j’espère que les designers ne s’arrêteront jamais d’en faire. Mais en les faisant, j’espère aussi qu’ils se rappelleront que ça n’aide personne, et encore moins l’auteur du redesign, de présumer le pire de la source originale et des gens qui travaillent dur pour la maintenir et l’améliorer, bien que ces efforts puissent sembler imparfaits vus de l’extérieur.

L’un de mes principaux griefs envers ces redesigns non sollicités est qu’ils sont réalisés en dehors de toute contrainte du monde réel. Pas de contrainte de temps, pas de contrainte de budget, pas de contrainte hiérarchique, pas de contrainte historique. C’est facile d’arriver à présenter quelque chose qui peut sembler mieux sans tenir compte d’aucune de ces contraintes.

Mais surtout, quand il s’agit d’un redesign non sollicité d’un site ou d’une application, j’ai l’impression qu’il existe une certaine complaisance élitiste chez leurs auteurs à ne pas vouloir aller plus loin que des JPG. Et le problème, c’est qu’un JPG, ce n’est qu’un JPG. Tout récemment (vu chez Daring Fireball), un contre-point de vue sur un redesign de l’écran verrouillé de l’iPhone résumait très bien le problème :

Juste parce qu’un design a l’air beau ne signifie pas qu’il a été bien pensé.

Le design d’interface, c’est avant tout du design interactif. Ce n’est pas en vous paluchant sur vos PSD dans Photoshop que vous allez résoudre des problèmes. Et si ce redesign que vous entreprenez vous tient vraiment à coeur, alors allez jusqu’au bout, et réalisez le. Vous ne savez pas coder ? Alors apprenez à coder. Sans quoi, votre idée n’a pas beaucoup plus de valeur, que vous ayez ou pas réalisé des maquettes en JPG.

Derek Sivers, fondateur de CD Baby et auteur de l’e-mail le plus réussi au monde, avait rédigé l’article parfait à ce sujet en 2005 : « Les idées sont juste un multiplicateur de la réalisation« .

Ça me fait toujours rire quand j’entends des gens vouloir protéger leurs idées. (Des gens qui veulent que je signe une clause de confidentialité pour me parler même de leur plus simple idée.)

Selon moi, les idées ne valent rien à moins d’être réalisées. Elles sont juste un multiplicateur. La réalisation vaut des millions.

Explication :

IDÉE HORRIBLE = -1
IDÉE FAIBLE = 1
IDÉE COUCI-COUÇA = 5
BONNE IDÉE = 10
EXCELLENTE IDÉE = 15
IDÉE GÉNIALE = 20

PAS DE RÉALISATION = 1$
RÉALISATION FAIBLARDE = 1000$
RÉALISATION COUCI-COUÇA = 10 000$
BONNE RÉALISATION = 100 000$
EXCELLENTE RÉALISATION = 1 000  000$
RÉALISATION GÉNIALE = 10 000 000$

Pour faire des affaires, vous devez multiplier les deux.

La plus géniale des idées, sans réalisation, vaut 20$.
La plus géniale des idées avec une excellente réalisation peut valoir 20 000 000$.

Voilà pourquoi je ne veux pas entendre les idées des gens.
Je ne suis pas intéressé jusqu’à ce que je voie leur réalisation.

Le mois dernier, j’ai découvert en regardant la retransmission du HTML Meetup le projet Responsive Museum Week, initié par Geoffrey Dorne. Partant du constat que les sites de musée sont en général mal conçus et pas du tout adaptés à une consultation mobile, il a lancé un appel pour créer en une semaine des versions responsives de ces sites. Ce qui m’a particulièrement plu dans ce projet, c’est son côté très concret. Ici, pas de JPG, pas de Photoshop. Vous remontez vos manches, vous installez Stylish et vous créez votre CSS. Et le résultat est directement utilisable par tout le monde.

Ce matin je suis tombé sur ce bien chouette article intitulé « Le pouvoir de la complexité dans la communication visuelle » :

Un des axiomes de la communication technique est de garder les choses simples. Mais parfois, une communication complexe est la meilleure alternative.

De nombreux types d’informations ont leur propre vocabulaire accompagné de conventions pour la communication visuelle. Prenez l’exemple suivant :

La plupart d’entre vous reconnaîtront certainement ici de la musique, mais êtes-vous capable de lire la partition et d’identifier le morceau ? (en voici un enregistrement)

Si vous savez lire des partitions, vous pouvez tirer une énorme quantité d’information de cet extrait : les notes et les rythmes, les phrasés, les nuances (très fort ou très faible), quel instrument utiliser (cet extrait n’indique pas explicitement un piano, mais c’est suggéré par la façon dont la musique est organisée), les placements de doigts, etc. Dans cet exemple, la connaissance de la musique Italienne est utile pour comprendre « sempre pianissimo e senza sordini » (toujours très calme et sans sourdine) et d’autres phrases.

Voici un autre exemple différent d’un langage visuel spécialisé :

Voici le résultat du modèle complet :

Les modèles de tricots, comme la musique, utilisent un ensemble standard de symboles. Mais malheureusement pour la communauté mondiale du tricot, il existe de nombreuses variantes régionales. (Le problème est encore pire en crochet, où des termes comme « double crochet » [bride, en français] ou « treble/triple crochet » [double bride, en français, merci Madame pour la traduction] ont une signification différente dans les modèles en anglais Britannique et les modèles en anglais Américain). Ceci dit, il est faisable pour un tricoteur qui parle seulement anglais d’utiliser un modèle de tricot russe ou japonais.

Ces exemples m’ont immédiatement rappelé cette interview de Richard Feynman, prix nobel de physique. Je vous avais déjà montré cet extrait en février dernier en m’intéressant à la première partie de l’interview. Interrogé par un journaliste agacé qui cherche à comprendre pourquoi des aimants se repoussent quand on les colle. Dans cette deuxième partie, Richard Feynman lui explique pourquoi il ne peut pas lui répondre (à partir de 6:09).

Je ne peux pas vous expliquer cela dans des termes qui vous seraient familiers. Par exemple, si je vous expliquais que les aimants s’attirent comme s’ils étaient reliés par un élastique, je tricherais avec vous. Parce que rapidement vous me poseriez des questions concernant la nature des élastiques. Et si vous êtes suffisamment curieux, vous me demanderiez pourquoi des élastiques tendent à revenir à leur forme initiale, et je devrais alors vous expliquer cela en terme de forces électriques, ce qui était exactement ce que je voulais éviter de vous expliquer à la base. Donc j’aurais triché vraiment pauvrement.

Donc je ne vais pas pouvoir vous donner une réponse à votre question « Pourquoi est-ce que les aimants s’attirent ? », à part vous dire que c’est effectivement le cas. Et aussi vous dire que ça fait parti des éléments de ce monde, avec les forces électriques, les forces magnétiques et les forces gravitationnelles parmi tant d’autres. Si vous étiez étudiant je pourrais aller encore plus loin et vous expliquer que les forces magnétiques sont liées aux forces électriques, de manière très intime. Que la relation entre les forces de la gravité et les forces électriques reste inconnue. Et ainsi de suite.

Mais je ne peux vraiment pas faire un bon travail, voire même le moindre travail, pour expliquer les forces magnétiques dans des termes qui vous seraient plus familiers, parce que je ne le comprends pas moi même dans des termes qui vous sont plus familiers.

Tout cela m’a rappelé un travail qui m’a occupé en partie cette semaine. Il y a quelques années, nous avions développé un outil de génération de code HTML remplaçant certains codes de templates par des valeurs saisies dans un formulaire. A l’époque, on avait opté pour une écriture des codes de templates la plus simple possible, du genre [[field_type:field_name]]. Deux ans plus tard, en remettant le nez dans ce projet, cette écriture me semble des plus farfelues. A vouloir créer un système de templates lisible par n’importe qui, on a omis de rendre ça lisible pour un développeur. Notre outil étant destiné uniquement pour nous en interne, entre développeurs, il n’y avait aucune raison à vouloir chercher à simplifier cette écriture pour un néophyte.

Ça m’a rappelé la différence d’écriture qu’on peut trouver entre un template Smarty en PHP et un template WordPress. Smarty est un très bon système de template si vous souhaitez à tout prix masquer à votre audience (créateurs de thèmes, développeurs, intégrateurs) quelque chose qui pourrait ressembler à du code. Mais en tant qu’intégrateur, je trouve que c’est particulièrement horrible à lire et très rigide à manipuler. A l’inverse, WordPress propose simplement un ensemble de fonctions. Ça ressemble à du PHP, ça sent le PHP : c’est du PHP, et rien n’est fait pour essayer de le cacher. C’est probablement un peu plus décourageant pour un néophyte qui voudrait se lancer dans la création d’un thème WordPress.

Mais ça a le mérite d’imposer un minimum de rigueur. Si vous voulez jouer de la musique, il va falloir apprendre à lire des partitions ou des tablatures. Si vous voulez tricoter, il va falloir apprendre à lire des modèles de tricot. Si vous voulez comprendre comment fonctionnent des aimants, il va falloir comprendre la physique. Si vous voulez coder, il va falloir comprendre comment coder.

La semaine dernière j’ai lu Subcompact Publishing, une très longue et très complète analyse par Craig Mod des applications de magazines numériques.  Il part de l’exemple de la version iPad du magazine Vanity Fair qui nécessite plusieurs écrans d’explications pour comprendre comment s’en servir. Et il répond alors magnifiquement à la question : « Comment en sommes-nous arrivés à des interfaces si complexes ? »

Peut-être que nous avons fait nos Homer.

Quand il a été demandé à Homer Simpson de créer sa voiture idéale, il a créé The Homer. Sans retenue, le processus d’Homer était additif. Il ajouta trois klaxons et une bulle spéciale insonorisée pour les enfants. Il ajouta plus à tout ce que les voitures étaient déjà. Plus de klaxons, plus de porte-gobelets.

Dans le design de produit, l’exercice le plus facile est de faire des ajouts. C’est le moyen le plus facile pour faire d’un vieux truc un nouveau truc. L’exercice le plus difficile est de reconsidérer le produit dans le cadre du présent. Un cadre qui peut être très différent de ce moment où le produit avait été initialement conçu.

C’est une parfaite illustration. La prochaine fois que je me surprendrais ou surprendrais l’un de mes collaborateurs à vouloir ajouter des fonctionnalités sans queue ni tête à un site, je n’aurais qu’une chose à dire : « Arrête de faire ton Homer ! ».

Je n’ai pas beaucoup écrit ces deux dernières semaines, et ce pour deux raisons. La première, c’est que j’ai beaucoup travaillé la refonte d’un gabarit d’e-mail responsive pour un client. C’était un travail très intéressant et enrichissant. Mais c’est aussi le genre de travail qui donne envie de passer sa soirée prostré dans sa douche en pleurant. J’y reviendrais prochainement. Mais surtout, si je n’étais pas très actif sur ce blog, c’est parce que j’étais occupé sur le lancement d’un autre projet : 24 jours de web.

Inspiré par 24ways.org, 24 jours de web est un « calendrier de l’avent pour les gens qui font le web d’après ». Chaque jour jusqu’au 24 décembre, vous aurez droit à un nouvel article sur le design, l’intégration, le développement, l’accessibilité, etc. Et jusqu’au 24 décembre, le site vous invite à faire un don à une association caritative.

J’ai lancé ce projet principalement pour le fun. Mais j’en tire déjà beaucoup de leçons sur l’organisation d’un projet collaboratif dans des délais relativement courts. Les premiers retours que j’ai pu lire sur Twitter me semblent plutôt enjoués. Et vous aurez même droit à une surprise inutile totalement débile si vous faites un don.

Je vous invite donc cordialement à découvrir le site et à le suivre tout au long du mois de décembre. Et si vous avez des remarques ou des suggestions, n’hésitez pas à me les soumettre.