Realizzare form usabili: un'introduzione

Il titolo di questo articolo dovrebbe essere autoesplicativo: si tratta di una semplice introduzione, una raccolta di "pillole", su un argomento complesso e su cui esistono centinaia di risorse online e non solo.

La questione è in effetti davvero cruciale: i form sono un formidabile strumento di interazione e in certi casi (come nei siti di e-commerce) sono il cuore stesso del sistema. Le applicazioni sono poi svariate: raccolta di informazioni, sondaggi e interviste online, registrazione, login, ricerca e altro ancora. È chiaro che sbagliare la progettazione o realizzazione di un form può compromettere il funzionamento e il successo di un sito. Ciò che va evitato è, in buona sostanza, che un difetto a questo livello porti un utente ad abbandonare il sito o a non usufruire di certi servizi. O, ancora, che il nostro database costruito con grande cura e dispendio di tempo si riempia presto di dati inutili. Penso spesso a quelli che tentano di mandare una newsletter a tyweugfh@euasdyg.tr...

Iniziamo il nostro percorso partendo dall'impostazione generale di un form. Passeremo poi ad analizzare alcune questioni riguardanti i singoli tipi di campo.

Impostazioni generali

Ogni form dovrebbe essere preceduto da un titolo chiaro ed esplicativo che ne spieghi la funzione. Allo stesso tempo è opportuno fornire all'inizio un breve testo di istruzioni e/o spiegazioni: chiarire perché vengono richieste certe informazioni, specificare quali sono i campi obbligatori, per esempio. Un errore da evitare è, infatti, quello di costruire form con richieste di cui l'utente non coglie immediatamente l'utilità in quel contesto.

Internet non è uno strumento che ispira in genere molta fiducia e se l'utente non si fida da subito il pericolo dell'abbandono o della falsificazione è dietro l'angolo. Se si tratta di form di registrazione ricordate di inserire alla fine la richiesta di assenso al trattamento dei dati personali. Per form lunghi può essere utile suddividere il modulo in sezioni precedute da un titolo (dati anagrafici, residenza, dati finanziari, etc).

Per quanto riguarda il layout, molti esperti sottolineano l'importanza della visualizzazione. Il suggerimento è in genere che sia visibile nella sua interezza in una schermata a 800x600.

Splitting?!?

Ecco una parola inglese che trovo di difficile traduzione. Potremmo dire semplicemente
"suddivisione", ma sarebbe meglio parlare di "frantumazione di
un elemento in più parti". A noi, però, interessa qui una
cosa: è utile fare lo splitting? La risposta non può essere univoca
e qui più che mai è fondamentale l'analisi dei comportamenti degli
utenti, al fine, eventualmente, di correggere il sistema. In linea generale
possiamo dire che lo splitting va evitato all'interno di un singolo form. Gli
esempi che vengono subito alla mente sono le richieste dell'indirizzo o della
data di nascita. Sono due cose che i visitatori del nostro sito dovrebbero conoscere!
E che sono anche abituati a scrivere di getto.

Perchè dunque frantumare il campo indirizzo in 3 campi (una per il tipo di via, uno per il nome e uno per il numero civico)? Diverso potrebbe essere il discorso per la data di nascita. Se i dati vanno in un db, è probabile che si sia impostato un formato data ben definito. Giusto "pretendere" il rispetto di quel formato nell'immissione. Ma una cosa è suggerire il formato corretto, un altra costringere l'utente a scegliere giorno, mese e anno da scomodi menu a tendina.

Dove invece lo splitting va fatto è per form lunghi. Qui è fondamentale
suddividere la compilazione in diversi step per non intimidire e creare confusione.
Ove si faccia così è importante evidenziare il punto di ogni singolo
step, perché si sappia da subito quanto dura il processo. In alto mettiamo
dunque un'indicazione tipo "Pagina 1 di 4" e simili.

Campi di testo

I campi di testo sono forse il più semplice dei tipi di input, quello che più si avvicina alle abitudini dell'utente. Non dimentichiamo che i moduli HTML non sono altro che una trasposizione di quelli (a volte odiati!) cartacei.

Per i textfields va valutata con attenzione la lunghezza. Essa va sempre commisurata alla risposta che ci si attende. Un campo troppo lungo o troppo breve potrebbe far pensare: ma ho capito la domanda? Ricordiamo che la lunghezza di un campo di testo si imposta in HTML con l'attributo "size" e che nei CSS si può usare la proprietà "width". Con "maxlenght" si imposta invece il numero massimo di caratteri che è possibile inserire (attenti con questa opzione). Anche qui è opportuno ragionare e pensare magari più a chi usa il form che all'armonia del layout.

Un caso interessante nell'usabilità dei campi di testi è l'uso del tasto Invio. Sappiamo per esperienza che per inviare un modulo è possibile, oltre che cliccare sull'apposito pulsante, premere questo tasto trovandosi all'interno di un input. In form semplici come quelli di ricerca ciò non comporta problemi ed è anzi comodissimo. In form più lunghi il discorso cambia. Se un utente preme, anche per sbaglio, il tasto di invio quando la compilazione non è completa, il risultato sarà l'invalidità del form. Esiste un metodo per disabilitare il tasto Invio. Basta usare l'evento onClick invece del classico onSubmit:

