Kontextsensitive Katalogunterstützung: Handhabung umfangreicher Auswahllisten

Mit der richtigen Platzierung und plausiblen Interaktionsmöglichkeiten lassen sich auch sehr große Auswahllisten handhaben. Doch lesen Sie selbst…

Viele Anwendungen bieten zum Ausfüllen verschiedener Eingabefelder umfangreiche Auswahllisten. Diese Auswahllisten werden auch Kataloge genannt. Man setzt sie ein, um sicherzustellen, dass nur bestimmte Werte eingegeben werden. Als kontextsensitiv wird eine Anwendung bezeichnet, wenn abhängig vom Feld, das den Fokus hat, unterschiedliche Informationen angeboten werden. Wir kennen das von der Hilfe. Wenn man auf der Erfassungsmaske A die Hilfe aufruft, werden genau zu dieser Maske passende Erklärungen angezeigt – und nicht die gesamte Onlinehilfe oder die Hilfetexte zur Maske B. Genau so kann man auch mit Katalogen verfahren. In einem festgelegten Bereich zeigt man für das Feld, das gerade den Fokus hat, den entsprechenden Katalog an. Das ist also die sogenannte kontextsensitive Katalogunterstützung.

Dafür gibt es doch die Select-Felder, könnte man meinen. Nicht ganz. Wenn ich hier von Katalogen spreche, meine ich Listen mit teilweise bis zu 1000 Einträgen. Und die einzelnen Einträge können auch recht lang sein. 100 und mehr Zeichen sind keine Seltenheit. So etwas begegnet einem in Onlineshops nicht so häufig, Fachanwendungen in der Verwaltungen setzten derart große Kataloge häufig ein. Und dafür sind einfache Select-Felder schlichtweg nicht geeignet.

Früher hat man umfangreiche Kataloge in separate Dialoge ausgelagert. An dem jeweiligen Feld fand sich ein Button – häufig mit drei Punkten gekennzeichnet -, über den man den Dialog öffnen konnte. Dann musste man durch lange Listen blättern und den gewünschten Eintrag auswählen. Und zuguterletzt musste der Dialog meistens noch bestätigt werden. Bei der Anzahl erforderlicher Nutzerinteraktionen kann einem doch wirklich schwindelig werden. Da geht nicht nur die Produktivität flöten. Es nervt einfach. Das können wir heute besser.

Tastaturgestützte Katalogsteuerung

Bevor wir darüber sprechen, wo die Kataloge angeboten werden sollten, muss klar werden, dass es der Möglichkeit bedarf, einen Katalogwert auch via Tastatur auszuwählen – oder zumindest den Auswahlbereich via Tastatur einzuschränken. Hierfür bieten sich zwei Mittel an. Das erste ist die Verwendung von Fachschlüsseln und einem eigens dazu vorgesehenen Eingabefeld. Man gibt einen vielleicht vierstelligen Code ein, und der angezielte Katalogwert ist ausgewählt. Das ist sehr effektiv. Aber jeder kann sich vorstellen, dass das eines sehr hohen Lernaufwands bedarf. Dies kann und darf also nicht die einzige Lösung sein.

Das Stichwort lautet Autovervollständigung. Der Nutzer gibt einige Zeichen ein, und das System ergänzt den Rest. Sie kennen das wahrscheinlich von gängigen Textverarbeitungen oder der sogenannten T9-Funktionalität eines traditionellen Mobiltelefons. Die aktuellen Internet Browser unterstützen das ebenfalls bei der URL-Eingabe oder der Suche.

Doch gibt es für die Autovervollständigung zumindest zwei Varianten:

1. Das System springt zu dem ersten Eintrag, der mit den eingegeben Zeichen beginnt. Die Liste der angezeigten Katalogeinträge wird also nicht eingeschränkt, die Selektion springt einfach an die treffende Stelle. Der Nutzer kann mit den Scrollbars nach wie vor den gesamten Katalog durchblättern.

2. Die zweite Variante ist viel reizvoller – aber leider auch viel komplexer. Der Nutzer gibt bspw. “Ball” ein, und das System zeigt alle Katalogwerte an, die “Ball” beinhalten. Die Liste der erreichbaren Katalogeinträge wird also eingeschränkt. Nun kann der Nutzer in der kurzen Liste schnell finden, was er sucht.

Beide Varianten haben ihre Vorteile. Und in Kombination mit geschickt strukturierten Katalogen wird das zu einem mächtigen Werkzeug….

Der richtige Platz für Kataloge

Neben der Frage, wie man die Auswahl des gewünschten Eintrags steuert, ohne den Nutzer zum Scroll-Sklaven zu degradieren, stellt sich die Frage, wo und wie man den Katalog am besten anbietet.

Möglichkeit 1: Umschalten des Object Browsers

Schon vor langen Jahren habe ich eine Anwendung konzipiert, die sich das Prinzip des Objektbrowsers aneignete. Man kennt das von verschiedenen Mailclients mit eingeschalteter Mail-Vorschau. Links in der Container-Sicht werden die Ordner angezeigt. Rechts im oberen Bereich werden in der Objektsicht die Inhalte des gewählten Ordners aufgelistet, und darunter in der Detailsicht wird die Vorschau des oben selektierten Objektes angezeigt. Sozusagen ein klassischer Dreisprung.

