Orientierung

Mit den in den Gestaltungsbereichen Präsentation und Interaktion vorgestellten Forderungen haben wir die Grundlagen gelegt, um Nutzungsschnittstellen zu gestalten, in denen Bildschirmobjekte ergonomisch gestaltet und übersichtlich angeordnet sind. Die Objekte ermöglichen Eingaben und Manipulationen und die Nutzungsoberfläche insgesamt bietet entsprechende Rückmeldungen und Möglichkeiten an, Prozesse zu beeinflussen und abzubrechen. Von wenigen Ausnahmen wie Meldungsfenstern abgesehen, haben wir uns aber bislang jeweils nur mit einem einzigen Bildschirmaufbau beschäftigt.

Zwar gibt es Systeme und Software-Produkte, die mit nur einem einzigen Bildschirmaufbau auskommen, doch stellen sie die große Ausnahme dar. In aller Regel können nicht alle Objekte gleichzeitig angezeigt und nicht alle Funktionen der Software gleichzeitig angeboten werden. Zu sehen ist immer nur ein Ausschnitt. Durch Interaktion mit der Software ändert sich dieser Ausschnitt fortwährend. Im ersten Unterkapitel unseres Gestaltungsbereichs Orientierung geht es zunächst darum, die Forderungen an die Gestaltung der zwangsläufig entstehenden Übergänge vorzustellen. Die beiden folgenden Kapitel beschäftigen sich jeweils mit wichtigen Teilaspekten der Gestaltung solcher Übergänge. Bei der Navigation geht es darum, eine große Menge an Objekten in einer Software strukturiert zugänglich zu machen. Im Kapitel Modusgestaltung setzen wir uns speziell mit Fragen des Umgangs mit einem sehr großen Funktionsumfangs und der Technik, verschiedene Modi zu nutzen, auseinander.

Übergänge

Sobald nicht mehr alle Objekte, alle Eingabemöglichkeiten und das komplette Funktionsangebot mit einem einzigen Bildschirmaufbau dargestellt werden können, sobald also Objekte dynamisch erzeugt werden, sich während der Programmnutzung ändern oder zwischen mehreren Bildschirmseiten¹ gewechselt werden muss, braucht es zusätzliche Forderungen, die das Zurechtfinden im jeweiligen Angebot ermöglichen bzw. unterstützen. Zwischen einem Bildschirmaufbau und dem jeweils folgenden gibt es einen Übergang, dessen ergonomische Gestaltung uns an dieser Stelle interessiert.

Konstruieren wir ein einfaches Beispiel: Das abgebildete Mockup stellt eine Software zum Verwalten von Kursen dar. Sie sehen im unteren Bereich eine Reihe von bereits angelegten Kursobjekten in Form von Icons. Im oberen Teil bietet die Software eine Menüleiste mit Funktions-Icons zum Anzeigen eines Stundenplans, zum Erstellen eines neuen Kurses und zum Löschen eines oder mehrerer Kurse an. Wenn Sie nun zum Beispiel auf „Neuer Kurs“ klicken, müssen Sie auf eine andere Bildschirmseite wechseln, denn die Elemente zum Erstellen eines neuen Kurses, wahrscheinlich in Form eines Formulars, können nicht zusätzlich auf dieser Bildschirmseite untergebracht werden. Es gibt also einen Übergang von dem, was Sie gerade sehen, zu einer anderen Bildschirmseite, die erscheint, wenn das Icon geklickt wird.

Dieser Übergang kann recht ruppig sein, weil nach dem Klicken auf das „Neuer Kurs“-Icon das, was Sie gerade noch gesehen haben, verschwunden ist. Stattdessen sehen Sie eine Eingabemaske für die Kursdaten, die anders gestaltet ist als die zuvor betrachtete Übersichtsseite. Dieser unvermittelte Übergang von einer Bildschirmseite auf eine andere ebenso wie der große Unterschied zwischen diesen beiden Seiten hat einen negativen Einfluss auf die Orientierung. Wenn Sie die Software oft benutzen und das Icon nicht versehentlich anklicken, Sie also erwarten können, was passiert, können Sie damit sicher leben. Wenn sie jedoch die Software selten nutzen, die Funktionen noch ausprobieren wollen oder versehentlich auf das Icon geklickt haben, fehlt Ihnen jegliche Orientierungsunterstützung.

Dies kann ein Gefühl von Desorientierung auslösen. Ein derart unvermittelter Übergang ist in der „normalen“ Welt, für die unser kognitives System eingerichtet ist, kaum möglich. Es gibt zwar die Situation, dass man in den Keller geht und nicht mehr weiß, was man dort wollte (doorway effect), aber man fragt sich in der Regel nicht, wie man dort hingekommen ist, weil man nicht plötzlich und unvermittelt dort ist. Sieht man von künstlich geschaffenen Situationen und Unfällen einmal ab, geht jede Veränderung des Wahrnehmungsfeldes mit kontinuierlichen menschlichen Aktivitäten und ebenso kontinuierlich begleitenden sensorischen Rückmeldungen einher, d. h. Handlungs- und Wahrnehmungsraum sind durchgängig miteinander gekoppelt. Ohne die durch diese Kopplung ermöglichte Differenzerfahrung wären wir nicht imstande, uns zu orientieren und einen Punkt außerhalb des Wahrnehmungsbereichs gezielt anzusteuern. Das betrifft nicht nur die eigene Bewegung, sondern auch die Beobachtung von Veränderungen in der Umgebung. Objekte oder Personen erscheinen oder verschwinden nicht von Zauberhand, sondern kommen hinein und gehen hinaus. Selbst dann, wenn man die Aufmerksamkeit kurzzeitig auf etwas anderes richtet, bleibt die Umgebung als Ganzes relativ stabil. Zwar wird auch jeder Wechsel des Bildschirminhalts durch eine entsprechende Aktion ausgelöst, doch ist die Art der Auslösung in vielen Fällen motorisch entkoppelt. Ein Tastendruck kann lediglich lokale Änderungen bewirken oder massive Konsequenzen haben, indem der komplette Bildschirminhalt erneuert oder die jeweilige Software gewechselt wird. Unabhängig von der Schwierigkeit, sich mental im Rahmen der Nutzung eine komplette Karte aller möglichen Bildschirminhalte und ihrer Zusammenhänge aufzubauen, erfordert die Arbeit in einer solchen Umgebung höchste Konzentration sowie Unterbrechungs- und Ablenkungsfreiheit durch äußere Faktoren wie z. B. Telefonanrufe. Einmal unterbrochen, ist es kaum möglich, insbesondere bei gelegentlicher Nutzung, den Faden wieder aufzunehmen. Die Gedächtnisbelastung ist sehr hoch, weil zusätzliche Informationen fehlen, die es gestatten, sich das System zu erschließen und entsprechend den Faden wieder an der geeigneten Stelle aufzunehmen.

Deshalb müssen wir die zuvor besprochenen Eigenschaften der menschlichen Umwelt auch in die Welt der virtuellen Objekte übertragen. Dazu stellen wir in diesem Abschnitt entsprechende Forderungen auf und schauen uns Nutzungsschnittstellen-Techniken an, die der Kontinuität und Stabilität der natürlichen Umwelt entsprechen.

Erschließbarkeit von Inhalten und Optionen

Wir beginnen den Reigen der Forderungen an orientierungsunterstützende Software mit dem grundlegenden Problem der Erschließbarkeit aller Optionen und Inhalte.

Erschließbarkeit ist einer der Hauptvorteile einer grafisch-räumlichen Nutzungsschnittstelle gegenüber einer solchen mit Kommandozeile. Bei einem Computer, der mit einer Kommandozeile bedient wird, fällt es Ihnen schwer, die von ihm bereitgestellten Objekte und Funktionen zu erschließen, denn Sie sehen ja nur einen blinkenden Cursor. Bei einer grafisch-räumlichen Nutzungsschnittstelle hingegen sehen Sie die Objekte auf dem Bildschirm und auch die möglichen Operationen werden Ihnen direkt am Bildschirm, zum Beispiel in Form eines Menüs, angezeigt.

Erneut ist ein Vergleich mit der Orientierung in natürlichen Umgebungen sehr hilfreich. Nehmen wir an, Sie befinden sich in einem Büro, in dem Ihnen verschiedene Handlungsoptionen zur Verfügung. Sie können zum Beispiel einen Zettel vom Schreibtisch nehmen und in den Papierkorb werfen oder Sie nehmen einen Stift, um eine Anmerkung an einem Text anzubringen, der auf dem Schreibtisch liegt. Sie können auch das Büro verlassen, indem Sie die Tür öffnen und hindurchgehen. All diese Handlungsmöglichkeiten werden durch Objekte und wahrnehmbare Unterschiede verkörpert. Das Erkennen der Handlungsmöglichkeiten setzt zwar immer eine gewisse Erfahrung voraus, doch entscheidend ist, dass Sie sich diese Umwelt durch Wahrnehmen und Handeln erschließen können, was ohne die Kopplung von Handlungs- und Wahrnehmungsraum nicht möglich ist. Das Erkennen ähnlicher Gegenstände und ihrer Arrangements erlaubt es zudem, Erfahrungen aus anderen Umgebungen zu übertragen. Diese wichtige Eigenschaft der Erschließbarkeit der Umgebung durch die reflektierende Kopplung von Wahrnehmen und Handeln müssen wir auf die Gestaltung von Nutzungsschnittstellen übertragen.

Der Begriff „intuitiv“ wird sehr gerne und sehr inflationär verwendet. Es ist verblüffend, welch komplexe und komplizierte Software in ihrer Eigenwerbung als intuitiv bezeichnet wird. In dem Adjektiv steckt das Nomen „Intuition“. Wenn man etwas aus der Intuition heraus tut, so tut man es quasi aus einem Bauchgefühl heraus, ohne dass es eine Verstandeserklärung dafür bedürfte. Wenn jedoch jemand behauptet, dass eine Software intuitiv bedienbar sei, dann legt der- oder diejenige damit nahe, dass sich die Software eben rein aus der Intuition, also ohne nachzudenken, erschließt. Doch ist das plausibel? Das Etikett „intuitiv“ wird einer Software angeheftet, wenn jemand, der sie nicht kennt, sie bedienen kann, ohne ein Handbuch lesen oder eine Schulung machen zu müssen. Unserer Ansicht nach sind Differenziertheit der Rückmeldung und Erschließbarkeit die Forderungen, die man also an intuitive Software stellt, denn eine Software, die diesen Forderungen entspricht, ermöglicht durch ihre Nutzungsschnittstelle, alle Optionen und Inhalte zu erschließen. Im besten Fall werden im Handlungsablauf so differenzierte Rückmeldungen gegeben, dass der Nutzer durch die Interaktion erfahren kann, was geschehen ist und was noch geschehen kann. Dennoch gerät die Erschließbarkeit immer wieder in Gefahr. Das ist nachvollziehbar, denn Erschließbarkeit erfordert zusätzlichen Bildschirmplatz für die Anzeige der zur Verfügung stehenden Operationen und Optionen. Erschließbarkeit steht damit in Konflikt zu vielen anderen Forderungen an die ergonomische Gestaltung. Wie immer in Design-Konflikten gilt es, eine dem Nutzungskontext angemessene Lösung zu finden. #### Unsichtbare Handlungsmöglichkeiten

Viele Anwendungen verfügen über Funktionalitäten, ohne entsprechende Hinweise darauf zu geben. Ein gutes Beispiel ist die in allen gängigen Präsentationssystemen enthaltene Funktion, während einer laufenden Präsentation eine beliebige Folie anzuspringen, indem lediglich die Foliennummer eingegeben und diese Eingabe durch Enter abgeschlossen wird. Das ist enorm praktisch, da es das Blättern durch die Präsentation vermeidet. Sie ist aber oftmals nicht bekannt, denn es gibt keinerlei sichtbaren Hinweis auf sie.

In vielen heutigen Nutzungsoberflächen lässt sich beobachten, dass bei mehreren angegebenen Handlungsmöglichkeiten nicht alle Optionen als Button angeboten werden, sondern die ablehnende oder abbrechende Operation weggelassen wird. In den beiden abgebildeten Beispielen scheint eine Auswahl mit nur einer Option geboten zu werden. Die jeweilige zweite Option, die das „Abbrechen“ verkörpert, erreicht man durch ein Klicken oder Tippen in den freien Bereich. Es spricht nichts dagegen, eine solche Abkürzung für das Ablehnen vorzusehen. Eine versehentlich ausgelöste Funktion lässt sich damit einfacher „wegklicken“ als mit einem Button. Das Problem ist aber, dass es keinen Hinweis darauf gibt, wie man die Einblendung wieder loswerden kann. In beiden Beispielen wäre genug Platz, jeweils auch die zweite Option unterzubringen.

Funktionen nur per Doppelklick oder Rechts-Klick erreichbar?

In früheren Versionen von Windows, wie hier in Windows XP, können Sie Dateien dadurch öffnen, dass Sie sie markieren und im Menü „Datei“ den Befehl „Öffnen“ wählen. Am Macintosh funktioniert das seit der ersten Version des Betriebssystems. Frühe Handbücher des Macintosh erklären das Öffnen auf diese Weise und verweisen auf den heute üblichen Doppelklick nur als Abkürzung für Profis. Dieser ist zwar heute allgemein üblich, doch schadet es nicht, wenn eine Funktion, die per Doppelklick ausgelöst wird, in der Nutzungsschnittstelle auch sichtbar und damit erschließbar vorhanden ist. Dies ist auch für jene eine Erleichterung, die sich mit dem Doppelklick schwertun, verbessert also die Handhabbarkeit des Systems.

Ebenfalls problematisch sind Funktionen und Operationen, die nur über ein Kontextmenü mittels rechtem Mausklick erreichbar sind. Es gibt keinerlei Hinweis darauf, dass dieses Menü an der jeweiligen Stelle auf diese Art und Weise aufgerufen werden kann. Das ist unproblematisch, wenn die gleichen Operationen auch an anderer Stelle aufrufbar und damit erschließbar bleiben.

Nutzungsschnittstellen jenseits des Bildschirmrandes

In Smartphones ist die Technik verbreitet, bestimmte Funktionen und Menüs durch das Streichen vom Bildschirmrand aufzurufen. Beim abgebildeten iOS streichen Sie zum Beispiel vom unteren Bildschirmrand nach oben, um von der aktuellen App auf die App-Übersicht zu wechseln. Wie Sie sehen, hat Apple für diese Funktion einen kleinen Hinweis in Form eines schwarzen Balkens vorgesehen. Dieser Balken ist eine Möglichkeit, die ein Mindestmaß an Erschließbarkeit sicherstellt. Zwar kann an dieser Stelle nicht in ausführlicher Prosa angegeben werden, was alles erreichbar ist, doch zeigt der Balken immerhin an, dass eine Manipulation möglich ist. Auch an anderen Stellen kann man in iOS durch Bewegungen über Bildschirmränder hinweg etwas auslösen. Wenn Sie vom rechten oberen Rand eine Streichbewegung nach unten vollziehen, öffnen sich beispielsweise die System-Schnelleinstellungen, in denen Sie etwa den Flugmodus aktivieren können. Es gibt jedoch keinerlei Hinweis darauf, dass dies möglich ist. Die Forderung nach Erschließbarkeit ist folglich nicht erfüllt; man muss es wissen, zufällig darauf kommen oder im Handbuch nachlesen, dass sich dieses Menü an dieser Stelle verbirgt.

