Un bouton à bascule doit-il afficher l’état actuel ou l’état vers lequel il va basculer ? (2010)

 (ux.stackexchange.com)
3 points par GN⁺ 2024-02-13 | 1 commentaires | Partager sur WhatsApp
  • Quand un même toggle sert à la fois à une action immédiate comme Play/Pause et à un réglage persistant comme Shuffle, l’utilisateur peut confondre l’état actuel et l’action suivante
  • About Face 2.0 recommande d’éviter les flip-flop buttons, qui regroupent deux choix dans un seul contrôle, et considère que transmettre l’état actuel est plus important que gagner de la place
  • La solution consiste plutôt à exprimer l’action avec un groupe verbal, comme Passer en mode portrait, ou à séparer l’état et la bascule avec des boutons radio, des cases à cocher, ou un libellé d’état + un bouton d’action
  • Avec un switch de style iOS, si le texte est dans le bouton, ON peut être ambigu : est-ce l’état actuel ou l’état suivant ? Avec l’approche OS X ou Windows Metro, où le texte d’état est placé hors du bouton, l’ambiguïté diminue
  • La convention Play/Pause peut, à titre exceptionnel, afficher l’action suivante, mais pour des options comme Shuffle, Like ou Auto save, il est plus sûr de mettre en avant l’état actuel et de le renforcer avec une infobulle, la couleur, l’état enfoncé ou un libellé séparé

Conflit entre indication d’état et indication d’action

  • Pour des boutons qui alternent entre deux états, comme Play/Pause ou Shuffle/Lecture normale, la question centrale est de savoir s’il faut afficher l’état actuel ou l’état de transition après clic
  • Play/Pause est facilement compris par l’utilisateur comme une action — « lancer la lecture » ou « mettre en pause » —, si bien que la convention consistant à afficher Play à l’arrêt et Pause pendant la lecture est familière
  • Shuffle/Lecture normale se rapproche davantage d’un état d’option lié au mode de lecture ; afficher l’état à venir peut rendre flou le fait de savoir si la lecture aléatoire ou séquentielle est actuellement active
  • Le lecteur musical intégré de la Xbox 360 est cité comme exemple de confusion : il affiche l’icône de lecture directe lorsque le mode Shuffle est actif, et l’inverse dans la situation opposée

Recommandation d’About Face : éviter les flip-flop buttons

  • About Face 2.0 classe ce type de contrôle parmi les idiomes de choix à éviter, sous le nom de flip-flop button
  • Lorsqu’un seul bouton contrôle deux options mutuellement exclusives, on gagne de la place, mais il devient difficile de remplir la seconde mission du contrôle : indiquer l’état actuel
  • Si le bouton affiche ON alors que l’état actuel est éteint, l’état du réglage devient flou ; et s’il affiche OFF alors qu’il est éteint, on peut se demander où se trouve le bouton ON
  • Deux solutions sont recommandées
    • écrire l’action du bouton sous forme de groupe verbal, comme Passer en mode portrait
    • utiliser une autre technique d’interface qui rend explicite le choix d’état, comme deux boutons radio

Distinguer boutons d’action et boutons d’état

  • action button et state button doivent être conçus différemment
    • pour une action comme Play/Pause, on affiche ce qui se passera au clic
    • pour une option comme Shuffle/Linéaire, on affiche l’état actuel
  • Pour un bouton Shuffle composé uniquement d’une icône, il est préférable de conserver l’icône Shuffle et de la faire apparaître active ou inactive selon l’état
    • à l’état activé, elle peut être plus lumineuse ou ressembler à un bouton enfoncé
    • à l’état désactivé, il faut pouvoir comprendre immédiatement que la lecture séquentielle est active
    • dans un environnement avec hover, une infobulle peut être ajoutée pour plus de clarté
  • Certains estiment que même Play/Pause pourrait être moins ambigu sans changer le libellé, en affichant simplement le bouton Play comme enfoncé

L’ambiguïté créée par le texte dans le bouton

  • ON et OFF peuvent se lire en anglais soit comme des états, soit comme des actions de bascule ; placés dans le bouton, ils brouillent la distinction entre état et commande
  • Des paires de mots jugées plus explicites sont proposées
    • Enable / Disable
    • Enabled / Disabled
    • Start / Stop
    • Running / Stopped
  • Le choix des mots ne suffit toutefois pas à faire disparaître totalement le problème
    • l’utilisateur peut encore devoir déterminer si le texte du bouton décrit un état ou une commande
    • la différence entre Enable et Enabled peut ne pas être assez évidente dans l’interface

