Mangelhafte Fehlermeldungen

Technische Dokumentation
Online-Hilfe
250 Meldungen unter der Lupe
Mangelhafte Fehlermeldungen
Von Johann Olasz
Eine Software hat einen Programmierfehler, eine Installation wurde nicht richtig ausgeführt, eine
Hardware ist nicht richtig angeschlossen oder der Anwender macht einfach einen Fehler – prompt
erhält er eine Meldung, die ihm den genauen Fehler, dessen Ursache und die passende Abhilfe
nennt. So zumindest die Theorie. In der Realität sieht es leider etwas anders aus. Mangelhafte
Fehlermeldungen sorgen mehr für Unklarheit und damit bei manchem Anwender für Stress,
Hilflosigkeit und Zeitverlust.
Johann Olasz M.A. ist seit 1985 Technischer Redakteur. Die umfassende Erfahrung mit Dokumentation aus Bereichen
der Technik, IT und betrieblichen Kommunikation bildet die Grundlage für das
Dienstleistungsspektrum seines Büros.
Im Mittelpunkt steht die lerngerechte
Informationsgestaltung von Benutzerdokumenten, Online-Hilfen und Softwareoberflächen.
N
iemand bestreitet, dass das Erstellen hilfreicher Fehlermeldungen eine recht komplizierte
Angelegenheit ist, müssen doch softwaretechnische und sprachlich-didaktische Aspekte unter einen Hut gebracht
werden. Nicht zu vergessen sind die finanziellen Gesichtspunkte.
In den wenigsten Fällen scheint es zu
gelingen, anwenderfreundliche Fehlermeldungen zu erstellen. Von über 250
Meldungen, die im Vorfeld dieses Beitrags analysiert wurden, weisen 75 Prozent kleine oder große Mängel auf. Bei
einem Usability-Test oder einer Konformitätsprüfung nach der EU-Richtlinie zur Bildschirmarbeit 90/270 würden
diese Meldungen einfach durchfallen.
Damit nicht genug: durch die Lokalisierung verbreitet sich das Problem.
Die Aufgaben einer Fehlermeldung
sind eindeutig: Sie soll in jedem konkreten Fehlerfall dem Anwender möglichst
schadlos aus der Patsche helfen oder ihn
zumindest über die Ausweglosigkeit der
Situation informieren. Nicht so klar ist,
wie diese Ziele zu erreichen sind.
Wenn wir uns vorstellen, dass in einem kleinen Meldungsfenster ein oft
recht komplexer Sachverhalt unterzubringen ist, benötigen die Hilfe-Autoren
50
und Technischen Redakteure eindeutige
und detaillierte Vorgaben, um anwenderfreundliche Meldungen erstellen zu
können. Trotz aller Bemühungen, Fehlersituationen durch Programmierung
abzufangen, produziert Software Fehler.
Um einer schlechten Beurteilung ihrer
Anwendung vorzubeugen, sollten Softwarehersteller aus der Not eine Tugend
machen und Fehlermeldungen den Bedürfnissen und Wünschen des Anwenders anpassen. Und dieser benötigt letztlich nichts anderes als die richtige Hilfe.
Wann ist eine Fehlermeldung hilfreich?
Mängelliste ergeben, die deutlich zeigt,
wo die Probleme liegen und in welchem
Umfang sie auftreten.
1. Ist der Meldungstext verständlich und sinnvoll?
Auf Inhalt und Verständlichkeit des Textes, so haben es Forscher des Instituts für
Psychologie in Bern herausgefunden, legen die Anwender am meisten wert. Ein
unverständlicher oder nichtssagender
Text löst bei ihnen Gefühle wie Überforderung oder Unfähigkeit aus.
Was die Verständlichkeit beeinträchtigen kann, ist uns allen geläufig.
Die Mängel in den analysierten Meldungen erstrecken sich von einfachen
Schreibfehlern über Fachjargon (Abb.
1), fehlende Informationen, didaktisch
falsche Sequenzierung (Abb. 2) bis hin
zu absurden Aussagen (Abb. 3).
• Ergebnis der Analyse:
38 Prozent mangelhaft
Die Qualitätskriterien finden sich in der
Usability-Norm DIN EN ISO 9241, Teil
13. Eine gute Fehlermeldung muss den
Anwendern helfen,
• trotz des Fehlers das beabsichtigte
Arbeitsziel zu erreichen,
• Situationen/Tätigkeiten, die zu Fehlern führen, zu erkennen und künftig zu vermeiden,
• Grenzen der Software
zu erkennen, um künf- Abb. 1: Dieser Fachjargon ist für den Anwender untig innerhalb dieser verständlich. Sollte die Meldung für Programmierer
Grenzen zu agieren,
gedacht sein, darf sie nicht erscheinen.
• die Anwendung auch im
Fehlerfall wenn möglich
selbst zu steuern.
Wie können die
Qualitätskriterien
erfüllt werden?
Bei einer Beurteilung sind
die nachfolgend aufgeführten Merkmale zu bewerten. Die Analyse der
Fehlermeldungen hat eine
Abb. 2: Dieses Beispiel zeigt eine falsche Informationsreihenfolge der Lösungsschritte. Zuerst sind immer Anschluss und Stromversorgung zu prüfen. Erst
wenn das in Ordnung ist, soll eine Testseite gedruckt
werden.
01/07 technische kommunikation
#5393 tk 01_07.indd 50
20.12.2006 14:37:46 Uhr
Online-Hilfe
bestätigung“, ohne jedoch
eine klare Klassifikation
aufzustellen oder gar Symbole vorzugeben.
Die Notwendigkeit, den
Meldungstyp zu erkennen,
Abb. 3: Auch Computer scheinen wohl zu „menist umstritten. Psycholoscheln“ und wissen nicht immer, was falsch oder
gisch gesehen stimmt die
richtig ist.
Identifizierung des Meldungstyps
den
Anwender auf die Situa2. Alle Informationen zur
tion ein. Andererseits schließt mancher
Problemlösung vorhanden?
Anwender beim Erkennen des Symbols
Um aus einer Fehlersituation herauszu- (meist ein „i“ oder ein „Warndreieck“)
kommen, falls überhaupt Chancen be- das Meldungsfenster, ohne die Melstehen, benötigt der Anwender gezielte dung zu lesen – negative Folgen nicht
Informationen. Bei Fehlermeldungen ausgeschlossen. Eine klare Darstellung
sind das: Fehlerbeschreibung, Fehler- des Meldungstyps durch Symbole oder
Signalwörter ist sinnvoll. Nicht nur aus
ursachen, Fehlerbehebung.
Aus der einfachen und verständli- psychologischen Gründen, sondern
chen Beschreibung des Fehlers und sei- auch wegen der Anwender, die diese
ner Ursachen lernt der Anwender, seine Klassifikation gewohnt sind.
Allerdings ist kritisch anzumerken,
Aktionen an die Möglichkeiten der Anwendung anzupassen. Die Fehlerbehe- dass die Microsoft-Definitionen teilweibung zeigt sinnvolle Wege auf, um die se Spielraum für Interpretationen lassen,
gestartete Aktion einigermaßen unbe- so dass eine eindeutige Zuordnung mancher Meldung nicht möglich ist. So verschadet zu beenden.
wundert es auch nicht, dass besonders
• Ergebnis der Analyse:
Fehlermeldungen oft als Warnmeldun35 Prozent mangelhaft.
gen daherkommen, was den Anwender
letztlich nur verwirrt. Softwarehersteller
Abb. 4: Lapidarer
sollten daher intern präzisere Klassifikageht es wohl
tionsregeln aufstellen, um dem Verwirrkaum.
spiel ein Ende zu setzen. Der Anwender
benötigt lediglich
die drei erwähnten Meldungstypen. Alle feineren
Abstufungen, zum
Abb. 5: Welche Ursache hat dieser Fehler? Wie kann der AnBeispiel nach Fehwender die Aufgabe erfolgreich ausführen?
lerarten, interes-
4. Ist erkennbar,
wo die Meldung herkommt?
Bei der Anzahl der parallel ablaufenden
Programme, viele davon auch noch im
Hintergrund, ist es besonders wichtig
zu wissen, welche Anwendung den Fehler verursacht hat. Wenn der Anwender
Quelle und Ursache kennt, kann er entsprechend reagieren.
• Ergebnis der Analyse: 20 Prozent
mangelhaft.
Abb. 8: Aufgrund
des Textes ist erst
auf den zweiten
Blick erkennbar,
dass es sich eigentlich um eine
Warnmeldung
handelt, die eine
Entscheidung vor
der Ausführung
des Befehls verlangt.
Abb. 9: Nur erfahrene Anwender
erkennen, dass die
Meldung von Windows kommt.
5. Bezieht sich die Meldung
auf das konkrete Ereignis?
Was nützen allgemein formulierte Fehlermeldung, die beispielsweise Microsoft liefert, aber von einem anderen
Hersteller nicht an die konkreten Fehlersituationen seiner Software angepasst werden? Dass es bei unbekannten Fehlern oder bei Fehlern aus dem
Betriebssystem nur eine unspezifische
Meldung gibt, mag noch verständlich
sein. Kein Verständnis gilt aber für die
Tatsache, dass der Anwender bei Softwarefehlern nur die Textkonserve von
Microsoft angezeigt bekommt.
• Ergebnis der Analyse:
13 Prozent mangelhaft.
Abb. 6: Wie ist die Überprüfung durchzuführen? Diese Meldung hilft nicht wirklich
weiter.
3. Meldungstyp erkennbar,
passt er zum Meldungsinhalt?
Eine eindeutige Klassifikation von Meldungen gibt nur Microsoft vor: „Information“, „Warning“ und „Critical“. Der
Softwarehersteller Apple hingegen unterscheidet lediglich den Typ „Alert“ und
verwendet nur gelegentlich das Warndreieck-Symbol. Die Norm 9241 spricht
von „Warnmeldung“, „Sicherheitsabfrage“, „Fehlermeldung“, „Ausführungs-
sieren nur die Programmierer und dürfen
nicht am Bildschirm angezeigt werden.
• Ergebnis der Analyse:
28 Prozent mangelhaft
Abb. 10: Der Prozess und die Datei sollten explizit benannt
werden, denn das Programm „weiß“ genau, welcher Prozess
welche Datei bearbeitet.
Abb. 7: Diese offensichtliche Fehlermeldung (Signalwort „Fehler“) erscheint mit dem hier völlig falschen Symbol für Warnmeldungen und bewirkt, dass der Anwender verwirrt wird.
technische kommunikation 01/07
#5393 tk 01_07.indd 51
51
20.12.2006 14:37:48 Uhr
Online-Hilfe
6. Sind die richtigen
Schaltflächen vorhanden?
Eine anwenderfreundliche Software
wird so weit wie möglich die Arbeit
erleichtern und Lösungen zeigen, um
schnell und einfach den Fehler zu beheben. Wenn schon mögliche Lösungen genannt werden, warum nicht
gleich die dafür geeigneten Schaltflächen bereitstellen, die den Anwender
genau an die Lösungsstelle bringen?
Ein anderer Punkt, der zur Anwenderfreundlichkeit beiträgt, sind Schaltflächen, deren Bezeichnung beziehungsweise Funktion eindeutig ist.
Ansonsten kann der Anwender das
Risiko der Aktion nicht abschätzen
und ist verunsichert.
• Ergebnis der Analyse:
10 Prozent mangelhaft
•
Abb. 12: So haben die Anwender zumindest eine Wahlmöglichkeit …
Fazit
•
•
Wenn Sie Fehlermeldungen erstellen
müssen, berücksichtigen Sie folgende
Kriterien:
• Der Meldungstext muss verständlich und sinnvoll sein.
• Für die Lösung des Problems müssen alle notwendigen Informationen
vorhanden sein.
• Der Meldungstyp muss erkennbar
sein und zum Meldungsinhalt passen.
Abb. 11: Abgesehen von den vielen Mängeln
dieser Fehlermeldung ist hier die Schaltfläche
„Abbrechen“ falsch. „Abbrechen“ hat die Funktion, die Aktion abzubrechen und den Zustand vor
der Meldung wieder herzustellen, was bei diesem
Programmabsturz unmöglich ist. Richtig wäre die
Schaltfläche „Schließen“, um das Meldungsfenster
zu schließen. Das Fehlerprotokoll würde schon
interessieren, aber wo finden? Hilfreich wäre hier
die Schaltfläche „Protokoll anzeigen“.
•
Die Fehlerquelle – das Programm,
das die Meldung generiert hat –
muss erkennbar sein.
Die Fehlermeldung muss sich genau
auf das konkrete Ereignis beziehen.
Zur Lösung des Problems müssen
aus dem Meldungsfenster die nötigen Aktionen gestartet werden können.
Für jede ausführbare Aktion muss
die richtige Schaltfläche vorhanden
sein.
Alle Elemente einer Fehlermeldung
müssen ein in sich stimmiges Ganzes bilden.
Autorenanschrift
Johann Olasz
Technik & Dokumentation
[email protected]
www.technischedok.de
Testen Sie die Qualität von Fehlermeldungen
Kleine Checkliste nach DIN EN ISO 9241
Prüffragen
Erfüllungsgrad der Anforderung
Vollständig
Weitgehend
Zum Teil
Kaum/nicht
Sind die Fehlermeldungen hilfreich?
Sind die Fehlermeldungen verständlich?
Sind Fehlermeldungen einheitlich nach denselben Regeln aufgebaut?
Sind die Meldungstexte grammatisch einheitlich formuliert?
Sind die Formulierungen in Meldungen den kulturellen Gegebenheiten angepasst?
Enthält die Fehlerbeschreibung alle notwendigen Informationen, damit der Anwender den
Fehler korrigieren kann?
Sind die Informationen zur Fehlerkorrektur so präzise, dass nur eine Korrekturmöglichkeit in
Frage kommt?
Falls das System die Fehlerursache nicht eindeutig feststellen kann, werden alle in Frage kommenden Fehlerursachen angegeben?
Falls keine ausführliche Fehlermeldung möglich ist, kann der Anwender Zusatzinformationen
abrufen?
Hilft das Programm, eine Fehlersituation so zu beheben, dass das Arbeitsziel trotzdem erreicht
wird?
Ist der Aufwand für die Fehlerkorrektur im Allgemeinen gering?
Ist die Gestaltung der Fehlermeldungen immer gleich?
52
01/07 technische kommunikation
#5393 tk 01_07.indd 52
20.12.2006 14:37:50 Uhr

Download Report