Bei klassischen Nutzungsschnittstellen mit Maus und Tastatur haben Sie ein ähnliches Problem, wenn Sie Menüs und Buttons erst anzeigen, wenn die Maus an einen Bildschirmrand stößt. Solche sich selbst einblendenden Bildschirmobjekte werden oft in Vollbildmodi eingesetzt, um den vorhandenen Platz für den Inhalt zu maximieren. Die Folge ist ein Erschließbarkeits- und Orientierungsproblem, das dazu führen kann, dass keine Anschlusshandlungen vorgenommen werden. Um dieses Problem abzumildern, könnte beispielsweise eine Art Lasche am Bildschirmrand angezeigt werden, um weitere Handlungsoptionen zu signalisieren. Ist das unerwünscht oder störend, sollte zumindest eine Meldung zu Beginn darauf hinweisen, wie die zusätzlichen Funktionen zu erreichen sind.

Komplexe Gesten

Im Zusammenhang mit Touch-Eingaben sowohl auf Tablets und Smartphones als auch mit Trackpads an Laptops ist über die Zeit eine Vielfalt von Eingabegesten entstanden. Einige dieser Gesten haben sich auf vielen Eingabegeräten durchgesetzt. Dazu gehört zum Beispiel das Swipen zum nächsten Element oder auch das „Pinch-To-Zoom“, also das Auseinanderspreizen der Finger zum Vergrößern der Anzeige. Aktuelle Softwaresysteme verfügen aber oft über viele weitere Gesten mit drei oder mehr Fingern, mit Bewegungen oder Tippen, und teilweise abhängig davon, an welcher Stelle auf dem Bildschirm sie ausgeführt werden. Kennt man die Gesten gut, sind sie eine hervorragende Abkürzung, um Funktionen aufzurufen, die sonst nur viel komplizierter umsetzbar wären. Aus Sicht der Erschließbarkeit jedoch sind Gesten ein großes Problem, denn es gibt bei Gesten kein sichtbares Artefakt auf dem Bildschirm. Man kennt eine Geste oder man kennt sie nicht. Das ist kein Problem, wenn man die mit der Geste verbundene Funktionalität auch anders erreichen kann.

Gesten haben auch das Problem, dass es leicht ist, sie versehentlich auszulösen. Es wird eine Funktion aufgerufen oder eine Ansicht oder das Programm gewechselt, ohne dass dies der handelnden Person bewusst ist. Gesten, die über das Übliche hinausgehen, sollten mit einer neuen Anwendung nur eingeführt werden, wenn das Abkürzungspotenzial größer ist als die Fehlbedienungsgefahr.

Die Nutzung von Modifikationstasten

Die Tasten STRG, ALT und SHIFT auf Tastaturen sind sogenannte Modifikatoren. Für sich stehend haben Sie keinerlei Bedeutung und lösen meist auch nichts aus (mit der Ausnahme der ALT-Taste, die bei Windows klassischerweise das Menü der Anwendung öffnet). Das Drücken dieser Tasten modifiziert aber die Funktion, die eine Eingabe hat. Ein gutes Beispiel ist Drag and Drop bei einer Datei aus einem Finder- oder Explorer-Fenster heraus in ein anderes oder auf den Desktop. Je nachdem, ob sich Quelle und Ziel auf dem gleichen Datenträger befinden oder auf einem anderen, führt das Betriebssystem eine Kopier- oder Verschiebe-Aktion aus. Gefällt einem diese Auswahl nicht, kann man durch Drücken von SHIFT dafür sorgen, dass die Dateien verschoben, mit STRG, dass sie kopiert werden, und mit ALT, dass eine Verknüpfung angelegt wird. An keiner Stelle zeigt das System an, dass man mit diesen Tasten die Funktion beeinflussen kann. Es wird auch zu keinem Zeitpunkt an irgendeinem Ort angezeigt. Auch dies ist nicht problematisch, solange eine andere Möglichkeit gegeben ist, an die jeweilige Funktion zu gelangen. Fehlt eine solche Möglichkeit jedoch, liegt ein Erschließbarkeitsproblem vor.

Das Vertrauen auf Drag and Drop

Die letzte in unserer sicher nicht vollständigen Liste von Techniken, die zwar verbreitet, aber in Sachen Erschließbarkeit problematisch sind, ist das Drag and Drop, also das Auslösen von Funktionen dadurch, dass Objekte am Bildschirm durch Touch-Bewegungen oder bei gedrückter Maustaste verschoben werden können. Dass Drag and Drop zur Verfügung steht, muss man wissen. Den Objekten, die bewegt werden können, kann man das in vielen Fällen nicht ansehen. Auch hier ist es unproblematisch, Drag and Drop einzusetzen, man muss aber entweder verdeutlichen, dass diese Funktionalität besteht, oder aber (am besten zusätzlich) dafür sorgen, dass die Funktionalität auch auf andere Weise zur Verfügung steht. In den gängigsten Dateimanagern ist das gut gelöst. Man kann per Drag und Drop Dateien verschieben oder es genauso gut über das Menü, über ein Icon in einer Symbolleiste oder per Tastenkombination erledigen. Drag and Drop ist eine Möglichkeit, die nicht erschließbar ist, aber da sie nicht die einzige Möglichkeit ist, ist das nicht tragisch.

Unsere kleine Aufstellung soll verdeutlichen, dass die vorgestellten Techniken im Sinne der Erschließbarkeit oft problematisch sein können. Das ist aber kein grundsätzliches Problem, wenn dafür Sorge getragen wird, dass die Erschließbarkeit auf andere Art und Weise gewährleistet ist. Dies geht entweder durch einen sichtbaren, also erschließbaren Hinweis auf die sonst nicht sichtbare Nutzungsschnittstellentechnik oder aber durch das Bereitstellen verschiedener Wege zum Ziel, die erschließbar sind.

Aufdecken bei Bedarf

Übergänge sind immer nötig, wenn – was nahezu immer der Fall ist – nicht alle Inhalte und Optionen auf einer Bildschirmseite angezeigt werden können oder es aus Gründen der Komplexitätsreduzierung der Aufgabe nicht sollen. Damit diese Inhalte und Optionen nicht einfach entfallen, braucht es einen Mechanismus, sie bei Bedarf anzuzeigen. Auch für dieses Aufdecken bei Bedarf gilt es, die Forderung nach Erschließbarkeit zu gewährleisten.

Aufdecken bei Bedarf wurde 1981 mit der Vorstellung des Xerox Star unter dem Namen „Progressive Disclosure“ bekannt ². Zu sehen ist ein Eigenschaften-Fenster, das die Attribute des Textes eines Textdokuments betrifft. Obwohl man Vieles einstellen kann, bietet die Maske nicht alle Einstellungen direkt an. Für die Wahl der Abstände vor und nach einem Absatz sowie für den Zeilenabstand hat man sich dafür entschieden, nur die häufigsten Einstellungen direkt verfügbar zu machen und die selten genutzte Einstellung für andere Werte erst anzuzeigen, wenn auf „Other“ geklickt wird. Gemäß der Argumentation des Entwicklungsteams ist aber auch das Anzeigen der Eigenschaften in einem überlappenden Fenster, das erst erscheint, wenn es explizit aufgerufen wird, eine Umsetzung von Progressive Disclosure, denn auch in diesem Fall wird ein Teil der Nutzungsschnittstelle erst angezeigt, wenn es explizit verlangt wird.

Elemente dauerhaft anzuzeigen erfordert Platz und kann Probleme mit der Übersichtlichkeit erzeugen, hat aber den Vorteil, dass sie sofort zu sehen sind. „Versteckt“ man sie hingegen im Menü eines erst aufzurufenden Fensters, besteht die Möglichkeit, dass sie nicht gefunden werden. In jedem Falle entsteht Zusatzaufwand durch das Aufrufen des Menüs oder des Fensters. Eine Aufdecktechnik, und um die handelt es sich auch bei Menüs, sollte also mit Bedacht und ausgewogen eingesetzt werden.

Die Abbildung zeigt ein typisches Beispiel der Aufdecktechnik in einem FTP-Programm. Für die meisten Anwendungsfälle reichen die auf der linken Seite gezeigten Einstellungen. Falls aber doch weitere nötig sein sollten, kann der Bereich „Erweiterte Einstellungen“ aufgeklappt werden. Allerdings sagt „Erweiterte Einstellungen“ nichts darüber aus, was zu erwarten ist und was vielleicht noch eingestellt werden könnte. Durch das nicht dauerhafte Anzeigen dieser Einstellungen bleiben sie zunächst unerkannt, es sei denn, man blendet ohnehin die verdeckten Bereich ein, um sehen zu können, was sich dahinter verbirgt. Was im Rahmen einer routinierten Nutzung von Vorteil ist, kann im Rahmen gelegentlicher Nutzung und beim Erlernen des Systems ein Problem bereiten. Wann immer es möglich ist, versuchen Sie daher den Auslöser für das Aufdecken möglichst spezifisch zu benennen. Im gezeigten Beispiel wäre es zugegebenermaßen schwierig, da ein ganzes Sammelsurium verschiedenster Einstellungen gebildet worden ist. Wären es beispielsweise nur Einstellungen zur Verschlüsselung, wäre „Weitere Verschlüsselungsoptionen“ besser gewählt als „Erweiterte Optionen“.

Auch dieses Beispiel illustriert ein Aufdecken bei Bedarf oder, in der Gegenrichtung formuliert, ein Zuklappen bei Bedarf. Zu sehen ist der Editor Notepad++. Dieser bietet eine Funktion, Codeblöcke auf- und zuzuklappen. Im zugeklappten Zustand bleibt lediglich die Kopfzeile stehen, sodass man immer noch sieht, welche Funktionen es gibt und welche Signatur diese haben.

Verdeutlichung der Handlungsfolgen

Zur Erschließbarkeit gehört es, dass die möglichen Handlungsoptionen nicht nur benannt, sondern auch im Hinblick auf ihre Folgen beschrieben werden. Man könnte von einer Art „vorausschauender Rückmeldung“ sprechen, die, wie Rückmeldungen grundsätzlich, differenziert sein müssen. Dazu ein Beispiel: Ergonomische Nutzungsschnittstellen bieten meist, entsprechend unserer Forderung nach Beeinflussbarkeit, eine Möglichkeit an, getätigte Eingaben und andere Manipulationen rückgängig zu machen. Während der Ausführung vieler kleiner Handlungen ist aber mitunter nicht offensichtlich, was genau die letzte Handlung war, was also passiert, wenn eine Funktion, die mit „Rückgängig“ oder „Widerrufen“ betitelt ist, aufgerufen wird.

Die Anzeige im Finder von MacOS enthält mehr Informationen, denn dort steht nicht nur „Rückgängig“ oder „Widerrufen“, sondern auch, welche Operation widerrufen werden soll. Ideal ist die Umsetzung aber nicht, denn es wird nicht klar, um welches Objekt oder um welche Objekte es sich handelt, deren Bewegung widerrufen wird.

An anderer Stelle ist dies besser gelöst worden. Die Funktion zum Kopieren des markierten Objekts ist sehr spezifisch beschriftet, sodass klar ist, was passieren wird, wenn man diese Funktion aufruft. Unbedingt nötig wäre das in diesem Fall nicht, denn das markierte Objekt ist noch zu sehen. Doch sollte man im Sinne einer robusten Gestaltung davon ausgehen, dass das nicht immer der Fall sein muss.

Umso verblüffender ist es, dass beim Gegenstück zum Kopieren einer Datei in die Zwischenablage, also dem Einfügen, der gerade in der Zwischenablage befindlichen Datei nicht angegeben wird, welches Objekt eingefügt wird. An dieser Stelle wäre es hilfreich, die Datei zu benennen, denn sie ist in der Zwischenablage nicht sichtbar.

Vorschau vermeidet Probehandeln

Funktionsaufrufe in einem Menü spezifisch zu beschriften statt einfach nur generell „Rückgängig“ oder „Kopieren“ zu schreiben, könnte man auch als eine sehr einfache Art der Vorschau charakterisieren. Der entsprechende Menüeintrag beschreibt nicht nur eine Funktion, sondern legt auch nahe, wie der Folgezustand nach der Ausführung der Funktion sein wird. Vorschauen sind in gewisser Weise wie Berechnungen. Eine Berechnung ermöglicht Probehandeln, indem das Ergebnis bestimmter Handlungen errechnet werden kann, ohne die tatsächliche Handlung vollziehen zu müssen. Vorschauen in Nutzungsschnittstellen bieten dieses Potenzial auch. Sie offenbaren die Konsequenzen einer Handlung bzw. den Aufruf einer Funktion, bevor diese mit allen Konsequenzen ausgeführt werden müssen.

Das Beispiel zeigt eine etwas komplexere Art der Vorschau aus Microsoft PowerPoint. Eine Vorschau verdeutlicht die Konsequenz einer Handlung, in diesem Fall der Auswahl eines Stils, bevor die entsprechende Aktion ausgeführt wird. Die Stile werden nicht nur per Namen aufgerufen, sondern es erscheint eine Ansicht, in der man sieht, wie das Ergebnis aussieht, wenn der jeweilige Stil ausgewählt wird. Um zu einer Auswahl zu kommen, muss man nicht erst Stil 1 bis Stil 5 oder „Professionell“ bis „Verspielt“ einzeln anwenden, um zu einer Einschätzung zu kommen.

Auch diese Vorschaufunktion des Finders, der Dateimanager von MacOS, zeigt das potenzielle Ergebnis einer Handlung, ohne dass sie durchgeführt werden muss. Hätte man die Vorschau nicht, hätte man eine Reihe von Dateien, die allenfalls durch ihren Titel verdeutlichen, was sich dahinter verbirgt. Oft reicht das nicht. Befindet sich eine bestimmte Folie nun in diesem oder in jenem Foliensatz? War dieses oder jenes das Foto vom Kölner Dom? Um das herauszufinden, müsste man die Dateien nacheinander öffnen, was immer mit zusätzlichem Aufwand und mit einem Kontextwechsel verbunden ist. Die Vorschaufunktion ermöglicht auch das Blättern innerhalb des Foliensatzes, was sehr sinnvoll ist, da die Titelfolien von Foliensätzen sich oft kaum unterscheiden. Das Inhaltsangebot wird dadurch erschließbar, ohne dass die Anwendung gestartet werden müsste.

