Quante informazioni su un errore dovrebbero essere mostrate all'utente?


38

Le applicazioni possono sempre generare errori. Se si verifica un errore del genere, l'utente deve essere avvisato, perché ciò che ha chiesto all'applicazione di fare non è riuscito.

Tuttavia, quante informazioni devono essere fornite all'utente? Penso che la maggior parte di noi sia d'accordo sul non mostrare una traccia dello stack ( dovrebbe esserci una traccia dello stack nel messaggio di errore presentato all'utente? ), Ma non riesco a trovare una domanda sul resto del contenuto dell'errore o su cosa mostrare al utente.

Ad esempio, un linguaggio che supporta le eccezioni (.net, java) ha il tipo di eccezione da condividere, in cui si è verificata l'eccezione, e un messaggio un po 'chiarificatore da accompagnare all'eccezione. Anche questo dovrebbe essere nascosto all'utente? O dovremmo mostrarlo comunque? O dovremmo mostrare un messaggio generico? o dovremmo mostrare uno dei numerosi messaggi in base a quale sia l'eccezione sottostante?

Risposte:


34

cosa mostrare all'utente. Anche questo dovrebbe essere nascosto all'utente?

Mostra all'utente ciò che è utilizzabile per loro.

Ad esempio, se si verifica un errore causato da un'eccezione del puntatore null e da un errore maggiore rispetto all'errore utente, non si desidera una spiegazione completa perché non possono fare nulla di diverso.

O dovremmo mostrarlo comunque? O dovremmo mostrare un messaggio generico?

Mostrare l'eccezione come contenuto del messaggio di errore primario è inutile per la maggior parte degli utenti . Forse se la tua base di utenti target sono gli sviluppatori, potresti mostrare le informazioni come errore completo in ogni momento (forse hai un'applicazione interna per i test automatizzati). Ma generalmente gli utenti non possono fare nulla di diverso anche con quella conoscenza.

dovremmo mostrare uno dei numerosi messaggi in base a quale sia l'eccezione sottostante?

La migliore strategia è di fare quanto segue:

  • Interpreta l'errore nel testo che è significativo per l'utente.
    • Parte di questo è "cosa può fare l'utente in modo diverso?"
    • Se non possono fare qualcosa di diverso, dire qualcosa come "si è verificato un errore imprevisto".
  • Aggiungi una descrizione dell'errore dettagliata "opzionale"
  • Consenti agli utenti di inviare il rapporto errori (o farlo automaticamente, a seconda della base utenti)

Esempio

inserisci qui la descrizione dell'immagine

  1. Mostra il "ecco cosa è successo" (errore imprevisto)
  2. Indica all'utente cosa fare (riapri Mail, include anche un collegamento per farlo)
  3. Ha anche un "visualizza dettagli" se qualcuno è curioso di vedere l'errore tecnico completo
  4. Fornisce notifica di archiviazione di un rapporto di errore (vedere sotto)

Si noti che in alcuni casi è possibile che si desideri che il rapporto di errore sia manuale o automatico.


20
Non sono d'accordo. Non c'è nulla di così fastidioso come un'applicazione che stampa "si è verificato un errore". allo schermo e quindi esce. Ogni volta che succede, mi chiedo sempre perché lo sviluppatore sia stato così pigro da stampare un messaggio così poco informativo. Spiegare qualcosa all'utente in modo che possano capire cosa è andato storto in senso generale, anche se non c'è nulla che possano fare al riguardo. Nel migliore dei casi, possono Google il messaggio di errore e forse trovare una soluzione che qualcun altro ha descritto, il che è quasi impossibile se ogni errore diverso stampa lo stesso messaggio generico.
Jon Bentley,

3
@JonBentley Lo stai guardando come uno sviluppatore, che vuole capire queste cose. L'utente medio sarà semplicemente iniziato a preoccuparsi che essi dovrebbero capire, che non hanno bisogno di.
deworde,

12
@deworde Al contrario, lo considero un utente . Come utente, non voglio comprenderlo in termini tecnici, ma voglio abbastanza informazioni da non ritenere che la persona che ha scritto il software sia incompetente ("si è verificato un errore" dà l'impressione che lo sviluppatore non abbia fatto ' non so cosa stessero facendo), e così posso cercare le risposte. Se ogni singolo crash dice "si è verificato un errore", una ricerca su Google non mi aiuterà. Un messaggio unico per ogni situazione è molto più probabile che mi porti a un forum in cui qualcun altro ha avuto lo stesso problema e forse lo ha risolto.
Jon Bentley,

