Fehlermeldungen in Windows 7

Hinweis

Dieses Entwurfshandbuch wurde für Windows 7 erstellt und wurde nicht für neuere Versionen von Windows aktualisiert. Ein Großteil der Anleitungen gilt immer noch grundsätzlich, aber die Präsentation und die Beispiele spiegeln nicht unsere aktuellen Entwurfsanleitungen wider.

Fehlermeldungen in Windows 7 warnen Benutzer auf bereits aufgetretene Probleme. Im Gegensatz dazu warnen Warnmeldungen Benutzer auf Bedingungen, die in Zukunft Probleme verursachen könnten. Fehlermeldungen können über modale Dialogfelder, direkte Nachrichten, Benachrichtigungen oder Ballons angezeigt werden.

Eine typische modale Fehlermeldung.

Effektive Fehlermeldungen informieren Benutzer darüber, dass ein Problem aufgetreten ist, erklären, warum es aufgetreten ist, und bieten eine Lösung, damit Benutzer das Problem beheben können. Benutzer sollten entweder eine Aktion ausführen oder ihr Verhalten als Ergebnis einer Fehlermeldung ändern.

Gut geschriebene, hilfreiche Fehlermeldungen sind entscheidend für eine hochwertige Benutzererfahrung. Schlecht geschriebene Fehlermeldungen führen zu einer geringen Produktzufriedenheit und sind eine führende Ursache für vermeidbare technische Supportkosten. Unnötige Fehlermeldungen unterbrechen den Benutzerfluss.

Hinweis: Richtlinien im Zusammenhang mit Dialogfeldern, Warnmeldungen, Bestätigungen, Standardsymbolen, Benachrichtigungen und Layout werden in separaten Artikeln dargestellt.

Ist dies die richtige Benutzeroberfläche?

Orientieren Sie sich an folgenden Fragen:

• Stellt die Benutzeroberfläche ein Bereits aufgetretenes Problem dar? Andernfalls ist die Meldung kein Fehler. Wenn der Benutzer über eine Bedingung benachrichtigt wird, die in Zukunft ein Problem verursachen könnte, verwenden Sie eine Warnmeldung.
• Kann das Problem verhindert werden, ohne Verwirrung zu verursachen? Wenn ja, verhindern Sie stattdessen das Problem. Verwenden Sie beispielsweise Steuerelemente, die auf gültige Werte beschränkt sind, anstatt nicht eingeschränkte Steuerelemente zu verwenden, die möglicherweise Fehlermeldungen erfordern. Außerdem würde das Deaktivieren von Steuerelementen beim Klicken zu einem Fehler führen, solange offensichtlich ist, warum das Steuerelement deaktiviert ist.
• Kann das Problem automatisch behoben werden? Wenn ja, behandeln Sie das Problem, und unterdrücken Sie die Fehlermeldung.
• Führen Benutzer wahrscheinlich eine Aktion aus oder ändern ihr Verhalten als Ergebnis der Nachricht? Andernfalls rechtfertigt die Bedingung nicht die Unterbrechung des Benutzers, daher ist es besser, den Fehler zu unterdrücken.
• Ist das Problem relevant, wenn Benutzer aktiv andere Programme verwenden? Wenn ja, sollten Sie das Problem mithilfe eines Benachrichtigungsbereichssymbols anzeigen.
• Hängt das Problem nicht mit der aktuellen Benutzeraktivität zusammen, erfordert es keine sofortige Benutzeraktion und kann es von Benutzern frei ignoriert werden? Wenn ja, verwenden Sie stattdessen eine Aktionsfehlerbenachrichtigung .
• Bezieht sich das Problem auf die status einer Hintergrundaufgabe innerhalb eines primären Fensters? Wenn ja, sollten Sie das Problem mithilfe eines status anzeigen.
• Sind die primären Zielbenutzer IT-Experten? Wenn ja, sollten Sie einen alternativen Feedbackmechanismus verwenden, z. B. Protokolldateieinträge oder E-Mail-Warnungen. IT-Experten bevorzugen dringend Protokolldateien für nicht kritische Informationen.

Entwurfskonzepte

Die Merkmale schlechter Fehlermeldungen

Es sollte nicht überraschen, dass es viele lästige, nicht hilfreiche und schlecht geschriebene Fehlermeldungen gibt. Und da Fehlermeldungen häufig über modale Dialoge angezeigt werden, unterbrechen sie die aktuelle Aktivität des Benutzers und fordern, bestätigt zu werden, bevor der Benutzer fortfahren kann.

Ein Teil des Problems ist, dass es so viele Möglichkeiten gibt, es falsch zu machen. Sehen Sie sich die folgenden Beispiele aus der Fehlermeldungshalle der Schande an:

Unnötige Fehlermeldungen

Falsch:

Dieses Beispiel von Windows XP ist möglicherweise die schlechteste Fehlermeldung überhaupt. Es gibt an, dass ein Programm nicht gestartet werden konnte, weil Windows selbst gerade heruntergefahren wird. Es gibt nichts, was der Benutzer dagegen tun kann oder sogar tun möchte (der Benutzer hat sich schließlich dafür entschieden, Windows herunterzufahren). Und durch die Anzeige dieser Fehlermeldung verhindert Windows das Herunterfahren!

Das Problem: Die Fehlermeldung selbst ist das Problem. Abgesehen vom Schließen der Fehlermeldung gibt es für Benutzer nichts zu tun.

Führende Ursache: Melden aller Fehlerfälle, unabhängig von den Zielen oder Sichtweisen der Benutzer.

Empfohlene Alternative: Melden Sie keine Fehler, die Benutzern nicht wichtig sind.

Fehlermeldungen "Erfolg"

Falsch:

Diese Fehlermeldung resultierte aus der Entscheidung des Benutzers, Windows nicht sofort nach dem Entfernen des Programms neu zu starten. Die Programmentfernung war aus Sicht des Benutzers erfolgreich.

Das Problem: Aus Sicht des Benutzers liegt kein Fehler vor. Abgesehen vom Schließen der Fehlermeldung gibt es für Benutzer nichts zu tun.

Führende Ursache: Die Aufgabe wurde aus Sicht des Benutzers erfolgreich abgeschlossen, aber aus Sicht des Deinstallationsprogramms ist ein Fehler aufgetreten.

Empfohlene Alternative: Melden Sie keine Fehler für Bedingungen, die Benutzer für akzeptabel halten.

Völlig nutzlose Fehlermeldungen

Falsch:

Benutzer erfahren, dass es einen Fehler gab, haben aber keine Ahnung, was der Fehler war oder was sie dagegen tun sollen. Und nein, es ist nicht in Ordnung!

Das Problem: Die Fehlermeldung weist kein bestimmtes Problem auf, und benutzer können nichts dagegen tun.

Führende Ursache: Höchstwahrscheinlich weist das Programm eine schlechte Fehlerbehandlung auf.

Empfohlene Alternative: Entwerfen Sie eine gute Fehlerbehandlung im Programm.

Unverständliche Fehlermeldungen

Falsch:

In diesem Beispiel ist die Problemaussage klar, aber die zusätzliche Erklärung ist völlig verblüffend.

Das Problem: Die Problembeschreibung oder -lösung ist unverständlich.

Führende Ursache: Erläutert das Problem aus der Sicht des Codes anstelle des Benutzers.

Empfohlene Alternative: Schreiben Sie Fehlermeldungstext, den Ihre Zielbenutzer leicht verstehen können. Stellen Sie Lösungen bereit, die Benutzer tatsächlich ausführen können. Entwerfen Sie die Fehlermeldungsoberfläche Ihres Programms, ohne dass Programmierer Fehlermeldungen vor Ort verfassen.