Interne Konsistenz

Die Forderung nach Erschließbarkeit ist essentiell, um die Orientierung in einem Softwaresystem zu unterstützen. Neben der Erschließbarkeit haben wir mit interner Konsistenz und Kontinuität zwei weitere wichtige Forderungen, die zwar allein nicht für Orientierung sorgen können, bei deren Nichtbeachtung aber die Orientierung beeinträchtigt ist.

Mit der Forderung nach interner Konsistenz soll sichergestellt werden, dass man während der Nutzung eine stabile Umgebung vorfindet, in der man trotz des Hin- und Herwechselns zwischen verschiedenen Bildschirmseiten sich in einer vertrauten Umgebung befindet. Eine wichtige Grundlage für den Aufbau dieses Vertrauens während der Nutzung ist die Forderung nach interner Konsistenz.

In diesen Screenshots einer universitären Lernplattform ist in allen drei Bildern ein Nutzungsschnittstellenelement markiert, das dazu dient, neue Objekte zu erzeugen. In den drei unterschiedlichen Bereichen der Software sieht dieses Schnittstellenelement jeweils unterschiedlich aus und ist auch verschiedenartig bezeichnet. Eine neue Datei wird angelegt bzw. hochgeladen durch einen Klick auf ein Icon innerhalb einer Icon-Leiste. Ein neuer Termin im Kalender wird durch einen Button angelegt, der mit „Neuer Termin“ beschriftet und rechtsbündig angeordnet ist. Ein neuer Beitrag im „Website-Blog“ wird angelegt durch einen Klick auf „Neuer Beitrag“ – in dieser Hinsicht konsistent zum Kalender –, allerdings nicht auf einen Button, sondern auf einen Hyperlink, und auch nicht rechtsbündig, sondern zentriert über der Anzeige der bisherigen Beiträge.

Für diese Unterschiede gibt es weder eine funktionale noch ergonomische Rechtfertigung. Inkonsistenzen innerhalb einer Anwendungswelt betreffen in vielen Fällen die Wortwahl in verschiedenen Bereichen einer Software. Haben wir es mit Einstellungen, mit Optionen oder mit einer Konfiguration zu tun? Wird eine Einstellung bearbeitet oder geändert? Wird sie angewandt oder übernommen? Selbst wenn die Konsequenzen vergleichsweise harmlos sein sollten, muss die Tatsache, dass verschiedene Dinge gleich sind, erst erlernt und verstanden werden; also in jedem Fall erzwungene Sequenzialität, da die Unterschiede ja bedeutungslos sind. Bestenfalls sorgt das nur für eine kurze Irritation, schlimmstenfalls aber werden unnötige Unterschiede falsch interpretiert.

Achtung: Ein Unterschied, der keinen Unterschied macht, ist immer eine Verletzung der internen Konsistenz. Der Unterschied wird zwar wahrgenommen, aber es steckt keine Information dahinter. Differenzerfahrung wird sabotiert.

Die Forderung nach interner Konsistenz bezieht sich auf viele Aspekte einer Nutzungsschnittstelle. Neben den Bezeichnungen, dem Objektaussehen, der Objektposition und der Anordnung von Objekten kann dies auch die Funktionsweise der Oberfläche betreffen.

Diese Screenshots zeigen zwei Einstellungsfenster des Windows Editors Notepad++. Obwohl die beiden Fenster ähnliche Einstellungen zu Programmfunktionen ermöglichen, funktionieren sie auf unterschiedliche Art und Weise. Das mit „Stile“ beschriftete Fenster hat Buttons zum „Abbrechen“ und zum „Speichern & Schließen“. Zunächst wird also die Auswahl angezeigt und erst durch die Auswahl einer Alternative die entsprechende Funktion ausgeführt. Im Fenster „Optionen“ wird diese Auswahl nicht angezeigt. Jeder Klick wird sofort umgesetzt. Es gibt keine Möglichkeit, sie in der Gesamtheit wieder zurückzunehmen. Das Fenster kann lediglich geschlossen werden. Diese Inkonsistenz ist problematisch, denn im Optionen-Fenster kann der Eindruck entstehen, dass die getätigten Einstellungen nicht zur Anwendung kommen, da es keinen entsprechenden Button gibt. Personen, die sich entsprechend der Funktionsweise des unteren Fensters angewöhnt haben, das Einstellungsfenster nach den Einstellungen über das Icon X im Fensterkopf zu schließen, würden im oberen Fenster wahrscheinlich eine Fehlhandlung begehen, weil sie in diesem Fall den Einstellungsvorgang ungewollt abbrechen.

Das logische Gegenstück dazu, dass Gleiches gleich gestaltet werden soll, ist, dass Ungleiches auch ungleich gestaltet werden sollte. Dies betrifft auch Bezeichner und Icons, also zum Beispiel, dass das gleiche Icon für verschiedene Funktionen eingesetzt wird, also eine Lupe nicht einmal eine Suchfunktion auslöst und an anderer Stelle eine Vergrößerung bewirkt oder dass der gleiche Ausdruck „Schließen“ mal nur ein Fenster schließt und im anderen Falle einen Vorgang abschließt.

Interne Konsistenz in einer Software kann man nur dadurch erreichen, dass man die Dinge, die gleich sein müssen, und die Dinge, die unterschiedlich sein müssen, explizit festlegt.

Die Erstellung von Design-Guidelines ist eine wertvolle Hilfe bei der Entwicklung, zumal wenn der Entwicklungsprozess sich über einen längeren Zeitraum und mehrere Versionen erstreckt. In Design-Guidelines werden von Schriftgrößen, Farben, dem Aussehen von Buttons und Icons bis zu Ausrichtungen all diese Eigenschaften festgelegt. Technisch komplementiert werden können Design-Guidelines durch die Verwendung von Vorlagen (Templates) und Ressourcenbibliotheken. Hiermit wird ein hohes Maß an Konsistenz bereits dadurch garantiert, dass Gestaltungsoptionen nicht mehr individuell festgelegt werden, sondern übergreifend für alle Beteiligten festgeschrieben werden.

Bei der Verwendung von Templates bewegt man sich jedoch auf einem schmalen Grat. Je mehr man innerhalb eines Templates explizit vorgibt, desto mehr besteht die Gefahr, dass das Design generisch wird, es also schlimmstenfalls auf zu generische Beschriftungen und Elemente hinausläuft. Durch ein unbedachtes Template könnte ein Einstellungsfenster zum Beispiel stets mit einem Knopf „Anwenden“ versehen werden. Wird dieses Template aber nun zum Beispiel auch für die Einstellungen für einen Druckvorgang verwendet, wäre „Anwenden“ nicht die richtige Wahl. Wir hätten durch den Versuch, Konsistenz auf einer Ebene herzustellen, ein Konsistenzproblem geschaffen, denn nun würde Ungleiches gleich benannt.

Da bei der Bezeichnung von Objekten und Funktionen schnell Konsistenzprobleme entstehen, möchten wir das Anlegen eines Glossars und das Einhalten und Überarbeiten desselben dringend empfehlen. Gerade bei verteilter Arbeitsweise muss organisatorisch dafür gesorgt werden, dass sowohl die Design-Vorlage als auch das Glossar für alle Software-Teile gelten.

Stabile Objektpositionen

Ein wichtiger Aspekt beim Übergang sowohl innerhalb einer Bildschirmseite, wenn sich dort etwas am Objektarrangement ändert, als auch beim Wechsel zwischen zwei unterschiedlichen Bildschirmseiten sind stabile Positionen der Elemente.

Die drei Screenshots zeigen verschiedene Einfügeoperationen aus LibreOffice (Literatureintrag, Indexeintrag und Lesezeichen). Alle drei Masken enthalten die Buttons „Close“, „Insert“ und „Help“, jedoch an unterschiedlichen Positionen im Fenster. Bei den ersten beiden Screenshots befinden sich die Objekte einmal unten und einmal rechts oben. Diese Inkonsistenz führt eventuell zu kurzen Irritationen, doch eine Fehlbedienung ist eher nicht zu erwarten. Problematischer ist der Unterschied zwischen dem ersten und dritten Screenshot, denn beide Fenster zeigen jeweils unten fünf Knöpfe an, die sich aber in Funktion und Reihenfolge unterscheiden. Eine häufige Nutzung der Funktion zum Einfügen von Literatureinträgen beispielsweise führt dazu, dass die Position der Buttons mit der jeweiligen Funktion identifiziert wird (Ortskodierung). Je stärker eine Routine ausgeprägt ist, desto weniger verwendet der Wahrnehmungsapparat noch aufwändige Lesehandlungen, um sicherzustellen, dass auf dem Button auch die erwartete Funktion steht. Wenn diese Routinehandlung auf die Bookmark-Funktion angewandt wird, kann es passieren, dass statt auf „Insert“ auf „Help“ und statt auf „Rename“ zum Bearbeiten auf „Close“ geklickt wird.

Wie groß die Gefahr solcher Fehlhandlungen ist, zeigt sich auch darin, dass Personen in vertrauten Nutzungssituationen dazu neigen, bei sich langsam aufbauenden Bildschirmseiten die Maus bereits an die Position zu bewegen, an der sie ein Objekt erwarten. Dies entspricht der Grundarchitektur der Wahrnehmung mit ihren getrennten Wahrnehmungsbereichen für das Verarbeiten des „Was“ und des „Wo“, bei dem Hypothesen zur Position von Objekten dominieren (siehe unsere Erläuterungen im Unterkapitel zum Hypothesengenerator). In der Konsequenz gilt es folglich zu vermeiden, Objektpositionen ohne Notwendigkeit zu verändern. Zudem sollte in der Regel über die Anordnung während der Nutzung explizit entschieden werden können (siehe Anpassbarkeit im Kapitel Flexibilität). Das Ändern von Objektpositionen sollte stets auf ein Minimum reduziert werden. Das hat auch Konsequenzen für den Fall, dass Objekte am Bildschirm neu erscheinen oder verschwinden. Idealerweise bleiben die übrigen Objekte an ihrem Ort.

Wie Sie am obigen Beispiel der Suchfunktion innerhalb der Systemeinstellungen des Macintosh sehen, werden bei der Eingabe eines Suchbegriffs bestimmte Elemente innerhalb der Objektauswahl hervorgehoben. Die nicht hervorgehobenen Objekte bleiben sichtbar, vor allem aber bleiben alle Objekte auf ihren Positionen am Bildschirm. Die Objektpositionen sind stabil, es kommt zu keinen abrupten Positionsänderungen.

Wichtig sind diese stabilen Objektpositionen auch bei formularartigen Eingabebereichen wie dem rechts abgebildeten Einstellbereich der Software „FastRawViewer“. Dieser verfügt über Einstellungen für den sogenannten „Grid-Mode“. Nur wenn diese Funktion aktiviert ist, ist es sinnvoll, Einstellungen für diesen Modus vorzunehmen. Statt nun aber bei deaktiviertem Grid-Mode die Einstellungen komplett auszublenden, wird eine Ausgrautechnik verwendet. Sie hat den Nachteil, dass Platz „verschwendet“ wird, dem aber klare Vorteile gegenüberstehen: Würde der Einstellungsbereich beim Deaktivieren der Funktion vollständig verschwinden, würden beim Umschalten die Elemente, die sich darunter befinden, nach oben springen. Dieser plötzliche Übergang kann sehr desorientierend sein. Zudem hat die grundsätzliche Sichtbarkeit der Einstellungsmöglichkeiten, auch wenn sie nicht nutzbar sind, den Vorteil, dass sie die Orientierung, welche Einstellungen möglich sind, unterstützen, und damit indirekt auch, was der Grid-Mode eigentlich ist. Würde das Ausgrauen nicht eigesetzt, müsste man den Modus erst aktivieren, um zu sehen, welche Einstellungen er beinhaltet. Dieser Zwischenschritt kann beim Ausgrauen entfallen.

Geschmeidige Übergänge

Situationen, in denen Objekte in einer Nutzungsschnittstelle ihre Position verändern, lassen sich nicht vermeiden. Die Möglichkeit, alle Objekte am Bildschirm zu behalten und lediglich auszugrauen, ist stark abhängig von der Anzahl der Elemente und letztlich auch von dem Szenario, in dem wir uns befinden. Bei dem Verzeichnis-Listing im Finder von Apple sind vier Ordner zu sehen. Der Finder erlaubt es, diese Ordner aufzuklappen, um die Elemente darin anzusehen (rechts im Bild). Bei dieser Aufklapptechnik sind die Positionen der Objekte am Bildschirm nicht mehr konstant. Jedes Objekt außer dem Objekt „Bilder“ verschiebt sich nach unten, hat also seine Position verändert. Positionsänderungen dieser Art sind oft unvermeidbar, etwa wenn Fenster geöffnet und geschlossen werden, wenn Sortieroptionen geändert werden, oder allgemein, wann immer ein Wechsel der Position aufgrund der Anwendungslogik nötig sein sollte.

In jeder dieser Situationen kann es zu Orientierungsproblemen kommen, denn was gerade noch zu sehen war, ist nicht mehr sichtbar und neue oder veränderte Objekte tauchen plötzlich auf. Das menschliche Wahrnehmungssystem ist auf solche disruptiven Änderungen nicht eingestellt. Um sie räumlich verstehen und leichter nachverfolgen zu können, ist es deshalb hilfreich, die Übergänge kontinuierlich zu gestalten.

Ein Mittel, Kontinuität zu erreichen, sind Animationen. Im oben beschriebenen Beispiel des aufgeklappten Ordners springen die Elemente, die nach unten wandern, nicht schlagartig an den neuen Ort, sondern bewegen sich in einer zügigen, aber sichtbaren Bewegung dorthin.

Ein gutes Beispiel für derartige Kontinuität durch Animation findet sich in MacOS, wo beim Minimieren von Fenstern sich dieses kontinuierlich verkleinert und dabei auf seinen Platz innerhalb des Docks wandert. Das Fenster verschwindet nicht spurlos, sondern deutet mit dem Übergang nachvollziehbar an, wo es anschließend wieder ansprechbar ist. Das Gleiche passiert, wenn das Fenster von dort aus wieder vergrößert wird. Windows 10 hat einen ähnlichen Mechanismus, der grafisch weniger aufwändig, aber ebenso effektiv ist.

Um das Wahrnehmungssystem zu entlasten, sollten disruptive Veränderungen des Bildschirminhalts grundsätzlich vermieden werden, indem man Übergänge kontinuierlich und geschmeidig gestaltet.

Kontinuität bei Rückmeldungen

Kontinuierliche Übergänge sind oft Teil einer Rückmeldung auf eine getätigte Eingabe. Ein Klick auf ein Minimieren-Icon in einem Fenster hat zur Folge, dass das entsprechende Fenster auf eine kontinuierliche Art und Weise minimiert wird.

