L’usabilità preventiva nel web

Cosa intendo con usabilità preventiva nel web? Intendo la capacità, per un sito o servizio, di anticipare e guidare l’utente allo scopo di limitare lo sforzo richiesto per raggiungere i propri obiettivi.

Il visitatore, si sa, ha poco tempo da perdere, o almeno ci piace crederlo. Allora perché non agevolare la sua navigazione filtrando quello che potrebbe interessargli rispetto all’intero contenuto del sito?

Le strade per implementare questo tipo di soluzione sono diverse. La strada più percorsa, quella classica, è di chiedere esplicitamente al visitatore qualche informazione preventiva, come la nazione o la lingua, così da fornire subito quello che è più adatto alle sue esigenze. E’ il caso di un sito di e-commerce che calcola le spese di spedizione o di un sito multilingua che presenta le “bandiere” nazionali da qualche parte nella pagina.

Un’altra strada, usata soprattutto da siti che prevedono l’iscrizione del visitatore, è quella di permettere la personalizzazione, anche spinta, degli elementi dell’interfaccia grafica. Quello che fa, tanto per capirci, l’homepage personalizzata di Google.

C’è una terza possibilità. Il server web di cose sul navigatore ne sa infatti parecchie, dalla risoluzione del monitor al numero di colori, dalla nazione di provenienza alla lingua usata. Di solito queste informazioni sono usate, a posteriori, a fini statistici. E’ quello che si fa per esempio con Google Analytics. Nessuno vieta di usare alcune di queste informazioni nel corso della navigazione dell’utente, così da agevolare alcune operazioni. Anche di questo parla l’interessante presentazione di Stephen Anderson di cui ho parlato qualche mese fa, in cui l’autore immagina un form che presenti precompilata la nazione di provenienza basandosi sull’indirizzo di IP (con possibilità, ci mancherebbe, di modificare il dato).

Questo terzo approccio, se ben impiegato, senza per forza voler strafare, potrebbe ridurre l’attività svolta “inutilmente” del visitatore.

Vediamo come con un’esperienza – negativa – vissuta in prima persona.

Incuriosito dal rilascio da parte della BBC dell’iPlayer, un software che permette il download dei programmi dell’emittente britannica trasmessi nell’ultima settimana, l’ho voluto provare. Ecco la cronistoria delle faticose operazioni che ho compiuto un mese fa. Oggi le cose sono diverse, proprio perché la stessa BBC ha impiegato qualche semplice tecnica di usabilità preventiva.

In coda

Ho richiesto un invito per partecipare al programma e ho atteso pazientemente. E’ passata circa una settimana e ho ricevuto nella mia casella un accredito, cioè un login e una password

Login con sorpresa

Dal sito iPlayer ho cercato il login e mi è apparsa la relativa schermata.

image

Si tratta di una finestra modale. Un peccato, perché mi ha impedito di accedere a Gmail dove erano salvati login e password, che ho allora dovuto copiare e incollare da un documento di testo.

Selezione del programma

A questo punto mi è apparsa la pagina principale dedicata ai programmi, in perfetto stile web 2.0.

image

Da qui ho navigato verso un qualcosa che mi interessava, in particolare un documentario sulle montagna.

Download

Ho cliccato sulla scheda del programma e mi si è presentata la possibilità di procedere con il download, come del resto mi sarei aspettato.

image

Problema 1: il browser

image

Ma non avrei dovuto usare Firefox, perché il sito è per il momento rivolto solo a utenti Internet Explorer. Anche se avessi usato il Mac non avrei avuto fortuna migliore. Ho allora ripetuto tutta la procura e mi sono autenticato con Internet Explorer.

Problema 2: la versione di Windows Media Player

Questo problema è quasi divertente. Anche se il computer sembra soddisfare tutti i requisiti presenti in questa pagina, c’è ancora qualcosa che non va.

image

Si tratta in realtà – è bastato poco per scoprirlo – della versione di Windows Media Player, che va quindi aggiornato. Scarichiamo il player, installiamo e ricominciamo da capo. Login, ricerca, selezione, ecc.

Download e installazione di iPlayer

image

A questo punto mi è stato chiesto di procedere con il download di iPlayer, che è un programma Windows a tutti gli effetti. L’ho scaricato, installato e sono poi ritornato per l’ennesima volta sulla scheda del programma e ho – finalmente – potuto richiederne la visione. Ricevendo questa pagina in risposta:

image

In poche parole: non posso usare il servizio perché mi sto connettendo da fuori della Gran Bretagna. Non posso fare nulla, il servizio è disponibile solo a chi vive lì. Fine, stop, punto.

La colpa, diciamolo francamente, è mia. Se avessi letto con attenzione le pagina fitta fitta di requisiti avrei trovato il riferimento a questo limite fondamentale e avrei risparmiato mezz’ora di tentativi.

Qualcosa in più l’avrebbe potuta però fare anche lo stesso sito della BBC. E oggi è infatti così: non riuscirete più ad ottenere una login e una password per accedere alle schermate che ho riportato qui sopra, perché ancora prima della richiesta di un accredito per la versione beta troverete ad attendervi il messaggio che vi avvisa del requisito principale, ovvero di essere residenti in Gran Bretagna.

L’esempio di iPlayer è sicuramente al limite, in quanto l’IP è usato addirittura per impedire l’accesso a una sezione (limite che con un po’ di impegno è comunque possibile aggirare).

Eppure in casi più semplici, come la precompilazione di alcuni dati nelle maschere di inserimento, i dati lasciati dal browser dell’utente potrebbe essere usati, una volta tanto, per risparmiargli un po’ di tempo piuttosto che per spiarne il comportamento.

Quando il cliente va di fretta

L’errore più comune commesso da chi progetta interfacce e interazioni per il web è credere che, trovata una soluzione, questa sia applicabile in ogni contesto.

Illuminante in questo senso l’esempio riportato da Luke Wroblewski nel proprio blog.

Immaginate di trovarvi in aeroporto e di avere 10 minuti di tempo per collegarvi a un provider wireless per leggere la posta.

Ecco, in questo caso l’interfaccia deve davvero mirare al sodo e limitare gli errori introdotti dal cliente, tanto che perfino la procedura di registrazione potrebbe essere superflua o, perlomeno, evitare il continuo caricamento della pagina a ogni invio.

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.