Questa è la traduzione dell'articolo Inline Validation in Web Forms di Luke Wroblewski pubblicato originariamente su A List Apart il 1 Settembre 2009. La traduzione viene qui presentata con il consenso dell'editore e dell'autore.
I form per il web non sono grandi conversatori. Fanno un po' di domande, poi aspettano fin quando non rispondiamo a tutte prima di rispondere a loro volta. Così, se ci registriamo sull'ultimo fantastico social network o usiamo un sito di e-commerce, ne viene fuori praticamente un monologo.
Per questa mancanza di buone maniere della maggior parte dei form possiamo incolpare il modo in cui sono stati realizzati. I form che usano il classico modello di interattività "invio/refresh della pagina" non rispondono fino a quando non clicchiamo sul pulsante di invio, ma non dovrebbe essere così. La validazione inline e in tempo reale può aiutare le persone a completare i form più rapidamente e con meno sforzo, con meno errori di compilazione e (sorpresa!) più soddisfazione.
La validazione inline da alle persone diversi tipi di feedback in tempo reale. Può confermare una risposta appropriata, suggerire risposte valide, fornire aggiornamenti regolari per aiutare le persone a rimanere nei limiti fissati. Questo feedback può essere presentato prima, durante e/o dopo che l'utente ha inserito le sue risposte.
Testare la validazione inline
Per meglio comprendere le considerazioni di design che stanno alla base della validazione inline ho lavorato con Etre, un'azienda di Londra specializzata in usabilità, per svolgere dei test su 22 utenti medi alle prese con 6 varianti di un tipico form per la registrazione ad un sito. Aramys Miranda ha sviluppato il form usato con i nostri utenti, che avevano un età compresa tra i 21 e i 49 anni.
Dei nostri 6 form, la versione di controllo validava gli input solo quando cliccava sul pulsante "create account". Gli altri 5 usavano differenti metodi di validazione inline. Abbiamo misurato il tasso di successo nella compilazione, i tempi di completamento, il livello di soddisfazione e alcuni metodi standard di tracciamento oculare per ogni variazione. Abbiamo presentato ciascun form con un ordien casuale per minimizzare gli effetti della familiarità con l'interfaccia.
Cosa abbiamo imparato sulla validazione inline?
I nostri partecipanti sono stati più veloci, hanno ottenuto più successo nella compilazione, sono andati meno incontro ad errori quando hanno usato form con validazione inline. Il tracciamento oculare ha mostrato anche che essi fissavano lo sguardo sui form con la validazione inline meno frequentemente e per meno tempo rispetto ai form senza validazione inline, cosa che dimostra come essi abbiano trovato quei form più semplici da processare visivamente. Ciò è avvenuto probabilmente perché non dovevano rileggere l'intero form dopo l'invio per correggere gli errori, errori che invece venivano corretti mentre compilavano il modulo.
Come potete vedere in questo video, le persone sottoposte al test ricevevano una risposta dalla versione di controllo del form dopo averlo completato e cliccato sul pulsante di invio. A quel punto, gli errori venivano mostrati sullo schermo fino a quando il form non veniva riinviato. Inviare e riinviare form per verificare le risposte può condurre ad una certa frustrazione e a comportamenti che vanno sotto il nome di "pogosticking". È qualcosa di comune quando chiediamo alle persone di dare una risposta che non sono in grado di fornire la prima volta che si sentono porre la domanda. Selezionare un nome utente unico, per esempio, può produrre un effetto di "pogosticking": nessuno può sapere in anticipo quali nomi utente sono disponibili su un sito, così si tira a indovinare, si clicca sul pulsante "create account", si scopre che quel nome è già stato scelto, si tira di nuovo a indovinare, si clicca sul pulsante, e così via.
I nostri form con la validazione inline funzionavano diversamente: davano un feedback in tempo reale, mentre le persone compilavano le risposte, usando messaggi di successo diretti e non invasivi (un segno di spunta verde) e messaggi di errore (un traingolo rosso e del testo) accanto ai campi del form. Potete verificare le differenze nel secondo video.
Quando è stato confrontato con la versione di controllo, il form con la validazione inline con la migliore performance mostrava grandi miglioramenti su tutti i dati che abbiamo misurato. Nello specifico abbiamo verificato:
- un 22% in più nel tasso di successo;
- un 22% in meno negli errori commessi;
- un 31% in più nel livello di soddisfazione;
- un 42% in meno nei tempi di compilazione;
- un 47% in meno nel numero di impressioni oculari nei test di eye-tracking.
I commenti dei partecipanti hanno evidenziato una forte preferenza per il feedback in tempo reale:
"Dovresti essere informato sugli errori che commetti mentre compili il form."
"È molto meglio così che compilare tutto e inviare per poi scoprire il tuo nome utente non va bene. È molto meglio quando vieni informato nel corso della compilazione."
Questi risultati evidenziano come la validazione inline ha una forte influenza sui form. Ma qual è il modo migliore per ottenere questi risultati? Quando e come dovremmo validare le risposte dell'utente?
Usare la validazione inline quando le risposte non sono scontate
Non tutte le domande poste in un form sono uguali. Ci sono alcuen cose, come il nostro nome, che sappiamo senza doverci pensare. Altre cose come le nuove password richiedono più ragionamento. Quando si prende in considerazione la validazione inline, dobbiamo prima di tutto capire quali domande il form pone. Ciò è risultato evidente nei risultati dei nostri test.
Nella prima metà del nostro form abbiamo chiesto alle persone cose per cui conoscevano le risposte: il nome, il cognome, l'indirizzo e-mail, il sesso, la nazionalità, il codice postale. Nella seconda parte abbiamo posto domande a cui era più complicato rispondere correttamente la prima volta. I partecipanti dovevano scegliere un nome utente (come facevano a sapere se era disponibile?) e una password (con requisiti di composizione molto rigidi). Non è stato sorprendente osservare diversi comportamenti nella prima e nella seconda parte del modulo.
Solo il 30-50% dei nostri partecipanti ha visto i messaggi di validazione (figura 2) nella prima metà dei nostri form, mentre l'80-100% li ha visti nella seconda. Ciò è forse avvenuto perché i partecipanti non si aspettava una conferma per le risposte corrette nella prima sezione del form. Fidandosi delle loro risposte a quelle semplici domande, la maggior parte delle persone non ha posto attenzione ai messaggi di validazione quando apparivano sullo schermo.
Per contrasto, nella seconda sezione, quando i partecipanti hanno risposto a domande più complicate (come quelle sul nome utente e sulla password), la fiducia nelle risposte date è venuta un po' meno e pertanto sono stai più inclini a cercare una conferma. Inoltre, era più probabile che esitassero, avendo così una maggiore opportunità per vedere i messaggi (compresi quelli già visibili nella prima parte del form). Il path del tracciamento oculare illustra bene questo comportamento (figura 3). I messaggi di validazione sulla destra del campo hanno attirato una grande attenzione nella seconda parte del form, nessuna nella prima.
Queste osservazioni sembrano indicare che la validazione inline è molto utile per i campi di input che sono difficili da completare. Il fatto che i partecipanti erano confusi quando semplici domande erano marcate con un "corretto", supporta questa interpretazione:
"State dicendo che ho inserito un nome valido o che il mio nome l'ho scritto correttamente?"
"Questa è la conferma per un codice postale formattato correttamente o che questo è il mio codice postale giusto?"
Questo tipo di domande dei partecipanti hanno causato qualche piccolo problema nel corso dei test. I nostri partecipanti sapevano che noi non potevamo conoscere il loro nome o il loro codice postale, dunque sapevano che il segno di spunta verde non significava "è corretto". Ma cosa hanno pensato che significasse? Non ne erano sicuri, e questo era un problema. Non sapendo cosa significava il messaggio i nostri partecipanti si sono fermati per fare domande al moderatore del test invece che rispondere con fiducia a domande che erano semplici.
Possiamo dare la colpa al segno di spunta verde che implica un significato di "corretto" per questa confusione, ma abbiamo anche imparato che possiamo eliminare tale confusione riservando la validazione inline per domande per cui la gente ha bisogno di aiuto. L'inconsistenza può essere lo svantaggio di questo approccio. Se messaggi di successo appaiono a fianco di tutti i campi del form tranne quelli semplici, le persone possono pensare che i dati inseriti non sono validi dal momento che non compare alcun messaggio di successo! Il risultato è che possono provare a correggere campi assolutamente validi e corretti. Non siamo sicuri se ciò possa essere un grande problema, ma è certamente qualcosa da prendere in considerazione.
A questo punto rimane da vedere come mostrare all'utente il feedback della validazione. Sarà l'argomento della seconda parte dell'articolo.
Quando mostrare la validazione inline
Una volta stabilito che la validazione inline può fornire un valido aiuto, il passo successivo consiste nel mettere tutto in azione. Per meglio comprendere quando mostrare i messaggi di validazione abbiamo testato una serie di variazioni nella parte superiore del form.
Dopo
In questa versione del form abbiamo mostrato un messaggio di validazione (successo o errore) dopo che l'utente aveva mostrato di aver risposto ad una domanda spostandosi nel campo successivo (tecnicamente parlando è la validazione che avviene in seguito all'evento "onblur").
Mentre
In questa versione abbiamo mostrato un messaggio di validazione mentre l'utente rispondeva a ciascuna domanda (ovvero con l'evento "onkeypress").
Prima e mentre
In questa versione abbiamo mostrato un messaggio di validazione prima che l'utente rispondesse ad ogni domanda(ovvero non appena l'utente spostava il focus su ciascun campo) e mentre rispondeva. Abbiamo insomma combinato il tipo "onblur" e quello "onkeypress".
Si vesa al riguardo il terzo video.
Per le domande relative a nome utente e password abbiamo usato il metodo "mentre" con un leggero ritardo in ogni versione testata. Il nostro precedente lavoro con dei prototipi aveva rivelato che questo metodo aveva senso per domande con forti restrizioni, come la disponibilità di nomi utente liberi o il modo giusto per creare una password sicura.
Il metodo "dopo" aiuta gli utenti a completare il form più velocemente
Quando abbiamo usato il metodo "dopo" nella prima sezione del form, i partecipanti hanno completato il form tra 7 e 10 secondi più rapidamente di quando abbiamo usato i metodi "mentre" e "prima e mentre". Perché? Ecco quello che è accaduto quando gli utenti hanno usato i metodi "mentre" e "prima e mentre". Quando diversi partecipanti hanno notato un messaggio di errore mentre provavano a rispondere ad una domanda, hanno inserito un carattere aggiuntivo nel campo di input, quindi hanno aspettato che il messaggio si aggiornasse. Se il messaggio aggiornato continuava a segnalare un errore, inserivano un altro carattere, quindi aspettavano l'aggiornamento del messaggio di errore, e così via. I tempi i completamento si allungavano.
Il metodo "prima e mentre" non ha solo causato tempi di completamento più lunghi, ma produce anche più elevati tassi di errore e più bassi livelli di soddisfazione. I nostri partecipanti hanno così espresso il loro sfavore per questa soluzione:
"È frustrante il fatto che non hai la possibilità di inserire qualcosa nel campo prima che lampeggi di rosso"
"Quando ho cliccato sul campo First Name, il campo mi ha subito avvisato che il mio nome è troppo corto. Certo che lo è! Non ho ancora nemmeno iniziato!"
"Ho trovato fastidioso come il segno rosso è apparso quando ancora non avevo finito di scrivere. È una cosa che distrae molto."
Queste reazioni negative, i tempi di completamento più lunghi e i tassi di errore mostrano che validare i campi prematuramente può essere dannoso. Invece, quando si valida è meglio fornire un feedback dopo che l'utente finisce di dare una risposta. Oppure, in situazioni in cui le persone hanno bisogno di un aiuto più rapidamente, fornite il feedback mentre si avviano a dare una risposta, ma usate un ritardo appropriato in modo da evitare noiosi messaggi di errore troppo prematuri.
Come mostrare la validazione inline
In ciascuna variazione che ha testato quando mostrare la validazione inline, abbiamo sempre messo i messaggi di successo ed errore sulla destra del campo di input. Ma per saperne di più sul come mostrarli abbiamo testato ulteriori varianti del form: una in cui i messaggi di successo scomparivano con un effetto fade dopo un leggero ritardo e una che inseriva i messaggi all'interno del campo stesso. In ciascuna versione i messaggi di errore scomparivano solo dopo che l'utente aveva corretto l'errore.
Di queste opzioni i nostri partecipanti hanno apprezzato di più i messaggi persistenti. Questi elementi sempre visibili rassicuravano gli utenti sul fatto che i campi ch avevano completato correttamente rimanevano in quel modo. Come ho detto prima si è osservata una leggera confusione sul significato del segno verde: significa corretto o valido? Così stando le cose, potete provare ad aggiungere del testo (tipo "completato!") per confermare ulteriormente che il campo va bene. Potete anche provare altri indicatori nella validazione. Ciò può prevenire la confusione che le persone potrebbero avere con il segno verde tipicamente usato per esprimere la correttezza di una risposta.
Mantenere fissi i messaggi di successo e fuori dal campo
Quando i messaggi di successo svanivano, alcuni partecipanti si sono preoccupati di aver fatto qualcosa che rendeva non validi campi un momento prima corretti. I messaggi persistenti hanno consentito agli utenti che "volevano controllare ogni campo man mano che si presentavano" di fare così, mentre hanno soddisfatto pure quelli che "volevano verificare tutti i campi alla fine".
Mostrare i messaggi di validazione all'interno dei campi non porta benefici. Il posizionamento di questi messaggi era necessariamente inconsistente. Inoltre, i messaggi piazzati all'interno dei campi non erano per nulla più in vista rispetto a quelli piazzati fuori dai campi.
Il risultato
I nostri test hanno fornito risultati molto interessanti. Hanno anche dato l'opportunità di esplorare più a fondo dove, quando e come dovrebbe essere usata la validazione inline per alleviare i fastidi dei form in modo che le persone possano completarli e ottenere quello che desiderano davvero vogliono fare online. Che, credetemi, non è riempire dei moduli!
Ringraziamenti
Vorrei ringraziare Etre per tutto il lavoro di scripting, di esecuzione e per i report. Grazie anche ad Aramys Miranda che ha curato il codice di tutte le variazioni testate.
