Conferme

Una conferma è una finestra di dialogo modale che chiede se l'utente vuole procedere con un'azione.

Una tipica conferma.

Le conferme hanno queste caratteristiche essenziali:

• Vengono visualizzati come risultato diretto di un'azione avviata dall'utente.
• Verificano che l'utente voglia procedere con l'azione.
• Sono costituiti da una semplice domanda e da due o più risposte.

Le conferme sono più utili quando l'azione richiede all'utente di effettuare una scelta rilevante e distinta che non può essere effettuata in un secondo momento. Questa scelta spesso implica un elemento di rischio che non è ovvio per l'utente, ma il rischio non è essenziale per le conferme. Questi elementi sono necessari per giustificare l'interruzione della risposta a un dialogo modale.

Al contrario, i messaggi di avviso presentano una condizione che potrebbe causare un problema in futuro. La loro caratteristica fondamentale è che comportano rischi:

• Comportano una potenziale perdita di uno o più dei seguenti elementi:
  • Un bene prezioso, ad esempio la perdita di dati o la perdita finanziaria.
  • Accesso al sistema o integrità.
  • Privacy o controllo sulle informazioni riservate.
  • Tempo dell'utente (una quantità significativa, ad esempio 30 secondi o più).
• Hanno conseguenze impreviste o impreviste.
• Richiedono una corretta gestione ora perché gli errori non possono essere risolti facilmente e possono anche essere irreversibili.

Se una conferma comporta rischi, può essere considerata anche un avviso. Di conseguenza, si applicano anche le linee guida per i messaggi di avviso.

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

Si tratta dell'interfaccia utente corretta?

Per decidere, prendi in considerazione queste domande:

• L'utente ha chiesto una domanda per procedere con un'azione con due o più risposte? In caso contrario, il messaggio non è una conferma.
• L'interfaccia utente presenta un errore o un problema che si è verificato? In tal caso, usare invece un messaggio di errore .
• Per procedere con l'azione è necessario che l'utente faccia una scelta che non abbia un valore predefinito appropriato? In tal caso, potrebbe essere appropriata una conferma.
• Esiste una progettazione alternativa che elimina la necessità di conferma? La necessità di una conferma a volte indica un difetto di progettazione. Spesso esiste un'alternativa di progettazione migliore che non richiede una conferma.
• L'utente sta per eseguire un'azione rischiosa? In tal caso, una conferma è appropriata se l'azione ha conseguenze significative o non può essere facilmente annullata.
• L'utente sta per abbandonare un'attività? In tal caso, non confermare. Si supponga che gli utenti comprendano le conseguenze del mancato completamento di un'attività.
• L'azione ha conseguenze che gli utenti potrebbero non essere a conoscenza? In tal caso, potrebbe essere appropriata una conferma.
• Dato il contesto corrente, è probabile che gli utenti eseseguono un'azione in errore? In tal caso, potrebbe essere appropriata una conferma.
• Gli utenti eseguono spesso l'azione? In tal caso, prendere in considerazione una progettazione alternativa. Le conferme frequenti sono fastidiose e hanno poco valore perché gli utenti imparano a rispondere senza pensare.
• L'azione ha implicazioni per la sicurezza? In tal caso, potrebbe essere necessaria una conferma anche se i test precedenti indicano in caso contrario.

Concetti relativi alla progettazione

Le conferme non necessarie sono fastidiose

La prima conferma di Windows mai creata ha senza dubbio un aspetto simile al seguente:

La conferma originale fastidiosa.

Questo è stato un brutto inizio. Se vuoi che gli utenti odiano il tuo programma, basta cospargere conferme come questa in tutto questo. Per comprendere il motivo, considerare il punto di vista dell'utente. L'utente ha semplicemente chiesto di eseguire un'azione in base alla definizione di una conferma, quindi, a meno che qualcosa non sia stato in qualche modo fatto clic o premuto accidentalmente, naturalmente l'utente vuole procedere.

Non solo sono inutili conferme fastidiose, ma non sono efficaci per proteggere l'utente da errori. Gli utenti individuano rapidamente quando un programma ha conferme non necessarie e la loro risposta naturale è di ignorarli il più rapidamente possibile, spesso senza leggere. Di conseguenza, tali conferme fanno poco più di aggiungere un passaggio aggiuntivo a queste attività.

