Usabile.it

Comprensibilità linguistica

Usare per ogni form testi introduttivi che spieghino esattamente cosa è necessario fare.

I testi introduttivi sono quelli che vengono presentati in cima al form, subito dopo il titolo, per spiegarne eventualmente il senso e il funzionamento. In tutti i form abbastanza complessi dovrebbero essere presenti, ma essere estremamente sintetici e focalizzati a chiarire. Non dovrebbero essere testi che “vendono”, ma che spiegano all’utente cosa e perché.

Usare per ogni campo etichette verbali chiare per l’utente.

Ogni campo dovrebbe avere un’etichetta verbale che spieghi il dato che l’utente deve inserire o selezionare, in maniera chiara e non ambigua.

Presentare informazioni di supporto sensibili al contesto per i diversi campi, o per i più ambigui.

Spesso un’etichetta iniziale non è sufficiente a spiegare quale dato viene richiesto o perché viene richiesto. A volte il dato è chiaro ad utenti esperti ma non ad utenti inesperti. È utile prevedere fin dall’impaginazione la possibilità di inserire testi ulteriori per spiegare meglio il dato richiesto. Due soluzioni, a seconda dei casi, sono particolarmente efficaci:

1. Inserire il testo in punto fisso dell’impaginato
2. Inserire il testo in elementi a comparsa attivabili dall’utente.

Il modulo di iscrizione a Blogger è un esempio di come una colonna intera del modulo viene riservata ad un testo esplicativo.

Esempio di testo esplicativo per ogni campo da Blogger.com

In altri casi il testo esplicativo può invece venir presentato a comparsa, cliccando o passando sopra un simbolo con il punto interrogativo o il simbolo della “i” di informazioni. Naturalmente è importante che questi testi siano perfettamente comprensibili per l’utente.

Operabilità

Assicurarsi che sui campi e sui bottoni si possa sempre operare con facilità.

Non parliamo tanto degli errori in inserimento del form, ma di selezione del campo. Tendine che non consentono di scorrere le voci, che si chiudono prima che l’utente riesca a spostarsi, campi che cancellano (o che non cancellano quando lo si vuole fare…) quello che si è scritto, selezioni non deselezionabili… tutte cose che vanno testate con cura e accuratamente evitate. E’ un tipo di errore che può capitare solo in certi punti del form o ripetersi spesso: diverse valutazioni di questo errore, diverse cause e diverse soluzioni sono di conseguenza possibili.

Non aprire nuove finestre senza motivo.

Non è un ordine tassativo (si veda l’articolo sulle finestre modali). Ma mi capita spesso di utilizzare o analizzare form che aprono nuove finestre, a volte a dimensione intera (in modo che se l’utente non se ne accorge non funziona più il tasto back del browser), altre di dimensioni più piccole. In alcuni casi particolarmente problematici, vi sono 5 o 6 finestre che si aprono in successione. Al punto che si perde facilmente la relazione fra di esse. Inutile dire che vi sono altri modi per chiedere informazioni specifiche, come riferiamo in un precedente articolo, e che vanno dove possibile preferiti.

Messaggi e recupero dell’errore

I messaggi d’errore dovrebbero essere presentati in pagina, contestualmente al punto in cui l’errore si verifica.

Non dovrebbero essere cioè presentati solo con un alertbox, che non ha alcun riferimento al contesto della pagina². In ogni caso, a beneficio di tutti, gli errori devono essere segnalati in prossimità del campo interessato.

In questo esempio i messaggi di errore sono pertinenti ai singoli campi. Un riepilogo dell’errore può comunque essere utile in cima a tutti i campi.

Quando presentare l’errore? Vi sono due soluzioni a seconda delle tecniche che si usano. Con tecniche lato server (php, asp, ecc.) gli errori sui campi vanno presentati al ricaricamento della pagina dopo il tentativo di invio. Con tecniche lato client (ajax, javascript) è possibile presentare i messaggi di errore contestualmente. E’ possibile provvedere anche alla validazione del campo in maniera asincrona (si vedano alcune tecniche Ajax per questo). Per ragioni di accessibilità è bene duplicare i controlli anche con tecnologie lato server.

