Messaggi di errore in Windows 7

Nota

Questa guida alla progettazione è stata creata per Windows 7 e non è stata aggiornata per le versioni più recenti di Windows. Gran parte delle linee guida si applica ancora in linea di principio, ma la presentazione e gli esempi non riflettono le linee guida di progettazione correnti.

I messaggi di errore in Windows 7 avvisano gli utenti dei problemi che si sono già verificati. Al contrario, i messaggi di avviso avvisano gli utenti di condizioni che potrebbero causare problemi in futuro. I messaggi di errore possono essere presentati tramite finestre di dialogo modali, messaggi sul posto, notifiche o aree.

Messaggio di errore modale tipico.

I messaggi di errore effettivi informano gli utenti che si sono verificati un problema, spiegano perché si è verificato e forniscono una soluzione in modo che gli utenti possano risolvere il problema. Gli utenti devono eseguire un'azione o modificarne il comportamento in seguito a un messaggio di errore.

Messaggi di errore utili e ben scritti sono fondamentali per un'esperienza utente di qualità. I messaggi di errore scritti in modo errato comportano una scarsa soddisfazione del prodotto e sono una causa principale dei costi di supporto tecnico evitabili. I messaggi di errore non necessari interrompono il flusso degli utenti.

Nota: Le linee guida relative a finestre di dialogo, messaggi di avviso, conferme, icone standard, notifiche e layout vengono presentate in articoli separati.

Si tratta dell'interfaccia utente corretta?

Per decidere, prendi in considerazione queste domande:

• L'interfaccia utente presenta un problema già riscontrato? In caso contrario, il messaggio non è un errore. Se l'utente viene avvisato di una condizione che potrebbe causare un problema in futuro, usare un messaggio di avviso.
• Il problema può essere impedito senza causare confusione? In tal caso, evitare il problema. Ad esempio, usare controlli vincolati a valori validi anziché usare controlli senza vincoli che potrebbero richiedere messaggi di errore. Inoltre, disabilitare i controlli quando si fa clic genera un errore, purché sia ovvio perché il controllo è disabilitato.
• Il problema può essere corretto automaticamente? In tal caso, gestire il problema e eliminare il messaggio di errore.
• È probabile che gli utenti eseguano un'azione o modifino il loro comportamento come risultato del messaggio? In caso contrario, la condizione non giustifica l'interruzione dell'utente, pertanto è preferibile eliminare l'errore.
• Il problema è rilevante quando gli utenti usano attivamente altri programmi? In tal caso, valutare la possibilità di visualizzare il problema usando un'icona dell'area di notifica.
• Il problema non è correlato all'attività utente corrente, non richiede un'azione immediata dell'utente e gli utenti possono ignorarlo liberamente? In tal caso, usare invece una notifica di errore dell'azione .
• Il problema riguarda lo stato di un'attività in background all'interno di una finestra primaria? In tal caso, valutare la possibilità di visualizzare il problema usando le barre di stato.
• Gli utenti IT di destinazione principali sono i professionisti IT? In tal caso, è consigliabile usare un meccanismo di feedback alternativo, ad esempio voci di file di log o avvisi di posta elettronica. I professionisti IT preferiscono fortemente i file di log per informazioni non critiche.

Concetti relativi alla progettazione

Caratteristiche dei messaggi di errore scadenti

Non dovrebbe sorprendere che ci siano molti messaggi di errore fastidiosi, inutili e mal scritti. Inoltre, poiché i messaggi di errore vengono spesso presentati usando dialoghi modali, interrompono l'attività corrente dell'utente e richiedono di essere riconosciuti prima di consentire all'utente di continuare.

Parte del problema è che ci sono così tanti modi per farlo male. Si considerino questi esempi della Sala messaggi di errore di Vergogna:

Messaggi di errore non necessari

Non corretto:

