Gedanken zur Ergonomie

Die äußere Gestalt der Applikation

Das Leitmotiv einer Applikation sollte das WYSIWYG-Prinzip (WYSIWYG: What You See Is What You Get) sein. Auch wenn es oft nur auf die Gleichheit von Bildschirm- und Druckerausgabe bezogen wird, geht der Anspruch dieses Prinzips weiter. Der Grundgedanke liegt darin, daß der Benutzer das Objekt, auf dem er arbeitet, sehen kann und die Aktionen, die er mit dem Objekt ausführt, visuell zurückgemeldet werden. Aus diesem Grund sollte das Fenster das Objekt zeigen, mit dem der Benutzer arbeitet. Eine gute Eselsbrücke ist es, daß auf dem Fenster das Substantiv und im Menü das Verb ist.

Es ist sinnvoll, dem Benutzer zu Anfang den bestmöglichen Überblick über die bearbeiteten Objekte zu verschaffen. Bei Textverarbeitung oder Tabellenkalkulation ergibt sich der Inhalt des Hauptfensters fast von selbst. Hier stellt die Applikation im Fenster naheliegenderweise das Arbeitsblatt dar. Bei datenbankähnlichen Anwendungen ist im Ausgangsfenster eine Auflistung mehrerer Einträge in Kurzform meist sinnvoller als die Darstellung einer Maske für nur einen Eintrag. Arbeitet die Anwendung auf mehreren Tabellen, kann eine ikonisierte Darstellung aller verfügbaren Tabellen sinnvoller sein als die Listendarstellung. In diesem Fall sollte ein Doppelklick auf die Ikone eine Listendarstellung und der Doppelklick auf einen Listeneintrag eine Maskendarstellung in zusätzlichen Fenstern hervorbringen.

Die Darstellung des zu bearbeitenden Objekts scheint trivial zu sein. In manchen Fällen bringt aber eine gelungene Variante der Darstellung Wettbewerbsvorteile. Bei Sequencern14 war es weit verbreitet, für jede Spur nur einen Knopf darzustellen. Über diese konnte man nacheinander die Notensequenzen durchblättern. In den neueren Programmen erhält man dagegen eine zeitanaloge Übersicht über das Musikstück, in denen die Spuren untereinander in langen Streifen dargestellt werden. Dadurch ist leicht zu überschauen, wann welches Instrument einsetzt. Alle Operationen wie Kopieren, Verschieben oder Löschen sind intuitiv.

In den Menüs sollten sich die Tätigkeiten finden, die der Benutzer auf das angezeigte Objekt anwenden kann. Diese Tätigkeiten sollten möglichst objektbezogen interpretierbar sein. So sollte ein Menüpunkt statt zwei Einträgen ``Kunde entfernen'' und ``Kundenstamm löschen'' ein Eintrag ``Entfernen'' vorgesehen werden, der je nachdem, ob ein einzelner Kunde oder eine komplette Tabelle angewählt ist, die entsprechende Operation durchführen. Der Vorteil ist, daß die Menüs kürzer und universeller werden. Sind bestimmte Operationen auf dem markierten Objekt nicht möglich, sollte der entsprechende Menüeintrag deaktiviert werden.

Für Eingaben in kleinerem Umfang verwendet man Dialogboxen. Nehmen die Eingaben den Umfang von größeren Masken an, werden eher Fenster für die Eingabe verwendet, da Dialogboxen dem Charakter nach eher für kleine und vor allem kurzfristige Rückfragen an den Benutzer gedacht sind.


Der gelungene Entwurf einer Oberfläche zeigt sich in seiner Einfachheit. Je weniger Bedienungselemente und Objekte vorliegen, desto einfacher kann der Benutzer den Überblick bewahren. Um dieses Ziel zu erreichen, ist eine geeignete Sicht auf die zu bearbeitenden Objekte zu schaffen und Operationen zu definieren, die möglichst vielseitig auf die verschiedenen Teilaspekte anwendbar sind. Dazu gehört es auch, Operationen, die seltener benötigt werden, vom Hauptfenster in speziellere Fenster oder Dialogboxen auszulagern.

Gedankenlesen

