Sollte ein Toggle-Button den aktuellen Zustand anzeigen oder den Zustand, in den er wechseln wird? (2010)

• Wenn sofort auszuführende Aktionen wie Play/Pause und dauerhafte Einstellungen wie Shuffle mit demselben Toggle-Muster behandelt werden, können Nutzer den aktuellen Zustand und die nächste Aktion verwechseln
• About Face 2.0 empfiehlt, Flip-Flop-Buttons zu vermeiden, bei denen zwei Auswahlmöglichkeiten in einem Bedienelement stecken, und hält die Vermittlung des aktuellen Zustands für wichtiger als Platzersparnis
• Die Lösung geht eher dahin, die Aktion als Verbphrase zu formulieren, etwa Switch to portrait mode, oder Zustand und Wechsel über Radio-Buttons, Checkboxen oder Zustandslabel + Aktionsbutton zu trennen
• Wenn Text wie bei iOS-Schaltern im Button selbst steht, kann unklar sein, ob ON den aktuellen oder den nächsten Zustand meint; wenn Zustandstext wie bei OS X oder Windows Metro außerhalb des Buttons steht, sinkt die Mehrdeutigkeit
• Die Play/Pause-Konvention kann ausnahmsweise die nächste Aktion anzeigen, doch Optionen wie Shuffle, Like oder Auto save sollten sicherer den aktuellen Zustand betonen und dies mit Tooltips, Farbe, gedrücktem Zustand oder separatem Label ergänzen

---

Konflikt zwischen Zustandsanzeige und Aktionsanzeige

• Bei Buttons, die zwischen zwei Zuständen wechseln, etwa Play/Pause oder Shuffle/Regular Play, ist die Kernfrage, ob sie den aktuellen Zustand oder den Zielzustand nach dem Klick anzeigen sollen
• Play/Pause wird von Nutzern leicht als Aktion „Wiedergabe starten“ oder „pausieren“ verstanden; daher ist die Konvention vertraut, im gestoppten Zustand Play und während der Wiedergabe Pause anzuzeigen
• Shuffle/Regular Play ist eher ein Optionszustand für die Wiedergabeart; zeigt man den Zustand an, zu dem gewechselt wird, kann unklar werden, ob gerade Zufallswiedergabe oder sequenzielle Wiedergabe aktiv ist
• Der integrierte Musikplayer der Xbox 360 wird als Beispiel für Verwirrung genannt, weil er im Shuffle-Modus das Symbol für direkte Wiedergabe anzeigt und umgekehrt

Empfehlung aus About Face: Flip-Flop-Buttons vermeiden

• About Face 2.0 ordnet diesen Typ als Flip-Flop-Button ein, eine „zu vermeidende Auswahlkonvention“
• Wenn ein einzelner Button zwei sich gegenseitig ausschließende Optionen steuert, spart das zwar Platz, erfüllt aber die zweite Aufgabe eines Bedienelements nur schwer: den aktuellen Zustand zu vermitteln
• Wenn ein Button ON anzeigt, obwohl der aktuelle Zustand aus ist, ist der Einstellungszustand unklar; zeigt er im ausgeschalteten Zustand OFF, kann unklar sein, wo der ON-Button ist
• Empfohlen werden zwei Lösungen
  • Die Aktion des Buttons als Verbphrase ausschreiben, etwa Switch to portrait mode
  • Eine andere UI-Technik verwenden, bei der die Zustandsauswahl sichtbar ist, etwa zwei Radio-Buttons

Aktionsbuttons und Zustandsbuttons unterscheiden

• Action Buttons und State Buttons sollten unterschiedlich gestaltet werden
  • Bei einer Aktion wie Play/Pause zeigt man, was beim Klick passiert
  • Bei einer Option wie Shuffle/Linear zeigt man den aktuellen Zustand
• Wenn ein Shuffle-Button nur aus einem Icon besteht, ist es passend, ein einziges Shuffle-Icon beizubehalten und es je nach Zustand aktiv/inaktiv wirken zu lassen
  • Im eingeschalteten Zustand heller darstellen oder wie einen gedrückten Button aussehen lassen
  • Im ausgeschalteten Zustand sollte sofort erkennbar sein, dass sequenzielle Wiedergabe aktiv ist
  • In Umgebungen mit Hover kann ein Tooltip ergänzt werden, um es noch klarer zu machen