Die Abbildung soll die Kopplung der Unmittelbarkeit einer Rückmeldung mit der Kontinuität einer differenzierten Rückmeldung illustrieren. Zu sehen ist eine Liste, bei der einzelne Objekte durch Drag and Drop in der Reihenfolge verändert werden können. Beim Herausziehen des Objekts „Navigation“ aus der Liste muss das System, wie immer bei Drag and Drop, unmittelbar reagieren, denn nur so kann sichergestellt werden, dass das Objekt dem Mauszeiger ohne Probleme folgt. Wenn das Objekt nun, bei noch gedrückter Maustaste, in die Nähe einer Position geschoben wird, an der sich bereits ein anderes Element befindet, wandert dieses in einer kurzen Animation nach unten oder nach oben. Dadurch lässt sich verfolgen, welche Änderung passieren würde, würde das Objekt an der jeweiligen Position „fallengelassen“.

Kontinuität durch Erhalt des räumlichen Kontextes

Auch bei kontinuierlichen Übergängen sollten Bildschirminhalte nur so weit überschrieben werden, wie es aus inhaltlichen oder funktionalen Gründen erforderlich ist.

In der Windows-Version von Microsoft Word müssen Sie auf „Datei“ klicken, um einen geschriebenen Text abzuspeichern. Ab dem Augenblick ist jedoch Ihr Text und alles andere, was Word Ihnen bis dahin gezeigt hat, nicht mehr zu sehen. Das kann nicht nur für Irritationen sorgen, sondern nimmt Ihnen auch jede Möglichkeit des Bezugs auf den Text, beispielsweise um einen geeigneten Dateinamen zu wählen. Zwischen dem Eingabe- und dem Speichern-Modus vollzieht sich ein Wechsel der Objektumgebung. Das ist besonders kritisch, weil der bisherige Arbeitskontext vollständig ausgeblendet wird. Das sollte, soweit es geht, vermieden werden.

Auch in diesen Beispielen wird eine Überlagerung verwendet, um neu benötigte Objekte anzuzeigen, jedoch ohne die bisherige Umgebung komplett unzugänglich zu machen. Alle Beispiele haben gemeinsam, dass der Hintergrund jeweils durch Abdunkeln bestehen bleibt. Diese Art der Überlagerung bietet sich an, wenn die Bearbeitung des Vordergrundobjekts weiterhin erforderlich ist, bevor mit dem Ensemble im Hintergrund wieder gearbeitet werden kann. Hierzu gehören vor allem Bestätigungsmeldungen und Einstelldialoge. Eine übliche Konvention und sinnvolle Abkürzung bei dieser Art der Überblendungen ist es, einen Klick in den abgedunkelten Hintergrund mit der Abbrechen-Option zu verknüpfen.

Navigation

Im vorherigen Kapitel haben wir mit Erschließbarkeit eine der wichtigsten Forderungen beschrieben, um einen Computer möglichst weitgehend ohne vorherige Schulungen oder das Lesen eines Handbuchs nutzen zu können. Die Forderung zielt darauf ab, am Bildschirm sichtbare Hinweise zu geben, welche Operationen möglich sind, wie man sie ausführen kann und welche Inhalte erreichbar sind. Dies ist jedoch nur vollständig umsetzbar, wenn es gelänge, für jede mögliche Anschlusshandlung und auf jedes Inhaltsobjekt einen sichtbaren Hinweis zu geben. Anhand eines großen Textverarbeitungssystems wie beispielsweise Microsoft Word lässt sich vergegenwärtigen, was ein solcher Anspruch auf Vollständigkeit bedeuten würde. Das System müsste beispielsweise für jede Funktion der Software dauerhaft ein sichtbares Icon als Hinweis anzeigen. Der Bildschirm bestünde nur noch aus Icons und Hinweisen auf Tastenkürzel und würde vermutlich noch nicht einmal alle Funktionen abbilden können. Für den eigentlichen Inhalt, den zu bearbeitenden Text, bliebe kein Platz. Vollständigkeit ist mit Ausnahme sehr einfacher Nutzungsschnittstellen, etwa einer Lichtsteuerung, nicht ohne Gestaltkonflikte umsetzbar.

Die sich aus dieser Erkenntnis ergebenden Problemstellungen werden mit Techniken von Nutzungsschnittstellen gelöst, die wir unter dem Begriff „Navigationsschnittstellen“ zusammenfassen wollen. Dabei geht es darum, wie man die möglichen Handlungsoptionen und Inhalte, ohne zu viel Platz zu verbrauchen und ohne unübersichtlich zu werden, zugänglich machen und wie man den Ausschnitt aus einem Objekt darstellen und den Rest zugänglich machen kann.

Navigation ist immer mit Sequenzialität verbunden, denn wenn Sie erst navigieren müssen, um etwas zu erreichen, heißt es, dass das, was Sie erreichen wollen, nicht sofort im Zugriff ist, es also Zusatzschritte braucht. Gänzlich vermeiden lässt sich diese Sequenzialität nicht, denn es sind nicht nur viele Forderungen wie Erkennbarkeit (alle Objekte sind hinreichend vom Hintergrund abgesetzt etc.), Übersichtlichkeit und Strukturiertheit (die Objekte sind räumlich abgesetzt), Handhabbarkeit (die verschiedenen Alternativen sind sicher auswählbar) und Eingabeminimalität (für die Auswahl einer Option sollten möglichst wenig Eingaben notwendig sein) zu bedenken, die Abwägung dieser Anforderungen hängt auch von einer Vielzahl von Rahmenbedingungen wie Bildschirm- bzw. Fenstergröße, Eingabemodus, erwarteten Nutzungscharakteristiken etc. ab. Die Konsequenz ist, dass es keine für alle Einsatzzwecke gleich gut geeignete Navigationsschnittstelle gibt. Stattdessen gilt es, das Spektrum aufzuspannen, die auftretenden Gestaltungskonflikte zu erkennen und über die Ausgestaltung verbreiteter Navigationstechniken nachzudenken.

Vielleicht sind Sie über den Begriff „Navigationsschnittstelle“ gestolpert, den wir hier verwenden. Wir wollen damit unseren Fokus auf Navigationstechniken einschränken, die über eigene Objekte in der Nutzungsschnittstelle verfügen. Diese Navigationsobjekte erscheinen als zusätzliche Elemente zu den eigentlichen Inhaltsobjekten der Anwendung. Wir bezeichnen solche Elemente in Anlehnung an den Experten Jacob Nielsen als „GUI-Chrome“³.

Wir beschränken uns bei unserer Betrachtung von Navigationstechniken auf solche, die zum GUI-Chrome gehören, bei denen es also eine explizite Nutzungsschnittstelle zur Erschließung der Inhalte und Optionen gibt⁴. Obiger Screenshot von Microsoft Word kann gut verdeutlichen, um welche Art von Bildschirmelementen es uns geht. Im Inhaltsbereich in der Mitte werden Anwendungsobjekte angezeigt. Rund um diesen Inhaltsbereich befindet sich aber viel GUI-Chrome; von den von Microsoft „Ribbons“ getauften Reitern (deutsch: „Menüband“ oder technokratisch „Multifunktionsleiste“) im oberen Teil des Bildes, über eine Scrollbar auf der rechten Seite bis hin zur Fußzeile unten. Die meisten Elemente im GUI-Chrome sind Navigationselemente, denn sie dienen der Zugänglichmachung der Funktionalität der Software einerseits (die Ribbons, die Kurzwahlleiste oben, die Icons und Menüs innerhalb der Ribbons) und der Manipulation und Darstellung des sichtbaren Ausschnitts andererseits (die Scrollbar, die Zoom-Einstellungen, die Seitenangabe). Daneben gibt es auch einige wenige andere Metainformationen, die hier ebenfalls untergebracht sind, etwa die Anzeige der Dokumentsprache. Ebenfalls zum Bereich des GUI-Chromes zählen wir Objekte wie das Pop-up-Menü im obigen Beispiel oder auch Navigationsbereiche, die in den Inhalt eingebunden sind oder eingeblendet werden, aber nicht selbst den Inhalt verkörpern.

Was GUI-Chrome, also Anwendungsrahmen, ist und was der Inhalt der Anwendung ist, kann sich so verhalten wie die russischen Matroschkas. Beim Auseinandernehmen der größeren Puppe kommt eine kleinere, identisch aussehende Puppe zum Vorschein. Vor allem in webbasierten Nutzungsschnittstellen ist das so. Der Browser selbst hat sein GUI-Chrome, das dazu dient, Websites anzusteuern, Lesezeichen zu verwalten und andere Browser-Funktionalitäten zugänglich zu machen. Daneben gibt es den Inhaltsbereich, in dem Websites angezeigt werden. Wenn man nun eine Website oder Web-Anwendung öffnet, zum Beispiel eine Online-Version einer Textverarbeitung, hat auch diese Anwendung wieder ihren GUI-Chrome- und ihren Inhaltsbereich.

Navigationsschnittstellen zur Wahl des Ausschnitts

Die Menge der Inhaltsobjekte einer Anwendung (zum Beispiel die Bilder im Fotoalbum, die heruntergeladenen Musikstücke oder der Inhalt eines Verzeichnisses der Festplatte) und auch die einzelnen Inhaltsobjekte selbst (etwa ein Textdokument oder aber auch ein Eingabeformular) können in den wenigsten Fällen auf nur einer einzigen Bildschirmseite vollständig angezeigt werden. Der Ausschnitt dessen, was gerade angezeigt wird, ist immer begrenzt. Wenn Sie nur einen Ausschnitt sehen, kann es zu Orientierungsproblemen kommen. Gestaltet man die Navigationsschnittstelle nicht angemessen, kann es passieren, dass während der Nutzung nicht erkannt wird, dass es sich nur um einen Ausschnitt handelt. Das bedeutet, dass die weiteren Inhalte nicht erschließbar sind und dass es keine Unterstützung gibt, um eine Vorstellung davon zu entwickeln, wie sich der aktuelle Ausschnitt zum Ganzen verhält.

Zoomen

Ein Ansatz zur Wahl des Ausschnitts kann eine Zoom-Technik sein. Sie soll zweierlei leisten, zum einen, den Überblick über den gesamten oder zumindest einen großen Teil des Inhalts anzubieten, zum anderen aber auch eine Detailbetrachtung zu ermöglichen, indem die Granularitätsstufe gewechselt wird. Gute Zoom-Techniken erlauben es, zwischen mehreren Granularitätsstufen geschmeidig hin und her zu wechseln.

Der folgende Screenshot zeigt mehrere Seiten eines Textes in einer verkleinerten Darstellung. Diese Darstellung ist gut geeignet, um sich eine Übersicht zu verschaffen, nicht aber, um den Text tatsächlich zu lesen.

Scrolling

Wenn nicht alle Objekte zu sehen sind oder nicht das vollständige Objekt auf einmal angezeigt werden kann, braucht es einen Mechanismus, um den aktuellen Ausschnitt erschließbar und manipulierbar zu machen. Eine der beiden wichtigsten Techniken hierfür ist das Scrolling (auf Deutsch „Rollen“ oder „Bildlauf“ genannt). Scrolling an sich kommt ohne Schnittstellenelemente aus. In einem Text kann zum Beispiel der Cursor bewegt werden. Der dargestellte Bildausschnitt wandert mit dem Cursor mit, sobald dieser den aktuellen Bildschirmbereich verlässt. Ein derart simples Scrolling ist aber aus mehreren Gründen nicht ergonomisch, denn es liefert keine erschließbaren Hinweise auf die Ausschnittsnavigation. So ist nicht direkt ersichtlich, dass es weiteren Inhalt gibt, dass auf diese Weise gescrollt werden kann, welcher Ausschnitt innerhalb des Ganzen gerade zu sehen ist und schlussendlich, welches Verhältnis der aktuelle Ausschnitt zum Ganzen hat. Abhilfe für diese Erschließbarkeitsprobleme schafft eine Scrollbar.

Eine Scrollbar (deutsch „Rollbalken“ oder „Bildlaufleiste“), dargestellt sind die Bildlaufleisten des Atari ST aus den 1980er Jahren, zeigt nicht nur die aktuelle Position des Ausschnitts innerhalb des Dokuments, sondern auch das Größenverhältnis des aktuellen Ausschnitts im Vergleich zum Ganzen. Ein solcher Bildlauf vermittelt also umfangreiche Informationen, die der Orientierung innerhalb des dargestellten Inhalts dienen. Scrollbars dienen bei reiner Mauseingabe nicht nur dazu, den Ausschnitt anzuzeigen, sondern auch dazu, ihn zu manipulieren. Die genaue Ausgestaltung hängt stark vom Betriebssystem ab. Allen gemein ist die Möglichkeit, die Position im Dokument durch Verschieben des Bildlauffeldes zu ändern. Zusätzliche Schaltflächen oder auch das Klicken in Bereiche auf dem Rollbalken bewirkt zudem das zeilen- oder seitenweise Scrollen.

Die verschwundene Scrollbar

Leider sind Scrollbars heute teils einer Mode und teils einem falschen Minimalismus zum Opfer gefallen. Zunächst sind sie auf Touch-Geräten wie Handys und Tablets verschwunden, später bei MacOS und inzwischen hat auch Microsoft bei Windows 10 nachgezogen und blendet Scrollbars unter bestimmten Bedingungen aus. Die Ausblendung ist insofern verständlich, als die Leiste als Eingabeelement für das Scrollen heute kaum noch benötigt wird. Verwendet man eine Maus, scrollt man mit dem Scrollrad, auch Trackpads bieten direkte Möglichkeiten zum Scrollen und bei Touch-Eingaben wird ohnehin durch Wischen auf dem Inhaltsbereich gescrollt. Ausladende Scrollbars, wie sie in der obigen Abbildung zu sehen sind, werden in diesen Fällen zwar nicht mehr unbedingt benötigt, doch rechtfertigt das nicht, sie gänzlich wegzulassen.

Dieses Beispiel illustriert, zu welchen Problemen das Fehlen einer Scrollbar führen kann. Es ist der Inhalt eines Ordners mit einer Reihe von Foliensätzen zu sehen. Beim Betrachten entsteht der Eindruck, dass diese Darstellung alle Icons anzeigt. Bestärkt wird man darin nicht zuletzt dadurch, dass es freien Raum gibt, was den Eindruck erweckt, dass die Anzeige größer ist als die Menge der anzuzeigenden Objekte. Lediglich die kleine Anzeige „7 Objekte“ unten in der Fußleiste des Fensters gibt einen Hinweis darauf, dass ein Objekt fehlt. Allerdings wird diese Statusleiste im Regelfall nicht angezeigt, sondern muss explizit aktiviert werden. Abgesehen davon gibt es keinen Hinweis darauf, dass es ein weiteres Objekt gibt und wie man es erreicht, denn die Scrollbar wird nur angezeigt, während man scrollt. Diese Implementierung verstößt gegen unsere Forderung nach Erschließbarkeit. Die Oberfläche wird durch das Weglassen der Scrollbar vielleicht schicker, in keinem Fall jedoch besser. Mit Übersichtlichkeit für die Ausblendung von Scrollbars zu argumentieren, wird übrigens schwierig, denn vor allem wenn man sie nur zur Positionsanzeige und nicht mehr als eigentliches Interaktionselement nutzt, brauchen die Scrollbars kaum Platz und können sehr unaufdringlich gestaltet werden.

