it-swarm-eu.dev

Le caselle di allerta dovrebbero essere evitate ad ogni costo?

Grazie a Gabriel Svennerberg e Sam K per questo - sollevato in un commento qui .

Ero piuttosto informato riguardo alle caselle di allerta fino a quando una serie di test per gli utenti in cui era stata istituita una casella di allerta per avvisare gli studenti che se avessero lasciato un corso online in un determinato punto avrebbero perso il lavoro che avevano già fatto. Lasciando da parte il fatto che quella situazione probabilmente non dovrebbe mai sorgere in primo luogo (! No poka-Yoke lì), siamo rimasti molto allarmati da ciò che abbiamo visto.

Gli utenti hanno sostanzialmente cliccato su quella casella di avviso in modo completamente casuale, in base alla loro precedente esperienza di caselle di avviso in altri software.

Solo una piccola minoranza di utenti legge il testo della casella di avviso. La maggior parte ha appena fatto clic su qualcosa: o il pulsante che li ha tenuti al sicuro sulla pagina, o quello che ha eliminato il loro lavoro o la "X" per chiudere il dialogo. La maggior parte erano confusi da qualunque cosa venisse dopo. Scavando più a fondo, sembrava che molte persone avessero appena intrapreso un'azione per le caselle "errore": fai clic su qualcosa per farlo sparire.

Su tale base, fino a che punto possiamo evitare le caselle di avviso?

27

Penso che il motivo principale dell'uso eccessivo delle caselle degli avvisi sia che sono così facili da implementare. È molto più difficile implementare un'interfaccia utente tollerante.

Le caselle di avviso sono errate per diversi motivi:

Innanzitutto, poiché sono modali per natura, interrompono il flusso di lavoro degli utenti e sono quindi attività inadatte che vengono eseguite regolarmente.

In secondo luogo sono inefficaci poiché, come già sottolineato da Andrew, gli utenti tendono a non leggerli e fare semplicemente clic su qualcosa. Se il sistema genera avvisi durante le normali attività, l'utente alla fine tende a ignorarli e fa semplicemente clic su "OK". Quando si rende conto di aver eliminato il documento sbagliato, è già troppo tardi.

A mio avviso, gli avvisi dovrebbero essere riservati per eventi veramente critici, come quando si sta per eseguire un'azione irreversibile che non viene eseguita regolarmente (ad esempio, l'eliminazione di un database). Altrimenti ci sono modi molto migliori di progettare le cose.

22

Gli utenti hanno sostanzialmente cliccato su quella casella di avviso in modo completamente casuale, in base alla loro precedente esperienza di caselle di avviso in altri software. ... Su tale base, fino a che punto possiamo evitare le caselle di avviso?

La domanda quasi risponde a se stessa: Non usare mai caselle di avviso.

Le finestre di dialogo e di avviso modali pongono una barriera di fronte all'utente. Naturalmente rispondono respingendo la barriera. Spesso non leggono gli avvertimenti e finiscono per fare qualcosa di cui si pentono.

Ecco un'alternativa:

  • Per i messaggi informativi che non richiedono intervento, presentare il messaggio in modo discreto in linea (come fa questo sito).
  • I messaggi di conferma dovrebbero essere eliminati il ​​più possibile. Invece di confermare un'operazione in anticipo, è sufficiente eseguirla e lasciare che l'utente la annulli successivamente.
  • Le domande a cui l'utente deve rispondere devono essere presentate all'interno della pagina in un formato ordinario. Dal momento che questo non presenta un popup eliminabile, non attiva il riflesso "Fai clic su qualsiasi cosa per eliminarlo".
17
Bennett McElwee

Andrea,

Quando si tratta di caselle di allerta, sono perfettamente buone da usare. Hai solo bisogno di sapere quando e quando non usarli. Sapendo quando è facile, basta seguire questa semplice logica:

Non usare mai un avviso, quando ciò che intendi è annullare.

Questa logica è trattata in un articolo approfondito, che puoi leggere qui .

A quanto pare, stai usando correttamente una finestra di avviso, perché stai avvisando il tuo pubblico che stanno per perdere le loro informazioni. Detto questo, ci sono ancora domande da porre:

  1. Riesci a rilevare se una persona ha cambiato qualcosa? In tal caso, puoi eliminare l'avviso se non ci sono informazioni da perdere.
  2. Le persone non leggono o non capiscono il tuo avviso? Se non stanno leggendo e facendo clic sul pulsante "OK" in modo insensato, non utilizzare "OK". Rinominalo, "Esci dall'applicazione e perdi quello che ho fatto." Se non comprendono il tuo avviso, prova un'altra lingua.

Naturalmente, ripetere il test delle modifiche. Ciò che molto probabilmente scoprirai è che non riuscirai mai a far leggere a tutti una casella di avviso, non importa cosa fai. Ma se riesci a ottenere una percentuale di cui sei soddisfatto, è tutto ciò di cui hai bisogno.

Brenton

5
Brenton

Il vero problema è che le caselle di avviso vengono implementate troppo spesso e senza alcun pensiero dato all'utente. Guarda l'avviso che ho ricevuto quando ho messo a fuoco questo campo di commento (ma non è stato digitato nulla!) E ho provato a chiudere questa finestra: http://www.flickr.com/photos/jonesabi/4033266787/ =

OK/ANNULLA? Sul serio?

4
Abi

Hmm. Molto interessante, Andrew. Mostra perché l'assunzione senza prove è generalmente negativa.

