Ne cachez pas mes contrôles : les contrôles d’interface cachés nuisent à l’utilisabilité

• Les contrôles cachés dégradent l’utilisabilité des interfaces utilisateur
• Par le passé, les menus visibles à l’écran ont constitué un tournant majeur dans l’amélioration de l’utilisabilité
• Récemment, sur mobile et sur divers appareils, on observe un retour vers des interactions qui exigent à nouveau une manipulation fondée sur la mémoire
• La complexité du design d’interface et les considérations esthétiques sont les principales causes de l’augmentation des contrôles cachés
• Les designers doivent désormais repenser la structure pour rendre visibles toutes les fonctions principales afin que les utilisateurs puissent les découvrir

---

Introduction : où se trouve la connaissance dans une interface

• Dans les années 1960, Douglas Engelbart a proposé l’idée de « la connaissance est-elle dans le monde ou dans la tête ? »
• La « connaissance dans le monde » signifie que les contrôles de manipulation sont visibles dans l’interface, ce qui permet à l’utilisateur de les trouver et de les utiliser directement, sans avoir à les mémoriser
  • Exemple : une interface graphique avec des menus déroulants
• La « connaissance dans la tête » désigne un environnement dans lequel l’utilisateur doit mémoriser tous les contrôles et toutes les commandes
  • Exemple : dans l’invite de commande DOS, si l’on ne connaît pas les commandes (DIR, etc.), on ne peut rien faire

Pourquoi les contrôles cachés se multiplient et leurs effets négatifs

• À mesure que la complexité des interfaces augmente, de plus en plus de contrôles sont masqués visuellement
• En apparence, cela peut sembler plus épuré, mais du point de vue des utilisateurs débutants, les manipulations deviennent bien plus difficiles
• L’apparition de menus déroulants et d’autres « contrôles visibles » a considérablement favorisé la démocratisation de l’informatique et la productivité
• Pourtant, sur les appareils mobiles et les nouveaux équipements électroniques, les interactions fondées sur une « cartographie mémorielle » se généralisent à nouveau
  • Exemple : pour utiliser la lampe torche de l’iPhone, afficher les notifications ou lancer Apple Pay, il faut connaître des actions cachées ou des gestes spécifiques sans toujours disposer d’indices suffisants

Exemples de contrôles cachés au quotidien

• Des clés de voiture sans fil ou des poignées de porte comportent elles aussi des contrôles cachés, au point qu’il peut être difficile d’effectuer les actions les plus élémentaires si l’on ne connaît pas leur fonctionnement
  • Ex. : emplacement de la clé interne, barillet dissimulé, séquence particulière de boutons, etc.
• Les systèmes de navigation automobile (comme Apple Maps sur CarPlay) ont également tendance à masquer des contrôles essentiels pour afficher une carte plus large, ce qui oblige à connaître précisément quelle zone toucher pour accéder à certaines fonctions
• Les contrôles fondés sur le temps constituent eux aussi une forme de contrôle caché
  • Ex. : le bouton d’alimentation d’un ordinateur n’effectue un arrêt normal qu’après une pression prolongée ; sur une serrure électronique, le verrouillage peut nécessiter une touche distincte ou un appui long

Problèmes généraux liés aux contrôles cachés et impact sur les utilisateurs experts

• Même lorsque le volume est réglé sur 0, certaines apps émettent tout de même du son : des « réglages cachés » viennent ainsi écraser les commandes directes de l’utilisateur
• Les utilisateurs avancés eux aussi subissent une forte dépendance à la connaissance dans la tête dans les interfaces à commande (par ex. R, une fenêtre DOS, etc.)
• On observe progressivement un retour vers des interfaces plus primitives

Pourquoi les contrôles cachés se multiplient-ils ?

• Les fonctionnalités sont devenues si nombreuses qu’il est impossible de tout afficher à l’écran, ce qui réduit la visibilité
• Les interactions entre les modes du système, l’augmentation de la complexité, ainsi que la recherche d’esthétique ou de facilité d’implémentation par les designers favorisent fréquemment la dissimulation des contrôles
• En pratique, cette évolution découle souvent de la priorité donnée à des objectifs de design (comme l’esthétique) plutôt qu’à l’attention portée à l’utilisateur

Exemples réussis et différence avec les systèmes critiques

• Certains systèmes, comme la navigation de General Motors, affichent en permanence tous les contrôles nécessaires, ce qui permet même aux débutants de s’orienter facilement
  • Ex. : fonction de zoom via une molette physique sur la Buick LaCrosse
