Home » Articoli » L’usabilità dei form
6/04/2009
[di Maurizio Boscarol]
I form1 sono elementi interattivi della pagina web molto importanti per tutti i siti che, oltre a presentare informazioni, hanno bisogno che l’utente fornisca informazioni e interagisca con il sito. Sia rispondendo a questionari, inviando una richiesta, acquistando qualcosa o registrandosi ad un servizio. Sono il fondamento di qualsiasi applicazione web, dove attraverso i form gli utenti modificano impostazioni, gestiscono dati in inserimento, in visualizzazione e in modifica.
Esistono form semplici e complessi, basati solo sull’HTML oppure modificati con javascript, per utenti smaliziati o novizi. Stabilire linee guida rigide per i form valide e sufficienti per tutti i casi per la mia esperienza è quasi impossibile. Può essere di aiuto distinguere diversi aspetti sui quali i form possono essere valutati, secondo linee guida o principi che vanno prima di tutto interpretati e capiti, piuttosto che applicati rigidamente: nel compiere qualunque analisi bisogna infatti capire se una certa regola può portare benefici alla specifica applicazione oppure no.
Propongo qui, partendo dalla mia personale esperienza di analisi, oltre che dalla letteratura di settore, una serie di aree di valutazione distinte, che possono non essere sempre applicabili a tutti i form, ma che possono aiutare a costruire un proprio insieme modulare di linee guida, adattato al proprio sito e alla propria situazione. In seguito integrerò queste analisi con link e spunti di approfondimento ad altri siti. Le aree di analisi che per convenienza distinguo sono nove:
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é.
Ogni campo dovrebbe avere un’etichetta verbale che spieghi il dato che l’utente deve inserire o selezionare, in maniera chiara e non ambigua.
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:
Il modulo di iscrizione a Blogger è un esempio di come una colonna intera del modulo viene riservata ad un testo esplicativo.
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.
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 è 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.
Non dovrebbero essere cioè presentati solo con un alertbox, che non ha alcun riferimento al contesto della pagina2. In ogni caso, a beneficio di tutti, gli errori devono essere segnalati in prossimità del campo interessato.
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.
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.
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.
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:
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.
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:
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.
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.
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.
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
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.
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.
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.
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.
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.
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…
…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.
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.
L’uso del solo colore porta ad ovvi problemi di accessibilità.
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…
…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.
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.
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.
1 Uso il genere maschile per il termine “form”, seguendo le indicazioni secondo le quali si dovrebbe assegnare il genere della corrispondente parola italiana per le parole straniere che vengono introdotte. Trovo più appropriata la traduzione di form con “modulo”, che con altre alternative come “mascherina” o “scheda”, che sono comunque sinonimi accettabili. Come sottolinea l’Accademia della crusca, anche l’uso di “la form”, al femminile, può essere corretto, e dunque non ne faccio una questione decisiva: spiego solo la ragione per cui adotto la forma maschile. ^
2 Alcuni utenti ciechi mi hanno segnalato durante alcuni test di gradire l’alertbox come mezzo di segnalazione di errori in linea, direttamente sul singolo campo durante la compilazione. Perché se l’errore viene segnalato solo nella pagina successiva, essi devono riposizionarsi sul campo dell’errore, e farlo sequenzialmente in una pagina complessa è più difficile che per coloro che ci vedono. La segnalazione degli errori dovrebbe dunque essere migliorata, probabilmente, anche per ragioni di accessibilità, offrendo segnalazioni multimodali e, in una pagina di riepilogo, inserendo anche forse dei link interni in cima alla pagina per segnalare il punto dell’errore. Tuttavia, queste soluzioni andrebbero studiate e validate, e vanno prese per ora solo come spunto di approfondimento. ^
Circa una mail al mese (ma spesso meno) con gli aggiornamenti più significativi.
Precedente:
« L’usabilità delle tag cloud
Successivo:
Progettare l'informazione: intervista con Andrea Resmini »