Fehlermeldungen, die überlasten

Falsch:

In diesem Beispiel versucht die Fehlermeldung anscheinend, jeden Problembehandlungsschritt zu erläutern.

Das Problem: Zu viele Informationen.

Führende Ursache: Geben Sie zu viele Details an oder versuchen Sie, einen komplizierten Problembehandlungsprozess in einer Fehlermeldung zu erklären.

Empfohlene Alternative: Vermeiden Sie unnötige Details. Vermeiden Sie außerdem Problembehandlungen. Wenn eine Problembehandlung erforderlich ist, konzentrieren Sie sich auf die wahrscheinlichsten Lösungen, und erläutern Sie den Rest, indem Sie auf das entsprechende Thema in der Hilfe verlinken.

Unnötig harte Fehlermeldungen

Falsch:

Die Unfähigkeit des Programms, ein Objekt zu finden, klingt kaum katastrophal. Und angenommen, es ist katastrophal, warum ist die Antwort in Ordnung?

Das Problem: Der Ton des Programms ist unnötig hart oder dramatisch.

Führende Ursache: Das Problem ist auf einen Fehler zurückzuführen, der aus Sicht des Programms katastrophal erscheint.

Empfohlene Alternative: Wählen Sie die Sprache sorgfältig basierend auf dem Standpunkt des Benutzers aus.

Fehlermeldungen, die Benutzer Blame

Falsch:

Warum fühlen sich Benutzer wie ein Krimineller?

Das Problem: Die Fehlermeldung wird so formuliert, dass der Benutzer einen Fehler vorwirft.

Führende Ursache: Unempfindliche Ausdrücke, die sich auf das Verhalten des Benutzers und nicht auf das Problem konzentrieren.

Empfohlene Alternative: Konzentrieren Sie sich auf das Problem, nicht auf die Benutzeraktion, die zu dem Problem geführt hat, und verwenden Sie nach Bedarf die passive Stimme.

Dumme Fehlermeldungen

Falsch:

In diesem Beispiel ist die Problemaussage ziemlich ironisch, und es werden keine Lösungen bereitgestellt.

Das Problem: Fehlermeldungsanweisungen, die dumm oder nicht sequitors sind.

Führende Ursache: Erstellen von Fehlermeldungen, ohne auf deren Kontext zu achten.

Empfohlene Alternative: Lassen Sie Ihre Fehlermeldungen von einem Writer erstellen und überprüfen. Berücksichtigen Sie beim Überprüfen der Fehler den Kontext und den Geisteszustand des Benutzers.

Fehlermeldungen des Programmierers

Falsch:

In diesem Beispiel gibt die Fehlermeldung an, dass ein Fehler im Programm vorliegt. Diese Fehlermeldung hat nur Bedeutung für den Programmierer.

Das Problem: Nachrichten, die den Entwicklern des Programms helfen sollen, Fehler zu finden, werden in der Releaseversion des Programms verbleiben. Diese Fehlermeldungen haben für Benutzer keine Bedeutung oder keinen Wert.

Führende Ursache: Programmierer, die die normale Benutzeroberfläche verwenden, um Nachrichten für sich selbst zu erstellen.

Empfohlene Alternative: Entwickler müssen alle diese Meldungen bedingt kompilieren, sodass sie automatisch aus der Releaseversion eines Produkts entfernt werden. Verschwenden Sie keine Zeit mit dem Versuch, solche Fehler für benutzer verständlich zu machen, da ihr einziges Publikum die Programmierer sind.

Schlecht dargestellte Fehlermeldungen

Falsch:

Dieses Beispiel weist viele häufige Darstellungsfehler auf.

Das Problem: Fehler beim Abrufen aller Details in der Fehlermeldungsdarstellung.

Führende Ursache: Die Richtlinien für Fehlermeldungen nicht kennen und anwenden. Verwenden Sie keine Writer und Editoren, um die Fehlermeldungen zu erstellen und zu überprüfen.

Die Art der Fehlerbehandlung ist so, dass viele dieser Fehler sehr einfach zu machen sind. Es ist beunruhigend zu erkennen, dass die meisten Fehlermeldungen Nominierte für die Halle der Schande sein könnten.

Die Merkmale guter Fehlermeldungen

Im Gegensatz zu den vorherigen schlechten Beispielen haben gute Fehlermeldungen Folgendes:

• Ein Problem. Gibt an, dass ein Problem aufgetreten ist.
• Eine Ursache. Erläutert, warum das Problem aufgetreten ist.
• Projektmappe Stellt eine Lösung bereit, damit Benutzer das Problem beheben können.

Darüber hinaus werden gute Fehlermeldungen wie folgt dargestellt:

• Relevanten. Die Meldung stellt ein Problem dar, das Benutzern wichtig ist.
• Umsetzbare. Benutzer sollten entweder eine Aktion ausführen oder ihr Verhalten als Ergebnis der Nachricht ändern.
• Benutzerzentriert. In der Meldung wird das Problem in Bezug auf Die Aktionen oder Ziele des Zielbenutzers beschrieben, nicht im Hinblick darauf, womit der Code unzufrieden ist.
• Kurze. Die Nachricht ist so kurz wie möglich, aber nicht kürzer.
• „Löschen“. Die Nachricht verwendet eine einfache Sprache, damit die Zielbenutzer das Problem und die Lösung leicht verstehen können.
• Sie müssen speziell sein. In der Meldung wird das Problem mithilfe einer bestimmten Sprache beschrieben, wobei bestimmte Namen, Speicherorte und Werte der beteiligten Objekte angegeben werden.
• Höflich. Benutzer sollten nicht beschuldigt oder dazu gebracht werden, sich dumm zu fühlen.
• Selten. Wird selten angezeigt. Häufig angezeigte Fehlermeldungen sind ein Zeichen für einen fehlerhaften Entwurf.

Indem Sie Ihre Fehlerbehandlung so gestalten, dass sie diese Merkmale aufweist, können Sie die Fehlermeldungen Ihres Programms aus der Fehlermeldungshalle der Schande heraushalten.

Vermeiden unnötiger Fehlermeldungen

Häufig ist die beste Fehlermeldung keine Fehlermeldung. Viele Fehler können durch einen besseren Entwurf vermieden werden, und es gibt oft bessere Alternativen zu Fehlermeldungen. Es ist in der Regel besser, einen Fehler zu verhindern, als einen zu melden.

Die offensichtlichsten Fehlermeldungen, die vermieden werden sollten, sind solche, die nicht umsetzbar sind. Wenn Benutzer die Nachricht wahrscheinlich verwerfen, ohne etwas zu tun oder zu ändern, lassen Sie die Fehlermeldung aus.

Einige Fehlermeldungen können eliminiert werden, da sie aus Sicht des Benutzers keine Probleme sind. Angenommen, der Benutzer hat versucht, eine Datei zu löschen, die bereits gelöscht wird. Obwohl dies aus Der Sicht des Codes ein unerwarteter Fall sein kann, betrachten Benutzer dies nicht als Fehler, da ihr gewünschtes Ergebnis erreicht wird.

Falsch:

Diese Fehlermeldung sollte gelöscht werden, da die Aktion aus Sicht des Benutzers erfolgreich war.

Angenommen, der Benutzer bricht eine Aufgabe explizit ab. Aus Sicht des Benutzers ist die folgende Bedingung kein Fehler.