La mia argomentazione sull'uso delle caselle di avviso era in realtà basata sull'aspetto familiare di esse, ma da quello che stai dicendo sembra più negativo che positivo. La familiarità genera apatia, suppongo.

Immagino che una domanda aggiuntiva sia se utilizzare il singolo avviso del pulsante "OK" anziché l'avviso di conferma "OK"/"Annulla". Uno dei maggiori svantaggi di quest'ultimo è che non è possibile modificare il testo dei pulsanti e il più delle volte, "OK" e "Annulla" sono fuorvianti e irrilevanti.

Ottima domanda, comunque. Se non utilizziamo gli avvisi (e suppongo che intendo esclusivamente gli "avvisi di JavaScript"), quali altre opzioni ci sono e come si confrontano dal punto di vista dell'usabilità?

2
Sam K

Semplicemente: un avviso è esattamente questo: un avviso. Hanno posto lì, ma a volte sono anche molto usati troppo.

Penso che uno dei problemi principali con le caselle di avviso sia che sono semplicemente brutti e non molto personalizzabili nella maggior parte dei casi. I progettisti/sviluppatori troveranno invariabilmente una soluzione "personalizzata", diversa per ogni soluzione/applicazione, quindi non c'è coerenza che è un altro grosso problema che gli utenti devono affrontare.

(E questo vale per tutte le lingue/tecnologie)

2
Kieron

Gli avvisi sono inoltre dannosi perché impediscono alle attività di essere completamente automatizzate in grandi lotti. Supponiamo che il tuo programma o app esegua alcune attività X (che richiedono 30 secondi) sull'input Y. Supponiamo ora che l'utente desideri eseguire l'attività X per l'input Y per 100 valori di Y. Se l'attività X non ha caselle di avviso, l'utente può impostare l'attività per l'esecuzione su 100 input e l'utente torna 50 minuti dopo per trovare tutte le 100 attività completate. Ma se l'attività X prevede l'apertura di una finestra di avviso (in qualsiasi momento nei 30 secondi di lavoro prevalentemente automatizzato), il computer deve attendere l'utente e l'utente deve guardare e supervisionare un'attività che ora chiede all'utente lo stesso domanda 100 volte. Un design migliore sarebbe impostare un'opzione/preferenza e salvarla, o almeno avere una di quelle caselle con una casella che dice "Non chiedere più".

2
Jared Updike

Sì a tutte le cose da evitare AB, specialmente per mezzo di un design migliore.

Ora, nel caso tu decida di usarne uno, allora deve essere progettato.

L'AB più semplice ha tre parti: titolo, testo e pulsanti.

Uso titoli che comunicano il significato di AB, come "Cestino cambia?", In questo modo, in modo che possa essere subito criticato.

Nel testo spiego di più, come "Hai modificato questo documento e ora stai per annullare tali modifiche. Fai clic su" OK "per annullare," Annulla "per tornare in modalità sicura".

L'etichettatura dei pulsanti è importante. Il pulsante "Fallo", quello principale, deve essere allineato con il titolo. Se il titolo è "rilascialo", il pulsante principale deve essere "Sì" o "OK".

Con questo tipo di design cerco di abbreviare il tempo in cui l'utente deve essere consapevole dell'esito dell'accettazione dell'offerta AB.

2
Juan Lanus

Concordo sul fatto che dovrebbero essere evitati a tutti i costi; francamente, la maggior parte degli utenti ha imparato a ignorarli.

Tuttavia, che dire di quei momenti in cui è assolutamente necessario assicurarsi che abbiano visto e letto il messaggio? Su uno dei miei progetti, gli utenti devono essere avvisati dei prossimi tempi di inattività ... di solito, riceveranno un'e-mail (che viene ignorata), oltre a un messaggio chiaro sulla dashboard quando accedono (che ignorano anche).

Un pensiero era di far apparire una finestra modale al primo accesso, ma è probabile che facciano semplicemente clic per chiuderla. Per questa particolare applicazione, è cruciale che ne sono stati informati poiché influisce negativamente sul loro lavoro.

Cosa poi? Includo un timer di 5 secondi prima che venga visualizzato un pulsante "ignora"? Sì, probabilmente questo farà incazzare l'utente, ma non sarebbe efficace, per quelle poche volte in cui è davvero necessario?

0
Lynn Cyr

cerco di evitarli il più possibile rendendo chiaro ciò che accadrà dopo dall'interazione precedente. basta chiedere a te stesso è una casella di avviso un'esperienza liscia? no ha la sua interruzione e "alerty" hahah.

anche perché i dati devono essere persi. ci sono modi per conservare i dati anche se la persona ricarica o se ne va via. ho quando i moduli perdono dati all'interno della mia sessione corrente.

solo la mia opinione :)

0
valtronic

Se strettamente necessario, alla fine si può andare a creare un paio di messaggi di avviso nelle applicazioni. tuttavia, è necessario tenere presente un problema relativo alla densità di informazioni che si desidera inserire nella propria applicazione.

Potresti voler avere un'app che fornisca all'utente molti feedback sull'utilizzo o un'app che non fa una cosa del genere e che abbia un flusso di informazioni minore.

In ogni caso, dovrei consigliare di avere zone Nell'applicazione in cui vi sono più informazioni, zone che hanno meno informazioni, zone che si trovano nel mezzo e mantenere una sequenza temporale di eventi nella cache che consente di regolare le informazioni visualizzate in base all'input dell'utente, il numero di volte in cui l'applicazione è stata utilizzata, ecc., può essere una strategia di Nizza. giocando quindi con la densità degli elementi dell'interfaccia utente in conformità con l'analisi dell'input dell'utente

0
tmm88