Non usare le conferme solo perché è possibile che gli utenti commetteno un errore. Invece, le conferme sono più efficaci quando usate per confermare le azioni che hanno conseguenze significative o impreviste. Buone conferme non dichiarano mai l'ovvio; devono comunicare qualcosa che gli utenti devono essere consapevoli di un buon motivo per non continuare. E vengono usati solo quando sono effettivamente necessari da un'azione, ad esempio chiedendo agli utenti di salvare le modifiche solo quando sono presenti modifiche che vale la pena salvare. Questa operazione richiede l'attenzione dell'utente solo quando è veramente garantito.

Per altri tipi di conferme, spesso esiste un'alternativa di progettazione migliore rispetto all'uso forzato degli utenti a rispondere a una domanda.

Prendere in considerazione le alternative di progettazione

Ecco alcune alternative di progettazione che eliminano la necessità di conferme di routine:

• Evitare errori. Progettare attività in modo che errori significativi siano difficili da eseguire accidentalmente. Ad esempio, separare fisicamente i comandi distruttivi da altri comandi e richiedere il completamento di più azioni.
• Specificare annulla. Consente di ripristinare le azioni. Ad esempio, l'eliminazione di un file in Microsoft Windows in genere non richiede una conferma perché i file eliminati possono essere recuperati dal Cestino. Si noti che se un'azione è molto semplice da eseguire, è possibile che gli utenti ripetino l'azione.
• Fornire commenti e suggerimenti. Rendere ovvi i risultati indesiderati. Fornire undo da solo non è sufficiente se gli utenti non si rendono conto quando commettono un errore. Ad esempio, l'effetto della manipolazione diretta ,ad esempio un'operazione di trascinamento della selezione, deve essere sempre ovvio.
• Si supponga il risultato probabile, ma semplificarne la modifica. Se non si è certi di cosa vogliono gli utenti, ma esiste una scelta probabile, sicura e sicura, presupporre che scelta, rendere chiaro cosa è successo e semplificare la modifica usando un menu di scelta rapida. Ad esempio, Microsoft Word presuppone che gli utenti vogliano scrivere correttamente le parole. Se riconosce una parola con errori di ortografia e conosce la probabile ortografia corretta, Word esegue automaticamente la correzione, ma consente agli utenti di ripristinare.
• Eliminare completamente la scelta. Se la scelta non è importante, gli utenti non importano. Meglio semplificare il programma ed eliminare la scelta.

Per effettuare le conferme, è necessario pensare

Per ottenere un valore, gli utenti devono comprendere il motivo per cui non procedere. A volte il motivo è ovvio, come quando gli utenti chiudono un documento con modifiche che non sono state salvate:

In questo esempio, il motivo della conferma è ovvio.

In altre situazioni, il motivo potrebbe non essere così ovvio.

Quando si scelgono le etichette dei pulsanti di commit per le finestre di dialogo, le linee guida generali consentono di scegliere etichette che sono risposte specifiche all'istruzione principale. Ciò comporta un processo decisionale efficiente perché gli utenti devono leggere una quantità minima di testo per continuare. Tuttavia, questo obiettivo di efficienza può essere controproducente per le conferme. Prendere in considerazione questo esempio:

Non corretto:

In questo esempio la risposta corretta richiede il pensiero.

Se si presenta questa conferma immediatamente dopo che l'utente ha dato il comando Disinstalla, è probabile che la risposta dell'utente sia "Naturalmente voglio disinstallare!" L'utente farà clic su Disinstalla senza dare un secondo pensiero.

Per le conferme, non vogliamo che gli utenti esevono decisioni affrettate ed emotivo. Per incoraggiare gli utenti a pensare alla loro risposta, è necessario fornire una piccola velocità decisionale. Quando si è pratici, in genere è meglio eseguire questa operazione eseguendo attentamente la formulazione dei pulsanti di commit. Ad esempio, è possibile usare un linguaggio aggiuntivo per indicare che esiste un motivo per cui non continuare.

Meglio:

In questo esempio viene aggiunto "comunque" all'etichetta del pulsante commit per indicare che la conferma indica un motivo per cui non continuare.

Se questo approccio non è pratico, è possibile usare i pulsanti Sì/No commit.

Anche meglio:

In questo esempio, l'uso dei pulsanti di commit Sì/No impone agli utenti di leggere almeno l'istruzione principale.

Fornire tutte le informazioni