• Es gibt auch die Ansicht, dass sich Verwirrung bei Play/Pause reduzieren lässt, wenn das Label nicht wechselt und stattdessen der Play-Button als gedrückt angezeigt wird

Mehrdeutigkeit durch Text im Button

• ON und OFF können im Englischen sowohl als Zustand als auch als Umschaltaktion gelesen werden; im Button platziert, kann daher verschwimmen, ob es sich um Zustand oder Befehl handelt
• Als eindeutigere Wortpaare wurden folgende Ausdrücke vorgeschlagen
  • Enable / Disable
  • Enabled / Disabled
  • Start / Stop
  • Running / Stopped
• Allein durch die Wortwahl verschwindet das Problem nicht vollständig
  • Nutzer müssen weiterhin möglicherweise beurteilen, ob der Buttontext Zustand oder Befehl ist
  • Der Unterschied zwischen Enable und Enabled ist innerhalb einer UI möglicherweise nicht deutlich genug

Labels außerhalb des Buttons und Trennung von Zustand + Aktion

• Wenn man keinen Text in den Button selbst setzt, sondern Text außerhalb des Buttons platziert, lassen sich aktueller Zustand und möglicher Wechselzustand gemeinsam anzeigen
• Ein Schalter im OS-X-Stil sagt nicht selbst ON oder OFF; der Text rund um den Schalter zeigt den Zustand an und reduziert damit die Frage „Ist dieser Button der aktuelle Zustand oder die nächste Aktion?“
• Der Windows-Metro-UI-Ansatz zeigt den aktuellen Zustand über die Buttonfarbe an und bestätigt ihn zusätzlich mit dem Text On/Off unter dem Optionstext
• Auch eine Aufteilung in Zustandslabel + Aktionsbutton ist möglich, etwa Online [Go offline]
  • Online ist ein nicht klickbares Label für den aktuellen Zustand
  • Go offline ist die klickbare Umschaltaktion
  • Nach dem Klick wird daraus Offline [Go online]
• Diese Methode ist kompakter als Radio-Buttons und kann zugleich die visuellen Rollen von Zustand und Aktion trennen

Checkboxen, Radio-Buttons und gedrückter Zustand

• Optionen wie Shuffle lassen sich als Checkbox mit dem Label Shuffle darstellen, wodurch weniger Verwirrung entsteht
• Wenn man ein einzelnes Wort verwendet und den Aktivierungsstatus über den Haken zeigt, sinkt die Belastung, Bedeutungen zwischen mehreren Wörtern interpretieren zu müssen
• Formulierungen mit negierenden Präfixen sollte man eher vermeiden
  • Präfixe wie Not, Non-, Un-, Dis-, Im-, Mis-, In-, Il-, Ir- können in Kombination mit einem deaktivierten Zustand wie eine doppelte Verneinung gelesen werden
• Der Like-Button der Facebook-Android-App ist ein Beispiel: ausgeschaltet grau, eingeschaltet blau hervorgehoben
  • Farbe allein reicht für Nutzer mit Farbsehschwäche allerdings möglicherweise nicht aus

Beispiele aus realen UIs und Vorsichtspunkte

• Ein Kompromiss ist die Verwendung einer neutralen Farbe im ausgeschalteten Zustand und einer Akzentfarbe im eingeschalteten Zustand, wie beim Shuffle-Button der Spotify-Webapp
• Der Twitter-artige Hover-Wechsel zeigt zunächst den aktuellen Zustand und beim Überfahren mit der Maus die Aktion
  • In Umgebungen mit Hover kann das funktionieren, auf Touchscreens gilt derselbe Ansatz aber möglicherweise nicht
• iOS-Schalter zeigen beide Zustände in einem Bedienelement, werden aber auch dafür kritisiert, dass unklar sein kann, ob ON der aktuelle Zustand ist oder der Zustand, zu dem man durch Tippen wechselt
• Die Einstellungs-UI von Discord ist ein Beispiel für einen checkboxartigen Toggle, der aktuellen und künftigen Zustand klarer macht
• Es gibt auch Beispiele wie Evernotes Mouseover-Toggle oder den Türgriffschalter in Flugzeugtoiletten, bei denen Zustand und Bedienbarkeit gleichzeitig erkennbar sind

Gestaltungsprinzipien

