Questa è la traduzione dell'articolo Sensible Forms: A Form Usability Checklist di Brian Crescimanno, pubblicato originariamente su A List Apart il 19 dicembre 2005. La traduzione viene qui presentata con il consenso dell'editore (A Lista Apart Magazine) e dell'autore.
I computer dovrebbero rendere la nostra vita più semplice, non più complicata. Come progettisti consapevoli dei problemi di usabilità, possiamo semplificare la vita dei nostri utenti valutando con attenzione il modo in cui le persone interagiscono con i nostri siti, fornendo indicazioni chiare, affidando il compito di definire i dettagli di funzionamento ai computer non agli utenti.
È su quest'ultimo aspetto che ci concentreremo in questo articolo. Abbiamo sentito e letto tante cose sui principali errori in tema di usabilità: "Non usare immagini o Flash per la navigazione", "Non usare Javascript per i link", etc. Spero davvero che tutti noi stiamo mettendo in pratica queste lezioni nel nostro lavoro. Spesso, comunque, sono i piccoli difetti in termini di usabilità a risultare più fastidiosi per gli utenti, specialmente quando si parla di form HTML. Seguite queste linee guida, allora: saranno certamente un buon punto di partenza.
Usare i campi giusti
Con tanti elementi di form tra cui scegliere, ciascuno con i propri vantaggi e svantaggi, può essere difficile decidere quali usare in una determinata situazione. Usiamo sempre in modo appropriato radio button, checkbox e menu select. Per radio button e checkbox, usiamo i tag <fieldset> e <legend> per raggruppare logicamente gli elementi sotto un'intestazione significativa. Raggruppare in questo modo fa sì che il form sia più facile da gestire da parte dell'utente, dal momento che, mentalmente, può essere separato in tante sezioni più piccole.
Jacob Nielsen (http://www.useit.com) fornisce queste linee guida per l'uso dei radio button rispetto ai checkbox:
I radio button sono usati quando c'è una lista di due o più opzioni che sono reciprocamente esclusive e l'utente deve selezionarne soltanto una. In altri termini, cliccare su un radio button non selezionato deselezionerà automaticamente un radio button che sia stato selezionato in precedenza nella lista.
I checkbox sono invece usati con liste in cui l'utente può selezionare qualunque numero di opzioni (nessuna, una o più di una). In altri termini, ogni checkbox è indipendente dagli altri, così, selezionando un checkbox non si deselezionano gli altri.
Un checkbox individuale è usato per un'opzione singola che l'utente può selezionare o deselezionare.
Fonte: "Checkboxes vs. Radio Buttons" (http://www.useit.com/alertbox/20040927.html)."
Per campi in cui viene richiesta una sola scelta e ci sono diverse opzioni possibili, si valuti se non sia meglio usare un menu select per risparmiare spazio prezioso sullo schermo. Se sia meglio usare una serie di radio button o un menu select, dipende sempre dal contesto. Se ci troviamo a dover usare cinque o più radio button, forse è preferibile optare per una select.
Se un campo prevede selezioni multiple, cerchiamo di evitare l'adozione dei cosiddetti box "multi-select". Questo elemento, se va bene confonde l'utente, e nello scenario peggiore rende il form inusabile e inutile per quanti non comprendono subito la sua funzione. Se il numero delle opzioni è talmente grande da trasformarsi in qualcosa di indistinto e poco chiaro quando rappresentate sotto forma di checkbox, cerchiamo di raggruppare alcune delle opzioni o di distribuirle secondo una gerarchia a categorie per renderle più comprensibili.
Lasciare spazio per l'inserimento del testo
È importante come il compiere la giusta scelta relativamente al tipo di campo specificarne la giusta lunghezza. Se il nostro nome è Joe Tod non significa che altri utenti non avranno bisogno di più spazio per inserire il loro di nome. Dunque, offriamo almeno 20 caratteri per i campi 'Nome' e 'Cognome'. Inoltre, facciamo in modo che la lunghezza fisica del campo non risulti inferiore all'area di inserimento possibile del testo. Per le aree di testo, assicuriamoci di offrire all'utente lo spazio sufficiente per scrivere e leggere il testo che inseriranno. Aree molto alte e poco larghe sono difficili da leggere quanto quelle eccessivamente estese in larghezza e troppo corte. I valori esatti da usare dipenderanno dall'uso a cui è destinata la textarea, ma per assicurare la leggibilità possiamo stabilire un minimo di 50 caratteri in larghezza e di 10 righe in altezza.
Abbreviare i form e valutare l'uso dei campi obbligatori
Per rendere i nostri form brevi e coincisi, raccomando una sorta di valutazione in due passi di ciascun elemento. Per iniziare, chiediamoci sempre:
"Questa informazione è davvero importante per noi?"
"Questa informazione è talmente importante da impedire l'accesso all'utente se non la fornisce?"
Uno degli esempi più ovvi di elemento di form che non passa il primo test è quello che riguarda appellativi e formule di saluto. Non offre davvero nessun beneficio raccogliere questi dati: perché allora stiamo chiedendo all'utente di fornirceli? Non facciamo perdere loro tempo prezioso chiedendo di darci informazioni inutili.
Il secondo test ("dobbiamo rendere questo campo obbligatorio?") è un po' più soggettivo. Un esempio è quello del numero di telefono. In molte circostanze sarebbe senz'altro un bene averlo. Ma in genere non è necessario per completare la transazione. In questi casi, facciamo sempre scegliere gli utenti.
Marcare chiaramente i campi obbligatori
Alcuni campi devono essere compilati per completare la transazione. Se vendiamo beni di consumo, avremo ovviamente bisogno di un indirizzo per la consegna. Come avviene per le segnalazioni di errori, forniamo agli utenti chiari segnali visuali relativamente ai campi che sono obbligatori. Molte volte chi progetta un form utilizza il testo in grassetto o in corsivo per identificarli, e ci si aspetta che gli utenti siano in grado di fare la giusta associazione. Ci sono però molte altre opzioni esplicite che si possono usare per attirare l'attenzione sul fatto che certi campi vanno compilati obbligatoriamente. Si può usare un asterisco, si può mettere accanto al campo la dicitura "Campo obbligatorio", oppure possiamo suddividere il modulo in due parti: informazioni obbligatorie e informazioni opzionali. In ogni caso, se usiamo un qualunque tipo di simbolo o di evidenziazione per marcare i campi richiesti, dobbiamo offrire anche una legenda ben visibile che spieghi all'utente il significato del simbolo.
Personalmente consiglio di non usare il colore rosso per identificare i campi obbligatori, perché il rosso in genere segnala un errore o un avviso. Come vedremo più avanti, si dovrebbero offrire segnali visuali molto chiari per indicare gli errori, e dunque scegliamo un colore che non possa essere confuso con quello tradizionale per i messaggi di errore.
Offrire etichette descrittive per tutti i campi
A cosa serve un campo di form se non si sa cosa inserirci? Usiamo il tag <label> per assicurare che ciascun campo sia accessibile per tutti gli utenti. Inoltre, facciamo in modo che le label indichino chiaramente lo scopo del campo, in modo che l'utente non abbia alcun dubbio al riguardo. I nomi dei campi dovrebbero essere chiari e coincisi. Se riteniamo utile dare delle informazioni aggiuntive, XHTML 1.1 fornisce il tag <caption> per aggiungere un testo descrittivo e offrire il giusto livello di accessibilità. I meno avventurosi potranno sempre creare un breve testo informativo usando il tradizionale markup XHTML 1.0 e i CSS.
La formattazione dei dati la fa il computer
Poche cose confondono gli utenti come la richiesta di inserire dati in uno specifico formato. È una richiesta comune per i campi con numeri di telefono. I modi per rappresentarli sono davvero molti:
- (800) 555-1212
- 800-555-1212
- 800.555.1212
- 800 555 1212
Alla fine, il formato che forse ci serve contiene solo numeri:
- 8005551212
Ci sono tre modi per gestire queste situazioni. Con il primo metodo l'utente viene avvisato che è richiesto un formato specifico per un certo campo e viene reindirizzato al form con un messaggio di errore se sbaglia ad applicare queste istruzioni.
Il secondo metodo consiste nello spezzare il campo per il numero di telefono in tre parti. È un sistema che pone all'utente due grossi ostacoli in termini di usabilità. Primo: l'utente potrebbe provare a scrivere i numeri tutti insieme ed essere bloccato per aver inserito l'intero numero di telefono in un campo che può contenere al massimo tre cifre. La soluzione "ingegnosa" potrebbe essere quella di utilizzare Javascript per spostare automaticamente il focus sul campo seguente quando l'utente ha inserito il numero massimo di caratteri in quello precedente. Qualcuno ha mai fatto un errore di inserimento in uno di questi campi e sperimentato il ridicolo nel tentare di far tornare il focus su un campo che Javascript considera completato? Su le mani, prego. Non siate timidi! Ecco, ora vi vedo.
Cerchiamo di essere ragionevoli. Abbiamo tanta paura delle regular expression al punto da non riuscire ad eliminare caratteri estranei da un campo di input? Lasciamo che gli utenti inseriscano il loro numero di telefono nel formato che preferiscono. Basta affidarsi poi ad un piccolo filtro per fare piazza pulita di ciò che non ci serve.
Usare messaggi di errore efficaci
Quando ho iniziato a lavorare su questo articolo, ho discusso dell'argomento con mia madre, una persona di quelle che in genere viene definita come "utente medio". La questione degli errori nella compilazione dei form è stata la prima di cui ha parlato, o meglio, di cui si è lamentata. Quando ha provato ad ordinare un regalo di Natale da un sito web, ha riempito i campi del modulo e poi cliccato sul pulsante 'Ordina'. È stata reindirizzata sul form con il seguente messaggio: "Errore nella Carta di Credito". In grassetto, rosso, nella parte superiore dello schermo. Confusa, ha cercato nel form indicazioni per trovare il punto esatto in cui si era verificato l'errore. Non trovandone, ha cercato nuovamente per trovare il campo di input destinato al numero di carta di credito. Ha verificato solo il numero e la data di validità. Ha persino verificato che il suo nome fosse stato inserito correttamente, ma ogni volta che provava a inviare il form, compariva lo stesso messaggio di errore.
Come si è capito dopo, il problema era che il sistema di gestione della carta di credito era in quel momento inattivo. Niente di quello che lei avrebbe potuto fare sul form avrebbe fatto la differenza. Reindirizzare l'utente sul modulo in situazioni come questa lo fa solo sentire incapace, e credo si sia tutti d'accordo nel dire che insultare gli utenti non è proprio nel nostro interesse.
Ci sono diversi passi che possiamo compiere al fine di gestire meglio gli errori nei form HTML. Primo: possiamo fornire messaggi più chiari e più informativi. Sostituiamo un messaggio criptico come "Errore nella Carta di Credito" con uno che tanga maggiormente conto del contesto attuale:
"Si è verificato un errore nel nostro sistema di gestione delle carte di credito. Non abbiamo effettuato alcun prelievo dalla Sua carta. Per favore, riprovi più tardi o ci contatti direttamente al...."
"Si è verificato un errore nella gestione della sua carta di credito; non siamo stati in grado di verificare il numero, Per favore, controlli il suo nome, il numero di carte e la data di validità. Ricordi che questi dati devono corrispondere esattamente a quelli riportati sulla carta di credito".
Questi messaggi di errore sono completi e informano l'utente su quanto è accaduto. Inoltre, guidano l'utente stesso alla ricerca di possibili soluzioni piuttosto che limitarsi a dirgli cosa è andato storto chiedendo a lui di trovare la soluzione.
Il passo successivo per evitare errori che possono confondere consiste nel fornire segnali visuali nei pressi del punto in cui si è verificato il problema. Non lasciamo che sia l'utente a dover andare a caccia dell'errore. Con l'uso dei CSS possiamo modificare un form in vari modi facendo sì che l'utente possa facilmente identificare gli elementi da correggere. Possiamo utilizzare i CSS anche per nascondere i campi che sono stati compilati correttamente e mostrare solo quelli che presentano problemi. Possiamo farlo per gruppi di campi (come quelli relativi alle informazioni sulla carta di credito) usando il tag <fieldset>.
Non reindirizzare gli utenti su un form modificato
Quante volte abbiamo compilato un form e cliccato il pulsante 'Invia' solo per scoprire di aver tralasciato un campo obbligatorio? Scommetto che è capitato a tutti un sacco di volte. Certo, potrebbe essere il prezzo da pagare per aver guardato il tutto con troppa fretta, ma se faccio un errore non dovrei mai essere reindirizzato su un form modificato.
Quando ho inviato i miei dati, ho controllato il box in cui si dice che sono d'accordo con i termini del servizio. Ho anche inserito la password. E, se ricordo bene, ho deselezionato quei box che ti dicono più o meno "Iscrivi il mio indirizzo email la maggior numero possibile di mailing list". E allora, perché così tante volte mi viene ripresentato un form compilato a metà?
Questo esempio è in realtà una combinazione di pigrizia dello sviluppatore e zelo eccessivo da parte degli uomini del marketing (sebbene il dover reinserire la password possa essere una legittima precauzione di sicurezza). Dico a voi, signori del marketing: ricordate che il marketing ha a che fare con la soddisfazione dei bisogni del cliente. Se è un bisogno del cliente non ricevere le vostre attenzioni, dovreste rispettare tale bisogno invece di scocciare la gente su qualcosa che hanno già detto con chiarezza di non volere. E a voi sviluppatori dico: fate in modo di ripresentare già compilati tutti i campi che l'utente ha correttamente riempito. Non c'è motivo per cui essi dovrebbero ri-accettare i termini di servizio o inserire nuovamente i loro dati per un piccolo errore di battitura.
Ricordate: più controllo gli utenti hanno sulla loro esperienza, più saranno felici di usare il vostro sito.