Se si vuole porre una domanda, è necessario fornire informazioni sufficienti per gli utenti per rispondere a tale domanda in modo intelligente. Prendere in considerazione la finestra di dialogo Conferma sostituzione file da Windows XP:

Finestra di dialogo Conferma file sostituisci file di Windows XP.

Questa conferma fornisce tutte le informazioni che gli utenti potrebbero dover rispondere alla domanda? Prima di rispondere, considerare gli scenari utente più comuni:

• Copiare (o spostare) l'altro file, sostituendo quello esistente.
• Mantenere il file esistente, senza copiare o spostare l'altro file.
• Mantenere o copiare il file più recente (scenario superiore).
• Mantenere il file esistente o copiare l'altro file, a seconda dei criteri, ad esempio il contenuto e le dimensioni del file.
• Mantenere il file esistente e copiare l'altro file usando un nome diverso.
• Annullare l'operazione se qualcosa non è corretto o imprevisto.

Gli utenti possono ottenere lo scenario 1 facendo clic su Sì e lo scenario 2 facendo clic su No. Possono ottenere lo scenario 3 confrontando le date del file e facendo clic sul pulsante appropriato, ma si noti quanto è necessario determinare il file più recente e quindi determinare il pulsante appropriato soprattutto per ciò che è probabile che sia lo scenario più comune.

Gli scenari 4, 5 e 6 sono anche sorprendentemente difficili. Le dimensioni del file vengono arrotondate, quindi, ad esempio, è impossibile determinare se questi file hanno le stesse dimensioni o anche se sono lo stesso file. Le icone sono per l'applicazione usata per aprire il file, quindi gli utenti dovranno aprire i file per controllare e confrontare il contenuto. La presenza di anteprime del contenuto del file sarebbe molto più utile per rispondere alla domanda.

La conferma copia file da Windows Vista offre un lavoro molto migliore per gestire questi scenari fornendo altre informazioni e aggiungendo l'opzione per mantenere entrambi i file:

Conferma del file di copia di Windows Vista.

Fornire informazioni specifiche e utili

Se si vuole porre una domanda, assicurarsi che gli utenti comprendano la domanda e le implicazioni delle risposte alternative. Prendere in considerazione questa conferma della sicurezza di Windows Internet Explorer:

Una conferma di sicurezza vaga.

Questa conferma pone una domanda che gli utenti non possono rispondere in modo intelligente. L'utente ha richiesto che Windows Internet Explorer visualizzi una pagina e questo messaggio lo consiglia in modo implicito tramite la parola del testo e evidenziando No come scelta predefinita.

Il problema di sicurezza specifico che la pagina pone non è sufficientemente spiegata, quindi il rischio di continuare non è chiaro. Quali informazioni nella conferma causano che l'utente abbia mai fatto clic su No? A causa della vagozza del messaggio, la conferma non è probabile che gli utenti continuino, ma li farà sentire male per farlo.

Per questa conferma essere utile, deve fornire ulteriori informazioni specifiche che potrebbero causare che l'utente non decida di procedere. In generale, per ogni risposta in una conferma, prendere in considerazione gli scenari che lo richiedono e assicurarsi che siano disponibili informazioni sufficienti per gli utenti che vogliono sceglierla. Fornire scelte, non dilemma.

Come determinare se è necessaria una conferma

Pensando agli scenari e alla probabilità di scegliere ogni risposta suggerisce un modo sistematico per determinare se è necessaria una conferma. Se è probabile che gli utenti selezionino tutte le risposte, la conferma è necessaria e utile. Tuttavia, se una sola risposta è probabile (ad esempio il 98% del tempo), la conferma è chiaramente inutile e deve essere rimossa. Si noti che le conferme correlate a problemi di sicurezza, legali e di sicurezza sono possibili eccezioni.

Questa conferma è necessaria? Gli utenti potranno mai selezionare No? È possibile ma molto improbabile. Questa conferma deve essere rimossa.

Se fai solo tre cose...

1. Assicurarsi che la conferma sia davvero necessaria. Ci dovrebbe essere un motivo legittimo e chiaro non procedere, e una possibilità che a volte gli utenti non saranno.

2. Se il motivo della conferma non è immediatamente ovvio, scegliere pulsanti di commit che incoraggiano gli utenti a pensare alla risposta. In genere, questa operazione viene eseguita tramite la formulazione della conferma come sì o nessuna domanda e fornisce risposte completamente esplicative o Sì/No.

3. Prendere in considerazione tutti gli scenari e fornire le informazioni necessarie per rispondere in modo intelligente alla domanda.

