Come gestiresti gli utenti che non leggono le finestre di dialogo? [chiuso]
https://stackoverflow.com/questions/125269
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Un recente articolo su Ars Technica discute un recente studio condotto dal Dipartimento di Psicologia della North Carolina State University, che ha mostrato che gli utenti hanno la tendenza a fare tutto il necessario per sbarazzarsi di una finestra di dialogo per tornare al loro compito a portata di mano. La maggior parte di essi farebbe clic su OK o Sì, minimizzare la finestra di dialogo o chiudere la finestra di dialogo, indipendentemente dal messaggio visualizzato. Alcune delle finestre di dialogo visualizzate erano reali e alcune erano false (come quei popup visualizzati da pagine Web che si presentano come un avviso antivirus). I tempi di risposta indicherebbero che quegli utenti non stanno realmente leggendo quelle finestre di dialogo.
Quindi, sapendo questo, in che modo ciò influirebbe sul tuo design e cosa proveresti a fare al riguardo (se non altro)?
Soluzione
Cerco di progettare applicazioni robuste di fronte agli incidenti, scivolando (operazioni involontarie, come fare clic nel posto sbagliato) o errori (errori cognitivi, come fare clic su OK o Annulla in una finestra di dialogo). Alcuni modi per farlo sono:
- infinito (o almeno multi-step) annulla / ripristina
- integrare la documentazione con l'interfaccia, tramite tooltip dinamici e altri mezzi di comunicazione sensibili al contesto (un documento particolarmente rilevante riguarda 'Surprise, Explain, Reward' (collegamento diretto: SER ) - utilizzando le risposte psicologiche tipiche a comportamenti imprevisti per informare gli utenti)
- Incorporare lo stato del sistema in detta documentazione (utilizzare i dati dell'utente corrente come esempi e rendere concreta la documentazione utilizzando i dati che possono vedere adesso )
- Aspetto errore utente. Se esiste la possibilità che qualcuno proverà a scrivere su un: \ quando non è presente un disco, implementare un timeout in modo che il sistema possa non funzionare correttamente e richiedere un'altra posizione. Salvare i dati in memoria finché non sono al sicuro su disco, ecc.
Questo si riduce a due cose fondamentali: (1) Programma difensivo e (2) Tenere l'utente il più informato possibile. Se l'interfaccia del sistema è facile da usare e si comporta in base alle loro aspettative, è più probabile che sappia quale pulsante fare clic quando appare una finestra di dialogo fastidiosa.
Provo anche molto, molto duramente a evitare qualsiasi cosa modale, quindi gli utenti possono ignorare la maggior parte delle finestre di dialogo che devo usare, almeno per un po '(e quando hanno davvero bisogno di prestare attenzione a loro, hanno abbastanza informazioni per sapere cosa farne).
È impossibile realizzare un sistema completamente a prova di errore, ma ho scoperto che le tecniche di cui sopra vanno molto lontano nella giusta direzione. (e sono stati incorporati nei sistemi utilizzati per sviluppare Surprise Explain Reward e altri strumenti che sono stati controllati da studi approfonditi degli utenti.)
Altri suggerimenti
In primo luogo l'uso del colore e delle icone dovrebbe aiutare l'utente a dare una certa consapevolezza visiva della gravità del problema, il rosso per trasmettere eccezionale, il giallo per trasmettere un avvertimento e il bianco per trasmettere informazioni.
In secondo luogo l'uso di verbi sui pulsanti della finestra di dialogo dà agli utenti un'idea di ciò che stanno dicendo al sistema anche se non leggono il testo della finestra di dialogo.
Infine, se sei interessato a esaminare un paradigma di notifica completamente diverso, controlla la barra delle informazioni o la barra di notifica implementata in Firefox e Internet Explorer. StackOverflow utilizza lo stesso tipo di meccanismo per avvisare gli utenti quando hanno ottenuto un nuovo badge.
La barra delle informazioni non è invadente e rimane nella parte superiore dello schermo in attesa dell'attenzione dell'utente. Penso che sia una grande metafora del design.
Ecco un paio di tutorial di implementazione:
Ecco Guida di Microsoft sulla progettazione dei dialoghi , tocca il Anche concetto della barra delle informazioni.
Immediatamente mi viene in mente il libro di Steve Krug Don't Make Me Think .
Nella progettazione di finestre di dialogo, messaggi di stato all'utente, ecc. è bene usare l'iconografia e i suggerimenti sul colore su ciò che le parole effettivamente dicono.
Evidenzia quindi i messaggi di errore rossi, gli avvisi gialli, ecc.
The Humane Interface, di Jef Raskin merita una lettura. Una finestra di dialogo è l'ultima risorsa e un segno di design scadente. La maggior parte non è necessaria e, come hai scoperto, sono tutti ignorati dagli utenti.
Perché c'è una finestra di dialogo? Risolvi il problema: non chiedere agli utenti di confermare un'operazione, ma semplifica l'operazione. Non aprire una finestra di dialogo che annuncia un errore: esegui comunque il ripristino (o qualsiasi cosa sia possibile). Sicuramente non mostrare finestre di dialogo che hanno un solo risultato (solo le caselle "OK" sono il diavolo), presentano le informazioni all'interno dell'app in modo discreto.
Un paio di suggerimenti
- Usa le caselle solo quando assolutamente necessario.
- Imposta sempre l'opzione predefinita sull'opzione meno pericolosa
Mi viene in mente un episodio di .NET Rocks (credo episodio 338," Mark Miller su Science of Good UI " ) tratta proprio questo argomento. Penso che la chiave di tutta questa discussione sia che questa è la progettazione dell'interfaccia utente di base presa troppo in là. Laddove il modale era un tempo un mezzo di comunicazione accettabile, ora scopriamo che è diventato un passo falso di programmazione. Gli utenti comprendono che 6 volte su 10 le informazioni non sono abbastanza pertinenti da preoccuparsi. Di conseguenza trattano tutti i modali allo stesso modo: impotenza appresa. Se viene visualizzato un modale che mi informa che si è verificato l'errore di applicazione X e tutto ciò che posso fare clic è "quot" OK " - anche quando non penso che sia "OK" Imparo un comportamento particolare. Assosciate i modali con l'idea che probabilmente non posso farci molto, ma se faccio clic su OK / Sì, posso tornare a ciò di cui ho bisogno.
Quindi, perché è ancora usato? Forse gli sviluppatori hanno cercato di evitare il fatto che lo sviluppo di applicazioni sta diventando molto più di una semplice interfaccia di base e gli utenti richiedono una progettazione dell'interfaccia utente fluida: i vecchi standbys sono difficili da rinunciare ...
Penso che la chiave qui sia capire che una buona progettazione dell'interfaccia utente ora indica che le interruzioni (anche per l'utente di computer più alle prime armi) sono fastidi e che dobbiamo sforzarci di avere un'esperienza utente senza interruzioni in cui il focus dell'applicazione è l'utente - non le esigenze dell'applicazione tramite prompt e segnalazione errori - non consentire a un utente di affrontare situazioni in cui non gli interessa.
Spesso gli sviluppatori usano finestre di dialogo modali semplicemente perché è facile codificarle.
Tuttavia, le notifiche non modali sono spesso più convenienti da gestire per l'utente.
Un suggerimento:
- Non usare finestre di dialogo. Finestre di dialogo particolarmente modali, OK / Annulla.
A volte è difficile ... come gestisci l'apertura di un file? A volte è facile ... devi davvero avvisare l'utente che stanno per sovrascrivere un file? È probabile che, se faccio clic ciecamente su " OK " ;, non ascolterò alcun avviso.
Se è necessario utilizzare una finestra di dialogo, inserire didascalie descrittive sui pulsanti all'interno della finestra di dialogo.
Ad esempio, anziché i pulsanti OK e Annulla, fai loro dire " Invia fattura " e " Torna indietro " ;, o qualsiasi altra cosa sia appropriata nel contesto della finestra di dialogo.
In questo modo, il testo è proprio sotto il loro cursore e hanno buone possibilità di comprensione.
Mac OS X lo fa quasi sempre. Ecco un'immagine di esempio.
Modifica:
Questa è un'immagine migliore e L'ho trovato sul sito della Apple Human Interface Guideline, che è un ottimo riferimento e molto leggibile. Questo documento su quel sito riguarda i dialoghi.
Domanda sbagliata. " Come gestiresti gli utenti " inizia dalla parte sbagliata.
La domanda corretta è " Dato che i dialoghi distraggono gli utenti dall'attività in corso, quali alternative migliori esistono? " ;.
Quando lavoriamo per raggiungere un obiettivo o completare un'attività, possiamo distinguere tre situazioni:
(1) L'applicazione giunge alla conclusione che non è possibile intraprendere azioni che consentano all'utente di raggiungere l'obiettivo. Fai apparire un messaggio, con un pulsante per chiuderlo. Non ti importa se il lettore lo capisce, dal momento che il risultato non importa comunque.
(2) È possibile eseguire solo un'azione oppure le alternative sono irrilevanti per l'utente. Non disturbarlo affatto.
(3) Esistono due o più modi per raggiungere l'obiettivo. Consenti all'utente di scegliere tra questi. Non formulare questa domanda come una domanda sì / no. (Vista offre questo come una finestra di dialogo comune, per sostituire la finestra di messaggio.) Se possibile, non renderlo una scelta irreversibile.
L'eccezione a questa regola è la situazione in cui l'utente si aspetta una domanda sì / no. Ma davvero, se è così, allora perché la domanda non fa parte del normale flusso di lavoro? Le finestre di dialogo non rientrano nel normale flusso di lavoro.
Penso che probabilmente vorrai leggere questo documento: " Impatto delle interruzioni ad alta intensità di stile negoziato sull'estremità- Debug degli utenti " , TJ Robertson, Joseph Lawrance e Margaret Burnett, Journal of Visual Languages ??and Computing 17 (2), 187-202, aprile 2006.
Ha posto una domanda simile. Il risultato è stato, far sapere all'utente che si desidera la sua attenzione, quindi sedersi e attendere che l'utente risponda. Tuttavia, non interrompere l'utente, non è quello che vuole.
La [Lightbox] ( http://en.wikipedia.org/wiki/ Lightbox_ (JavaScript)) la finestra di dialogo modale sembra una tecnica efficace in alcuni casi (derivazione web 2.0, ma può essere implementata in altri contesti).
Un altro punto: se puoi rinunciare a una finestra di dialogo per una Undo (Gmail per uno ha sostenuto questo concetto come comportamento standard di webapp) che è qualcosa da considerare.
Se devi usare una finestra di dialogo, premia l'utente con un testo esplicativo simpatico o persino satirico e molto breve . Se di tanto in tanto distribuisci qualcosa di esilarantemente scandaloso, leggeranno tutto .
L'utente sta funzionando pericolosamente basso buon senso. Rimuovi questo utente e inserirne un altro.
Ho poca pazienza con gli utenti che non leggono ciò che mi ha richiesto molto tempo e sforzi per sviluppare: 1) l'applicazione 2) le istruzioni A parte questo, se non leggi e semplicemente fai " qualunque cosa prende " sei da solo. Lo dico in anticipo. Progetto le mie applicazioni per essere il più intuitivo possibile e ci sono ancora persone che faranno telefonate di supporto di punto in bianco, come un bambino che sbuca in classe quando non dovrebbe esserlo. Non ho tolleranza per quello. Leggi il manuale, leggi le finestre di dialogo: le risposte al 99% dei problemi sono proprio lì.
Un sacco di buoni consigli sopra. Voglio solo aggiungere ai consigli del libro - Joel Splosky "User Interface Design for Programmers" vale la pena leggere il libro:
Una cosa che puoi fare è disattivare il pulsante OK per 3 secondi.
Firefox lo fa quando installi un'estensione.
Modifica: Va bene, alcune persone lo trovano fastidioso. Penso ancora che circa 1 secondo andrebbe bene. Sopprimerebbe l'istinto di clic su OK istantaneo che hanno le persone (me compreso) e forzerebbe una doppia presa. Naturalmente, anche questo infastidirà le persone se il tuo dialogo non è qualcosa che devono effettivamente leggere.
Prima di tutto, lo stupido dovrebbe far male, ma di solito non è così ...
La prossima cosa migliore è includere un'icona che tenta di comunicare la gravità del problema. Una percentuale di coloro che non leggeranno potrebbe cambiare abitudine se l'icona della finestra di dialogo sembra minacciosa. Qualche percentuale non lo leggerà a prescindere.
Includi un quiz a scelta multipla alla fine della finestra di dialogo, a cui l'utente deve selezionare la risposta che mostra di aver letto e compreso il testo. Cambia casualmente l'ordine delle scelte in modo che non possano sempre fare clic sulla stessa.
Aiutare a modificare il testo e il modo in cui funziona la finestra di dialogo. Ad esempio, avere i pulsanti OK / Annulla tende a consentire agli utenti di ignorare la maggior parte della finestra di dialogo. Se rimuovi i pulsanti normali e li sostituisci con collegamenti a comandi wordier, è più probabile che gli utenti leggano ciascun pulsante perché l'opzione "rapido, vai via" non è disponibile.
Io chiamo questo il "pilota automatico" problema.
- Non utilizzare i pulsanti OK, Annulla nella parte inferiore dello schermo. Guarda come Vista tenta di forzare gli utenti a prendere una decisione reale.
- Disabilita i pulsanti per alcuni secondi, visualizza un " Tempo di pensare " Timer / ProgressBar. Quindi l'utente non può fare clic sul pilota automatico. Gli utenti tendono a trovarlo molto fastidioso.
Non usare la conferma (sei sicuro? Sì / No), ma usa Annulla.
Non visualizzare avvisi popup che bloccheranno , poiché gli utenti proveranno a riprendere a lavorare il più rapidamente possibile, ignorando il messaggio e semplicemente facendo clic su di esso. Usa qualcosa come la barra delle informazioni di Internet Explorer, che non blocca.
Puoi evitare di usare tutte le finestre di dialogo! In alcuni programmi è presente un minibuffer che mostra errori e avvisi. Oltre a ciò, potrebbe anche chiederti una cosa, dove devi digitare ciò che vuoi fare. È una soluzione abbastanza pulita e piacevole, tendo a preferirla rispetto a una barra dei menu.
Ma se devi davvero usare le finestre di dialogo, prova questo:
- Solo una frase per finestra di dialogo
- Al massimo due o tre pulsanti
- Rendi il testo leggibile all'interno della finestra di dialogo (più grande, nero su bianco)
- Piuttosto usa ripetutamente una finestra di dialogo che molte piccole (suggerimento: casella di riepilogo)
Cosa penso delle finestre di dialogo? In poche parole: sono cose stupide e stupide. I programmi che li usano si fanno strada e mi rallentano con le loro stupide domande insignificanti. Inoltre, spesso i programmi che utilizzano finestre di dialogo sono piuttosto stupidi.