Libellé hors du bouton et séparation état + action

  • Si l’on évite d’inscrire du texte dans le bouton lui-même et qu’on place le texte à l’extérieur, on peut montrer à la fois l’état actuel et l’état vers lequel on peut basculer
  • Le switch de style OS X n’indique pas ON ou OFF dans le bouton ; c’est le texte autour du switch qui exprime l’état, ce qui réduit la question « ce bouton montre-t-il l’état actuel ou l’action suivante ? »
  • L’approche Windows Metro utilise la couleur du bouton pour signaler l’état actuel et le texte On/Off sous le libellé de l’option pour le confirmer
  • On peut aussi séparer libellé d’état + bouton d’action, comme dans En ligne [Passer hors ligne]
    • En ligne est un libellé non cliquable indiquant l’état actuel
    • Passer hors ligne est l’action cliquable de transition
    • après clic, l’ensemble devient Hors ligne [Passer en ligne]
  • Cette approche est plus compacte que des boutons radio tout en séparant visuellement le rôle de l’état et celui de l’action

Cases à cocher, boutons radio et état enfoncé

  • Une option comme Shuffle est moins ambiguë si elle est représentée par une case à cocher libellée Shuffle
  • Avec un seul mot et un état coché/non coché pour indiquer l’activation, l’utilisateur a moins besoin d’interpréter le sens de plusieurs termes
  • Il vaut mieux éviter les expressions à préfixe négatif
    • des préfixes comme Not, Non-, Un-, Dis-, Im-, Mis-, In-, Il-, Ir- peuvent produire une lecture proche d’une double négation lorsqu’ils sont associés à un état décoché
  • Le bouton Like de l’application Facebook Android est cité comme exemple : gris lorsqu’il est désactivé, bleu lorsqu’il est activé
    • toutefois, la couleur seule peut ne pas suffire pour les personnes ayant un trouble de la vision des couleurs

Exemples concrets d’UI et points d’attention

  • Le bouton Shuffle de l’application web Spotify illustre un compromis : couleur neutre lorsqu’il est désactivé, couleur accentuée lorsqu’il est activé
  • Le comportement de type Twitter au survol consiste à montrer l’état actuel, puis l’action au passage de la souris
    • cela peut fonctionner dans un environnement avec hover, mais pas forcément sur écran tactile
  • Les switches de style iOS montrent les deux états dans un seul contrôle, mais sont aussi critiqués parce que ON peut rester ambigu : état actuel ou état après appui ?
  • L’interface de réglages de Discord est citée comme exemple de toggle de type case à cocher rendant plus clairement l’état actuel et l’état futur
  • Les toggles au survol d’Evernote ou les poignées de verrouillage de toilettes d’avion sont également mentionnés comme exemples où l’état et la possibilité d’action apparaissent simultanément

Principes de conception

  • Lorsqu’un même contrôle doit à la fois indiquer un état et indiquer une action, une ambiguïté apparaît
  • L’état actuel doit impérativement être communiqué d’une manière ou d’une autre
    • pour Play/Pause, des retours externes comme le son de la musique ou l’écoulement du temps peuvent aider à comprendre l’état courant
    • pour Shuffle, il est difficile de connaître l’état avant d’observer réellement comment le morceau suivant est choisi, ce qui rend l’indication d’état sur le bouton lui-même plus importante
  • Faire défiler plusieurs états avec un seul bouton permet de compacter l’UI et de regrouper des réglages mutuellement exclusifs, mais l’utilisateur doit pouvoir identifier rapidement l’état courant
  • Play/Pause peut constituer une exception qui affiche l’action suivante grâce à une convention très forte ; pour les toggles d’options plus classiques, mettre l’accent sur l’état actuel reste plus cohérent

À lire aussi