• Wenn ein Bedienelement zugleich Zustand vermitteln und Aktion vermitteln soll, entsteht Mehrdeutigkeit
• Der aktuelle Zustand muss in irgendeiner Form unbedingt vermittelt werden
  • Bei Play/Pause können externe Rückmeldungen wie hörbare Musik oder fortschreitende Zeit den aktuellen Zustand ergänzen
  • Bei Shuffle ist der Zustand schwer zu erkennen, bis man sieht, wie der nächste Titel tatsächlich ausgewählt wird; daher ist die Zustandsanzeige am Button selbst wichtiger
• Ein einzelner Button, der durch mehrere Zustände rotiert, kann die UI verdichten und sich gegenseitig ausschließende Einstellungen bündeln, aber Nutzer müssen den aktuellen Zustand schnell erfassen können
• Wegen der starken Konvention kann Play/Pause eine Ausnahme sein, die die nächste Aktion anzeigt; bei gewöhnlichen Options-Toggles ist es konsistenter, den aktuellen Zustand hervorzuheben

[GN⁺]

Meinungen auf Hacker News

• Microsoft Teams frustriert mich derzeit wirklich. In der Desktop-App sieht man im stummgeschalteten Zustand ein Mikrofon-Icon mit einem Strich darüber, und wenn die Stummschaltung aufgehoben ist, wechselt es zu einem Mikrofon ohne Strich – das ist leicht zu verstehen.
  Wenn man aber über die Smartphone-App teilnimmt, bedeutet dasselbe durchgestrichene Mikrofon-Icon: „derzeit nicht stummgeschaltet; wenn du diesen Button drückst, wirst du stummgeschaltet“. Auch nach dem Drücken bleibt das Icon ein durchgestrichenes Mikrofon, nur der Hintergrund wird invertiert.
  Vielleicht ist es so, dass die eine Seite ein „Mikrofon einschalten“-Button ist und die andere ein „Stummschaltung einschalten“-Button, und deshalb dasselbe Icon verwendet wird. Am Ende muss man wissen, wie der Button im jeweils gegenteiligen Zustand aussieht, um den aktuellen Zustand beurteilen zu können, sodass ich immer ein paarmal herumdrücke, um herauszufinden, welchen Ansatz diese App verwendet.
  Ich frage mich, ob das der Preis von Flat UI ist, das seine Referenzen aus der realen Welt verloren hat.

  • Ein Teil dieser Verwirrung kommt meiner Meinung nach aus der Denkweise, dass das Mikrofon standardmäßig eingeschaltet ist. Das Muster, bei dem „Mikrofon aktiv“ der Normalzustand ist und Stummschalten als Abweichung davon behandelt wird, reicht von UIs für Telefonkonferenzsysteme über analoge Telefone bis noch weiter zurück in die Zeit, als zwischen den Teilnehmern tatsächlich eine Leitung verbunden war.
    Audio-Mischpulte für Livemusik oder Aufnahmen verwenden normalerweise dasselbe Muster. Wenn ein Kanal ausgeschaltet ist, leuchtet ein roter „Mute“-Button; nur manche Geräte haben oberhalb des Faders einen „ON“-Button, der leuchtet und den aktiven Zustand des Kanals anzeigt.
    Ich finde, es ist an der Zeit, dass auch Meeting-Apps zu einem Ansatz wechseln, bei dem Audio standardmäßig aus ist. Man sieht das schon ein wenig daran, dass UI-Elemente aufleuchten, wenn eine sprechende Person redet.
  • Das ist wirklich ein Button, der nicht verwirrend sein darf.
  • Auch bei Plex ist es ähnlich frustrierend, weil die UI je nach App unterschiedlich ist. Wenn man sich auf dem Smartphone eine Staffel einer TV-Serie ansieht, haben bereits gesehene Folgen ein blaues Häkchen; sieht man dieselbe Staffel auf dem Fernseher, gibt es kein blaues Häkchen, sondern ungesehene Folgen haben ein gelbes Dreieck.
    Jedes Mal, wenn ich zwischen Geräten wechsle, stockt mein Gehirn kurz.
  • Discord ist noch schlimmer. Der Button zum Stummschalten des Mikrofons und der Button zum Ausschalten der Kamera funktionieren nach genau gegensätzlichen Prinzipien.
  • Am Problem der Mikrofonanzeige/-steuerung gibt es einen ziemlich interessanten Aspekt. Ohne direktes visuelles Feedback weiß man nicht, in welchem Modus das Mikrofon ist, bis andere reagieren oder eben nicht reagieren.
    Selbst wenn es eingeschaltet ist, ist es ein Werkzeug mit hoher Feedback-Latenz. Die andere Person hat vielleicht innegehalten oder denkt vor der Antwort nach, sodass man oft zwei- oder dreimal testen muss, bis man sicher ist.
    Das ist anders als beim Dark Mode, den man beim Ein- und Ausschalten sofort sieht. Deshalb hilft eine visuelle Anzeige des aktuellen Zustands sehr, egal welche Aktion der Button ausführt, und es überrascht nicht, dass gerade beim Mikrofon viele Versuche entstehen, „Zustand“ und „Steuerung“ zu vermischen.

