Messaggi di errore in Windows 7

Nota

Questa guida di 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 visualizzati usando finestre di dialogo modali, messaggi sul posto, notifiche o palloncini.

Messaggio di errore modale tipico.

I messaggi di errore effettivi informano gli utenti che si sono verificati problemi, 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.

I 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 bassa soddisfazione del prodotto e rappresentano una causa principale dei costi di supporto tecnico evitabili. I messaggi di errore non necessari interrompono il flusso degli utenti.

Nota: Linee guida relative alle finestre di dialogo , messaggi di avviso, conferme, icone standard, notifichee layout vengono presentati in articoli separati.

Si tratta dell'interfaccia utente corretta?

Per decidere, considerare 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 invece il problema. Ad esempio, usare controlli vincolati a valori validi anziché usare controlli non vincolati 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 modifichino il 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, è consigliabile 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 può essere ignorato liberamente dagli utenti? In tal caso, usare invece una notifica di errore dell'azione .
• Il problema si riferisce allo stato di un'attività in background all'interno di una finestra primaria? In tal caso, è consigliabile visualizzare il problema usando una barra di stato .
• Gli utenti IT principali sono i professionisti IT? In tal caso, è consigliabile usare un meccanismo di feedback alternativo, ad esempio file di log voci o avvisi di posta elettronica. I professionisti IT preferiscono fortemente i file di log per informazioni non critiche.

Concetti di progettazione

Caratteristiche dei messaggi di errore scarsi

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 finestre di dialogo 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