Modelli di utilizzo

Le conferme hanno diversi modelli di utilizzo:

Utilizzo	Esempio
Conferme di routine verificare che l'utente voglia procedere con un'azione di routine a basso rischio.	Queste conferme vengono in genere frasi "sei sicuro...?" e spesso hanno una casella di controllo non mostrare di nuovo questo messaggio per ridurre al minimo la loro annoia. Esempi di conferme di routine. Nota: Questo modello è in genere non necessario e deve essere evitato.
Conferma dell'azione rischiosa verificare che l'utente voglia procedere con un'azione che presenta un rischio e non può essere facilmente annullata.	Poiché hanno rischio, queste conferme in genere hanno un'icona di avviso. Esempi di conferma dell'azione rischiosa.
Conferme di conseguenza non intenzionali verificare che l'utente voglia procedere con un'azione che ha conseguenze impreviste o impreviste.	Oltre a porre una domanda, queste conferme indicano le conseguenze impreviste. poiché hanno conseguenze impreviste, queste conferme in genere hanno un'icona di avviso. esempi di conferme di conseguenza non intenzionali. tuttavia, questo modello richiede che le conseguenze siano veramente impreviste. Errato: Le conseguenze sono destinate qui, quindi si tratta di una conferma di routine.
Precisazioni chiarire in che modo l'utente vuole procedere con un'azione che ha conseguenze potenzialmente ambigue o impreviste.	Le operazioni di trascinamento possono causare chiarimenti se l'effetto dell'operazione può essere interpretato in modo non corretto. Esempi di chiarimenti. Nota: Questo modello deve essere evitato perché è meglio progettare azioni senza conseguenze ambigue e presupporre il risultato più probabile desiderato.
Conferma della sicurezza verificare che l'utente voglia procedere con un'azione con conseguenze di sicurezza.	Esempi di conferma della sicurezza.
Conferma della motivazione dell'ulteriore fornire informazioni su un'azione, ma presentarla come conferma.	Mentre queste finestre di dialogo vengono presentate come conferme, il loro obiettivo reale è l'istruzione utente o la pubblicità delle funzionalità. Esempio di conferma del motivo ulterior. Nota: Questo modello non è consigliato perché in genere esiste un'alternativa migliore e più diretta. Ad esempio, le animazioni sono un modo migliore per mostrare la relazione tra la causa e l'effetto.

Indicazioni

Generale

• Usare le conferme "Salva modifiche" solo quando sono presenti modifiche significative. Non confermare le modifiche apportate direttamente dall'utente, ad esempio la riformattazione automatica dei documenti.

Non corretto:

Questo esempio non è corretto quando viene usato per un messaggio di posta elettronica o un documento vuoto che non è stato modificato dall'utente.

Icone

• Le conferme non usano le icone della barra del titolo.

• L'icona dell'area di contenuto per una conferma è basata sul relativo modello di progettazione:

  Modello	Icona
  Conferme di routine	Nessuna icona.
  Conferma dell'azione rischiosa	Icona avviso.
  Conferme di conseguenza non intenzionali	Usare un'icona di avviso se esiste un rischio, l'icona della funzionalità se disponibile; in caso contrario, nessuna icona.
  Precisazioni	Se la conferma implica un documento, usare l'anteprima del documento; in caso contrario, usare l'icona della funzionalità se disponibile o nessuna icona.
  Conferma della sicurezza	Icona avviso.
  Conferma della motivazione dell'ulteriore	Nessuna icona.

• Non usare le icone di avviso per le domande di routine. In questo modo è contro il tono incoraggiante di Windows e fa uso del programma come un'attività pericolosa. Si supponga che gli utenti comprendano le conseguenze dell'annullamento di un'attività prima che venga completata.

Non corretto:

In questo esempio viene usata un'icona di avviso per porre una domanda di routine.

Pulsanti di commit

• Usare risposte specifiche all'istruzione principale se il motivo della conferma è ovvio o può essere reso autoesplicativo.

In questo esempio il motivo della conferma è ovvio, quindi Salva e Non salvare bene il lavoro.

• In caso contrario, usare i pulsanti Sì e No per le risposte di conferma. In questo modo gli utenti danno la conferma di qualche pensiero prima di rispondere. Non usare mai OK e Annulla per le conferme.

Corretto:

In questo esempio, l'uso dei pulsanti di commit Sì/No impone agli utenti di leggere almeno l'istruzione principale.