3
@JonBentley alcuni punti da considerare. Innanzitutto, il punto principale di questa risposta è fornire all'utente informazioni fruibili. Se si tratta di un errore, possono correggere la necessità di comunicare loro informazioni per risolverlo. Questo cade You show the user what is actionable for them. Se conosci la causa del problema, lo mostri all'utente nella descrizione. Ma in genere se si conosce il motivo di un errore, si conoscerà la risoluzione del problema per informare l'utente in modo appropriato.
Enderland,

2
In secondo luogo, sopravvaluti gravemente la capacità media dell'utente di auto-risolvere i problemi. La stragrande maggioranza della popolazione è ciò che la maggior parte degli sviluppatori / programmatori / gente di Stack Exchange chiamerebbe analfabeta del computer. La maggior parte di queste persone, francamente, non è attrezzata per diagnosticare, risolvere e risolvere i problemi. I dettagli possono effettivamente peggiorare le cose perché le persone possono fraintendere cose che avrebbero perfettamente senso per gli sviluppatori. I programmatori e gli esperti di tecnologia non sono quasi universalmente il target demografico per la maggior parte delle applicazioni, con grande delusione di tutti qui ... :)
enderland

12

Dipende da chi è l'utente e da cosa può fare con le informazioni.

In generale, prova a mostrare loro solo informazioni utili su cose che possono risolvere da sole. Una traccia dello stack di 40 righe con un errore di espressione regolare nella parte superiore non è molto utile. Molto meglio sarebbe un messaggio che dice che la data deve essere formattata come "aaaa-mm-gg" . Nient'altro e l'utente potrebbe non sapere come rispondere all'errore, quindi potrebbe non voler utilizzare l'applicazione, per paura che causi errori più criptici e spaventosi (e sì, gli utenti non tecnici a volte sono spaventati dallo stack tracce). E questo potrebbe essere dannoso per gli affari.

Per le applicazioni interne utilizzate da altri sviluppatori, sono un po 'più rilassato nel visualizzare una traccia dello stack, oltre a qualcosa di più utile , perché so che l'utente può gestire la visualizzazione di una traccia dello stack e probabilmente saprà cosa fare al riguardo.

Per gli utenti non tecnici, l'unica volta in cui penso che sarebbe OK mostrare loro una traccia dello stack si trova in una situazione di errore critico in cui è necessario per risolvere il problema e viene chiesto loro di copiare e incollare la traccia dello stack e inviarlo per te, anche se davvero un modo molto migliore per farlo è chiedere loro di inviare un file di registro, o meglio ancora, fare in modo che l'applicazione invii un file di registro allo sviluppatore, dopo aver chiesto all'utente l'autorizzazione a condividere il file.


5
Non starei bene con un'applicazione che invia registri ovunque senza chiedermelo. Invece, la finestra di dialogo del messaggio di errore dovrebbe fornire un'opzione per segnalare l'errore. L'utente dovrebbe essere in grado di rivedere tutte le informazioni, inclusa la traccia dello stack, prima di inviare il rapporto.
piedar

1
@piedar: è un buon punto.
FrustratedWithFormsDesigner,

4
@piedar: Avere un pulsante "Visualizza più dettagli" nella finestra di dialogo dell'errore o un collegamento al file di registro dell'applicazione è probabilmente un buon modo per presentare tutti i dettagli cruenti ai poweruser che vogliono tali informazioni. Anche una casella di controllo "mostra i dettagli per impostazione predefinita", se si desidera andare al problema di codificarlo. Ma non tutti gli utenti vorranno vederlo, e alcuni utenti ne saranno disattivati.
FrustratedWithFormsDesigner,

2
@Paddy: hai ragione, ma: 1) È un esempio. : P 2) Forse ho risolto e ripulito tale codice, motivo per cui è fresco nella mia mente ...
FrustratedWithFormsDesigner