Das könntefür eine Vorgangsbearbeitung bei der Polizei ungefähr so aussehen:

Vorschau des ausgewählten Vorgangs

Und wo sind die Kataloge? Wenn man nun das selektiertes Objekt bzw. einen Unteraspekt in Bearbeitung nimmt, wird die Vorschau durch die Erfassungsmaske ausgetauscht. Und die Kataloge? Ja, die kommen nun. Es wird nämlich nicht nur die Detailsicht von Vorschau auf Erfassungsmaske umgeschaltet, auch die darüber befindliche Objektsicht wird von der Auflistung der Ordnerinhalte umgeschaltet auf die Anzeige de Kataloge.

Bearbeitung eines Teilaspekt des ausgewählten Vorgangs

Und hier kommt nun die Kontextsensitivität zum Zuge. Abhängig vom Eingabefeld, das gerade den Fokus hat, wird der passende Katalog angezeigt. Nun werden aber nicht alle Eingabefelder durch Kataloge unterstützt. In diesem Fall sollte man aber nicht die Objektsicht wieder zurückschalten. Stattdessen bietet man besser andere unterstützende Informationen an: Für ein Datumsfeld kann man einen Kalender anzeigen, ein einfaches Textfeld kann mit einem kleinen Hilfetext ergänzt werden. So wird die Objektsicht im Bearbeitungsmodus immer für Unterstützungsinformation zum aktuellen Feld verwendet.

Das ist konsistent und überaus praktisch. Erst wenn die Bearbeitung verlassen wird (durch Speichern oder Abbrechen), schaltet das System wieder in die vorige Ansicht mit Objektliste und Vorschau zurück. Diese Mimik ist mit einfachem HTML nicht möglich. Im Zuge der Verbreitung von Rich Internet Applications könnte sie aber auch in browserbasierten Anwendungen vermehrt wieder eingesetzt werden.

Möglichkeit 2: Unterhalb des aktuellen Feldes

Eine weitere Möglichkeit sehe ich darin, dass man den Katalog unterhalb des jeweiligen Feldes anbietet. Das ist zwar streng genommen nicht kontextsensitiv, da der Funktionsbereich zur Anzeige des Katalogs nicht statisch an derselben Stelle bleibt sondern dem Feld mit dem Fokus folgt. Entspricht aber mehr dem Gesetz der räumlichen Nähe. Und das ist ja bekanntermaßen auch ein Kernsatz der Usability. Also in diesem Fall wird der Katalog immer unterhalb des aktuellen Feldes angezeigt.

Der Katalog wird unterhalb des aktuellen Feldes angezeigt.

Einerseits kann man so die volle Breite des Dialogs ausnutzen. Das ist besonders bei langen Katalogwerten vorteilhaft. Andererseits entsteht beim Feldwechsel erhebliche optische Unruhe. Der Katalogbereich wird ausgeblendet, das nächste Feld wird also nach oben geschoben, und der Katalogbereich wird nun darunter eingeblendet. Obwohl im UI jetzt einiges neu geordnet wird, verschiebt sich der Fokus – bzw. viel wichtiger die Schreibmarke – nur um eine Zeile. Das ist durchaus praktikabel.

Möglichkeit 3: Am rechten Rand der Erfassungsmaske

Abgesehen von Mobilgeräten werden die Bildschirme relativ zur Höhe immer breiter. 16:9 ist sogar bei Laptops nunmehr sehr verbreitet. Aber was fangen wir damit an? Zwei- oder sogar dreispaltige Formulare und Erfassungsmasken. Nein. Richtlinien zur Formulargestaltung sagen ganz klar, dass ein einspaltiges Design leichter zu lesen ist. Bei der Breite der Bildschirme bleibt da nun rechts eine Menge Platz übrig. Der bietet sich förmlich an, um dort unterstützende Informationen und eben auch den Katalogbereich anzuzeigen. Das könnte dann so aussehen:

Der Katalog wird rechts neben dem Eingabefeld angeboten.

Das scheint mir ein guter Ausweg zu sein, wenn man nicht wie in Möglichkeit 1 beschrieben einen Object Browser einsetzten möchte. Und wenn man den Katalogbereich mit dem Fokus mit wandern lässt, wird auch der Forderung nach der räumlichen Nähe Genüge getan. Je nach Layout steht einem aber nicht die Breite wie in den Möglichkeiten 1 und 2 zur Verfügung. Erhöhtes Scroll-Aufkommen könnte aufgrund mehrzeiliger Katalogwerte die Folge sein. Das muss natürlich durch eine gute Autovervollständigung (tastaturgestützte Auswahl des gewünschten Katalogwertes) kompensiert werden.

Fazit

Riesig lange Auswahllisten und Kataloge sind nie gut, lassen sich aber häufig nicht vermeiden. Mit den hier vorgestellten Lösungen lassen sie sich dennoch recht ordemtlich handhaben. Und wenn zusätzlich die Auswahl per Tastatur mit Autovervollständigung angeboten wird, braucht man sich vor sehr großen Auswahllisten nicht mehr zu fürchten.

#EnterpriseApplication #UserInteractionDesign #UserInteractionPattern