Falsch:

Diese Fehlermeldung sollte ebenfalls gelöscht werden, da die Aktion aus Sicht des Benutzers erfolgreich war.

Manchmal können Fehlermeldungen vermieden werden, indem sie sich auf die Ziele der Benutzer anstatt auf die Technologie konzentrieren. Überlegen Sie dabei, was ein Fehler wirklich ist. Liegt das Problem mit den Zielen des Benutzers oder mit der Fähigkeit Ihres Programms, diese zu erfüllen? Wenn die Aktion des Benutzers in der realen Welt sinnvoll ist, sollte dies auch in der Software sinnvoll sein.

Angenommen, in einem E-Commerce-Programm versucht ein Benutzer, ein Produkt mithilfe der Suche zu finden, aber die literale Suchabfrage hat keine Übereinstimmungen, und das gewünschte Produkt ist nicht auf Lager. Technisch gesehen ist dies ein Fehler, aber anstatt eine Fehlermeldung zu geben, könnte das Programm:

• Suchen Sie weiterhin nach Produkten, die der Abfrage am ehesten entsprechen.
• Wenn die Suche offensichtliche Fehler aufweist, empfehlen Sie automatisch eine korrigierte Abfrage.
• Behandeln Sie häufig auftretende Probleme wie Rechtschreibfehler, alternative Schreibweisen und nicht übereinstimmende Pluralisierungen und Verbfälle automatisch.
• Geben Sie an, wann das Produkt auf Lager sein wird.

Solange die Anfrage des Benutzers angemessen ist, sollte ein gut konzipiertes E-Commerce-Programm angemessene Ergebnisse und keine Fehler liefern.

Eine weitere hervorragende Möglichkeit, Fehlermeldungen zu vermeiden, besteht darin, Probleme überhaupt zu vermeiden. Sie können Fehler verhindern, indem Sie:

• Verwenden von eingeschränkten Steuerelementen. Verwenden Sie Steuerelemente, die auf gültige Werte beschränkt sind. Steuerelemente wie Listen, Schieberegler, Kontrollkästchen, Optionsfelder sowie Datums- und Uhrzeitauswahlen sind auf gültige Werte beschränkt, während Textfelder häufig nicht sind und Fehlermeldungen erfordern. Sie können Jedoch Textfelder einschränken, um nur bestimmte Zeichen zu akzeptieren und eine maximale Anzahl von Zeichen zu akzeptieren.
• Verwenden von eingeschränkten Interaktionen. Bei Ziehvorgängen können Benutzer nur auf gültige Ziele ablegen.
• Verwenden von deaktivierten Steuerelementen und Menüelementen. Deaktivieren Sie Steuerelemente und Menüelemente, wenn Benutzer leicht ableiten können, warum das Steuerelement oder Menüelement deaktiviert ist.
• Bereitstellen guter Standardwerte. Benutzer machen weniger wahrscheinlich Eingabefehler, wenn sie die Standardwerte akzeptieren können. Auch wenn Benutzer sich entscheiden, den Wert zu ändern, informiert der Standardwert benutzer über das erwartete Eingabeformat.
• Dinge einfach funktionieren lassen. Benutzer machen weniger Fehler, wenn die Aufgaben für sie unnötig oder automatisch ausgeführt werden. Oder wenn Benutzer kleine Fehler machen, aber ihre Absicht klar ist, wird das Problem automatisch behoben. Beispielsweise können Sie kleinere Formatierungsprobleme automatisch korrigieren.

Bereitstellen der erforderlichen Fehlermeldungen

Manchmal müssen Sie wirklich eine Fehlermeldung angeben. Benutzer machen Fehler, Netzwerke und Geräte funktionieren nicht mehr, Objekte können nicht gefunden oder geändert werden, Aufgaben können nicht abgeschlossen werden, und Programme weisen Fehler auf. Im Idealfall würden diese Probleme weniger häufig auftreten, z. B. können wir unsere Software so entwerfen, dass viele Arten von Benutzerfehlern verhindert werden, aber es ist nicht realistisch, all diese Probleme zu verhindern. Und wenn eines dieser Probleme auftritt, bringt eine hilfreiche Fehlermeldung die Benutzer schnell wieder auf die Beine.

Eine gängige Meinung ist, dass Fehlermeldungen die schlechteste Benutzererfahrung sind und um jeden Preis vermieden werden sollten, aber es ist genauer zu sagen, dass Benutzerverwirrung die schlechteste Erfahrung ist und um jeden Preis vermieden werden sollte. Manchmal sind diese Kosten eine hilfreiche Fehlermeldung.

Betrachten Sie deaktivierte Steuerelemente. Meistens ist es offensichtlich, warum ein Steuerelement deaktiviert ist. Daher ist das Deaktivieren des Steuerelements eine gute Möglichkeit, eine Fehlermeldung zu vermeiden. Was ist jedoch, wenn der Grund für die Deaktivierung eines Steuerelements nicht offensichtlich ist? Der Benutzer kann nicht fortfahren, und es gibt kein Feedback, um das Problem zu ermitteln. Nun bleibt der Benutzer hängen und muss entweder das Problem ableiten oder technischen Support erhalten. In solchen Fällen ist es viel besser, das Steuerelement aktiviert zu lassen und stattdessen eine hilfreiche Fehlermeldung zu geben.

Falsch:

Warum ist die Schaltfläche Weiter hier deaktiviert? Besser, sie aktiviert zu lassen und Benutzerverwechslungen zu vermeiden, indem Sie eine hilfreiche Fehlermeldung geben.

Wenn Sie nicht sicher sind, ob Sie eine Fehlermeldung geben sollten, erstellen Sie zunächst die Fehlermeldung, die Sie möglicherweise geben. Wenn Benutzer wahrscheinlich entweder eine Aktion ausführen oder ihr Verhalten ändern, geben Sie die Fehlermeldung an. Wenn Benutzer die Nachricht dagegen wahrscheinlich schließen, ohne etwas zu tun oder zu ändern, lassen Sie die Fehlermeldung aus.

Entwerfen für eine gute Fehlerbehandlung

Das Erstellen eines guten Fehlermeldungstextes kann zwar schwierig sein, aber manchmal ist es ohne eine gute Unterstützung für die Fehlerbehandlung durch das Programm nicht möglich. Beachten Sie die folgende Fehlermeldung:

Falsch:

Wahrscheinlich ist das Problem wirklich unbekannt, da die Unterstützung für die Fehlerbehandlung des Programms fehlt.

Es ist zwar möglich, dass dies eine sehr schlecht geschriebene Fehlermeldung ist, aber es spiegelt eher die fehlende gute Fehlerbehandlung durch den zugrunde liegenden Code wider, da keine spezifischen Informationen über das Problem bekannt sind.

Um bestimmte, umsetzbare, benutzerzentrierte Fehlermeldungen zu erstellen, muss der Fehlerbehandlungscode Ihres Programms spezifische allgemeine Fehlerinformationen bereitstellen:

• Jedem Problem sollte ein eindeutiger Fehlercode zugewiesen sein.
• Wenn ein Problem mehrere Ursachen hat, sollte das Programm nach Möglichkeit die spezifische Ursache ermitteln.
• Wenn das Problem Parameter aufweist, müssen die Parameter beibehalten werden.
• Probleme auf niedriger Ebene müssen auf einem ausreichend hohen Niveau behandelt werden, damit die Fehlermeldung aus Sicht des Benutzers angezeigt werden kann.