• Als Tesla-Besitzer kann man dem nur zustimmen. Die Toggle-Buttons im Auto-UI sind so unterschiedlich, dass es weder Konsistenz noch Standards gibt.
  Zum Beispiel ist der Button der Klimaanlage ein einzelner Button, der die Temperatur anzeigt, aber je nachdem, wie und wie lange man ihn drückt, reagiert er unterschiedlich. Ein kurzer Druck öffnet ein kleines Pop-up, ein etwas längerer Druck öffnet das komplette Bedienfeld für die Klimaanlage, und wenn man ihn ein paar Sekunden gedrückt hält, kann die eingeschaltete Klimaanlage ausgeschaltet werden. Das Problem ist, dass man all das während der Fahrt tun muss, während man auf die Straße achten sollte.
  Wenn die Hand-Auge-Koordination nur ein wenig danebenliegt – was besonders wahrscheinlich ist, wenn man während der Fahrt über Unebenheiten fährt –, kann man schon bei 1 mm Abweichung einen anderen Button drücken und eine unbeabsichtigte Aktion auslösen.
  Eine weitere Katastrophe ist die UX zum Verbinden von Bluetooth-Geräten. Zumindest die Implementierung im Model S von 2012–2022 war eines der schlimmsten UI-Durcheinander, die ich je in einem ausgelieferten Produkt gesehen habe. Der Button unten rechts zeigt auch nach bereits hergestellter Verbindung weiter „Connect“ an, während auf der gegenüberliegenden Bildschirmseite oben links erst „Connecting...“ steht und dann die abgeschlossene Verbindung angezeigt wird.
  Auch das ist eine UI im Auto, die man während der Fahrt nur für einen Augenblick ansehen kann. Allein mit der Tesla-Bluetooth-UI könnte man ein ganzes Kapitel eines UI-Buchs füllen – so beeindruckend schlecht ist sie.

  • In der Tesla-Mobile-App sind sogar direkt nebeneinanderliegende Toggles untereinander inkonsistent.
    Ein geschlossenes Schloss bedeutet, dass die Türen verriegelt sind; drückt man darauf, werden die Türen geöffnet.
    Das Wort „Open“ am Kofferraum bedeutet, dass der Kofferraum geschlossen ist; drückt man darauf, öffnet sich der Kofferraum.
  • So einen Artikel sollte man selbst schreiben. Analysen dieser Art sind immer interessant, und wenn das Thema Tesla ist, kommt noch Elon dazu, was vermutlich noch mehr Aufmerksamkeit bringt.
  • So benutze ich den Klimaanlagen-Button: Zuerst schaue ich auf den Button; wenn er leicht transparent ist und ich einschalten möchte, klicke ich einfach darauf, dann schaltet er sich ein. Wenn ich erneut klicke, öffnet sich die vollständige Steuerung, und wenn ich nach unten wische, schließt sie sich.
    Wenn ich ausschalten möchte, drücke ich den Button erneut, um die vollständige Steuerung zu öffnen, und drücke dann den Ausschalt-Button. Die Temperatur erhöhe oder senke ich, indem ich nach dem Klick auf den Button nach links oder rechts wische.
    Für mich wirkt das ziemlich intuitiv. Beim nächsten Fahren werde ich auch ausprobieren, ob man durch langes Drücken ausschalten kann; das scheint ziemlich nützlich zu sein.
  • Beim Model Y des Jahrgangs 2023 funktioniert Bluetooth tatsächlich gut. Bei meinem früheren Audi und Ford war das nicht so, deshalb bin ich zufrieden.
    Wenn Implementierungen immer so schlecht sind, frage ich mich, ob in der Bluetooth-Spezifikation selbst nicht irgendetwas ernsthaft verkorkst ist.
  • Das sollte illegal sein

