La fascination pour le pire

Comme beaucoup de designers dont le travail est de créer de bonnes interfaces, je suis fasciné par l’extrême inverse : des interfaces monstrueusement mauvaises.

Il y a les interfaces frontalement horribles, comme cet outil de maintenance pour un distributeur de billet.

Il y a les interfaces 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 application qui ne suit pas des raccourcis universels et basiques (par exemple CTRL+A pour tout sélectionner). On parle d’une application fournie avec un utilitaire pour la forcer à quitter quand les choses tournent mal. Une application suicidaire.

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électeur de numéro de téléphone.

Des gens sur Reddit ont remis ça, autour d’un variateur de volume. Magnifique et totalement pataphysique.

Il y aussi une expérimentation autour du choix des cookies.

Et enfin, le petit dernier : un formulaire absolument atroce. Ce n’est plus un dark pattern, c’est un trou noir.

Les points communs entre tout ça ? Le meilleur des worst practices, une connaissance fine des habitudes des internautes pour s’en écarter le plus, des interfaces possédées, ayant leur vie propre ou luttant activement contre l’utilisateur, un succès toujours techniquement possible mais avec des probabilités infimes, un humour noir auto‐référencé… J’en passe.

Pourquoi cette fascination pour le pire ? Déjà, elle n’est pas limitée aux interfaces. Il y a bien des gens se consacrant à trouver l’algorithme le plus inefficace possible et des communautés de fans de nanar.

Cependant, voici quelques hypothèses sommaires :

  • Catharsis : on se purge de tous les travaux peu glorieux dont on est responsable.
  • Expertise : investiguer le pire permet par contraste de mieux comprendre le meilleur et de prendre consciene des mécaniques cognitives à l’oeuvre chez l’utilisateur.
  • Pédagogie : ce peut être une bonne technique d’animation, comme le suggèrent Jared Spool ou Akiani.
  • Prise de recul : après tout, qu’est-ce qu’une bonne interface ? 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 designer comme hôte – Charles Eames, 1972.

Le designer comme traducteur, performeur ou réalisateur — Mickael Rock, 1996.

Le designer comme dramaturge – Brenda Laurel, 1991.

Le designer comme ventriloquiste – Hutchins, 1987 (alerte mauvais PDF) :

The metaphor of user and computer engaged in a conversation with each other or carrying on a dialogue about the task at hand is the most popular of the mode of interaction metaphors for human computer interfaces.

Voir aussi :

Vous n’avez pas le monopole du design.

Le Tao du design web (2000).

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

Twitter est un terrain d’expérimentations intéressant pour les créateurs d’applications. Non parce que la plateforme permet des travaux révolutionnaires, mais au contraire parce qu’elle est limitée en complexité et encadré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 interdictions.

C’est aussi une bonne illustration d’une idée simple mais fondamentale en architecture de l’information : il n’y a pas qu’une manière d’organiser le contenu d’un service. Pour commencer, tout le monde n’est pas d’accord sur les concepts de base : rédiger, mentions, message privé, favoris, recherche, listes, abonnements, abonnés, activité, découverte, brouillon…

Seule une poignée de ces concepts est retenu pour figurer dans la navigation globale. Chaque application (y compris les versions officielles) fait des choix différents :

Twittelator
Twittelator pour iPad

Les contraintes de place et les particularités de l’OS entrent aussi en jeu mais n’expliquent pas tout. Par exemple, la refonte de Twitter.com de 2011 a été pas mal critiquée pour avoir relégué l’accès aux messages privés dans un sous‐menu et créé un onglet « découverte ». C’était une stratégie consciente pour privilégier les conversations publiques et les suggestions de contenu, pas seulement une question d’alléger l’interface.

Twitter pour MacAutre exemple : tous les clients officiels choisissent d’enfouir les favoris dans un sous‐menu du profil, à trois clics de profondeur. C’est aussi le cas sur Mac, alors que la navigation globale n’est pas vraiment bondée. Le choix se défend mais signale que pour eux, les favoris sont loin d’être une fonction essentielle.