Gute Fehlermeldungen sind nicht nur ein Problem der Benutzeroberfläche, sie sind ein Softwareentwurfsproblem. Eine gute Fehlermeldungserfahrung ist nicht etwas, das später angeheftet werden kann.

Problembehandlung (und wie sie vermieden werden kann)

Die Problembehandlung tritt auf, wenn ein Problem mit verschiedenen Ursachen mit einer einzelnen Fehlermeldung gemeldet wird.

Falsch:

Richtig:

Die Problembehandlung erfolgt, wenn mehrere Probleme mit einer einzigen Fehlermeldung gemeldet werden.

Im folgenden Beispiel konnte ein Element nicht verschoben werden, weil es bereits verschoben oder gelöscht wurde oder der Zugriff verweigert wurde. Wenn das Programm die Ursache leicht ermitteln kann, warum die Belastung für den Benutzer, um die spezifische Ursache zu ermitteln?

Falsch:

Nun, was ist es? Nun muss der Benutzer die Problembehandlung durchführen.

Das Programm kann ermitteln, ob der Zugriff verweigert wurde, daher sollte dieses Problem mit einer bestimmten Fehlermeldung gemeldet werden.

Richtig:

Bei einer bestimmten Ursache ist keine Problembehandlung erforderlich.

Verwenden Sie Nachrichten mit mehreren Ursachen nur, wenn die spezifische Ursache nicht ermittelt werden kann. In diesem Beispiel wäre es für das Programm schwierig zu ermitteln, ob das Element verschoben oder gelöscht wurde. Daher kann hier eine einzelne Fehlermeldung mit mehreren Ursachen verwendet werden. Es ist jedoch unwahrscheinlich, dass es Benutzern wichtig ist, wenn sie z. B. eine gelöschte Datei nicht verschieben können. Für diese Ursachen ist die Fehlermeldung nicht einmal erforderlich.

Behandeln unbekannter Fehler

In einigen Fällen kennen Sie das Problem, die Ursache oder die Lösung nicht. Wenn es unklug wäre, den Fehler zu unterdrücken, ist es besser, den Mangel an Informationen im Voraus zu behandeln, als Probleme, Ursachen oder Lösungen zu präsentieren, die möglicherweise nicht richtig sind.

Wenn Ihr Programm beispielsweise über eine nicht behandelte Ausnahme verfügt, ist die folgende Fehlermeldung geeignet:

Wenn Sie einen unbekannten Fehler nicht unterdrücken können, ist es besser, sich im Voraus über den Mangel an Informationen zu informieren.

Stellen Sie andererseits spezifische, umsetzbare Informationen bereit, wenn dies wahrscheinlich die meiste Zeit hilfreich ist.

Diese Fehlermeldung eignet sich für einen unbekannten Fehler, wenn normalerweise netzwerkkonnektivität das Problem ist.

Ermitteln des geeigneten Nachrichtentyps

Einige Probleme können je nach Betonung und Formulierung als Fehler, Warnung oder Information dargestellt werden. Angenommen, eine Webseite kann ein nicht signiertes ActiveX-Steuerelement basierend auf der aktuellen Windows Internet Explorer-Konfiguration nicht laden:

• Fehler. "Diese Seite kann kein nicht signiertes ActiveX-Steuerelement laden." (Als vorhandenes Problem bezeichnet.)
• Warnung. "Diese Seite verhält sich möglicherweise nicht wie erwartet, da Windows Internet Explorer nicht für das Laden von nicht signierten ActiveX-Steuerelementen konfiguriert ist." oder "Zulassen, dass diese Seite ein nicht signiertes ActiveX-Steuerelement installiert? Dies aus nicht vertrauenswürdigen Quellen kann Ihrem Computer schaden." (Beide werden als Bedingungen bezeichnet, die zukünftige Probleme verursachen können.)
• Information "Sie haben Windows Internet Explorer so konfiguriert, dass nicht signierte ActiveX-Steuerelemente blockiert werden." (Als Tatsachenaussage formuliert.)

Um den geeigneten Nachrichtentyp zu bestimmen, konzentrieren Sie sich auf den wichtigsten Aspekt des Problems, den Benutzer kennen oder handeln müssen. Wenn ein Problem den Benutzer daran hindert, fortzufahren, sollten Sie es in der Regel als Fehler darstellen. wenn der Benutzer fortfahren kann, geben Sie dies als Warnung an. Erstellen Sie die Standard Anweisung oder einen anderen entsprechenden Text basierend auf diesem Fokus, und wählen Sie dann ein Symbol (Standard oder anderweitig) aus, das dem Text entspricht. Der Standard Anweisungstext und symbole sollten immer übereinstimmen.

Fehlermeldungsdarstellung

Die meisten Fehlermeldungen in Windows-Programmen werden mithilfe modaler Dialogfelder angezeigt (wie die meisten Beispiele in diesem Artikel), aber es gibt andere Optionen:

• Direkt
• Ballons
• Benachrichtigungen
• Symbole des Benachrichtigungsbereichs
• Statusleisten
• Protokolldateien (für Fehler, die sich an IT-Experten richten)

Das Einfügen von Fehlermeldungen in modale Dialogfelder hat den Vorteil, dass der Benutzer die sofortige Aufmerksamkeit und Bestätigung fordert. Dies ist jedoch auch ihr Hauptnachteil, wenn diese Aufmerksamkeit nicht erforderlich ist.

Müssen Sie Benutzer wirklich unterbrechen, damit sie auf die Schaltfläche Schließen klicken können? Andernfalls sollten Sie Alternativen zur Verwendung eines modale Dialogfelds in Erwägung ziehen.

Modale Dialoge sind eine gute Wahl, wenn der Benutzer das Problem sofort erkennen muss, bevor er fortfährt, aber sonst oft eine schlechte Wahl. Im Allgemeinen sollten Sie lieber die leichteste Präsentation verwenden, die die Arbeit gut macht.

Vermeiden von Überkommunikation

In der Regel lesen Benutzer nicht, sie scannen. Je mehr Text vorhanden ist, desto schwieriger ist der Text zu scannen, und desto wahrscheinlicher werden Benutzer den Text überhaupt nicht lesen. Daher ist es wichtig, den Text auf das Wesentliche zu reduzieren und bei Bedarf progressive Offenlegungs- und Hilfelinks zu verwenden, um zusätzliche Informationen bereitzustellen.

Es gibt viele extreme Beispiele, aber sehen wir uns ein typisches beispiel an. Das folgende Beispiel enthält die meisten Attribute einer guten Fehlermeldung, aber ihr Text ist nicht präzise und erfordert Motivation zum Lesen.

Falsch:

Dieses Beispiel ist eine gute Fehlermeldung, aber es übergibt die Kommunikation.

Was sagt dieser Text wirklich? Ungefähr so wie hier gezeigt:

Richtig:

Diese Fehlermeldung enthält im Wesentlichen die gleichen Informationen, ist aber viel präziser.

Mithilfe der Hilfe zum Bereitstellen der Details weist diese Fehlermeldung eine invertierte Pyramidendarstellung auf.

Weitere Richtlinien und Beispiele zur Überkommunikation finden Sie unter Text der Benutzeroberfläche.

Wenn Sie nur acht Dinge ausführen

