Testo del messaggio di errore - Best practice

Question

Stiamo cambiando parte del testo per i nostri vecchi messaggi di errore scritti male. Quali sono alcune risorse per le migliori pratiche sulla scrittura di buoni messaggi di errore (in particolare per Windows XP / Vista).

Answer 1

In termini di formulazione dei messaggi di errore, ti consiglio di fare riferimento alle seguenti guide di stile per le applicazioni Windows:

• Linee guida sull'esperienza utente di Windows , e in particolare la sezione sull'errore messaggi qui .
• Manuale di stile Microsoft

Answer 2

La migliore pratica finale è impedire all'utente di causare errori in primo luogo.

Non dire agli utenti nulla di cui non si preoccupano; il codice di errore 5064 non significa nulla per nessuno. Non dire loro che hanno fatto qualcosa di sbagliato; non consentirlo in primo luogo. Non incolparli, soprattutto non per errori commessi dal tuo software. Soprattutto, quando c'è un problema, digli come risolverlo in modo che possano andare avanti e fare un po 'di lavoro.

Answer 3

Un buon messaggio di errore dovrebbe:

• Sii discreto (niente schermo blu o schermo giallo della morte)
• Fornisci all'utente la direzione per correggere il problema (da solo, se possibile, o chi contattare per chiedere aiuto)
• Nascondi inutili sciocchezze esoteriche del programmatore (non dite, " si è verificata un'eccezione di riferimento null sulla riga 45 ")
• Sii descrittivo senza essere prolisso. Informazioni sufficienti per dire all'utente cosa devono sapere e niente di più.

Una cosa che ho iniziato a fare è generare un numero univoco che visualizzo nel messaggio di errore e scrivere nel file di registro in modo da poter trovare l'errore nel registro quando l'utente mi invia uno screenshot o chiama e dice , " Ho ricevuto un errore. Dice che il mio numero di riferimento è 0988-7634 "

Answer 4

Per motivi di sicurezza, non fornire informazioni sul sistema interno di cui l'utente non ha bisogno.
Esempio fondamentale: quando non riesci ad accedere, non dire all'utente se il nome utente è sbagliato o la password è sbagliata; questo aiuterà solo l'attaccante a forzare brutalmente il sistema. Invece, basta dire " Combinazione nome utente / password non valida " o qualcosa del genere.

Answer 5

Includi sempre suggerimenti per eliminare l'errore.

Answer 6

Prova a trovare un modo per scrivere il tuo software in modo che risolva il problema per loro.

Answer 7

Per qualsiasi input dell'utente (stringhe, nomi di file, valori, ecc.), visualizzare sempre il valore errato con delimitatori (virgolette, parentesi, ecc.). per es.

Impossibile trovare il nome file inserito: " somefile.txt "

Questo aiuta a mostrare tutti i ritorni di spazi bianchi / trasporto che possono essersi intrufolati e riduce notevolmente la risoluzione dei problemi e la frustrazione.

Answer 8

1. Evita messaggi di errore identici provenienti da luoghi diversi; parametrizza con file: line se possibile, oppure usa un altro contesto che consenta allo sviluppatore di identificare in modo univoco dove si è verificato l'errore.
2. Progetta il meccanismo per consentire una facile localizzazione, specialmente se si tratta di un prodotto commerciale.
3. Se i messaggi di errore sono visibili all'utente, renderli frasi complete e significative che non presuppongono una conoscenza intima del codice; ricorda, sei sempre troppo vicino al problema - l'utente no. Se possibile, fornire all'utente indicazioni su come procedere, chi contattare, ecc.
4. Se possibile, ogni errore dovrebbe contenere un messaggio; in caso contrario, cerca di assicurarti che tutti i percorsi di svolgimento degli errori alla fine raggiungano un messaggio di errore che faccia luce su ciò che è accaduto.
   
   Sono sicuro che ci saranno altre buone risposte qui ...

Answer 9

I messaggi più brevi possono effettivamente essere letti.

Più lungo è il tuo messaggio di errore, meno l'utente leggerà. Detto questo, prova a riformattare il codice in modo da poter eliminare le eccezioni in caso di risposta ovvia. Prova ad avere solo eccezioni che si verificano in base a cose al di fuori del tuo utente o del controllo del tuo codice.

Il miglior messaggio di eccezione è quello che non devi mai visualizzare.

Answer 10

Errore gestione è sempre meglio dell'errore segnalazione , ma dato che stai adattando i messaggi di errore e non necessariamente il codice ecco un paio di suggerimenti:

Gli utenti vogliono soluzioni, non problemi. Aiutali a sapere cosa fare dopo un errore, anche se il messaggio è semplice come " Chiudi la finestra corrente e riprova ad agire. & Quot;

Sono anche un grande fan della registrazione centralizzata degli errori. Assicurarsi che il registro sia scansionabile sia umano che computer. Gli utenti non ti fanno sempre sapere quali sono i loro problemi, soprattutto se possono essere "aggirati", quindi il registro può aiutarti a sapere quali cose devono essere risolti.

Se puoi controllare facilmente la finestra di dialogo di errore, avere una finestra di dialogo che mostra un messaggio piacevole e leggibile con un pulsante 'dettagli' per mostrare il numero di errore, la traccia, ecc. può essere di grande aiuto per la risoluzione dei problemi in tempo reale come bene.

Answer 11

Il supporto per multilingua si applica a tutti i tipi di messaggi, ma tende a essere dimenticato nel caso di messaggi di errore.

Answer 12

In secondo luogo non direi all'utente informazioni esoteriche inutili come codici numerici di errore. Seguirei tuttavia ciò dicendo di registrare definitivamente tali informazioni per la risoluzione dei problemi da parte di persone tecnicamente più esperte.