• Früher hatte ich ein paar NASA-Drucktastenschalter, in denen zwei Glühlampen steckten. Wenn der Schalter aus war, waren beide aus; drückte man den Knopf, ging die gelbe Lampe an und zeigte, dass die Schalterbetätigung angenommen wurde.
  Wenn das Gerät, das man tatsächlich einschalten wollte, anging, leuchtete Grün und Gelb ging aus. Der gelbe Zustand war also die Bestätigung, dass man den Schalter umgelegt hatte, und Grün die Bestätigung, dass die gewünschte Aktion tatsächlich stattgefunden hatte – ein interessantes Status-Feedback-Verfahren.

  • Gute Lösung, und Flugzeuge machen das auch so[1]. Solche Probleme haben Leute, denen Usability sehr wichtig ist, längst gelöst; die Computerbranche ist nur langsam darin, solche Dinge aus anderen Bereichen zu übernehmen.
    Auch die Variante mit einem Label außerhalb des Schalters funktioniert gut[2].
    [1]: https://my737ng.com/wp-content/uploads/2014/08/cp_mcp_header...
    [2]: https://i.pinimg.com/originals/2c/37/0a/2c370a3f4018cfa9c3ef...
  • Einen großen Teil meiner frühen Laufbahn habe ich damit verbracht, GUI-Software zu schreiben, die entfernte Hardware steuert und ihren Zustand anzeigt, und ich habe bald alle UI-Elemente, die ihren Zustand selbst speichern, ausgeschlossen. Bei Toggles, Schaltern, Checkboxen und Radiobuttons – also Elementen, deren Verhalten sich je nach eigenem Zustand ändert – kam es nicht selten vor, dass Interface und Hardwarezustand auseinanderliefen.
    Stattdessen habe ich für jede Option einen eigenen Button verwendet und den Button leuchten lassen, der dem aktuellen Zustand entsprach. Aus einem Ein/Aus-Toggle wurden zum Beispiel zwei Buttons, „on“ und „off“. Anfangs waren beide grau; wenn von der Hardware ein SOH mit Status „ein“ kam, wurde der on-Button grün, bei „aus“ wurde der off-Button rot.
    Wenn die Kommunikation eine Weile unterbrochen war, wurden alle Farben blasser dargestellt, um zu zeigen, dass der Status veraltet war. Drückte man einen Button, wurde der bisherige Zustand weiter angezeigt, bis der neue Status zurückkam, aber nur diese Button-Gruppe wurde ausgegraut.
    Nutzer konnten jederzeit direkt on oder off befehlen, unabhängig davon, welchen Zustand die UI gerade annahm. Ein Toggle dagegen kann nur in den „anderen Zustand“ wechseln.
    Radiobuttons ersetzte ich ebenfalls durch Gruppen von Buttons mit Zustandsnamen; nur der Eintrag, den die UI für den aktuellen hielt, bekam Farbe. Die meisten neutralen Zustände waren blau; wenn etwas eine Bedeutung wie gut/Vorsicht/schlecht hatte, die der Operator hervorgehoben sehen sollte, verwendeten wir Grün/Gelb/Rot.
    Es war ein ungewöhnliches Design, aber die Operatoren verstanden es meist ohne gesonderte Schulung. Die Buttons sahen aus wie Buttons und damit klickbar, der Abstand machte die Gruppierung sichtbar, und in UIs der 90er war Grau der Standard, sodass ein andersfarbiger Button ganz natürlich als aktueller Zustand auffiel.
    Ob das auch in heutigen Umgebungen noch funktioniert, in denen UI-Elemente aus ästhetischen Gründen oder zur Conversion-Lenkung beliebige Farben verwenden und nur gelegentlich Informationen vermitteln, weiß ich nicht. Wir experimentierten auch mit einer Darstellung wie bei den NASA-Buttons, die Befehlszustand und empfangenen Zustand gleichzeitig zeigte, aber das war alles verwirrender.
  • Gefällt mir. Ich weiß nicht, warum unsere Branche nicht häufiger auf Luftfahrt und Militär schaut, wo Missverständnisse Menschen töten können.

