Les articles de la catégorie « Réfléxions »

Il y a 6 ou 7 ans, dans la première agence web dans laquelle j’ai travaillé, l’équipe de graphistes a failli me rendre fou. J’avais l’impression que la plupart d’entre eux avaient une culture web proche du néant. Digg ? « Jamais entendu parler, c’est quoi ? » LaFraise ? « Un site de bonbons ? » 37signals ? « Combien de quoi ? » Et encore aujourd’hui, il n’est pas rare que je lise des commentaires de personnes travaillant dans le web se vantant fièrement de ne jamais avoir eu de compte Facebook, ou de ne pas avoir de smartphone. Je trouve ça fou.

Selon moi, pour être un bon concepteur web, vous devez être un bon utilisateur. Et ce, que vous soyez chef de projet, graphiste, développeur, intégrateur, etc.

Être un bon utilisateur, c’est avant tout être curieux. C’est ne pas rechigner à s’inscrire sur un site, ou à installer une nouvelle application pour remplacer votre IDE ou votre logiciel de retouche photo habituel. En tant qu’utilisateur, vous allez peut-être faire de très bonnes découvertes, ou au contraire tomber sur des expériences exécrables. Vous allez peut être tomber sur un e-mail extrêmement bien rédigé. Ou vous allez peut être vous rendre compte que votre grille-pain veut vous tuer. Mais ce qui est bien, c’est que dans les deux cas, ce sera enrichissant pour vous.

Récemment, Jason Fried avait écrit ce tweet :

You know that thing you don’t like? What’s one good thing about it?

Être un bon utilisateur, c’est aussi faire attention au moindre détail. En utilisant un produit que vous n’aimez pas, essayez d’identifier ce que vous n’aimez pas. En utilisant un produit que vous aimez, essayez d’identifier ce que vous aimez. Dans les deux cas, est-ce que vos critiques sont universelles, ou alors purement subjectives et personnelles ? Soyons réalistes : aucun produit n’est universellement parfait. En répondant à ces questions, vous devriez commencer à prendre conscience de la cible des produits que vous concevez.

L’excellent Dustin Curtis a écrit un article plus ou moins sur ce sujet la semaine dernière :

 « Le meilleur » n’est pas nécessairement un produit ou un objet. C’est la récompense d’avoir gagné le combat entre la patience, l’obsession et le désir. Cela prend une quantité de temps déraisonnable pour trouver le meilleur de quelque chose. Cela vous demande de connaître tout à propos du marché du produit, de sa fabrication, de son design, et d’arriver à naviguer parmi les prix trompeurs et le marketing. Cela vous demande de trouver le meilleur objet pour vous-même, ce qui demande de savoir ce qui compte réellement pour vous.

Des gens raisonnables ne passeraient probablement pas leur temps à lire un livre sur l’histoire des couverts, à en acheter vingt ensembles, et à tester le ressenti de chaque ustensile en métal contre leurs dents. Cela paraît fou. Mais qui se soucie des gens raisonnables ?

Si vous êtes une personne déraisonnable, croyez moi : le temps passé à trouver le meilleur de quoi que ce soit vaut totalement la peine. Il vaut mieux avoir quelques objets fantastiques conçus pour vous plutôt que d’avoir de nombreux objets peu fiables conçus pour plaire à tout le monde. Le résultat, être capable de faire confiance aveuglément aux objets que vous possédez, est intensément libérateur.

Être un bon utilisateur, c’est aussi savoir faire la différence entre le suffisant, le bon, et le meilleur.

Ce week-end, j’ai regardé la vidéo du test du Nexus 4 de The Verge. Les tests vidéo de The Verge sont particulièrement bien réalisés, et le Nexus 4 semble être un bon rapport qualité/prix pour un téléphone Android. Mais à un moment, je suis un resté bloqué devant un petit détail de l’interface d’Android. De 4:15 à 4:30 dans la vidéo, Joshua Topolski joue avec le menu de notifications et le nouveau panneau de préférences.

Ma réaction a été de me dire : « Whao, cette animation est vraiment naze ». Alors que je regardais ce passage en boucle pour comprendre pourquoi, mon cerveau n’arrêtait pas de me dire « Ce n’est pas possible. On n’y croit pas une seule seconde. Pitié arrête moi ça ».

A ce stade de votre lecture, il y a quelque chose que vous devez savoir sur moi : j’adore les animations. Et pas juste des courts-métrages animés, comme celui-ci, celui-ci ou celui-là. Mais plus particulièrement, les animations d’interface. Bien réalisé, c’est le genre de détails qui peut totalement transformer et donner vie à une interface. Et dans ce domaine, Apple maîtrise plutôt bien le sujet.

