Es werden Gründe angeführt, weshalb heute befriedigende Lösungen für eine gute Mensch-Maschine-Interaktion so schwierig zu realisieren sind. Eine Gegenüberstellung gegensätzlicher Charakteristika und Eigenschaften von Benutzer und System, von Mensch und Rechner, schließt sich an. Das dient zur Verdeutlichung der Stärken beider Seiten und führt schließlich zur Forderung nach Benutzerfreundlichkeit dialogorientierter DV-Systeme (Teil 6, Schluß)
* Die Verfasserin ist im Zentralbereich Technik bei Siemens (München-Perlach) tätig und war an der Entwicklung des Projekts CONDOR (COmmunikation in Natürlicher Sprache mit dialog-orientierten Retrieval-Systemen) beteiligt einem vom BMFT geforderten Modell eines integrierten DB-/lR-Systems für strukturierte Daten und Textdaten.
4.5 Verläßlichkeit
- Das System sollte sich in indentischen Situationen identisch verhalten. - Vom Benutzer sollten bei ähnlichen Aufgaben einheitliche Aktionen gefordert werden. Möglicherweise im Widerspruch dazu: Die Abfolge der Arbeitsgänge sollte sich durch das System sowenig wie möglich verändern.
- Die logische Bearbeitungsfolge sollte - auch bei formatierten Bildschirmen - dem üblichen Schreibfluß (von links nach rechts) folgen und dennoch nicht die Übersichtlichkeit des Formats beeinträchtigen.
- Es sollten geringe Überraschungseffekte für den Benutzer geboten werden.
- Es sollte stur dort angekreuzt werden können (Menüs), wo Gefahren warten - und es sollte dort der Benutzer aktiviert werden (unstrukturierte Eingabe), wo sichere Eingaben erwartet werden.
- Es sollte als Prinzip gelten: Sicherheit der Datenbestände.
- Es sollte ein schnelles Neuladen bei maximalem Schutz der bereits vom Benutzer eingegebenen Informationen, auch bei Systemausfällen, möglich sein.
- Der Benutzer muß die Ausgabe (zum Beispiel bei zuviel Information) anhalten und wieder fortsetzen können, ohne daß dabei Daten verlorengehen.
Oder: Vorwarnung, daß die Ausgabe sehr groß sein wird, und Vorschläge des Systems zur Eingrenzung.
- Bei längeren Vorgängen sollten Zwischenausgaben den Stand der Bearbeitung anzeigen, etwa an einer fest dafür definierten Stelle.
- In der Menütechnik sollten im weiteren Dialog nur noch die ausgewählten Vorgänge ablaufen beziehungsweise erscheinen. Nicht mehr benötigte Schritte sollten gelöscht werden und wichtige Informationen des bisherigen Dialogs in Kurzform dargestellt werden können.
4.6 Berücksichtigung des Zeitfaktors
- Antwortzeiten sollten kurz sein und für die gleichen Ein-/ Ausgaben nicht zu stark variieren.
- Zu schnelle Antwortzeiten können dazu führen, daß sich der Benutzer gehetzt fühlt.
- Lange Antwortzeiten (über 4 Sekunden) werden eher akzeptiert, wenn der Benutzer der Ansicht ist, daß der Rechner eine schwierige Antwort erarbeitet oder wenn sie einem Dialogabschnitt folgen, in dem ein Zwischenziel erarbeitet wurde (lange Antwortzeiten unterbrechen den Gedankenfluß).
- Anstreben von kurzen Suchzeiten eines bestimmten Elementes auf einem Bildschirm: Die Suchzeit wird herabgesetzt, wenn jeder Begriff in einer neuen Zeile steht.
- Ein oftmaliges Verwenden der Leertaste sollte vermieden werden.
- Der Blickweg zwischen dem vorgegebenen Text auf dem Schirm und der Eintragung ist kurz zu halten.
- Die Suchzeit von Elementen auf einem Bildschirm wird herabgesetzt und die Fehlerhäufigkeit vermindert, wenn häufig benutzte Begriffe am Anfang einer Liste stehen. Das gilt vor allem für die Anordnung von Menüs, die so sein sollte, daß die am wahrscheinlichsten anzukreuzenden Punkte oben, die weniger wahrscheinlichen abgestuft nach unten angeboten werden sollten.
4.7 Benutzerfreundliche Fehlerbehandlung
- Fehlermeldungen sollten so exakt und problemorientiert wie nur möglich sein, das heißt Auskunft mit möglichst direktem Bezug zu aktuellem erkannten Fehler geben.
- Nach Eingabefehlern und Ausgabe einer Fehlermeldung sollte das System nicht sofort die Arbeit einstellen.
- Es sollten Möglichkeiten vorhanden sein, einen verkürzten Fehlercode oder einen auführlichen Fehlertext ausgeben zu lassen.
- Dem Benutzer sollten Fehler im Klartext gemeldet werden sowie die Art des Fehlers die Stelle seines Auftretens mit der Möglichkeit des Zurücksetzens zur Fehlerstelle und ein Korrekturhinweis im Hinblick auf das Weiterarbeiten.
- Nach der Verbesserung beziehungsweise Veränderung eines Fehlers muß der Benutzer seine Arbeit sinnvoll fortsetzen können und nicht jedes Mal von vorn beginnen müssen.
- Die Fehlermeldung sollte nicht nur für Systemkenner verständlich sein.
- Das System muß typische Tippfehler des Benutzers erkennen und tolerieren.
- Bei folgenschweren Anweisungen (zum Beispiel DELETE) solle das System vorher nochmals fragen, um Kummer zu vermeiden. Oder: Es sollten besondere Dateien angelegt werden, in die gelöschte oder überschriebene Information zunächst gespeichert wird; das bedeutet eine "sichere" Fehlerbehandlung. Eine falsche Handhabung hat damit nicht die Zerstörung von Daten zur Folge (Lernen dadurch, daß man Fehler macht, ist sehr effektiv!).
- Der Benutzer vergißt und macht Fehler. Sein Handeln soll als unvorhersehbar eingeschätzt werden.
- Eine uneingeschränkte Wiederaufsetzbarkeit in allen Situationen sollte gewährleistet sein.
- Ein Hinweis auf erlaubte Zeichen oder Sprachelemente kann ein Nachschlag in der Bedienungsanleitung überflüssig machen.
Quellen
Dazida, W.: Herda, S.: Itzfeld, W. D. u.a.: was ist Benutzerfreundlichkeit? GMD-Spiegel 3/77
Dehning, W.: Essig, H., Maaß, S.: Zur Anpassung virtueller Mensch-Rechner-Schnittstellen an Benutzererfordernisse im Dialog. Dargestellt am Beispiel von Datenbanksystemen. Bericht Nr. 50 des Instituts für Informatik, Hamburg, Juli 1978
DIN-Norm-Entwurf 66 2343, Nov. 78
Jaeschke, G: Keppel, E: Kropp, D.: Interaktive Programmierung durch Endbenutzer. IBM Deutschland GmbH, April 1977
Nievergelt, J.: Weydert, J.: Sites, Modes, and Trials: Telling the User of an Interaktive System Where he is, What he can Do and How to Get to Place. Swiss Federal Institute of Technologie, Zürich, Januar 1979.
Weichselbaumer, Claus: Methoden und Hilfsmittel zur Entwicklung von Benutzersprachen In: Data Report 14 (1979), Heft 3, S.40