• Oh Checkbox, 1990–2009. Sie war perfekt und eindeutig, aber Smartphone-Designer mochten sie aus irgendeinem Grund nicht.

  • Noch absurder ist, dass man etwas, das im Grunde eine Checkbox ist, ziemlich hübsch und wie einen Toggle aussehen lassen kann. Kein großartiges Beispiel, aber es zeigt, dass es nicht zwingend ein Quadrat mit Häkchen sein muss: https://www.ranecommercial.com/legacy/hal/MobileHelp/Advance...
  • Das medizinische Video-/Telemedizin-System, das ich nutze, hat Checkboxen kaputtgemacht. In der Direktnachrichten-Oberfläche ändert es je nach Häkchen den Labeltext des Checkbox-Felds.
    Nicht angehakt steht dort „Not Urgent“, angehakt „Urgent“. Ich habe mehrmals schnell geklickt, dachte, ich hätte „nicht dringend“ markiert, und dann auf Senden gedrückt.
  • Ich stimme zu, dass Checkboxen perfekt sind. Allerdings liegt es auch daran, dass man auf Smartphones ungern Formulare ausfüllt.
    Die Standard-Checkbox im Browser ist auf dem Smartphone zu klein, um sie bequem mit dem Daumen zu treffen, und daher schwer regelmäßig zu nutzen.
  • Wer hat das Checkbox-Widget eigentlich erfunden? System 1 (1984) hatte eine „x box“, die den Häkchen in Menüs entsprach, aber soweit ich weiß keine Checkbox im eigentlichen Sinn war.
  • Ist Jony Ive der Thomas Midgley Jr. der Designwelt? Mit iOS 7 hat er schlecht benutzbares Flat Design populär gemacht und trägt auch Verantwortung für die runde iMac-Maus und die fragilen MacBook-Tastaturen.

• Das schlimmste Beispiel, das ich gesehen habe, ist die Tesla-Dashboard-Bildschirm-UI. Auf der Abbildung des Autos kleben Labels, die nicht wie Buttons aussehen, und darauf steht „Open“.
  Das liest sich eindeutig so, als sei dieser Teil offen, aber das ist nicht gemeint. Das Label ist ein Button zum Öffnen dieses Teils, und Nutzer können das nicht wissen.

  • Genau. Ich bin dieses Wochenende einen gemieteten Tesla gefahren und war mehrmals verwirrt und irritiert, weil ich dachte, vorderer und hinterer Kofferraum seien beide offen.
  • 100 % Zustimmung. Das ist der zweitnervigste Punkt der Tesla-Kofferraum-UX. Der erste ist die viel zu lange Animation, auf die man warten muss, nachdem man auf Parken geschaltet hat, um den Kofferraum zu öffnen.
    Insgesamt ist Teslas UX anderen Autos weit voraus, aber solche Kleinigkeiten sind extrem nervig.
  • Ich finde das überhaupt nicht verwirrend. Das gerenderte Auto zeigt den aktuellen Zustand des Kofferraums klar an, und wenn man den Öffnen-Button drückt, sieht man auch eine Animation, wie der Kofferraum aufgeht.
    Offenbar empfindet das jeder anders.
  • Interessanterweise ist das ein Problem des Englischen. Im Englischen sind Verb und Adjektiv oft identisch. Auf Spanisch wären „Abrir“ (Infinitiv) und „Abierto“ (Adjektiv) verschieden, sodass das nicht passieren würde.
    Mit Formulierungen wie „Do open“ oder „Is open“ ließe sich das vermutlich vermeiden, aber klingt das für Muttersprachler unnatürlich?
  • Ist das eine Eigenschaft, die nur Englisch hat? Im Spanischen zum Beispiel sind Verb und Adjektiv unterschiedliche Wörter.

