Wie viele Informationen zu einem Fehler sollten dem Benutzer angezeigt werden?


38

Anwendungen können immer Fehler auslösen. Wenn ein solcher Fehler auftritt, sollte der Benutzer benachrichtigt werden, da das, was er von der Anwendung verlangt hat, nicht erfolgreich war.

Wie viele Informationen sollte der Benutzer jedoch erhalten? Ich denke, die meisten von uns stimmen darin überein, keinen Stack-Trace anzuzeigen ( Sollte ein Stack-Trace in der Fehlermeldung enthalten sein, die dem Benutzer angezeigt wird? ), Aber ich kann keine Frage zum Rest des Fehlerinhalts oder zu dem, was angezeigt werden soll, finden Benutzer.

Beispielsweise muss eine Sprache, die Ausnahmen unterstützt (.net, java), den Ausnahmetyp freigeben, in dem die Ausnahme aufgetreten ist, und eine etwas klarstellende Meldung, die mit der Ausnahme einhergeht. Sollte dies auch vor dem Benutzer verborgen bleiben? Oder sollten wir das trotzdem zeigen? Oder sollten wir eine allgemeine Nachricht anzeigen? Oder sollten wir eine von mehreren Nachrichten anzeigen, basierend auf der zugrunde liegenden Ausnahme?

Antworten:


34

was dem Benutzer zu zeigen ist. Sollte dies auch vor dem Benutzer verborgen bleiben?

Sie zeigen dem Benutzer, was für ihn umsetzbar ist.

Wenn Sie zum Beispiel einen Fehler haben, der durch eine Nullzeiger-Ausnahme und einen eher fehlerhaften als einen Benutzerfehler verursacht wird, möchten Sie keine vollständige Erklärung, da sie nichts anderes tun können.

Oder sollten wir das trotzdem zeigen? Oder sollten wir eine allgemeine Nachricht anzeigen?

Das Anzeigen der Ausnahme als Hauptinhalt der Fehlermeldung ist für die meisten Benutzer sinnlos . Wenn Ihre Zielgruppe Entwickler sind, können Sie die Informationen die ganze Zeit als vollständigen Fehler anzeigen (möglicherweise haben Sie eine interne Anwendung für automatisierte Tests). Aber im Allgemeinen können Benutzer auch mit diesem Wissen nichts anderes machen.

Sollen wir eine von mehreren Nachrichten anzeigen, basierend auf der zugrunde liegenden Ausnahme?

Die beste Strategie besteht darin, Folgendes zu tun:

  • Interpretieren Sie den Fehler in einen für den Benutzer aussagekräftigen Text.
    • Ein Teil davon ist "Was kann der Benutzer anders machen?"
    • Wenn sie nichts anderes machen können, sagen Sie etwas wie "ein unerwarteter Fehler ist aufgetreten."
  • Fügen Sie eine "optionale" detaillierte Fehlerbeschreibung hinzu
  • Zulassen, dass Benutzer den Fehlerbericht senden (oder dies je nach Benutzerbasis automatisch tun)

Beispiel

Bildbeschreibung hier eingeben

  1. Es zeigt die "hier ist was passiert" (unerwarteter Fehler)
  2. Weist den Benutzer an, was zu tun ist (Mail erneut öffnen, enthält sogar eine Verknüpfung dazu)
  3. Hat auch eine "Details anzeigen", wenn jemand neugierig ist, den vollständigen technischen Fehler zu sehen
  4. Liefert eine Benachrichtigung, bei der ein Fehler gemeldet wird (siehe unten)

Beachten Sie, dass Sie in einigen Fällen den Fehlerbericht manuell oder automatisch erstellen möchten.


20
Ich stimme dir nicht zu. Nichts ist so ärgerlich wie eine Anwendung, die "ein Fehler ist aufgetreten" ausgibt. auf den Bildschirm und dann beendet. Wenn das passiert, frage ich mich immer, warum der Entwickler so faul war, eine so uninformative Nachricht auszudrucken. Erklären Sie dem Benutzer etwas , damit er verstehen kann, was im Allgemeinen schief gelaufen ist, auch wenn er nichts dagegen tun kann. Im besten Fall können sie die Fehlermeldung googeln und möglicherweise eine von einer anderen Person beschriebene Lösung finden. Dies ist fast unmöglich, wenn bei jedem Fehler dieselbe generische Meldung ausgegeben wird.
Jon Bentley

