Wir haben noch nicht alle älteren Artikel nachbearbeitet. Das bezieht sich in der Regel nur auf die Codebeispiele, die noch nicht optimal dargestellt werden.
Best Practices Interaktionselemente - Teil 2
Im gestrigen ersten Teil hat Stefan Nitzsche 13 Regeln zum Umgang mit Interaktionselementen aufgestellt. Im heutigen zweiten Teil gibt er konkrete Tipps zum Umgang mit speziellen Interaktionselementen. Der Inhalt des Artikels ist eine lose Regelsammlung und erhebt keinen Anspruch auf Vollständigkeit.
Links
Links führen zu anderen Dokumenten (Web 1.0) oder rufen Funktionen, Dialoge auf (Web 2.0). Sie müssen deutlich als Links zu erkennen sein, der Benutzererfahrung gemäß optimalerweise durch eine besondere Farbigkeit und eine Unterstreichung. Wichtig ist auch, bereits besuchte und gerade aktive Links von unbesuchten Links visuell zu unterscheiden. Für suchende Benutzer ist die Kennzeichnung von besuchten Links ein willkommenes Hilfsmittel, unnötige wiederholte Besuche von Seiten zu vermeiden. Auch kann wichtig sein, das Ziel der Links visuell darzustellen und so externe von internen Links zu unterscheiden, oder zu visualisieren, welche Art von Quelle (Video, Audio, etc.) referenziert wird.
Radiobuttons
Radiobuttons symbolisieren eine Auswahl aus zwei oder mehr Möglichkeiten, von denen nur eine auswählbar ist. Sie sollten niemals dazu zwingen, nur eine aus verschiedenen denkbaren Optionen auszuwählen – dadurch fühlt sich der Benutzer bevormundet. Nur wenn tatsächlich immer nur eine einzige Möglichkeit zutreffen kann, sollten Radiobuttons verwendet werden.
Wie aus gedruckten Formularen gelernt, sollten Sets aus Radiobuttons immer untereinander stehen, mit der Beschriftung in Leserichtung nach dem Radiobutton. Bei horizontaler Ausrichtung ist die Zugehörigkeit von Radiobutton zu Beschriftung schlecht erkennbar. Außerdem sollte man bei Radiobuttons eine Vorbelegung erwägen, und zwar auf einen neutralen Standardwert, der nicht mit der eigentlichen Auswahl an Möglichkeiten in Verbindung steht.
Die Wahrnehmungspychologie lehrt, dass ein Mensch sieben Auswahlmöglichkeiten problemlos behalten kann – bei mehr als sieben wird es schwer. Obwohl die Lehren der Wahrnehmungspsychologie hier nur mit Vorsicht adaptierbar sind, sollte man doch die Anzahl der Möglichkeiten gering halten.
Checkboxen
Sie symbolisieren eine Zustimmung zu einer Vorgehensweise (eine einzige Checkbox) oder eine Auswahl mit mehreren oder gar keinen zutreffenden Möglichkeiten (mehrere Checkboxen). Wie bei Radiobuttons sollten Sets aus Checkboxen ebenfalls immer untereinander stehen, mit der Beschriftung in Leserichtung nach der Checkbox.
Selectboxen
Sie symbolisieren eine Auswahl an Möglichkeiten, aus der nur eine einzige gewählt werden kann. Der kognitive und koordinatorische Aufwand, eine Selectbox zu bedienen, ist wesentlich höher, als der, eine Liste von Radiobuttons zu bedienen. In Einzelfällen kann es jedoch sinnvoll sein, die Selectbox vorzuziehen, beispielsweise bei einer Datumsangabe. Hier ist es noch wichtiger als bei Radiobuttons, dem Benutzer einen neutralen Standardwert zu zeigen, bevor er eine der angebotenen Möglichkeiten wählt. Es gibt jedoch einen Sonderfall: eine Selectbox, die in der Höhe so angelegt ist, dass die enthaltenen Optionen bereits sichtbar sind, ohne sie aufklappen zu müssen. Diese Variante macht es möglich, beispielsweise bei einer gedrückten Strg- (Microsoft Windows) oder Cmd-Taste (Apple Mac OS X) mehrere Optionen auszuwählen. Allerdings bietet auch diese Variante einen Fallstrick, denn ein unerfahrener Benutzer erkennt ohne Erklärung nicht, dass er mehrere Möglichkeiten wählen kann. Hier bietet es sich eher an, eine eigene Form dieser Art des Interaktionselement zu gestalten, als ein bestehendes Element zu missbrauchen.
Drehregler
Man findet sie sehr selten auf Webseiten, sie sollten aber dennoch erwähnt werden. Sie haben zwei gelernte Einsatzfelder: die Steigerung eines Werts (wie bei dem Lautstärkeregler einer Stereoanlage) oder die Abweichung von einem Normalwert (wie bei dem Balance-Regler einer Stereoanlage). Es ist Standard, dass gemäß der Leserichtung der Wert von links nach rechts ansteigt oder aber nach links ins Negative und nach rechts ins Positive abweicht. Für Drehregler gibt es kein Markup-Element und auch kein von einer Rendering Engine oder einem Betriebssystem gestellte Standard-Visualisierung. Daher ist es hier immer nötig, zu einer individuellen Visualisierung zu greifen.
Schieberegler
Auch sie sind eher selten zu finden, allerdings im Rahmen von Webapplikationen deutlich häufiger als Drehregler. Bei Youtube beispielsweise finden sich sowohl horizontale (Timeline), als auch vertikale Schieberegler (Lautstärke). Der Standard ist hier einfach: wie auch bei Drehreglern finden sich sowohl der Einsatz als reine Steigerung oder als Abweichung, auch hier von rechts nach links ansteigend oder von links negativ abweichend nach rechts positiv abweichend. Bei vertikalen Schiebereglern steht unten synoym für links/mehr und oben synonym für rechts/weniger.
Texteingabefelder
Die wohl am zweithäufigsten genutzten Interaktionselemente, direkt nach den Links, sind Texteingabefelder. Hier hat man auch ohne aufwändige Ersetzungstechniken einen großen gestalterischen Spielraum, der nicht immer komplett ausgeschöpft werden muss.
Bewährt hat sich ein hoher Kontrast zur unmittelbaren Umgebung (Rahmen, Farbe) und eine in Leserichtung vor dem Texteingabefeld stehende Beschriftung. Die Beschriftung über dem Texteingabefeld zu platzieren, ist ebenfalls möglich, allerdings ist der Aufwand der Zuordnung größer. Dabei ist die Beziehung zwischen Beschriftung und Texteingabefeld im Markup zu beschreiben, so dass das Textfeld ausgewählt werden kann, indem man die Beschriftung anwählt.
Wählt man ein Texteingabefeld an, um es auszufüllen, sollte dieser Zustand visualisiert werden, damit man erkennt, welches Feld sich in Bearbeitung befindet. Bei AJAX-getriebenen Suchanfragen mit ausklappenden Vorschlägen unterhalb des Eingabefelds (Auto-Suggest) muss darauf geachtet werden, dass erst nach erfolgter Eingabe einiger Zeichen und einem entsprechenden Delay nach der Eingabe eine Anzeige der vorgeschlagenen Daten erfolgt.
Pflichtfelder
Ist man als Betreiber einer Webseite geneigt, soviel Information wie möglich vom Benutzer zu erhaschen, so sollte man sich doch zügeln, denn zuviele Pflichtfelder wirken abschreckend. Als Visualisierung eines solchen Zwangs hat sich das Sternchen „*“ als Standard etabliert, oft auch in einer anderen Farbigkeit als die verpflichtende Beschriftung, aber immer mit einer Fußnote.
Reiter
Reiter sind umstrittene Metaphern im Web. Apple hat sie über Jahre genutzt, um die verschiedenen Bereiche der Webseite voneinander zu trennen – im wahren Leben kommen die Reiter sowohl als physisch voneinander getrennte Element vor (Hängeregister), die man auch separat wählen und betrachten kann, als auch als Teil einer Einheit innerhalb eines Containers (einer Akte z.B.).
Jakob Nielsen empfiehlt Reiter nur dort, wo sie verschiedene Ansichten des gleichen Bereichs anwählbar machen, aber nicht als übergeordnetes Navigationselement einer ganzen Webseite. Darüber lässt sich streiten, nicht aber darüber, dass die optische Anmutung von Reitern von der Wirkung eines realen Reiters inspiriert sein muss. Die Simulation der Haptik, also die Erhabenheit des gewählten Reiters in Kombination mit seiner Verbindung mit dem darunter beginnenden Inhalt spielt eine große Rolle bei der Erkennung dieses Interaktionselements. Eine andere Farbigkeit, die den aktiven Zustand anzeigt, hilft zusätzlich. Sind die Reiter getrennt voneinander und getrennt vom Inhalt darunter, sind sie kaum als solche wahrnehmbar.
Dialoge
Dialoge sind der Desktop Software entlehnt, wo sie auf versehentlich Geschehenes aufmerksam machen, Entscheidungen verlangen oder vor ungewollten Aktionen warnen. Eben diesen Zweck haben sie auch im Web, allerdings findet man sie fast ausschließlich in Webapplikationen.
Derartige Dialoge sollten deutlich von der Umgebung abgehoben werden, oft wird sogar die Umgebung ausgeblendet, um den Fokus des Benutzers auf den Dialog zu lenken. Auch eine simulierte Erhabenheit über dem eigentlichen Inhalt kann die Funktion unterstützen, zumindest ein Rahmen und eine Signalfarbe ist nötig, um einen Dialog hervorzuheben. Nur ein Bestätigungsdialog darf sich zurücknehmen, wobei er selbstverständlich nicht nahezu unsichtbar bleiben sollte.
Scrollbalken
Der einzig berechtigte Scrollbalken findet sich am rechten Rand des Browserfensters – horizontale Scrollbalken sind tabu! Auch sollte man auf bereichsbezogene Scrollbalken verzichten, da die Steuerung von verschachtelten oder scrollbaren Bereichen nebeneinander nur mit den Maustasten effizient möglich ist. Sobald man sich derartige Bereiche in Kombination mit Bedienung durch einen Touch Screen oder durch eine Tastatur vorstellt, werden Schwierigkeiten klar.
Ist man zur Verwendung von bereichsbezogenen Scrollbalken gezwungen, sollte man sich der durch Rendering Engine oder Betriebssystem bereitgestellten Elemente bedienen. Eigens dafür entwickelte haben den Nachteil, dass sie oft nicht intuitiv erkannt werden, nicht mittels Maus-Scrollrad bedienbar und nicht selten sehr anfällig für Bedienungsfehler sind.
Scrollbalken sollten nur dann angezeigt werden, wenn Scrollen tatsächlich notwendig ist. Ist sämtlicher Inhalt zu sehen, sollten Scrollbalken ausgeblendet werden. Der bei Zentrierung des Inhalts auftretende Versatz bei Seiten mit und ohne Scrollbalken kann dabei in unkritischen Fällen in Kauf genommen werden. Es gibt natürlich Anwendungsfälle, in denen es wichtig ist, dass der Inhalt nicht springt. Beispielsweise bei der Gestaltung einer im Viewport zentrierten Bildergalerie kann man das kleinere Übel wählen: dem Benutzer das problemlose Durchklicken einer Galerie zu ermöglichen, ihm dabei aber einen Scrollbalken zu zeigen, der nicht nutzbar ist.
Kommentare
Gunnar Bittersmann
am 19.12.2008 - 10:33
Kleine Anmerkung zu:
Man sollte das IMHO nicht nur erwägen, sondern immer tun. Ansonsten droht undefiniertes Verhalten, eventuell wird der erste Radiobutton (vom Webseitenautor ungewollt) als ausgewählt ausgewertet. Siehe HTML-Spec Kapitel 17.2.1.
Sollen Nutzer nicht durch eine Vorbelegung zu einer bestimmten Auswahloption geleitet werden (wichtig bei Fragebögen), kann ein zusätzlicher Radiobutton „keine Antwort“ vorgesehen werden, der vorausgewählt wird und mit CSS versteckt wird. Siehe Posting im SELFHTML-Forum.
Stefan Nitzsche (Autor)
am 19.12.2008 - 11:13
@Gunnar: Du hast Recht, eine Vorbelegung macht in den meisten Fällen Sinn. Aber:
Diese Spezifikation (HTML 2.0) ist aus dem Jahr 1995 und noch ziemlich naiv, was den Umgang mit Formularfeldern angeht. Aktuell bestimmen Radiobuttons Zustimmung zu Newsletter-Anmeldungen, Akzeptanz von Lizenzvereinbarungen, etc. – hier ist keinerlei Vorauswahl möglich, der Benutzer muss nach geltendem Recht eine eigene, aktive Entscheidung treffen.
Derzeit gibt es, auch laut der von Dir zitierten HTML 4.01-Spezifikation, keinen Zwang, in einer Liste von Radiobuttons eine Option vorauszuwählen, auch das W3C bedient sich hier der abgeschwächten Form „Autoren sollten sicherstellen“. Mir ist noch nie untergekommen (und das habe ich gerade mit allen mir zur Verfügung stehenden Browsern getestet), dass ein Browser (ohne eine explizite Anweisung im Markup) den ersten Radiobutton einer Liste vorausgewählt hat.
Der Caspers
am 19.12.2008 - 11:28
Ihr beiden habt schön die Problematik herusgearbeitet: die häufige Verwendung von "sollte" ist der Kern des Problems in vielen W3C-Spezifikationen. Damit ist schon die Grundlage gegeben, dass der eine Browserhersteller sich so entscheidet, und der andere eben anders.
Und so wird dann bei Webautoren aus einem "sollte man eigentlich so machen" (was "muss es aber nicht" implizieren sollte) mal ganz schnell ein "muss immer und überall so sein".
HTML 4 ist so dermaßen unterspezifiziert, dass es schon fast an ein Wunder grenzt, dass es überhaupt Implementierungen davon gibt.
Jared
am 19.12.2008 - 12:13
Super Beitrag. Vieles wusste ich noch garnicht :)
Aber eine Sache ist mir aufgefallen:
Ich kann mich dran erinnern das YAML bei einem bestimmten Zustand (ich glaube, wenn die Höhe des Viewports auf 100% eingestellt wird) immer einen Scrollbalken anzeigte. Ganz sicher bin ich mir nicht.
Dies wäre laut dem Artikel ja dann nicht korrekt?!
Stefan Nitzsche (Autor)
am 19.12.2008 - 12:28
@Jared: Hier kollidieren zwei Richtlinien. Die eine Richtlinie soll die Darstellung von überflüssigen Interaktionselementen, die andere soll Inkonsistenzen im Interface vermeiden. Da muss man fallweise abwägen, für welche Richtlinie man sich entscheidet.
Gerade mit Dirk Jesse habe ich im Vorfeld über den Artikel gesprochen, und er nannte mir einige überzeugende Beispiele für Anwendungsfälle, bei denen es tatsächlich besser ist, einen deaktivierten Scrollbalken einzublenden. Ebensoviele gibt es aber für die gegenteilige Vorgehensweise.
Bei YAML ist es also weder falsch, noch richtig – Dirk hat sich einfach für eine Variante entschieden, die ja vom YAML-Benutzer problemlos geändert werden kann.
Jared
am 19.12.2008 - 13:22
@Stefan Nitzsche
Dann lag ich mit meiner Vermutung richtig :) Danke dir für die Erklärung. Bei uns in der Agentur wäre der Scrollbalken in dem Fallbeispiel YAML z.B. nicht gerne gesehen und da ist es sehr hilfreich ihn ausknipsen zu können.
lg
Jared
Stefan
am 19.12.2008 - 15:10
Ein Toller Artikel mit vielen hilfreichen Tipps. Bei den besuchten Links
würde ich das ganze auf die Content Links reduzieren. In der Navigation wirkt das meist eher unruhig als hilfreich.
nikosch
am 20.12.2008 - 00:55
Das Problem ist ein anderes: Klickt der Nutzer versehentlich einen Punkt an, gelangt er nie wieder in den Status "keine Auswahl", die aber im Interface (ohne Vorselektierung) erstmal "gefühlt" möglich ist. Was dann die Validierung sagt, steht dann auf einem anderen Blatt.
Kleine Anmerkung zu Selectboxens:
Die angesprochenen mehrzeiligen Auswahllisten sind nicht zwingend Mehrfachoptionen, obgleich diese üblicherweise so dargestellt werden. Auch Einfachauswahlen erlauben mehrzeilige Anzeigestile.
Ansonsten: Netter Text. Nichts wirklich neues, aber eine schöne Zusammenstellung!
Die Kommentare sind geschlossen.