La fascination pour le pire

Comme beau­coup de desi­gners dont le travail est de créer de bonnes inter­faces, je suis fasciné par l’extrême inverse : des inter­faces mons­trueu­se­ment mauvaises.

Il y a les inter­faces fron­ta­le­ment horribles, comme cet outil de main­te­nance pour un distri­bu­teur de billet.

Il y a les inter­faces qu’il faut avoir utilisé pour comprendre. Prenez Lotus Notes : des analyses et des sites entiers sont dédiés à sa nullité. On parle d’une appli­ca­tion qui ne suit pas des raccourcis univer­sels et basiques (par exemple CTRL+A pour tout sélec­tionner). On parle d’une appli­ca­tion fournie avec un utili­taire pour la forcer à quitter quand les choses tournent mal. Une appli­ca­tion suici­daire.

Mais pour aller au fond de la nullité et creuser encore, il faut la créer soi-même.

Il y a ce défi collectif sur Reddit pour créer le pire sélec­teur de numéro de télé­phone.

Des gens sur Reddit ont remis ça, autour d’un varia­teur de volume. Magnifique et tota­le­ment pata­phy­sique.

Il y aussi une expé­ri­men­ta­tion autour du choix des cookies.

Et enfin, le petit dernier : un formu­laire abso­lu­ment atroce. Ce n’est plus un dark pattern, c’est un trou noir.

Les points communs entre tout ça ? Le meilleur des worst prac­tices, une connais­sance fine des habi­tudes des inter­nautes pour s’en écarter le plus, des inter­faces possé­dées, ayant leur vie propre ou luttant acti­ve­ment contre l’uti­li­sa­teur, un succès toujours tech­ni­que­ment possible mais avec des proba­bi­lités infimes, un humour noir auto-référencé… J’en passe.

Pourquoi cette fasci­na­tion pour le pire ? Déjà, elle n’est pas limitée aux inter­faces. Il y a bien des gens se consa­crant à trouver l’al­go­rithme le plus inef­fi­cace possible et des commu­nautés de fans de nanar.

Cependant, voici quelques hypo­thèses sommaires :

  • Catharsis : on se purge de tous les travaux peu glorieux dont on est respon­sable.
  • Expertise : inves­ti­guer le pire permet par contraste de mieux comprendre le meilleur et de prendre consciene des méca­niques cogni­tives à l’oeuvre chez l’uti­li­sa­teur.
  • Pédagogie : ce peut être une bonne tech­nique d’ani­ma­tion, comme le suggèrent Jared Spool ou Akiani.
  • Prise de recul : après tout, qu’est-ce qu’une bonne inter­face ? Quelle est la limite entre le défi ludique et la corvée ?

Six métaphores plus modestes qu’il n’y parait pour le rôle du designer

Le desi­gner comme hôte – Charles Eames, 1972.

Le desi­gner comme traduc­teur, perfor­meur ou réali­sa­teur — Mickael Rock, 1996.

Le desi­gner comme drama­turge – Brenda Laurel, 1991.

Le desi­gner comme ventri­lo­quiste – Hutchins, 1987 (alerte mauvais PDF) :

The meta­phor of user and computer engaged in a conver­sa­tion with each other or carrying on a dialogue about the task at hand is the most popular of the mode of inter­ac­tion meta­phors for human computer inter­faces.

Voir aussi :

Vous n’avez pas le mono­pole du design.

Le Tao du design web (2000).

L’architecture de l’information expliquée avec Twitter

Twitter est un terrain d’ex­pé­ri­men­ta­tions inté­res­sant pour les créa­teurs d’ap­pli­ca­tions. Non parce que la plate­forme permet des travaux révo­lu­tion­naires, mais au contraire parce qu’elle est limitée en complexité et enca­drée par des règles assez strictes. Chacun fait de son mieux à partir des mêmes données, des mêmes concepts de base, des mêmes inter­dic­tions.

