Benutzerfreundlichkeit in der Praxis
Wenn etwas schiefgeht
Dr. Charles Kreitzberg und Ambrose Little
Codedownload verfügbar in der MSDN-Codegalerie
Code online durchsuchen
Inhalt
Die Herausforderung der Benutzerfreundlichkeit
Fehlermeldungen sind wichtig
Wichtige Fragen in der Entwurfsphase
Formatieren von Fehlermeldungen
Programmierverfahren
Konsistente Verarbeitung
Eine wohlformulierte Fehlermeldung
Frameworks
Anpassen von Ausnahmen (mit Enterprise Library)
Charles Kreitzberg
DIE HERAUSFORDERUNG DER BENUTZERFREUNDLICHKEIT
Aus Sicht der Benutzerfreundlichkeit sind Fehlermeldungen oft wahre Albträume. Etwas ist mit dem Programm schiefgegangen, und der Benutzer muss entscheiden, was nun zu tun ist. Im Idealfall gibt das Programm eine Fehlermeldung aus, um dem Benutzer mitzuteilen, was schiefgegangen ist und wie das Problem korrigiert werden kann. Leider ist dies bei vielen Fehlermeldungen nicht der Fall.
Betrachten Sie die Meldung in Abbildung 1, die auf meinem PC kurz nach der Startsequenz angezeigt wurde. Stellen Sie sich die Auswirkungen dieser Meldung auf einen technisch nicht versierten Benutzer vor, der keine Ahnung hat, wo das Problem liegt. Die Meldung impliziert, dass die Sicherheit beeinträchtigt wurde und die Lage prekär ist. Eigentlich war die Situation gar nicht so schlimm. Ich konnte als Fehlerursache später meine Videobearbeitungssoftware identifizieren, und alles lief daraufhin glatt. Aber es ist beeindruckend, wie viele Entwurfsmängel in dieser Meldung enthalten sind:
- Es gibt keinen Hinweis, welches Programm die Fehlermeldung erzeugt hat.
- Die Meldung erläutert nicht, warum das Programm beendet wird.
- Die Meldung ist sehr allgemein. Sie spricht von „Sicherheitsinformationen“ ohne jeden Hinweis, um welche Informationen es sich handelt.
- Die Meldung zeigt nicht an, wie schwer das Problem ist und ob der Computer des Benutzers gefährdet ist.
- Der Benutzer erhält keine Informationen, wie das Problem korrigiert werden oder wo er Hilfe einholen kann. Er hat lediglich die Möglichkeit, auf „OK“ zu klicken (aber OK ist die Lage sicherlich nicht).
Abbildung 1 Das klingt überaus ernst
Abbildung 2 Was ist, wenn ich nicht zu Hause bin, wenn Windows mich kontaktiert?
Niemand ist davor gefeit, schlechte Fehlermeldungen zu schreiben. Sogar Microsoft, ein Unternehmen, das selbst Standards dazu vorgeschlagen hat, wie gute Meldungen aussehen sollten, produziert gelegentlich Exemplare wie das in Abbildung 2, das ich ab und zu erhalte.
Das Handbuch zur Windows Vista-Benutzerfunktionalität bietet Richtlinien für Fehlermeldungen, die besagen, dass eine gute Fehlermeldung drei Bedingungen erfüllen sollte:
- darauf hinweisen, dass ein Problem besteht
- die Ursache nennen
- eine Lösung bieten, mit der der Benutzer das Problem beheben kann
In den Richtlinien wird außerdem vorgeschlagen, dass eine gute Fehlermeldung wie folgt präsentiert werden sollte:
- Relevant – die Meldung weist auf ein Problem hin, das für den Benutzer von Bedeutung ist.
- Umsetzbar – Benutzer sollten infolge der Meldung entweder eine Aktion durchführen oder ihr Verhalten ändern.
- Benutzerzentriert – die Meldung beschreibt das Problem in Bezug auf Ziele oder beabsichtigte Benutzeraktionen, nicht in Bezug darauf, was dem Code nicht gefällt.
- Kurz – die Meldung ist so kurz wie möglich, aber nicht zu kurz.
- Klar – die Meldung ist in einer einfachen Sprache verfasst, sodass die Zielbenutzer das Problem und die Lösung problemlos verstehen können.
- Spezifisch – die Meldung beschreibt das Problem unter Verwendung spezifischer Sprache und unter Angabe spezifischer Namen, Speicherorte und Werte der betroffenen Objekte.
- Höflich – der Benutzer sollten nicht beschuldigt werden oder das Gefühl bekommen, er sei dumm.
- Selten – Häufig angezeigte Fehlermeldungen sind ein Zeichen für einen schlechten Entwurf.
Die meisten dieser Kriterien werden von der Fehlermeldung in Abbildung 2 nicht erfüllt.
Fehlermeldungen sind wichtig
Da die Effizienz von Endbenutzern außerordentlich wichtig ist, sind gute Fehlermeldungen nicht einfach eine Gefälligkeit. Fehler unterbrechen die Arbeit der Software, verschlechtern die Benutzerfunktionalität und verursachen Kosten. Die Kosten für den Benutzersupport können beträchtlich sein. Gute Fehlermeldungen, die Benutzern ermöglichen, Probleme zu identifizieren und zu korrigieren, helfen möglicherweise dabei, viel Zeit und Geld einzusparen und die Auswirkungen auf die Benutzerfunktionalität zu minimieren. Aber es ist nicht immer einfach, gute Fehlermeldungen zu erstellen.
Definitionsgemäß werden Fehlermeldungen ausgegeben, wenn das Programm einer unerwarteten Situation begegnet. Die Ursache des Problems kann weit von dem Punkt entfernt sein, an dem der Fehler festgestellt wird, und es ist vielleicht unmöglich, die tatsächliche Ursache zu ermitteln. Auch wenn Sie die Umgebung nicht immer kontrollieren können, können Sie die Situation verbessern, indem Sie sich die Zeit nehmen, eine nützliche Meldung zu entwerfen und das technische Problem in benutzerzentrierte und umsetzbare Formulierungen zu fassen.
Wichtige Fragen in der Entwurfsphase
Hier sind einige wichtige benutzerzentrierte Fragen, die Sie berücksichtigen sollten, wenn Sie über den Umgang mit Ausnahmen nachdenken:
An wen wenden Sie sich? Sind es Entwickler, erfahrene Benutzer, gelegentliche Benutzer oder die Öffentlichkeit?
Welche Arten von Ausnahmen werden gemeldet? Wie möchten Sie diese präsentieren?
Welcher Support wird dem Benutzer geboten? Gibt es z. B. Support in Form eines Helpdesk und einer Knowledge Base?
Wie wird dem Benutzer geholfen, die Lage zu bereinigen? Einfach den Benutzer zu benachrichtigen, dass ein Problem aufgetreten ist, ohne eine umsetzbare Möglichkeit zu bieten, das Problem zu beheben, beeinträchtigt unweigerlich die Benutzerfunktionalität.
Benötigen Sie eine Protokollierung auftretender Ausnahmen sowie entsprechende Benachrichtigungen? Wenn dies der Fall ist, müssen Sie möglicherweise erwägen, wie Benutzer oder IT-Mitarbeiter die Protokolle anzeigen, suchen, sortieren, filtern und verwalten sowie das Format und den Inhalt für die Benachrichtigungen festlegen. Die Nutzbarkeit sollte äußerst hoch sein.
Sollten Sie die Ansicht für verschiedene Zielgruppen personalisieren? Wären z. B. eine Entwickleransicht und eine öffentliche Ansicht hilfreich? Führt die Verwendung externer Richtliniendateien zum Steuern der Anzeige zu irgendwelchen Sicherheitslücken?
Können Sie die Benutzerfreundlichkeit Ihrer Meldungen erhöhen? Können Sie die Verknüpfung zu den grundlegenden technischen Informationen beibehalten, indem Sie die Ausnahme in eine neue von Ihnen erstellte Ausnahme einschließen? Sind mit der Weitergabe technischer Informationen über eine Anwendungsgrenze hinweg möglicherweise Sicherheitsrisiken verbunden?
Diese Fragen sollten früh bedacht werden – nicht erst am Ende des Projekts.
Formatieren von Fehlermeldungen
Fehlermeldungen sollten so verständlich, korrekt und umsetzbar wie möglich sein. Bemühen Sie sich, Folgendes zu bieten:
- Eine möglichst vollständige Beschreibung der Situation.
- So viel Kontext wie möglich in einer Form, die der Benutzer versteht.
- Klare Vorschläge für Benutzeraktionen. Helfen Sie dem Benutzer so gut wie möglich bei der Entscheidung, indem Sie sicherstellen, dass er die Auswirkungen jeder Entscheidung versteht.
Hier sind einige Vorschläge, die Ihnen helfen sollen, gute Fehlermeldungen zu erstellen:
Nennen Sie die Ursache Achten Sie darauf, dass Sie die Website oder die Anwendung angeben, die die Fehlermeldung erzeugt hat. Es kann auch nützlich sein, detailliertere Informationen anzuzeigen, die beim Auffinden des Codebereichs behilflich sind, in dem der Fehler aufgetreten ist, aber seien Sie vorsichtig beim Bereitstellen interner Details, da solche Informationen für Angriffe verwendet werden könnten. Trennen Sie zusätzliche Diagnose- und Referenzinformationen von der Hauptmeldung, damit sie dem Endbenutzer nicht zu technisch erscheint. Erwägen Sie die Möglichkeit, Details auf Anfrage anzuzeigen (z. B. in einem reduzierbaren Bereich), damit sich technisch weniger versierte Benutzer nicht mit einer technischen Präsentation herumschlagen müssen.
Verwenden Sie eine einfache Sprache Erklären Sie in einer möglichst untechnischen Sprache, was geschehen ist. Dies kann schwierig sein, weil Sie möglicherweise nicht wissen, was der Benutzer zu tun versuchte, als der Fehler auftrat. Aber je mehr Sie das Problem mit den Aktionen der Benutzer und den betroffenen Daten in Zusammenhang bringen können, desto besser werden die Benutzer das Problem verstehen und möglicherweise entsprechend handeln können. Achten Sie aber auch hier wieder darauf, keine Informationen verfügbar zu machen, die für einen Angriff oder eine Beeinträchtigung des Datenschutzes verwendet werden könnten. Erläutern Sie den Schweregrad des Fehlers und, wenn möglich, die Auswirkungen des Problems.
Bieten Sie Details und Anleitungen Versuchen Sie, bei allgemeinen Ausnahmen wie „HTML-Fehler -500 -Interner Serverfehler“ nach Möglichkeit mehr Details und konkrete Anleitungen bereitzustellen. Erläutern Sie die Aktionen, die der Benutzer durchführen kann, um den Fehler zu beheben, und stellen Sie sicher, dass die Optionen und die Folgen klar sind. Bieten Sie, wenn möglich, einen Link zu weiteren Informationen, die dem Benutzer helfen können, die richtige Entscheidung zu treffen. Wenn die einzige Option darin besteht vorzuschlagen, dass sich der Benutzer an den Support wendet, stellen Sie sicher, dass die Kontaktinformationen korrekt und problemlos aktualisierbar sind.
Geben Sie dem Benutzer Orientierung Wenn Sie eine benutzerdefinierte Fehlerseite in ASP.NET verwenden, integrieren Sie sie visuell in Ihre Website, und bieten Sie Navigationsmöglichkeiten zu verwandten Seiten (oder zumindest zur Homepage). Wenn Sie Benutzer auf eine Website mit zusätzlichen Informationen verweisen, helfen Sie ihnen, die Informationen zu finden, indem Sie sie direkt zur entsprechenden Seite führen.
Ambrose Little
PROGRAMMIERVERFAHREN
Ich denke auch, dass Fehlermeldungen schwierig sein können, und alle Vorschläge von Charles Kreitzberg sind sehr nützlich. Aber wie können diese Vorschläge eigentlich in Ihrem Code implementiert werden?
Zu Programmierzwecken ist es nützlich, Fehlermeldungen in zwei Kategorien einzuteilen. Programmfehler sind Ausnahmen, die im Code aufgrund unvorhergesehener Umstände auftreten. Wenn ein Programmfehler auftritt, gibt es möglicherweise keine andere Option, als das Programm so ordentlich wie möglich zu beenden. Benutzereingaben oder Überprüfungsausnahmen sind Situationen, in denen der Benutzer das Problem möglicherweise beheben kann. Bei dieser Art von Fehler kann eine wohlformulierte Fehlermeldung eine Wiederherstellung ermöglichen. In diesem Artikel liegt der Schwerpunkt auf der ersten Kategorie, den Programmfehlern. Benutzereingaben und Überprüfungsfehler werden ein anderes Mal erörtert.
Konsistente Verarbeitung
Sogar in den am besten geschriebenen Programmen treten Fehler auf. Die beste Möglichkeit, sie zu behandeln, besteht darin, Klassen für Fehlermeldungen zu erstellen, die im gesamten Programm verwendet werden können. Dadurch, dass die gesamte Fehlermeldungsverarbeitung durch einen einzigen Punkt geleitet wird, erreichen Sie Folgendes:
- Es wird sichergestellt, dass alle Meldungen in einem vollständigen und konsistenten Format angezeigt werden.
- Sie können benutzerdefinierte Ausnahmetypen verwenden und eindeutige Fehlercodes für jede Meldung zuweisen, sodass es einfach wird, ein Wörterbuch der Fehlermeldungen zu erstellen, es mit zusätzlichen Informationen zu erweitern und es nach Bedarf zu lokalisieren.
- Sie können Fehlermeldungen gegebenenfalls mit einer Website verknüpfen, die Benutzersupport oder zumindest die Möglichkeit bietet, dass sich Benutzer mit der Fehlermeldung an den Anwendungssupport wenden.
- Sie können Protokolle erstellen, die automatisch oder mit dem Einverständnis der Benutzer an einen Server gesendet werden und dabei helfen, Probleme zu analysieren und die Software zu verbessern.
Eine wohlformulierte Fehlermeldung
Die Dialogfelder in den Abbildungen 3 und 4 zeigen die Elemente einer wohlstrukturierten Fehlermeldung. Wenn die Fehlermeldung einfach ist, können Sie ein Dialogfeld wie das in Abbildung 3 verwenden, das den Windows Vista-Richtlinien entspricht. Diese Fehlermeldung ist am nützlichsten bei einem Fehler, den der Benutzer korrigieren kann. Für einen Programmfehler ist möglicherweise eine umfassendere Meldung als die in Abbildung 4 gezeigte erforderlich.
Abbildung 3 Format einer einfachen Fehlermeldung
Abbildung 4 Meldung für einen komplexeren Fehler
Eine gute Quelle für Informationen zur Behandlung von Ausnahmen ist der Artikel .NET Framework-Entwicklerhandbuch: Entwurfsrichtlinien für Ausnahmen in der MSDN-Bibliothek. Wo Sie schon in der MSDN-Bibliothek sind, lesen Sie den Artikel Anwendungsblock zur Ausnahmebehandlung. Damit können Sie eine Ausnahme umschließen, indem Sie sie in eine von Ihnen erstellte Ausnahme einbetten, die weitere Informationen enthält. Auf diese Weise können zusätzliche Informationen über den Kontext hinzugefügt werden, in dem die Ausnahme aufgetreten ist. Sie können diese Informationen zum Erstellen benutzerzentrierterer Fehlermeldungen verwenden.
Wenn die Sicherheit ein Problem ist und Sie vermeiden möchten, technische Informationen weiterzugeben, können Sie die Ausnahme durch eine benutzerzentriertere ersetzen, statt sie zu umschließen. Abschließend können Sie den Ausnahmebehandlungsblock verwenden, um den Fehler zu protokollieren und Betroffene per E-Mail, über die Windows-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI) oder auf eine andere benutzerdefinierte Weise zu benachrichtigen.
Wenn Sie eine einfache Möglichkeit für ASP.NET zum Protokollieren und zur Berichterstattung suchen, werfen Sie einen Blick auf ELMAH (Error Logging Modules and Handlers). Diese Tools bieten Protokollierung, mehrere Protokollspeicheroptionen, die Möglichkeit, die Protokolle auf einer Webseite anzuzeigen, E-Mail-Funktionen sowie RSS-Benachrichtigungen. Sie können einen ELMAH-Ausnahmehandler für EntLib erstellen, wie z. B. jenen, der auf dotNetTemplar kostenlos verfügbar ist. So erhalten Sie die Infrastruktur von EntLib zusammen mit den Berichterstattungsdiensten von ELMAH.
Wenn Sie Anwendungen für eine Windows XP- oder Windows Vista-Umgebung erstellen, sollten Sie sich den Windows-Fehlerberichterstattungsdienst (Dr. Watson) ansehen. Wenn ein Benutzer Absturzdaten sendet, prüft der Windows-Fehlerberichterstattungsdienst, ob es eine entsprechende Benutzermeldung gibt, und zeigt die Meldung zum Zeitpunkt des Absturzes an.
Obwohl diese Frameworks hervorragende Lösungen zum Verwalten der Ausnahmebehandlung sind, garantiert ihre Verwendung keine Benutzerfreundlichkeit. Sie müssen die Situation nach wie vor aus Sicht des Benutzers betrachten, indem Sie versuchen, die technischen Kenntnisse des Benutzers zu verstehen und eine möglichst klare, korrekte und umsetzbare Präsentation zu schaffen.
Sehen wir uns nun ein Beispiel sowie etwas Beispielcode an, der die bislang diskutierten Konzepte veranschaulicht.
Anpassen von Ausnahmen (mit Enterprise Library)
Im Folgenden wird anhand eines Beispiels beschrieben, wie der Enterprise Library-Ausnahmebehandlungsblock genutzt wird, um Ausnahmen für eine Windows Forms-Anwendung anzupassen. Ein ähnliches Verfahren könnte für andere Microsoft .NET Framework-Benutzeroberflächentechnologien eingesetzt werden.
Zentralisieren Sie zuerst die Ausnahmebehandlung durch eine Art von ExceptionHandling-Klasse (siehe Abbildung 5). Dies ist eine statische Klasse mit Methoden, die direkt definierten Ausnahmerichtlinien in Ihrer Enterprise Library-Konfiguration zugeordnet sind.
Abbildung 5 Die ExceptionHandling-Klasse
public static class ExceptionHandling
{
public static Exception UiUnknown(Exception exception)
{
try
{
if (Microsoft.Practices.EnterpriseLibrary.
ExceptionHandling.ExceptionPolicy
.HandleException(exception, "UiUnknown"))
return exception;
}
catch (Exception ex)
{
return ex;
}
return null;
}
}
Konfigurieren Sie diese Richtlinie im Enterprise Library-Konfigurationstool (siehe Abbildung 6). Geben Sie zwei Typhandler an, ganz so wie in einer try/catch-Anweisung. Es wird der spezifischere Handler ausgewählt. Für beide können Sie zunächst die ausgegebene Ausnahme protokollieren, indem Sie den integrierten XML-Ausnahmeformatierer mit einem XML-Protokollierungsablaufverfolgungslistener verwenden. Für die allgemeine Ausnahme können Sie die Quellausnahme mit einer neuen Ausnahme umschließen, die eine benutzerzentrierte Meldung enthält. Alternativ können Sie sie ersetzen, aber für den Fall, dass die Benutzeroberfläche die Details der eigentlichen Ausnahme benötigt, ist es möglicherweise besser, sie zu umschließen.
Abbildung 6 Das Enterprise Library-Konfigurationstool
Ein wichtiger kleiner Trick, den Sie beim Umschließen oder Ersetzen anwenden müssen, besteht darin, das PostHandlingAction der Ausnahmetypen auf ThrowNewException zu setzen – auf diese Weise wird die neue, umschlossene Ausnahme ausgegeben.
Wenn der Aufrufcode mit der Ausnahme weitere Funktionen erfüllen soll, besteht die andere Option darin, NotifyRethrow auszuwählen, was dazu führt, dass das ExceptionPolicy.HandleException von EntLib den Wert „true“ zurückgibt. Sie werden sehen, dass Sie bei DatabaseConnectivityException die benutzerzentrierten Aspekte in Ihrem benutzerdefinierten Ausnahmetyp behandeln können. Alles, was die vorangegangene Richtlinie dazu beiträgt, ist die Protokollierung sowie die Informationen, dass eine erneute Ausgabe erfolgen sollte.
Vom Aufruf von ExceptionHandling.UiUnknown erhalten Sie die neue, umschlossene Ausnahme, die ursprüngliche Ausnahme oder keine Ausnahme zurück, wenn die Richtlinie sich entscheidet, keine neue auszugeben oder zu einer erneuten Ausgabe aufzufordern. Das ist einer der wichtigsten Vorteile des Ausnahmebehandlungsblocks: Sie können die Richtlinien außerhalb des Anwendungscodes konfigurieren (eine gute Möglichkeit, diesen Querschnittsaspekt aus dem Anwendungscode herauszuhalten). Übergeben Sie dies dann an die ErrorMessage.Show-Methode, die in Abbildung 7 im ErrorMessage-Formular definiert ist.
Abbildung 7 Das ErrorMessage-Formular
public static void Show(Exception relatedException)
{
ErrorMessage em = new ErrorMessage();
if (relatedException == null)
{
em.problemDetailsContainer.Visible = false;
}
else
{
em.problemDescription.Text = relatedException.Message;
IUIExceptionDetail detail =
relatedException as IUIExceptionDetail;
if (detail == null)
{
em.errorCode.Text = "500";
em.problemDetails.Visible = false;
}
else
{
em.errorCode.Text = detail.ErrorCode.ToString();
em.problemDetails.Text = detail.DetailMessage;
}
em.problemType.Text =
em.GetMeaningfulExceptionType(relatedException).Name;
em._SearchText = em.errorCode.Text + " " + em.problemType.Text;
}
em.ShowDialog();
}
Das ErrorMessage-Formular ist ein „freundlicher“ Bildschirm, der Markeninformationen zum Unternehmen und Kontaktinformationen enthält und die Möglichkeit bietet, dem Unternehmen das Problem zu melden und online nach einer Lösung zu suchen.
Wenn keine Ausnahme vorhanden ist, wird der Detailcontainer ausgeblendet, denn dem Benutzer sollte nicht der falsche Eindruck vermittelt werden, dass Details vorhanden sind. (In diesem Fall sollte möglicherweise gar keine Meldung angezeigt werden.) Wenn eine Ausnahme vorliegt, setzen Sie die Problembeschreibung auf die Ausnahmemeldung. Überprüfen Sie dann, ob der Ausnahmetyp die benutzerdefinierte IUIExceptionDetail-Schnittstelle implementiert.
Diese Schnittstelle ermöglicht es Ihnen, dem Benutzer gegebenenfalls auf intelligente Weise sinnvollere Ausnahmeinformationen zu bieten. Die Schnittstelle sieht wie folgt aus:
public interface IUIExceptionDetail
{
int ErrorCode { get; }
string DetailMessage { get; }
}
Damit können Sie benutzerdefinierte, sinnvolle, benutzerzentrierte Ausnahmen erstellen, die Benutzern möglicherweise dabei helfen, die Probleme selbst zu lösen, oder Sie können zumindest einen guten Fehlercode bereitstellen, der als einfacher Verweisschlüssel für die Suche und den Support dient. Die Beispielimplementierung dieser Schnittstelle ist der DataConnectivityException-Typ, der in Abbildung 8 gezeigt wird.
Abbildung 8 DataConnectivityException
public class DatabaseConnectivityException
: Exception, IUIExceptionDetail
{
public DatabaseConnectivityException(Exception innerException)
: base(Resources.Exceptions.DatabaseConnectivityException_Message,
innerException)
{
int.TryParse(
Resources.Exceptions.DatabaseConnectivityException_Code,
out _ErrorCode);
_DetailMessage =
Resources.Exceptions
.DatabaseConnectivityException_DetailMessage;
}
#region IUIExceptionDetail Members
int _ErrorCode;
public int ErrorCode
{
get { return _ErrorCode; }
}
string _DetailMessage;
public string DetailMessage
{
get { return _DetailMessage; }
}
#endregion
}
Der interessanteste Aspekt hierbei ist die Verwendung einer RESX-Datei zum Speichern der Meldung, des Fehlercodes und der Details. Dies ermöglicht die Lokalisierung, dient aber gleichzeitig als nützliche XML-Quelle für Fehlermeldungsdokumentation – Sie könnten problemlos XSLT auf das RESX-Format anwenden, um etwas HTML oder anderes Rich-Text-Markup zu erzeugen.
Möglicherweise bevorzugen Sie diesen Ansatz gegenüber den grundlegenderen Umschließungs-/Ersetzungsfunktionen von EntLib, und das ist in Ordnung – Sie müssen nicht EntLib verwenden, um benutzerzentrierte Meldungen zu bieten, aber es ist dennoch gut, die Ausnahmebehandlung zur Protokollierung in Richtlinien zu externalisieren, und es gibt Ihnen zumindest die Möglichkeit, die Ausnahmebehandlung außerhalb der Anwendung anzupassen.
In der ErrorMessage.Show-Methode können Sie die Überprüfung auf das Vorhandensein der IUIExceptionDetail-Schnittstelle sehen. Wenn sie gefunden wird, zeigt sie dem Benutzer die zusätzlich bereitgestellten Informationen an. Andernfalls wird das Detailfeld ausgeblendet und ein generischer Fehlercode 500 (ähnlich wie HTTP 500) angezeigt.
Das Ergebnis eines generischen/unbekannten Fehlers ist in Abbildung 9 dargestellt. Für einen konkreteren Fehler wie DataConnectivityException erhalten Sie eine Meldung wie in Abbildung 10.
Abbildung 9 Generische Fehlermeldung
Abbildung 10 Konkretere Fehlermeldung
Hierbei sind einige Dinge zu beachten. Dies folgt ziemlich genau den Windows Vista-Richtlinien für Fehlermeldungen. Das Fenster ist ein modales Dialogfeld. Der Dialogfeldtitel teilt dem Benutzer deutlich mit, was den Fehler verursacht, damit er ihn z. B. nicht mit Systemfehlern verwechselt. Dies könnte auch ein spezifisches Feature der Anwendung sein. Es gibt einen auffallenden Indikator für einen Fehler in Form eines großen Symbols, das das Anwendungslogo überlagert. Dies verstärkt zum einen den Hinweis auf die Quelle des Problems und macht zum anderen klar, dass es sich um einen Fehler handelt. Der Titeltext teilt dem Benutzer ebenfalls deutlich mit, dass es ein Problem mit der Anwendung gibt.
Direkt unter dem Titel wird die Ausnahmemeldung angezeigt. Diese sollte kurz und bündig, aber höflich und für den Benutzer gut verständlich sein. Wenn möglich, sollten auch Lösungsmöglichkeiten geboten werden. Im Fall des allgemeinen Fehlers sind Ihnen diese möglicherweise nicht bekannt. Deshalb besteht der beste Ansatz in diesem Fall darin, den Benutzer aufzufordern, den Fehler zu melden oder eine Onlinesuche durchzuführen. Wenn es um die Konnektivität geht, können Sie einige zusätzliche Vorschläge unterbreiten, wenn Sie wahrscheinliche Lösungsmöglichkeiten kennen. Idealerweise sollte der Benutzer hier befähigt werden, das Problem selbst zu beheben, weshalb möglichst konkrete Meldungen allgemeinen Meldungen vorzuziehen sind.
Abbildung 11 „Tell Us About the Problem“ als Schaltfläche
Über den Link „Search for Solutions Online“ (Online nach Lösungen suchen) wird eine Suche gestartet, bei der MSDN Magazin sowie der Fehler und der Ausnahmetyp verwendet werden. Dies ist ein nützliches Feature, da Benutzer möglicherweise nicht wissen, was sie in das Suchfeld eingeben sollen. Wenn ihre Website über einen Benutzersupportbereich verfügt, könnten Sie die Suche auch auf Ihre Website begrenzen. Wenn Sie über einen spezifischen (codebasierten) Suchdienst verfügen, sollten Sie diesen selbstverständlich einer allgemeinen Schlüsselwortsuche vorziehen.
Mit der Schaltfläche „Tell Us About the Problem“ (Teilen Sie uns das Problem mit) sollte das XML-Protokoll an einen Webdienst gesendet werden. Möglicherweise möchten Sie dem Benutzer die Gelegenheit geben, kontextbezogene Hinweise und/oder Kontaktinformationen bereitzustellen, und der Dienst sollte gewisse Nachverfolgungsinformationen zurückgeben, die der Benutzer als Referenz verwenden kann, falls er diesen Dienst in Anspruch nimmt.
Eine alternative Anzeige ist in Abbildung 11 dargestellt. Der Vorteil besteht hier darin, dass „Tell Us About the Problem“ der auffälligste Befehl auf dem Bildschirm ist. Denken Sie beim Benutzeroberflächenentwurf immer daran, den Benutzer basierend auf einer visuellen Hierarchie zu führen. Anders gesagt: Wenn etwas besonders wichtig ist oder Sie, wie in diesem Fall, den Benutzer ermutigen möchten, einen bestimmten Befehl zu verwenden, stellen Sie sicher, dass es sich um das auffälligste und am einfachsten zu verwendende Element handelt. Sie müssen basierend auf dem Kontext entscheiden, welche Aktionen besonders wichtig sind, und dies, wenn es eine Hierarchie gibt, auch visuell vermitteln.
Wenn dies umgesetzt ist, können Sie in der Program.cs-Main-Methode einen Handler auf Anwendungsebene hinzufügen, und zwar folgendermaßen:
Application.ThreadException += Application_ThreadException;
Diese Methode sieht wie folgt aus:
static void Application_ThreadException(object sender,
System.Threading.ThreadExceptionEventArgs e)
{
ErrorMessage.Show(ExceptionHandling.UiUnknown(e.Exception));
}
Damit werden alle unerwarteten Benutzeroberflächenausnahmen aufgefangen und durch die „UiUnknown“-Richtlinie an Ihre zentralisierte Ausnahmehandlerklasse weitergeleitet, die in diesem Beispiel die Behandlung an Enterprise Library delegiert, obwohl es sich auch um ein beliebiges anderes Ausnahmebehandlungsframework handeln könnte. Diese Methode gibt möglicherweise eine Ausnahme zurück, die über das benutzerfreundlichere ErrorMessage-Formular angezeigt wird, das Sie entworfen haben. Selbstverständlich können Sie einen ähnlichen Ansatz für spezifischere Ausnahmerichtlinien in Ihrer gesamten Anwendung verwenden.
Wie Sie sehen, ist das Erstellen guter Fehlermeldungen nicht einfach, aber sich die Zeit zu nehmen, sie sorgfältig zu strukturieren, kann Benutzern sehr viel Arbeit ersparen und Unzufriedenheit vorbeugen.
Dr. Charles Kreitzberg ist CEO der Cognetics Corporation, die Beratung rund um das Thema Benutzerfreundlichkeit sowie Dienstleistungen im Bereich des Entwurfs der Benutzerfunktionalität anbietet. Seine Leidenschaft ist die Erstellung intuitiver Oberflächen, die die Benutzer ansprechen und begeistern und gleichzeitig die Geschäftsziele für das Produkt unterstützen. Charles Kreitzberg lebt in Central New Jersey, wo er in seiner Freizeit auch als Musiker auftritt.
Ambrose Little lebt mit seiner Ehefrau und vier Kindern in Central New Jersey. Er entwirft und entwickelt seit mehr als 10 Jahren Software und fühlt sich geehrt, ein INETA-Sprecher und Microsoft MVP zu sein. Vor kurzem ist er vom technischen Entwurf zum benutzerorientierten Entwurf gewechselt und ist jetzt als Designer von Benutzerfunktionalität für Infragistics tätig.