Der Grundgedanke bei der Entwicklung der grafischen Oberflächen war es, dem Benutzer eine Oberfläche zur Verfügung zu stellen, in denen er möglichst intuitiv Operationen durchführen können sollte, ohne daß er den Syntax einer Steuerung kennen mußte. Anstatt dem Benutzer einen Weg vorzuschreiben, der als einziger zu einer korrekten Lösung seines Problems führt, sollten ihm Analogien zu seinem Alltagsbereich zur Verfügung gestellt werden, die ihm ermöglichen sollen, mit einfachen Mitteln die Operationen durchzuführen. Nach der Gestaltung der Programmoberfläche sollte sich der Programmierer in die Rolle des Benutzers begeben und überlegen, was dieser alles tun könnte, um einem bestimmten Ziel näher zu kommen. Bei einem Programm unter einer grafischen Oberfläche gibt es häufig mehrere Wege, die der Benutzer einschlagen könnte, um das gleiche Ziel zu erreichen. Ein markierter Bereich könnte gelöscht werden, indem ein Menüpunkt angeklickt, der Bereich in den Papierkorb geschoben, oder die Entfernentaste gedrückt wird. Alle Wege, die einen Benutzer auf logische Weise zu einem bestimmten Ziel führen, sollten idealerweise funktionieren.

Um solche Wege zu finden, kann ein Blick ins Programmlisting gute Ausgangspunkte liefern. Ein vom Programm bisher ignoriertes Ereignis sollte daraufhin abgeklopft werden, ob der Benutzer vielleicht auf diesem Weg eine bestimmte Lösung sucht. Programmtechnisch ist es meist kein großer Aufwand, diesen Weg zu öffnen. Die Erstellung einer intuitiven Benutzerschnittstelle grenzt ein wenig an Gedankenlesen: was könnte sich der Benutzer gedacht haben, als er das Ereignis xyz aulöste? Jedes Ereignis, das nicht einfach ignoriert wird, sondern einen vernünftigen Weg zu einer Operation ebnet, erleichtert dem Benutzer die Bedienung des Programms.

Besondere Aufmerksamkeit verdienen in diesem Zusammenhang die Sondertasten. Sie sollte die Entfernen-Taste zum Löschen des angewählten Objektes führen, im Zweifelsfall über den Weg einer Warnung.

Neben der Tastatur bietet natürlich die Maus viele Möglichkeiten, dem Benutzer zusätzliche Wege zur Verfügung zu stellen. Hier können sich durch Ziehen, Anklicken oder Doppelklicken bislang passiver Elemente zusätzliche Möglichkeiten auftun.

Ungeliebte Individualisten

Fast jeder von uns hat seine eigenen Vorstellungen, wie ein ergonomisch optimales Programm auszusehen hat. Dies ist auch bei Programmierern so und das ist der Grund, warum früher kaum zwei Programme auf die gleiche Art und Weise bedient werden konnten. Leider hatte diese Individualität den Nachteil, daß der Anwender sich ständig umstellen mußte.

Gerade in der systemkonformen Bedienung wird die Hemmschwelle zur Benutzung des Programms erheblich reduziert. Die Begeisterung für die grafischen Benutzeroberflächen seitens der Kunden findet sicher in der gleichartigen Bedienung der meisten Programme einen Hauptursprung.

Aus diesem Grund geben fast alle Hersteller grafischer Oberflächen Vorschriften über die Programmierung heraus. Je näher sich die Anwendung den "Style Guide" genannten Papieren verhält, desto einfacher wird der Anwender die Bedienung finden. Bei der Erstellung einer Applikation sollte man davon ausgehen, daß der Benutzer auch andere Programme benutzt und darauf achten, daß das eigene Programm sich möglichst an die Quasi-Standards der anderen hält, wenn es schon keine Vorgaben vom Hersteller der Oberfläche gibt. Umgeht man solche Regeln, fällt dies meist auf das eigene Produkt zurück. Auch wenn man solche Richtlinien für umständlich hält, gilt die Regel, daß ein schlechter Standard immerhin besser ist als gar keiner.

Bei OSF/Motif sind diese Richtlinien sogar in die Programmierschnittstellen wie das MainWindow- und das Dialog-Widget eingeflossen. IBM hat bereits für seine textorientierten Systeme den Common User Access (CUA) definiert und bei Erscheinen auf den Presentation Manager erweitert. Beim GEM gab es keine von Atari vorgegebenen Richtlinien. Allerdings ist die Notwendigkeit solcher Regeln von den Entwicklern selbst erkannt und in die Hand genommen worden. Hinweise auf die systemspezifischen Richtlinien sollten sich in den Programmierhandbüchern der entsprechenden Systeme finden.

Ein Programmierer oder Grafiker mag die Elemente seiner Oberfläche inzwischen langweilig finden. Für den Benutzer ist diese "Langeweile" Gewohnheit und Sicherheit. Man muß sich darüber klar sein, daß die meisten Anwender nicht so "computersicher" sind wie Entwickler. Die Multimediabranche hat uns eine neue Welt der Grafik gebracht. Daß Grafiker keinen Gefallen an der Standardoberfläche haben, ist leicht zu glauben. Leider ist es aber durch den Einfluß des Designs manchmal nicht leicht, die Buttons zu finden, weil so schick in die Oberfläche integriert sind. Viele Lexikonprogramme sind aufgrund ihrer Grafiküberfrachtung nicht mehr als Hilfsprogramm für die Textverarbeitung zu gebrauchen, sondern nur noch als Rahmen für die darin gesammelten Animationen.

