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

38

Le domande possono sempre generare errori. Se si verifica un errore di questo tipo, l'utente deve ricevere una notifica, perché ciò che ha chiesto all'applicazione non è riuscito.

Tuttavia, quante informazioni dovrebbero essere fornite all'utente? Penso che molti di noi siano d'accordo nel non mostrare una traccia dello stack ( Dovrebbe esserci una traccia di 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, una lingua che supporta le eccezioni (.net, java) ha il tipo di eccezione da condividere, dove si è verificata l'eccezione e un messaggio un po 'chiarificatore da seguire con l'eccezione. Questo dovrebbe anche essere nascosto all'utente? O dovremmo mostrarlo comunque? O dovremmo mostrare un messaggio generico? o dovremmo mostrare uno di un numero di messaggi in base a quale sia l'eccezione di base?

    
posta Nzall 17.06.2014 - 16:40
fonte

6 risposte

34

what to show to the user. Should this also be hidden from the user?

Mostrate all'utente cosa è utilizzabile per loro.

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

Or should we show this anyway? Or should we show a generic message?

La visualizzazione dell'eccezione come contenuto principale del messaggio di errore è inutile per la maggior parte degli utenti . Forse se la tua base di utenti di riferimento sono gli sviluppatori, puoi sempre mostrare le informazioni come l'errore completo (forse hai un'applicazione interna per i test automatici). Ma generalmente gli utenti non possono fare nulla di diverso anche con quella conoscenza.

should we show one of a number of messages based on what the underlying exception is?

La migliore strategia consiste nel fare quanto segue:

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

Esempio

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

Tieni presente che in alcuni casi potresti voler rendere il rapporto errori manualmente o automatico.

    
risposta data 17.06.2014 - 16:52
fonte
12

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

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

Per le applicazioni interne utilizzate da altri sviluppatori, sono un po 'più rilassato sulla visualizzazione di 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 che 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 richiesto per copiare e incollare lo stack trace e inviarlo a te, anche se in realtà un modo molto migliore per farlo è chiedere a loro di inviare un file di log, o meglio ancora, fare in modo che l'applicazione invii un file di log allo sviluppatore, dopo aver chiesto al utente per il permesso di condividere il file.

    
risposta data 17.06.2014 - 16:48
fonte
1

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

Ciò dipenderà ovviamente dalla tua applicazione e base utente, ma dovrebbe essere il tuo principio guida - il tuo intento dovrebbe essere quello di fornire le informazioni necessarie per il "chiamante" per determinare cosa, se mai, possono fare per eseguire con successo l'azione desiderata. Se si tratta di qualcosa di semplice come un errore di accesso a un file, si fornisce un percorso file e il messaggio che non è possibile accedervi. Se si tratta di un'eccezione di puntatore nullo, basta dare un messaggio di errore generico.

Ovviamente ci saranno più messaggi "non in grado di eseguire l'azione desiderata" rispetto a quelli che l'utente può effettivamente correggere, ma è solo la vita - la maggior parte delle eccezioni sono perché abbiamo commesso un errore, non perché l'utente configurare l'ambiente in modo errato.

    
risposta data 17.06.2014 - 17:40
fonte
1

Questo è un tema comune:

Come puoi aiutare gli informatici non informati / informatici e allo stesso tempo mostrare le informazioni che possono essere utilizzate da utenti più avanzati come programmatori, sviluppatori, tester, ecc.

Penso che la risposta sia che tu faccia entrambi!

L'ordine è importante e ti consiglio di avere:

  • Che cosa è successo.
  • Che cosa fare ora
  • Dettagli tecnici

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

    
risposta data 14.07.2014 - 13:01
fonte
0

Quello che vuoi mostrare dipende da quanto ti vergogni di aver sbagliato.

Il punto è di ottenere i dettagli del mancato supporto tecnico nel modo più rapido e agevole possibile. Ciò potrebbe significare che tu invii automaticamente il file di registro, inclusa la traccia dello 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.

    
risposta data 21.12.2018 - 16:52
fonte
0

Mi piace la logica alla base della risposta accettata, ma devo rispettosamente non essere d'accordo almeno con la mia interpretazione di limitare l'informazione a ciò che è "utilizzabile" . Voglio sapere solo un po 'di teeny più di quello di un utente di "errore inaspettato" .

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

Anche se so poco dell'aviazione, dite che il mio volo è 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." Almeno in questi casi mi troverai un po 'più di un cliente scontento perché, anche se non influisce in alcun modo sul mio modo di agire, voglio solo sapere un po' di più sul perché sono inconveniente in questo modo come cliente pagante.

Se hanno appena detto "Stiamo vivendo un clima turbolento" o "Abbiamo avuto un'emergenza medica nel nostro precedente volo", o un malfunzionamento delle attrezzature o altro, è abbastanza per comprendermi molto più di "inaspettato" errore "ed essere un po 'più contento seduti intorno e aspettando 3 ore per il prossimo volo. In realtà potrei anche preferire un po 'di technobabble che mi passa per la testa a un "errore inaspettato" come, "Va bene, le parole che escono dalla tua bocca mi entrano nell'orecchio ma non raggiungono il processore centrale, ma ora capisco che c'è qualche tipo del problema e io vado a prendere un caffè e mi siedo là! Spero che voi ragazzi risolviate il problema con quel thingmajig! "

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 è successo nel sito catch , 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 quali potrebbero essere le informazioni molto tecniche allegate all'eccezione, ma almeno ci dice molto di più di "errore imprevisto". Fornisce almeno un contestuale "what / where / when" anche se non dice "why / how". Penso che almeno il desiderio di questo livello base di informazioni non sia particolarmente influenzato dal mio computer-savvy.

Il resto è probabilmente molto specifico per i tuoi clienti e esigenze particolari. Ma il mio appello è almeno per qualcosa solo un po 'più di un "errore inaspettato".

    
risposta data 21.12.2018 - 16:37
fonte