Wenn das Ende kein Ende ist

Eine andere problematische Einrichtung, die die Funktion von Scrollbars stark beeinträchtigt, ist das dynamische Nachladen weiterer Inhalte, wie es häufig bei modernen Webanwendungen üblich ist. Wenn Sie beispielsweise in Facebook durch die Inhalte einer Seite scrollen und unten angekommen sind, lädt die Seite nach und wird nach unten hin verlängert. Die Scrollbar, die gerade noch bis nach unten gezogen wurde, springt unvermittelt wieder nach oben. Dadurch wird es schwerer bis unmöglich, mittels der Scrollbar einzuschätzen, welchen Ausschnitt man an welcher Position zu sehen bekommen wird. Auch die Orientierungsfunktion ist nicht mehr gegeben, denn am unteren Ende der Scrollbar ist nicht mehr das Ende, sondern nur das Ende des gerade geladenen Ausschnitts.

Der Vorteil bei Facebook ist, dass in der Regel viel weniger Daten übertragen werden müssen, denn bei biografisch geordneten Inhalten sind oft nur die aktuellen Inhalte, die oben stehen, von Interesse. Es gibt jedoch zu diesem Nachlademechanismus auch Alternativen, um die Datenmenge klein zu halten. Die einfachste ist, unten auf der Seite jeweils einen Link zu Folgeseiten anzubieten, das Scrollen also mit dem Blättern zu kombinieren, um das es im folgenden Abschnitt geht. Auch Nachladen ist grundsätzlich in Ordnung, könnte aber zum Beispiel durch Klicken auf einen Button am Ende geschehen. Mit dem automatischen Nachladen wird zwar dieser Klick gespart, dies geschieht jedoch auf Kosten der Orientierung.

Wenn Sie eine Software haben, bei der Inhalte erst hinzugeladen werden, wenn sie gebraucht werden, stößt die klassische Scrollbar an ihre Grenzen.

Blättern

Die Alternative zum Scrollen, vor allem bei den oft anzutreffenden eindimensionalen Ausdehnungen, ist das Blättern. Der Vorteil des Scrollings liegt vor allem in der Kontinuität – im Gegensatz zum Blättern wird der Inhalt weitergeschoben statt komplett ersetzt. Das ermöglicht auf modernen Desktop-Rechnern, Laptops und Touch-Geräten, bei denen per Wischen oder per Scrollrad gescrollt werden kann, eine sehr einfache Handhabung. Für das Blättern ist es im Gegensatz dazu in den meisten Fällen nötig, einen Verweis oder einen Button räumlich auszuwählen und anzuklicken. Es gibt dennoch Bedingungen, unter denen das Blättern besser ist als das Scrollen:

• Wenn die Anzahl der Elemente oder der Inhalt sehr groß ist: Das Scrollen über die komplette Menge verliert seine Vorteile, denn der jeweils aktuelle Ausschnitt wird im Vergleich zur Gesamtmenge sehr klein, die Anzeige ungenau und das manuelle Wählen des Ausschnitts durch das Positionieren des Rollfeldes nicht mehr handhabbar.
• Wenn die Anzahl der gleichzeitig zu ladenden Elemente verringert werden soll: Hierfür kann es inhaltliche, aber auch technische Gründe, wie Arbeitsspeicherbedarf oder die Übertragungszeit, geben. Gerade für die Fälle, in denen weiter hinten bzw. unten liegende Elemente selten betrachtet werden (zum Beispiel in der Facebook-Timeline) ist das Einteilen in Seiten sinnvoll.
• Wenn Eingabetechniken eingesetzt werden, die kein Scrollen unterstützen oder das Wissen über die Scroll-Technik nicht vorausgesetzt werden kann: Fahrkartenautomaten wären hier ein Beispiel.
• Wenn es möglich sein soll, einzelne Ausschnitte oder Positionen innerhalb des Inhalts oder der Objekte zu adressieren: Dies geht zwar grundsätzlich auch mit Scroll-Techniken, ist aber komplexer und von einer spezifischen Umsetzung abhängig. Bei der Verwendung von Seiten ist eine Adressierung leichter zu bewerkstelligen.
• Wenn einzelne Seiten mit semantischen Einheiten des Inhalts, wie zum Beispiel Handlungsschritte, Kapitel, Ereignisse oder Vergleichbares gekoppelt werden können: Die Verwendung von Seiten sorgt in diesem Fall für inhaltlich abgeschlossene Einheiten.

Für die Navigationselemente zum Blättern gelten ähnliche Anforderungen wie an Scrollbars. Sie sollten nicht nur Möglichkeiten bereithalten, die vorherige und die nachfolgende Seite zu erreichen, sondern auch anzeigen, auf welcher Seite man sich gerade befindet, und auch verdeutlichen, in welcher Relation die aktuelle Seite zum Ganzen steht.

Diese Seitenauswahl stammt aus der Bildplattform flickr. Das Navigationselement zeigt, dass die aktuelle Seite die Nummer 5 ist und erlaubt das Weiterschalten auf die direkt umgebenden Seiten 4 und 6. Darüber hinaus veranschaulicht sie auch die Relation zum Ganzen durch die Angabe der Gesamtseitenzahl und ermöglicht, wenn auch mit Einschränkungen, die direkte Anwahl von Seiten.

Navigation auf Strukturebene

Die oben beschriebenen Navigationstechniken erweitern die Bildschirmanzeige um Navigationselemente, mittels derer der Ausschnitt aus einem Objektarrangement oder einem großen Objektinhalt dargestellt und gewählt werden kann. Die Voraussetzung dafür ist, dass es einen solchen räumlich-grafisch darstellbaren Inhalt gibt. Beim schon mehrfach benutzten Beispiel eines längeren Textes ist das der Fall, denn dieser ist linear und wird räumlich dargestellt. Viele Navigationsprobleme sind jedoch anders gelagert. Denken Sie zum Beispiel an die Menge aller Funktionen, die eine Textverarbeitung bietet. Jede einzelne davon könnten Sie über eine Textfläche, einen Button oder ein Icon darstellen, aber die Gesamtheit dieser Funktionen hat keine natürliche Ordnung, die sich direkt auf räumliche Achsen abbilden ließe. Um in ihnen scrollen oder blättern zu können, müssen sie erst in eine darstellbare Anordnung gebracht werden. Man könnte zum Beispiel alle Funktionen mit einem Namen versehen und sie alphabetisch sortieren.

Eine solche Liste ist keine angemessene Struktur, da die alphabetische Distanz auf kein semantisches Kriterium abbildbar ist. Doch bleiben wir kurz bei dieser abwegigen Idee, denn sie verdeutlicht eine notwendige Voraussetzung, die erfüllt sein muss, um eine Nutzungsschnittstelle zur Navigation umsetzen zu können. Bei einer alphabetischen Liste auf dem Bildschirm handelt es sich um eine räumliche Darstellung eines linearen Index. Ein solcher Index ist die Grundlage für die Navigationstechniken, die wir im Folgenden besprechen wollen. Alphabetische Listen oder auch eine Sortierung nach Zeitpunkten sind für die meisten Anwendungen allerdings nur am Rande interessant, wenn es darum geht, die Funktionalität zu erschließen.

Die am häufigsten anzutreffende Indexart für die Navigation ist die zweidimensionale Struktur des Baums, denn sie gestattet das Bilden von Kategorien und Unterkategorien und ermöglicht dadurch die Realisierung von Menüs, Reitern und Pfaden.

Wenn Sie das Wort „Index“ im Zusammenhang mit dem Wort „Navigation“ hören, mag Ihnen vielleicht das Thema „Suche“ in den Sinn kommen. Um eine Suche geht es hier allerdings nicht. Wenn für eine Suche indiziert wird, ist damit nicht das Erstellen einer Struktur für die Inhalte gemeint, sondern das Erstellen eines Volltextindexes. Suchen ist zwar eine sehr praktische Funktion, sorgt jedoch nicht für die Erschließbarkeit einer Software und schafft auch keine Orientierung innerhalb der von ihr angebotenen Handlungsoptionen.

Damit ein Index die Navigation unterstützen kann, muss er unter Berücksichtigung vielfältiger Rahmenbedingungen und Forderungen zur Anzeige gebracht werden. Werden zum Beispiel alle Funktionen einer Textverarbeitung in Kategorien und Unterkategorien, also in einen Baum, eingeordnet, könnte man versuchen, den Baum vollständig darzustellen. Allerdings würde man nicht nur viel Platz verbrauchen, man käme auch nicht den Anwendungsanforderungen entgegen. Ein Menü, bei dem einzelne Ebenen bei Bedarf eingeblendet werden können, wäre an dieser Stelle die bessere Navigationstechnik.

Menüs

Menüs dienen der Darstellung eines hierarchischen Index, also eines Baums. Die Funktionen einer Software, aber auch Inhalte von Websites werden sehr häufig in Baumstrukturen organisiert und damit per Menü zugänglich gemacht. Wie ein solcher Baum konstruiert wird, also welche Elemente jeweils unter einem Oberbegriff zusammengefasst werden sollten, hängt von der Anwendung ab. Im Folgenden geht es uns stattdessen darum, wie das Menü ergonomisch dargestellt werden sollte. Die konkrete Gestaltung hängt von vielen Rahmenbedingungen ab, etwa, ob ein Menü häufig genutzt wird oder nicht und vor allem auch, wie viel Platz zur Verfügung steht und welche Eingabetechnik zum Einsatz kommt. Menüs können, wie der kurze historische Rückblick zeigt, sehr verschiedene Darstellungsformen annehmen.

In der Abbildung sehen Sie die klassische Darstellung eines Menüs. Die Menüpunkte sind textuell untereinander dargestellt und mit Zahlen versehen. Diese Zahlen dienen dazu, einen Menüpunkt anzuwählen. Wird ein Menüpunkt ausgewählt, so wird entweder die direkt damit verbundene Funktion ausgeführt oder es öffnet sich ein Untermenü, das wiederum den Großteil des Bildschirms einnimmt, sodass die vorherige Menüebene nicht mehr zu sehen ist. Mit dem Aufkommen grafischer Nutzungsoberflächen mit Zeigegeräten ist diese Form des Menüs nahezu vollständig von den Personal Computern verschwunden. Man findet sie allerdings noch häufig in Einstellungsbereichen von Fernsehern und in Geräten mit nur kleinen Anzeigen. Zu letzteren gehören interessanterweise auch Handys. Die Einstellungs-App von iOS auf einem iPhone funktioniert genau auf die oben beschriebene Weise. Es ist stets nur eine Menüebene zu sehen, ein Klick auf ein Element wechselt in eine andere Menüebene und ein einzeln herausgestelltes Eingabeelement wird dazu verwendet, wieder auf die übergeordnete Ebene zurückzuwechseln. Der einzige Unterschied zwischen dieser Art des Menüs und dem oben abgebildeten klassischen Menü aus der Zeit der textbasierten Computersysteme ist die Eingabemodalität. Statt Zahlen einzugeben wird nun auf den entsprechenden Menüeintrag getippt.

Menüs dieser Art haben den großen Nachteil, dass bei jedem Wechsel der Menüebene der räumliche Kontext verloren geht, denn eine Menüebene ersetzt vollständig die vorherige, sodass man die Ebene der parallelen Untermenüs nicht mehr im Blick hat. In solchen Menüs etwas zu finden oder sie zu durchschauen, ist nicht einfach. Man kann sich leicht in ihnen „verlaufen“. Nach Möglichkeit sollten derartige Menüs vermieden werden. Nur in Ausnahmefällen wie dem kleinen Bildschirm eines Smartphones sind sie gerechtfertigt.

Wie Menüs dargestellt werden, wie viel von ihnen dauerhaft zu sehen ist und inwiefern mit Aufdecken und Überlagern gearbeitet werden kann, ist Gegenstand vieler Forderungen an die Ergonomie. Die Forderung nach Erschließbarkeit würde darauf abzielen, möglichst viele Elemente und Ebenen dauerhaft darzustellen. Platzbeschränkungen und die Forderungen nach Übersichtlichkeit, Erkennbarkeit und Handhabbarkeit sprechen allerdings dagegen, dies zu extensiv auszugestalten und eher darauf zu setzen, die Menüebenen nacheinander aufzurufen. Man erkauft sich allerdings die gewonnene Übersichtlichkeit durch zusätzliche Eingabeschritte mit Maus oder Tastatur, opfert also bis zu einem bestimmten Grad die Eingabeminimalität.

Erste Menüebene möglichst sichtbar machen

Mit dem WIMP-Paradigma (Windows, Icons, Menus, Pointer) der 1980er Jahre ist es üblich geworden, die oberste Ebene des Hauptmenüs einer Anwendung dauerhaft anzuzeigen. Sowohl Apples Betriebssysteme als auch Microsofts Windows sowie die meisten grafischen Nutzungsschnittstellen von Linux und Unix halten es auf diese Weise.

Hier sieht man dies am Beispiel von LibreOffice Writer. Die erste Ebene des Anwendungsmenüs mit den Unterpunkten „Datei“, „Bearbeiten“, „Ansicht“ usw. ist dauerhaft sicht- und jederzeit anwählbar. Eine solche Darstellung des Menüs würde auf einem Tablet mit Touch-Eingabe nicht gut funktionieren. Die Elemente müssten größer sein, um per Touch-Eingabe gut und sicher getroffen werden zu können. Dieser Platz geht jedoch zulasten des Anwendungsinhalts. Spätestens auf einem kleinen Smartphone-Bildschirm gibt es nicht mehr genug Platz, um neben dem Anwendungsinhalt auch noch das Menü auf diese Weise anzuzeigen. Im Falle einer solchen Platzbeschränkung ist es sinnvoll, auch die oberste Menüebene erst auf explizite Anforderung anzuzeigen. Heute geschieht das meist durch den Klick auf ein sogenanntes „Burger-Icon“.

Die Tendenz, Nutzungsschnittstellen, die für eine Geräteklasse optimiert worden sind, auf andere Arten von Geräten zu übertragen, ohne die Designkonflikte neu auszutarieren, führt heutzutage leider oft dazu, dass generell auf die Menüleiste verzichtet wird, auch wenn genügend Platz vorhanden ist und die Eingabeform per Maus und Tastatur genutzt wird. Die Ausnahme ist hier Apple, wo die Menüleiste so stark in die Nutzungsschnittstelle des Betriebssystems MacOS integriert ist, dass auch Software wie Google Chrome, Firefox und Microsoft Word, die unter Windows ihr klassisches Menü haben, sich dem angepasst haben.