I messaggi di errore devono essere presentati in un linguaggio chiaramente comprensibile e spiegare all’utente cosa dovrebbe fare.

Il linguaggio deve spiegare in maniera comprensibile quale sia l’errore e soprattutto cosa dovrebbe fare l’utente a quel punto. Luca Chittaro presenta un evidente esempio di violazione di questa linea guida in uno degli ultimi post del suo blog, riguardante il sito della Ryanair.

Dovrebbe essere possibile tornare indietro a modificare senza difficoltà i passaggi precedenti.

Vale per i form suddivisi in più pagine. In quei casi ci dovrebbe essere un tasto “indietro”, sulla sinistra in cima e/o in fondo alla pagina, opposto ad un tasto “avanti” che dovrebbe stare sulla destra, per consentire di tornare a modificare le impostazioni precedenti.

In quel caso, anche i dati inseriti dall’utente nella pagina che poi non ha completato, dovrebbero essere mantenuti quando egli vi ritorna.

Un esempio di presenza di tasti “indietro” e “continua” (qui preferito ad “avanti”) in un form su più pagine. Non viene presentato però alcun riferimento a quante pagine si devono compilare. Inoltre è particolarmente mal riuscito il layout visivo.

Il sistema dovrebbe tollerare più formati per l’inserimento dei dati oppure vincolare chiaramente al formato necessario

Il problema è particolarmente complesso per tutti i dati di tipo numerico, come date o codici. Ma è importante approfondirlo anche per altri tipi di interfaccia. Si vedano per esempio le soluzioni di tre mascherine per le mappe, che richiedono quindi in input un indirizzo:

L’interfaccia per le mappe di Google consente l’inserimento in formato testo. Accetta un’unica stringa, e si incarica di interpretare via e città.

Tuttocittà invece richiede di spezzare i dati su più campi.

Anche Mappy richiede di spezzare i dati su più campi. Ma se lo compilate dopo esservi abituati a Tuttocittà rischiate di sbagliare l’inserimento, perché il layout visivo è simile, ma l’ordine dei campi è cambiato. Che senso ha usare un layout simile alla concorrenza, ma cambiarne il funzionamento? Se esiste un precedente diffuso, è meglio per gli utenti che anche i concorrenti mantengano questo standard. Oppure, che usino uno standard chiaramente diverso e più efficiente, come nel caso della linea unica di Google Maps.

Complessità della procedura

Dovrebbero essere richieste solo le informazioni strettamente necessarie

Compilare i form è noioso e a rischio di errore. Perciò i form dovrebbero essere semplici. Se ci sono informazioni che possono essere dedotte dal sistema da altri dati inseriti dall’utente (ad esempio il codice fiscale qualora fossero già stati inseriti luogo e data di nascita) bisognerebbe evitare di chiederle. Ma soprattutto se ci sono informazioni opzionali, che non sono necessarie al sistema, andrebbero omesse. Minore è il numero di campi, meglio è per l’utente. Questo è tanto più vero quanto più il form è complesso.

Per procedure che si articolano su più pagine, dovrebbe esser chiaro in ogni momento quanti passaggi sono necessari e a quale punto della procedura ci si trova.

Spesso i form sono articolati su più pagine senza anticiparlo all’utente con strumenti che consentano di anticiparsi quanti passaggi saranno necessari. Un esempio positivo di chiara segnalazione dei passaggi della procedura viene da blogger.com:

Un esempio di indicazione dei passaggi successivi in Blogger

Si faccia attenzione a rendere cliccabili i punti precedenti della procedura solo se è previsto che l’utente possa tornarci. Spesso i punti successivi non sono cliccabili perché l’utente ci può arrivare solo dopo aver effettivamente inserito i dati.

I form complessi dovrebbero essere raggruppati in aree tematiche affini, in modo da diminuirne la complessità, attraverso spazi, allineamenti, o eventualmente cornici o sfondi.

