HTML5, CSS3 et les technologies qui fonctionnent

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

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

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

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

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

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

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

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

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

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

Une licorne en intégration

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

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

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

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

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

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

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

Ton dogme c’est de la merde

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

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

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

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

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

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

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

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

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

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

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

Qu’est-ce que j’ai fait ?

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

RIEN.

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

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

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

Puis il enchaine :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La nature du web

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

La compression d’images par les opérateurs

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

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

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

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

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

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

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

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

Et le résultat est sans appel.

Orange modifie vos couleurs

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

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

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

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

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

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

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

La cible

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

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

"This is for Everyone", Tim Berners Lee lors de la cérémonie d'ouverture des Jeux Olympiques de Londres en 2012

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

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

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

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

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

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

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

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

Un iPhone, c’est compliqué

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Et si on faisait un site meilleur pour rien ?

Google ferme Google Reader

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

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

Google Reader

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

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

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

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

Un pré-processeur est un outil

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

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

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

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

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

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

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

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

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

Mais comme on dit dans l’informatique : PEBKAC.

Les boutons « J’aime » de Facebook n’affichent pas les « J’aime »

En juin dernier, je parlais des inconvénients techniques des boutons des réseaux sociaux. Tout récemment, en étudiant l’impact sur la performance du site d’un client des boutons « J’aime », j’ai découvert quelque chose que j’ignorais totalement. Je suis peut-être la dernière personne sur Terre à avoir appris ça. Mais ça m’a tellement émoustillé que j’ai cru bon de partager ma découverte. Attention, accrochez-vous.

Les boutons « J’aime » de Facebook n’affichent pas les « J’aime ».

Du moins, pas que. Voici ce que dit officiellement la documentation de Facebook :

De quoi est composé le nombre affiché sur mon bouton J’aime ?

Le nombre affiché est la somme :

  • Du nombre de « J’aime » sur cette URL
  • Du nombre de partages de cette URL (cela inclut le copier/coller d’un lien sur Facebook)
  • Du nombre de « J’aime » et de commentaires sur des publications sur Facebook concernant cette URL

C’est visible clairement dans la vieille API REST où l’on retrouve ces trois valeurs distinctes :

  • like_count : le nombre de clics sur un bouton « J’aime » associé à cette URL, ou de « J’aime » sur une publication sur Facebook contenant cette URL.
  • share_count : le nombre de partage de cette URL sur Facebook.
  • comment_count : le nombre de commentaires publiés sur un message de Facebook contenant cette URL.
  • total_count : la somme des trois points précédents, affichés sur un bouton « J’aime ».

Vous pouvez tester par vous même en remplaçant l’URL du paramètre urls à la fin de l’adresse suivante (ici avec l’adresse de mon article précédent) :

http://api.facebook.com/restserver.php?method=links.getStats&urls=http://www.hteumeuleu.fr/shitty-shitty-design/

Ce fonctionnement me paraît totalement fou. Cela signifie que le compteur d’un bouton « J’aime » ne reflète en rien l’appréciation de votre page ou de votre marque. Mais plutôt uniquement un volume de réactions générés sur Facebook. J’ai fait quelques tests, et voici ce que j’ai observé.

Imaginons que vous écriviez un article absolument odieux. Quelqu’un va poster votre article sur Facebook avec un commentaire du genre : « Non mais n’importe quoi, quelle merde cet article ! ». Vous venez de gagner un « J’aime ». Un des amis de cette personne va alors cliquer sur le lien « J’aime » de cette publication, et poster un commentaire pour dire qu’il est totalement d’accord. Vous venez de gagner deux « J’aime ». Cet ami va reposter un commentaire quelques minutes plus tard pour corriger une faute de son précédent commentaire. Vous gagnez un « J’aime » supplémentaire. Et ainsi de suite…

Et vous connaissez le meilleur dans tout ça ? Si la publication originale est supprimée (et donc tous les « J’aime » et tous les commentaires associés par la même occasion), vous conservez tous les « J’aime » à votre compteur.

Et toute cette petite machinerie fonctionne également si vous publiez une URL sur votre propre mur dans une publication limitée à votre propre profil (« Moi uniquement »). Vous pouvez donc faire grimper le nombre de « J’aime » sur vos propres URL en vous contentant de poster des commentaires sur votre propre publication visible uniquement par votre propre profil.

Le narcissisme est à son apogée.

« Shitty shitty design »

Je viens de regarder la conférence Death to Bullshit de Brad Frost après être tombé sur sa magnifique page de présentation. Les conférences de Brad Frost sont en général un bon mélange d’inspiration, d’humour, d’énergie, de chemise à carreaux et surtout de très bonnes réflexions. (Je recommande également chaudement le visionnage de sa conférence For a Future-Friendly Web.)

Il y a un passage dans cette conférence qui a particulièrement résonné en moi. A 32min10, Brad parle de Craigslist :

Je veux aussi vous parler de Craigslist. Parce que j’adooore Craigslist ! J’adore le design de Craigslist. Allez-y, achevez-moi, je l’ai dit.

Ce que j’aime chez Craigslist et son design tout pourri (« its shitty shitty design« ) c’est que vous vous concentrez sur toutes les bonnes choses. Vous n’êtes pas distraits par des fioritures visuelles. Vous êtes à la recherche d’une information et le design l’offre à vous.

Ils sont à la quarante-troisième place dans le top cent des sites les plus visités au monde. Et ils sont là depuis seize ans. Vous croyez qu’ils n’auraient pas eu un peu de temps et un peu d’argent pour revoir leur site ? Ils savent ce qu’ils font.

