Convalida in tempo reale, UX buona o cattiva
Ho un modulo di iscrizione in cui ho effettuato una convalida IN TEMPO REALE quando l'utente inizia a digitare come vedi nell'immagine.
Non so se questo danneggi l'esperienza dell'utente o no, e inoltre non ho trovato una risorsa su questo tipo di convalida.
Risposte
Per citare da nngroup.com :
7. Non convalidare i campi prima che l'input sia completo
...
Può essere fastidioso vedere un messaggio di errore prima di avere la possibilità di terminare la digitazione.
La convalida non dovrebbe iniziare prima del completamento dell'input
Quando l'utente inizia a immettere un valore corretto, non dovrebbero essere visualizzati errori durante la digitazione. L'input è considerato completo quando
- lo stato attivo per l' input viene perso (spostamento in un altro campo) o
- il modulo viene inviato (es. invio automatico quando si preme invio) o pari
- dopo non aver ricevuto input per un po 'di tempo (es. 3sec dopo l'ultimo evento di input).
La visualizzazione immediata degli errori di input durante la digitazione è molto fastidiosa ("deve contenere almeno 3 caratteri" quando si inizia a digitare) e raramente è utile.
Gli errori di convalida dovrebbero essere rimossi al volo
Una volta che il campo è stato convalidato e mostra alcuni errori, l'utente vuole che l'errore svanisca non appena il valore modificato è corretto, non quando lascia il campo o invia il modulo (che probabilmente sarà comunque disabilitato fintanto che ci sono errori visualizzato).
Ciò può essere ottenuto rimuovendo tutti gli errori dal campo quando diventa di nuovo sporco (e riconvalidandolo in seguito all'invio o al focus perso), o riconvalidando automaticamente il campo ogni volta che viene modificato.
Piuttosto che visualizzare continuamente un messaggio di convalida rosso quando l'utente non ha soddisfatto i requisiti di un campo, una buona alternativa è (1) visualizzare un suggerimento che dice all'utente cosa è previsto e (2) visualizzare un messaggio verde "requisiti soddisfatti" quando l'utente ha inserito un valore valido. Puoi diventare verde non appena l'input è OK.
Dipende dal tipo di campo di input.
- Per il campo e-mail:
Non vuoi essere troppo nervoso. Lascia che l'utente finisca di digitare l'indirizzo e-mail. Se il campo di input diventa rosso con un testo di errore nel momento in cui l'utente inizia a digitare, ciò darà fastidio all'utente.
L'approccio giusto sarebbe lasciare che l'utente finisca di digitare e quando l'utente sposta il focus lontano da quel campo, convalidare e mostrare se sembra buono o lanciare un testo di eccezione se ce n'è uno.
- Per il campo nome utente e password:
I campi nome utente e password devono essere convalidati prima dell'invio perché hanno i requisiti di input più severi. Quindi mostra chiaramente all'utente cosa è accettato e cosa non lo è in tempo reale mentre inizia a digitare.
Link agli articoli:
https://designmodo.com/ux-form-validation/
https://uxmovement.com/forms/why-users-make-more-errors-with-instant-inline-validation/
La convalida in tempo reale funziona se gestisci correttamente le risposte incomplete.
L'esempio fornito è una cattiva interfaccia utente perché "reara" è un modo valido per avviare un indirizzo email. Un esempio in cui la convalida in tempo reale può rifiutare una risposta incompleta è "reara @@". In tal caso la convalida in tempo reale può rifiutarla senza attendere il completamento.
In generale, è necessario visualizzare un messaggio di errore quando non è presente alcun input aggiuntivo che possa rendere valida la risposta. La difficoltà di rilevarlo varia da caso a caso. Se hai un dizionario, è abbastanza facile. Con le espressioni regolari, meno.
Naturalmente aiuta ad avere buoni messaggi di errore, che sono appropriati nel contesto di un input incompleto. "Un indirizzo email dovrebbe contenere esattamente un segno @", ad esempio.
Se non puoi gestire risposte incomplete, ad esempio perché è sempre possibile inserire un suffisso per rendere legale un particolare campo, allora dovresti attendere l'input completo come suggerito nelle altre risposte.
È bene convalidare dal vivo. Tuttavia, tale convalida deve distinguere tra due casi:
- input che può essere reso valido aggiungendo elementi alla fine e
- input che non può essere reso valido aggiungendo cose alla fine.
Quest'ultimo caso dovrebbe far apparire immediatamente il messaggio di errore, mentre il primo deve attendere il completamento dell'input.
Ma come puoi distinguere l'uno dall'altro?
È un po 'complicato con gli strumenti attuali, ma se stai scrivendo il tuo motore di espressioni regolari (o qualche altro tipo di macchina a stati finiti per la convalida) puoi ottenerlo in questo modo:
- se il motore raggiungeva la fine della regexp (lo stato dell'obiettivo), c'era una corrispondenza.
- se il motore ha raggiunto la fine della stringa , potrebbe esserci una corrispondenza in seguito.
- se neanche il motore può raggiungere, non ci sarà mai una corrispondenza.
Il problema è che la maggior parte dei linguaggi di programmazione non fornisce alcuna indicazione sul raggiungimento della fine della stringa. Inoltre, anche se si tratta di una modifica minore a qualsiasi motore regexp esistente, il lancio del tuo è praticamente certamente fuori portata per ogni progetto di progettazione dell'interfaccia utente di sempre.
Risposta semplice immagino che se si tratta di una pagina di accesso con 3-4 campi è completamente corretto aggiungere la convalida quando l'utente fa clic su Invia
Forme lunghe il controllo di convalida dovrebbe attivarsi quando l'input si trova su qualsiasi altro campo eccetto il campo menzionato.
Questo è fattibile in Javascript
Ho scritto un articolo sul problema con la convalida dal vivo :
In breve: fornisce un feedback troppo presto e spesso prima che l'utente abbia avuto la possibilità di digitare la risposta OPPURE lo fornisce troppo tardi una volta che l'utente ha finito di digitare la risposta e si concentra sul campo successivo che risponde alla domanda successiva.
Concentrati invece su:
- etichetta chiara e concisa, testo di suggerimento e messaggi di errore
- perdona errori banali
- consentire all'utente di inviare il modulo quando è pronto
In questo modo gli utenti vedranno molto raramente un messaggio di errore e quando lo faranno, sarà quando si aspettano di vederne uno.