C’est aussi une bonne illus­tra­tion d’une idée simple mais fonda­men­tale en archi­tec­ture de l’in­for­ma­tion : il n’y a pas qu’une manière d’or­ga­niser le contenu d’un service. Pour commencer, tout le monde n’est pas d’ac­cord sur les concepts de base : rédiger, mentions, message privé, favoris, recherche, listes, abon­ne­ments, abonnés, acti­vité, décou­verte, brouillon…

Seule une poignée de ces concepts est retenu pour figurer dans la navi­ga­tion globale. Chaque appli­ca­tion (y compris les versions offi­cielles) fait des choix diffé­rents :

twitter2twitter1

Twittelator
Twittelator pour iPad

Les contraintes de place et les parti­cu­la­rités de l’OS entrent aussi en jeu mais n’ex­pliquent pas tout. Par exemple, la refonte de Twitter.com de 2011 a été pas mal criti­quée pour avoir relégué l’accès aux messages privés dans un sous-menu et créé un onglet « décou­verte ». C’était une stra­tégie consciente pour privi­lé­gier les conver­sa­tions publiques et les sugges­tions de contenu, pas seule­ment une ques­tion d’al­léger l’in­ter­face.

Twitter pour MacAutre exemple : tous les clients offi­ciels choi­sissent d’en­fouir les favoris dans un sous-menu du profil, à trois clics de profon­deur. C’est aussi le cas sur Mac, alors que la navi­ga­tion globale n’est pas vrai­ment bondée. Le choix se défend mais signale que pour eux, les favoris sont loin d’être une fonc­tion essen­tielle.

Je n’ai pas encore parlé de la time­line. Tout s’ar­ti­cule autour de cette vue chro­no­logie, mais là aussi on peut l’in­ter­préter de diverses manières. La première version de Twitter mettait au même plan la chro­no­logie publique et celle de l’uti­li­sa­teur, vu qu’à l’époque le volume global de messages était faible. Quant à Tweetbot pour iPad, il permet de basculer entre la chro­no­logie prin­ci­pale et les listes de l’uti­li­sa­teur, si bien que, d’une certaine manière, celles-ci deviennent le concept premier. La chro­no­logie n’est plus qu’une liste parmi d’autres.

Twitter en 2006
Twitter en 2006

Citons égale­ment toute les expé­ri­men­ta­tions autour des conver­sa­tions, qui contri­buent à complexi­fier la time­line et à aller au-delà d’une simple présen­ta­tion anté-chronologique.

Le responsive design ailleurs que sur le web

Les appli­ca­tions natives mobiles, sur Android (et Apple depuis peu) ont accès à des fonc­tions respon­sive, mais sur desktop la pratique est moins fréquente. Non seule­ment les inter­faces ont rare­ment des agen­ce­ments diffé­rents selon la taille de la fenêtre, mais en plus elles ne sont pas toujours fluides, c’est-à-dire que tailles et marges des éléments ne sont pas redi­men­sion­nées. Certains logi­ciels bloquent égale­ment la largeur mini­male de la fenêtre, parfois dras­ti­que­ment. C’est dommage, car ce serait l’oc­ca­sion de mieux prendre en compte les petits écrans (cf. par exemple les distri­bu­tions de Linux visant spéci­fi­que­ment les notet­books) et toutes les manières d’uti­liser un OS fenêtré.

Il y a évidem­ment des contre-exemples : en mode album, iTunes ajuste le nombre de colonnes et la taille des jaquettes. Depuis des années, Microsoft adapte intel­li­gem­ment son fameux « ribbon », avec un grand nombre de points de rupture au fur et à mesure qu’on réduit la fenêtre.

ribbon microsoft word en responsive design