Alors j’ai me suis tourné vers Youtube pour voir des vidéos du centre de notifications d’iOS, et essayer de comprendre en quoi l’animation d’Apple était si différente. Voici une comparaison côte à côte.

iOS et Android utilisent deux métaphores différentes pour cet effet d’apparition, que j’appelerais le tiroir et le parchemin. Quand vous ouvrez un tiroir, le contenu qui se révèle à vous suit le mouvement du tiroir. Pour voir le contenu qui apparaît, il suffit de laisser votre regard fixe vers le haut du tiroir. Quand vous déroulez un parchemin, le contenu qui se révèle à vous reste fixe. Pour voir le contenu qui apparaît, vous devez suivre du regard le déroulement en cours.

Retranscrits dans notre monde informatique, vous comprendrez déjà que l’effet du parchemin est naturellement plus fatigant pour notre cerveau et nos yeux. Mais surtout, sans notion physique et sans indication visuelle du contenu restant à dérouler, je pense que cette métaphore ne fonctionne pas.

Et le problème, c’est que sur le web, on en voit partout, des menus déroulants en parchemin. Voici quelques exemples glânés sur le web et via Twitter (merci @synapse_studio) : Ville d’Agen, Beats by Dr Dre, World Trade Center de Lyon, Highcharts JS, La cinémathèque française.

Alors cela ne signifie pas qu’il faut bannir les animations en parchemin. Mais ça signifie que si vous tenez vraiment à faire une animation en parchemin, vous allez devoir faire quelques kilomètres en plus pour que ça fonctionne vraiment. Récemment, Justin Windle a publié Makisu, une impressionnante démonstration de menu déroulant en CSS 3D. Je pense que cette animation rend particulièrement bien car elle est très détaillée. Mais le rendu est du coup visuellement un peu trop lourd et beaucoup trop caractérisé pour une utilisation réelle sur un site institutionnel.

Je pense que la propagation de cette animation est dûe en partie à jQuery. En jQuery, pour faire une animation en parchemin, il suffit d’appeler la fonction slideDown() sur n’importe quel élément. Et c’est tout. A l’opposé, pour faire une animation en tiroir, il faudra surcharger son code HTML pour avoir un conteneur avec une hauteur souple et un overflow:hidden, pour ensuite jouer sur un margin-top négatif sur un élément global à l’intérieur. Ce n’est pas forcément plus compliqué, mais ça demande plus de travail, et plus de réflexion. Certains sites, comme Converse, font ça pas trop mal.

Après jQuery, il devient désormais plus facile que jamais de faire des animations dans une page web. Mais comme j’aime à le répéter : juste parce que vous pouvez le faire ne signifie pas que vous devez le faire. Voici quelques conseils pour animer vos sous-menus :

1. Une animation sert à attirer l’attention et à renforcer la compréhension d’une action. Si vous n’êtes pas sûr de ce que vous faites, ou si vous n’avez pas beaucoup de temps pour travailler sur ces animations, alors ne faites rien. Une mauvaise animation va rendre votre site pire que sans animation.
2. A moins que vous n’ayez de solides arguments, privilégiez une animation en tiroir (plus reposante visuellement), et pas en parchemin (plus difficile à suivre pour notre cerveau, et beaucoup plus complexe à mettre en place pour être réellement efficace).
3. Ne répétez pas votre animation à l’apparition de chaque sous-menu quand on passe d’un onglet à un autre. Votre animation doit se jouer à la première ouverture d’un sous-menu, et puis c’est tout. Cela signifie que même si vous utilisez des animations CSS, vous aurez besoin d’un peu de JavaScript pour détecter ce comportement. Si cela vous semble trop contraignant à mettre en place, alors ne faites pas d’animation.

La conférence de Véronique Marino à Paris Web la semaine dernière, Comprendre l’autisme pour améliorer les projets transmédias, était pour moi une très bonne surprise. Certes, ce n’était pas une grande conférence ni du grand spectacle, comme ont pu l’être les conférences de Mike Monteiro ou Jake Archibald. Mais c’était une conférence avec un sujet important, le genre de sujet qu’on garde bien dans un petit coin de sa tête et qui mûrit en nous tout doucement.

La conférence tournait beaucoup autour de la description de l’autisme et les effets du handicap, mais aussi sur les solutions pour accompagner les autistes. Les exemples n’étaient pas nombreux, mais pourtant bien marquants.

Par exemple, les autistes comprennent difficilement le langage imagé. Donc si vous dîtes à un autiste que vous allez « manger un buffet froid », il comprendra plutôt que vous allez manger le meuble de votre grand-mère sans le réchauffer. Et ça, ça pose évidemment des problèmes dans la vie quotidienne, notamment face à des pictos.