• Dans les systèmes critiques (avions, usines, etc.), la conception repose presque toujours sur des contrôles visibles en permanence
  • Personne n’accepte le risque qu’un contrôle caché ralentisse une action rapide

La défense des interfaces cachées et ses limites

• Les contrôles cachés ne relèvent pas d’un simple conflit générationnel, mais d’un véritable problème d’utilisabilité
• Certains présentent l’exploration des « fonctions cachées » comme un avantage, mais dans les faits, la baisse d’accessibilité est évidente
• Du point de vue de l’utilisateur, un contrôle impossible à trouver équivaut à un contrôle qui n’existe pas

Informatique ubiquitaire et automatisation / invisibilisation des contrôles

• Mark Weiser et Donald Norman ont prédit un futur où la technologie deviendrait « transparente » et fonctionnerait en arrière-plan
  • Ex. : le contrôle du moteur d’une voiture est entièrement ajusté automatiquement en arrière-plan, sans intervention de l’utilisateur
• Lorsque l’automatisation fait disparaître complètement un contrôle, la nécessité et le contexte sont clairement établis
  • En revanche, lorsqu’une action de l’utilisateur est requise, des contrôles explicites restent indispensables

Conclusion et orientation pour les designers d’interface

• Les designers d’interface devraient éviter les contrôles cachés et faire évoluer toutes les fonctions vers une logique de connaissance dans le monde
• La capacité à découvrir les contrôles (discoverability) reste un principe de conception fondamental
• Dans les interfaces modernes, le recul de cette découvrabilité constitue en réalité une régression vers les débuts de l’informatique

Références

• Engelbart, D.C. (1962) et autres références essentielles
• Citations d’ouvrages et d’articles tels que Apple Macintosh, The Psychology of Everyday Things, The Invisible Computer, etc.

À propos de l’auteur

• Philip Kortum : professeur au département de sciences psychologiques de la Rice University, dont les recherches portent sur le développement de systèmes centrés sur l’utilisabilité dans des domaines variés comme l’évaluation de la confiance, la santé mondiale et les systèmes mobiles

[GN⁺]

Réactions sur Hacker News

• Partage d’expériences utilisateur récentes où les designs qui masquent les barres de défilement sont perçus comme gênants ; il est aussi noté que certains exemples de boutons physiques intuitifs cités dans l’article ont des limites en coût et en praticité ; confusion ressentie face à des interrupteurs à bascule dont le libellé indique l’état vers lequel on va basculer, et non l’état actuel
  • Certains détestent aussi les vrais interrupteurs à bascule parce qu’ils sont ambiguës ; des cases à cocher ou des boutons enfoncés sont bien plus clairs, et c’est regrettable que cela ait été sacrifié au nom de la modernisation
  • Souvenir d’un interrupteur de validation immédiate déroutant sur un distributeur de billets de train en Autriche ; les barres de défilement sont aussi devenues si fines qu’il faudrait presque des compétences de joueur FPS, et il arrive qu’une barre de défilement horizontale soit plus pratique ; pique adressée à Firefox et aux standards CSS
  • Sous macOS, il est rappelé qu’on peut toujours afficher les barres de défilement via les réglages système ou une commande Terminal
  • Si un toggle représente une action, il devrait impérativement employer un verbe ("TURN ON") pour être clair ; s’il affiche un état, une formulation explicite comme "IS ON" est proposée ; sauf dans quelques cas de contexte vraiment ambigus, l’usage d’un verbe rend presque toujours la chose évidente
  • Merci aussi de prendre en charge PgUp et PgDn
• Un intervenant explique conduire une vieille Toyota où tous les contrôles sont toujours visibles, clairement étiquetés et identifiables au toucher ; selon lui, c’est facile à reproduire et cela demande un minimum d’ingénierie, minimum que la plupart des constructeurs actuels n’atteindraient même plus
  • Accord sur certains points, mais affirmer que « tous les contrôles doivent être visibles » reviendrait à sous-estimer les designers ; en pratique, seuls les contrôles indispensables pendant la conduite sont exposés, tandis que d’autres sont petits, complexes ou cachés ; le levier de réglage de hauteur du siège ou l’ouverture du capot sont dissimulés mais restent accessibles ; la conception qui tient compte de tous ces détails n’a rien de simple ni de trivial, et traiter cela à la légère serait justement une des causes de la dégradation actuelle de l’UX
  • Pour d’autres, ce n’est pas un problème de compétence mais de coût : aujourd’hui, un écran tactile est moins cher et plus simple à fabriquer que de nombreuses touches et molettes distinctes à produire et assembler
  • Une personne raconte avoir reçu beaucoup d’offres d’embauche comme développeur systèmes chez des constructeurs automobiles américains, mais sur Hacker News beaucoup disaient : « si tu veux préserver ta santé mentale, évite »
  • Un autre explique aussi que différencier les pièces mécaniques comme les molettes augmente les coûts de fabrication, notamment avec des moules personnalisés ; intégrer cela à un écran est bien plus efficace économiquement