1. Entwerfen Sie Ihr Programm für die Fehlerbehandlung.
2. Geben Sie keine unnötigen Fehlermeldungen an.
3. Vermeiden Sie Benutzerverwechslungen, indem Sie erforderliche Fehlermeldungen senden.
4. Stellen Sie sicher, dass die Fehlermeldung ein Problem, eine Ursache und eine Lösung enthält.
5. Stellen Sie sicher, dass die Fehlermeldung relevant, umsetzbar, kurz, klar, spezifisch, höflich und selten ist.
6. Entwerfen Sie Fehlermeldungen aus der Sicht des Benutzers, nicht aus der Sicht des Programms.
7. Vermeiden Sie es, den Benutzer in die Problembehandlung einzubeziehen, und verwenden Sie für jede erkennbare Ursache eine andere Fehlermeldung.
8. Verwenden Sie die leichteste Darstellungsmethode, die die Arbeit gut erledigt.

Verwendungsmuster

Fehlermeldungen weisen mehrere Verwendungsmuster auf:

Bezeichnung	Wert
Systemprobleme Das Betriebssystem, das Hardwaregerät, das Netzwerk oder das Programm ist ausgefallen oder befindet sich nicht in dem Zustand, der zum Ausführen einer Aufgabe erforderlich ist.	Viele Systemprobleme können vom Benutzer gelöst werden: Geräteprobleme können gelöst werden, indem Sie das Gerät einschalten, das Gerät erneut verbinden und Medien einfügen. Netzwerkprobleme können gelöst werden, indem Sie die physische Netzwerkverbindung überprüfen und die Netzwerkdiagnose und -reparatur ausführen. Programmprobleme können gelöst werden, indem Programmoptionen geändert oder das Programm neu gestartet wird. In diesem Beispiel kann das Programm keine Kamera finden, um eine Benutzeraufgabe auszuführen. In diesem Beispiel muss ein Feature aktiviert werden, das zum Ausführen einer Aufgabe erforderlich ist.
Dateiprobleme Eine Datei oder ein Ordner, die für eine vom Benutzer initiierte Aufgabe erforderlich ist, wurde nicht gefunden, wird bereits verwendet oder weist nicht das erwartete Format auf.	In diesem Beispiel kann die Datei oder der Ordner nicht gelöscht werden, da er nicht gefunden wurde. In diesem Beispiel unterstützt das Programm das angegebene Dateiformat nicht.
Sicherheitsprobleme Der Benutzer verfügt nicht über die Berechtigung für den Zugriff auf eine Ressource oder über ausreichende Berechtigungen, um eine vom Benutzer initiierte Aufgabe auszuführen.	In diesem Beispiel verfügt der Benutzer nicht über die Berechtigung für den Zugriff auf eine Ressource. In diesem Beispiel verfügt der Benutzer nicht über die Berechtigung zum Ausführen einer Aufgabe.
Aufgabenprobleme Es liegt ein bestimmtes Problem bei der Ausführung einer vom Benutzer initiierten Aufgabe vor (mit Ausnahme eines Systems, einer nicht gefundenen Datei, eines Dateiformats oder eines Sicherheitsproblems).	In diesem Beispiel können die Zwischenablagedaten nicht in Paint eingefügt werden. In diesem Beispiel kann der Benutzer kein Softwareupgrade installieren.
Benutzereingabeprobleme Der Benutzer hat einen Wert eingegeben, der falsch oder inkonsistent mit anderen Benutzereingaben ist.	In diesem Beispiel hat der Benutzer einen falschen Zeitwert eingegeben. In diesem Beispiel weist die Benutzereingabe nicht das richtige Format auf.

Richtlinien

Präsentation

• Verwenden Sie Aufgabendialoge, wann immer dies angebracht ist , um ein einheitliches Aussehen und Layout zu erzielen. Aufgabendialoge erfordern Windows Vista oder höher, daher sind sie für frühere Versionen von Windows nicht geeignet. Wenn Sie ein Meldungsfeld verwenden müssen, trennen Sie die Standard-Anweisung von der zusätzlichen Anweisung durch zwei Zeilenumbrüche.

Fehler bei der Benutzereingabe

• Verhindern oder reduzieren Sie Nach Möglichkeit Benutzereingabefehler durch:
  • Verwenden von Steuerelementen, die auf gültige Werte beschränkt sind.
  • Das Deaktivieren von Steuerelementen und Menüelementen beim Klicken würde zu einem Fehler führen, solange offensichtlich ist, warum das Steuerelement oder Menüelement deaktiviert ist.
  • Bereitstellen guter Standardwerte.

Falsch:

In diesem Beispiel wird ein uneingeschränktes Textfeld für eingeschränkte Eingaben verwendet. Verwenden Sie stattdessen einen Schieberegler.

• Verwenden Sie die moduslose Fehlerbehandlung (direkte Fehler oder Sprechblasen) für kontextbezogene Benutzereingabeprobleme.
• Verwenden Sie Sprechblasen für nicht kritische Benutzereingabeprobleme mit einem einzelnen Punkt, die während eines Textfelds oder unmittelbar nach dem Verlust des Fokus erkannt wurden.Sprechblasen erfordern keinen verfügbaren Bildschirmbereich oder das dynamische Layout, das zum Anzeigen von in-situ-Nachrichten erforderlich ist. Zeigt jeweils nur einen einzelnen Sprechblasen an. Da das Problem nicht kritisch ist, ist kein Fehlersymbol erforderlich. Sprechblasen verschwinden, wenn sie geklickt werden, wenn das Problem behoben wurde oder nach einem Timeout.

In diesem Beispiel weist eine Sprechblase auf ein Eingabeproblem hin, während sich das Steuerelement noch befindet.

• Verwenden Sie direkte Fehler für verzögerte Fehlererkennung, in der Regel Fehler, die durch Klicken auf eine Commitschaltfläche gefunden werden. (Verwenden Sie keine direkten Fehler für Einstellungen, die sofort committet werden.) Es können mehrere direkte Fehler gleichzeitig auftreten. Verwenden Sie normalen Text und ein Fehlersymbol mit 16 x 16 Pixeln, und platzieren Sie sie nach Möglichkeit direkt neben dem Problem. Direkte Fehler verschwinden nicht, es sei denn, der Benutzer committet, und es werden keine anderen Fehler gefunden.

In diesem Beispiel wird ein direkten Fehler für einen Fehler verwendet, der durch Klicken auf die Schaltfläche "Commit" gefunden wurde.

• Verwenden Sie modale Fehlerbehandlung (Aufgabendialoge oder Meldungsfelder) für alle anderen Probleme, einschließlich Fehlern, die mehrere Steuerelemente betreffen oder nicht kontextbezogene oder nicht eingabebezogene Fehler sind, die durch Klicken auf eine Commitschaltfläche gefunden werden.
• Wenn ein Benutzereingabeproblem gemeldet wird, legen Sie den Eingabefokus auf das erste Steuerelement mit den falschen Daten fest. Scrollen Sie bei Bedarf in die Ansicht des Steuerelements. Wenn das Steuerelement ein Textfeld ist, wählen Sie den gesamten Inhalt aus. Es sollte immer offensichtlich sein, worauf sich die Fehlermeldung bezieht.
• Löschen Sie keine falschen Eingaben. Belassen Sie es stattdessen, damit der Benutzer das Problem sehen und beheben kann, ohne von vorn zu beginnen.
  • Ausnahme: Löschen Sie falsche Kennwörter und PIN-Textfelder, da Benutzer maskierte Eingaben nicht effektiv korrigieren können.

Problembehandlung

