Hilfe-Funktionen

Viele Programme verfügen über eingebaute Hilfe-Funktionen. Die schlechtesten davon sind diejenigen, die dem Benutzer auf dem Bildschirm ein Handbuch aufblättern und ihm eventuell als Spitze von Luxus das Suchen nach Schlagworten erlauben. Das Problem daran ist, dass der Benutzer entweder genau wissen muss, was er will oder was er falsch gemacht hat. Dies ist in der Regel aber nicht der Fall. Besser geeignet sind kontextabhängige oder kontext-sensitive Hilfefunktionen. Sie können sowohl den Zustand des Systems erklären als auch Unterstützung in Situationen bieten, in denen der Benutzer Fehler gemacht hat und nicht mehr weiter weiß. Für die Beschreibung des Systemzustands bieten fast alle Systeme mit grafischem Benutzer-Interface hinreichend brauchbare Funktionen, während es bei Fehlern in konkreten Situationen noch sehr hapert. In der Blütezeit der Großrechner waren Meldungen wie

durchaus an der Tagesordnung. Sie bieten dem Benutzer, der natürlich selber Schuld ist, wenn er kein Englisch versteht, so gut wie keine Chance, sich eine Meinung zu bilden, was denn nun falsch gelaufen ist. Fehlermeldungen sollten also in deutscher Sprache erfolgen und verwertbare Informationen enthalten.

Gerade bei Programmen, die viele Eingabetätigkeiten verlangen, kann die Fehlerprüfung in fast 100 Prozent der Fälle im “Eingabedialog” selbst erfolgen. So können unbrauchbare Formate wie Buchstaben in einem Feld, das nur Zahlen enthalten soll, direkt abgewiesen werden. Falsche oder unkonventionelle Datumseingaben könnten automatisch vom Programm korrigiert werden; allerdings sollte dies dann in einer Form geschehen, in der der Benutzer bemerkt, dass der Computer seine Eingabe abgeändert hat. Bestimmte Schlüsselangaben können sofort auf Existenz und Plausibilität geprüft werden, z.B. bei Konten, Kostenstellen, Personalnummern, Auftragsnummern, Arbeitsplänen usw. prüft das Programm, ob die eingegebenen Werte überhaupt existieren. Anspruchsvollere Systeme prüfen zusätzliche Plausibilitäten, z.B. ob die Benutzereingabe an der erfolgten Stelle sinnvoll sein kann. Dies setzt voraus, dass sich der Arbeitsgegenstand in Form von Regeln beschreiben lässt. In diesem Fall wären die Regeln auf dem für die Benutzer zentralen Datenbankserver abzulegen. Dies geschieht auch relativ häufig in der beschriebenen Form. Leider wird meist vergessen, erklärende und auswertungsfähige Texte für den Benutzer dazuzuspeichern. Man merkt dann zwar, dass eine falsche Eingabe nicht gelingt, erhält aber keine brauchbare Information darüber, warum die Eingabe falsch ist.

Techniken regel- oder wissensbasierter Systeme könnten durchaus eingesetzt werden, um dem Benutzer auswertbarere Erklärungen zu bieten. Dahinter verbergen sich kleine “Expertensysteme”, in denen gewisse Regeln über den Gebrauch des Anwendungssystems enthalten sind. Die Propagandisten führender Softwarefirmen haben hier zwar schon marktfördernde Schlagworte wie “intelligenter Fehlerdialog” geschaffen, doch den Worten fehlen leider weitgehend die Taten. Wir befinden uns hier in einem Bereich, in dem der Aufwand sehr hoch ist. Solche Systeme hätten nicht nur die erlaubten Regeln der Eingabe abzufragen, sondern auch die Benutzereingabe zu analysieren. Doch mindestens für die benutzereingabeintensiven zigtausendfach verbreiteten Standardsoftwarepakete à la SAP sollte die Anwender-Kundschaft dies von den Entwicklerfirmen fordern, denn bei tausenden zu siebenstelligen Summen verkauften Lizenzen ist der Aufwand durchaus finanzierbar.

Besonders fehleranfällig sind Programme, die mit mehreren Modi oder Arbeitszuständen arbeiten. Von den Textsystemen aus Großrechnerzeiten oder bei den unter Programmierern immer noch beliebten Editoren kennt man die Systeme mit Befehls- und Schreib- oder Arbeitsmodus. Wegen der geringen Zahl der Tasten und der großen Zahl der möglichen Befehle werden Tasten oft mit unterschiedlichen Funktionen je Arbeitszustand belegt. Dies führt schnell zu Verwechslungen, vor allem dann, wenn nicht ersichtlich ist, in welchem Modus man sich gerade befindet.

Ein besonders krasses Beispiel bietet ein älteres, für Multi-user-Systeme konzipiertes Editorsystem. Es unterscheidet auch zwischen Befehlsmodus, dem command mode, und einem Schreibmodus, dem insert mode. Befindet man sich im Befehls- statt im Schreibmodus und schreibt das unverfänglich klingende Wort EDIT, so erlebt man eine böse Überraschung. Der Befehlsmodus in unserem Beispiel ist auch noch mit einer Pufferfunktion versehen, d.h. man kann mehrere Befehle in den Puffer schreiben, die dann alle der Reihe nach später ausgeführt werden. Als erstes nimmt das System das “E” aus dem Puffer und editiert die ganze Datei. Dann folgt das “D”, und dies ist unglücklicherweise der Kurzbefehl für DELETE: Der frisch editierte Text wird gelöscht. Der Buchstabe “I” bewirkt nun das Umstellen auf den insert mode, den Schreibmodus. “T” wird nun als zu schreibendes Zeichen interpretiert. Man steht nun vor dem berauschenden Ergebnis, dass man seinen ganzen Text gelöscht und stattdessen ein Dokument mit einem einzigen Buchstaben, einem T, erstellt hat.

Was ist zu tun? Programme mit unterschiedlichen Arbeitszuständen sollten unbedingt gemieden werden. Wenn sich solche Programme nicht verhindern lassen, dann muss darauf geachtet werden, dass die Zahl der Modi möglichst gering bleibt und dass der Benutzer unbedingt eine klar erkennbare Anzeige erhält, die ihm mitteilt, in welchem Arbeitszustand er sich mit dem System befindet.

Einleitung -Modellierung - Steuerbarkeit - Sichtbarkeit -Natürliche Symbole - Umgang mit Fehlern - Einfachheit - Intuitive Bedienung - Anpassbarkeit - Regelungen