Non corretto:

In questo esempio, l'uso di OK/Cancel è confuso.

• Per chiudere un programma o riavviare Windows, usare risposte specifiche all'istruzione principale. Per evitare eventuali incomprensioni, non usare Chiudi o Sì/No per questo scopo.

Corretto:

Non corretto:

Nell'esempio errato, Sì viene usato per riavviare Windows.

Collegamenti ai comandi

• Per i chiarimenti, considerare l'uso dei collegamenti ai comandi per rendere chiare le alternative.

Accettabile:

Meglio:

Nell'esempio migliore, i collegamenti ai comandi rendono chiare le alternative.

• Presentare prima i collegamenti ai comandi usati più comunemente. L'ordine risultante dovrebbe seguire approssimativamente la probabilità di uso, ma anche un flusso logico.
• Se un collegamento al comando richiede ulteriori spiegazioni, fornire una spiegazione supplementare. Le spiegazioni supplementari descrivono perché gli utenti potrebbero voler scegliere l'opzione o cosa accade se l'opzione è scelta.

Per altre linee guida ed esempi, vedere Collegamenti ai comandi.

Valori predefiniti

• La risposta predefinita per una conferma è basata sul relativo modello di progettazione:

  Modello	Risposta predefinita
  Conferme di routine	Procedere.
  Conferma dell'azione rischiosa	Non procedere (o la scelta sicura).
  Conferme di conseguenza non intenzionali	Se le conseguenze sono significative, non procedere; in caso contrario, procedere.
  Precisazioni	Risposta più probabile.
  Conferma della sicurezza	Non procedere.
  Conferma della motivazione dell'ulteriore	Procedere.

Non visualizzare di nuovo questo messaggio

• Usare questa opzione solo per i modelli di conferma dei motivi di routine e ulterior. Per gli altri modelli, se le informazioni sono necessarie, deve essere sempre visualizzata.
• Non fornire questa opzione per giustificare la visualizzazione di una conferma non necessaria. Basta liberarsi della conferma.

Non corretto:

Ancora errato:

In questi esempi, l'aggiunta di un'opzione Non visualizzare di nuovo questo messaggio non risolve una conferma non necessaria.

Per altre linee guida, vedere Finestre di dialogo.

Operazioni in blocco

• Per le conferme che si applicano alle operazioni bulk, fornire un'opzione per applicare la conferma all'intera operazione.

In questo esempio è disponibile un'opzione per le operazioni bulk.

• Eliminare o posticipare le conferme in un'operazione in blocco.

Non corretto:

In questo esempio Esplora risorse in Windows XP conferma ogni file di sola lettura durante lo spostamento di un file bulk. Meglio solo copiare i file di sola lettura senza chiedere o posticipare la gestione di questi file e presentare la conferma alla fine dell'attività.

Rivelazione progressiva

• Se è necessario includere informazioni avanzate in un messaggio di conferma, visualizzarla usando pulsanti di divulgazione progressiva (ad esempio, "Mostra dettagli"). In questo modo si semplifica la conferma dell'utilizzo tipico. Non nascondere le informazioni necessarie perché gli utenti potrebbero non trovarlo.
• Non usare "Mostra dettagli" a meno che non siano presenti dettagli più dettagliati. Non riformulare solo le informazioni esistenti in un formato diverso.

Per le linee guida per l'etichettatura, vedere Diffusione progressiva.

Controllo dell'account utente

• Non usare l'interfaccia utente controllo dell'account utente come sostituto di una conferma. Se un'azione richiede una conferma, usare una finestra di dialogo separata. Durante l'interfaccia utente per l'elevazione dei privilegi, gli utenti devono concentrarsi sulla necessità di avviare l'attività e se il programma è attendibile.
• Visualizzare la conferma prima dell'interfaccia utente di elevazione. In questo modo si eliminano le elevazioni non necessarie.

Testo

Generale

• Rimuovere il testo ridondante. Cercare testo ridondante nei titoli, istruzioni principali, istruzioni supplementari, aree di contenuto, 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.
• Non usare "warning" o "warning" nel testo. Se gli utenti devono procedere con cautela, indicare l'uso di un'icona di avviso.

Non corretto:

In questo esempio il termine "warning" non è necessario.

Titoli

• Usare il titolo per identificare il comando o la funzionalità da cui proviene la conferma. Eccezioni:
  • Se viene visualizzata una conferma 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.