3
@ JonBentley Sie sehen es als Entwickler, der dieses Zeug verstehen will . Der durchschnittliche Benutzer wird sich einfach Sorgen machen, dass er es verstehen sollte , was er nicht muss.
Deworde

12
@deworde Im Gegenteil, ich betrachte es als Benutzer . Als Benutzer möchte ich es nicht in technischen Begriffen verstehen , aber ich möchte genügend Informationen, die meiner Meinung nach nicht inkompetent sind ("ein Fehler ist aufgetreten" erweckt den Eindruck, dass der Entwickler es nicht getan hat). Ich weiß nicht, was sie getan haben, damit ich nach Antworten suchen kann. Wenn bei jedem Absturz die Meldung "Ein Fehler ist aufgetreten" angezeigt wird, hilft mir die Google-Suche nicht weiter. Es ist weitaus wahrscheinlicher, dass eine eindeutige Nachricht für jede Situation mich zu einem Forum bringt, in dem jemand anderes das gleiche Problem hatte und es möglicherweise löste.
Jon Bentley

3
@ JonBentley ein paar Punkte zur Überlegung. Erstens ist der Hauptpunkt dieser Antwort, dass Sie dem Benutzer umsetzbare Informationen geben. Wenn es sich um einen Fehler handelt, müssen sie Informationen mitteilen, um ihn zu beheben. Dies fällt in You show the user what is actionable for them. Wenn Sie die Ursache des Problems kennen, zeigen Sie dies dem Benutzer in der Beschreibung. Aber in der Regel , wenn Sie wissen , den Grund für einen Fehler finden Sie kennen die Problemlösung die Benutzer in geeigneter Weise zu informieren.
Enderland

2
Zweitens überschätzen Sie die durchschnittliche Fähigkeit des Benutzers, Probleme selbst zu lösen. Die überwiegende Mehrheit der Bevölkerung ist das, was die meisten Entwickler / Programmierer / Stack Exchange-Leute als Computer-Analphabeten bezeichnen würden. Die meisten dieser Personen sind offen gesagt nicht in der Lage, Probleme zu diagnostizieren, zu beheben und zu beheben. Details können die Sache tatsächlich verschlimmern, weil die Leute Dinge falsch interpretieren können, die für Entwickler völlig sinnvoll wären. Programmierer und technikbegeisterte Menschen sind für die meisten Anwendungen fast immer nicht die Zielgruppe, sehr zur Enttäuschung aller hier ... :)
enderland

12

Es kommt darauf an, wer der Benutzer ist und was er mit den Informationen anfangen kann.

Versuchen Sie im Allgemeinen, ihnen nur nützliche Informationen zu Dingen zu zeigen, die sie selbst lösen können. Eine 40-Zeilen-Stack-Ablaufverfolgung mit einem Fehler durch reguläre Ausdrücke im oberen Bereich ist nicht sehr nützlich. Viel besser wäre eine Meldung, die besagt, dass Datum als "JJJJ-MM-TT" formatiert sein muss . Alles andere und der Benutzer weiß möglicherweise nicht, wie er auf den Fehler reagieren soll, und möchte Ihre Anwendung dann möglicherweise nicht verwenden, aus Angst, dass es zu kryptischeren und beängstigenderen Fehlern kommt (und ja, nicht-technische Benutzer haben manchmal Angst vor dem Stack Spuren). Und das könnte schlecht fürs Geschäft sein.

Für interne Anwendungen von anderen Entwicklern verwendet wird , bin ich ein wenig mehr entspannt über einen Stack - Trace, zeigt zusätzlich zu etwas nützlich , weil ich der Benutzer wissen umgehen kann einen Stack - Trace zu sehen und wird wahrscheinlich wissen , was zu tun ist .

Für nicht technische Benutzer ist es meines Erachtens nur in einer kritischen Fehlersituation in Ordnung, ihnen einen Stack-Trace anzuzeigen, wenn Sie ihn zur Behebung des Problems benötigen. Sie werden aufgefordert, den Stack-Trace zu kopieren, einzufügen und zu senden Obwohl es eine viel bessere Möglichkeit ist, die Anwendung zum Senden einer Protokolldatei aufzufordern, oder noch besser, eine Protokolldatei an den Entwickler zu senden, nachdem Sie den Benutzer um die Erlaubnis gebeten haben, die Datei freizugeben.