• On peut comprendre qu’on cache des éléments d’UI pour économiser de l’espace, mais les masquer tout en laissant l’espace vide est jugé incompréhensible ; dans IntelliJ, les icônes au-dessus de l’arborescence du projet n’apparaissent qu’au survol, et certains se demandent s’il était vraiment nécessaire de faire ainsi
  • À une époque où les écrans de mobile, de bureau et de portable n’ont jamais été aussi grands, certains doutent du bien-fondé des interfaces qui masquent des éléments ; rappel aussi qu’en 1984, le Macintosh, malgré son petit écran monochrome, sacrifiait déjà une partie de la surface pour placer des boutons clairs et visibles
  • Certains se plaignent que le « bruit » visuel nuit à la concentration, tandis que d’autres veulent voir en permanence tous les contrôles et voyants, comme sur un tableau de bord ; les réglages par défaut des IDE sont donc un compromis pour tenter de satisfaire ces préférences extrêmes, et certains outils proposent en plus des modes comme le « no distractions mode »
  • Sur la version Windows d’IntelliJ, le menu est lui aussi caché derrière une icône hamburger, ce qui laisse encore plus d’espace vide ; heureusement, on peut le rétablir dans les réglages, mais le choix par défaut reste incompréhensible
  • Même en sachant qu’un bouton existe et en se rappelant comment l’afficher, il arrive parfois d’oublier où il se trouvait et de rester à fixer l’écran sans rien faire
  • À l’inverse, certaines applications cachent trop peu de boutons, et l’on souhaiterait parfois une option pour en masquer ; Google Maps est cité
• À propos des smart keys de voiture, il est reproché aux ingénieurs de cacher la vraie clé, voire de forcer à démonter la poignée de porte pour trouver la serrure : dissimuler des contrôles importants serait profondément hostile pour l’utilisateur
  • Quelqu’un raconte avoir vécu une situation semblable avec une voiture de location : la télécommande était tombée en panne et tous les bagages étaient restés enfermés ; il savait qu’une clé physique existait, mais il a trouvé l’emplacement de la serrure grâce aux traces de rayures laissées par les utilisateurs précédents autour de la poignée
  • D’autres répondent que ce genre de choses fait partie des informations de base que l’utilisateur devrait connaître, et qu’on peut les trouver sur Google ; exemple donné d’une personne qui, en recevant une voiture récente, a immédiatement vérifié les options de secours et leur fonctionnement, en insistant sur l’importance de connaître un minimum le produit que l’on possède
• Sur iPhone, la disparition du bouton Home a été l’une des raisons du passage à Android, car expliquer l’usage aux personnes âgées de la famille est devenu plus difficile ; à l’achat d’un nouveau Pixel, certains activent d’abord la navigation à 3 boutons, mais soulignent que beaucoup d’apps récentes supposent uniquement une barre de navigation inférieure et voient donc leur contenu masqué par ces 3 boutons
  • Certains affirment que les éléments essentiels de l’UI doivent absolument être visibles ; Apple enfreindrait parfois ce principe mais y résisterait le plus souvent ; la suppression du bouton Home serait moins une disparition d’élément UI qu’une transformation de l’interaction ; on peut débattre de son intuitivité, mais une fois l’habitude prise, les frictions d’usage deviennent presque nulles ; il est aussi rappelé qu’iOS propose une fonction d’accessibilité avec un petit bouton rond déplaçable à l’écran, avec libellés textuels
  • Le même phénomène existe dans les logiciels classiques quand des éléments de menu disparaissent sans bruit ; exemple donné de MS Word, où l’icône permettant d’enregistrer un fichier en lecture seule a complètement disparu ; il serait préférable de la laisser désactivée, puis d’expliquer lors de l’enregistrement la cause du blocage et la manière de le résoudre
  • Un utilisateur Android de longue date explique que, chaque fois qu’il doit emprunter un iPhone, il est frustré par des interactions non intuitives ou absentes ; la qualité photo des Pixel et Samsung étant désormais très bonne, il ne voit plus de raison de passer à l’écosystème Apple
