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.