Questo esempio di Windows XP potrebbe essere il messaggio di errore peggiore mai. Indica che non è stato possibile avviare un programma perché Windows stesso è in fase di arresto. Non c'è nulla che l'utente può fare su questo o addirittura vuole eseguire questa operazione (l'utente ha scelto di arrestare Windows, dopo tutto). E visualizzando questo messaggio di errore, Windows impedisce di arrestarsi.

Il problema: Il messaggio di errore è il problema. A parte ignorare il messaggio di errore, non c'è nulla da fare per gli utenti.

Causa iniziale: Segnalazione di tutti i casi di errore, indipendentemente dagli obiettivi o dal punto di vista degli utenti.

Alternativa consigliata: Non segnalare errori che gli utenti non interessano.

Messaggi di errore "Operazione riuscita"

Non corretto:

Questo messaggio di errore è stato causato dalla scelta dell'utente di non riavviare Windows immediatamente dopo la rimozione del programma. La rimozione del programma ha avuto esito positivo dal punto di vista dell'utente.

Il problema: Non viene visualizzato alcun errore dal punto di vista dell'utente. A parte ignorare il messaggio di errore, non c'è nulla da fare per gli utenti.

Causa iniziale: L'attività è stata completata correttamente dal punto di vista dell'utente, ma non è riuscita dal punto di vista del programma di disinstallazione.

Alternativa consigliata: Non segnalare errori per le condizioni che gli utenti considerano accettabili.

Messaggi di errore completamente inutili

Non corretto:

Gli utenti imparano che si è verificato un errore, ma non hanno idea di cosa fosse l'errore o cosa fare. E no, non è ok!

Il problema: Il messaggio di errore non fornisce un problema specifico e non è possibile eseguire alcuna operazione da parte degli utenti.

Causa iniziale: Molto probabilmente, il programma ha una gestione degli errori scadente.

Alternativa consigliata: Progettare una buona gestione degli errori nel programma.

Messaggi di errore incomprensibili

Non corretto:

In questo esempio, l'istruzione del problema è chiara, ma la spiegazione supplementare è completamente sconcertante.

Il problema: L'istruzione o la soluzione del problema è incomprensibile.

Causa iniziale: Spiegazione del problema dal punto di vista del codice anziché da quello dell'utente.

Alternativa consigliata: Scrivere il testo del messaggio di errore che gli utenti di destinazione possono facilmente comprendere. Fornire soluzioni che gli utenti possono effettivamente eseguire. Progettare l'esperienza dei messaggi di errore del programma non prevede che i programmatori componino messaggi di errore sul posto.

Messaggi di errore che sovracommunicate

Non corretto:

In questo esempio, il messaggio di errore tenta apparentemente di spiegare ogni passaggio di risoluzione dei problemi.

Il problema: Troppe informazioni.

Causa iniziale: Troppi dettagli o tentativo di spiegare un processo di risoluzione dei problemi complicato all'interno di un messaggio di errore.

Alternativa consigliata: Evitare dettagli non necessari. Evitare anche gli strumenti di risoluzione dei problemi. Se è necessario uno strumento di risoluzione dei problemi, concentrarsi sulle soluzioni più probabili e spiegare il resto collegando l'argomento appropriato nella Guida.

Messaggi di errore inutilmente difficili

Non corretto:

L'impossibilità del programma di trovare un oggetto sembra quasi irreversibile. E supponendo che sia catastrofico, perché va bene la risposta?

Il problema: Il tono del programma è inutilmente duro o drammatico.

Causa iniziale: Il problema è dovuto a un bug che sembra irreversibile dal punto di vista del programma.

Alternativa consigliata: Scegliere con attenzione la lingua in base al punto di vista dell'utente.

Messaggi di errore che incolpano gli utenti

Non corretto:

Perché gli utenti si sentono come un criminale?

Il problema: Il messaggio di errore viene espresso in modo da accusare l'utente di aver generato un errore.

Causa iniziale: Formulazione senza distinzione che si concentra sul comportamento dell'utente anziché sul problema.

Alternativa consigliata: Concentrarsi sul problema, non sull'azione dell'utente che ha portato al problema, usando la voce passiva in base alle esigenze.

Messaggi di errore stupidi

Non corretto:

In questo esempio, l'istruzione del problema è piuttosto ironica e non vengono fornite soluzioni.

Il problema: Istruzioni del messaggio di errore stupide o non sequitor.

Causa iniziale: Creazione di messaggi di errore senza prestare attenzione al contesto.

Alternativa consigliata: I messaggi di errore vengono creati e rivisti da un writer. Quando si esaminano gli errori, considerare il contesto e lo stato di mente dell'utente.

Messaggi di errore del programmatore

Non corretto:

In questo esempio, il messaggio di errore indica che è presente un bug nel programma. Questo messaggio di errore ha significato solo per il programmatore.

Il problema: I messaggi destinati a aiutare gli sviluppatori del programma a trovare i bug vengono lasciati nella versione di rilascio del programma. Questi messaggi di errore non hanno significato o valore per gli utenti.

Causa iniziale: I programmatori usano la normale interfaccia utente per creare messaggi a se stessi.

Alternativa consigliata: Gli sviluppatori devono compilare in modo condizionale tutti questi messaggi in modo che vengano rimossi automaticamente dalla versione di rilascio di un prodotto. Non perdere tempo cercando di creare errori come questo comprensibile per gli utenti perché il loro unico pubblico è il programmatore.

Messaggi di errore non presentati correttamente

Non corretto:

Questo esempio presenta molti errori comuni di presentazione.

Il problema: Recupero di tutti i dettagli errati nella presentazione del messaggio di errore.

Causa iniziale: Non conoscendo e applicando le linee guida per i messaggi di errore. Non usare writer e editor per creare ed esaminare i messaggi di errore.

La natura della gestione degli errori è tale che molti di questi errori sono molto facili da fare. È inquietante rendersi conto che la maggior parte dei messaggi di errore potrebbe essere candidata alla Hall of Shame.

Caratteristiche dei messaggi di errore validi

A differenza degli esempi non validi precedenti, i messaggi di errore validi sono:

• Un problema. Indica che si è verificato un problema.
• Una causa. Spiega perché si è verificato il problema.
• Soluzione. Fornisce una soluzione in modo che gli utenti possano risolvere il problema.

Inoltre, vengono visualizzati messaggi di errore validi nel modo seguente:

• Rilevante. Il messaggio presenta un problema a cui gli utenti interessano.
• Eseguibili. Gli utenti devono eseguire un'azione o modificarne il comportamento come risultato del messaggio.
• Centrato sugli utenti. Il messaggio descrive il problema in termini di azioni o obiettivi dell'utente di destinazione, non in termini di ciò che il codice non è soddisfatto.
• Breve. Il messaggio è il più breve possibile, ma non più breve.
• Cancella. Il messaggio usa un linguaggio normale in modo che gli utenti di destinazione possano facilmente comprendere il problema e la soluzione.
• Specifico. Il messaggio descrive il problema usando una lingua specifica, assegnando nomi, posizioni e valori specifici degli oggetti coinvolti.
• Cortese. Gli utenti non devono essere incolpati o fatti per sentirsi stupidi.
• Raro. Visualizzato raramente. I messaggi di errore visualizzati di frequente sono un segno di progettazione non valida.

Progettando l'esperienza di gestione degli errori in modo da avere queste caratteristiche, è possibile mantenere i messaggi di errore del programma fuori dalla Sala messaggi di errore di vergogna.

Evitare messaggi di errore non necessari

Spesso il messaggio di errore migliore non è un messaggio di errore. Molti errori possono essere evitati tramite una progettazione migliore e spesso esistono alternative migliori ai messaggi di errore. In genere è preferibile evitare un errore che segnalare uno.

I messaggi di errore più evidenti da evitare sono quelli che non sono interattivi. Se gli utenti potrebbero ignorare il messaggio senza eseguire alcuna operazione o modificarlo, omettere il messaggio di errore.

Alcuni messaggi di errore possono essere eliminati perché non sono problemi dal punto di vista dell'utente. Si supponga, ad esempio, che l'utente abbia tentato di eliminare un file già in corso di eliminazione. Anche se questo potrebbe essere un caso imprevisto dal punto di vista del codice, gli utenti non considerano questo errore perché viene raggiunto il risultato desiderato.

Non corretto:

Questo messaggio di errore deve essere eliminato perché l'azione ha avuto esito positivo dal punto di vista dell'utente.

Per un altro esempio, si supponga che l'utente annulla esplicitamente un'attività. Per il punto di vista dell'utente, la condizione seguente non è un errore.

Non corretto:

Questo messaggio di errore deve essere eliminato anche perché l'azione ha avuto esito positivo dal punto di vista dell'utente.

A volte i messaggi di errore possono essere eliminati concentrandosi sugli obiettivi degli utenti anziché sulla tecnologia. In questo modo, riconsiderare ciò che è veramente un errore. Il problema riguarda gli obiettivi dell'utente o la capacità del programma di soddisfarli? Se l'azione dell'utente ha senso anche nel mondo reale, dovrebbe avere senso anche nel software.

Si supponga, ad esempio, che all'interno di un programma di e-commerce un utente tenti di trovare un prodotto usando la ricerca, ma la query di ricerca letterale non ha corrispondenze e che il prodotto desiderato non sia disponibile. Tecnicamente, si tratta di un errore, ma invece di fornire un messaggio di errore, il programma potrebbe:

• Continuare a cercare i prodotti più vicini alla query.
• Se la ricerca presenta errori evidenti, consigliare automaticamente una query corretta.
• Gestire automaticamente i problemi comuni, ad esempio errori di ortografia, ortografia alternativa e casi di pluralizzazione e verbi non corrispondenti.
• Indicare quando il prodotto sarà in magazzino.

Se la richiesta dell'utente è ragionevole, un programma di e-commerce ben progettato dovrebbe restituire risultati ragionevoli non errori.

Un altro ottimo modo per evitare i messaggi di errore consiste nel prevenire i problemi in primo luogo. È possibile evitare errori in base a:

• Uso di controlli vincolati. Usare i controlli vincolati a valori validi. I controlli come elenchi, dispositivi di scorrimento, caselle di controllo, pulsanti di opzione e selezione data e ora sono vincolati a valori validi, mentre le caselle di testo spesso non sono e potrebbero richiedere messaggi di errore. Tuttavia, è possibile vincolare le caselle di testo per accettare solo determinati caratteri e accettare un numero massimo di caratteri.
• Uso delle interazioni vincolate. Per le operazioni di trascinamento, consentire agli utenti di rilasciare solo le destinazioni valide.
• Uso di controlli e voci di menu disabilitati. Disabilitare i controlli e le voci di menu quando gli utenti possono dedurre facilmente il motivo per cui il controllo o la voce di menu è disabilitata.
• Specificare valori predefiniti validi. È meno probabile che gli utenti verifichino errori di input se possono accettare i valori predefiniti. Anche se gli utenti decidono di modificare il valore, il valore predefinito consente agli utenti di conoscere il formato di input previsto.
• Fare cose solo lavoro. Gli utenti hanno meno probabilità di fare errori se le attività non sono necessarie o eseguite automaticamente per loro. O se gli utenti fanno piccoli errori, ma la loro intenzione è chiara, il problema viene risolto automaticamente. Ad esempio, è possibile correggere automaticamente problemi di formattazione secondari.

Specificare i messaggi di errore necessari

A volte è necessario specificare un messaggio di errore. Gli utenti fanno errori, reti e dispositivi arrestano il funzionamento, gli oggetti non possono essere trovati o modificati, le attività non possono essere completate e i programmi hanno bug. Idealmente, questi problemi si verificherebbero meno spesso, possiamo progettare il nostro software per evitare molti tipi di errori utente, ma non è realistico prevenire tutti questi problemi. E quando si verifica uno di questi problemi, un messaggio di errore utile recupera rapidamente gli utenti sui loro piedi.

Una convinzione comune è che i messaggi di errore sono l'esperienza utente peggiore e devono essere evitati a tutti i costi, ma è più accurato dire che la confusione dell'utente è l'esperienza peggiore e deve essere evitata a tutti i costi. A volte questo costo è un messaggio di errore utile.

Prendere in considerazione i controlli disabilitati. La maggior parte del tempo, è ovvio perché un controllo è disabilitato, quindi la disabilitazione del controllo è un ottimo modo per evitare un messaggio di errore. Tuttavia, cosa accade se il motivo per cui un controllo è disabilitato non è ovvio? L'utente non può procedere e non esiste alcun feedback per determinare il problema. Ora l'utente è bloccato e deve dedurre il problema o ottenere supporto tecnico. In questi casi, è molto meglio lasciare abilitato il controllo e fornire un messaggio di errore utile.

Non corretto:

Perché il pulsante Avanti è disabilitato qui? Meglio lasciarlo abilitato ed evitare confusione utente dando un messaggio di errore utile.

Se non si è certi se si deve assegnare un messaggio di errore, iniziare scrivendo il messaggio di errore che si potrebbe assegnare. Se gli utenti possono eseguire un'azione o modificare il comportamento come risultato, specificare il messaggio di errore. Al contrario, se gli utenti potrebbero ignorare il messaggio senza eseguire o modificare alcun elemento, omettere il messaggio di errore.

Progettazione per una corretta gestione degli errori

Durante la creazione di un buon testo del messaggio di errore può essere difficile, a volte è impossibile senza un buon supporto per la gestione degli errori dal programma. Prendere in considerazione questo messaggio di errore:

Non corretto:

È probabile che il problema sia davvero sconosciuto perché il supporto per la gestione degli errori del programma manca.

Sebbene sia possibile che si tratti di un messaggio di errore molto poco scritto, è più probabile che rifletta la mancanza di una corretta gestione degli errori dal codice sottostante non sono presenti informazioni specifiche sul problema.

Per creare messaggi di errore specifici, utilizzabili, centrati dall'utente, il codice di gestione degli errori del programma deve fornire informazioni di errore specifiche e di alto livello:

• Ogni problema deve avere un codice di errore univoco assegnato.
• Se un problema ha diverse cause, il programma deve determinare la causa specifica ogni volta che possibile.
• Se il problema ha parametri, i parametri devono essere mantenuti.
• I problemi di basso livello devono essere gestiti a un livello sufficientemente elevato in modo che il messaggio di errore possa essere presentato dal punto di vista dell'utente.

I messaggi di errore validi non sono solo un problema dell'interfaccia utente, sono un problema di progettazione software. Una buona esperienza di messaggio di errore non è qualcosa che può essere usata in un secondo momento.

Risoluzione dei problemi (e come evitarlo)

Risoluzione dei problemi quando viene segnalato un problema con diverse cause con un singolo messaggio di errore.

Non corretto:

Corretto:

Risoluzione dei problemi quando vengono segnalati diversi problemi con un singolo messaggio di errore.

Nell'esempio seguente non è stato possibile spostare un elemento perché è già stato spostato o eliminato o è stato negato l'accesso. Se il programma può determinare facilmente la causa, perché mettere il carico sull'utente per determinare la causa specifica?

Non corretto:

Beh, qual è? Ora l'utente deve risolvere i problemi.

Il programma può determinare se l'accesso è stato negato, quindi questo problema deve essere segnalato con un messaggio di errore specifico.

Corretto:

Con una causa specifica, non è necessaria alcuna risoluzione dei problemi.

Usare i messaggi con più cause solo quando non è possibile determinare la causa specifica. In questo esempio, sarebbe difficile determinare se l'elemento è stato spostato o eliminato, quindi un singolo messaggio di errore con più cause potrebbe essere usato qui. Tuttavia, è improbabile che gli utenti siano interessati se, ad esempio, non è stato possibile spostare un file eliminato. Per queste cause, il messaggio di errore non è nemmeno necessario.

Gestione degli errori sconosciuti

In alcuni casi, non si conoscerà il problema, la causa o la soluzione. Se non sarebbe opportuno eliminare l'errore, è preferibile essere davanti alla mancanza di informazioni che per presentare problemi, cause o soluzioni che potrebbero non essere corrette.

Ad esempio, se il programma ha un'eccezione non gestita, il messaggio di errore seguente è adatto:

Se non è possibile eliminare un errore sconosciuto, è preferibile essere davanti alla mancanza di informazioni.

D'altra parte, fornire informazioni specifiche, utilizzabili se è probabile che sia utile la maggior parte del tempo.

Questo messaggio di errore è adatto per un errore sconosciuto se la connettività di rete è in genere il problema.

Determinare il tipo di messaggio appropriato

Alcuni problemi possono essere presentati come errore, avviso o informazioni, a seconda dell'enfasi e della formulazione. Si supponga, ad esempio, che una pagina Web non possa caricare un controllo ActiveX senza segno in base alla configurazione corrente di Windows Internet Explorer:

• Errore. "Questa pagina non può caricare un controllo ActiveX senza segno". (Frase come problema esistente).
• Avviso. "Questa pagina potrebbe non comportarsi come previsto perché Windows Internet Explorer non è configurato per caricare controlli ActiveX senza segno." o "Consenti a questa pagina di installare un controllo ActiveX non firmato? In questo modo da origini non attendibili può danneggiare il computer." Entrambe le frasi come condizioni che possono causare problemi futuri.
• Informazioni. "È stato configurato Windows Internet Explorer per bloccare i controlli ActiveX non firmati". (Frase come un'istruzione di fatto.

Per determinare il tipo di messaggio appropriato, concentrarsi sull'aspetto più importante del problema su cui gli utenti devono conoscere o agire. In genere, se un problema impedisce all'utente di procedere, è necessario presentarlo come errore; se l'utente può procedere, presentarlo come avviso. Creare l'istruzione principale o altro testo corrispondente in base a tale stato attivo, quindi scegliere un'icona (standard o altrimenti) corrispondente al testo. Il testo e le icone delle istruzioni principali devono sempre corrispondere.

Presentazione del messaggio di errore

La maggior parte dei messaggi di errore nei programmi Windows viene presentata usando finestre di dialogo modali (come sono la maggior parte degli esempi in questo articolo), ma sono disponibili altre opzioni:

• Sul posto
• Palloncini
• Notifiche
• Icone dell'area di notifica
• Barre di stato
• File di log (per errori destinati ai professionisti IT)

L'inserimento di messaggi di errore nelle finestre di dialogo modali offre il vantaggio di richiedere l'attenzione e il riconoscimento immediato dell'utente. Tuttavia, questo è anche il loro svantaggio principale se tale attenzione non è necessaria.

È davvero necessario interrompere gli utenti in modo che possano fare clic sul pulsante Chiudi? In caso contrario, prendere in considerazione le alternative all'uso di una finestra di dialogo modale.

I dialoghi modali sono una scelta ottimale quando l'utente deve riconoscere il problema immediatamente prima di continuare, ma spesso una scelta scarsa in caso contrario. In genere, è consigliabile usare la presentazione di peso più leggera che fa il lavoro bene.

Evitare di sovracommunicare

In genere, gli utenti non leggono, eseguono l'analisi. Più testo c'è, più difficile è la scansione del testo e più probabilmente gli utenti non leggeranno affatto il testo. Di conseguenza, è importante ridurre il testo ai suoi elementi essenziali e usare i collegamenti di diffusione progressiva e Guida quando necessario per fornire informazioni aggiuntive.

Esistono molti esempi estremi, ma diamo un'occhiata a una più tipica. L'esempio seguente include la maggior parte degli attributi di un messaggio di errore valido, ma il testo non è conciso e richiede la motivazione per leggere.

Non corretto:

Questo esempio è un messaggio di errore valido, ma sovramunica.

Che cosa dice davvero tutto questo testo? Qualcosa di analogo a quanto segue:

Corretto:

Questo messaggio di errore contiene essenzialmente le stesse informazioni, ma è molto più conciso.

Utilizzando la Guida per fornire i dettagli, questo messaggio di errore presenta uno stile di presentazione invertito a piramide .

Per altre linee guida ed esempi sull'overcommunicating, vedere Testo dell'interfaccia utente.

Se si eseguono solo otto operazioni

1. Progettare il programma per la gestione degli errori.
2. Non fornire messaggi di errore non necessari.
3. Evitare confusione dell'utente fornendo messaggi di errore necessari.
4. Assicurarsi che il messaggio di errore restituisca un problema, una causa e una soluzione.
5. Assicurarsi che il messaggio di errore sia rilevante, interattivo, breve, chiaro, specifico, corteggiante e raro.
6. Progettare messaggi di errore dal punto di vista dell'utente, non dal punto di vista del programma.
7. Evitare di coinvolgere l'utente nella risoluzione dei problemi, usare un messaggio di errore diverso per ogni causa rilevabile.
8. Usare il metodo di presentazione con peso più leggero che esegue correttamente il processo.

Modelli di utilizzo

I messaggi di errore hanno diversi modelli di utilizzo:

Etichetta	Valore
Problemi di sistema Il sistema operativo, il dispositivo hardware, la rete o il programma non è riuscito o non è nello stato necessario per eseguire un'attività.	Molti problemi di sistema possono essere risolti dall'utente: I problemi del dispositivo possono essere risolti attivando il dispositivo, riconnettendo il dispositivo e inserendo i supporti. I problemi di rete possono essere risolti controllando la connessione alla rete fisica ed eseguendo diagnosi e riparazione della rete. I problemi del programma possono essere risolti modificando le opzioni del programma o riavviando il programma. In questo esempio il programma non riesce a trovare una fotocamera per eseguire un'attività utente. In questo esempio è necessario attivare una funzionalità necessaria per eseguire un'attività.
Problemi relativi ai file Non è stato trovato un file o una cartella necessaria per un'attività avviata dall'utente, è già in uso o non ha il formato previsto.	In questo esempio il file o la cartella non possono essere eliminati perché non è stato trovato. In questo esempio il programma non supporta il formato di file specificato.
Problemi di sicurezza L'utente non dispone dell'autorizzazione per accedere a una risorsa o privilegi sufficienti per eseguire un'attività avviata dall'utente.	In questo esempio l'utente non dispone dell'autorizzazione per accedere a una risorsa. In questo esempio l'utente non ha il privilegio di eseguire un'attività.
Problemi relativi alle attività Si è verificato un problema specifico durante l'esecuzione di un'attività avviata dall'utente (diverso da un sistema, file non trovato, formato di file o problema di sicurezza).	In questo esempio i dati degli Appunti non possono essere incollati in Paint. In questo esempio l'utente non può installare un aggiornamento software.
Problemi di input dell'utente L'utente ha immesso un valore non corretto o incoerente con altri input dell'utente.	In questo esempio l'utente ha immesso un valore di ora non corretto. In questo esempio l'input dell'utente non è nel formato corretto.

Indicazioni

Presentazione

• Usare le finestre di dialogo delle attività ogni volta che è appropriato per ottenere un aspetto e un layout coerenti. Le finestre di dialogo attività richiedono Windows Vista o versioni successive, quindi non sono adatte per le versioni precedenti di Windows. Se è necessario utilizzare una finestra di messaggio, separare l'istruzione principale dall'istruzione supplementare con due interruzioni di riga.

Errori di input dell'utente

• Quando possibile, prevenire o ridurre gli errori di input dell'utente in base a:
  • Utilizzo di controlli vincolati a valori validi.
  • La disabilitazione di controlli e voci di menu quando si fa clic genera un errore, purché sia ovvio perché la voce di controllo o di menu è disabilitata.
  • Specificare valori predefiniti validi.

Non corretto:

In questo esempio viene usata una casella di testo senza vincoli per l'input vincolato. Usare invece un dispositivo di scorrimento.

• Usare la gestione degli errori in modalità (errori sul posto o aree) per i problemi di input dell'utente contestuale.
• Usare le aree per problemi di input utente non critici e a punto singolo rilevati mentre si trova in una casella di testo o immediatamente dopo che una casella di testo perde lo stato attivo.I palloncini non richiedono lo spazio disponibile sullo schermo o il layout dinamico necessario per visualizzare i messaggi sul posto. Consente di visualizzare solo un singolo fumetto alla volta. Poiché il problema non è critico, non è necessaria alcuna icona di errore. Le aree vengono rimosse quando si fa clic, quando il problema viene risolto o dopo un timeout.

In questo esempio, un fumetto indica un problema di input mentre è ancora nel controllo .

• Usare gli errori sul posto per il rilevamento ritardato degli errori, in genere errori rilevati facendo clic su un pulsante di commit. Non usare errori sul posto per le impostazioni di cui viene immediatamente eseguito il commit. Possono essere presenti più errori sul posto alla volta. Usa il testo normale e un'icona di errore di 16x16 pixel, posizionandoli direttamente accanto al problema quando possibile. Gli errori sul posto non vengono allontanati a meno che l'utente non esegua il commit e non vengano trovati altri errori.

In questo esempio viene usato un errore sul posto per un errore trovato facendo clic sul pulsante commit.

• Usare la gestione degli errori modali (finestre di dialogo attività o finestre di messaggio) per tutti gli altri problemi, inclusi gli errori che coinvolgono più controlli o sono errori non contestuali o non di input rilevati facendo clic su un pulsante di commit.
• Quando viene segnalato un problema di input dell'utente, impostare lo stato attivo dell'input sul primo controllo con i dati non corretti. Se necessario, scorrere il controllo nella visualizzazione. Se il controllo è una casella di testo, selezionare l'intero contenuto. Dovrebbe essere sempre ovvio a cosa fa riferimento il messaggio di errore.
• Non cancellare l'input non corretto. Lasciare invece il problema in modo che l'utente possa visualizzare e risolvere il problema senza ricominciare.
  • Eccezione: Deselezionare le caselle di testo password e PIN non corrette perché gli utenti non possono correggere l'input mascherato in modo efficace.

Risoluzione dei problemi

• Evitare di creare problemi di risoluzione dei problemi. Non fare affidamento su un singolo messaggio di errore per segnalare un problema con diverse cause rilevabili.
• Usare un messaggio di errore diverso (in genere un'istruzione supplementare diversa) per ogni causa rilevabile. Ad esempio, se un file non può essere aperto per diversi motivi, fornire un'istruzione supplementare separata per ogni motivo.
• Usare un messaggio con più cause solo quando non è possibile determinare la causa specifica. In questo caso, presentare le soluzioni in ordine di probabilità di risolvere il problema. In questo modo, gli utenti possono risolvere il problema in modo più efficiente.

Icone

• Le finestre di dialogo dei messaggi di errore modali non hanno icone della barra del titolo. Le icone della barra del titolo vengono usate come distinzione visiva tra le finestre primarie e le finestre secondarie.

• Usare un'icona di errore. Eccezioni:

  • Se l'errore è un problema di input dell'utente visualizzato usando una finestra di dialogo modale o un fumetto, non usare un'icona. In questo modo è contro il tono incoraggiante di Windows. Tuttavia, i messaggi di errore sul posto devono usare una piccola icona di errore (16x16 pixel) per identificarli chiaramente come messaggi di errore.

    

    

    In questi esempi, i problemi di input dell'utente non richiedono icone di errore.

    

    In questo esempio un messaggio di errore sul posto richiede un'icona di errore piccola per identificarla chiaramente come messaggio di errore.

• Se il problema riguarda una funzionalità con un'icona (e non un problema di input dell'utente), è possibile usare l'icona della funzionalità con una sovrimpressione degli errori. In questo caso, usare anche il nome della funzionalità come oggetto dell'errore.

  

  In questo esempio, l'icona della funzionalità presenta una sovrimpressione degli errori e la funzionalità è l'oggetto dell'errore.

• Non usare icone di avviso per gli errori. Questa operazione viene spesso eseguita per rendere la presentazione meno grave. Gli errori non sono avvisi.

  Non corretto:

  

  In questo esempio viene usata erroneamente un'icona di avviso per rendere l'errore meno grave.

Per altre linee guida ed esempi, vedere Icone standard.

Rivelazione progressiva

• Usare un pulsante Mostra/Nascondi dettagli di divulgazione progressiva per nascondere informazioni avanzate o dettagliate in un messaggio di errore. In questo modo si semplifica il messaggio di errore per l'utilizzo tipico. Non nascondere le informazioni necessarie, perché gli utenti potrebbero non trovarlo.

In questo esempio il pulsante di divulgazione progressiva consente agli utenti di eseguire il drill-down in modo più dettagliato se lo desiderano o semplificare l'interfaccia utente in caso contrario.

• Non usare Mostra/Nascondi dettagli a meno che non siano presenti dettagli più dettagliati. Non riformulare solo le informazioni esistenti in un formato più dettagliato.
• Non usare Mostra/Nascondi dettagli per visualizzare le informazioni della Guida. Usare invece i collegamenti della Guida.

Per le linee guida per l'etichettatura, vedere Controlli di divulgazione progressiva.

Non visualizzare più questo messaggio

• Se un messaggio di errore richiede questa opzione, riconsiderare l'errore e la relativa frequenza. Se ha tutte le caratteristiche di un errore valido (rilevante, interattivo e poco frequente), non dovrebbe essere opportuno per gli utenti eliminarlo.

Per altre linee guida, vedere Finestre di dialogo.

Valori predefiniti

• Selezionare la risposta più sicura, meno distruttiva o più sicura per essere l'impostazione predefinita. Se la sicurezza non è un fattore, selezionare il comando più probabile o pratico.

Help

• Progettare i messaggi di errore per evitare la necessità di assistenza. In genere, gli utenti non devono leggere testo esterno per comprendere e risolvere il problema, a meno che la soluzione non richieda diversi passaggi.
• Assicurarsi che il contenuto della Guida sia rilevante e utile. Non dovrebbe essere una riformulazione dettagliata del messaggio di errore, ma deve contenere informazioni utili oltre l'ambito del messaggio di errore, ad esempio modi per evitare il problema in futuro. Non fornire un collegamento alla Guida solo perché è possibile.
• Usare collegamenti della Guida specifici, concisi e pertinenti per accedere al contenuto della Guida. Non usare pulsanti di comando o divulgazione progressiva a questo scopo.
• Per i messaggi di errore che non è possibile rendere specifici e interattivi, è consigliabile fornire collegamenti al contenuto della Guida online. In questo modo, è possibile fornire agli utenti informazioni aggiuntive che è possibile aggiornare dopo il rilascio del programma.

Per altre linee guida, vedere La Guida.

Codici di errore

• Per i messaggi di errore che non è possibile rendere specifici e interattivi o che traggono vantaggio dalla Guida, è consigliabile fornire anche codici di errore. Gli utenti spesso usano questi codici di errore per cercare informazioni aggiuntive su Internet.
• Fornire sempre una descrizione testuale del problema e della soluzione. Non dipendere solo dal codice di errore per questo scopo.

Non corretto:

In questo esempio viene usato un codice di errore come sostituto di un testo della soluzione.

• Assegnare un codice di errore univoco per ogni causa diversa. In questo modo si evita la risoluzione dei problemi.
• Scegliere i codici di errore facilmente ricercabili in Internet. Se si usano codici a 32 bit, usare una rappresentazione esadecimale con caratteri iniziali "0x" e maiuscoli.

Corretto:

1234

0xC0001234

Non corretto:

-1

-67113524

• Usare Mostra/Nascondi dettagli per visualizzare i codici di errore. Frase come codice errore: <error code>.

In questo esempio viene usato un codice di errore per integrare un messaggio di errore che può trarre vantaggio da ulteriori informazioni.

Suoni

• Non accompagnare i messaggi di errore con un effetto sonoro o un segnale acustico. In questo modo è inutile e inutile.
  • Eccezione: Riprodurre l'effetto sonoro Stop critico se il problema è fondamentale per il funzionamento del computer e l'utente deve intervenire immediatamente per evitare gravi conseguenze.

Testo

Generale

• Rimuovere il testo ridondante. Cercala nei titoli, nelle istruzioni principali, nelle istruzioni supplementari, nei collegamenti ai comandi e nei pulsanti di commit. In genere, lasciare il testo completo nelle istruzioni e nei controlli interattivi e rimuovere qualsiasi ridondanza dalle altre posizioni.
• Usare le spiegazioni incentrate sugli utenti. Descrivere il problema in termini di azioni o obiettivi dell'utente, non in termini di ciò che il software è infelice con. Usare la lingua che gli utenti di destinazione conoscono e usano. Evitare il gergo tecnico.

Non corretto:

Corretto:

In questi esempi la versione corretta parla la lingua dell'utente, mentre la versione errata è eccessivamente tecnica.

• Non usare le parole seguenti:
  • Errore, errore (usare il problema)
  • Impossibile (non è possibile usare invece)
  • Illegale, non valido, cattivo (usare invece non corretto)
  • Interrompere, uccidere, terminare (usare invece stop)
  • Irreversibile, irreversibile (usare invece grave)

Questi termini non sono necessari e contrariamente al tono incoraggiante di Windows. Se usato correttamente, l'icona di errore comunica sufficientemente che si verifica un problema.

Non corretto:

Corretto:

Nell'esempio errato i termini "irreversibili" e "errore" non sono necessari.

• Non usare la frase che accusa l'utente o implica l'errore dell'utente. Evitare di usare te e il tuo nel fraseggio. Anche se la voce attiva è in genere preferita, usare la voce passiva quando l'utente è l'oggetto e potrebbe sentirsi incolpato dell'errore se la voce attiva è stata usata.

Non corretto:

Corretto:

L'esempio errato incolpa l'utente usando la voce attiva.

• Essere specifici. Evitare parole vaghe, ad esempio l'errore di sintassi e l'operazione illegale. Specificare nomi, posizioni e valori specifici degli oggetti coinvolti.

Non corretto:

File non trovato.

Disco pieno.

Valore non compreso nell'intervallo.

Carattere non valido.

Dispositivo non disponibile.

Questi problemi sarebbero molto più facili da risolvere con nomi, posizioni e valori specifici.

• Non dare probabilmente problemi, cause o soluzioni in un tentativo di essere specifici. Non fornire un problema, una causa o una soluzione, a meno che non sia probabile che sia giusto. Ad esempio, è preferibile dire che si è verificato un errore sconosciuto rispetto a qualcosa che è probabile che non sia accurato.
• Evitare la parola "per favore", ad eccezione di situazioni in cui l'utente viene chiesto di fare qualcosa di scomodo (ad esempio in attesa) o il software è in colpa per la situazione.

Corretto:

Attendere mentre Windows copia i file nel computer.

• Usare la parola "sorry" solo nei messaggi di errore che causano problemi gravi per l'utente (ad esempio, perdita di dati o impossibilità di usare il computer). Non scusarsi se il problema si è verificato durante il normale funzionamento del programma (ad esempio, se l'utente deve attendere che venga trovata una connessione di rete).

Corretto:

Ci dispiace, ma Fabrikam Backup ha rilevato un problema non recuperabile ed è stato arrestato per proteggere i file nel computer.

• Fare riferimento ai prodotti che usano i nomi brevi. Non usare nomi di prodotti completi o simboli di marchio. Non includere il nome della società a meno che gli utenti non associano il nome della società al prodotto. Non includere i numeri di versione del programma.

Non corretto:

Corretto:

Nell'esempio errato vengono usati nomi di prodotti completi e simboli di marchio.

• Usare virgolette doppie intorno ai nomi degli oggetti. In questo modo il testo risulta più semplice da analizzare ed evitare dichiarazioni potenzialmente imbarazzanti.
  • Eccezione: I percorsi di file, gli URL e i nomi di dominio completi non devono essere inclusi tra virgolette doppie.

Corretto:

In questo esempio il messaggio di errore risulterebbe confuso se il nome dell'oggetto non era tra virgolette.

• Evitare di iniziare frasi con nomi di oggetti. Questa operazione è spesso difficile da analizzare.
• Non usare segni esclamativi o parole con tutte le lettere maiuscole. I segni esclamativi e le lettere maiuscole fanno sentire come si sta gridando all'utente.

Per altre linee guida ed esempi, vedere Stile e Tono.

Titoli

• Usare il titolo per identificare il comando o la funzionalità da cui è stato generato l'errore. Eccezioni:
  • Se viene visualizzato un errore da molti comandi diversi, è consigliabile usare invece il nome del programma.
  • Se il titolo sarebbe ridondante o confuso con l'istruzione principale, usare invece il nome del programma.
• Non usare il titolo per spiegare o riepilogare il problema che è lo scopo dell'istruzione principale.

Non corretto:

In questo esempio il titolo viene usato in modo errato per spiegare il problema.

• Usare la maiuscola in stile titolo, senza terminare la punteggiatura.

Istruzioni principali

• Usare l'istruzione principale per descrivere il problema in linguaggio chiaro, normale e specifico.
• Usare conciso solo una singola frase completa. Pare l'istruzione principale fino alle informazioni essenziali. È possibile lasciare l'oggetto implicito se è il programma o l'utente. Includere il motivo del problema se è possibile farlo in modo conciso. Se è necessario spiegare qualcosa di più, usare un'istruzione supplementare.

Non corretto:

In questo esempio l'intero messaggio di errore viene inserito nell'istruzione principale, rendendo difficile la lettura.

• Specificare se sono presenti oggetti coinvolti, assegnare i nomi.
• Evitare di inserire percorsi di file completi e URL nell'istruzione principale. Invece, usare un nome breve (ad esempio il nome del file) e inserire il nome completo (ad esempio il percorso del file) nell'istruzione supplementare. Tuttavia, è possibile inserire un singolo percorso completo o UN URL nell'istruzione principale se il messaggio di errore non richiede in caso contrario un'istruzione supplementare.

In questo esempio, solo il nome del file è nell'istruzione principale. Il percorso completo è nell'istruzione supplementare.

• Non assegnare il percorso completo e l'URL del file se è ovvio dal contesto.

In questo esempio l'utente sta ridenominando un file da Esplora risorse. In questo caso, il percorso completo del file non è necessario perché è ovvio dal contesto.

• Usare la tensione presente ogni volta che è possibile.
• Usare le maiuscole/minuscole come nelle frasi comuni.
• Non includere periodi finali se l'istruzione è un'istruzione. Se l'istruzione è una domanda, includere un punto interrogativo finale.

Modelli di istruzione principali

Sebbene non siano presenti regole rigorose per la formulazione, provare a usare i modelli di istruzione principali seguenti ogni volta che possibile:

• [nome soggetto facoltativo] non può [eseguire l'azione]
• [nome soggetto facoltativo] non può [eseguire l'azione] perché [motivo]
• [nome soggetto facoltativo] non può [eseguire l'azione] su "[nome oggetto]"
• [nome soggetto facoltativo] non può [eseguire l'azione] su "[nome oggetto]" perché [motivo]
• Non è sufficiente [risorsa] per [eseguire l'azione]
• [Nome soggetto] non ha un [nome oggetto] obbligatorio per [scopo]
• [Dispositivo o impostazione] è disattivato in modo che [risultati indesiderati]
• [Dispositivo o impostazione] non è [disponibile | trovato | attivato | abilitato]
• "[nome oggetto]" non è attualmente disponibile
• Il nome utente o la password non sono corretti
• Non si dispone dell'autorizzazione per accedere a "[nome oggetto]"
• Non si dispone dei privilegi per [eseguire l'azione]
• [nome programma] ha riscontrato un problema grave e deve chiudersi immediatamente

Naturalmente, apportare modifiche in base alle esigenze affinché l'istruzione principale sia grammaticalmente corretta e conforme alle linee guida principali per le istruzioni.

Istruzioni supplementari

• Usare l'istruzione supplementare per:
  • Fornire dettagli aggiuntivi sul problema.
  • Spiegare la causa del problema.
  • Elencare i passaggi che l'utente può eseguire per risolvere il problema.
  • Fornire misure per impedire la ricorsione del problema.
• Quando possibile, proporre una soluzione pratica e utile in modo che gli utenti possano risolvere il problema. Tuttavia, assicurarsi che la soluzione proposta possa risolvere il problema. Non sprecare tempo agli utenti suggerendo soluzioni possibili, ma improbabili.

Non corretto:

In questo esempio, mentre il problema e la soluzione consigliata sono possibili, sono molto improbabili.

• Se il problema è un valore non corretto immesso dall'utente, usare l'istruzione supplementare per spiegare i valori corretti. Gli utenti non devono determinare queste informazioni da un'altra origine.
• Non fornire una soluzione se può essere dedotto in modo semplice dall'istruzione del problema.

In questo esempio non è necessaria alcuna istruzione supplementare; la soluzione può essere dedotta in modo semplice dall'istruzione del problema.

• Se la soluzione include più passaggi, presentare i passaggi nell'ordine in cui devono essere completati. Tuttavia, evitare soluzioni in più passaggi perché gli utenti hanno difficoltà a ricordare più di due o tre semplici passaggi. Se sono necessari altri passaggi, fare riferimento all'argomento della Guida appropriato.
• Mantenere concise le istruzioni supplementari. Specificare solo ciò che gli utenti devono sapere. Omettere i dettagli non necessari. Mirare a un massimo di tre frasi di lunghezza moderata.
• Per evitare errori mentre gli utenti eseguono istruzioni, inserire i risultati prima dell'azione.

Corretto:

Per riavviare Windows, fare clic su OK.

Non corretto:

Fare clic su OK per riavviare Windows.

Nell'esempio errato, è più probabile che gli utenti facciano clic su OK per caso.

• Non consigliare di contattare un amministratore a meno che non si verifichi questa operazione sia tra le soluzioni più probabili al problema. Riservare tali soluzioni per problemi che possono essere risolti solo da un amministratore.

Non corretto:

In questo esempio, molto probabilmente il problema riguarda la connessione di rete dell'utente, quindi non vale la pena contattare un amministratore.

• Non consigliare di contattare il supporto tecnico. L'opzione per contattare il supporto tecnico per risolvere un problema è sempre disponibile e non deve essere promossa tramite messaggi di errore. Concentrarsi invece sulla scrittura di messaggi di errore utili in modo che gli utenti possano risolvere i problemi senza contattare il supporto tecnico.

Non corretto:

In questo esempio, il messaggio di errore consiglia erroneamente di contattare il supporto tecnico.

• Usare frasi complete, maiuscole e minuscole in stile frase e punteggiatura finale.

Pulsanti Commit

• Se il messaggio di errore fornisce pulsanti di comando o collegamenti di comando che risolvono il problema, seguire le rispettive linee guida in Finestre di dialogo.
• Se il programma deve terminare in seguito all'errore, specificare un pulsante Esci dal programma. Per evitare confusione, non usare Chiudi per questo scopo.
• In caso contrario, specificare un pulsante Chiudi. Non usare OK per i messaggi di errore, perché questa formulazione implica che i problemi sono OK.
  • Eccezione: Usare OK se il meccanismo di segnalazione degli errori ha etichette fisse (come con l'API MessageBox).

Documentazione

Quando si fa riferimento a errori:

• Fare riferimento agli errori in base all'istruzione principale. Se l'istruzione principale è lunga o dettagliata, riepilogarla.
• Se necessario, è possibile fare riferimento a una finestra di dialogo di messaggio di errore come messaggio. Fare riferimento a come messaggio di errore solo nella programmazione e in altre documentazioni tecniche.
• Quando possibile, formattare il testo in grassetto. In caso contrario, inserire il testo tra virgolette solo se necessario per evitare confusione.

Esempio: Se si riceve un disco CD nel messaggio dell'unità , inserire un nuovo disco CD nell'unità e riprovare.