Risparmiare sui messaggi di errore

L’intervento di Jared Spool su User Interface Engineering sottolinea, se ancora ce ne fosse bisogno, la necessità di progettare form che siano (realmente) usabili.

E’ frequente trovarsi di fronte a form, come quello riportato da Spool, in cui sia possibile evidenziare non uno, ma diversi errori di design.

Form con la scritta: !The ZIP that you entered doesn’t match the City/State you entered. Please verify the information.

Quello che mi ha colpito dell’intervento è stato però il titolo, “Being cheap with error messages”, cioè risparmiare sui messaggi di errore.

Sì, perché quello che molto spesso succede è che già dalla fase di wireframing, di creazione delle bozze, la gestione degli errori nell’interfaccia non venga considerata, perché “tanto al cliente non interessa vedere cosa succede quando l’utente sbaglia o c’è qualche problema”.

Questo atteggiamento prosegue nelle altre fasi di progetto, fino ad arrivare in produzione dove, a meno di trovare qualche programmatore con buone competenze sull’usabilità delle interfacce (e ce ne sono, per fortuna), alla gestione degli errori viene riservato l’ultimo quarto d’ora prima dei test.

Per quella che è la mia esperienza, solo se fin dalle prime bozze è stato previsto di gestire con qualità gli errori, c’è qualche probabilità che questa situazione venga mantenuta fino alla messa online del sito. Proprio meglio non risparmiare in questo caso.

L’importanza del campo “azienda”

Di maschere per inserimento dati, o form, parlo sempre in abbondanza. Ne parlo perché è un argomento di cui va capita l’importanza, ne parlo anche perché sono un utente/cliente di numerosi siti di e-commerce, aziende di promozione turistica, editori.

Ogni form ha esigenze diverse dagli altri, ma se lo scopo è quello di inviare al visitatore del materiale acquistato, ma anche una semplice brochure, cercate di prevedere sempre un campo “azienda”.

Spesso visito siti che non prevedono la possibilità di specificare un riferimento aziendale. So che se inserissi semplicemente il mio nome e l’indirizzo dell’azienda il postino o il corriere non riuscirebbero mai a trovarmi. La soluzione per il visitatore è allora quella di sporcare il campo cognome con qualcosa del tipo “Cognome c/o Azienda”, ma così facendo viene compromesso il patrimonio di informazioni che lascia.

Certo, memorizzare il campo azienda è il primo passo, ma se questa informazione non è poi passata a chi si preoccupa della consegna, si è comunque fatta poca strada. E’ quello che succede per esempio con La Fonera: ho visto il corriere percorrere l’intero stabile in cerca del mio collega che l’ha ordinata perché nel documento di viaggio non compariva in alcun modo l’azienda per cui lavora.

Buone pratiche per progettare i form

Segnalo tre ottime risorse che si propongono di aiutare nella progettazione di maschere di inserimento dati (form). Operazione solo a prima vista facile e spesso sottovalutata, ma piena di insidie e trabocchetti.

La prima, e sicuramente la migliore, è la presentazione di Luke Wroblewki, designer di Yahoo!, dal titolo Best Practices for Form Design, che è possibile scaricare in formato Pdf. Una presentazione piena zeppa di suggerimenti e consigli su come presentare e raggruppare i campi di un form. Ne segnalo solo alcuni:

  • posizionare le etichette di campi in alto è utile per ridurre il tempo di completamento, ma richiede ovviamente più spazio verticale; allinearle a destra del campo lega con evidenza il campo e l’etichetta, ma può ridurre la leggibilità; allinearle a destra facilita la lettura delle etichette, ma ne riduce l’associazione con il campo
  • vale la pena indicare i campi obbligatori solo se sono in minima parte, altrimenti meglio indicare quelli opzionali
  • la lunghezza del campo fornisce preziose informazioni sulla compilazione
  • è bene cercare di raggruppare campi che sono in qualche modo correlati, per velocizzare la compilazione del form
  • le azioni primarie (salva, continua, invia) devono essere chiaramente separate ed evidenziate rispetto alle azioni secondarie (cancella, indietro, reset)
  • meglio usare poche indicazioni su come compilare il form, da porre vicino ai campi che richiedono attenzione

Molti, molti altri consigli nella presentazione.

Un’alta interessante documento è la guida realizzata dal ministero del commercio norvegese: Simplified Forms for the Public Sector, progetto Elmer. Si tratta di una serie di linee guida rivolte principalmente al settore pubblico, suddivise in categorie e sezioni. Alcuni suggerimenti sono forse fin troppo specifici ed esagerati, ma darci un occhio matura sicuramente delle buone ideee per il futuro.

Vale la pena anche dare un’occhiata alla presentazione di Aaron Gustafson dal titolo Learning to Love Forms, decisamente più tecnica e che va diretta al codice Html. Anche qui interessanti suggerimenti, come quello di usare le liste al posto di “div” o paragrafi per ospitare i campi del form e qualche esempio su come utilizzare tag normalmente dimenticati, come legend e fieldset. Sono 100 slide con estratti di codice che vale davvero la pena di provare.