1 commentaires

 
GN⁺ 2024-02-13
Avis sur Hacker News

  • Ces temps-ci, Microsoft Teams me rend vraiment fou. Dans l’application desktop, quand le micro est coupé, on voit une icône de micro barrée ; quand il ne l’est plus, elle devient un micro sans barre, donc c’est facile à comprendre.
    Mais quand on rejoint depuis l’application mobile, la même icône de micro barrée signifie « actuellement non coupé ; si vous appuyez sur ce bouton, le micro sera coupé ». Après avoir appuyé, l’icône reste un micro barré, seul l’arrière-plan s’inverse.
    J’en viens à me demander si, d’un côté, c’est un bouton « activer le micro » et, de l’autre, un bouton « activer le mode muet », d’où l’usage de la même icône. Au final, il faut savoir à quoi ressemble le bouton dans l’état opposé pour déterminer l’état actuel, et je finis toujours par appuyer plusieurs fois pour vérifier quelle logique cette appli utilise.
    Je me demande si c’est le prix à payer pour une flat UI qui a perdu ses référents dans le monde réel.

    • Je pense qu’une partie de cette confusion vient de l’idée que le micro est activé par défaut. Le schéma où « micro actif » est l’état par défaut et où le mode muet est traité comme une sortie de cet état remonte aux interfaces de systèmes de conférence téléphonique, aux téléphones analogiques, et même plus loin, à l’époque où une vraie ligne reliait les interlocuteurs.
      Les consoles de mixage audio pour la musique live ou l’enregistrement utilisent généralement le même modèle. Quand un canal est coupé, un bouton « Mute » s’allume en rouge ; seuls certains équipements affichent l’état actif du canal avec un bouton « ON » allumé au-dessus du fader.
      Je pense qu’il est temps que les applications de réunion passent elles aussi à une approche où l’audio est désactivé par défaut. On en voit déjà un peu les prémices avec des éléments d’interface qui s’allument quand l’intervenant parle.
    • C’est vraiment le genre de bouton qui ne devrait jamais prêter à confusion.
    • C’est pareil sur Plex, où l’UI varie selon les applications, ce qui est tout aussi frustrant. Sur téléphone, quand on regarde une saison de série TV, les épisodes déjà vus ont une coche bleue ; sur la TV, pour la même saison, il n’y a pas de coche bleue, et ce sont les épisodes non vus qui ont un triangle jaune.
      À chaque fois que je passe d’un appareil à l’autre, mon cerveau marque un temps d’arrêt.
    • Discord, c’est encore pire. Le bouton pour couper le micro et celui pour désactiver la caméra fonctionnent selon des logiques opposées.
    • Le problème de l’affichage/contrôle du micro a quelque chose d’assez intéressant. Sans retour visuel direct, on ne sait pas dans quel mode est le micro tant que les autres ne réagissent pas, ou ne réagissent pas.
      Même quand il est activé, c’est un outil avec un important délai de retour. L’autre personne s’est peut-être arrêtée, ou réfléchit avant de répondre, si bien qu’il faut souvent tester deux ou trois fois avant d’être sûr.
      Ce n’est pas comme le mode sombre, où le résultat se voit immédiatement quand on l’active ou le désactive. C’est pourquoi un indicateur visuel de l’état actuel aide beaucoup, quelle que soit l’action du bouton, et il n’est pas étonnant qu’on voie particulièrement souvent, avec les micros, des tentatives de mélanger « état » et « contrôle ».

  • Les propriétaires de Tesla ne peuvent qu’être d’accord. Les boutons bascule de l’UI de la voiture sont si variés qu’il n’y a ni cohérence ni standard.
    Par exemple, le bouton de climatisation est un unique bouton qui affiche la température, mais il réagit différemment selon la manière et la durée de l’appui. Un appui court ouvre une petite fenêtre pop-up, un appui un peu plus long affiche le panneau complet de contrôle de la climatisation, et si on maintient plusieurs secondes, la climatisation qui était allumée peut s’éteindre. Le problème, c’est qu’il faut faire tout cela en conduisant, alors qu’on doit regarder la route.
    Au moindre écart de coordination œil-main — ce qui est d’autant plus probable quand on passe sur une bosse en conduisant —, rater la cible d’un seul millimètre peut faire appuyer sur un autre bouton et déclencher une action non voulue.
    Autre catastrophe : l’UX de connexion des appareils Bluetooth. Au moins dans l’implémentation des Model S 2012–2022, c’était l’un des pires mélanges d’UI que j’aie vus dans un produit commercialisé. Le bouton en bas à droite continue d’afficher « Connect » même une fois la connexion déjà établie, tandis qu’à l’autre extrémité de l’écran, en haut à gauche, on voit « Connecting... » puis l’indication que la connexion est terminée.
    Là encore, c’est une UI embarquée, donc en conduisant on ne peut y jeter qu’un coup d’œil fugitif. Rien que l’UI Bluetooth de Tesla pourrait remplir un chapitre entier d’un livre sur l’UI, tant elle est brillamment mauvaise.

    • Dans l’application mobile Tesla, même des bascules placées juste à côté les unes des autres ne sont pas cohérentes.
      Un cadenas fermé signifie que les portes sont verrouillées, et si l’on appuie dessus, elles se déverrouillent.
      Le mot « Open » sur le coffre signifie que le coffre est fermé, et si l’on appuie dessus, il s’ouvre.
    • Ce serait bien d’écrire ce genre d’article soi-même. Ce type d’analyse est toujours intéressant, et si le sujet est Tesla, avec Elon dans l’équation, cela attirerait sans doute encore plus l’attention.
    • Voici comment j’utilise le bouton de climatisation : d’abord je regarde le bouton ; s’il est un peu transparent et que je veux l’activer, il suffit de cliquer pour l’allumer. Si je clique à nouveau, les contrôles complets s’ouvrent, et en faisant glisser vers le bas, ils se ferment.
      Quand je veux l’éteindre, j’appuie à nouveau sur le bouton pour ouvrir les contrôles complets, puis j’appuie sur le bouton d’arrêt. Pour la température, je clique sur le bouton puis je fais glisser vers la gauche ou la droite pour l’augmenter ou la baisser.
      Pour moi, cela paraît assez intuitif. La prochaine fois que je conduirai, j’essaierai aussi la méthode de l’appui long pour éteindre, qui a l’air assez utile.
    • Sur le Model Y 2023, le Bluetooth fonctionne réellement bien. Ce n’était pas le cas dans mes anciennes Audi et Ford, donc j’en suis satisfait.
      Quand on voit que les implémentations sont presque toujours aussi mauvaises, je me demande si la spécification Bluetooth elle-même n’a pas quelque chose de sérieusement tordu.
    • Ça devrait être illégal.

  • J’ai possédé autrefois quelques boutons-poussoirs NASA ; ils contenaient deux ampoules. Quand l’interrupteur était éteint, les deux étaient éteintes, et quand on appuyait sur le bouton, une ampoule jaune s’allumait pour indiquer que la commande avait bien été prise en compte.
    Quand l’appareil que l’on voulait réellement allumer se mettait en marche, un voyant vert s’allumait et le jaune s’éteignait. L’état jaune confirmait en quelque sorte que l’interrupteur avait été basculé, et le vert que l’action souhaitée s’était effectivement produite : un mécanisme de retour d’état intéressant.

    • C’est une bonne approche, et les avions font aussi comme ça[1]. Ce genre de problème a déjà été résolu par des gens qui accordent énormément d’importance à l’utilisabilité, mais l’industrie informatique est lente à adopter ce genre de choses venant d’autres domaines.
      Mettre le libellé à l’extérieur de l’interrupteur fonctionne bien aussi[2].
      [1]: https://my737ng.com/wp-content/uploads/2014/08/cp_mcp_header...
      [2]: https://i.pinimg.com/originals/2c/37/0a/2c370a3f4018cfa9c3ef...
    • J’ai passé une bonne partie du début de ma carrière à écrire des logiciels GUI qui contrôlaient du matériel à distance et affichaient son état, et j’ai rapidement fini par exclure tous les éléments d’UI qui conservent leur propre état. Les éléments comme les bascules, interrupteurs, cases à cocher ou boutons radio, qui changent de comportement selon leur propre état, se retrouvaient assez souvent désynchronisés entre l’interface et l’état du matériel.
      À la place, je mettais un bouton pour chaque option, et le bouton correspondant à l’état actuel s’allumait. Par exemple, une bascule marche/arrêt devenait deux boutons, « on » et « off ». Au départ, les deux étaient gris ; quand on recevait du matériel un SOH indiquant l’état « allumé », le bouton on devenait vert, et s’il indiquait « éteint », le bouton off devenait rouge.
      Si la communication était interrompue pendant un moment, toutes les couleurs étaient atténuées pour signaler que l’état était ancien. Quand on appuyait sur un bouton, l’ancien état restait affiché jusqu’au retour du nouvel état, mais seul ce groupe de boutons était affiché en atténué.
      L’utilisateur pouvait à tout moment commander directement on ou off, quel que soit l’état supposé par l’UI. Une bascule, en revanche, ne peut passer qu’à « l’autre état ».
      Les boutons radio étaient eux aussi remplacés par des groupes de boutons portant les noms des états, et seul l’élément que l’UI considérait comme actuel recevait une couleur. La plupart des états neutres étaient en bleu ; quand il y avait une signification bon/attention/mauvais que l’opérateur voulait mettre en avant, on utilisait vert/jaune/rouge.
      C’était une conception atypique, mais les opérateurs la comprenaient généralement sans formation particulière. Les boutons ressemblaient à des boutons et semblaient cliquables, l’espacement montrait qu’ils formaient un groupe, et dans les UI des années 90, le gris étant la couleur par défaut, le bouton d’une autre couleur ressortait naturellement comme l’état actuel.
      Je ne sais pas si cela fonctionnerait encore dans un environnement actuel où les éléments d’UI utilisent toutes sortes de couleurs pour des raisons esthétiques ou pour pousser à la conversion, et ne transmettent de l’information qu’occasionnellement. Nous avons aussi expérimenté des affichages montrant simultanément l’état de la commande et l’état reçu, comme les boutons NASA, mais tout cela s’est révélé plus confus.
    • J’aime bien. Je ne comprends pas pourquoi notre secteur ne s’inspire pas plus souvent de l’aéronautique/du militaire, où un malentendu peut tuer des gens.

  • Ô case à cocher, 1990-2009. Elle était parfaite et sans ambiguïté, mais les designers de smartphones l’ont détestée pour une raison obscure.

    • Le plus drôle, c’est qu’on peut faire quelque chose qui est en pratique une case à cocher, assez joli et avec l’apparence d’une bascule. Ce n’est pas un bon exemple, mais cela montre qu’il n’est pas nécessaire que ce soit un carré avec une coche dedans : https://www.ranecommercial.com/legacy/hal/MobileHelp/Advance...
    • Le système de consultation médicale en visio/télémédecine que j’utilise a réussi à casser la case à cocher. Dans l’interface de messagerie directe, le libellé du champ de la case change selon qu’elle est cochée ou non.
      Non cochée, elle affiche « Not Urgent » ; cochée, « Urgent ». Je l’ai cochée plusieurs fois rapidement en pensant indiquer que ce n’était pas urgent, puis j’ai appuyé sur envoyer.
    • Je suis d’accord pour dire que la case à cocher est parfaite. Cela dit, c’est aussi parce qu’on n’essaie pas de remplir des formulaires sur smartphone.
      La case à cocher par défaut du navigateur est trop petite pour être facilement actionnée au pouce sur smartphone, donc difficile à utiliser souvent.
    • Qui a inventé le widget de case à cocher ? System 1 (1984) avait une « boîte avec x » équivalente à la coche dans les menus, mais à ma connaissance ce n’était pas encore vraiment une case à cocher.
    • Jony Ive est-il le Thomas Midgley Jr du design ? Il a popularisé avec iOS 7 le flat design à faible utilisabilité, et il est aussi responsable de la souris ronde de l’iMac et des claviers fragiles des MacBook.

  • Le pire exemple que j’aie vu est l’UI de l’écran de tableau de bord Tesla. Sur le dessin de la voiture, des libellés qui ne ressemblent pas à des boutons sont posés sur certaines parties, avec écrit « Open ».
    On lit clairement cela comme signifiant que cette partie est ouverte, mais ce n’est pas le sens réel. Ce libellé est un bouton pour ouvrir la partie en question, et l’utilisateur n’a aucun moyen de le savoir.

    • Exact. J’ai conduit une Tesla de location ce week-end, et j’ai été plusieurs fois confus et inquiet en pensant que les coffres avant et arrière étaient tous les deux ouverts.
    • D’accord à 100 %. C’est la deuxième chose la plus agaçante dans l’UX du coffre chez Tesla. La première, c’est l’animation beaucoup trop longue qu’il faut attendre après être passé en stationnement pour ouvrir le coffre.
      Globalement, l’UX de Tesla est très en avance sur celle des autres voitures, mais ces petites choses sont vraiment frustrantes.
    • Je ne trouve pas ça confus du tout. Le rendu de la voiture montre clairement l’état actuel du coffre, et quand on appuie sur le bouton d’ouverture, une animation montre aussi le coffre qui s’ouvre.
      Chacun semble le ressentir différemment.
    • Fait intéressant, c’est un problème lié à l’anglais. En anglais, le verbe et l’adjectif sont souvent identiques. En espagnol, « Abrir » (infinitif du verbe) et « Abierto » (adjectif) sont différents, donc ce cas ne se produit pas.
      On pourrait peut-être l’éviter avec quelque chose comme « Do open » ou « Is open », mais est-ce que cela sonnerait bizarre pour un locuteur natif ?
    • Est-ce une particularité propre à l’anglais ? Par exemple, en espagnol, le verbe et l’adjectif sont deux mots différents.

  • Le problème central d’un bouton à bascule, c’est qu’un même objet contient à la fois l’état du système et l’action qui le modifie.
    Du coup, le « ON » affiché sur le bouton n’indique pas clairement s’il s’agit de l’état actuel ou de l’action qui sera exécutée si on appuie dessus.
    La solution consiste à séparer, dans une certaine mesure, l’état et l’action. Il existe plusieurs façons de le faire, par exemple celle proposée dans l’une des réponses du lien : placer le libellé à l’extérieur du bouton.
    Si ce n’est pas un interrupteur mais un bouton à bascule comme dans l’exemple de Teams, on peut garder l’icône et modifier une autre propriété du bouton. Par exemple, comme on l’a fait sans problème pendant des décennies, le laisser enfoncé pour indiquer l’état « ON ».

    • Dans les propriétés système du son de Windows 11, il y a une option « Allow apps and Windows to use this device for audio », avec un bouton « Don't allow » à côté. Résultat : je n’ai absolument aucune idée de l’état actuel.

  • Je suis d’accord avec la conclusion, mais il faut que l’état actuel et l’état obtenu si l’on bascule soient tous deux clairs. Trop souvent, on finit par essayer de basculer pour se rendre compte ensuite qu’on n’avait pas besoin de le faire.
    Le cas lecture/pause est intéressant, parce qu’il semble aller à l’encontre de la conclusion. Mais il suit un précédent physique bien compris, et en général il est aussi clair que la musique ou la vidéo est en cours de lecture. Donc même si l’icône du bouton ne change pas, l’utilisateur comprend ce qui va se passer en appuyant dessus.
    Pour revenir aux bascules et aux interfaces, passer la couleur d’une bascule d’un gris clair à un gris à peine plus clair n’aide quasiment pas. Mettez un libellé. Si le libellé ne colle pas au motif de design, il faut trouver un meilleur designer.

    • Si l’on suit le précédent physique, l’image du bouton aurait dû montrer l’action, c’est-à-dire la lecture, et l’état visuel enfoncé/non enfoncé aurait dû indiquer si cette action est active.
      Les designers logiciels ne l’ont pas suivi et ont créé cette alternance entre les icônes lecture/pause, ce qui a engendré une nouvelle confusion. Ce n’était pas vraiment pour des raisons d’ergonomie, mais plutôt parce que les boutons 3D skeuomorphiques sont passés de mode.
      Le seul avantage de l’affichage de l’état apparaît quand il y a un problème. C’est particulièrement fréquent avec l’audio : muet, casque débranché, pilote audio Linux encore cassé, etc.
      Aujourd’hui encore, quand je vois un bouton lecture/pause, j’ai une légère dissonance cognitive, et je ne suis jamais sûr à 100 % de ce que signifie exactement le bouton pause ; quand il y a un souci, il m’arrive donc de simplement appuyer deux fois dessus.
    • Je suis d’accord avec l’idée que l’état actuel doit être clair. Avec un interrupteur de lumière, on n’a pas besoin de savoir quel sens veut dire « allumé », et en pratique on ne le sait pas. Il suffit de regarder si la lumière est allumée.
    • Dire « mettez un libellé ; si le libellé ne colle pas au motif de design, trouvez un meilleur designer » n’aide pas, et ce n’est pas réaliste, surtout sur mobile.
      Par exemple, Spotify n’a pas la place de mettre un libellé derrière chaque bouton. Il faut aussi de l’espace pour afficher la pochette de l’album, et c’est ce que je veux.
      Ce n’est pas une question de meilleur designer : les contraintes d’espace existent vraiment. Certaines fonctions doivent être accessibles en un seul tap. Je n’ai pas envie que le mode aléatoire soit caché derrière un menu contextuel.

  • Un bouton à bascule doit afficher l’état actuel. La case à cocher en est un bon exemple.
    Muted [] et Muted [x] sont assez clairs.
    Cela se complique quand le designer crée une UI où le lien entre les mots et le design visuel n’est pas clair. Par exemple, Mute Off [---( )] ou Mute On [( )---] mélangent une description d’état avec une action, et on ne sait plus ce que ça veut dire.

    • S’il y a assez de place, une imitation de bascule avec libellés des deux côtés fonctionne bien.
      Loudspeaker [()---] Crossed-out loudspeaker
    • Une coche est un tick[1]. Sur une page de statut[2], un tick signifie « opérationnel » et une croix signifie un échec. Du point de vue de ce qui est « évident », Muted [x] peut se lire comme si quelque chose avait échoué.
      Pour le comprendre autrement, il faut avoir appris l’UX des ordinateurs, ce qui est l’inverse de l’évidence. Ou alors cela peut vouloir dire que, comme dans « X marks the spot », c’est la cible sur laquelle cliquer quand on veut couper le son.
      [1] Unicode U+2714 https://www.compart.com/en/unicode/U+2714
      [2] p. ex. https://www.githubstatus.com/
    • Une case à cocher montre à la fois l’état actuel et le choix possible sous une forme simple oui/non.
      Un bouton à bascule est déroutant parce qu’on ne connaît pas l’intention du designer. C’est difficile à comprendre tant que les deux choix ne sont pas affichés ensemble.
      Mute On[---()]Off
    • Un bouton doit dire ce qu’il fait quand on clique dessus. Si l’on veut afficher l’état actuel, c’est un indicateur séparé, pas un bouton.
      Un bouton existe pour être cliqué, donc il doit communiquer ce qui se passera lorsqu’on cliquera dessus.
    • Dans les systèmes d’écriture de droite à gauche, faut-il aussi inverser les deux côtés ?

  • Il faut montrer les deux, comme un interrupteur analogique. Montrer clairement et sans ambiguïté l’état actuel, tout en montrant aussi l’état vers lequel on basculera.
    La bascule coulissante gauche-droite d’Apple y parvient vraiment bien. On voit clairement où se trouve actuellement la bascule, où elle va se déplacer, et si le réglage actuel active la fonction, avec un fond bleu, ou la désactive, avec un fond gris.

  • Un design que j’aimais bien avait un voyant d’état à côté de l’interrupteur, et ce voyant s’allumait quand l’état était activé, mais je n’arrive plus à le retrouver.
    Le meilleur point, c’est que cela résolvait aussi le délai des opérations asynchrones. Quand on appuyait sur l’interrupteur, il basculait, puis le voyant s’allumait un instant plus tard. C’était très satisfaisant, parce que l’interaction donnait la certitude d’avoir réellement fait quelque chose.

    • Sans voir le design réel, cela ressemble aussi à un exemple de l’ambiguïté traitée dans l’article. On ne sait pas si l’icône indique ce qui va se passer ou ce qui est en train de se passer.
      Le problème est de savoir s’il s’agit d’un état ou d’une action. Le design précis n’était peut-être pas ambigu, mais sa description seule l’est.
    • Si l’on revient sur cette page longtemps après et qu’on voit la lumière allumée, comment savoir si cela signifie que l’état actuel est ON ou que cliquer le fera passer à ON ? Y a-t-il un moyen de le distinguer immédiatement en regardant simplement la lumière allumée ?
    • Cela ressemble à une fonctionnalité d’interface qu’on voit sur des appareils « smart ». Je ne connais vraiment que les interrupteurs TP-Link Kasa, mais dans l’UI de leur app il y a aussi des icônes colorées avec plusieurs états, et il me semble que l’état le plus proche de « allumé » signifie que l’appareil a vérifié auprès de l’interrupteur qu’il était bien allumé.
    • Ce serait sans doute un bon cas d’usage pour un écran HDR. On pourrait rendre le « voyant » beaucoup plus lumineux que le reste de l’écran, pour montrer très clairement que la lumière est désormais allumée.
      Bien sûr, cela ne marcherait que si l’utilisateur n’a pas déjà réglé la luminosité de son écran beaucoup trop haut.