• Vermeiden Sie das Erstellen von Problemen bei der Problembehandlung. Verlassen Sie sich nicht auf eine einzelne Fehlermeldung, um ein Problem mit verschiedenen erkennbaren Ursachen zu melden.
• Verwenden Sie für jede erkennbare Ursache eine andere Fehlermeldung (in der Regel eine andere zusätzliche Anweisung). Wenn eine Datei beispielsweise aus mehreren Gründen nicht geöffnet werden kann, geben Sie für jeden Grund eine separate zusätzliche Anweisung an.
• Verwenden Sie eine Nachricht mit mehreren Ursachen nur, wenn die spezifische Ursache nicht ermittelt werden kann. Stellen Sie in diesem Fall die Lösungen in der Reihenfolge der Wahrscheinlichkeit vor, das Problem zu beheben. Auf diese Weise können Benutzer das Problem effizienter lösen.

Symbole

• Modale Fehlermeldungsdialoge verfügen nicht über Titelleistensymbole. Titelleistensymbole werden als visuelle Unterscheidung zwischen primären und sekundären Fenstern verwendet.

• Verwenden Sie ein Fehlersymbol. Ausnahmen:

  • Wenn der Fehler ein Benutzereingabeproblem ist, das mithilfe eines modalen Dialogfelds oder einer Ballon angezeigt wird, verwenden Sie kein Symbol. Dies steht im Widerspruch zu dem ermutigenden Ton von Windows. Direkte Fehlermeldungen sollten jedoch ein kleines Fehlersymbol (16 x 16 Pixel) verwenden, um sie eindeutig als Fehlermeldungen zu identifizieren.

    

    

    In diesen Beispielen benötigen Benutzereingabeprobleme keine Fehlersymbole.

    

    In diesem Beispiel benötigt eine direkte Fehlermeldung ein kleines Fehlersymbol, um sie eindeutig als Fehlermeldung zu identifizieren.

• Wenn es sich bei dem Problem um ein Feature handelt, das ein Symbol (und kein Benutzereingabeproblem) aufweist, können Sie das Featuresymbol mit einer Fehlerüberlagerung verwenden. Verwenden Sie in diesem Fall auch den Featurenamen als Betreff des Fehlers.

  

  In diesem Beispiel weist das Featuresymbol eine Fehlerüberlagerung auf, und das Feature ist der Betreff des Fehlers.

• Verwenden Sie keine Warnungssymbole für Fehler. Dies wird häufig getan, um die Präsentation weniger schwerwiegend zu machen. Fehler sind keine Warnungen.

  Falsch:

  

  In diesem Beispiel wird fälschlicherweise ein Warnsymbol verwendet, um den Fehler weniger schwerwiegend zu machen.

Weitere Richtlinien und Beispiele finden Sie unter Standardsymbole.

Schrittweise Offenlegung

• Verwenden Sie die Schaltfläche Details anzeigen/ausblenden, um erweiterte oder detaillierte Informationen in einer Fehlermeldung auszublenden. Dadurch wird die Fehlermeldung für die typische Verwendung vereinfacht. Blenden Sie die benötigten Informationen nicht aus, da Benutzer sie möglicherweise nicht finden.

In diesem Beispiel hilft die Schaltfläche für die progressive Offenlegung Benutzern bei Bedarf einen Drilldown zu weiteren Details, oder vereinfacht die Benutzeroberfläche, falls dies nicht der Fall ist.

• Verwenden Sie nur Details anzeigen/ausblenden, es sei denn, es gibt wirklich mehr Details. Stellen Sie die vorhandenen Informationen nicht einfach in einem ausführlicheren Format um.
• Verwenden Sie keine Details ein-/ausblenden, um Hilfeinformationen anzuzeigen. Verwenden Sie stattdessen Hilfelinks.

Richtlinien zur Bezeichnung finden Sie unter Progressive Offenlegungssteuerelemente.

Diese Meldung wird nicht erneut angezeigt.

• Wenn eine Fehlermeldung diese Option benötigt, überprüfen Sie den Fehler und seine Häufigkeit. Wenn er alle Merkmale eines guten Fehlers aufweist (relevant, umsetzbar und selten), sollte es für Benutzer nicht sinnvoll sein, ihn zu unterdrücken.

Weitere Richtlinien finden Sie unter Dialogfelder.

Standardwerte

• Wählen Sie die sicherste, am wenigsten destruktive oder die sicherste Antwort aus, um die Standardeinstellung zu sein. Wenn Sicherheit kein Faktor ist, wählen Sie den wahrscheinlichsten oder bequemsten Befehl aus.

Hilfe

• Entwerfen Sie Fehlermeldungen, um die Notwendigkeit von Hilfe zu vermeiden. Normalerweise müssen Benutzer keinen externen Text lesen, um das Problem zu verstehen und zu lösen, es sei denn, die Lösung erfordert mehrere Schritte.
• Stellen Sie sicher, dass der Inhalt der Hilfe relevant und hilfreich ist. Es sollte keine ausführliche Neuauflage der Fehlermeldung sein, sondern nützliche Informationen enthalten, die den Bereich der Fehlermeldung sprengen, z. B. Möglichkeiten, das Problem in Zukunft zu vermeiden. Stellen Sie keinen Hilfelink bereit, nur weil Sie dies können.
• Verwenden Sie spezifische, präzise, relevante Hilfelinks, um auf Hilfeinhalte zuzugreifen. Verwenden Sie zu diesem Zweck keine Befehlsschaltflächen oder progressive Offenlegung.
• Für Fehlermeldungen, die Sie nicht spezifisch und umsetzbar machen können, sollten Sie Links zu Onlinehilfeinhalten bereitstellen. Auf diese Weise können Sie Benutzern zusätzliche Informationen bereitstellen, die Sie nach der Veröffentlichung des Programms aktualisieren können.

Weitere Richtlinien finden Sie unter Hilfe.

Fehlercodes

• Für Fehlermeldungen, die Sie nicht spezifisch und umsetzbar machen können oder die von der Hilfe profitieren, sollten Sie auch Fehlercodes angeben. Benutzer verwenden diese Fehlercodes häufig, um im Internet nach zusätzlichen Informationen zu suchen.
• Geben Sie immer eine Textbeschreibung des Problems und der Lösung an. Hängen Sie zu diesem Zweck nicht nur vom Fehlercode ab.

Falsch:

In diesem Beispiel wird ein Fehlercode als Ersatz für einen Lösungstext verwendet.

• Weisen Sie für jede ursache einen eindeutigen Fehlercode zu. Dadurch wird die Problembehandlung vermieden.
• Wählen Sie Fehlercodes aus, die im Internet leicht durchsuchbar sind. Wenn Sie 32-Bit-Codes verwenden, verwenden Sie eine hexadezimale Darstellung mit einem führenden "0x" und Großbuchstaben.

Richtig:

1234

0xC0001234

Falsch:

-1

-67113524

• Verwenden Sie Details anzeigen/ausblenden, um Fehlercodes anzuzeigen. Ausdruck als Fehlercode: <error code>.

In diesem Beispiel wird ein Fehlercode verwendet, um eine Fehlermeldung zu ergänzen, die von weiteren Informationen profitieren kann.

Sound

• Begleiten Sie Fehlermeldungen nicht mit einem Soundeffekt oder Signalton. Dies ist verstundend und unnötig.
  • Ausnahme: Spielen Sie den Soundeffekt Kritischer Stopp ab, wenn das Problem für den Betrieb des Computers von entscheidender Bedeutung ist und der Benutzer sofort Maßnahmen ergreifen muss, um schwerwiegende Folgen zu vermeiden.

Text

Allgemein