2
@NateKerkhofs "E se è lo sviluppatore, può replicare il bug" .. - oh, se solo fosse vero :(
Blorgbeard,

1

I messaggi agli utenti devono essere trattati allo stesso modo della creazione di una nuova eccezione da lanciare: si forniscono le informazioni di cui avranno bisogno per decidere cosa fare.

Questo ovviamente dipenderà dalla vostra applicazione e base di utenti, ma dovrebbe essere il vostro principale guida - il vostro intento dovrebbe essere quello di fornire le informazioni necessarie al "chiamante" per determinare cosa, se non altro, possono fare per eseguire con successo l'azione desiderata . Se è qualcosa di semplice come un errore di accesso a un file, dai un percorso al file e il messaggio a cui non puoi accedervi. Se si tratta di un'eccezione puntatore null, basta dare un messaggio di errore generico.

Naturalmente ci saranno più messaggi "incapaci di eseguire l'azione desiderata" di quanti ce ne siano in realtà che l'utente può risolvere, ma è solo la vita - la maggior parte delle eccezioni è dovuta al fatto che abbiamo commesso un errore, non perché l'utente ha impostato l'ambiente in modo non corretto.


1

Questo è un tema comune:

Come puoi aiutare gli analfabeti informatici / informatici allo stesso tempo a mostrare informazioni che possono usare utenti più avanzati come programmatori, sviluppatori, tester, ecc.

Penso che la risposta sia che fai entrambe le cose!

L'ordine è importante e ti consiglio di avere:

  • Quello che è successo.
  • cosa fare adesso
  • Dettagli tecnici

Dettagli tecnici è la parte che contiene informazioni per ordini avanzati o per utenti regolari quando segnalano un problema


0

Quello che vuoi mostrare dipende da quanto ti vergogni a rovinare.

Il punto è quello di ottenere i dettagli del mancato supporto tecnico nel modo più rapido e fluido possibile. Ciò può significare che tu invii automaticamente a casa il file di registro, incluso lo stack stack dell'errore di terminazione, oppure chiedi gentilmente all'utente di fare clic su un pulsante che avvierà il trasferimento. Forse tramite chiavetta USB se non c'è connessione a Internet.


0

Mi piace la logica alla base della risposta accettata, ma devo essere in disaccordo rispettoso almeno con la mia interpretazione di limitare l'informazione a ciò che è "attuabile" . Voglio sapere solo un po 'più di questo come utente di "errore imprevisto" .

E devo ammettere che sono un po 'esperto di computer e ho questo pregiudizio, ma non credo che questa sia una visione particolarmente distorta. Perché posso fare del mio meglio per rimuovere questo pregiudizio applicando questa mentalità ai domini per i quali ho poca esperienza, come l'aviazione.

Mentre so poco dell'aviazione, supponiamo che il mio volo sia in ritardo o cancellato e l'unica cosa che lo staff mi dice è: "Abbiamo avuto un errore imprevisto. Attendere 3 ore per un volo successivo". Mi troverai almeno un po 'più scontento in quei casi perché, anche se non influisce sul mio modo di agire in entrambi i casi, voglio solo sapere un po' di più sul perché sono scomodo in questo modo come cliente pagante.

Se dicevano semplicemente "Stiamo vivendo un clima turbolento" o "Abbiamo avuto un'emergenza medica nel nostro volo precedente" o un malfunzionamento dell'attrezzatura o altro, è abbastanza per me di simpatizzare molto più di un "errore imprevisto" e sii un po 'più di contenuto stando seduto e aspettando 3 ore per il prossimo volo. In realtà potrei persino preferire un po 'di tecnobabble che mi passa per la testa a "errore imprevisto" come, "Va bene, le parole che escono dalla tua bocca mi stanno andando nell'orecchio ma non raggiungono il processore centrale. Ma capisco ora che c'è un qualche tipo del problema e vado a prendere un caffè e sedermi lì! Spero che voi ragazzi risolviate quel problema con quella cosa! "

E spesso in termini di gestione delle eccezioni, penso che di solito tu abbia abbastanza di quel tipo di informazioni di base su ciò che è accaduto sul catchsito, anche se vuoi nascondere i dettagli più tecnici dell'eccezione, come:

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

E questo non mostra nemmeno quelle che potrebbero essere potenzialmente le informazioni molto tecniche allegate all'eccezione, ma almeno ci dice molto di più di un "errore imprevisto". Fornisce almeno un "cosa / dove / quando" contestuale anche se non dice "perché / come". Penso che almeno il desiderio di questo livello base di informazioni non sia particolarmente influenzato dalla mia conoscenza del computer.

Il resto è probabilmente molto specifico per i tuoi clienti e le tue esigenze particolari. Ma il mio appello è almeno per qualcosa di poco più che un "errore imprevisto".


Bene, è una visione distorta. L'utente medio non si preoccupa del perché non può fare ciò che non può fare. A loro importa solo se e come possono risolvere il loro problema.
gnasher729,

"L'utente medio non si preoccupa del perché non può fare ciò che non può fare. A loro importa solo se e come possono risolvere il loro problema." Se l'utente medio non capisce nemmeno cosa sia un file o un server, forse è così, ma ciò potrebbe comunque legarsi a ciò che è "utilizzabile", perché potrebbe essere in grado di toccarti sulla spalla e dire: "Ehi , questa applicazione afferma che non è possibile trovare questo file di configurazione richiesto "o qualcosa in tal senso, in cui potresti essere in grado di cercare il problema e risolverlo rapidamente, ad es.
Dragon Energy
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.