Il marcatore fieldset può essere usato per raggruppare fra loro gruppi di campi che sono tematicamente affini all’interno di in un’unica pagina. Ad esempio, si possono raggruppare tematicamente i campi per richieste anagrafiche, separandoli, in marcatura e visivamente, dai campi sulla professione. In questo modo si danno degli agganci visivi all’utente che rendono la pagina più affrontabile, un po’ come quando si separano i paragrafi di testo, con pause interne che aiutano inoltre a rafforzare la coerenza semantica dei diversi gruppi. Questa linea guida vale sia come espediente di organizzazione visiva che di rafforzamento semantico.

Dovrebbero essere chieste per prime informazioni semplici, che l’utente possa fornire senza sforzo.

Mi è capitato durante le mie analisi di incontrare moduli di finanziamento che richiedono prima il codice fiscale (o altri dati astrusi) del nome dell’utente. Questo è ostacolante: può darsi che l’utente non abbia sottomano il codice fiscale, mentre è improbabile che non si ricordi il suo nome. Poi offre una cattiva immagine, come se l’azienda considerasse gli utenti dei numeri e dei codici, anziché delle persone. Okay, anche se è così, non è detto che la cosa migliore sia esplicitarlo…

In generale, le prime informazioni dovrebbero essere semplici per incoraggiare l’utente. Una volta iniziato a compilare, è meno probabile che un utente abbandoni. Se invece vi è un ostacolo fin dall’inizio, è più probabile un abbandono.

Percepibilità

E’ preferibile utilizzare sfondi bianchi o neutri

Questo aumenta di solito la leggibilità dei form, come in qualunque altra pagina: ecco un esempio di linea guida generale che è bene applicare specificatamente anche ai form

E’ preferibile usare un colore di primo piano con forte contrasto, preferibilmente nero.

Ovviamente fa il paio con la precedente linea guida. Spesso per attutire il contrasto si usano testi grigi nella presunzione che siano più eleganti, ma sono anche estremamente meno leggibili, soprattutto per chi ha il minimo problema di vista.

I testi hanno una dimensione sufficiente per garantire la migliore leggibilità

Come per tutti i testi, dovrebbe essere scelta una soglia di leggibilità minima sufficiente a farsi leggere senza problemi da tutti (10-12 pixel). Il problema è forse meno urgente a causa del recente metodo di ingrandimento delle pagine usato dai nuovi browser (ingrandiscono l’intera pagina e non solo il testo). Non abbiamo però alcun dato su quanti utenti conoscano e usino, alla bisogna, la funzione di ingrandimento dei browser stessi.

Ridurre al minimo il rumore visivo del form

Ad esempio eliminando o riducendo colori, bordi, sfumature inutili o ridondanti: bastano già etichette e campi a creare affollamento visivo. Riducete al minimo tutto il resto.

Il modulo qui sopra è ordinato, ma i bordi e gli sfondi appesantiscono visivamente il modulo.

Già solo eliminando le bodature nere, senza altri interventi, l’impatto visivo ne viene migliorato. Naturalmente questo è solo un primo passo di una necessaria ristrutturazione del form, ma dimostra quanto alcuni dettagli visivi possano essere importanti.

Organizzazione spaziale

Le etichette verbali dovrebbero essere alllineate coerentemente fra loro e rispetto ai campi

Sull’allineamento delle etichette esiste uno studio di Matteo Penzo che trova come la soluzione più efficiente sia l’allineamento sopra il campo; o, se deve essere un allineamento a lato, è preferibile l’allineamento a destra (come nella seconda immagine di questo articolo), in modo da mantenere così una distanza costante fra le label e i campi. In ogni caso questo allineamento deve essere coerente in tutto il form.

La ricerca riguarda il tempo di lettura ed è stata condotta con l’eye-tracking in una pagina priva di design: i risultati, per ammissione dello stesso autore dovrebbero essere ulteriormente verificati in casi più complessi e reali. Ma è certamente utile capire che minore è la distanza fra label e inizio del campo, migliore è la percezione da parte dell’utente.

I campi dovrebbero essere di larghezza uguale, od omogenea, per quanto è possibile.

Uno degli aspetti visivamente meno gradevoli dei form sono i campi di lunghezza differente, caoticamente disallineati uno sull’altro. E’ preferibile scegliere da due a 4 dimensioni standard per i campi (a seconda del tipo di dato) e utilizzarli coerentemente, in modo da avere campi allineati ordinatamente per quanto possibile. L’esempio di blogger in cima all’articolo offre un’idea di quel che si intende.