5
Ich wäre mit einer Anwendung, die überall Protokolle sendet, ohne mich zu fragen, nicht einverstanden. Stattdessen sollte der Fehlermeldungsdialog eine Option zum Melden des Fehlers enthalten. Der Benutzer sollte in der Lage sein, alle Informationen, einschließlich des Stack-Trace, zu überprüfen, bevor er den Bericht sendet.
Piedar

1
@piedar: Das ist ein guter Punkt.
FrustratedWithFormsDesigner

4
@piedar: Die Schaltfläche "Weitere Details anzeigen" im Fehlerdialog oder ein Link zur Anwendungsprotokolldatei sind wahrscheinlich eine gute Möglichkeit, den Power-Anwendern, die diese Informationen wünschen, alle wichtigen Details zu präsentieren. Sogar ein Kontrollkästchen "Details standardmäßig anzeigen", wenn Sie sich die Mühe machen möchten, es zu codieren. Aber das werden nicht alle Benutzer sehen wollen, und einige Benutzer werden dadurch ausgeschaltet.
FrustratedWithFormsDesigner

2
@Paddy: Du hast recht, aber: 1) Es ist ein Beispiel. : P 2) Vielleicht habe ich solchen Code repariert und bereinigt, weshalb ich gerade daran denke ...
FrustratedWithFormsDesigner