Alors qu’ils sont d’usage courant, un autiste ne comprendra pas les pictogrammes de toilettes avec un homme ou une femme. Pour lui, c’est juste un homme ou une femme. Rien n’indique qu’il s’agit de toilettes dans le pictogramme en lui-même. Ça laisse à réfléchir sur les pictogrammes qu’on utilise sur nos sites (et ça rejoint l’autre excellente conférence de Sébastien Desbenoit sur l’utilisation des pictos).

L’autisme est un sujet que je connais peu, mais qui m’attire beaucoup. En début d’année, j’étais tombé sur cet article intitulé « Attention to Detail » qui m’avait particulièrement marqué (et il se base sur des exemples de Toy Story et Plants vs Zombies, donc allez le lire, vraiment).

Il y a une société appelée Specialist People Foundation qui traite abondamment des problèmes dans ce domaine. Elle emploie des personnes atteintes d’autismes et autres troubles similaires, et s’appuie sur la différente nature de perception de ses employés pour s’attaquer à une variété de problèmes. J’aime beaucoup de chose à propos de cette organisation, mais je pense que le plus impressionnant est comment ils ont efficacement créé une force de quelque chose qui est perçue comme une faiblesse.

« Nos consultants ont une passion pour le détail sans égal, et apportent des compétences uniques à des tâches pour lesquelles les employés de la plupart des sociétés ont moins de motivation à réaliser, laissant ainsi plus de places à des erreurs. Les caractéristiques uniques de l’autisme font que nos consultants apprécient vraiment des tâches que la plupart des employés trouvent ennuyeuses, répétitives ou difficiles dues au niveau de détail et de concentration requis.« 

En attendant la vidéo de Paris Web, vous pouvez consulter ses slides, ou regarder la vidéo de sa conférence donnée l’année dernière à Web-In à Montréal.

Suite à Paris Web la semaine dernière, j’avais très envie de vous parler de la conférence de Jake Archibald : Application cache is a douchebag. J’avais vu passer les slides de sa conférence en début d’année et j’avais trouvé ça plutôt rigolo. J’avais tort. C’est carrément excellent.

Jake Archibald prend un sujet en apparence assez simple, le cache d’application en HTML5, et explique en détails à quel point en pratique c’est complexe. Et le tout en enchaînant des blagues à un rythme soutenu tout au long de sa conférence. A tel point que Jake Archibald ferait passer Le comte de Bouderbala pour Anne Roumanoff.

Voici comment sa conférence débute.

A l’époque des modems 56k, on utilisait seulement Internet pour des courtes durées. Vous vous connectiez, vous vérifiez vos e-mails, et puis vous partiez. Mais maintenant on est presque toujours connecté. Et ça transforme le fait de ne pas avoir de connexion en un gros problème. Ceux qui comme moi doivent utiliser une connexion à l’étranger savent de quoi je parle. Quand je me connecte depuis l’étranger, je me sens comme un accro au jeu. A chaque fois que je me connecte, je sais que je dépense de l’argent. Mais je ne peux pas m’en empêcher. Je dois savoir ce qu’Internet dit sur mon dos ou ce qu’il se passe. Mon téléphone émets un petit son quand j’utilise des données en 3G depuis l’étranger. Mais je n’en ai pas vraiment besoin car j’arrive presque à entendre les bouchons de Champagne sauter à chaque fois que j’utilise un méga-octet.

Et ma propre dépendance me dégoûte vraiment. Il y a un moment, là où je travaillais, je devais aller faire la grosse commission aux toilettes. Il y avait cinq cabinets à l’intérieur. Malheureusement, les quatre premiers étaient occupés. En général ce n’est pas grave, je n’ai besoin que d’un cabinet. Mais je savais par mes expériences passées que le Wi-fi du bureau n’allait que jusqu’au quatrième.

J’y ai réfléchi un instant et je me suis dit : « Non. Je trouve cela totalement inacceptable. » Et j’ai fait demi-tour et je suis retourné à mon bureau et j’ai attendu.

Je suis devenu quelqu’un qui a besoin d’une connexion Internet pour aller faire caca.

Et c’est ainsi que Jake Archibald nous emmène dans les méandres du fonctionnement du cache d’application, en personnifiant cette spécification, et en la présentant comme un trou-du-cul (ou plus précisémment un « douchebag« ). Le genre de personne qui dirait « I’m going to turn your offline user experience from sucks-ass… to success !« .

J’étais mort de rire quand Jake expliquait qu’il ne faut surtout jamais changer le nom de fichier de manifeste. En faisant ça, vous rentrez dans une boucle infinie ou vos anciens utilisateurs ne recevront plus jamais aucune mise à jour.