Keine fixe Grenze für die Anzahl von Menüelementen

In manchen Hinweisen zur Gestaltung grafischer Nutzungsoberflächen werden Angaben darüber gemacht, wie viele Elemente ein Menü bzw. ein Untermenü enthalten sollte. Manche dieser Hinweise sind sinnvoll, viele sind es allerdings nicht.

• Für Menüs, die per Maus oder Tastatur gesteuert werden, sollte man vermeiden, dass innerhalb eines Menüs gescrollt oder geblättert werden muss. Dies ist zwar grundsätzlich bei jedem Menü anzustreben, wird aber zum Beispiel auf Handys mit kleinem Bildschirm und aufgrund der nötigen Touch-Eingabe oft nicht sicherzustellen sein.
• Eine zu tiefe Menüstruktur hat den Nachteil, dass zum Erreichen eines Elements sehr viele Klicks, Berührungen oder Tastatureingaben nötig sind und dass es keine Möglichkeit mehr gibt, ein Element direkt zu entdecken, da man in diesem Fall einen recht komplexen Pfad kennen muss. Eine Menütiefe größer als 3 ist unüblich und sollte aus den oben genannten Gründen auch vermieden werden.

Kritisch sind Angaben zur maximalen Elementanzahl innerhalb von Menüs. Häufig wird die Zahl 7(+-2), also 5 bis 9, als das Maximum von Elementen innerhalb einer Menüebene genannt. Diese „Magical Number 7“ ist von George Miller 1956 experimentell ermittelt worden⁵. Allerdings hat Miller in den 1950ern nichts über die Gestaltung von Menüs in grafischen Nutzungsschnittstellen gesagt. Schlimmer noch: Seine Ergebnisse lassen sich auch nicht darauf anwenden. Millers Experimente sollten zeigen, wie gut bzw. eher wie schlecht das Erinnerungsvermögen von Menschen ist. Um semantische Zusammenhänge und damit individuell nutzbare Hinweise auszuschließen, wurden im Experiment nur Gegenstände zusammen gezeigt, die möglichst keinen gemeinsamen Handlungskontext haben. Nach einer Ablenkungsaktivität wurden die Probanden gefragt, an welche Gegenstände sie sich erinnern können. Es zeigte sich, dass die Probanden sich jeweils nur an fünf bis neun Gegenstände erinnern konnten. Aufgrund dieses Befundes ist die „Magical Number 7“ auch als Richtwert für die Anzahl von Menüelementen entstanden. Diese Empfehlung hat es in etliche Ergonomie-Bücher und Styleguides geschafft.

Betrachtet man das von Miller konzipierte Experiment und sein Erkenntnisinteresse genauer, fällt auf, dass eine maximale Anzahl von Menüelementen aus seinen Untersuchungen nicht abgeleitet werden kann. Bei Millers Experiment hatten die Gegenstände, die gezeigt wurden, nichts miteinander zu tun. Das war auch nötig, weil das Erinnerungsvermögen und nicht die Assoziationsfähigkeit getestet werden sollte. Bei gut gestalteten hierarchischen Menüs hingegen haben die einzelnen Elemente sehr wohl etwas miteinander zu tun. In Millers Experiment wurden zudem die Gegenstände nur kurz gezeigt. Die Probanden sollten sich später ohne weiteren visuellen Hinweis an sie erinnern. Das Charakteristikum eines Menüs ist dagegen, dass es bis zur Auswahl eines Elements kontinuierlich am Bildschirm zu sehen ist. Man muss sich an die Elemente nicht frei erinnern, sondern unter dem Angebot eine Auswahl treffen. Die Empfehlung, die Anzahl von Menüpunkten auf fünf bis neun Elemente zu begrenzen, kann somit nicht aus diesem Experiment abgeleitet werden und könnte sich als ergonomisch nachteilig erweisen, wenn dadurch semantische Zusammenhänge unnötig auseinandergerissen werden.

Reiter

Menüs sind eine Navigationstechnik für einen hierarchischen Index. Nicht immer ist es jedoch nötig und sinnvoll, eine hierarchische Struktur aufzustellen. In vielen Fällen reicht es, Inhalts- und Funktionsbereiche lediglich zu kategorisieren. Würde man stattdessen ein Menü verwenden, enthielte es nur eine Ebene. Jeder der Punkte würde direkt zu einem Funktionsaufruf oder zu einem Inhalt führen. In den Fällen, in denen ein Aufruf eines Elements dieses Menüs dazu führen würde, dass jeweils verschiedene Bildschirmseiten angezeigt werden, das Menü also nur zur Auswahl dieser Bildschirmseiten verwendet wird, kann man das Menü auch durch eine Reiternavigation ersetzen.

Die Abbildung zeigt eine Reiternavigation innerhalb der Anzeigeeinstellungen von Windows XP. Die Kategorien „Designs“, „Desktop“, „Bildschirmschoner“, „Darstellung“ und „Einstellungen“ sind dauerhaft verfügbar. Ein Klick darauf wechselt den unten dargestellten Inhalt. Reiter sind mit der Verbreitung von Windows 95 vor allem bei Einstelldialogen sehr beliebt geworden. Gerade in diesem Bereich nimmt ihre Verwendung aber ab. Dagegen haben sie als Alternative zur Darstellung mehrerer Fenster in einer Vielzahl von Anwendungen, angefangen bei Webbrowsern über Dateimanager bis hin zu Grafikbearbeitungsprogrammen, weite Verbreitung gefunden.

Die Reiternavigation ist eine geschickte Verbindung eines Menüs zur Inhaltsauswahl mit der Möglichkeit, die aktuelle Auswahl direkt darzustellen. Der Clou bei der Darstellung als Reiter liegt in der optischen Einheit der Auswahlelemente für den Reiter und seinem Inhalt. Dazu wird die Illusion erzeugt, dass sich alle auszuwählenden Inhalte auf Registerkarten befinden, unter denen eine Karte ausgewählt werden kann. Die ausgewählte Karte wird jeweils als die zuoberst liegende dargestellt.

Hier ist dargestellt, wie Reiter unter Windows 10 aussehen. Die optische Gestaltung lässt jedoch stark zu wünschen übrig. Die nicht aktiven Reiter sind, im Gegensatz zur Darstellung unter Windows XP und unter Windows 7, nur unzureichend als im Hintergrund liegend abgesetzt, weshalb der aktive Reiter schlecht zu erkennen ist.

In diesem Beispiel des Browers Edge zeigt Microsoft, wie man es besser machen kann. Die nicht ausgewählten, also die „hinten liegenden“ Reiter sind im Vergleich zum hellen, aktiven Reiter optisch abgedunkelt. Ein Schlagschatten verstärkt die optische Absetzung (siehe hierzu unsere Ausführungen im Kapitel Bildschirmobjekte).

Eine andere Form von Reitern stellen Microsofts Ribbons dar, die Microsoft als Weiterentwicklung der Menüleisten verwendet. Anstelle der Anzeige einer Vielzahl von Leisten mit kleinen Icons ohne Beschriftung hat Microsoft sich vor einigen Jahren dazu entschlossen, die Elemente fortan in einer Reihe von Bändern, den sogenannten Ribbons, zugänglich zu machen. Oben abgebildet ist Microsofts Ribbon-Design aus dem Jahr 2016. Der aktuell ausgewählte Ribbon setzt sich sehr gut von den gerade nicht aktiven ab. Es bleibt das Geheimnis von Microsoft, warum die 2019er-Version der gleichen Ribbons (unten) erheblich schlechter gestaltet wurde. Der aktuell ausgewählte Ribbon ist nun durch eine Unterstreichung ausgezeichnet. Der räumliche Effekt der Reiterdarstellung ist dahin.

Auch die Reiternavigation hat ihre Grenzen. Die Abbildung zeigt ein altes Beispiel von Reitern in Microsoft Word unter Windows 95. Der jeweils aktive Karteireiter ist schlecht zu erkennen. Er unterscheidet sich von den anderen Reitern nur durch sehr wenige Merkmale: Der Reiter ist genau ein Pixel höher als die anderen und im unteren Bereich fehlt die Begrenzung. Bedeutend problematischer ist aber die Anzahl der Reiter, die nicht mehr in eine Zeile passen. Dies hat zur Folge, dass sich die Position der Karteireiter mit der Selektion ändert, weil die komplette Reihe, in der sich der ausgewählte Reiter befindet, nach vorne wandert. Das erzeugt ein Kontinuitätsproblem, das auf jeden Fall vermieden werden sollte.

Pfade und Brotkrumen

Die vorgestellten Reiter erfüllen drei wichtige Funktionen: Sie zeigen die zur Auswahl stehenden Optionen, verdeutlichen die aktuelle Auswahl und bieten zudem die Möglichkeit, diese Auswahl zu verändern. Leider eignen sich Reiter nur für flache Strukturen. Ein Navigationselement, das die gleichen guten Darstellungsmöglichkeiten und Manipulationsoperationen böte wie Reiter, existiert für hierarchische Strukturen leider nicht, denn es ist meist nicht möglich, alle Hierarchieebenen gleichzeitig übersichtlich darzustellen. Jedoch sind die Darstellung der aktuellen Position innerhalb der Hierarchie und der direkte Zugriff auf höhere Hierarchieebenen und, wie wir sehen werden, teils auch auf parallele Ebenen größtenteils ohne Probleme möglich.

Die aktuelle Position innerhalb einer hierarchischen Struktur lässt sich analog zu Dateipfaden als „Pfad“ beschreiben. Für die Anzeige eines Pfades hat sich vor allem im Webdesign der Begriff „Brotkrumen-Navigation“ bzw. „Breadcrumb Navigation“ durchgesetzt. Der Begriff nimmt Bezug auf das Märchen „Hänsel und Gretel“ und ist im Gegensatz zum Märchen insofern erfolgreich, als es keine Instanz gibt, die die Brotkrumen auffrisst.

Hier sehen sie eine Breadcrumb-Navigation in einer universitären Lernplattform. Der Pfad wird innerhalb der hierarchischen Struktur der Plattform verdeutlicht. Der Begriff „Breadcrumb“ hat sich auch für diese Lösung durchgesetzt, obwohl die Analogie nicht passt, denn die dargestellte Abfolge zeigt die Einordnung in die Hierarchie, nicht etwa den tatsächlich zurückgelegten Weg, über den man zur aktuellen Position gekommen ist. Dies wird durch Unterscheidung von ortsbezogenen und verlaufsbezogenen Breadcrumbs verdeutlicht. Letztere sind vor allem bei der Navigation durch Hypertextstrukturen interessant.

Zugriff auf höhere und parallele Hierarchieebenen

Breadcrumbs zeigen nicht nur den Pfad zur aktuellen Position, sondern erlauben es auch, höhere Ebenen der Hierarchie direkt durch Anklicken anzuspringen. Je nach Anwendung kann man auch weitergehen und die höheren Ebenen nicht nur als anklickbaren Text ausgestalten, sondern als manipulierbares Menü.

Im Explorer von Windows (hier zu sehen ist die Version in Windows 10), sind die Elemente des angezeigten Pfades nicht nur Abkürzungen, um diese Ebene wieder zu erreichen, sondern Objekte. Dadurch ist es auf einfache Weise möglich, ein Objekt in diese Ebene zu verschieben oder zu kopieren, indem es auf den entsprechenden Teil des Pfades verschoben wird. Im Finder von MacOS steht eine ähnliche Funktion zur Verfügung, wenn die sogenannte „Pfadleiste“ eingeblendet wird.

Mit der Einführung von Windows 7 fügte Microsoft der Pfadleiste des Explorers eine interessante Funktion hinzu, die es ermöglicht, Zugriff auf die Paralleläste der Elemente innerhalb des Pfades zu erhalten. Sie ermöglicht einen bequemen und schnellen Zugriff auf viele Hierarchieebenen, ohne dass dafür viele Klicks benötigt werden.

Modusgestaltung

Im Themenbereich Orientierung haben wir den Konflikt behandelt, dass einerseits die Menge der ergonomisch darstellbaren und damit direkt zugänglichen Elemente zu beschränken ist, dabei jedoch andererseits die Gesamtheit erschließbar zu gestalten ist. Damit stellt sich grundsätzlich die Frage, welche Funktionen und Objektoperationen sich in unmittelbarem Zugriff befinden und ohne Umweg über eine zusätzliche Navigation beispielsweise in Form eines Menüs erreichbar sein sollen. Oft ist es nicht einfach, diese Frage pauschal zu beantworten, denn je nachdem, welche individuellen Arbeitsstile zu erwarten, welche spezifischen Aufgabe zu erledigen sind oder auch in welcher Phase eines Arbeitsprozesses man sich gerade befindet, sind es andere Bereiche der Funktionalität und der Inhalte, die direkt verfügbar sein sollten. Man kann sich das gut an einer Präsentations-Software wie PowerPoint verdeutlichen:

• Ist es das Ziel, eine gleichmäßige Gestaltung von Folien sicherzustellen, muss ein Satz Vorlagen (in PowerPoint „Folienmaster“ genannt) erzeugt oder bearbeitet werden. Um das zu bewerkstelligen, benötigt man Zugriff auf die Funktionen, die das Design der Folienvorlagen betreffen. Während der Erstellung der Vorlagen sind andere Funktionen der Software von Interesse, wie das Eingeben von Inhalten, das Einfügen von Objekten oder das Anlegen neuer Folien.
• Während Folien mit Inhalt gefüllt werden, sind dagegen die Funktionen zur Veränderung der Vorlagen nicht interessant; stattdessen werden Funktionen zum Anlegen von Objekten und neuen Folien sowie zur Eingabe von Text und zum Einfügen von Bildern benötigt.
• Zum Zeitpunkt, an dem die Präsentation vorgeführt werden soll, besteht dagegen kein Bedarf an Funktionalität zum Einfügen neuer Objekte oder zur Änderung des Designs. Auch sollte es nicht mehr möglich sein, die Objekte zu verschieben oder zu löschen, denn das könnte schnell versehentlich passieren. Stattdessen werden andere Funktionalitäten wie das Erstellen eines Audiomitschnitts, das Einblenden eines Zeigers in die Präsentation und vor allem die Steuerung der Folienpräsentation besonders wichtig.