2
@NateKerkhofs "Und wenn er der Entwickler ist, kann er den Bug replizieren" .. - oh, wenn das nur wahr wäre :(
Blorgbeard

1

Nachrichten an die Benutzer sollten genauso behandelt werden wie das Erstellen einer neuen Ausnahmebedingung - Sie geben die Informationen an, die sie benötigen, um zu entscheiden, was zu tun ist.

Dies hängt natürlich von Ihrer Anwendung und Ihrer Nutzerbasis ab, sollte jedoch Ihr Leitgedanke sein - Ihre Absicht sollte es sein, die Informationen bereitzustellen, die der "Anrufer" benötigt, um zu bestimmen, was er, wenn überhaupt, tun kann, um die gewünschte Aktion erfolgreich durchzuführen . Wenn es sich einfach um einen Zugriffsfehler auf eine Datei handelt, geben Sie einen Dateipfad und die Meldung an, dass Sie nicht darauf zugreifen konnten. Wenn es sich um eine Nullzeigerausnahme handelt, geben Sie einfach eine allgemeine Fehlermeldung aus.

Natürlich wird es mehr Meldungen geben, die nicht in der Lage sind, die gewünschte Aktion auszuführen, als der Benutzer tatsächlich beheben kann, aber das ist nur das Leben - die meisten Ausnahmen sind, weil wir einen Fehler gemacht haben, und nicht, weil der Benutzer die Umgebung eingerichtet hat falsch.


1

Dies ist ein allgemeines Thema:

Wie können Sie Uninformierten / Computer-Analphabeten helfen und gleichzeitig Informationen anzeigen, die fortgeschrittenere Benutzer wie Programmierer, Entwickler, Tester usw. verwenden können?

Ich denke die Antwort ist, dass Sie beides tun!

Die Reihenfolge ist jedoch wichtig und ich empfehle Ihnen Folgendes:

  • Was ist passiert.
  • Was nun
  • Technische Details

Technische Details ist der Teil, der Informationen für Vorbestellungen oder für reguläre Benutzer enthält, wenn ein Problem gemeldet wird


0

Was du zeigen willst, hängt davon ab, wie beschämt du dich für das Miststück bist.

Es geht darum, die Einzelheiten des Ausfalls des technischen Supports so schnell und reibungslos wie möglich zu ermitteln. Das kann bedeuten, dass Sie die Protokolldatei mit dem Stack-Trace des Beendigungsfehlers automatisch nach Hause senden oder den Benutzer auffordern, auf eine Schaltfläche zu klicken, die die Übertragung initiiert. Möglicherweise über einen USB-Stick, wenn keine Internetverbindung besteht.


0

Ich mag die Gründe für die akzeptierte Antwort, aber ich muss zumindest mit meiner Interpretation der Beschränkung der Informationen auf das, was "umsetzbar" ist, respektvoll nicht einverstanden sein . Ich möchte nur ein bisschen mehr als das als Benutzer als "unerwarteter Fehler" wissen .

Zugegeben, ich bin ein bisschen computerversiert und habe diese Vorurteile, aber ich denke nicht, dass dies eine besonders voreingenommene Ansicht ist. Weil ich mein Bestes geben kann, um diese Tendenz zu beseitigen, indem ich diese Denkweise auf Bereiche anwende, für die ich wenig Erfahrung habe, wie die Luftfahrt.

Ich weiß zwar wenig über die Luftfahrt, sage jedoch, mein Flug sei verspätet oder annulliert, und das einzige, was die Mitarbeiter mir mitteilen, ist: "Wir hatten einen unerwarteten Fehler. Bitte warten Sie 3 Stunden, bis ein weiterer Flug beginnt." Zumindest empfinden Sie mich in diesen Fällen eher als verärgerten Kunden, denn obwohl dies meine Vorgehensweise in keiner Weise wirklich beeinflusst, möchte ich nur ein bisschen mehr darüber erfahren, warum ich so bin auf diese Weise als zahlender Kunde belästigt.

Wenn sie nur sagten: "Wir erleben turbulentes Wetter" oder "Wir hatten einen medizinischen Notfall in unserem vorherigen Flug" oder eine Gerätefehlfunktion oder was auch immer, dann reicht das für mich aus, um viel mehr als "unerwartete Fehler" zu sympathisieren Sei ein bisschen zufriedener damit, herumzusitzen und 3 Stunden auf den nächsten Flug zu warten. Vielleicht bevorzuge ich sogar ein Technobabble, das über meinen Kopf geht und "unerwarteten Fehlern" wie "In Ordnung, die Wörter, die aus Ihrem Mund kommen, gehen in mein Ohr, erreichen aber nicht den Zentralprozessor. Aber ich verstehe jetzt, dass es eine Art gibt Ich gehe Kaffee trinken und setze mich dort hin! Hoffe ihr kriegt das Problem mit dem Ding in den Griff! "

Und häufig, was die Ausnahmebehandlung anbelangt, denke ich, dass Sie in der Regel über genügend grundlegende Informationen zu den Ereignissen auf der catchWebsite verfügen , auch wenn Sie die technischen Details der Ausnahme ausblenden möchten, z.

try
{
     load_file(file_name);
}
catch (const exception& ex)
{
     exception_dialog("Failed to load file: '{1}'.", file_name);
}

Und das zeigt nicht einmal die möglicherweise sehr technischen Informationen an, die mit der Ausnahme verbunden sind, aber es sagt uns zumindest deutlich mehr als "unerwarteter Fehler". Es liefert zumindest ein kontextuelles "Was / Wo / Wann", auch wenn es nicht "Warum / Wie" sagt. Ich denke, zumindest der Wunsch nach dieser grundlegenden Informationsebene ist nicht besonders von meiner Computer-Geschicklichkeit beeinflusst.

Der Rest ist wahrscheinlich sehr spezifisch für Ihre Kunden und besonderen Bedürfnisse. Aber mein Appell ist zumindest für etwas, das nur ein kleines bisschen mehr ist als "unerwarteter Fehler".


Nun, es ist eine voreingenommene Sichtweise. Dem durchschnittlichen Benutzer ist es egal, warum er nicht das kann, was er nicht kann. Sie kümmern sich nur darum, ob und wie sie ihr Problem beheben können.
gnasher729

"Dem durchschnittlichen Benutzer ist es egal, warum er nicht kann, was er nicht kann. Es ist ihm nur wichtig, ob und wie er sein Problem beheben kann." Wenn der Durchschnittsbenutzer nicht einmal versteht, was eine Datei oder ein Server ist, kann dies möglicherweise mit dem "Handlungsbedarf" zusammenhängen, da er Ihnen möglicherweise auf die Schulter klopfen und sagen kann: "Hey , diese Anwendung sagt, dass sie die erforderliche Konfigurationsdatei nicht finden kann ", oder etwas in diesem Sinne, wo Sie möglicherweise nach dem Problem suchen und es schnell beheben können, z. B.
Dragon Energy
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.