• Entfernen Sie redundanten Text. Suchen Sie in Titeln, Standard Anweisungen, zusätzlichen Anweisungen, Befehlslinks und Commitschaltflächen. Behalten Sie im Allgemeinen Volltext in Anweisungen und interaktiven Steuerelementen bei, und entfernen Sie alle Redundanzen an den anderen Stellen.
• Verwenden Sie benutzerzentrierte Erklärungen. Beschreiben Sie das Problem in Bezug auf Benutzeraktionen oder -ziele, nicht in Bezug darauf, womit die Software unzufrieden ist. Verwenden Sie eine Sprache, die die Zielbenutzer verstehen und verwenden. Vermeiden Sie technischen Jargon.

Falsch:

Richtig:

In diesen Beispielen spricht die richtige Version die Sprache des Benutzers, während die falsche Version zu technisch ist.

• Verwenden Sie nicht die folgenden Wörter:
  • Fehler, Fehler (verwenden Sie stattdessen das Problem)
  • Fehler bei (Verwendung kann nicht stattdessen verwendet werden)
  • Illegal, invalid, bad (verwenden Sie stattdessen falsch)
  • Abbrechen, beenden, beenden (stattdessen stop verwenden)
  • Katastrophal, tödlich (stattdessen ernst verwenden)

Diese Begriffe sind unnötig und stehen im Gegensatz zum ermutigenden Ton von Windows. Bei richtiger Verwendung gibt das Fehlersymbol ausreichend an, dass ein Problem vorliegt.

Falsch:

Richtig:

Im falschen Beispiel sind die Begriffe "katastrophal" und "fehler" unnötig.

• Verwenden Sie keine Ausdrücke, die den Benutzer beschuldigen oder Benutzerfehler impliziert. Vermeiden Sie es, Sie und Ihr in der Formulierung zu verwenden. Während die aktive Stimme im Allgemeinen bevorzugt wird, verwenden Sie die passive Stimme, wenn der Benutzer das Motiv ist, und sich möglicherweise für den Fehler verantwortlich fühlen, wenn die aktive Stimme verwendet wurde.

Falsch:

Richtig:

Im falschen Beispiel wird der Benutzer mit der aktiven Stimme dafür verantwortlich gemacht.

• Spezifisch sein. Vermeiden Sie vage Formulierungen, z. B. Syntaxfehler und unzulässige Vorgänge. Geben Sie bestimmte Namen, Speicherorte und Werte der beteiligten Objekte an.

Falsch:

Die Datei wurde nicht gefunden.

Der Datenträger ist voll.

Wert außerhalb des Bereichs.

Das Zeichen ist ungültig.

Gerät nicht verfügbar.

Diese Probleme wären mit bestimmten Namen, Standorten und Werten viel einfacher zu lösen.

• Geben Sie möglicherweise unwahrscheinliche Probleme, Ursachen oder Lösungen nicht an, um spezifisch zu sein. Geben Sie kein Problem, keine Ursache oder Lösung an, es sei denn, es ist wahrscheinlich richtig. Es ist beispielsweise besser zu sagen, dass ein unbekannter Fehler aufgetreten ist, als etwas, das wahrscheinlich ungenau ist.
• Vermeiden Sie das Wort "bitte", außer in Situationen, in denen der Benutzer aufgefordert wird, etwas Unbequemes zu tun (z. B. Warten) oder die Software für die Situation Blame.

Richtig:

Warten Sie, während Windows die Dateien auf Ihren Computer kopiert.

• Verwenden Sie das Wort "sorry" nur in Fehlermeldungen, die zu schwerwiegenden Problemen für den Benutzer führen (z. B. Datenverlust oder Unfähigkeit, den Computer zu verwenden). Entschuldigen Sie sich nicht, wenn das Problem während des normalen Funktionierens des Programms aufgetreten ist (z. B. wenn der Benutzer warten muss, bis eine Netzwerkverbindung gefunden wird).

Richtig:

Es tut uns leid, aber Fabrikam Backup hat ein nicht behebbares Problem erkannt und wurde heruntergefahren, um Dateien auf Ihrem Computer zu schützen.

• Verweisen Sie auf Produkte mit ihren Kurznamen. Verwenden Sie keine vollständigen Produktnamen oder Markensymbole. Schließen Sie den Firmennamen nicht ein, es sei denn, Benutzer ordnen den Firmennamen dem Produkt zu. Fügen Sie keine Programmversionsnummern ein.

Falsch:

Richtig:

Im falschen Beispiel werden vollständige Produktnamen und Markensymbole verwendet.

• Verwenden Sie doppelte Anführungszeichen um Objektnamen. Dies erleichtert die Analyse des Texts und vermeidet potenziell peinliche Anweisungen.
  • Ausnahme: Vollqualifizierte Dateipfade, URLs und Domänennamen müssen sich nicht in doppelten Anführungszeichen befinden.

Richtig:

In diesem Beispiel wäre die Fehlermeldung verwirrend, wenn der Objektname nicht in Anführungszeichen wäre.

• Vermeiden Sie anfangs Sätze mit Objektnamen. Dies ist oft schwierig zu analysieren.
• Verwenden Sie keine Ausrufezeichen oder Wörter mit allen Großbuchstaben. Ausrufezeichen und Großbuchstaben lassen den Benutzer anschreien.

Weitere Richtlinien und Beispiele finden Sie unter Stil und Ton.

Titel

• Verwenden Sie den Titel, um den Befehl oder das Feature zu identifizieren, von dem der Fehler stammt. Ausnahmen:
  • Wenn ein Fehler von vielen verschiedenen Befehlen angezeigt wird, sollten Sie stattdessen den Programmnamen verwenden.
  • Wenn dieser Titel redundant oder verwirrend mit der Standard-Anweisung wäre, verwenden Sie stattdessen den Programmnamen.
• Verwenden Sie den Titel nicht, um das Problem zu erläutern oder zusammenzufassen, das der Zweck der Standard-Anweisung ist.

Falsch:

In diesem Beispiel wird der Titel fälschlicherweise verwendet, um das Problem zu erklären.

• Verwenden Sie die Groß- und Kleinschreibung im Titelformat, ohne die Interpunktion zu beenden.

Hauptanweisungen

• Verwenden Sie die Standard Anweisung, um das Problem in einer klaren, einfachen, spezifischen Sprache zu beschreiben.
• Seien Sie prägnant, verwenden Sie nur einen einzigen, vollständigen Satz. Analysieren Sie die Standard Anweisung auf die wesentlichen Informationen. Sie können den Betreff implizit lassen, wenn es sich um Ihr Programm oder den Benutzer handelt. Geben Sie den Grund für das Problem an, wenn Sie dies präzise tun können. Wenn Sie weitere Erläuterungen benötigen, verwenden Sie eine zusätzliche Anweisung.

Falsch:

In diesem Beispiel wird die gesamte Fehlermeldung in die Standard-Anweisung eingefügt, was das Lesen erschwert.

• Seien Sie spezifisch, wenn Objekte beteiligt sind, geben Sie deren Namen an.
• Vermeiden Sie das Einfügen vollständiger Dateipfade und URLs in der Standard-Anweisung. Verwenden Sie stattdessen einen Kurznamen (z. B. den Dateinamen), und fügen Sie den vollständigen Namen (z. B. den Dateipfad) in die ergänzende Anweisung ein. Sie können jedoch einen einzelnen vollständigen Dateipfad oder eine url in die Standard-Anweisung einfügen, wenn die Fehlermeldung andernfalls keine zusätzliche Anweisung benötigt.

In diesem Beispiel ist nur der Dateiname in der Standard-Anweisung enthalten. Der vollständige Pfad befindet sich in der ergänzenden Anweisung.

