Ne cachez pas les contrôles : les contrôles d’interface cachés nuisent à l’utilisabilité
(interactions.acm.org)- À mesure que les interfaces modernes gagnent en fonctionnalités et dissimulent les éléments de commande hors de l’écran, les utilisateurs reviennent à une situation de knowledge in the head, où ils doivent mémoriser le mode d’emploi plutôt que reconnaître des indices visibles
- Les menus déroulants fournissaient du knowledge in the world en permettant d’explorer les actions possibles, mais smartphones, voitures et appareils électroménagers s’appuient souvent sur des interactions invisibles comme le balayage, l’appui long ou des combinaisons de boutons
- La lampe torche, les notifications et Apple Pay sur iPhone, les key fobs de voiture, Apple Maps dans CarPlay, les serrures électroniques, les sons de notification des apps et l’écran vide de R montrent comment les contrôles cachés dégradent concrètement l’utilisabilité
- Le problème ne concerne pas seulement les débutants : même les outils utilisés par des experts, comme les logiciels statistiques, peuvent devenir moins accessibles lorsqu’ils passent d’un système à menus à un outil centré sur la ligne de commande
- Les concepteurs ne devraient pas cacher les contrôles uniquement pour simplifier l’esthétique ou économiser de l’espace à l’écran ; pour les fonctions difficiles à automatiser, ils devraient privilégier la découvrabilité et des éléments de commande visibles en permanence
Contrôles visibles et contrôles à mémoriser
- Douglas Engelbart a introduit au début des années 1960 les notions de knowledge in the world et de knowledge in the head dans les interfaces informatiques, et Donald Norman les a formalisées et popularisées dans The Psychology of Everyday Things
- Le knowledge in the world désigne une situation où les contrôles nécessaires sont visibles, et où l’utilisateur peut les identifier et les manipuler par reconnaissance plutôt que par mémorisation
- Dans les interfaces graphiques modernes, les menus déroulants permettent de parcourir la structure des menus pour trouver l’action souhaitée, sans devoir mémoriser des commandes ou leur emplacement
- Le knowledge in the head désigne une situation où l’utilisateur doit mémoriser des commandes et des modes opératoires pour utiliser un appareil donné
- Sur les systèmes DOS, il fallait connaître la commande
DIRpour afficher la liste des fichiers, et la commande pouvait différer sur d’autres systèmes - Ces systèmes exigeant d’avoir presque toute la connaissance nécessaire en tête, ils se rapprochent d’une forme extrême de contrôles cachés
- Sur les systèmes DOS, il fallait connaître la commande
L’accessibilité transformée par les menus déroulants
- Les spécialistes de l’IHM ont rapidement compris qu’une exigence excessive de knowledge in the head empêchait les utilisateurs non spécialistes d’accéder aux systèmes
- Les menus déroulants placent la connaissance à l’écran, permettant aux utilisateurs de voir les actions possibles avant de choisir la fonction nécessaire
- Ce changement a rendu possible l’exécution efficace et efficiente de nombreuses tâches informatiques sans formation détaillée aux commandes, et a contribué à accélérer l’adoption de l’informatique
Le retour des interactions cachées dans les smartphones et les voitures
- En quarante ans, la forme des ordinateurs a beaucoup changé ; si les ordinateurs de bureau suivent encore souvent le modèle des années 1980 fondé sur des contrôles visibles, les smartphones exigent à nouveau des interactions fondées sur la mémoire
- Sur iPhone, pour accéder à la lampe torche, il faut balayer vers le haut depuis le coin inférieur gauche afin d’ouvrir le panneau de contrôle, mais l’interface elle-même n’indique pas que cette action est possible
- Pour voir les notifications, il faut balayer vers le bas depuis le coin supérieur
- Apple Pay nécessite de double-cliquer sur un bouton multifonction sans libellé
- Même des tâches simples deviennent difficiles lorsque le nombre de contrôles cachés augmente
- Dans l’exemple du déverrouillage d’une voiture, lorsque les boutons du key fob et ceux de la poignée de porte ne fonctionnaient pas, toutes les solutions étaient cachées
- Il fallait savoir qu’une clé physique était dissimulée dans le fob
- Il fallait aussi savoir qu’il fallait démonter une partie de la poignée de porte pour faire apparaître la serrure
- Le véhicule était passé en mode no remote unlock, et le seul indice était un motif particulier de clignotement des feux
- Pour résoudre le problème, il fallait ramener le véhicule dans le bon mode au moyen d’une séquence obscure d’appuis sur les boutons du key fob
- Le code caché signalant le problème ainsi que les solutions mécaniques et informatiques étant tous invisibles, il a fallu environ 30 minutes avant de pouvoir entrer dans la voiture
Interfaces graphiques embarquées et contrôles temporels
- Dans CarPlay, Apple Maps cache par défaut les contrôles de recherche et de zoom afin d’afficher la carte aussi grande que possible
- Pour saisir une destination ou zoomer sur la carte, il faut toucher le coin inférieur gauche de l’écran ; les icônes de recherche et de zoom apparaissent alors
- Les contrôles fondés sur le temps sont également une forme courante d’interaction cachée
- Même lorsqu’il est étiqueté, le bouton d’alimentation d’un ordinateur peut ne pas déclencher l’action souhaitée par une simple pression : il faut parfois le maintenir appuyé pendant une durée précise
- Sans formation ou connaissance préalable, le mode d’interaction lui-même reste caché
- Les serrures électroniques combinent contrôles cachés et contrôles temporels
- Pour déverrouiller, le grand bouton central offre l’affordance de poser le doigt
- Pour verrouiller, la touche
#est un contrôle caché, et elle ne s’active pas par une simple pression : il faut la maintenir enfoncée pendant 5 secondes - Lorsque la contrainte de durée et le contrôle caché se superposent, il devient difficile de verrouiller pour toute personne qui ne connaît pas bien le système
Un contrôle caché qui contourne les commandes de l’utilisateur
- Lorsqu’un utilisateur baisse le volume d’une chaîne stéréo à 0, il s’attend à ce qu’aucun son ne soit émis tant qu’il ne le remonte pas
- Sur iPhone, même si l’on baisse complètement le volume ou que l’on active le commutateur silencieux, une app peut produire du son via un contrôle caché
- Par exemple, une litière connectée pour chat peut signaler à minuit que le nettoyage est terminé, ou Instagram peut prévenir à 3 h 30 du matin qu’un enfant a publié une vidéo
- Ce comportement revient à permettre aux apps de contourner une simple commande de silence donnée par l’utilisateur
Même les experts n’échappent pas à l’écran vide
- Le problème des interfaces cachées ne touche pas uniquement les débutants
- Dans les logiciels d’analyse statistique, de nombreux chercheurs experts se retrouvent dans une situation où ils doivent passer de systèmes à menus comme SPSS à des programmes d’édition en ligne comme R
- Dans sa forme de base, R propose une interface très intimidante, proche d’une fenêtre DOS vide, et exige pour les tâches les plus simples une quantité importante de connaissances d’usage au-delà des connaissances statistiques
Pourquoi les contrôles cachés se multiplient
- Il y a environ 35 ans, Donald Norman a présenté la visibilité — appelée plus tard découvrabilité — comme l’un des principes fondamentaux de conception
- Les utilisateurs doivent pouvoir explorer systématiquement les contrôles et les menus pour comprendre ce que le système peut faire
- Les appareils modernes intègrent tellement de fonctions qu’il n’y a plus assez de place pour afficher tous les contrôles à l’écran
- La complexité des systèmes et les interdépendances que les utilisateurs ignorent ou comprennent mal peuvent aussi donner l’impression que les contrôles sont cachés
- Dans certains modes, un contrôle peut être visible, et dans d’autres non
- Si l’utilisateur ne comprend pas cette dépendance, le contrôle peut lui sembler caché
- Il est plus facile d’ajouter plusieurs fonctions à un contrôle existant, ou d’obliger l’utilisateur à toucher une zone non signalée de l’écran, que de concevoir des boutons visibles et persistants
- Le bouton d’alimentation d’un ordinateur peut viser à éviter les arrêts accidentels, mais une commande rotative bien étiquetée peut préserver la fonction et l’utilisabilité tout en réduisant les interactions cachées
Exemples de conception conservant des contrôles visibles
- Contrairement à Apple Maps, l’interface cartographique de General Motors place les contrôles nécessaires de façon visible et persistante sur l’écran principal de navigation
- Elle ne cache pas les contrôles de recherche et de zoom, sans nuire aux fonctionnalités ni à l’utilisabilité de la carte
- Elle offre aux débutants une expérience plus fluide et plus simple
- Sur la Buick LaCrosse, le zoom de la carte est implémenté par un bouton physique rotatif, avec une interaction simple : tourner dans le sens horaire pour zoomer et dans le sens antihoraire pour dézoomer
- La plupart des systèmes critiques s’appuient non pas sur des contrôles cachés, mais sur des contrôles visibles, persistants et indiquant l’état du système
- Les concepteurs reconnaissent que même des opérateurs très entraînés doivent pouvoir agir rapidement sans avoir à mémoriser comment effectuer une action ou y accéder
La différence entre l’informatique qui disparaît et les contrôles cachés
- En 1991, Mark Weiser a proposé l’idée de disappearing computing, où l’informatique se fond dans l’arrière-plan et accomplit les tâches avec très peu d’interaction humaine
- Dans The Invisible Computer, Donald Norman affirmait que la technologie devait être invisible et cachée
- L’ordinateur de gestion moteur d’une voiture mesure en continu les variables environnementales et les conditions de conduite pour ajuster automatiquement les paramètres du moteur, et fournit le résultat attendu sans que l’utilisateur ait à voir un écran d’options
- Mais cacher délibérément les interactions de l’utilisateur n’est pas ce que Norman et Weiser avaient en tête
- Il faudrait que les contrôles apparaissent au moment où ils sont nécessaires, ou qu’ils n’apparaissent pas du tout lorsque la fonction peut être exécutée automatiquement
- Pour l’ordinateur de gestion moteur, l’intention de l’utilisateur — vouloir que la voiture roule correctement — est relativement claire
- Pour une fonction comme la lampe torche d’un smartphone, lorsqu’il est difficile de déterminer automatiquement quand l’utilisateur en a besoin, le contrôle devrait être visible ou présenter une affordance forte
Les principes que les concepteurs doivent réexaminer
- Les concepteurs d’interfaces commerciales devraient réévaluer l’usage des contrôles cachés et rendre les fonctions des appareils suffisamment accessibles par le seul knowledge in the world
- La découvrabilité des contrôles reste un principe essentiel de conception d’interface
- La multiplication des contrôles cachés dans les nouvelles interfaces ressemble à une régression vers l’époque où l’usage de l’ordinateur était plus difficile parce que les fonctions n’étaient pas visibles
1 commentaires
Avis sur Hacker News
Je conduis une Toyota qui a presque l’âge minimum pour se présenter au Sénat américain : toutes les commandes dans l’habitacle sont toujours visibles, clairement étiquetées et reconnaissables au toucher
Les opérations de maintenance courantes, comme remplacer la batterie, ne bloquent pas non plus l’accès aux commandes
Une conception aussi facile à reproduire relève quasiment d’une compétence d’ingénierie minimale ; pourtant les constructeurs automobiles n’atteignent souvent même pas ce niveau et, raisonnablement, on peut dire qu’ils ne font pas leur travail
Ce ne sont pas « toutes les commandes » qui doivent être visibles, mais les commandes indispensables pendant la conduite, qui doivent être visibles et accessibles
Les commandes moins importantes, comme le levier de réglage de hauteur du siège ou la tirette d’ouverture du capot, peuvent être cachées tant qu’elles restent accessibles, et il existe énormément de choix subtils et subjectifs pour rendre une interface efficace
Ce processus de conception n’a rien de trivial ni de simple, et le fait de le balayer d’un revers de main est justement, selon moi, l’une des raisons pour lesquelles les constructeurs automobiles en sont venus à ignorer ce type de considérations
Aujourd’hui, fabriquer un seul écran tactile est plus simple et moins cher que de fabriquer et assembler une multitude de petits boutons et molettes
Dire adieu à l’épouvantable UI tactile de ma voiture ne me manquera absolument pas
Mon ancien micro-ondes m’avait été offert par mes parents quand je suis parti étudier à l’étranger, je l’ai utilisé plus de 20 ans, et il fonctionnait encore jusqu’à mes quarante ans, mais la molette avait du jeu et l’extérieur était usé, alors je l’ai remplacé
Le nouveau, à la mode actuelle, est couvert de boutons ; honnêtement, je ne sais même pas à quoi servent toutes ces fonctions, et un seul réglage de puissance plus la durée, peut-être une fonction décongélation, suffiraient largement
C’était une discussion plus large sur l’ingénierie, la qualité et l’utilisabilité en général ; de son point de vue, les entreprises sont d’abord dirigées par des ingénieurs, puis quelques décennies plus tard par des managers, et ensuite par le marketing
Je ne sais pas ce qui vient ensuite, mais ce pourrait être « rien du tout », où tout le monde demande à l’IA à chaque étape et où les décisions finissent par être prises par l’IA par accident ; ce serait peut-être même mieux que le monde actuel piloté par le marketing
Je ne pense pas que le fait que les apps et les systèmes d’exploitation cachent les indices d’affordance de l’interface utilisateur soit un hasard
C’est un antipattern destiné à retenir les utilisateurs, et il apparaît souvent quand un logiciel atteint un point de saturation de sa croissance, où empêcher les utilisateurs existants de partir devient plus important que d’en attirer de nouveaux
Ce n’est pas non plus un hasard si la plupart des logiciels que nous utilisons sont fabriqués par des entreprises qui se trouvent précisément dans cette position, comme Google, Apple, Microsoft ou Meta
Il peut sembler contre-intuitif que cacher l’interface rende le départ des utilisateurs plus difficile, mais cela fonctionne parce que l’appareil cesse d’être quelque chose que l’on « utilise » pour devenir quelque chose que l’on « connaît »
Une fois qu’on a appris qu’il faut faire un swipe depuis un coin de manière imprévisible pour accomplir une tâche essentielle, l’idée même de passer à un nouveau téléphone et de devoir réapprendre tout cela devient effrayante
Les plaintes sur les produits Google, Apple, Microsoft et Meta comme ayant une « interface complexe et obèse » sont aussi courantes, et certains montrent un écran vide de VS Code en se plaignant qu’il est plus complexe qu’une configuration Vim presque sans interface
Le flat design et le minimalisme ont été à la mode pendant un temps, et les gens qui personnalisent /r/unixporn ou des distributions Linux cachent souvent les commandes des apps au nom du minimalisme
Si vous avez essayé GNOME récemment, vous savez qu’une interface minimale où la plupart des commandes sont cachées correspond aussi à une esthétique particulière que certaines personnes préfèrent
Beaucoup de gens ont l’impression qu’on peut cacher le « bruit » et le retrouver quand on en a besoin, sans forcément devoir fouiller dans un manuel
Cela peut empêcher l’utilisateur d’essayer cette interface
Les interfaces Apple m’agacent parce que tout commence par cet unique bouton, et j’oublie souvent comment accéder aux réglages, donc Android me paraît plus naturel
Android a réussi à jouer le rôle de verrouillage, tandis qu’Apple s’est tiré une balle dans le pied
Les refontes agaçantes de Firefox ou GNOME entrent dans cette catégorie
Je comprends qu’on masque des éléments d’interface pour utiliser l’espace à l’écran à autre chose.
Mais certaines interfaces masquent des éléments tout en laissant cet espace vide, et là, je ne comprends pas pourquoi.
Dans IntelliJ, par exemple, c’est le cas des icônes au-dessus de l’arborescence du projet, dont la petite icône en forme de cible qui déplace la sélection de l’arborescence vers le fichier de l’onglet d’éditeur actuellement actif.
Il faut connaître l’emplacement secret à l’écran et déplacer la souris vers un espace vide pour qu’elle apparaisse comme par magie.
J’aimerais connaître la justification de ce genre d’implémentation.
Quand il y a trop de stimuli dans le champ de vision, elles ont l’impression que leur attention est attaquée et que leur concentration se brise ; elles veulent donc que ce qui n’est pas l’objet de leur attention actuelle disparaisse, ou au moins soit moins visible.
À l’inverse, des personnes comme les pilotes d’avion aiment que tous les indicateurs soient immédiatement visibles et que toutes les commandes soient à portée de main, et peuvent changer facilement de point de focalisation.
Les réglages par défaut d’un IDE doivent trouver un équilibre entre des préférences différentes, ce qui impose forcément des compromis ; certains outils proposent donc des interrupteurs avec des niveaux de détail préconfigurés, comme un « mode Ne pas déranger » ou un « mode expert ».
Il existe bien une option pour revenir en arrière, enfouie dans les paramètres, mais le fait que ce soit la valeur par défaut est vraiment difficile à comprendre.
Les écrans de téléphones, tablettes, ordinateurs portables et ordinateurs de bureau sont plus grands que jamais.
Le Macintosh original de 1984 avait un écran monochrome de 9 pouces à faible résolution et, même s’il y avait sans doute aussi le fait que les interfaces graphiques étaient alors peu familières, Apple avait choisi la clarté, la visibilité et la découvrabilité, quitte à sacrifier des ressources d’écran, de calcul et de mémoire extrêmement limitées.
Une fois les écrans agrandis, ce coût en espace est devenu presque négligeable.
Quand on a commencé à parler d’« expérience utilisateur » plutôt que d’« interface utilisateur », on s’est mis à se préoccuper davantage de l’état émotionnel de l’utilisateur que du rôle d’outil, et la forme a pris le pas sur la fonction.
Désormais, il faut même s’inquiéter de « le tenir mal », alors qu’en réalité les machines sont là pour servir les humains, pas l’inverse.
Il y a quelque temps, je me suis retrouvé enfermé hors de ma voiture, et le bouton de la clé télécommande ne fonctionnait pas.
On pourrait dire qu’il suffisait d’utiliser la clé, mais il faut d’abord savoir qu’il y a une clé cachée dans la télécommande, et comme il n’y a pas de serrure visible sur la portière, il faut aussi savoir qu’il faut démonter une partie de la poignée pour faire apparaître la serrure.
Cacher des commandes automobiles importantes, c’est de l’ingénierie hostile, et ce n’est même pas particulièrement atypique dans l’expérience automobile moderne.
Le manuel n’explique pas seulement comment changer de station de radio ; il contient aussi des informations de sécurité et indique quoi faire en cas de problème.
J’ai du mal à croire qu’un conducteur qui ne sait même pas qu’il peut ouvrir sa voiture quand la batterie est à plat tienne compte de choses comme la charge maximale de sécurité.
Ce n’est qu’après avoir quitté le parking et être arrivé à un hôtel à 30 minutes de là que j’ai découvert que la télécommande était en panne, et tous mes bagages étaient enfermés dans la voiture.
Je savais qu’il devait forcément y avoir une clé physique, mais si j’ai pu trouver la serrure, c’est uniquement parce qu’un précédent locataire avait beaucoup rayé la poignée en essayant de trouver cette même serrure.
Dès que j’ai reçu une voiture sans clé physique apparente, ma première question a été : « Quelle est l’option de secours et comment fonctionne-t-elle ? »
Avoir des connaissances de base sur les objets que l’on possède n’a rien de difficile.
C’est ce qui arrive quand des artistes appelés « designers » prennent le contrôle des décisions d’UI.
Ils veulent que ce soit « propre », même au prix de la découvrabilité, et oublient que les indices d’affordance aident les gens à apprendre.
À comparer avec des exemples comme un cockpit d’avion, qui demande une expertise et comporte beaucoup de commandes, mais où tout est étiqueté.
Elles sont deux fois plus grandes que nécessaire, regroupées, si bien qu’il faut passer la souris dessus pour voir quelle instance correspond à quoi, puis cliquer encore pour basculer vers la fenêtre voulue.
Il faut deviner à partir de miniatures, alors que toutes les fenêtres de terminal se ressemblent.
La méthode de Windows NT jusqu’à Vista — afficher ensemble icône et libellé, comme les onglets d’un navigateur web — était le sommet de l’UX desktop pour le changement de contexte, et GNOME n’arrive même pas à rendre correctement une telle barre des tâches.
Les experts habitués à une situation donnée ont une tolérance bien plus élevée à la densité visuelle, parce que pour eux ce n’est pas de l’encombrement, mais de l’information signifiante.
Mais la plupart des gens n’utilisent pas la plupart des applications mobiles avec ce degré de familiarité.
Le design mobile doit fournir de nombreuses fonctions tout en gardant l’utilisateur près d’un niveau de confort acceptable, en les révélant progressivement ; il faut donc un compromis où certaines choses sont cachées et d’autres exposées à des niveaux plus profonds.
Je suis d’accord pour dire que le design mobile et celui des systèmes d’exploitation ont trop réduit les indices d’affordance, mais hors outils professionnels, le cockpit d’avion n’est pas un bon modèle.
Un téléphone n’est pas un 747, et quand une personne ordinaire qui n’est pas pilote entre dans un cockpit d’avion, elle est submergée par la quantité de commandes et ne sait pas ce qui est quoi.
Les designers d’interface savent ce qu’ils font, savent ce qui est intuitif ou non, et ont porté au niveau de l’art la manière d’intégrer des ensembles complexes de fonctionnalités dans des formes relativement simples.
Penser que des gens sans formation en design feraient mieux que ces « soi-disant designers » relève presque de l’arrogance et du manque de respect envers un domaine de recherche mûr ; en pratique, les gens utilisent assez bien leur téléphone avec très peu de formation.
C’est en soi un miracle moderne.
C’est un peu à côté du sujet, mais c’est l’une des raisons pour lesquelles je suis passé à Android après que l’iPhone a supprimé le bouton d’accueil.
Expliquer les interactions à des utilisateurs âgés de ma famille est clairement devenu plus difficile, et à peine avaient-ils appris “Force Touch” que ça a aussi disparu.
Quand je reçois un nouveau Pixel, la première chose que je fais est d’activer la navigation à 3 boutons, mais aujourd’hui même ça est de plus en plus marginalisé du point de vue de l’UI.
Les apps supposent la présence d’une barre de navigation en bas et ne tiennent pas compte de l’espacement plus important de la navigation à 3 boutons, si bien que du contenu ou du texte se retrouve parfois dessous.
Par exemple, quand on ouvre un fichier en lecture seule dans MS Word, l’option d’enregistrement n’est pas visible.
Il est difficile de comprendre pourquoi on peut le modifier mais pas l’enregistrer.
Une bien meilleure expérience utilisateur consisterait à ne pas masquer l’option d’enregistrement et à la laisser active, puis, quand l’utilisateur essaie d’enregistrer, à lui indiquer “ce fichier ne peut pas être enregistré pour telle raison” et à proposer une solution.
Les interactions sont cachées, peu intuitives, ou carrément absentes.
Maintenant que l’appareil photo du Pixel dépasse celui de l’iPhone et que Samsung est à peu près au même niveau, je ne vois vraiment aucune raison d’aller dans l’écosystème Apple.
Parce que, où qu’elle soit, elle peut appuyer sur un gros bouton évident pour revenir à l’écran d’accueil familier.
Cela dit, dans l’ensemble, je trouve qu’ils résistent plutôt bien à cette tentation, et je ne suis pas d’accord avec l’idée que la suppression du bouton d’accueil revienne à cacher un élément d’UI.
C’est une interaction qui est passée de “appuyer” à “balayer”, et l’élément d’UI n’est pas le bouton mais le bord de l’écran lui-même.
On peut débattre de son caractère intuitif ou de sa supériorité, mais c’est comparable au double-clic sur une icône pour lancer une app, ou au clic droit pour ouvrir un menu contextuel.
Dans les deux cas, il n’y a pas d’indice visuel, mais ce sont des fonctions essentielles utilisées en permanence, et une fois qu’on y est habitué, elles ne créent plus de friction.
On peut dire qu’Apple impose trop librement de nouvelles intuitions, et je suis d’accord pour des exemples comme le déplacement de la barre d’adresse dans Safari, mais je considère que le bouton d’accueil est une exception.
iOS propose aussi une fonction d’accessibilité qui affiche à l’écran un petit cercle déplaçable ; quand on appuie dessus, il peut afficher un bouton d’accueil avec un libellé texte et plusieurs raccourcis utiles.
Je connais même des gens qui l’activaient à l’époque où il y avait encore un bouton d’accueil matériel, parce qu’ils ne voulaient pas l’user.
C’est aussi une solution.
Nous avons une règle de conception d’UI selon laquelle les raccourcis clavier et les menus contextuels doivent être des moyens d’accès rapides à des commandes découvrables via des boutons ou menus explicites.
C’est peut-être pour ça que nos apps ont l’air datées.
On m’a appris autrefois que les quatre coins de l’écran étaient l’espace le plus précieux, parce qu’on peut les atteindre rapidement sans contrôle précis de la souris.
C’est pourquoi je considère que le fait que Microsoft ait déplacé par défaut le menu Démarrer au centre dans Windows 11 est hostile à l’utilisateur.
Il est difficile d’attribuer ça au mobile-first ; à la rigueur, ça pourrait être du “touch-first”, où le déplacement de la souris ne s’applique pas.
L’équipe de conception devait probablement y être habituée parce que c’est l’environnement qu’elle utilise elle-même, mais il n’y a aucune raison UX rationnelle.
Même sur macOS, cette approche nuit à l’interface.
En plus, chaque élément de menu devrait afficher le raccourci clavier qui l’active.
Toutes les infobulles qui apparaissent au survol d’un bouton devraient aussi montrer le raccourci qui exécute cette fonction.
C’est le meilleur moyen pour les débutants de découvrir les raccourcis dont ils ont besoin sans devoir les chercher ailleurs.
Après avoir déplacé la souris loin, il faut une manipulation précise pour agrandir, et si l’on échoue en voulant voir le programme en plus grand, le résultat est destructeur et il ne reste rien.
Il suffit de voir la loi de Fitts : https://en.wikipedia.org/wiki/Fitts%27s_law
Mon client de métavers affiche généralement une vue épurée d’un monde 3D, et quand on amène le curseur en haut ou en bas de l’écran, une barre de menu et des commandes apparaissent.
Elles restent visibles tant que le curseur est au-dessus des commandes, puis disparaissent au bout de quelques secondes.
Même sans explication volontaire, les utilisateurs découvrent naturellement les commandes, parce qu’en bougeant la souris ils finissent par toucher les bords.
Il est vraiment rageant que les systèmes d’exploitation modernes continuent de masquer les chemins du système de fichiers, aussi bien sur desktop que sur mobile
Dans les anciens OSX, il existait un réglage pour afficher la barre d’adresse dans Finder, mais ce n’était pas le comportement par défaut ; aujourd’hui, ça semble impossible sans extension tierce, donc on finit par devoir utiliser le terminal
Ça n’a aucun sens de rendre impossible la localisation d’un fichier quand on devra plus tard le déplacer ou le transférer
Le problème, c’est que les personnes qui font ces tests optimisent, volontairement ou non, pour le mauvais indicateur : « avec quelle rapidité et facilité une personne qui voit ça pour la première fois comprend comment faire cette tâche »
À l’échelle macro, c’est une mauvaise optimisation : cela peut augmenter les conversions à court terme, mais à long terme ça nuit à l’utilisabilité, à la fonctionnalité et à la découvrabilité, et ça met en colère les utilisateurs avancés et fidèles, ceux qui aimeront l’app et en parleront autour d’eux
Quand on fait des tests A/B et des tests d’utilisabilité en labo ou en focus group sans perspective sociale plus large, on se concentre sur des métriques qui améliorent les KPI immédiats de court terme, et on finit par promouvoir des conceptions d’UX objectivement pires comme étant fondées sur des preuves et sur les données
Je pense que cela a ruiné l’utilisabilité des logiciels ces 20 dernières années, et que cela cause aussi beaucoup de tort à la génération suivante, qui grandit en ayant rarement l’occasion de rencontrer une UX réellement réfléchie
Il est souvent plus utile de partager le répertoire qui contient ce fichier plutôt que le fichier lui-même
MS Office offre bien un moyen d’obtenir cette information, mais il faut le trouver
Finder → menu Présentation → Afficher la barre du chemin d’accès
defaults write com.apple.Finder _FXShowPosixPathInTitle -bool trueComme signe que la conception d’UI part dans la mauvaise direction, il y a l’antipattern « la nourriture est dans le frigo », qu’on voit souvent ces temps-ci
Au lieu de fournir directement un bouton pour activer une fonction, du texte d’UI placé à un endroit incongru vous explique quelles étapes suivre pour activer une autre fonction
Une autre variante consiste à avoir un bouton ou un élément de menu qui, au lieu d’effectuer réellement l’action, déplace le focus vers un autre bouton ou ouvre un menu ailleurs, afin que l’utilisateur clique ensuite dessus
On le voit de plus en plus dans les produits Microsoft, en particulier VS Code
Game Helpin' Squad: World Quester 2
https://www.youtube.com/watch?v=0Gy9hJauXns
Chaque fois que je sélectionne « Cursor => Settings => Cursor Settings » dans Cursor, je ris en pensant à World Quester 2
J’aime tellement World Quester 2 que j’ai implémenté sa fonctionnalité la plus innovante, « Space Inventory », dans la version WASM de Micropolis (SimCity)
https://micropolisweb.com/
Attention : n’appuyez pas sur la barre d’espace !!!! Si vous l’avez fait par erreur, surtout ne rappuyez pas dessus !!!! Et ne rappuyez pas encore une fois !!!!
SimCity Micropolis Tile Sets Space Inventory Cellular Automata To Jerry Martin's Chill Resolve:
https://www.youtube.com/watch?v=319i7slXcbI
C’est un peu tangent et ça ressemble à une bataille perdue de vieux, mais, par pitié, ne masquez pas les barres de défilement
L’article était intéressant, mais il y a aussi des points sur lesquels je ne suis pas entièrement d’accord
Certaines choses ont un coût et des limites pratiques, comme un bouton physique pour zoomer/dézoomer sur une carte de voiture
Dans une app que j’ai récemment installée, j’ai appuyé sur un interrupteur, et il a fait l’inverse de ce que disait son libellé
Je pensais que le libellé indiquait l’état actuel, mais en réalité il indiquait l’état qui serait activé après bascule ; après l’avoir changé c’était clair, mais ça m’a semblé être l’implémentation la moins utile possible
Ils sont tout aussi ambigus
Les cases à cocher et les boutons enfoncés sont beaucoup plus clairs, mais malheureusement ils ont été sacrifiés sur l’autel de la « modernité »
C’était une fonction qui validait immédiatement le billet, et une erreur pouvait coûter de l’argent
Et il faudrait aussi arrêter de rendre les barres de défilement si fines qu’il faille des réflexes de joueur de FPS pour les viser
Firefox est particulièrement concerné, et c’est peut-être un problème permis par le CSS standard
Pour le défilement vertical, on peut s’en sortir, mais pour le défilement horizontal, une barre de défilement est plus pratique que d’appuyer sur Shift avec l’autre main
« TURN ON » est parfaitement clair, et si l’on veut montrer l’état, « IS ON » l’est aussi
Il existe sans doute quelques cas où même un verbe affiché, comme « INCREASE », peut prêter à confusion, mais il faut vraiment se forcer pour imaginer une UI où l’on ne sait pas si le bouton affiche un verbe ou un nom
https://superuser.com/a/1720363
Vous utilisez Firefox ?