Tuttavia, se la conferma proviene da un'attività a esecuzione prolungata e può essere visualizzata correttamente dopo l'avvio dell'attività, usare sempre il comando o la funzionalità per identificare chiaramente il contesto.

• Non usare il titolo per spiegare cosa fare nel dialogo che è lo scopo dell'istruzione principale.
• Se aggiunge chiarezza, avviare il titolo con la parola Conferma.
• Per le conferme dell'azione rischiosa, è possibile aggiungere il nome dell'oggetto coinvolto per un'enfasi aggiuntiva.

In questo esempio l'unità da formattare è inclusa nel titolo.

• Usare la maiuscola in stile titolo, senza terminazione della punteggiatura.

Istruzioni principali

• L'istruzione principale per una conferma è basata sul modello di progettazione:

  Modello	Istruzione principale
  Conferme di conseguenza impreviste	dichiarare la conseguenza imprevista. eccezione: se una domanda che chiede se l'utente vuole procedere chiaramente implica la conseguenza imprevista, porre invece la domanda. In questo esempio, chiedere all'utente di procedere in modo sufficiente indica le conseguenze dell'azione.
  Tutti gli altri	Porre una singola domanda per determinare se l'utente vuole procedere.

• Usare conciso solo una singola frase completa. Rimuovere l'istruzione principale fino alle informazioni essenziali. Se è necessario spiegare di più, usare un'istruzione supplementare.

• Specificare se sono presenti oggetti coinvolti, assegnare i nomi completi.

• Usare formulazioni positive. La formulazione positiva è più semplice per gli utenti di comprendere.

Corretto:

Abilitare la condivisione di file e stampanti?

Non corretto:

Disabilitare la condivisione di file e stampanti?

Tuttavia, la formulazione deve corrispondere al comando associato, anche se il comando è espresso negativamente; Ad esempio, usare disable per confermare un comando Disable.

• Anche se non esistono regole rigide per la formulazione, queste frasi di conferma comuni hanno la connotazione indicata:

  Frase	Connotazione
  Assicurarsi di voler [eseguire un'azione]?	Conferma del risultato diretto di una richiesta utente.
  Vuoi [eseguire un'azione]?	Conferma di un effetto collaterale di una richiesta dell'utente.
  Vuoi [selezionare un risultato]?	Serve un chiarimento.
  [Eseguire un'azione]?	Nessuna connotazione.

• Per le conferme di azioni rischiose, usare il termine in modo permanente per indicare che non è possibile annullare un'azione.

In questo esempio , "permanentemente" indica che l'azione non può essere annullata.

• Usare la maiuscola in stile frase.

Istruzioni supplementari

• L'istruzione supplementare per una conferma si basa sul modello di progettazione:

Etichetta	Valore
Modello	Istruzione supplementare
Conferme di conseguenza impreviste	Porre una singola domanda per determinare se l'utente vuole procedere.
Tutti gli altri	Spiegare eventuali motivi non ovvi per cui l'utente potrebbe non voler procedere. Tali motivi includono: Potenziale perdita di uno o più dei seguenti elementi: Un bene prezioso, ad esempio la perdita di dati o la perdita finanziaria. Accesso al sistema o integrità. Privacy o controllo sulle informazioni riservate. Azioni irreversibili.

• Non ripetere l'istruzione principale con una formulazione leggermente diversa. In alternativa, omettere l'istruzione supplementare se non è più necessario aggiungere.
• Per le conferme impreviste, è consigliabile usare comunque il termine per indicare concisamente che non vi è un motivo per continuare nel caso in cui l'utente non ha trascurato l'istruzione principale. Per altre informazioni, vedere Concetti di progettazione.
• Usare frasi complete, maiuscole e minuscole in stile frase e punteggiatura finale.

Documentazione

Quando si fa riferimento alle conferme:

• Fare riferimento a una conferma in base al titolo se il titolo è specifico per la conferma (ovvero, non per il nome del programma); in caso contrario, farvi riferimento in base alla relativa istruzione principale.
• Se necessario, è possibile fare riferimento a una finestra di dialogo di conferma come messaggio.
• Usare il testo esatto, inclusa la relativa maiuscola.
• Quando possibile, formattare il testo in grassetto. In caso contrario, inserire il testo tra virgolette solo se necessario per evitare confusione.

Esempio: nel messaggio Copia file fare clic sul file più recente.