risposta errata:

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 anche vuole fare su questo (l'utente ha scelto di arrestare Windows, dopo tutto). E visualizzando questo messaggio di errore, Windows impedisce di arrestarsi.

Problema: Il messaggio di errore è il problema. Oltre a 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"

risposta errata:

Questo messaggio di errore è stato generato dall'utente che sceglie 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 è presente alcun errore dal punto di vista dell'utente. Oltre a 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

risposta errata:

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

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

causa principale: molto probabilmente, il programma presenta una gestione degli errori insufficiente.

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

messaggi di errore incomprensibili

risposta errata:

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

Il problema: La dichiarazione o la soluzione del problema è incomprensibile.

causa iniziale: Spiegare il problema dal punto di vista del codice anziché dall'utente.

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

Messaggi di errore che sovracommunicate

risposta errata:

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 complesso 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 non inutilizzabili

risposta errata:

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

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

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

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

messaggi di errore che incolpano gli utenti

risposta errata:

carattere non valido

Perché gli utenti si sentono come un criminale?

Il problema: Il messaggio di errore viene fraseto in modo da accusare l'utente di effettuare un errore.

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

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

messaggi di errore stupidi

risposta errata:

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

Il problema: istruzioni del messaggio di errore sciocche o non sequitor.

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

Alternativa consigliata: Visualizzare i messaggi di errore creati ed esaminati da un writer. Quando si esaminano gli errori, prendere in considerazione il contesto e lo stato di mente dell'utente.

messaggi di errore del programmatore

risposta errata:

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: 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 alcun significato o valore per gli utenti.

causa principale: programmatori che 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 fare errori come questo comprensibile per gli utenti perché il loro unico pubblico è il programmatore.

messaggi di errore presentati in modo non valido

risposta errata:

Questo esempio presenta molti errori comuni di presentazione.

Problema: Ottenere tutti i dettagli errati nella presentazione del messaggio di errore.

Causa iniziale: Non conoscere e applicare 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 hanno:

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

Inoltre, i messaggi di errore validi vengono presentati in modo analogo a:

• Rilevante. Il messaggio presenta un problema a cui gli utenti si preoccupano.
• Querelabile. 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 è infelice.
• Breve. Il messaggio è il più breve possibile, ma non più breve.
• Chiaro. Il messaggio usa una lingua semplice 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 sentire 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 per 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é il risultato desiderato viene raggiunto.

risposta errata:

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 in modo esplicito un'attività. Per il punto di vista dell'utente, la condizione seguente non è un errore.

risposta errata:

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 è davvero 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 il prodotto desiderato non è disponibile. Tecnicamente, si tratta di un errore, ma invece di fornire un messaggio di errore, il programma potrebbe:

• Continuare a cercare i prodotti che corrispondono più strettamente 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 messaggi di errore consiste nel prevenire i problemi in primo luogo. È possibile evitare errori tramite:

• Uso di controlli vincolati. Usare 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 richiedono messaggi di errore. Tuttavia, è possibile vincolare le caselle di testo per accettare solo determinati caratteri e accettare un numero massimo di caratteri.
• Uso di interazioni vincolate. Per le operazioni di trascinamento, consentire agli utenti di rilasciare solo destinazioni valide.
• Uso di controlli disabilitati e voci di menu. Disabilitare i controlli e le voci di menu quando gli utenti possono facilmente dedurre il motivo per cui il controllo o la voce di menu è disabilitato.
• 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 le cose solo lavoro. È meno probabile che gli utenti commettono errori se le attività non sono necessarie o eseguite automaticamente per loro. Oppure se gli utenti commettono 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 è davvero necessario fornire un messaggio di errore. Gli utenti commettono errori, reti e dispositivi smettono di funzionare, gli oggetti non possono essere trovati o modificati, le attività non possono essere completate e i programmi presentano bug. Idealmente, questi problemi si verificherebbero meno spesso, ad esempio, possiamo progettare il nostro software per evitare molti tipi di errori dell'utente, ma non è realistico prevenire tutti questi problemi. E quando si verifica uno di questi problemi, un messaggio di errore utile restituisce rapidamente agli utenti i piedi.

Una convinzione comune è che i messaggi di errore sono la peggiore esperienza utente 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.

Considerare i controlli disabilitati. Nella maggior parte dei casi, è 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 è disponibile 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 invece un messaggio di errore utile.

risposta errata:

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

Se non si è certi che venga visualizzato un messaggio di errore, iniziare componendo il messaggio di errore che potrebbe essere specificato. Se è probabile che gli utenti eseguano un'azione o modifichino il loro comportamento, fornire il messaggio di errore. Al contrario, se gli utenti potrebbero ignorare il messaggio senza eseguire alcuna operazione o modificarlo, omettere il messaggio di errore.

Progettazione per una corretta gestione degli errori

Mentre 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. Si consideri questo messaggio di errore:

risposta errata:

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

Anche se è possibile che si tratti di un messaggio di errore scritto in modo molto errato, è più probabile che rifletta la mancanza di una corretta gestione degli errori dal codice sottostante non esistono informazioni specifiche note sul problema.

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

• A ogni problema deve essere assegnato un codice di errore univoco.
• Se un problema presenta diverse cause, il programma deve determinare la causa specifica quando possibile.
• Se il problema presenta parametri, è necessario mantenere i parametri.
• 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 è un elemento che può essere tacco in un secondo momento.

risoluzione dei problemi (e come evitarlo)

La risoluzione dei problemi risulta quando viene segnalato un problema con diverse cause con un singolo messaggio di errore.

risposta errata:

risposta esatta:

La risoluzione dei problemi risulta 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 oppure l'accesso è stato negato. Se il programma può determinare facilmente la causa, perché mettere il carico sull'utente per determinare la causa specifica?

risposta errata:

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.

risposta esatta:

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 per il programma 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 si preoccupino 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, in realtà non si conoscerà il problema, la causa o la soluzione. Se non sarebbe opportuno eliminare l'errore, è meglio essere davanti alla mancanza di informazioni che a 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 in primo piano sulla mancanza di informazioni.

D'altra parte, fornire informazioni specifiche e 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 un errore, un 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. "Impossibile caricare un controllo ActiveX senza segno". (Frase come problema esistente).
• Avvertimento. "Questa pagina potrebbe non comportarsi come previsto perché Windows Internet Explorer non è configurato per caricare controlli ActiveX non firmati." o "Consenti a questa pagina di installare un controllo ActiveX non firmato? In questo modo da fonti non attendibili può danneggiare il computer." Entrambe le condizioni che possono causare problemi futuri.
• Informazione. "È stato configurato Windows Internet Explorer per bloccare i controlli ActiveX non firmati". (Frase come affermazione 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 altro) che corrisponda al testo. Il testo e le icone delle istruzioni principali devono corrispondere sempre.

presentazione del messaggio di errore

La maggior parte dei messaggi di errore nei programmi Windows viene presentata usando finestre di dialogo modali (come 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 gli errori destinati ai professionisti IT)

L'inserimento di messaggi di errore nelle finestre di dialogo modali offre il vantaggio di richiedere l'attenzione e l'acknowledgement immediati dell'utente. Tuttavia, questo è anche il loro svantaggio principale se l'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.

Le finestre di dialogo modali sono un'ottima scelta 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 più leggera del peso che fa il lavoro bene.

evitare l'overcommunicating

In genere, gli utenti non leggono, analizzano. 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 fino ai suoi elementi essenziali e usare collegamenti di divulgazione progressiva e Guida quando necessario per fornire informazioni aggiuntive.

Sono disponibili molti esempi estremi, ma si esaminerà uno più tipico. L'esempio seguente presenta la maggior parte degli attributi di un messaggio di errore valido, ma il testo non è conciso e richiede la motivazione per leggere.

risposta errata:

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

Che cosa dice davvero tutto questo testo? Qualcosa di simile al seguente:

risposta esatta:

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 piramide invertito di presentazione.

Per altre linee guida ed esempi sull'overcommunicating, vedere User Interface Text.

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 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 i 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 usando 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 supporti. I problemi di rete possono essere risolti controllando la connessione di rete fisica ed eseguendo diagnostica e ripristino 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.	file In questo esempio non è possibile eliminare il file o la cartella perché non è stata trovata. 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 di 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 utente L'utente ha immesso un valore non corretto o incoerente con l'input di un altro 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.

Istruzioni

Presentazione

• Usare le finestre di dialogo attività ogni volta che appropriate 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, impedire o ridurre gli errori di input dell'utente tramite:
  • 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é il controllo o la voce di menu è disabilitata.
  • Specificare valori predefiniti validi.

risposta errata:

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

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

carattere non corretto

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 verificarsi più errori sul posto alla volta. Usa testo normale e un'icona di errore di 16x16 pixel, posizionandoli direttamente accanto al problema quando possibile. Gli errori sul posto non vengono visualizzati 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 rilevato 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 sull'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 Cancella 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 basarsi 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 un'icona di errore piccola (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 sovrapposizione degli errori e la funzionalità è l'oggetto dell'errore.

• Non usare icone di avviso per gli errori. Questo è spesso fatto per rendere la presentazione meno grave. Gli errori non vengono visualizzati.

  risposta errata:

  

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

Per altre linee guida ed esempi, vedere icone standard.

Divulgazione progressiva

• Usa un pulsante Mostra/Nascondi divulgazione progressiva dei dettagli per nascondere informazioni avanzate o dettagliate in un messaggio di errore. In questo modo viene semplificato 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 solo riformulare 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 di nuovo questo messaggio

• Se un messaggio di errore richiede questa opzione, riconsiderare l'errore e la relativa frequenza. Se presenta tutte le caratteristiche di un buon errore (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.

Guida

• Progettare 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 pertinente e utile. Non dovrebbe trattarsi di una riformulazione dettagliata del messaggio di errore, ma deve contenere informazioni utili che non rientrano nell'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. A questo scopo, non usare pulsanti di comando o divulgazione progressiva.
• 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 Guida.

Codici di errore

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

risposta errata:

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 "0x" iniziali e maiuscoli.

risposta esatta:

1234

0xC0001234

risposta errata:

-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.

Suono

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

Testo

generale

• Rimuovere il testo ridondante. Cercalo in titoli, istruzioni principali, istruzioni supplementari, collegamenti ai comandi e pulsanti di commit. In genere, lasciare il testo completo nelle istruzioni e nei controlli interattivi e rimuovere qualsiasi ridondanza dalle altre posizioni.
• Usare 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 comprendono e usano. Evitare il gergo tecnico.

risposta errata:

risposta esatta:

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

• Non usare le parole seguenti:
  • Errore, errore (uso del problema)
  • Non è possibile (non è possibile usare invece)
  • Illegale, non valido, non valido (usare invece errato)
  • Interrompere, uccidere, terminare (usare invece stop)
  • Irreversibile, fatale (usare invece serio)

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

risposta errata:

risposta esatta:

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

• Non usare la formulazione che incolpa l'utente o implica l'errore dell'utente. Evitare di usare te e il tuo nella formulazione. Sebbene la voce attiva sia generalmente preferita, usare la voce passiva quando l'utente è l'oggetto e potrebbe sentirsi incolpata dell'errore se è stata usata la voce attiva.

risposta errata:

di accesso non corretto

risposta esatta:

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

• Essere specifici. Evitare formulazioni vaghe, ad esempio errori di sintassi e operazione non valida. Specificare nomi, posizioni e valori specifici degli oggetti coinvolti.

risposta errata:

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 problemi improbabili, cause o soluzioni nel tentativo di essere specifici. Non fornire un problema, una causa o una soluzione, a meno che non sia probabile che sia corretta. Ad esempio, è preferibile dire Che si sia verificato un errore sconosciuto rispetto a un elemento che è probabilmente impreciso.
• evitare la parola "per favore", tranne nelle situazioni in cui l'utente viene chiesto di fare qualcosa di scomodo (ad esempio in attesa) o il software è la colpa per la situazione.

risposta esatta:

Attendere mentre Windows copia i file nel computer.

• Usare la parola "sorry" solo nei messaggi di errore che causano gravi problemi 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).