Ça m’a rappelé un exemple que j’ai donné il y a deux ans, et qui reste pour moi l’un des meilleurs exemples de design français : Leboncoin. Leboncoin est le onzième site le plus visité en France, et est en ligne depuis bientôt sept ans. C’est assez perturbant d’aller sur archive.org et de constater que la page d’accueil n’a quasiment pas bougé d’un iota en sept ans. Il y a eu des petites évolutions, mais le « shitty shitty design » du site est toujours là. Vous pensez qu’ils n’ont pas eu le temps ou les moyens pour revoir leur site ?

Voici un autre exemple pour des sites que je visite quotidiennement : Hacker News et Designer News. Les deux sites ont le même principe : agréger et organiser du contenu soumis et mis en avant par les utilisateurs. Comme leurs noms l’indiquent, Hacker News s’adresse à des hackers, Designer News s’adresse à des designers. Designer News propose une charte graphique soignée et illustrée. Hacker News propose juste un « shitty shitty design« .

Hacker News

Designer News

D’un point de vue purement esthétique, Designer News est bien plus attrayant. Mais en réalité, je trouve le design de Designer News bien plus difficile à lire que celui de Hacker News. En particulier, les icônes ajoutées sur la gauche pour illustrer le type d’article et leurs couleurs vives nuisent à la lecture des titres des articles, ne sont pas suffisamment explicites (voici l’icône pour les articles qui parlent de design de sites), ou redondantes (voici l’icône pour les sujets de type « Ask DN »). Un bel exemple de « C’est joli, mais…« . Je préfère de loin le « shitty shitty design » de Hacker News qui est bien plus efficace.

Dans sa conférence, Brad Frost conclue son exemple de Craigslist :

Je pense que c’est important pour nous de prendre ces leçons à cœur. Trop souvent j’appelle ça « des beaux morceaux de merde ». Lorsque vous créez ces choses magnifiques, mais qui ne font pas grand chose et où il y a tellement de distraction dans l’interface que nous n’arrivons pas à passer au travers. C’est vraiment important que nous comprenions que, oui, notre métier implique de la beauté visuelle. Mais si le contenu, si la fonctionnalité, si l’accessibilité basique n’est pas là : est-ce que ça vaut le coût ?

Non.

Ce n’est pas du web

Au hasard de mes pérégrinations sur Awwwards (l’équivalent des Darwin Awards pour le web), je suis tombé sur My Provence Festival 2013, un site pour un événement touristique des Bouches-du-Rhône organisé dans le cadre de Marseille-Provence 2013, capitale européenne de la culture. J’ai été séduit par la charte graphique colorée et joliment illustrée du site. Mais mon enchantement est vite retombé.

Le site coupé sur mon Macbook Air

 

Le Festival débute chaque fin d’année par un concours de création sur internet ouvert à tous. À l’issue de ce concours, les lauréats et les artistes membres du jury viennent partager une résidence artistique éphémère afin de produire des

Afin de produire des quoi ?

Voilà tout ce que je peux voir sur mon Macbook Air 11″, configuré dans sa résolution maximale de 1366x768px. Le site utilise un défilement spécifique en JavaScript qui ne s’adapte non pas au contenu, mais aux différentes parties de la page. Ce qui signifie que sur mon écran, je ne pourrais jamais lire la suite du texte de présentation.

Motivé, je tente alors ma chance sur mon iPhone.

Mode portrait bloqué

Pas de chance, le site est totalement bloqué en mode portrait. En bon élève, je prends donc la peine de désactiver le verrouillage automatique de la rotation de mon iPhone, et je le tourne en mode paysage.

iPhone en mode paysage

Dommage pour moi, je ne peux toujours pas lire le contenu de ce site web. Désespéré, je tente ma chance sur un vieux PC que j’ai sous la main (avec un bon vieux IE7 des familles).

Vous utilisez une ancienne version de votre navigateur

Au final, le seul et unique moyen pour moi de lire le contenu de ce site, c’est d’en désactiver les styles.

My Provence sans CSS

Ceci n’est pas du web.

On ne doit pas faire de discrimination sur le web, c’est mal. Bloquer les gens selon leur appareil, c’est mal. Selon la taille de leur écran, leur système d’exploitation ou leur navigateur, c’est mal.
(à lire dans la voix de La Classe Américaine)

Faire ça, c’est passer à côté de l’essence même du web, un moyen de communication destiné à tous. Si vous créez une page HTML, par défaut, elle sera responsive, optimisée retina, compatible de Mosaic à Chrome 25 en passant par Lynx. Le travail d’un concepteur web, c’est de partir de cette base et de la rendre encore meilleure. Le travail d’un concepteur web, ce n’est pas de tout casser pour essayer d’arriver à un quelconque contrôle.

Pour paraphraser Christian Heilmann, si votre site web ne fonctionne qu’à partir d’une certaine résolution, ce n’est pas du web. C’est stupide.

Chez Mozilla ils sont nuls en zoologie

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. Chez Mozilla ils sont nuls en zoologie

Un exemple de la théorie de l’engagement

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 :

Une popup intrusive sur Upworthy

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 :

Et voilà : maintenant on vous demande de vous inscrire à la newsletter

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.

Ta page charge. Ce n’est pas sale.

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.

Beurk, beurk, beurk

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.

Les interfaces gestuelles

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.

Mon jeu préféré sur iOS

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.

Opera passe sous WebKit

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.

L’imbécile regarde le doigt

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.

Des boutons pour les imbéciles

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

Le bouton pour imbécile

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.

Le bouton pour les autres

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

L'imbécile regarde le doigt

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.

Ode au design itératif

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

Porsche

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

iPhoneDe la Game and Watch à la 3DS

Amazon

 

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.