Im Laufe der „Lebensgeschichte“ einer Folienpräsentation müssen üblicherweise all diese Aufgaben irgendwann durchgeführt werden, was entsprechend den Zugriff auf alle damit verbundenen Operationen und Inhalte erfordert. Im Normalfall werden jedoch die drei beschriebenen Arbeitsphasen nicht zur gleichen Zeit genutzt. Entsprechend sind bei PowerPoint die Funktionen auch aufgeteilt. Eine solche Aufteilung in Funktionen, in unserem Beispiel solche zur Vorlagenbearbeitung, zur Folienbearbeitung und zur Präsentation, nennen wir „Modi“. Jeder Modus hat seine eigene Nutzungsoberfläche, die für diesen Modus angepasst ist. Die Funktionen eines Modus sind direkt erreichbar, die für einen anderen Modus stehen nicht unmittelbar zur Verfügung. Um sie zu erreichen, muss der Modus gewechselt werden. Gut gestaltete Modi erhöhen die ergonomische Qualität einer Software, denn sie können dafür sorgen, dass weniger Elemente gleichzeitig auf dem Bildschirm angezeigt werden müssen (Übersichtlichkeit) und dass die Operationen, die ausgeführt werden müssen, mit nur wenig Zusatzaufwand erreichbar sind (Eingabeminimalität). Letztlich hilft dies, Fehleingaben zu vermeiden. Gestaltet man die Modi jedoch schlecht, verursachen sie mehr Schaden als Nutzen und können zur Desorientierung beitragen.

Studiert man ältere Lehrbücher und Artikel zu softwareergonomischen Fragen, fällt auf, dass der Begriff Modus in diesen oft eine sehr wichtige Rolle einnimmt. Des Weiteren fällt auf, dass der Begriff unterschiedlich verstanden und verwendet wird. Larry Tesler beispielsweise hat in den 1980er Jahren das Schlagwort der „modusfreien Interaktion“ etabliert und dazu aufgefordert, Modi grundsätzlich zu vermeiden. Mit Blick auf die seinerzeit vorherrschenden Technik beklagt er zum Beispiel, dass Textverarbeitungssysteme es nicht erlaubten, während des Betriebes die auf einem Datenträger gespeicherten Dokumente zu erfassen, was beim Laden und Speichern von Dateien zum Nachteil gereichte und gelegentlich sogar ein zwischenzeitliches Verlassen der Textverarbeitungsumgebung nach sich zog. Derartige Modi, gegen die er sich zur damaligen Zeit zu Recht gewandt hatte, haben sich allerdings mit der Einführung von Multitasking und Fenstertechnik größtenteils erledigt. Modi, die sich aus der Aufgabe begründen, hat er dagegen nicht im Blick gehabt.

Modale Dialoge

Wenn von Modi und ihrer Vermeidung die Rede ist, richtet sich der Fokus oft auf den Teilaspekt der sogenannten „modalen Dialoge“ oder „modalen Fenster“. Grafische Nutzungsoberflächen bieten in der Regel die Wahlfreiheit, ein beliebiges Fenster anzuklicken und in diesem Aktionen durchzuführen. Es gibt jedoch Situationen, in denen zunächst eine Aktion in einem Fenster abgeschlossen werden muss, bevor im anderen weitergearbeitet werden kann. Das Fenster ist „modal“. Ein typischer Fall ist das Speichern einer Datei. Wenn „Speichern unter“ ausgewählt worden ist, öffnet sich ein Fenster, in dem man den Speicherort und den Dateinamen festlegen kann. Während dieses Fenster geöffnet ist, ist es nicht möglich, das Dokument weiter zu bearbeiten. Das Fenster lässt sich nicht wechseln. Erst wenn der Prozess im Fenster abgeschlossen ist, also entweder die Datei tatsächlich gespeichert oder die Aktion abgebrochen worden ist, kann der Inhalt weiterbearbeitet werden.

Das Anzeigen eines solchen modalen Fensters verkörpert immer Sequenzialität. Das ist unkritisch, wenn diese Sequenzialität so gewollt oder der Mehraufwand gering ist. Oft ist das Verwenden eines modalen Fensters sehr sinnvoll, doch gerade das Beispiel des Speichern-Fensters zeigt, dass diese Sequenzialität nachteilig sein kann. Nehmen wir einmal an, an einer bestimmten Stelle im Text steht eine Zeichenfolge, die als Dateiname ausgewählt werden soll. Wenn die Wahl des Dateinamens in einem modalen Fenster erfolgt, erzwingt das zum Einhalten einer bestimmten Reihenfolge. Man muss zuerst an die entsprechende Stelle im Text wechseln und die Zeichenfolge kopieren und kann erst danach die Speichern-Funktion aufrufen. Bei der entgegengesetzten Handlungssequenz steht das modale Fenster einer erfolgreichen Ausführung entgegen. Deshalb sind modale Fenster mit Bedacht einzusetzen, denn sie können leicht für erzwungene Sequenzialitäten sorgen, die Mehreingaben verursachen, und die freie Wahl des Wegs zur Erledigung der Aufgabe einschränken.

Eine Software, die ein modales Fenster anzeigt, befindet sich in einem Modus. Doch unser Verständnis von einem Modus geht über dieses doch sehr begrenzte Phänomen hinaus. Keiner der oben erläuterten Phasen einer Präsentationssoftware basiert etwa auf modalen Dialogen.

Modi und Modusprobleme

Für unsere nachfolgende Argumentation richten wir uns an folgender Charakterisierung für Modi aus:

• Innerhalb eines Modus steht ein bestimmter Satz von Funktionen und Objektoperationen zur Verfügung, der sich von denen in einem anderen Modus zur Verfügung stehenden Funktionen unterscheidet.
• In welchem Modus sich ein System befindet, hängt von einem Zustand der Nutzungsoberfläche ab. Es gibt also durch die Änderung dieses Zustands die Möglichkeit, einen Modus zu betreten und zu verlassen bzw. zwischen verschiedenen Modi umzuschalten.
• Die gleichen Eingaben (sowohl Tastatureingaben als auch räumliche Manipulationen oder Gesten) haben innerhalb verschiedener Modi verschiedene Konsequenzen.

Diese Charakterisierung von Modi kann mehr Situationen umfassen als die, die man intuitiv Modus nennen würde. Zum Beispiel ist, der Definition entsprechend, ein Programm, in dem gerade ein Öffnen-Dialog angezeigt wird, in einem anderen Modus als das gleiche Programm bei nicht geöffnetem Öffnen-Dialog. Ob man diesen Unterschied im Programmzustand typischerweise als Modus bezeichnen würde, ist fraglich. Entscheidend ist letztlich weniger die Frage, wann wer etwas als Modus bezeichnet, sondern wann Modi problematisch sein können.

In seinem Buch „The Humane Interface“ aus dem Jahr 2000 führt Jef Raskin den Begriff „modal“ ein. Das von ihm verwendete Wort „modal“ definiert nicht, was ein Modus ist, sondern als „modal“ bezeichnet Raskin eine Nutzungsschnittstelle nur in den Fällen, in denen es bei der Nutzung aufgrund der Modushaftigkeit der Schnittstelle auch zu einem Nutzungsproblem kommt. Diesem Ansatz, mit Hilfe des Begriffs „modal“ einen Modus nur dann als Modus zu bezeichnen, wenn er problematisch ist, können wir nicht folgen. Aber seinen Definitionsvorschlag können wir gestalterisch nutzen, indem wir uns die Bedingungen ansehen, unter denen es zu einem Modusproblem kommt. Wir definieren also in Anlehnung an Raskin:

Ein Modusproblem liegt vor, wenn

• die Reaktion des Interfaces auf eine Eingabe von einem Systemzustand abhängt,
• dieser Zustand des Systems aber zum Zeitpunkt der Eingabe nicht Gegenstand der Aufmerksamkeit ist.

Nicht jeder Modus verursacht also ein Modusproblem. Beispielsweise bewirkt die Eingabe von „=5+5“ in eine Textverarbeitung etwas anderes als bei einer Tabellenkalkulation. Unserer allgemeinen Charakterisierung folgend könnte man Textverarbeitung und Tabellenkalkulation als zwei Modi verstehen, wenn man es darauf anlegt. Es entsteht aber kein Modusproblem, denn durch die jeweilige Bildschirmgestaltung ist dies in der Regel offensichtlich. Auch zwischen dem Wiedergabemodus einer Präsentationssoftware und dem Folienbearbeitungsmodus besteht kein Modusproblem, denn der Unterschied zwischen den beiden Modi ist ebenfalls offensichtlich.

Andere Modi können ein Modusproblem verursachen. Oben sehen Sie das Präsentationsprogramm Keynote von Apple in zwei verschiedenen Modi. Die Eingabe „Drücken der Nach-unten-Taste“ bewirkt im linken Fall einen Wechsel auf die nächste Folie, im rechten Fall das Verschieben des Texteingabecursors innerhalb des Folientextes um eine Zeile nach unten. Problematisch ist, dass auf den ersten Blick kein Unterschied zwischen den Abbildungen erkennbar ist. Die beiden Modi werden zwar optisch angezeigt, die Unterschiede sind aber sehr subtil. Man muss genau hinsehen, um auf der rechten Abbildung eine dünne Umrahmung um den Folientext und den Eingabecursor zu sehen. Hinzu kommt, dass die markante Hinterlegung der aktiven Folie auf der linken Seite zur Fehleinschätzung führen kann, dass hier auch im rechten Fall der Eingabefokus läge.

Wir werden uns gleich einige weitere Beispiele für Modi ansehen, deren Gestaltung zu Modusproblemen führen kann. Lassen Sie uns aber zunächst einmal überlegen, welche Strategien es zur Vermeidung von Modusproblemen geben kann. Dies geht durch eine logische Umformung der obigen Definition des Modusproblems:

Ein Modusproblem kann nicht vorliegen, wenn

• die Reaktion der Nutzungsschnittstelle auf eine Eingabe unabhängig vom aktuellen Systemzustand ist, oder
• falls die Eingabe abhängig vom Systemzustand ist, aber dieser Systemzustand so offensichtlich ist, dass er bewusst wahrgenommen wird.

Beide Punkte sind für uns Ansatzpunkte, Modusprobleme zu vermeiden. Der erste Punkt bedeutet in letzter Konsequenz, einen Modus abzuschaffen oder zumindest abzuschwächen, denn wenn die gleiche Eingabe das gleiche bewirkt, handelt es sich zumindest bezüglich dieser Eingabe nicht mehr um einen Modus. Wenn es zum Beispiel bezüglich der Reaktion auf die Entfernen-Taste keinen Unterschied macht, ob ein Bild gerade im Vollbild angezeigt oder als markiertes Vorschaubild dargestellt wird, folglich in beiden Fällen das aktuelle Bild gelöscht wird und die Anzeige bzw. die Markierung auf das nächste Bild wechselt, dann liegt bezüglich dieser Eingabe kein Unterschied vor. Es kann also auch nicht zu Problemen kommen. Interne Konsistenz sorgt in diesem Fall dafür, dass es nicht zu einem Modusproblem kommt.

Der zweite Punkt ist ein wenig komplexer, denn ob ein bestimmter Systemzustand oder auch die Änderung dieses Zustands bewusst wahrgenommen werden, ist sehr situativ und kann während der Entwicklung nicht verlässlich ermittelt werden. Unabhängig davon gibt es jedoch gestalterische Ansätze, um Modi möglichst prägnant zu gestalten. Wir haben das schon bei den Forderungen aus dem Kapitel Bildschirmobjekte thematisiert. Ist der sichtbare Unterschied wie im obigen Beispiel zu subtil, ist die Wahrscheinlichkeit, dass er nicht wahrgenommen wird, hoch. Bei Übergängen von einem Zustand zum anderen kommt zusätzlich die Forderung nach Kontinuität ins Spiel, denn ihre Einhaltung verringert die Wahrscheinlichkeit, dass sich ein Nutzungsschnittstellen-Zustand unbemerkt ändert.

Problematische Modi und ihre Auflösung

Wir schauen uns im Folgenden einige Beispiele für problematische Modi aus verschiedenen Bereichen an. Diese Aufstellung kann nicht vollständig sein. Sie erhebt nicht einmal den Anspruch, alle möglichen Modi zu umfassen, denn diese können in ihrer Erscheinung sehr unterschiedlich sein.

Überflüssige Modi: Caps-Lock

Wir beginnen mit einer Art Fossil der Tastatureingabe, das sich über die Jahrzehnte erhalten hat und seitdem immer wieder für Probleme sorgt. Die Rede ist von der Feststelltaste, engl. „Caps-Lock“. Sie sorgt dafür, dass eingegebene Buchstaben als Majuskeln geschrieben werden. Es gibt also zwei Modi der Tastatur, einen festgestellten Modus und einen „normalen“ Modus, bei dem Buchstaben nur bei gleichzeitigem Drücken der SHIFT-Taste als Majuskel geschrieben werden. Die Aktivierung von Caps-Lock wird oft zum Modusproblem, denn es kann leicht einmal passieren, dass beim Drücken auf das A, die Tabulator- oder die SHIFT-Taste der Modus versehentlich gewechselt wird. Ein Moduswechsel ist leicht zu übersehen, wenn man nicht zufällig an der Stelle auf die Tastatur schaut, wo der Modus angezeigt wird (häufig durch das Aufleuchten einer kleinen Leuchtdiode). Auf dem Bildschirm wird der Caps-Lock-Modus dagegen nicht angezeigt.

Diesen Modus könnte man heutzutage vermeiden, denn für ein Feststellen gibt es auf heutigen Tastaturen außer bei körperlichen Einschränkungen keinen Anlass. Es handelt sich um ein Überbleibsel aus der Zeit mechanischer Schreibmaschinen. Erstaunlich ist jedoch, dass auf Laptop-Tastaturen, bei denen man einzelne Tasten aus Platzgründen geopfert hat, gerade diese Taste erhalten blieb.

Vermeidbare Modi: Einfügen und Überschreiben

Auch der zweite Fall ist einer, den die Zeit inzwischen überholt hat, der aber heute noch für Probleme sorgen kann. Mit dem Aufkommen von Screen-Editoren, also Editoren, bei denen ein Text am Bildschirm angezeigt wird und in dem ein Cursor positioniert werden kann, stellt sich die Frage, was passiert, wenn ein Cursor an einer Stelle am Bildschirm steht und eine Eingabe erfolgt. Wird diese eingefügt und der Rest nach hinten verschoben oder wird der bestehende Text ab dieser Position mit der Eingabe überschrieben? Je nach Situation und Aufgabe kann mal das eine, mal das andere sinnvoll sein. Aus diesem Grund haben Texteditoren lange Zeit über zwei verschiedene Eingabemodi verfügt, einen Einfügen- und einen Überschreiben-Modus.

In Windows können diese beiden Modi noch heute genutzt werden, allerdings werden sie von zunehmend weniger Programmen unterstützt bzw. unterschieden. Beim aktuellen Windows 10 funktioniert es zum Beispiel mit dem systemeigenen WordPad⁶. Man kann WordPad öffnen und schreiben „Dies ist ein Text“. Nun positioniert man den Mauszeiger vor dem Text, drückt auf die „Einfügen“-Taste (auf vielen Tastaturen ist sie mit „Einfg“ beschriftet und befindet sich rechts neben der Backspace-Taste) und schreibt „Unsinn“. Wie Sie sehen, wird jetzt nicht mehr eingefügt, sondern überschrieben. Das Resultat ist „Dies ist ein Unsinn“. Ein weiteres Tippen auf „Einfügen“ wechselt den Modus wieder zurück. Nun wird wieder eingefügt. Wenn Sie den Text vor „Unsinn“ platzieren und „großer“ eintippen, wird das Wort „Unsinn“ wieder, wie Sie es gewohnt sind, nach rechts verschoben.