risposta esatta:

Il backup di Fabrikam ha rilevato un problema irreversibile ed è stato arrestato per proteggere i file nel computer.

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

risposta errata:

risposta esatta:

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

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

risposta esatta:

In questo esempio, il messaggio di errore genera confusione se il nome dell'oggetto non fosse tra virgolette.

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

Per altre linee guida ed esempi, vedere Style and Tone.

Titoli

• Usare il titolo per identificare il comando o la funzionalità da cui ha avuto origine l'errore. Eccezioni:
  • Se un errore viene visualizzato da molti comandi diversi, prendere in considerazione l'uso del nome del programma.
  • Se tale 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.

risposta errata:

In questo esempio, il titolo viene usato in modo non corretto per spiegare il problema.

• Usa maiuscole e minuscole in stile titolo, senza punteggiatura finale.

istruzioni principali

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

risposta errata:

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 url e percorsi di file completi nell'istruzione principale. Usare invece un nome breve (ad esempio il nome file) e inserire il nome completo (ad esempio il percorso del file) nell'istruzione supplementare. Tuttavia, è possibile inserire un singolo percorso di file completo o UN URL nell'istruzione principale se il messaggio di errore non richiede altrimenti un'istruzione supplementare.

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

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

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

• Usare il tempo presente ogni volta che è possibile.
• Usare la maiuscola in stile frase.
• Non includere i periodi finali se l'istruzione è un'istruzione . Se l'istruzione è una domanda, includere un punto interrogativo finale.

modelli di istruzioni principali

Anche se non esistono regole rigide per la formulazione, provare a usare i modelli di istruzione principali seguenti quando 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] a "[nome oggetto]"
• [nome soggetto facoltativo] non può [eseguire l'azione] a "[nome oggetto]" perché [reason]
• [risorsa] non è sufficiente 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 sia probabilmente in grado di risolvere il problema. Non sprecare tempo agli utenti suggerendo possibili soluzioni, ma improbabili.

risposta errata:

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 facilmente dedotto 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 conoscere. 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.

risposta esatta:

Per riavviare Windows, fare clic su OK.

risposta errata:

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 sia tra le soluzioni più probabili al problema. Riservare tali soluzioni per problemi che possono essere risolti solo da un amministratore.

risposta errata:

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.

risposta errata:

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 ai comandi 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 errori include 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 Non è presente alcun disco CD nell'unità messaggio, inserire un nuovo disco CD nell'unità e riprovare.