Le déclin de la « usability » (2020)
(datagubbe.se)- Vers 1994–2012, les GUI de bureau partageaient de nombreuses règles communes même d’un système d’exploitation à l’autre, ce qui permettait aux utilisateurs expérimentés de s’adapter rapidement à un nouvel environnement, mais cette base s’est affaiblie ces dernières années
- Le paradigme de l’application unique, adapté aux petits écrans et à l’entrée tactile des smartphones, s’est déplacé vers le bureau, où il entre en conflit avec un mode d’usage à fenêtres multiples pensé pour le clavier et la souris de précision
- Dans les cas des applications Windows 10, de Slack, de Chrome, de Firefox 75, de QT5 et des applications Gnome, on voit se répéter des changements qui brouillent des concepts UI établis, comme les widgets de barre de titre, la megabar, les barres de défilement à masquage automatique ou la disparition de la barre de menus
- Les menus déroulants, une barre de titre claire, l’indication du focus de fenêtre, des boutons et des champs de saisie identifiables formaient un langage commun que l’on pouvait apprendre d’une plateforme à l’autre, mais des comportements différents selon les applications imposent un apprentissage séparé
- Il est difficile de justifier la remise en cause de concepts UI éprouvés au seul motif d’économiser de l’espace à l’écran, de l’inévitabilité du changement, des limites multiplateformes d’Electron ou du fait qu’il s’agit de logiciel gratuit ; les projets et entreprises influents ont besoin de critères de cohérence
Des règles communes affaiblies dans les GUI de bureau
- Vers 1994–2012, un utilisateur disposant de compétences informatiques raisonnables pouvait s’asseoir devant presque n’importe quelle GUI de système d’exploitation et s’adapter rapidement
- Windows, MacOS, CDE, OpenStep, OS/2, mais aussi des environnements comme Amiga, Atari ou BeOS, avaient davantage de points communs que de différences
- À l’époque, les fenêtres permettaient en général, via la barre de titre, de les déplacer, de les identifier et d’indiquer le focus d’entrée courant
- Les menus déroulants standardisés comme File, Edit, View ou Help facilitaient l’exploration des fonctions d’une nouvelle application et l’apprentissage des raccourcis
- Les boutons, champs de saisie et autres widgets étaient faciles à reconnaître comme éléments interactifs grâce à des indices visuels comme les biseaux 3D
- Certaines applications atypiques ne respectaient pas ces règles, mais dans les domaines fondamentaux, la plupart des logiciels partageaient les mêmes conventions
Le problème du paradigme smartphone transféré au bureau
- Sur des plateformes relativement nouvelles comme le smartphone, où les modes d’entrée et l’interaction avec l’écran diffèrent du bureau, un nouveau paradigme peut être nécessaire
- Le problème est la diffusion de ce paradigme vers le bureau, où l’on dispose d’un clavier et d’un contrôle de la souris au pixel près
- Combinés au flat design, les éléments UI ont tendance à devenir plus grands tout en étant plus difficiles à distinguer de la décoration ou du contenu
- Le design des applications de bureau évolue dans un sens qui affaiblit l’idée qu’on peut afficher plusieurs applis et fenêtres en même temps, et importe un mode d’usage à application unique inspiré du smartphone
- Le fait de contourner des conventions UI de bureau déjà ancrées comme une mémoire musculaire chez beaucoup d’utilisateurs entraîne une gêne encore plus forte
Gestion des fenêtres : la barre de titre n’est plus une zone réservée à la fenêtre
- Dans de nombreuses applications populaires de Windows 10, les barres de titre montrent un manque de cohérence frappant, alors même que les captures ont été faites à quelques minutes d’intervalle sur le même ordinateur
- Les six fenêtres indiquent toutes qu’elles sont actives, mais Outlook et Slack paraissent presque inactives, et dans les autres cas aussi, sauf
cmd.exe, la différence entre actif et inactif est très subtile - La plupart des barres de titre contiennent des icônes d’outils, des onglets, des menus déroulants ou une combinaison de ces éléments
- La largeur de la zone cliquable destinée aux opérations traditionnelles comme déplacer la fenêtre, gérer le focus ou la ramener au premier plan varie selon les applications
- Un utilisateur qui a appris que la barre de titre sert à manipuler la fenêtre peut facilement déclencher une fonction de l’application par inadvertance
- Certains éléments, comme le petit logo de Visual Studio Code, ressemblent à des icônes alors qu’ils ne sont en réalité que décoratifs
- Le fait que quatre des six applications soient des applications Microsoft montre que ce type de design irrégulier peut se diffuser comme un standard
- Dans la dernière version de Slack, la zone de redimensionnement par glisser sur la bordure supérieure et les coins, présente depuis Windows 2, a fortement rétréci
- La zone rouge représente les points restants pour redimensionner, la zone bleue les points permettant de déplacer la fenêtre
- Le reste de l’espace est occupé par une combinaison non standard de widgets
- Avec une mise à jour du 22 avril 2020, la version de bureau de Slack a commencé à afficher une barre de titre légèrement plus sombre pour les fenêtres inactives
UI des navigateurs : les infobulles et la barre d’adresse bousculent les concepts existants
- Chrome affiche une grande infobulle d’onglet immédiatement lorsqu’on survole un onglet avec la souris
- En général, les infobulles d’onglet des navigateurs apparaissent après un léger délai sous forme de petite infobulle flottante
- La nouvelle infobulle de Chrome apparaît sans délai et masque une grande zone de l’UI située en dessous
- L’utilité même de l’infobulle d’onglet peut être discutée, mais sous cette forme elle est considérée comme un élément distrayant et inutile
- Le changement de la barre URL dans Firefox 75 est appelé megabar
- Elle surgit à des moments difficiles à prévoir
- Il est difficile de la désactiver, et elle recouvre la barre de favoris en dessous
- Le champ de saisie de texte est un élément UI ancien dont le concept de base est resté stable au moins depuis le début des années 1980, et la megabar en modifie fortement le comportement
Barres de défilement : masquage et faible contraste compliquent le repérage de la position
- Les barres de défilement à masquage automatique peuvent être utiles sur smartphone pour libérer un peu d’espace sur un petit écran, tout en permettant de faire défiler directement avec le pouce
- Sur le bureau, la barre de défilement sert de indicateur d’état montrant la position actuelle dans le contenu
- L’utilisateur peut connaître sa position sans interrompre ce qu’il fait pour reprendre la souris
- On peut aussi voir la position d’une fenêtre qui n’a pas le focus
- Dans un lecteur de fichier log en suivi continu ou une invite de commande affichant un flux de debug, la barre de défilement aide à vérifier si l’on est bien sur la sortie la plus récente
- Avec une barre de défilement à masquage automatique, cette vérification devient plus difficile et oblige à recourir à d’autres moyens moins clairs ou plus contraignants
- Le rendu par défaut des barres de défilement de QT5 rend difficile la distinction entre la poignée et la piste, avec un contraste très faible
- Même en sachant que la partie légèrement plus claire est la poignée, les mauvais clics sont fréquents
- Sur les écrans de vieux ordinateurs portables bon marché, il peut être difficile de distinguer la poignée de la piste
- QT5 peut être configuré via des outils pour adopter une apparence plus traditionnelle, mais comme les nouveaux utilisateurs ont peu de chances de le savoir, l’apparence par défaut compte beaucoup
La barre de menus et l’incohérence des applications Gnome
- La barre de menus était un plus petit dénominateur commun dont le fonctionnement restait globalement similaire sous Windows, Mac et les systèmes de type Unix
- Le schéma traditionnel File, Edit, View servait de chemin standard pour explorer les fonctions d’une application, mais le design Gnome le remplace par autre chose
- Le menu hamburger peut être utile sur smartphone, mais sur un bureau à écran large, la nécessité de résoudre un manque d’espace horizontal est bien moindre
- Dans Gnome, le menu hamburger semble servir à contenir des actions UI qui ne sont placées nulle part ailleurs
- Dans le menu hamburger d’Evince, on trouve Open, Save, Print et Close
- Dans celui de Gnome-MPV, il n’y a ni Open ni Close, et pour ouvrir un fichier il faut cliquer sur le bouton à icône plus situé à gauche
- Le bouton d’icône d’application de Gnome-MPV contient les options preferences et quit, alors que celui d’Evince propose un autre menu
- Le manque de cohérence entre applications oblige l’utilisateur à apprendre des emplacements différents pour retrouver les mêmes fonctions
- Contrairement aux menus déroulants classiques ou à certains menus hamburger, il est difficile de savoir comment naviguer dans ces menus au clavier une fois ouverts
L’intégration de la barre de titre dans Gnome et les barres d’outils supplémentaires
- Les applications Gnome adoptent un nouveau paradigme consistant à intégrer la barre d’outils à la barre de titre de la fenêtre, institutionnalisant ainsi l’occupation de la barre de titre critiquée dans le cas des applications Windows
- Lorsqu’on utilise un autre gestionnaire de fenêtres, il peut y avoir un doublon apparent entre la barre de titre et le bouton de fermeture propre à l’application
- Comme il faut laisser au moins un peu d’espace pour déplacer la fenêtre, des widgets qui autrefois pouvaient tenir dans une barre d’outils sous la barre de titre se retrouvent relégués dans des zones qui s’ouvrent séparément
- La zone de recherche d’Evince est fournie sous forme de panneau qui se déplie séparément
- La barre d’outils d’annotation ne contient que deux icônes, mais il faut utiliser une icône distincte pour l’ouvrir
Réponses aux objections fréquentes
- L’idée selon laquelle « la technologie progresse et on ne peut pas empêcher le changement » tient davantage du cliché employé sans véritable argumentation
- Changer le design d’une UI n’est pas une force de la nature, mais une décision humaine
- Le changement ne signifie pas automatiquement amélioration ; le but doit être l’amélioration, pas le changement en soi
- L’objection du « rester dans le passé » peut être juste dans le sens où l’auteur préfère des éléments UI traditionnels, mais cela ne signifie pas que tous les bureaux modernes doivent ressembler à Windows 95 ou à CDE
- Il existe d’autres voies pour améliorer l’apparence et le ressenti d’une UI sans casser les concepts de base
- À l’objection selon laquelle les applications Electron ne peuvent pas suivre les standards d’une plateforme unique, la réponse est qu’une application multiplateforme devrait au contraire respecter des paradigmes transposables entre plateformes communes
- Les menus déroulants, une barre de titre propre, ou une indication claire du focus de fenêtre ne sont pas des concepts difficiles à mettre en œuvre
- Les frameworks multiplateformes devraient rendre ces concepts faciles à implémenter et difficiles à contourner
- À l’objection selon laquelle il ne faudrait pas se plaindre des logiciels gratuits, les grands projets FOSS comme Gnome et KDE influencent fortement utilisateurs, designers et programmeurs, au même titre que Microsoft ou Google
- Un projet censé montrer l’exemple devrait être soumis aux critères correspondants
Économie d’espace à l’écran et complexité UI
- Ajouter des éléments dans la barre de titre peut certes économiser un peu d’espace à l’écran
- Mais l’espace écran n’est plus vraiment un problème majeur
- Une personne qui utilise beaucoup son ordinateur peut acheter un grand moniteur 2560x1440 pour environ 200 dollars US
- Même les ordinateurs portables les moins chers offrent généralement au minimum une définition de 1366x768
- Le problème d’espace à l’écran est plutôt aggravé par les larges marges du design UI actuel
- Il existe des cas où une simple boîte de dialogue donne l’impression d’être une application plein écran
- Pour quelqu’un qui code toute la journée sur un portable 13 pouces, il faudrait selon l’auteur se préoccuper davantage de la santé du dos, du cou, des mains et des épaules que de quelques pixels
- Il est vrai que la conception UI est difficile et qu’on ne peut pas satisfaire tout le monde en permanence, mais cela ne justifie pas de casser délibérément des concepts UI fondamentaux éprouvés depuis des décennies
- Si chaque application impose d’apprendre séparément les détails de sa décoration de fenêtre et de son mode de manipulation, l’utilisateur dépense sans cesse du temps et de l’énergie à interpréter ces différences répétées
1 commentaires
Avis de Hacker News
Ces dix dernières années environ, j’ai eu l’impression de me battre en permanence avec les équipes UI/UX, et le fond du problème me semble être que les critères de conception sont passés des outils pour professionnels aux paradigmes de consommation de contenu grand public.
Il y a 20 ans, les logiciels étaient généralement des outils pour professionnels, mais aujourd’hui, en volume d’utilisation, ce sont les logiciels grand public comme la vidéo et les réseaux sociaux qui dominent. Les designers essaient d’appliquer les règles de consommation de contenu à des produits destinés à « accomplir une tâche ».
Exemple typique : au nom d’une interface « plus épurée et intuitive », on cache des outils visibles derrière un menu à trois points, transformant un clic en deux clics, que l’utilisateur de l’outil doit répéter des centaines de fois par jour. Les tableaux n’affichent plus que 10 éléments et 4 détails dans un espace où l’on voyait auparavant 20 éléments et 6 à 8 détails ; les tableaux de bord affichent 4 graphiques au lieu de 10 ; les menus occupent 10 à 20 % du haut de l’application ; les titres H1 deviennent énormes.
J’ai une tante qui déplace sans cesse ses meubles non pas parce qu’elle a trouvé une meilleure disposition, mais parce qu’elle s’ennuie de l’actuelle ; j’ai l’impression que cette tendance est fréquente chez les PM et les personnes côté UX. Ajouter une quatrième vue de tableau à un produit en disant qu’il faut « utiliser un style complètement différent » ne le rend pas meilleur. Depuis le COVID, je fais chaque semaine un Google Meet avec des amis ; presque à chaque fois, quelque chose a changé, et récemment le flux de demande de participation a encore changé, sans que ce soit devenu meilleur.
À un moment donné, on finit simplement par l’accepter et par attendre que la meilleure approche devienne la nouvelle bonne pratique.
Mais le mouvement qui cherchait à corriger le problème initial semble avoir continué à s’amplifier, sans que personne ne remarque qu’on était déjà allé trop loin. Ou peut-être que de nouveaux designers, qui ne connaissent pas le contexte des anciennes UI, appliquent à des UI déjà corrigées le même remède qu’autrefois.
On a l’impression que le pendule n’est pas en train de revenir, mais qu’il a atteint la vitesse de libération.
Chaque bouton et chaque barre de défilement à l’écran leur répète sans cesse « voici quelque chose que tu peux faire mais que tu n’as pas encore fait », et cela devient si agaçant et si explicite pour le designer qu’il finit par vouloir tout supprimer.
Je me demande quand l’UI reviendra vers la dose de skeuomorphisme nécessaire à l’utilisateur moyen. Même le paradigme des liens web semble trop difficile pour les personnes âgées ou peu expérimentées, et cela finira sans doute un jour par apparaître dans des données impossibles à ignorer.
Les PM et les responsables UX sont eux aussi payés pour travailler, et leur travail consiste à changer l’UI/UX. Si l’on vous payait pour maintenir un logiciel presque terminé, vous passeriez du temps à du refactoring ou à de petites corrections ; la différence, c’est que tout ce que nous faisons n’est pas visible pour l’utilisateur.
Peu importe ce que fait l’UX : il suffit de me permettre d’appuyer sur Ctrl-K et de taper les premières lettres de la commande que je veux.
En tant que designer UX qui conçoit des interfaces web, mobiles et associées depuis autour de 2000, je suis d’accord pour dire que le changement pour le changement crée beaucoup de problèmes d’utilisabilité.
Mais le problème plus important est que, parmi les personnes qui conçoivent réellement, les discussions professionnelles et les véritables analyses de conception ont presque disparu.
Beaucoup de designers avec qui je travaille n’ont ni le vocabulaire ni les connaissances pour expliquer, au sens large, ce qui rend quelque chose « utilisable », et manquent aussi de capacité à résoudre des problèmes subtils de conception d’interaction ou de présentation de l’information. Sans connaissance ni intérêt pour les heuristiques de base, ils ne savent même pas par où commencer.
Ils finissent donc par vivre dans Figma, à manipuler couleurs, formes et effets, puis à présenter quelques variantes de la même UI lors de « tests utilisateurs ». C’est devenu un culte de l’innovation « non technique », volontairement ignorant, qui a complètement perdu son objectif initial.
Dire que j’ai honte de mon métier n’est pas une exagération. Nous avons échoué de façon spectaculaire.
À l’époque, je pensais que nous ne faisions qu’entrevoir un univers que les designers UI/UX connaissaient bien mieux, mais ce n’est peut-être pas le cas.
Beaucoup reviennent à l’idée de rendre les choses « jolies », avec des recherches faibles et des questions étroites, au lieu de réfléchir au contexte, à l’écosystème et aux effets systémiques des décisions de conception.
J’ai quelques connaissances très basiques issues d’une introduction à la HCI et de bons designers, mais pas encore à un niveau technique ou formel.
En somme, ils investissent le minimum de travail intellectuel nécessaire pour être payés.
Je ne cherche pas à les accuser. Ils travaillent dans un domaine saturé et dépendent des caprices et des goûts de dirigeants qui privilégient l’attrait visuel ou le ressenti plutôt que l’utilisabilité.
Au final, c’est du marketing. Si les gens n’ont pas envie de l’utiliser, la facilité d’utilisation d’un produit ne compte pas tant que ça. Beaucoup d’industries fabriquent des objets très utilisables, comme l’armée, mais ils sont généralement simplement laids.
L’auteur disait manquer d’expérience avec macOS et donc suspendre son jugement, mais le même déclin s’y produit aussi. En particulier, Apple semble s’être entiché des effets de survol lents et des nuances de gris excessivement subtiles pour cacher des fonctionnalités
Probablement pour donner une impression de raffinement, mais cela nuit à la découvrabilité de l’interface. Même quand on a appris qu’il y a quelque chose derrière une animation au survol, on ne peut pas facilement le viser, car la zone cible réelle n’apparaît et ne s’active qu’une fois la souris déplacée exactement à cet endroit. L’app Music et le comportement des notifications sont particulièrement pénibles
Dans la barre de titre des fenêtres, on ne voit pas clairement non plus quelle zone peut être utilisée pour faire glisser. Je n’ai jamais compris pourquoi un pixel permet de déplacer la fenêtre, alors que le pixel juste en dessous, qui a exactement le même aspect, ne le permet pas
À mon avis, l’ergonomie de l’UI d’Apple n’a pas été un point fort depuis longtemps. Quand on doit utiliser à la fois des Mac et des PC, macOS est, à bien des égards, aussi horrible qu’un PC, voire pire
Ce qu’Apple fait bien, c’est l’ergonomie de l’intégration entre appareils dans tout son écosystème
Or macOS joue une animation poussive lors des changements d’écran. On ne peut pas la désactiver, et on ne peut choisir qu’entre deux variantes tout aussi lentes
Je ne vois aucune bonne raison de justifier ça. Je ne sais pas quel modèle utilisateur a pu mener à la conclusion que « quand on change de fenêtre, une animation lente est une bonne chose »
L’impression recto verso n’est pas prise en charge, il faut le faire à la main, et certaines apps impriment les pages en ordre inverse, ce qui oblige à les remettre dans le bon ordre
Pour que le
.du pavé numérique soit utilisé comme.et non comme,, il faut télécharger une app juste pour obtenir un comportement par défaut normalSi l’on n’utilise pas un clavier anglais, Alt+. ne fonctionne pas non plus dans le terminal
Pour lancer une app téléchargée, il faut l’exécuter, accepter l’échec, aller dans Réglages et sécurité, trouver l’app bloquée et l’autoriser. C’est pire que Windows Vista
Pour donner une permission à une app, il faut connaître le type d’autorisation, et on ne peut pas chercher par app. Et ça continue comme ça sans arrêt
Aujourd’hui encore, je passe beaucoup trop de temps à déchiffrer les icônes gris bleuté de la barre latérale du Finder
On est allé encore plus loin dans la dissimulation de la structure des fichiers, et même du concept de fichier. Demandez à des utilisateurs Windows ou Mac non techniques où leurs fichiers sont enregistrés, ils ne le savent pas. Demandez-leur si c’est dans le cloud, ils ne le savent pas non plus
Pire encore, comme pour l’UI, l’endroit où les apps stockent leurs données n’est pas cohérent d’une app à l’autre. Et n’oublions pas cette stupidité qui consiste à masquer les extensions de fichiers
Windows ment même aux utilisateurs non anglophones. Par exemple, en allemand, il indique que le répertoire personnel se trouve dans « Benutzer », alors qu’en réalité ce répertoire n’existe pas : il n’y a que « Users ». Les tentatives de cacher la complexité finissent par créer de la confusion et encore plus de complexité
Ça me rappelle un autre problème rencontré lors de mon premier poste iOS à temps plein. La description de l’app utilisait « button » et la traduction allemande était « Knopf », mais c’est tombé dans le filtre des mots interdits d’Apple. Sans doute parce que « Knopf » peut aussi traduire « knob », mais en allemand « Knopf » n’a pas la connotation sexuelle que peut avoir « knob » en anglais
Apple donne l’impression d’être l’acteur qui pousse le plus fort à s’éloigner du concept de « fichiers » pour aller vers du « contenu » que l’on déplace entre plusieurs apps. Mais chaque app a aussi un paradigme légèrement différent pour le partage, l’importation et l’exportation
Maintenant, il y a même l’app « Fichiers » pour iCloud Drive. Qu’est-ce que ça veut dire, et comment savoir si c’est sur mon téléphone ou si l’affichage ne fait que représenter ce qui est dans iCloud Drive ? Je ne sais pas si l’icône de nuage signifie que c’est téléchargé ou non, ni ce que signifient un gris un peu plus foncé et un gris un peu plus clair
Et ce, même si les utilisateurs les moins techniques savent ce qu’est une extension de fichier et comment elle fonctionne
Je ne sais vraiment pas ce que Microsoft fabrique
Une autre régression d’Explorer : autrefois, il y avait un petit signe « + » à côté des répertoires qui contenaient des éléments, et Microsoft l’a supprimé
Il n’apparaît désormais, sans raison, que lorsqu’on passe le curseur au-dessus du panneau de gauche. Ou bien ils ont peut-être encore régressé, en remplaçant le signe « + », universellement compris, par un triangle idiot
À ce stade, je n’arrive même plus à suivre les régressions
On a sacrifié l’utilisabilité sur desktop au nom de la compatibilité mobile, et pourtant beaucoup d’environnements n’ont toujours aucune présence sur mobile. Maintenant, par pitié, qu’on nous rende les barres de défilement
Une fois, un développeur et moi avons passé un temps fou à chercher un réglage, sans aucun indice indiquant qu’il y avait davantage de contenu et des cases à cocher en bas de la fenêtre. Avant l’arrivée des barres de défilement cachées, cela aurait évidemment été visible
Le problème, c’est que si le pointeur se trouve sur le panneau de navigation, là où il est presque toujours, la barre de défilement des autres panneaux est masquée. Sans l’indice visuel qu’est la barre de défilement, il n’y avait aucune raison de déplacer le pointeur pour découvrir qu’un autre panneau contenait davantage d’éléments. Désormais, on a aussi supprimé toutes les bordures, au point qu’on peut même ne plus savoir qu’il s’agit de panneaux distincts
Après avoir envoyé une capture d’écran au développeur et confirmé que j’utilisais bien la dernière version, il m’a répondu : « Faites défiler vers le bas ». Bien sûr, c’était moi l’idiot. /s
Comme sur mobile, il faut toucher au hasard tous les éléments d’UI pour comprendre leur fonctionnement, et les compétences ainsi acquises ne valent que pour une seule application précise. Taper, appuyer longuement, appuyer longuement pendant une durée différente, taper plus vite, appuyer partout, « googler », puis cette fois faire glisser depuis un endroit qui ne ressemble même pas à un élément d’UI
« La case est-elle cochée ? » n’a jamais été aussi ambigu que « l’interrupteur coulissant est-il activé ? ». Une case à cocher prend aussi moins de place à l’écran. Ici, on n’a optimisé ni l’espace ni la convivialité, seulement l’apparence
On pourrait même faire pire en l’aplatissant encore davantage, jusqu’à ce qu’il ressemble à deux rectangles. La zone sombre est-elle la partie de l’interrupteur ? Qui s’en soucie. Il suffit que ce soit propre et sans distraction. Pouvoir connaître l’état du commutateur me rendait sans doute trop distrait
Ce livre consacre des pages à dire qu’il faut éviter les modes, et explique pourquoi. Les choses à faire et à ne pas faire en matière d’UI, à la page 70, valent la peine d’être répétées
À faire : laisser autant que possible l’utilisateur contrôler l’apparence des objets, utiliser des verbes pour les commandes de menu qui déclenchent des actions, rendre les alertes explicites, et utiliser des contrôles et des éléments graphiques, pas seulement des commandes de menu
À ne pas faire : abuser des modes, imposer le clavier pour des tâches plus faciles à la souris, ou l’inverse, modifier de façon inattendue l’apparence de l’écran, notamment avec le défilement, redessiner inutilement les objets, ou créer ses propres menus avec les mêmes noms que les menus standard. Ce livre définissait About, File, Edit, ainsi que ce qui devait s’y trouver
Nous sommes arrivés dans un étrange minimum local où chaque application a sa propre UI à réponse unique, imposée sous la même forme à tous les utilisateurs. À l’inverse, dans des domaines comme le contrôle industriel, où une application associée à un équipement à 50 000 dollars est utilisée par une à trois personnes, on peut disposer une interface mobile responsive aussi facilement qu’un jeu de slides, et un tableau de bord personnalisé ne demande qu’un widget
Si le cloud fabriquait des chaussures, il y aurait des modèles séparés pour la pelouse et pour le béton, mais tous seraient de la même pointure : si vos pieds sont trop grands, il faudrait vous couper les orteils, et s’ils sont trop petits, vous devriez les remplir avec des implants
À propos des plaintes sur le défilement, il existe un principe propre au desktop qui devient évident quand on regarde d’anciennes UI de bureau : les contrôles ne défilent jamais, seul le contenu défile
Si les contrôles ne tiennent pas dans une fenêtre, on ne rend pas cette fenêtre défilable : on les répartit en onglets, ou on place les contrôles supplémentaires dans une fenêtre séparée ouverte par un bouton. Cela semble être un principe général, au moins sous Windows et macOS
Les cases à cocher sont bien meilleures, tant que le libellé n’est pas une double négation. Par exemple, les développeurs qui font en sorte que cocher une case désactive quelque chose mériteraient d’être fusillés à l’aube
Je ne sais même pas si le cercle qui glisse signifie activé ou désactivé, et dans la moitié des cas je n’arrive même pas à savoir lequel des deux états correspond à ce que je veux. Les doubles négations pullulent, les formulations sont bizarres, et il n’y a aucune indication de l’effet réel
Tout cela est complètement fou
On dit que des entreprises comme Google sont devenues de plus en plus obsédées récemment par les tests A/B, mais dans toute l’histoire de la recherche utilisateur, aucun test A/B n’a jamais correctement mesuré la rage intense qui jaillit chez les utilisateurs avancés lorsqu’un bouton est déplacé, quelle qu’en soit la raison
Les lecteurs de musique portables — autrefois les Walkman ou lecteurs MP3, aujourd’hui le domaine des DAP — sont ma plainte récurrente. Les lecteurs vendus actuellement ont une utilisabilité tellement catastrophique que je ne comprends pas qui peut avoir envie de les acheter.
Les bons produits ont disparu, évincés par l’association des services de streaming et des appareils Android. Il n’existe plus de lecteur léger et simple, avec une grande capacité, des boutons physiques et une bonne autonomie. Un truc qu’on peut mettre dans sa poche et avec lequel on peut courir sans se faire des bleus.
Un écran lisible, une structure de menus normale, un appareil qui lit les tags des fichiers et dans lequel on peut simplement glisser-déposer des playlists. Il y a clairement des gens qui veulent ça, mais les fabricants sortent d’énormes briques avec des molettes qui dépassent, des arêtes bizarres, d’immenses écrans tactiles qui dévorent la batterie et d’horribles variantes d’Android.
« Il a deux DAC ! » Vraiment ? Moi, je suis dans un bus avec des écouteurs, pas dans une salle d’écoute insonorisée avec des enceintes à 10 000 euros.
Les critiques abordent rarement l’aspect le plus important d’un lecteur de musique portable, et encensent plutôt l’odeur ou le goût de la musique comme des critiques de vin. Je plaisante à moitié. Plus un critique est réputé, plus il écrit de foutaises, et souvent on ne trouve même pas la moindre mention du poids ou des dimensions.
Et même quand ils les mentionnent, ils se trompent. Par exemple : « le Shanling Q1 est un appareil portable léger » — pas du tout. C’est une brique horrible, avec un OS médiocre, une mauvaise autonomie et des boutons beaucoup trop sensibles. Peu importe la qualité du son : si je ne peux pas y mettre de playlists, qu’il est lourd et que l’interface est exécrable au point de ne pas donner envie de l’utiliser, ça ne m’intéresse pas.
Il y a 13 ans, Rockbox sur le Sansa Clip+ était excellent. Si on pouvait simplement refaire ça avec la technologie d’aujourd’hui, je le choisirais plutôt que ces briques énormes et absurdement chères.
C’est vraiment triste de voir de mauvaises décisions de conception — UI, forme, écran tactile, etc. — ruiner du matériel tout à fait correct.
Après plusieurs heures, j’ai trouvé une solution utilisable. J’ai acheté un Hifi Walker H2 sur Amazon : l’UI est mal conçue, fautes de frappe comprises, mais le hardware est bon.
J’y ai installé RockBox et, avec un peu de personnalisation, ça a réglé le problème de l’UI calamiteuse. Le regret, c’est que RockBox ne prend pas en charge le Bluetooth ni l’USB DAC, ce qui peut poser problème si vous avez besoin de ces fonctions.
« Il faut économiser de l’espace à l’écran, donc… vérifie ses notes… on va mettre un bouton qui occupe tout l’écran. »
C’est toujours ce qui me gêne dans l’idée que « déplacer ça dans la barre de titre économise de l’espace à l’écran ».
Autre chose qui m’énerve ces temps-ci : beaucoup d’applications volent le focus plusieurs fois au démarrage. À cause de cet absurde vol de focus, trop de gens ont fini par poster leur mot de passe par erreur dans un chat d’équipe.
Quand iOS a introduit l’appui long, j’ai eu l’impression que c’était à peu près fini. On ne pouvait plus savoir ce que faisait un élément d’UI quand on appuyait dessus : il fallait tout tester en tapotant, et maintenant il faut aussi appuyer longuement pour déclencher d’autres actions.
Je ne peux pas passer mon temps à tapoter puis à appuyer longuement sur chaque élément pour découvrir les choses que je pense ou espère qu’une app est capable de faire.
Ça semblait évidemment devoir fonctionner comme ça, mais aujourd’hui l’appui long sert à tout et n’importe quoi.
Je ne peux pas le prouver, mais je pense que ces catastrophes d’UI/UX viennent parfois de la pression qui pousse à toujours changer, pour montrer que le logiciel est vivant
Imaginons qu’en 2023, une application ait atteint le sommet de son utilisabilité. Elle n’est pas parfaite, mais il n’existe aucune manière imaginable d’améliorer encore son utilisabilité. Les utilisateurs sont devenus assez compétents et, une fois franchis les obstacles intrinsèques à l’apprentissage de l’application, tout s’emboîte globalement
Cet état peut-il se maintenir ? Non. Si l’UI reste inchangée, le monde du logiciel finit souvent par considérer l’application comme « vieillotte », voire morte. Il faut donc la modifier. Mais changer quelque chose après le pic d’utilisabilité dégrade inévitablement l’UX, parfois de façon catastrophique
Je pense que c’est l’une des raisons pour lesquelles de bonnes UI de certaines applications et environnements de bureau finissent complètement massacrées
La généralisation des connexions Internet haut débit permanentes a énormément aggravé ce problème. Avant, les développeurs de logiciels devaient envoyer leurs produits en magasin sur CD, disquette, etc., et comme ils n’avaient pas facilement l’occasion de les mettre à jour, il fallait au moins un objectif clair et une échéance
Même lorsqu’une mise à jour sortait, elle devait être suffisamment significative et substantielle pour que l’utilisateur accepte de se donner la peine d’obtenir et d’installer la nouvelle version. À l’inverse, le logiciel moderne correspond très bien à une traduction approximative d’un proverbe de chez nous : « le samouraï n’a pas d’objectif, seulement un chemin »
Mon idéal serait de créer un produit aimé et largement utilisé, d’automatiser autant que possible le support client et les questions d’exploitation, puis de passer à un autre produit ou d’aller me reposer à la plage
Personne ne veut de changement. À chaque modification d’UI, je n’ai vu que des groupes de gens se plaindre, jamais, en face, une foule de vrais fidèles de taille comparable accourir pour la défendre
Au début, on veut que les gens aiment notre produit, on s’en soucie, on écoute, on alloue des ressources à l’utilisabilité. Des clients heureux nous rendent heureux
À l’étape intermédiaire, on se rend compte que l’utilisabilité est difficile, que concevoir de l’ergonomie et des affordances n’est pas aussi simple qu’on le pensait, et l’internationalisation arrive en plus. Comme personne n’enseigne vraiment correctement ce domaine, la plupart ont dû apprendre sur le tas, et les prestataires coûtent cher
À l’étape du déclin, on veut créer davantage de fonctionnalités, on embauche donc plus de programmeurs, et on licencie l’équipe utilisabilité en disant que « tout ce qui était nécessaire a été fait ». On licencie aussi l’équipe documentation. On se dit que les développeurs logiciels sont des ingénieurs, donc qu’ils peuvent bien écrire une FAQ
Au fond du trou, on a lancé plein de fonctionnalités aux clients au fil de super sprints, et pourtant les clients sont mécontents. On finit par se demander : « mais qu’est-ce qui leur prend ? »
Après Office 2007, j’ai retenu mon souffle pendant un moment en espérant que les développeurs d’OpenOffice/LibreOffice ne se précipiteraient pas pour implémenter le Ribbon. Le fait qu’ils aient tenu jusqu’ici est un petit point lumineux
On continue aussi de payer toute l’équipe UX qui a été utile pour une v1 presque parfaite, donc il faut bien lui donner du travail