Überraschung!

So sehr es der menschlichen Natur entspricht, den Anderen überraschen zu wollen, so sehr sollte sich der Programmierer dieser Versuchung entziehen. In der Software-Entwicklung sollte das Prinzip der geringsten Überraschung vorherrschen. Es sagt aus, daß der Benutzer möglichst selten von der Reaktion des Programmes auf seine Aktionen verblüfft sein sollte. Umgesetzt bedeutet dies, daß ein Verfahren, das an einer bestimmten Stelle des Programms funktioniert, an einer anderen Stelle mit ähnlicher Funktionalität auf ähnliche Art anwendbar sein sollte. Beispielsweise sollte ein Programm, bei dem man eine Datei durch Ziehen auf den Papierkorb löschen kann, dasselbe auch für das Löschen aller anderen Objekte ermöglichen.

Einige Aktionen sollten immer gleiche Reaktionen der Applikation mit sich bringen. Üblich sind z. B. folgende Zusammenhänge:

Einfaches Anklicken Selektion eines Objekts
Doppeltes Anklicken Aktivieren eines Objekts
Ziehen selektierter Objekte Verschieben oder Kopieren
Ziehen und Loslassen über Symbol Zuführen des Objektes an Symbol
Menüpunkt anwählen Aktion auf den selektierten Objekten
Tabulator-Taste Aktiviere nächstes Element
ESC Verwerfen einer Dialogbox
Return Akzeptieren einer Dialogbox

Wegen Überfüllung verworfen

Beim Herunterklappen manchen Klappmenüs gewinnt man den Eindruck, daß der Programmierer sich bei der Anzahl der Einträge nur durch die vertikale Auflösung des Bildschirms beschränkt fühlte. Auch wenn volle Menüs bei manchen Kunden das Gefühl hinterlassen mögen, das Programm sei mit vielen Funktionen ausgestattet, sollte man auch die Kunden berücksichtigen, die das Gefühl bekommen, die Bedienung sei von Komplexität geprägt. Wenn dies noch nicht überzeugend ist, helfen vielleicht einige Erfahrungen bezüglich der Fähigkeiten des Menschen komplexere Gebilde zu betrachten.

Als Faustregel gilt, das der Mensch maximal sieben Elemente schnell überblicken kann. Durch geschicktes Gruppieren ist es auch möglich, z. B. fünf Gruppen mit je drei Einträgen in ein Menü zu packen. Zur optischen Unterteilung der Gruppen wird eine Trennlinie eingesetzt. Wichtig für den Überblick ist, daß dem Benutzer die Unterteilung sofort einleuchtet. Diese Regeln kann man leicht verifizieren. Wenn man die Programme, mit denen man häufig arbeitet, daraufhin betrachtet, welche Menüs man auswendig kennt und welche man jedesmal erst wirklich ``durchlesen'' muß, wird man feststellen, daß dies meist gar nicht ausschließlich mit der Häufigkeit der Benutzung, sondern mit der Fülle der Punkte zu tun hat.

Die Anzahl der Menüpunkte kann man oft durch Zusammenfassung in einer Dialogbox verkleinern. So wird in einigen Textverarbeitungen die Schriftart (kursiv, unterstrichen, etc.) in den Menüs angezeigt. Dies hat den Vorzug, daß man durch Haken an den Einträgen leicht den aktuellen Zustand ablesen kann. Wird dagegen die Menüleiste zu voll, ist es sinnvoller, stattdessen einen Eintrag ``Schriftart...'' einzusetzen, der eine Dialogbox zeigt, in der die Schriftarten mit Hilfe von Auswahlknöpfen eingestellt wird. Bei der Gelegenheit sei erwähnt, daß es sich inzwischen auf fast allen Systemen durchgesetzt hat, daß man hinter Menüpunkte, die gleich anschließend eine weitere Auswahl ermöglichen, drei Punkte setzt.

Ähnliche Grundsätze gelten bei der Gestaltung von Dialogboxen. Auch hier ist eine überfüllte Box unübersichtlich. Enthält sie zu viele Elemente, ist zu überlegen, ob man sie nicht besser aufteilt. Bei MS-Windows kann man hierzu einen Mechanismus verwenden, mit dem eine Dialogbox auf Benutzeranfrage nach unten ausklappt um weitere, weniger häufig benutzte Einstellungen vorzunehmen. Der Presentation Manager ermöglicht die Verwendung von Notizbüchern. Dies sind eigentlich mehrere Dialogboxen übereinander, die mit einer Art Lesezeichen am Rand versehen sind und dem Benutzer einen schnellen Wechsel in die für ihn wichtige Dialogbox ermöglicht.