• Geben Sie den vollständigen Dateipfad und die URL überhaupt nicht an, wenn dies aus dem Kontext ersichtlich ist.

In diesem Beispiel benennt der Benutzer eine Datei aus Windows Explorer um. In diesem Fall wird der vollständige Dateipfad nicht benötigt, da er aus dem Kontext ersichtlich ist.

• Verwenden Sie nach Möglichkeit eine präsente Zeit.
• Verwenden Sie für Überschriften die Standardgroß- und kleinschreibung.
• Schließen Sie keine endgültigen Zeiträume ein, wenn es sich bei der Anweisung um eine Anweisung handelt. Wenn es sich bei der Anweisung um eine Frage handelt, fügen Sie ein abschließendes Fragezeichen ein.

Hauptanweisungsvorlagen

Es gibt zwar keine strengen Regeln für das Ausdrücken, aber versuchen Sie, nach Möglichkeit die folgenden Standard-Anweisungsvorlagen zu verwenden:

• [optionaler Antragstellername] kann nicht [Aktion ausführen]
• [optionaler Antragstellername] kann keine Aktion ausführen, weil [Grund]
• [optionaler Antragstellername] kann keine Aktion auf "[Objektname]" ausführen.
• [optionaler Antragstellername] kann keine Aktion auf "[Objektname]" ausführen, da [Grund]
• Es ist nicht genug [Ressource] vorhanden, um [Aktion auszuführen]
• [Antragstellername] verfügt nicht über einen [Objektnamen], der für [Zweck] erforderlich ist.
• [Gerät oder Einstellung] ist deaktiviert, sodass [unerwünschte Ergebnisse]
• [Gerät oder Einstellung] ist nicht [verfügbar | gefunden | aktiviert | aktiviert]
• "[Objektname]" ist derzeit nicht verfügbar.
• Der Benutzername oder das Kennwort ist falsch.
• Sie haben keine Berechtigung für den Zugriff auf "[Objektname]"
• Sie haben keine Berechtigung, [Aktion auszuführen]
• [Programmname] hat ein ernstes Problem und muss sofort geschlossen werden.

Nehmen Sie natürlich nach Bedarf Änderungen vor, damit die Standard Anweisung grammatikalisch korrekt ist und den richtlinien für die Standard-Anweisungen entspricht.

Zusätzliche Anweisungen

• Verwenden Sie die ergänzende Anweisung für Folgendes:
  • Geben Sie zusätzliche Details zum Problem an.
  • Erläutern sie die Ursache des Problems.
  • Listet die Schritte auf, die der Benutzer ausführen kann, um das Problem zu beheben.
  • Stellen Sie Maßnahmen bereit, um zu verhindern, dass das Problem erneut auftritt.
• Schlagen Sie nach Möglichkeit eine praktische, hilfreiche Lösung vor, damit Benutzer das Problem beheben können. Stellen Sie jedoch sicher, dass die vorgeschlagene Lösung das Problem wahrscheinlich löst. Verschwenden Sie die Zeit der Benutzer nicht, indem Sie mögliche, aber unwahrscheinliche Lösungen vorschlagen.

Falsch:

In diesem Beispiel sind das Problem und die empfohlene Lösung zwar möglich, aber sehr unwahrscheinlich.

• Wenn das Problem ein falscher Wert ist, den der Benutzer eingegeben hat, verwenden Sie die zusätzliche Anweisung, um die richtigen Werte zu erklären. Benutzer sollten diese Informationen nicht aus einer anderen Quelle ermitteln müssen.
• Geben Sie keine Lösung an, wenn sie aus der Problemerklärung trivial abgeleitet werden kann.

In diesem Beispiel ist keine zusätzliche Anweisung erforderlich. die Lösung kann aus der Problemaussage trivial abgeleitet werden.

• Wenn die Lösung über mehrere Schritte verfügt, zeigen Sie die Schritte in der Reihenfolge an, in der sie abgeschlossen werden sollen. Vermeiden Sie jedoch mehrstufige Lösungen, da Benutzer schwierigkeiten haben, sich mehr als zwei oder drei einfache Schritte zu merken. Wenn weitere Schritte erforderlich sind, lesen Sie das entsprechende Hilfethema.
• Halten Sie ergänzende Anweisungen kurz. Geben Sie nur das an, was Benutzer wissen müssen. Lassen Sie unnötige Details aus. Maximal drei Sätze mittlerer Länge sind vorgesehen.
• Um Fehler zu vermeiden, während Benutzer Anweisungen ausführen, legen Sie die Ergebnisse vor die Aktion.

Richtig:

Klicken Sie auf OK, um Windows neu zu starten.

Falsch:

Klicken Sie auf OK, um Windows neu zu starten.

Im falschen Beispiel klicken Benutzer eher versehentlich auf OK.

• Empfehlen Sie nicht, sich an einen Administrator zu wenden, es sei denn, dies gehört zu den wahrscheinlichsten Lösungen für das Problem. Reservieren Sie solche Lösungen für Probleme, die wirklich nur von einem Administrator gelöst werden können.

Falsch:

In diesem Beispiel liegt das Problem wahrscheinlich bei der Netzwerkverbindung des Benutzers, sodass es sich nicht lohnt, sich an einen Administrator zu wenden.

• Wenden Sie sich nicht an den technischen Support. Die Option, sich an den technischen Support zu wenden, um ein Problem zu lösen, ist immer verfügbar und muss nicht durch Fehlermeldungen heraufgestuft werden. Konzentrieren Sie sich stattdessen auf das Schreiben hilfreicher Fehlermeldungen, damit Benutzer Probleme lösen können, ohne sich an den technischen Support zu wenden.

Falsch:

In diesem Beispiel empfiehlt die Fehlermeldung fälschlicherweise, sich an den technischen Support zu wenden.

• Verwenden Sie vollständige Sätze, großgeschriebene Sätze und endende Interpunktion.

Commitschaltflächen

• Wenn die Fehlermeldung Befehlsschaltflächen oder Befehlslinks enthält, die das Problem lösen, befolgen Sie die entsprechenden Richtlinien in Dialogfeldern.
• Wenn das Programm aufgrund des Fehlers beendet werden muss, geben Sie die Schaltfläche Programm beenden an. Um Verwechslungen zu vermeiden, verwenden Sie für diesen Zweck nicht schließen.
• Geben Sie andernfalls die Schaltfläche Schließen an. Verwenden Sie OK nicht für Fehlermeldungen, da diese Formulierung impliziert, dass Probleme in Ordnung sind.
  • Ausnahme: Verwenden Sie OK, wenn Ihr Fehlerberichtsmechanismus feste Bezeichnungen aufweist (wie bei der MessageBox-API).

Dokumentation

Wenn Sie auf Fehler verweisen:

• Verweisen Sie auf Fehler in der Standard-Anweisung. Wenn die Standard Anweisung lang oder detailliert ist, fassen Sie sie zusammen.
• Bei Bedarf können Sie auf ein Fehlermeldungsdialogfeld als Meldung verweisen. Beziehen Sie sich nur in der Programmierung und anderen technischen Dokumentationen als Fehlermeldung.
• Formatieren Sie den Text nach Möglichkeit fett. Andernfalls setzen Sie den Text nur in Anführungszeichen, wenn dies erforderlich ist, um Verwechslungen zu vermeiden.

Beispiel: Wenn Sie die Meldung There is no CD disc in the drive erhalten, legen Sie eine neue CD in das Laufwerk ein, und versuchen Sie es erneut.