<form name="form1" onSubmit="return false">
<input type="text">
<input type="button" value="Invia" onClick="document.form1.submit()">
</form>

Select

Il select (menu a tendina) è una specie di jolly tra i vari tipi di
input. Può infatti sostituire praticamente tutti gli elementi, ma sempre
al fine di limitare le opzioni tra cui scegliere. Una prima importante questione
è dunque: quando è opportuno l'uso di un select al posto di un
altro elemento? Anche qui, valutare sempre e con attenzione, facendo quando
possibile prevalere il criterio della consistenza. Che significa: non mischiare
tanti tipi di elementi in un singolo form.

I menu a tendina pongono comunque altri seri problemi a livello di accessibilità
e usabilità. Segnaliamo i più importanti:

1. Non usare mai testi troppo lunghi per le opzioni
2. Non costruire liste molto lunghe. Fare lo scrolling e orientarsi tra le
   varie opzioni può risultare frustrante.
3. Quando è possibile filtrare le opzioni con menu dinamici
4. Se non possiamo fare a meno di lunghe liste di opzioni, raggruppiamole logicamente
   con l'elemento <optgroup>: aiuta la leggibilità e consente di
   rintracciare facilmente le informazioni. In ogni caso, elenchiamo le opzioni
   secondo un criterio trasparente per l'utente
5. Nei casi di pochissime opzioni o di risposte tipo si/no valutiamo se non
   sia opportuno usare checkbox e radio button

Select come menu di navigazione

Questi suggerimenti valgono soprattutto nel caso di raccolta di informazioni. Ma un uso frequente del select è anche quello di menu di navigazione. Diciamo la verità: è una grande comodità. In poco, pochissimo spazio, possiamo inserire lunghe sequenze di link. Anche in questo caso, però, i problemi da valutare sono di un certo rilievo. Tutto nasce dall'evento che si usa per attivare il link. Se si opta per il classico onChange state certi che le grane non mancheranno. Chi usa browser alternativi, screen-reader o chi è costretto a usare la tastiera per muoversi tra le pagina, per iniziare, o non può usare il menu, in quanto attivabile solo con il mouse o avrà grossi impedimenti. Un secondo problema, lo dico per esperienza personale, nasce con l'avvento dei mouse con rotellina. Strumento fantastico: scrolling veloce e comodissimo..finchè non ti imbatti in questi maledetti menu di navigazione. Capita che se dai un'occhiata al menu, ma non cambi l'opzione, il focus rimane sul select. Tu vai tranquillo, giri la rotellina e...addio pagina! Ti trovi catapultato senza volerlo in un'altra sezione del sito. La rotellina, infatti, ti consente anche di scorrere tra le opzioni di un select. Ma se si usa onChange, la frittata è fatta. In questi casi, dunque, è opportuno disabilitare onChange e gestire il cambio di pagina con un pulsante Submit messo a fianco
del menu.

Checkbox e Radio Button

Questi minuscoli elementi sono di grande utilità. Quando le opzioni sono poche usateli. In particolare, ricordiamo che i radio buttons si usano per scelte ad esclusione (tipo si/no, vero/falso), mentre i checkbox vanno bene per selezioni multiple. In questo caso sono sempre da preferire ai cosiddetti multi-select.

Sui radio buttons va fatta una piccola osservazione. È vero che si usano per scelte esclusive, ma è giusto pensare anche agli utenti che possano o vogliano rispondere "nè si nè no". Una volta scelta un'opzione, un radio button non può più essere deselezionato. Per evitare crisi esistenziali, aggiungiamo oltre a SI e NO, una terza opzione (Altro, Non applicabile, etc).

Risorse

Visto il carattere di introduzione dell'articolo non siamo scesi nei dettagli relativamente a questioni fondamentali. Pensiamo, ad esempio, alla validazione dei form. Procedimento utile, a volte necessario, ma fonte di frustrazioni per molti utenti. Penso con terrore al mio ultimo acquisto su un sito americano: per sette volte ho dovuto inserire il mio numero di telefono perché non azzeccavo il formato giusto. Se, come e dove (client o server) fare la validazione è un argomento da valutare e approfondire.

Un altro caso è quello dei form per utenze internazionali. L'articolo
che vi suggerisco è al riguardo illuminante e ricco di indicazioni anche
curiose:

Usable Forms (for an international audience)

Un campo importante è anche quello dell'accessibilità. Due segnalazioni:

1. How to Create
   Accessible Forms: guida all'uso dei tag <label> e <fieldset>
   per costruire form più accessibili
2. Dive into accessibility:
   visitate il sito e scaricate la versione PDF. È una delle cose più
   belle e ben fatte che ho letto sull'argomento. L'accessibilità resa...accessibile.

Un ottimo libro sull'argomento: Usable forms for the web, di Andy Beaumont, Jon Stephens, Jon James, Chris Ullman, Glasshaus, 2002