Dans mon expé­rience, ce n’est pour­tant pas fréquent. Il y a évidem­ment de bonnes raisons pour ces limi­ta­tions. D’une, dans la plupart des cas on a affaire à un view­port dont le contenu est par défi­ni­tion fixe (exemple : une page Word). On peut alors seule­ment jouer sur l’UI (comme dans l’exemple d’Office). De deux, on retombe sur le grand problème du « device-agnostic respon­sive design » (conce­voir pour une largeur donnée, sans préjuger de l’ap­pa­reil utilisé) : il est diffi­cile de prédire les préfé­rences des gens. Si je redi­men­sionne la fenêtre, serais-je content d’avoir un agen­ce­ment adapté et sans scroll hori­zontal, ou au contraire énervé qu’on m’im­pose quelque chose ? Suivant les cas et les raisons du redi­men­sion­ne­ment, la réponse varie.

La solu­tion la plus utilisée dans les logi­ciels de produc­ti­vité un peu complexes, c’est de laisser l’uti­li­sa­teur person­na­liser les diffé­rentes palettes, barres et panneaux d’interface comme il l’en­tend. Par exemple, Photoshop permet de créer diffé­rents « espaces de travail », c’est-à-dire diffé­rents agen­ce­ments que l’uti­li­sa­teur pourra activer comme il lui sied.

Jusqu’ici j’ai surtout parlé du cas assez restreint où l’uti­li­sa­teur redi­men­sionne sa fenêtre. Le problème du respon­sive se pose de manière peut-être plus aiguë si l’on veut créer des services dans l’éco­sys­tème Windows. Microsoft promet une plate­forme unifiée où le déve­lop­pe­ment à travers les OS sera unique, ou en tout cas faci­lité. Que Microsoft tienne sa promesse et que ce soit une bonne idée ou non, il reste que Windows, (feu ?) Windows RT et Windows Phone sont de plus en plus bâtis sur les mêmes fonda­tions, aussi bien dans le design que dans la tech­nique. Cela pose la ques­tion de la conver­gence des diffé­rentes appli­ca­tions : à quel point doivent-elles être semblables, faut-il un processus de concep­tion unique, etc.

Methodes Agile et conception d’objets

Un article inté­res­sant d’Internet Actu sur l’application des méthodes Agile au génie indus­triel. Quelques remarques :

  • Cela fait fait beau­coup penser à l’approche de Space X pour faire avancer l’exploration spatiale privée : au lieu de lancer peu de fusées après des procé­dures de qualité extre­me­ment lourdes, il vaut mieux itérer souvent. Cela permet d’abaisser les coûts et, para­doxa­le­ment, d’augmenter à terme la fiabi­lité des vols. Cf. cette décla­ra­tion : « I want to make mistakes on a small scale and not a large one » (tirée de cet entre­tien), ou encore cet article décri­vant l’insistance sur la simpli­cité dans la concep­tion de la fusée.
  • On peut rappeler que beau­coup de termes et de concepts de la gestion de projet viennent à l’origine des BTP : cahier des charges, maitre d’œuvre, etc. La boucle est bouclée, en quelque sorte.
  • L’article manque un peu de mise en pers­pec­tive : le totoy­tisme / lean manu­fac­tu­ring et l’utilisation de kanban sont des pratiques établies dans l’industrie et n’ont pas attendu la mode de l’Agile.
  • Ceci étant, l’Agile se prête parti­cu­liè­re­ment au déve­lop­pe­ment de logi­ciel. Par exemple, Facebook peut mettre en place une nouvelle version de son site auprès de millions d’utilisateurs, sans qu’ils aient de mise a jour à faire. Cela pose des problèmes d’acceptation de la part des utili­sa­teurs et de déploie­ment, mais c’est possible, et toujours plus facile que de vendre un nouveau modèle de voiture. Il serait donc inté­res­sant de voir les problèmes parti­cu­liers que pose l’application des méthodes Agile à la concep­tion et à la vente de biens. Pour une discus­sion sur une possible montée en force des star­tups de hard­ware, voir ici.