UI-Design: Checkbox oder Toggle?

Eine Checkbox hat drei Status, wie das Bild es auch zeigt:

• Ausgewählt
• Nicht ausgewählt
• Teilweise ausgewählt

Der dritte Status tritt immer dann auf, wenn sich unter einem selektierbaren Objekt noch weitere Objekte befinden, die die Benutzer:innen auswählen können. Dies passiert bspw. bei Bäumen oder Listen.

Die Metapher von Checkboxen ist relativ offensichtlich. Sie kommen vor allem auch in papierbasierten Formularen vor. Denken wir nur an Wahlzettel oder sonstige Fragebögen. Hier können wir stets auswählen und unsere Auswahl durch ein Kreuz markieren. Der dritte Status existiert jedoch nur in digitalen Checkboxen.

Ein Toggle hat im Gegensatz zur Checkbox nur zwei Status:

• An
• Aus

Meine Formulierung der beiden Status zeigt auch schon an, was die Metapher hinter Toggles ist: Schalter. Genau das ist im Übrigen auch die englische Übersetzung des Wort “toggle”: (Kipp)-Schalter

Damit wird auch schon deutlich, wann ein Toggle eingesetzt werden sollte. Ein Toggle zeigt nämlich nicht nur den Status an. Sobald Benutzer:innen ihn betätigen, wird eine Aktion ausgeführt, vergleichbar mit einem Schalter z.B. an Steckdosenleisten. An der Schalterstellung kann man erkennen, ob die Leiste an oder aus ist. Sobald man ihn betätigt, beginnt nicht nur der Schalter zu leuchten. Zusätzlich beginnt die Versorgung der Steckdosen mit Strom.

Ein Toggle sollte dann verwendet werden, wenn sich hinter der (De-)Selektion der Benutzer:innen zusätzlich eine Aktion verbirgt. So wird diese Aktion automatisch, d.h. ohne eine weitere Aktion der Benutzer:innen bei der Interaktion ausgeführt.

Das System kann sofort Rückmeldung über den Erfolg oder Misserfolg der Aktion liefern, falls dies nötig ist. So kann bei der Selektion eine Fehlermeldung erscheinen, falls die entsprechende Aktion nicht erfolgreich war, z.B. wenn Bluetooth nicht aktiviert werden kann, oder die geforderten zusätzlichen Felder nicht ein- oder ausgeblendet werden können.

Durch die Anwendung eines Toggles suggeriert man den Benutzer:innen auch klar, dass sie hier nicht nur eine Auswahl tätigen, sondern zusätzlich sofort die entsprechende Aktion durchführen.

Eine Checkbox sollte immer dann angewendet werden, wenn die Auswahl keine sofortige Aktion zur Folge hat. Wenn man also Einstellungen für das System durchführt, haben diese im Normalfall nicht sofort Auswirkungen auf die aktuelle Ansicht. Die Auswirkungen zeigen sich erst, wenn die Auswahl gespeichert wurde und die entsprechende Aktion auftritt.

Dies impliziert auch, dass bei Einstellungen immer ein zusätzlich Buttons benötigen, mit denen die Änderungen gespeichert bzw. verworfen werden können.

Eines der Beispiele, das auch im Bild gezeigt ist, behandelt das Abonnieren von Newslettern. Die Auswahl dieser Option hat keine sofortige Aktion zur Folge. Diese Einstellung wird erst beim Versenden des nächsten Newsletters vom System relevant.

Bei Multiple Choice, also wenn die Benutzer:innen unter mehreren Optionen beliebig viele wählen können, werden i.d.R. Checkboxen angewandt. Normalerweise werden bei Multiple Choice Optionen zur Wahl angeboten, die keine direkten Aktionen mit sich bringen.

Selbst wenn die einzelnen Optionen implizite Aktionen beinhalten, ist die Checkbox die richtige Wahl. Hintergrund davon ist, dass jede Aktion, die vom System durchgeführt wird, Zeit in Anspruch nimmt. Da man den Benutzer:innen aber viele mögliche Optionen anbietet, werden sie dieser Auffordung auch nachkommen. Das bedeutet allerdings, dass für jede gewählte Option der Benutzer:innen Zeit verloren geht. Dieses Verhalten einer Oberfläche kann für Benutzer:innen sehr anstrengend sein und dient daher nicht der Verbesserung der Usability.

Besser ist in einem solchen Fall, wenn die Oberfläche einen zusätzlichen Button aufweist, mit dem Benutzer:innen die Änderungen nehmen und alle Aktionen auf einmal ausgeführen können. So können die Benutzer:innen in Ruhe ihre Auswahl treffen und alle Aktionen auf einmal in Auftrag geben.

Bei hierarchischen Elementen, d.h. wenn unter einer Option weitere Kind-Elemente vorhanden sind, sind Checkboxen die richtige Wahl. Grund dafür ist, dass nur Checkboxen den Status “teilweise ausgewählt” darstellen können. So kann den Benutzer:innen klargemacht werden, dass eine Teilmenge der untergeordneten Elemente ausgewählt ist. Diese Anzeige ist mit Toggles nicht möglich.

Hier gilt auch wie im vorigen Beispiel, dass selbst bei impliziten Aktionen Checkboxen die bessere Wahl sind. Auch hier ist die Dauer der Interaktion das ausschlaggebende Argument.

Abgesehen davon, muss sich der Designer selbst hinterfragen, wenn Aktionen untereinander gruppiert sind und er den Benutzer:innen viele ähnliche Aktionen anbietet. Vielleicht wäre es dann eine bessere Option, die vielen ähnlichen Aktion zu einer parametrisierbaren Funktion umzuwandeln. Die Parametrisierung geschieht dann mittels Checkboxen.

Bei ähnlichen Optionen gilt es sich wieder ins Gedächtnis zu rufen, was die zwei entscheidenden Unterschiede zwischen Toggles und Checkboxen ist: die Anzahl der Status (3 bei Checkboxen, 2 bei Toggles) und die Auswirkung der Selektion (Statuswechsel bei Checkboxen, Statuswechsel samt automatischer Ausführung impliziter Aktionen bei Toggles).

Vor diesem Hintergrund sind somit bei der Auswahl einer oder mehrerer ähnlicher Optionen ohne eine implizite Ausführung von Aktionen Checkboxen zu wählen.

Entsprechend der Anwendungsfälle ist die Unterscheidung zwischen implizit auszuführenden Aktionen oder ausschließlichem Statuswechsel relevant.

Somit ist bei ähnlichen Aktionen für unterschiedliche Objekte der Toggle die richtige Wahl.

Eigenständige Bedienelemente, die während der Interaktion nicht zur automatischen Ausführung von Aktionen führen, sollten immer als Checkbox dargestellt werden.

Selbst wenn die einzelnen Optionen zwar zu Aktionen führen, diese allerdings nicht automatisch während der Bedienung ausgeführt werden, ist die Checkbox die richtige Wahl.

Sollte allerdings sofort mit der Interaktion mit den Elementen eine Aktion ausgeführt werden, so ist ein Toggle die richtige Wahl.