• Das Kernproblem von Toggle-Buttons ist, dass ein einziges Objekt zugleich den Zustand des Systems und die Aktion enthält, die diesen Zustand ändert.
  Deshalb ist nicht klar, ob das auf dem Button sichtbare „ON“ der aktuelle Zustand ist oder die Aktion, die beim Drücken ausgeführt wird.
  Die Lösung besteht darin, Zustand und Aktion bis zu einem gewissen Grad zu trennen. Dafür gibt es mehrere Möglichkeiten; eine ist, wie in einer der Antworten im Link, das Label außerhalb des Buttons zu platzieren.
  Wenn es kein Schalter ist, sondern ein Toggle-Button wie im Teams-Beispiel, kann das Icon gleich bleiben und man ändert eine andere Eigenschaft des Buttons. Zum Beispiel, indem er – wie seit Jahrzehnten problemlos praktiziert – gedrückt bleibt, um den Zustand „ON“ anzuzeigen.

  • In den Systemeigenschaften für Sound von Windows 11 gibt es die Option „Allow apps and Windows to use this device for audio“ und daneben einen Button „Don't allow“. Dadurch weiß man überhaupt nicht, was der aktuelle Zustand ist.

• Dem Fazit stimme ich zu, aber sowohl der aktuelle Zustand als auch der Zustand nach dem Umschalten müssen klar sein. Allzu oft probiert man einen Toggle erst aus und merkt danach, dass man ihn gar nicht hätte ändern müssen.
  Der Punkt mit Wiedergabe/Pause ist interessant, weil er dem Fazit zu widersprechen scheint. Er folgt aber einem gut verstandenen physischen Vorbild, und normalerweise ist auch klar, ob Musik oder Video gerade läuft. Deshalb versteht der Nutzer, was passiert, wenn er drückt, auch wenn sich das Button-Icon nicht ändert.
  Zurück zu Toggles und UI: Die Toggle-Farbe von Hellgrau zu einem minimal helleren Grau zu ändern, ist extrem wenig hilfreich. Bitte fügt ein Label hinzu. Wenn ein Label nicht zum Designmotiv passt, braucht ihr bessere Designer.

  • Bei einem physischen Vorbild hätte das Button-Bild die Aktion zeigen müssen, also Wiedergabe, und der visuelle Zustand gedrückt/nicht gedrückt hätte anzeigen müssen, ob diese Aktion aktiv ist.
    Software-Designer sind dem nicht gefolgt und haben stattdessen das Umschalten zwischen Wiedergabe- und Pause-Icon erfunden, was neue Verwirrung geschaffen hat. Nicht aus Gründen der Nutzerfreundlichkeit, sondern eher, weil skeuomorphe 3D-Buttons aus der Mode kamen.
    Der einzige Vorteil der Zustandsanzeige zeigt sich, wenn etwas schiefläuft. Besonders bei Audio ist das sehr häufig: Stummschaltung, abgezogene Kopfhörer, der Linux-Audiotreiber ist schon wieder kaputt und dergleichen.
    Selbst heute bekomme ich beim Anblick eines Wiedergabe/Pause-Buttons noch eine leichte kognitive Dissonanz, und ich bin mir nicht zu 100 % sicher, was der Pause-Button genau bedeutet; wenn es ein Problem gibt, drücke ich manchmal einfach zweimal.
  • Ich stimme zu, dass der aktuelle Zustand klar sein muss. Bei einem Lichtschalter muss man nicht wissen, in welche Richtung „an“ ist, und tatsächlich weiß man es oft nicht. Man sieht ja, ob das Licht an ist.
  • „Fügt ein Label hinzu; wenn ein Label nicht zum Designmotiv passt, braucht ihr bessere Designer“ ist besonders auf Mobilgeräten nicht hilfreich und unrealistisch.
    Bei Spotify zum Beispiel gibt es keinen Platz, hinter jeden Button ein Label zu setzen. Es muss auch Platz für Albumcover bleiben, und den will ich haben.
    Das ist kein Problem besserer Designer; Platzbeschränkungen existieren real. Manche Funktionen müssen mit einem einzigen Tippen direkt erreichbar sein. Ich möchte Shuffle nicht hinter einem Popup-Menü verstecken.