• Certains estiment que l’article ne traite pas assez du fait que la disparition de l’UI n’est ni accidentelle ni fortuite, mais relève d’une logique de lock-in utilisateur ; selon cette lecture, dans des logiciels arrivés à saturation, on modifie l’UI de façon moins intuitive pour empêcher les utilisateurs existants de partir ; l’appareil cesse d’être simplement quelque chose qu’on « utilise » pour devenir quelque chose d’« intériorisé », ce qui augmente le coût de sortie ; l’apprentissage de l’UI ferait naître une peur de changer de produit, ce qui expliquerait pourquoi la plupart des grands éditeurs suivent cette voie
  • D’autres jugent cette hypothèse seulement partiellement vraie ; dans les faits, il existe aussi un fort rejet des « interfaces complexes et encombrées » ; la tendance au minimalisme et des communautés comme /r/unixporn montrent que beaucoup d’utilisateurs choisissent eux-mêmes de masquer les contrôles ; GNOME suit également cette tendance récente vers des interfaces minimales ; nombre d’utilisateurs savent très bien aller chercher une fonction uniquement lorsqu’ils en ont besoin
  • Cette méthode est à double tranchant, car elle freine aussi l’arrivée de nouveaux utilisateurs ; une personne raconte préférer Android parce qu’elle déteste que toutes les interactions d’Apple soient concentrées autour d’un seul bouton, tout en ayant par ailleurs d’autres raisons de ne pas aimer Apple
  • Même dans l’OSS non lucratif, on suivrait ces tendances sans esprit critique ; Firefox et ses changements de design récurrents, ainsi que GNOME, sont cités dans ce contexte
• Lorsque des designers de type « artiste » prennent le contrôle des décisions UI, ils seraient obsédés par la propreté visuelle au point d’ignorer l’affordance et les possibilités d’apprentissage ; le cockpit d’avion, écrasant pour les non-spécialistes mais entièrement étiqueté pour les professionnels, est donné comme exemple de contraste
  • Réponse opposée : un robinet domestique n’a pas besoin d’étiquettes de direction ; un cockpit d’avion est justement excessivement intimidant pour un débutant ; les designers d’interface savent très bien ce qui est intuitif et sont capables de condenser des fonctions complexes dans un form factor simple ; croire que des personnes sans formation en design feraient mieux relèverait surtout de l’arrogance et du mépris ; le fait que tant d’utilisateurs sachent aujourd’hui manier un smartphone moderne sans formation est présenté comme une vraie réussite
• Question liée sur Hacker News concernant un coup de gueule sur les logiciels desktop et leur état actuel
• L’un des principes de conception UI dans une entreprise est que les raccourcis clavier et menus contextuels doivent toujours être accessibles via un bouton ou un menu clairement visible ; c’est peut-être old school, mais c’est jugé essentiel ; les quatre coins de l’écran sont aussi décrits comme des zones clés de l’UI, car la souris peut s’y déplacer très vite ; le déplacement du menu Démarrer au centre dans Windows 11 est cité comme exemple d’inconfort utilisateur, peut-être lié à une logique touch-first plutôt qu’au desktop
• Il est souligné que la baisse d’accessibilité et d’intuitivité des UI affecte particulièrement les personnes handicapées et les seniors ; le tactile et les gestes sont devenus dominants, mais les premières UI mobiles étaient selon certains plus accessibles ; la dérive vers des interfaces excessivement minimales et plates est vue comme la cause profonde ; palm, compaq pilot, l’iPod et les premières interfaces de l’iPhone sont évoqués avec nostalgie, et la suite est jugée régressive
  • À l’inverse, certains trouvent plus beau et plus agréable de pouvoir se concentrer sur le contenu grâce à des contrôles cachés, comme lorsqu’ils lisent les commentaires HN sur téléphone ; à l’époque du Palm Pilot, les boutons et contrôles occupaient parfois la moitié de l’écran, réduisant d’autant la zone de contenu ; des contrôles cachés ne sont donc pas forcément mauvais, et deviennent un outil puissant pour les experts une fois appris ; demander un minimum d’apprentissage de l’UI à l’utilisateur est dans une certaine mesure inévitable, et pour des outils puissants comme un éditeur de code ou git, il existe un vrai compromis entre simplicité et puissance ; en revanche, le fait que chaque app récente impose ses contrôles personnalisés réduit fortement la transférabilité de cet apprentissage, ce qui pose problème ; un modèle comme celui de Palm Pilot, où ce qu’on apprend dans une app sert partout, serait idéal