Tabpages werden häufig falsch eingesetzt
Tabpages in Thunderbirds Systemeinstellungen
Irgendwann Anfang der 90er haben sich sogenannte Tabpages in die User Interfaces eingeschlichen. Im Prinzip bilden diese Tabpages (kurz Tabs – nein, nicht die für den Geschirrspüler) ein Notizbuch nach. Die Tabs unterteilen das Notizbuch in verschiedene Bereiche. Bei OS/2 ist das für komplexe Systemeinstellungen verwendet worden. Und dafür haben sich die Tabpages auch als probates Mittel bewährt, um die Fülle der Einstellungen zu ordnen. Bei OS/2 ist der Notizbuchcharakter sogar noch durch eine Spiralbindung am linken Rand visualisiert worden.
Nun scheinen diese Tabpages aber so beliebt geworden zu sein, dass man sie fast überall im User Interface Design findet. Bevor man aber nun die Welt komplett ins Notizbuch steckt, gilt es noch mal zu hinterfragen, was die Tabpages leisten und was nicht. Es können sich nämlich aus falschen Verwendung ernsthafte Usability-Probleme ergeben.
Tabpages bieten die Möglichkeit, ein komplexes Objekt in seine verschiedenen Aspekte aufzugliedern und es so zu strukturieren:
==> Eine Tabpage stellt einen Aspekt dar. ==> Ein Aspekt beinhaltet viele Attribute. ==> Ein Aspekt sollte keine Unteraspekte beinhalten.
Merkmale von Tabpages
Was Tabpages leisten:
Sie bieten unterschiedliche Aspekte eines komplexen Objekts gleichberechtigt an.
Sie bieten die Aspekte unabhängig voneinander an.
Tabpages lassen dem Nutzer offen, welchen Aspekt er bearbeiten möchte. Er kann auch mehrere Aspekte bearbeiten.
Bei der Bestätigung des Dialog mit OK oder Speichern werden die Inhalte (Attribute) aller Tabpages -nicht nur des zuletzt sichtbaren- übernommen.
Was Tabpages nicht leisten:
Tabpages sind ungeeignet, eine sogenannte Sequentialität zu erzwingen. Man kann den Nutzer mit so einem Notizbuch nicht zwingen, erst die eine und dann eine andere Tabpage auszufüllen. Dafür sollte man einen Assistenten einsetzen.
Tabpages sind ungeeignet, um Abhängigkeiten zwischen den unterschiedlichen Aspekten abzubilden.
Das Notizbuch ist ungeeignet, um den Nutzer auf die Bearbeitung nur eines Tabs festzulegen.
Tabpages werden häufig falsch eingesetzt
Komplexe Detailsuchen werden in unterschiedliche Aspekte aufgebrochen: Der Nutzer sieht nur die zuletzt eingebenen Suchkriterien. Er wird Schwierigkeiten haben, die Trefferliste mit den zuvor auf anderen Tabpages definierten Kriterien in Deckung zu bringen. Das wird besonders dann offentsichtlich, wenn er die Suche verfeinern oder verallgemeinern möchte. Er sieht nur die zuletzt gewählte Tabpage und muss sich durch die anderen durchklicken. Unabhängig vom Sinn solcher komplexen Suchen -sie stellen an sich schon ein Usability-Problem dar- sollten alle auf die Reise geschickten Suchkriterien in der Nachbearbeitung sofort sichtbar sein. Lieber die ausgefüllten Suchaspekte untereinander anbieten und den Nutzer etwas scrollen lassen.
Manchmal werden Tabs auch verwendet, obwohl nur ein Aspekt (also die Felder eines Tabs) ausgefüllt werden darf. Das führt uns zu einer weiteren Usability-Problematik: Nun hat der Nutzer einen Aspekt mit aller Liebe ausgefüllt und stellt fest, dass er besser einen anderen Aspekt bearbeiten sollte. Was nun? Soll er die anderen Tabs nicht mehr anklicken können? Oder soll er sie anklicken aber nichts eingeben dürfen? Und was passiert mit den bereits eingegeben Daten? Muss er wieder zur zuvor befüllten Maske zurück und die Eingaben zurücksetzen bevor im wirklich gewüschten Aspekt Eingaben vornehmen kann? Ihr lächelt vielleicht. Aber solche Fragen stellen sich manchmal im Projekt.
Die zuvor erwähnte Unabhängigkeit der einzelnen Tabs voneinander wird auch häufig ignoriert. So gibt man bspw. auf dem zweiten Tab etwas ein und wird vom System daruf hingewiesen, dass bestimmte Eingaben auf dem ersten Tab noch fehlen. Noch schlimmer wird es, wenn man danach auf der ersten Tab Eingaben vornimmt, die die Attribute, die sich auf der zweiten befinden, löschen oder ungültig machen. Tabpages sind nicht geeignet, diese Abhängigkeiten zu visualisieren, da sie sich ausschließlich im Hintergrund unsichtbar auswirken. Offensichtlich sollte man stattdessen aus Gründen der Usability einen Assistenten verwenden.
Das leitet direkt zum Thema Sequentialität über. Dass Tabs hierfür ungeeignet sind, ergibt sich aus der Unabhängigkeit der Tabs voneinander. Es liegt auf der Hand, dass man mit Tabs keinen Prozess wie bei einer Installation umsetzen kann. Ein Prozess mit Schritt 1 bis Schritt n kann so nicht funktionieren, da der Nutzer aufgrund des Controls ja auch mit dem dritten Schritt beginnen könnte. Und schon fliegt uns die Installation um die Ohren. Durch das falsche User Interface Design geht die Usability vor die Hunde. Warum weise ich auf die Sequentialität hin? Weil ich so etwas leider auch schon sehen musste! Da nimmt man besser einen Assistenten.
Manchmal scheint die Welt so komplex zu sein, dass eine Tabpage sogar wieder mit Unter-Tabpages versehen wird. Und dann haben wir auf einmal eine Tabpage, die wieder ein Notizbuch beinhaltet. Also sozusagen ein Notizbuch in einem übergeordneten Notizbuch. Wenn man das macht, verlangt man vom Nutzer zuviel. Das kann keiner mehr nachvollziehen. Stellt Euch das noch in Kombination mit der Sequentialitäts-Problematik vor, und wir haben den Nutzer vollends ins Nirvana geschossen.
Fazit
Nicht immer, wenn die Welt komplex wird, sind Tabs die richtige Lösung. Es gibt auch andere Elemente wie Assistenten oder Maskenbereiche, die über Auswahllisten (DropDowns) ein- und ausgeblendet werden. Zuvorderst sollte man aber überlegen, wie man die Komplexizität reduziert. Besteht danach eventuell gar nicht mehr die Notwendigkeit, ein Objekt in verschiedene Aspekte zu zergliedern oder einen Prozess in mehere Arbeitsschritte aufzuteilen? Hier geht es nicht um Geschmacksfragren. Ich habe dargelegt, dass man hier wirklich gravierende Fehler machen kann. Also: Achtung bei der Verwendung von Tabpages. Sie sind kein Allheilmittel.
Interessierten möchte ich auch noch den Artikel von Jakob Nielsen (useit.com) empfehlen.