Bei der beschriebenen Nutzung von WordPad liegt ein Modusproblem vor. Die gleiche Eingabe führt jeweils zu einem unterschiedlichen Resultat und es gibt keinen Hinweis auf den jeweiligen Modus. Dasselbe gilt auch für LibreOffice. Zwar wird in der Fußzeile „Überschreiben“ angezeigt, doch ist die Wahrscheinlichkeit groß, dass der Aufmerksamkeitsfokus auf dem Text liegt und damit die außerhalb dieses Fokus gelegene Anzeige des Moduswechsels übersehen wird.

Die beiden Eingabemodi sind dadurch überflüssig geworden, dass man sie durch eine einzige Eingabe-Interpretation ersetzt hat. Die ursprünglich gebräuchlichen Modi „Einfügen“ und „Überschreiben“ wurden auf den „Ersetzen“-Modus reduziert. Jede Eingabe ersetzt die gerade gültige Selektion. Ist zuvor nichts explizit selektiert worden, gilt der Zwischenraum, in dem sich der Cursor befindet, als selektiert und wird somit überschrieben.

Schlecht erkennbare Modi – „vi“

Geradezu der Inbegriff einer Software mit vielen Modi bei einer aktuellen und viel genutzten Software ist der Unix-Editor „vi“.

Diese Abbildung zeigt die Modi des „vi“. Nehmen wir an, „vi“ ist von der Kommandozeile aus mit vi test.txt aufgerufen worden. Der Editor öffnet sich im Befehlsmodus. Man sieht zwar den Text der Textdatei, kann aber nicht in diesen hineinschreiben, wohl aber den Cursor bewegen. Zum Schreiben muss man in den Einfügemodus wechseln. Dies geschieht durch die Eingabe von i´, I´, a´, A´, o´ oder O´. Diese Alternativen unterscheiden sich nur darin, dass die Eingabe an der Stelle des Cursors, am Anfang oder am Ende der aktuellen Zeile oder aber in einer neuen Zeile darüber oder darunter einsetzt. Nach Tätigung einer dieser Eingaben befindet man sich im Eingabemodus, der durch das Betätigen der ESC-Taste wieder beendet wird. Der Befehlsmodus von „vi“ kann noch in einen unmittelbaren Modus und einen Ausführungsmodus unterschieden werden. Wir überlassen die Details an dieser Stelle aber den „vi“-Fans und betrachten den Editor in Bezug auf die Unterscheidung zwischen Befehls- und Eingabemodi.

Wer den Editor „vi“ sieht, weiß, dass er offensichtlich nicht nach den Kriterien gestaltet ist, die wir in diesem Buch propagieren. Bei „vi“ gibt es keinerlei Erschließbarkeit. Auch wenn man das so akzeptiert, ist die Modusgestaltung auch bei einer routinierten Nutzung problematisch. Den Unterschied zwischen Befehls- bzw. Eingabemodus erkennt man nur an der Anzeige von `– INSERT –´ in der letzten Bildschirmzeile im Falle des Eingabemodus. Auf den Befehlsmodus kann nur aus dem Fehlen dieser Anzeige geschlossen werden.

Unerwarteter Moduswechsel – Lightroom

Mit dem nächsten Beispiel verlassen wir den Bereich der anachronistisch wirkenden Nutzungsschnittstellen und schauen uns die aktuelle Software Lightroom⁷ von Adobe an. Lightroom ist eine Anwendung, die es zum einen erlaubt, Bilder zu verwalten und zu sortieren. Zum anderen verkörpert sie einen sogenannten RAW-Entwickler, mit dem die Rohdaten digitaler Kameras bearbeitet werden können. Die Entwickler haben für diese beiden Aufgabenbereiche zwei verschiedene Modi eingerichtet. Es kommen noch einige weitere Aufgaben wie das Erstellen von Diashows und Fotobüchern hinzu, die wir an dieser Stelle aber nicht betrachten wollen. Für unsere Betrachtung reichen zwei Modi, „Bibliothek“ und „Entwickeln“ genannt.

Der aktuelle Modus ist in Lightroom gut daran zu erkennen, dass oben rechts entweder „Bibliothek“ oder „Entwickeln“ hervorgehoben ist. Im Prinzip handelt es sich also um eine optisch stark abgespeckte Reiter-Navigation. Die Modi können durch Klick auf die Worte oder aber auch per Tastaturkommando geändert werden.

Da es sich beim Sortieren und Verwalten auf der einen Seite und beim Bearbeiten und Optimieren auf der anderen Seite um recht verschiedene Aufgaben handelt, stehen in diesen beiden Modi verschiedene Funktionen zur Verfügung. Die Trennung ist aber nicht absolut. Es ist zum Beispiel in beiden Modi möglich, ein Bild durch das Eintippen von X als abgelehnt zu markieren. Dies ist zwar eine Verwaltungsaufgabe, aber da oft erst während der Bearbeitung eines Bildes auffällt, dass die Qualität Anlass dazu gibt, ein Bild als ungeeignet zu markieren, ist es im Sinne der Eingabeminimalität erfreulich, dass diese Funktion an dieser Stelle zur Verfügung steht. Ein erzwungener Moduswechsel wäre sonst die Folge.

Das Problem, das wir beschreiben wollen, hat mit einer solchen Funktion zu tun, die in beiden Modi aufgerufen werden kann, weil sie auch in beiden Modi ihre Berechtigung hat.

Zunächst einmal: Die gleichen Tastaturkürzel haben innerhalb verschiedener Modi weitgehend unterschiedliche Auswirkungen, da verschiedene Funktionalitäten zur Verfügung stehen. Ein Klick auf die Raute-Taste bedeutet im Entwicklungsmodus beispielsweise die Erhöhung einer vorher definierten Entwicklungseinstellung, beispielsweise der Helligkeit des Bildes. Innerhalb des Bibliotheksmodus steht diese Funktion nicht in der Form zur Verfügung. Die Eingabe von `#´ bewirkt stattdessen eine Änderung der Darstellungsgröße. Für sich genommen ist dies noch kein Problem.

Schauen Sie sich erneut den obigen Screenshot von Lightroom an. Wir befinden uns gerade im Entwicklungs-Modus. Das Ziel ist nun, die Belichtung dieses Bildes zu optimieren. Dazu soll es mit einem Referenzbild verglichen und entsprechend angepasst werden. Das Vorhaben besteht also aus drei Schritten: In einen Bildervergleich wechseln, den Bildervergleich beenden, die Belichtung gegebenenfalls anpassen

Um einen Vergleich des aktuellen Bildes mit dem Referenzbild aufzurufen, kann die Taste C´ für Compare´ gedrückt werden. Diese Funktion steht sowohl im Bibliotheks- als auch im Entwicklungsmodus zur Verfügung.

Der Vergleich offenbart nun, dass die Belichtung unseres Bildes im Vergleich zum Referenzbild zu dunkel ist. Ein weiterer Klick auf `C´ beendet die Vergleichsansicht wieder.

Nun könnte man den Eindruck gewinnen, dass die Anwendung wieder im gleichen Zustand wie vor dem Vergleich ist. Das täuscht aber, denn unbemerkt von unseren Handlungen hat sich der Modus von „Entwickeln“ auf „Bibliothek“ umgeschaltet.

Klickt man nun auf die Raute-Taste, um die Belichtung anzupassen, wird stattdessen die Darstellungsgröße verändert. Eine Eingabe, die zu einem Modus gehört, ist versehentlich im falschen Modus durchgeführt worden. Das Ergebnis führt höchstwahrscheinlich zu Irritationen, in jedem Fall aber zu Korrekturaufwand. Der Ausgangspunkt des Problems ist, dass aus dem Entwicklungsmodus heraus eine Funktion aufgerufen werden kann, die eigentlich Teil eines anderen Modus ist. Ohne einen weiteren Hinweis wird jedoch nicht nur die Funktion selbst aufgerufen, sondern auch der Modus gewechselt. Das Modusproblem kann aber auf zweierlei Art vermieden werden. Entweder wird die Funktion in beiden Modi ohne Notwendigkeit eines Moduswechsels angeboten oder der Modus wird bei der Beendigung der Vergleichs-Funktion wieder auf den Modus „Entwickeln“ gesetzt, wenn die Funktion von dort aus aufgerufen worden ist.

Fremdgesteuerter Moduswechsel – Focus-Stealing

Im Lightroom-Beispiel ist der Moduswechsel zwar durch das Eingeben von `C´ ausgelöst worden, jedoch ohne Hinweis auf den damit verbundenen Moduswechsel. Im folgenden Beispiel haben wir es mit einem Moduswechsel zu tun, der ohne eine explizite Eingabe geschieht. Das sogenannte „Focus-Stealing“ bedeutet, dass ein Element der Nutzungsschnittstellen den Eingabefokus auf sich zieht, ohne dass diese Fokusänderung direkt über eine Eingabe initiiert worden wäre. Oft ist dies mit dem Erscheinen eines neuen Fensters verbunden.

Diese Abbildung zeigt ein zugegebenermaßen etwas konstruiertes Beispiel. Wir befinden uns im Editor und möchten dort den Text „Es gibt nichts Leckereres als eine gebackene Banane!“ schreiben. Unmittelbar bevor wir das Wort „Banane“ schreiben, öffnet sich ohne unser Zutun das Fenster eines Chatprogramms aus dem Hintergrund. Das Fenster enthält den Fokus und nimmt unsere Eingabe direkt an. Es gibt, oder gab zumindest, Chatprogramme, die tatsächlich so funktionieren. Häufiger tritt das Problem auf, wenn eine Software unvermittelt eine Fehlermeldung anzeigt, diese aber nicht bemerkt wird. Wenn in einem solchen Fall die Eingabe fortgesetzt und vielleicht mit „Enter“ abgeschlossen wird, kann die Meldung verschwinden oder eine Funktion ausgelöst werden. Solche Effekte sind schwer nachzuvollziehen und stiften Verwirrung. Typische Kandidaten für Focus-Stealing sind auch Fehlermeldungen oder Update-Assistenten, die sich ohne Ankündigung als vorderstes Fenster öffnen und die Eingaben an sich ziehen.

Wie lässt sich dieses Modusproblem vermeiden? Am besten dadurch, dass man vermeidet, dass Anwendungen den Fokus auf sich ziehen können. Moderne Betriebssysteme und GUI-Frameworks ermöglichen in der Regel auch das Einblenden von Nachrichten auf dem Bildschirm, die ausgewählt und bearbeitet werden können, die aber nicht den Handlungsfluss unterbrechen.

Wenn es doch nötig ist, für eine Meldung den Modus programmseitig ohne explizite Eingabeaufforderung zu ändern, muss auf den Moduswechsel, in diesem Fall das erscheinende Fenster, explizit hingewiesen werden (Ton und/oder Blinken am Bildschirm). Empfehlenswert ist in diesem Fall auch, die Eingabeverarbeitung kurzzeitig zu unterbrechen und die weiteren Eingaben nicht unmittelbar zu interpretieren. Trotz des ungefragten Moduswechsels kommt es jetzt zumindest nicht mehr zu unbewussten Aktionen und Manipulationen, weil die Unterbrechung des Handlungsflusses die Aktion bewusstseinspflichtig macht. Die Eingaben werden verworfen.

Hinweise zur Gestaltung von Modi

Aus unseren Überlegungen zum Modusproblem und aus den Beispielen können wir einige Konsequenzen für die Gestaltung von Modi ableiten.

1. Modi reduzieren. Wenn sich zwei Modi zusammenfassen lassen, ohne dass die Nutzungsoberfläche dadurch zu unübersichtlich oder unverständlich wird, sollte auf Modi möglichst verzichtet werden.
2. Den aktuellen Modus verdeutlichen. Mit den Erkenntnissen aus dem Kapitel Orientierung und dem Gestaltungsrepertoire aus dem Kapitel Präsentation muss der jeweils aktuelle Modus klar dargestellt werden, damit er auffällt und damit die Wahrscheinlichkeit für das Auftreten eines Modusproblems deutlich reduziert.
3. Moduswechsel explizit machen. Der Wechsel von einem Modus in einen anderen sollte immer ein expliziter Schritt sein. Dies kann dadurch geschehen, dass der Modus nur über ein dediziertes GUI-Element gewechselt werden kann. Falls Modi auch auf Nebenwegen wechseln können, muss gemäß der Forderungen Kontinuität und Attentionalität dafür gesorgt werden, dass der Wechsel trotzdem bewusstseinspflichtig wird.

Dieses Beispiel aus der Präsentationssoftware Keynote ist ein gutes Beispiel für die Punkte 2 und 3. Obige Meldung erscheint, wenn man versucht, ein Element des Foliendesigns zu bearbeiten, obwohl sich das Programm nicht im passenden Modus befindet. Es wird nicht etwa der Modus direkt gewechselt. Dies hätte sehr irritierende Folgen, denn es würden durch das Bearbeiten eines Objekts auf dem Bildschirm die anderen Objekte einfach verschwinden. Stattdessen wird der Arbeitsfluss sinnvollerweise unterbrochen. Dadurch wird auch die Entscheidung ermöglicht, ob der Moduswechsel tatsächlich vollzogen wird oder ob es sich um ein Versehen gehandelt hat.

Wird der Modus gewechselt, erscheint eine Bildschirmdarstellung, die zwar dem üblichen Folienbearbeitungsmodus sehr ähnelt, jedoch mit dem prominenten blauen Balken auch deutlich verschieden gestaltet ist. Dieser Balken zeigt eine Veränderung an und auch, in welchem Modus sich das System gerade befindet. Zugleich bietet dieser Balken auch eine schnelle und nicht zu übersehende Möglichkeit, den Modus wieder zu verlassen.

Die folgende Abbildung zeigt eine Software mit ähnlichem Funktionsumfang, die weitaus unübersichtlicher und mit weniger Modi durchsetzt ist. Bei Lightroom treten Probleme dadurch auf, dass Funktionen sowohl im Bibliotheks- als auch im Entwicklungsmodus sinnvoll angesiedelt sind. Die in der Abbildung zu sehende Software ist dagegen so gestaltet, dass diese Modi nicht erforderlich sind. Mittels eines GUI-Elements oben rechts kann zwischen verschiedenen Sichten, also einer Übersicht, einer Großansicht und einer gemischten, gewechselt werden, auf der linken Seite zwischen Entwicklungseinstellungen, Metainformationen und der Bibliothek selbst. Alle Kombinationen sind möglich und nicht einem Modus zugeordnet.