Je n’ai pas encore parlé de la timeline. Tout s’articule autour de cette vue chronologie, mais là aussi on peut l’interpréter de diverses manières. La première version de Twitter mettait au même plan la chronologie publique et celle de l’utilisateur, vu qu’à l’époque le volume global de messages était faible. Quant à Tweetbot pour iPad, il permet de basculer entre la chronologie principale et les listes de l’utilisateur, si bien que, d’une certaine manière, celles‐ci deviennent le concept premier. La chronologie n’est plus qu’une liste parmi d’autres.

Twitter en 2006
Twitter en 2006

Citons également toute les expérimentations autour des conversations, qui contribuent à complexifier la timeline et à aller au‐delà d’une simple présentation anté‐chronologique.

Le responsive design ailleurs que sur le web

Les applications natives mobiles, sur Android (et Apple depuis peu) ont accès à des fonctions responsive, mais sur desktop la pratique est moins fréquente. Non seulement les interfaces ont rarement des agencements 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 redimensionnées. Certains logiciels bloquent également la largeur minimale de la fenêtre, parfois drastiquement. C’est dommage, car ce serait l’occasion de mieux prendre en compte les petits écrans (cf. par exemple les distributions de Linux visant spécifiquement les notetbooks) et toutes les manières d’utiliser un OS fenêtré.

Il y a évidemment des contre‐exemples : en mode album, iTunes ajuste le nombre de colonnes et la taille des jaquettes. Depuis des années, Microsoft adapte intelligemment 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 pourtant pas fréquent. Il y a évidemment de bonnes raisons pour ces limitations. D’une, dans la plupart des cas on a affaire à un viewport dont le contenu est par définition fixe (exemple : une page Word). On peut alors seulement jouer sur l’UI (comme dans l’exemple d’Office). De deux, on retombe sur le grand problème du « device‐agnostic responsive design » (concevoir pour une largeur donnée, sans préjuger de l’appareil utilisé) : il est difficile de prédire les préférences des gens. Si je redimensionne la fenêtre, serais‐je content d’avoir un agencement adapté et sans scroll horizontal, ou au contraire énervé qu’on m’impose quelque chose ? Suivant les cas et les raisons du redimensionnement, la réponse varie.

La solution la plus utilisée dans les logiciels de productivité un peu complexes, c’est de laisser l’utilisateur personnaliser les différentes palettes, barres et panneaux d’interface comme il l’entend. Par exemple, Photoshop permet de créer différents « espaces de travail », c’est-à-dire différents agencements que l’utilisateur pourra activer comme il lui sied.

Jusqu’ici j’ai surtout parlé du cas assez restreint où l’utilisateur redimensionne sa fenêtre. Le problème du responsive se pose de manière peut‐être plus aiguë si l’on veut créer des services dans l’écosystème Windows. Microsoft promet une plateforme unifiée où le développement à travers les OS sera unique, ou en tout cas facilité. 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 fondations, aussi bien dans le design que dans la technique. Cela pose la question de la convergence des différentes applications : à quel point doivent‐elles être semblables, faut‐il un processus de conception unique, etc.

Methodes Agile et conception d’objets

Un article intéressant d’Internet Actu sur l’application des méthodes Agile au génie industriel. Quelques remarques :

  • Cela fait fait beaucoup 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é extremement lourdes, il vaut mieux itérer souvent. Cela permet d’abaisser les coûts et, paradoxalement, d’augmenter à terme la fiabilité des vols. Cf. cette déclaration : « I want to make mistakes on a small scale and not a large one » (tirée de cet entretien), ou encore cet article décrivant l’insistance sur la simplicité dans la conception de la fusée.
  • On peut rappeler que beaucoup 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 perspective : le totoytisme / lean manufacturing 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 particulièrement au développement de logiciel. 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 utilisateurs et de déploiement, mais c’est possible, et toujours plus facile que de vendre un nouveau modèle de voiture. Il serait donc intéressant de voir les problèmes particuliers que pose l’application des méthodes Agile à la conception et à la vente de biens. Pour une discussion sur une possible montée en force des startups de hardware, voir ici.