Die Maus und die andere Seite des Pferdes

Als die Maus ihren Platz rechts neben der Tastatur einnahm, war man so geblendet von den Möglichkeiten des kleinen Tierchens, daß man die links liegende Tastatur am liebsten vollständig entfernt hätte. Lediglich die Notwendigkeit von Texteingabe schien ihr das Verbleiben am Computer zu sichern. Die meisten Steuerungsaufgaben wurden nicht mehr von Funktionstasten, sondern ausschließlich von der Maus übernommen. Ein beredtes Zeugnis dieser Entwicklung war die Tatsache, daß die ersten Macintosh-Modelle nicht einmal über Cursortasten verfügten. Jede Neupositionierung innerhalb einer Textverarbeitung mußte mit der Maus durchgeführt werden.

Aus ergonomischer Sicht ist der Tod der Funktionstasten, die von Softwareherstellern bis dahin als das Symbol der Benutzerfreundlichkeit verkauft wurden, nicht unbedingt zu bedauern. Schließlich gibt es wohl kaum etwas Abstrakteres als eine Nummer. Und dies wird auch nicht dadurch verbessert, daß man ein F oder ein PF davor setzt. Obwohl sich im Laufe der Jahre ein gewisser Standard für die Bedeutung der Tasten durchgesetzt hat, wie F1 für Hilfe, F3 für Ende und F4 für Auswahl, sind diese Belegungen weder zwingend noch für den Benutzer einleuchtend, da die entsprechenden Bedeutungen nicht auf die Tasten aufgedruckt sind und so nur durch stumpfes Auswendiglernen zu erfassen sind.

Nun wurde alles durch die Maus gesteuert und die Welt schien in Ordnung. Man erkannte aber bald, daß man nun auf der anderen Seite vom Pferd gefallen war. Wollte eine Sekretärin mit 10-Fingertechnik eine andere Maske anwählen, brauchte sie vormals die Finger nicht von der Tastatur nehmen (höchstens um nach einer Funktionstaste zu suchen). Durch die Maussteuerung war dies nun ständig notwendig. Mag es daran liegen, daß die meisten Programmierer ihre Tastatur mit einer akrobatisch anmutenden 4- bis 6-Fingertechnik bedienen oder daran, daß die meisten Programmierer ihre eigenen Programme selten anwenden müssen: es dauerte eine ganze Weile, bis die Beschwerden der Anwender ihren Weg in die Softwareentwicklung fanden. Zum Glück gab es keinen reumütigen Schritt zurück zu den Funktionstasten, sondern es wurden Buchstaben in Verbindung mit Kontrolltasten zur Steuerung der Programme verwendet.

Für die Auswahl der Menüs, die hiervon besonders betroffen sind, haben sich zwei Strategien entwickelt. Auf der einen Seite sind z. B. unter GEM und Macintosh einzelne Kontrollsequenzen, wie Control-S bzw. Apfeltaste-S für Speichern, üblich geworden. Auf der anderen Seite werden wie bei PM und MS-Windows die Anfangsbuchstaben der Menüeinträge in Kombination mit der Alternatetaste verwendet. Dies ergibt im allgemeinen eine mindestens zweibuchstabige Sequenz. Letztere hat zwar den Nachteil, etwas länger zu sein, aber auch den Vorzug, daß sie leichter erlernbar ist, besonders wenn es sich nicht um Funktionen handelt, die in jedem Programm vorkommen, wie Speichern oder Laden.

Unter MS-Windows und Presentation Manager sind sogar Dialogboxen zur Not allein durch die Tastatur bedienbar. Für MS-Windows-Applikationen wird mit Blick auf Notebook-Computer gefordert, daß ihre Bedienung allein über die Tastatur möglich sein soll.

Zusammenfassend kann man sagen, daß ein Programm immer auch von der Tastatur aus zu bedienen sein sollte. Die Wahl der verwendeten Tasten sollte sich an den Richtlinien für das System orientieren, bzw. an dem, wie die meisten anderen Programme unter dieser Oberfläche bedient werden.


14 Ein Sequencer ist ist ein Programm zur Bearbeitung von Musikstücken für computergesteuerte Musikinstrumente. Dabei werden, vergleichbar mit einem Mehrspurtonband, die verschiedenen Instrumente auf parallel laufenden Spuren bearbeitet und schließlich gemeinsam abgespielt.


Inhaltsverzeichnis (C) Copyright 1993-1999 Arnold Willemer