Appropriatezza semantica dei comandi, delle funzioni e utilizzo delle convenzioni/affordance

Accertarsi di utilizzare check box, select e radio button in maniera appropriata al tipo di domanda.

Bisogna rispettare il significato di ogni widget, di ogni oggetto di selezione di un form. In particolare, è bene distinguere quando usare i radio button (pulsanti di opzione) o i checkbox (caselle di spunta: non sono la stessa cosa. I radio button servono a selezionare opzioni esclusive. E in quel caso è bene fornire anche un metodo per deselezionare l’opzione nel caso di campo opzionale (si/no/nessuna selezione, per esempio), perché altrimenti dopo una selezione accidentale non è più possibile deselezionare l’opzione

I checkbox sono invece utili nel caso di più risposte valide contemporaneamente, e non hanno bisogno di opzioni di deselezione perché si possono deselezionare ricliccandoci sopra.

Il select, nella variante a tendina o a box, può sostituire tutte e due queste opzioni, a seconda dell’uso o meno dell’attributo multiple. Tuttavia va valutato bene quando usare il select e quando radiobutton o checkbox, perché il select tende ad essere più difficile da manovrare e ad occultare le voci. E dunque è necessaria un’ulteriore linea guida…

Evitare l’elenco a tendina per un numero di opzioni inferiore a 4-5

…L’uso delle tendine (elemento select) è consigliato quando ci sono più di 4-5 opzioni, e l’uso dei radio button (cui il select nella versione base è sostanzialmente equivalente) rischia di occupare troppo spazio. Usare il select per 4/5 voci soltanto è invece inappropriato perché rischia di occultare le opzioni (a meno di non usare il select box). La tendina è inoltre più complicata da usare per gli utenti inesperti.

Quando è molto importante (ad esempio per il profumo dell’informazione, per dare suggerimenti sui contenuti) far vedere le singole opzioni, può essere preferibile usare radiobutton o checkbox anche per più di 5 opzioni.

I campi obbligatori devono essere identificati in maniera chiara e univoca

E’ sorprendente, ma dopo anni di web esistono ancora molti form professionali di servizi finanziari, che dimenticano di indicare fin da subito quali campi sono obbligatori e quali non lo sono. L’indicazione deve essere esplicita per ogni campo, a meno che tutti siano obbligatori od opzionali, nel qual caso va indicato in cima al form.

I campi obbligatori dovrebbero essere evidenziati usando non soltanto il colore (ad esempio con un asterisco o con un la dicitura “richiesto”)

L’uso del solo colore porta ad ovvi problemi di accessibilità.

Punti di azione

E’ chiaro dalla home page qual è il link, il tasto o il punto di partenza del form

Uno degli aspetti meno chiacchierati e discussi di un form è che spesso non è affatto chiaro come si arriva al form. Spesso nella home page di un sito importante, che richiede agli utenti di compilare un form, c‘è un link piccolisssimo o seminascosto che è l’unico modo per andare alla pagina del form. Se il vostro form è importante, rendete più evidente il punto di partenza del form fin dalla home page. Meglio ancora…

Rendete possibile fin dalla home page l’inserimento dei primi dati nel form

…Iniziate il form in home page, magari con solo due o tre campi. In questo modo è più probabile che l’utente lo noti, e magari inizi a compilarlo.

E’ sempre chiaro in ogni fase del flusso d’azione quale è il prossimo oggetto che attiva l’azione?

Spesso i messaggi testuali invitano l’utente a compiere un’azione (proseguire, riprovare), ma nell’interfaccia non è chiaro come l’utente dovrebbe compiere questa azione. Magari perché non è presente un bottone! Nell’esempio sotto, mancano completamente bottoni o altri inviti all’azione per trasformare la prenotazione in acquisto.

Come trasformare la prenotazione in acquisto? Cliccando su un link che non sembra un link!

In realtà l’utente deve cliccare sul link con il codice alfanumerico, per andare ad una pagina dalla quale fare un acquisto. Totalmente incomprensibile. Ho personalmente osservato utenti arenarsi a questo punto di una procedura d’acquisto.