• Toggle-Buttons sollten den aktuellen Zustand zeigen. Eine Checkbox ist ein gutes Beispiel.
  Muted [] und Muted [x] sind ziemlich eindeutig.
  Schwierig wird es, wenn Designer eine UI bauen, bei der die Verbindung zwischen Wörtern und visuellem Design nicht klar ist. Zum Beispiel ist bei Mute Off [---( )], Mute On [( )---] nicht klar, was gemeint ist, weil in die Zustandsbeschreibung eine Aktion hineingemischt wird.

  • Wenn genug Platz vorhanden ist, funktioniert die Nachahmung eines Toggles mit Labels auf beiden Seiten gut.
    Lautsprecher [()---] durchgestrichener Lautsprecher
  • Ein Häkchen ist ein Tick[1]. Auf Statusseiten[2] bedeutet ein Häkchen „in Betrieb“, ein Kreuz dagegen Fehler. Unter dem Gesichtspunkt der „Offensichtlichkeit“ kann Muted [x] also so gelesen werden, als sei etwas fehlgeschlagen.
    Um es anders zu verstehen, braucht man erlernte Computer-UX, und das ist das Gegenteil von offensichtlich. Oder es könnte, wie bei „X marks the spot“, das Ziel bedeuten, das man anklicken soll, wenn man Stummschaltung möchte.
    [1] Unicode U+2714 https://www.compart.com/en/unicode/U+2714
    [2] z. B. https://www.githubstatus.com/
  • Eine Checkbox zeigt den aktuellen Zustand und die mögliche Auswahl gemeinsam in einfacher Ja/Nein-Form.
    Ein Toggle-Button ist verwirrend, weil man die Absicht des Designers nicht kennt. Solange nicht beide Auswahlmöglichkeiten zusammen gezeigt werden, ist es schwer zu wissen.
    Mute On[---()]Off
  • Ein Button sollte sagen, was er tut, wenn man ihn anklickt. Wenn man den aktuellen Zustand anzeigen möchte, ist das eine separate Anzeige und kein Button.
    Ein Button existiert, um angeklickt zu werden, also sollte er vermitteln, was beim Klicken passiert.
  • Sollten bei Schriftsystemen von rechts nach links auch die beiden Seiten vertauscht werden?

• Wie bei einem analogen Schalter sollte beides gezeigt werden. Er sollte den aktuellen Zustand klar und unmissverständlich zeigen und zugleich den Zustand, zu dem gewechselt wird.
  Apples Links-rechts-Slider-Toggle hat das wirklich gut gelöst. Man sieht klar, wo der Toggle gerade steht, wohin er wechseln wird und ob die aktuelle Einstellung die Funktion aktiviert – mit blauem Hintergrund – oder deaktiviert – mit grauem Hintergrund.

• Eines der Designs, die ich mochte, hatte neben dem Schalter eine Statusleuchte, die anging, wenn der Zustand eingeschaltet war; ich kann es jetzt aber nicht mehr finden.
  Das Beste daran war, dass es auch Verzögerungen bei asynchronen Vorgängen löste. Man drückte den Schalter, der Schalter toggelte, und kurz darauf ging die Leuchte an. Das war sehr befriedigend, weil es die Sicherheit gab, dass die Interaktion tatsächlich etwas bewirkt hatte.

  • Ohne das tatsächliche Design gesehen zu haben, wirkt auch das wie ein Beispiel für die im Text behandelte Mehrdeutigkeit. Es ist unklar, ob das Icon bedeutet, was als Nächstes passieren wird, oder was gerade passiert.
    Zustand oder Aktion – das ist das Problem. Ein konkretes Design mag eindeutig gewesen sein, aber aus der Beschreibung allein ist es das nicht.
  • Wenn man nach langer Zeit wieder auf diese Seite kommt und sieht, dass das Licht leuchtet: Woher weiß man dann, ob das bedeutet, dass der aktuelle Zustand ON ist, oder dass er beim Klicken zu ON wechselt? Gibt es eine Möglichkeit, das allein am leuchtenden Licht sofort zu unterscheiden?
  • Klingt wie eine Interface-Funktion, die man bei „smarten“ Geräten sieht. Ich kenne nur TP-Link Kasa-Schalter, aber auch in deren App-UI haben farbige Icons offenbar mehrere Zustände; der Zustand, der „an“ am nächsten kommt, bedeutete meines Erachtens, dass die App mit dem Schalter abgeglichen hatte, dass er eingeschaltet ist.
  • Das wäre wohl ein guter Anwendungsfall für HDR-Displays. Man könnte die „Kontrollleuchte“ viel heller machen als den Rest des Bildschirms und damit sehr klar zeigen, dass das Licht jetzt an ist.
    Natürlich funktioniert das nur, wenn der Nutzer die Bildschirmhelligkeit nicht ohnehin viel zu hoch eingestellt hat.