J’ai fait ça sur Sprite Cow de façon totalement idiote. Et j’ai mis 30 minutes à me rendre compte de ce que j’avais fait et de pouvoir le corriger. D’après Google Analytics, 20 personnes ont visité le site pendant cette période. Ces 20 utilisateurs ne recevront plus jamais la moindre mise à jour du site. Jamais, jamais.

Ils vivent maintenant la vie de développeurs Drupal. Tous les autres s’amusent à faire des trucs nouveaux super cools, et eux sont coincés avec la vieille même merde.

Vous l’aurez compris, je vous recommande vraiment de voir cette conférence. Si la vidéo de Paris Web n’est pas encore en ligne, vous pourrez en trouver quelques unes dans d’autres événements, comme celle-ci à Mobilism 2012. Les slides de sa conférence sont eux déjà disponible sur le site de Paris Web. Et vous pouvez également lire son article du même nom chez A List Apart publié en mai dernier.

La semaine dernière, j’ai eu la chance d’assister aux conférences de Paris Web. Je vais essayer de revenir cette semaine sur les conférences qui m’ont le plus marqué. L’une des principales têtes d’affiche était Mike Monteiro, avec sa conférence intitulée How Designers Destroyed the World.

J’avais découvert Mike Monteiro via sa conférence « Fuck you, pay me« , puis via ses podcasts sur Mule Radio Syndicate, ou encore son travail via sa société Mule Design Studio sur AllThingsD ou Evening Edition, et en avril dernier son livre « Design Is a Job » (horriblement traduit en français en « Métier web designer« ).

Comme le nom de sa conférence l’indique, Mike Monteiro nous raconte comment les designers ont détruit le monde. Comment les designers ont détruit le monde en se préoccupant de projets futiles plutôt que de s’attarder sur des choses qui comptent vraiment. A-t-on vraiment besoin de plus de 60 projets de pochettes pour iPad sur Kickstarter ? A-t-on vraiment besoin de cette veste imaginée par des étudiants du MIT qui se gonfle quand on reçoit un J’aime sur Facebook ?

Mike tourne ensuite toute sa conférence autour d’un exemple concret de mauvais design qui a ruiné la vie d’un être humain. A cause des préférences incompréhensibles sur la vie privée de Facebook, Bobbi Taylor a révélé malgré elle son homosexualité, jusqu’alors tenue secrète, à son père. Problème : son père est un trou du cul et l’a menacée de la renier et s’est mis à insulter les gens de sa chorale gaie sur Facebook. Comme le dit Mike, « Je suis père d’un garçon, et ceci n’est pas une façon de traiter vos enfants ». Vous pouvez lire l’article original du Wall Street Journal ou en français sur les blogs du Monde.

Mike enchaîne alors les conseils pour éviter de se retrouver dans une telle situation. « Décide d’être le connard qui va faire bouger les choses. Personne ne te donnera la permission. » (piqué chez Les Intégristes). Et surtout : si vous n’êtes pas d’accord avec ce qu’on vous demande de faire, dites non. Quittez votre boulot. Mais arrêtez de faire du mauvais travail.

« You are responsible for the work you put into the world » est à mon avis la phrase qui résume le mieux sa conférence (thème qu’on retrouve largement dans son livre).

Ce que j’ai particulièrement aimé, c’est que cela ne concerne vraiment pas que les designers au sens graphique du terme. Cela concerne tous les créateurs. Les développeurs, les intégrateurs, les entrepreneurs, les chefs de projet. Si vous créez quelque chose, que ce soit une affiche, un site web, un article sur votre blog, une vidéo sur Youtube, vous êtes responsable de l’impact que cela aura sur les gens.

Reste que certains conseils de Mike sont vraiment propres à la culture américaine, et ça s’est senti pendant les questions-réponses. Aux États-Unis, vous pouvez quitter votre boulot un lundi soir et trouver un autre travail le mardi matin, comme si de rien n’était. En France, on préfère vous garder deux mois en préavis au cas où, même si vous avez manifestement montré votre désintérêt dans votre boîte en démissionnant.

Ça n’en reste pas moins une très bonne conférence, et un très bon moment. L’ambiance dans la salle était électrique, presque religieuse. Alors oui Mike Monteiro lisait son texte sur son écran. Oui, il utilise l’effet de fumée de Keynote dans ses slides. Ça n’en reste pas moins un très bon spectacle avec quelques bonnes idées à retenir et à mettre en pratique.

En attendant que la vidéo de la conférence ne soit en ligne (si on en croit les années précédentes, ce ne sera pas avant avril prochain), je vous recommande vraiment le livre « Design is a job« . Je vous invite également à voir sa conférence « What Clients Don’t Know (… And Why It’s Your Fault) » donnée au TYPO Talks en mai dernier, où Mike raconte comment il s’est acheté un vélo, et comment éduquer les clients en leur expliquant notre travail.