Volevo segna­lare que­sto bell’arti­colo sulla legge di Fitt, che descrive il tempo di acqui­si­zione di un ber­sa­glio, ad es. il tempo per clic­care su un link o un pulsante.

Dall’alto della mia grande espe­rienza in fatto di design delle GUI pen­savo fosse una sem­plice regola empi­rica, invece è una for­mula mate­ma­tica vera e pro­pria. Imbarazzante…

Negli ultimi giorni ho visto diverse recen­sioni su Kindle, l’e–book di Amazon ma pra­ti­ca­mente non ne ho letta nem­meno una, tranne que­sta. Leggetela, non vi por­terà via molto tempo ;-)

Inutile dire che sono d’accordo al 100%.

L’aver aggior­nato la mia pagina sui form mi ha fatto venire in mente che avevo alcuni arti­coli arre­trati sull’argomento; ad es. que­sto di Khoi Vinh dove si dimo­stra che è pos­si­bile dire qual­cosa di nuovo e/o di gra­de­vole anche nel design dei form.

Questo arti­colo elenca una serie di con­si­gli basati sui risul­tati degli study di eye–tracking alcuni dei quali mi suo­nano piut­to­sto inaspettati.

1. il testo attira l’attenzione più velo­ce­mente della grafica;
2. la for­mat­ta­zione fan­ta­siosa tende ad essere ignorata;
3. le dimen­sioni del testo influen­zano il modo di leggere;
4. le parti infe­riori della pagina ven­gono guardate;
5. gli utenti pas­sano molto tempo a guar­dare gli ele­menti dell’interfaccia gra­fica, come pul­santi e menu (que­sta me la devono pro­prio spiegare…).

Bell’arti­colo di 456 Berea Street sull’uso di label nei form.

In gene­rale mi era già tutto noto, tranne alcuni dettagli:

• è pos­si­bile asso­ciare più di una label ad ogni ele­mento di un form;
• IE6 rende clic­ca­bili solo le label asso­ciate espli­ci­ta­mente ad un elemento.

Studio sui tempi e l’accuratezza nel com­ple­ta­mento dei form in rela­zione al posi­zio­na­mento dei pulsanti.

A livello molto gene­rale le con­clu­sioni sem­brano ovvie, tut­ta­via, ci sono un paio di aspetti da non sot­to­va­lu­tare: prima di tutto si tratta di dati spe­ri­men­tali e non solo di qual­che ipo­tesi “span­no­me­trica”, in secondo luogo viene evi­den­ziato come i tempi di com­ple­ta­mento del form non siano in linea con la valu­ta­zione degli utenti.

Anche se il form con pul­santi gra­fi­ca­mente iden­tici per le azioni pri­ma­rie e secon­da­rie è stato quello con i tempi di com­ple­ta­mento più bassi, gli utenti hanno apprez­zato mag­gior­mente altri form dove i due pul­santi erano visi­va­mente distin­gui­bili. L’ipotesi dell’articolo è che si sia più pre­oc­cu­pati di per­dere i dati fin lì inse­riti che di com­pi­lare velocemente.

Ho un unico dub­bio sulla nume­ro­sità del cam­pione: 23 sog­getti mi sem­brano un po’ pochi.

Ho rac­colto in que­sta pagina un breve rias­sunto di alcuni arti­coli di Caroline Jarrett sul design dei forms. Spero possa essere utile.

Sto anche pen­sando di rag­grup­pare molti dei post su argo­menti simili sotto una nuova cate­go­ria – qual­cosa tipo infor­ma­tion design – più gene­rale ma anche più pre­cisa dei vari ia, usa­bi­lity, ui e ux. Non che que­ste cate­go­rie non abbiano valore ma la mag­gior parte delle volte mi sem­brano fuori fuoco rispetto all’argomento; infor­ma­tion design mi sem­bra otti­male, no?

Designing usa­ble forms #

Ogni form è com­po­sto da tre livelli: per­cet­tivo (lay­out), col­lo­quiale (domande e rispo­ste) e rela­zio­nale (la strut­tura del com­pito). A un livello più meta­fo­rico pos­siamo con­si­de­rare un form come una tazza di caffé, dove la tazza è il livello per­cet­tivo, il caffé è il livello col­lo­quiale e l’acqua quello relazionale.

Alcune domande da porsi per miglio­rare l’usabilità di un form:

• livello rela­zio­nale:
  • per­ché stai facendo que­ste domande?
  • È que­sta la domanda adatta a que­sto punto?
  • Puoi otte­nere l’informazione richie­sta in qual­che altro modo?
  • Stai chie­dendo all’utente di fare qual­cosa che invece dovre­sti fare tu?
• Livello col­lo­quiale:
  • disponi le domande nell’ordine corretto;
  • rifletti sulla pro­ve­nienza delle risposte;
  • rag­gruppa gli argo­menti in base alle risposte;
  • for­ni­sci le rispo­ste chiuse, se pos­si­bile, ma lascia spa­zio per even­tuali rispo­ste per­so­na­liz­zate, se adeguato;
  • cali­bra lo spa­zio dedi­cato alla rispo­sta in base alla sua lun­ghezza prevista.
• Livello per­cet­tivo:
  • usa inte­sta­zioni e colori per rag­grup­pare le aree del form in argomenti;
  • non aspet­tarti che gli utenti leg­gano le istru­zioni, tuttavia;
  • fai in modo che le istru­zioni siano il più sin­te­ti­che possibile.

Quali ele­menti sce­gliere in un form? #

Ci sono quat­tro ele­menti disponibili:

1. drop–down;
2. pul­santi radio;
3. check box;
4. campi di testo.

non cal­co­liamo i link, i button e i submit.

1. Qual’è lo scopo principale?

Il form è inse­rito in una pagina di navi­ga­zione o di rac­colta dati? Se la pagina è di navi­ga­zione i drop–down sareb­bero da evi­tare per­ché non visua­lizza imme­dia­ta­mente tutte le opzioni ed è più labo­rioso di link. Tuttavia que­sto è il caso più banale dato che di solito i form ser­vono a rac­co­gliere infor­ma­zioni, no?

2. Sei domande

1. È più natu­rale, per l’utente, l’inserimento libero che la selezione?
2. È facile sba­gliare risposta?
3. È neces­sa­rio rileg­gere le opzioni per capire la domanda?
4. Quante opzioni ci sono?
5. È pos­si­bile sce­gliere più di un’opzione?
6. Le opzioni sono visi­va­mente distinguibili?

Le domanda sono abba­stanza banali, gli unici appunti da fare riguar­dano la rilet­tura delle opzioni e la distin­gui­bi­lità visiva. Il primo punto scon­si­glia di usare un drop-down e con­si­glia pul­santi radio o chec­k­box. Il secondo ci ricorda di fare atten­zione a ren­dere distin­gui­bili, per quanto pos­si­bile, le varie rispo­ste: meglio scri­vere “uno” e ”dieci” piut­to­sto che “01” e “10”.

3. L’impatto del form

Una volta ristretta la rosa di ele­menti per ogni campo, con­si­de­rato sin­go­lar­mente, biso­gna allar­gare l’analisi ai vari ele­menti nel loro insieme, all’interno del form. E quindi:

• evi­tare troppi ele­menti eterogenei;
• le opzioni siano poche e concise;
• curare l’ordine delle opzioni.

Evitate i form a due colonne #

• Tendono a con­fon­dere (qual’è l’ordine giusto?);
• sono poco accessibili.

Forse non era neces­sa­rio costruirci sopra un articolo…

Due punti o no?#

Non conta; l’importante è essere costanti nella scelta. Io tendo a usarli…

Usare i tab? #

Il con­si­glio è: un form per pagina o al mas­simo un topic per pagina se il form è molto lungo. In que­sto caso, infatti, l’utente può arri­vare ad un punto in cui non sa più esat­ta­mente a che punto si trova. Non tra­scu­riamo però l’uso del form: se viene usato molto, dalle stesse per­sone, que­sto pro­blema tende a pas­sare in secondo piano.

Web Form Design in the Wild Parte 1, parte 2

Questa serie di due arti­coli rac­co­glie alcuni con­si­gli rica­vati dall’analisi di alcuni form di siti “reali”, usati tutti i giorni: hotel, biglietti aerei e così via. Ovviamente rimando alla let­tura degli arti­coli per rica­vare il con­te­sto neces­sa­rio a met­tere nella giu­sta pro­spet­tiva i con­si­gli ripor­tati qui sotto.

1. Non nascon­dere i form che devono essere com­pi­lati. Nell’esempio descritto il link che sem­brava por­tare al form, in realtà con­du­ceva l’utente alla home page, lascian­do­gli poi il com­pito di tro­varlo da solo.
2. Sii espli­cito nell’esporre il motivo per cui richiedi la com­pi­la­zione di un form. Il titolo del form dava l’impressione che l’utente dovesse essere già registrato.
3. Usa i defaults, Luke! Soprattutto quando sono dati che sono già disponibili.
4. Non trat­tare i clienti come dei sem­plici record in un data­base. Questo è un punto dif­fi­cile da rispet­tare per­ché non è solo una que­stion tec­nica ma coin­volge anche le sfu­ma­ture legate alle parole usate e anche – per­ché no – all’aspetto visuale.
5. Accertati che i mes­saggi impor­tanti abbiano un’adeguata prio­rità visiva.
6. Fai in modo che sia facile rime­diare agli errori.
7. Fai atten­zione ai dati inse­riti che con­servi. Da inten­dersi in rela­zione ai default, non a pos­si­bili impli­ca­zioni legali.
8. Spiega la ragione per richie­dere dei dati appa­ren­te­mente inu­tili. L’esempio ripor­tato è quello di un form per acce­dere al wifi di un aero­porto; una situa­zione in cui c’è spesso poco tempo e poca dispo­ni­bi­lità a per­dersi nella burocrazia.
9. Prendi in con­si­de­ra­zione una vali­da­zione inline per gli inse­ri­menti che si pos­sono facil­mente sba­gliare. Non è bello dover sot­to­met­tere un form cin­que volte per tro­vare uno user­name non ancora usato. Attenzione alle pre­sta­zioni, però. La vali­da­zione via Ajax può stres­sare il backend.
10. Distingui visi­va­mente gli errori.
11. Rimuovi tutti gli inse­ri­menti non necessari.
12. Rendi rico­no­sci­bile il per­corso di com­ple­ta­mento di un form.
13. Rimuovi le azioni secon­da­rie ogni volta che puoi.

Label pla­ce­ment in forms #

Gli studi di eye-tracking sug­ge­ri­scono alcune linee guida per il dise­gno di un form:

• le eti­chette posi­zio­nate al di sopra del campo sono di solito quelle più effi­cienti, anche se richiedo qual­che atten­zione alla giu­sta distanza fra i vari campi;
• se le eti­chette sono messe accanto al campo, il testo andrebbe alli­neato a destra;
• le eti­chette in gras­setto ten­dono ad essere più dif­fi­cili da leg­gere ma dipende anche dallo stile gene­rale del form;
• le liste sareb­bero da usare con par­si­mo­nia visto che ten­dono ad atti­rare molto l’attenzione;
• non usare un’etichetta sepa­rata per le liste, usa il default al suo posto.

Per un esem­pio di ridi­se­gno di un form seguendo, in parte, que­ste indi­ca­zioni vedi “Better Web Forms: Redesigning eBay’s Registration”.

Campi con lun­ghezza limi­tata #

Dobbiamo distin­guere fra due situa­zioni: quella con testo molto breve, dove usiamo un input e quella con testo lungo abba­stanza da non potersi ragio­ne­vol­mente aspet­tare che l’utente possa tenere il conto, dove usiamo una textarea.

Input

Nel primo caso è di solito suf­fi­ciente spe­ci­fi­care la lun­ghezza mas­sima nell’html ed even­tual­mente aggiun­gere del testo espli­ca­tivo a lato.

Textarea

Nel secondo caso la que­stione è più arti­co­lata. Se siamo for­tu­nati, il campo del data­base che con­terrà il testo inse­rito non ha limiti pre­im­po­stati e pos­siamo lasciare l’utente libero di inse­rire quanto testo vuole. È un’opzione da tenere sem­pre in con­si­de­ra­zione dato che è abba­stanza ragio­ne­vole pen­sare che non ver­ranno mai inse­rite delle moli di testo vera­mente grandi.

Se invece abbiamo un testo lungo ma limi­tato, ad es. i clas­sici 256 carat­teri, l’approccio con­si­gliato dall’articolo è di lasciare pure che l’utente superi il limite mas­simo quando sta scri­vendo, in modo che possa riar­ran­giare il testo per ripor­tarlo alla lun­ghezza mas­sima con­sen­tita. Un mes­sag­gio vicino al campo lo infor­merà della situazione.

Stavo guar­dando que­sto sito, tirato fuori dal solito mazzo di link che sono “asso­lu­ta­men­te­da­ve­dere” e, oltre ad ever tro­vato qual­che dise­gno inte­res­sante, mi sem­bra dove­roso segna­lare come è stata risolta la pro­ble­ma­tica della pagi­na­zione. Ecco uno screen­shot:

Mi piace per diversi motivi: scala benis­simo anche con tante pagine; l’effetto di “pros­si­mità” delle altre pagine, rispetto a quella visua­liz­zata in quel momento, ha effetti posi­tivi anche sulla faciltà di navi­ga­zione dato che per andare avanti e indie­tro non biso­gna fare molta strada con il mouse, men­tre soli­ta­mente i link di avanti/indietro sono agli estremi.

In que­sto arti­colo su A List Apart si ana­lizza l’inefficaci dell’uso degli avvisi – Sei sicuro di…? – per evi­tare che l’utente ese­gua delle azioni non volute. In sostanza il pro­blema si riduce al fatto che non esi­ste un sistema ragio­ne­vol­mente sicuro per impe­dire azioni inde­si­de­rate: ci sarà sem­pre il giorno storto in cui daremo quell’OK asso­lu­ta­mente catastrofico.

La solu­zione pro­po­sta è reim­po­stare la que­stione intorno all’uso degli undo, faceno spa­rire tutti i pro­blemi legati agli avvisi. È ovvia­mente un con­si­glio sen­sato ma mi sem­bra che sor­voli su alcuni dettagli.

I due sce­nari che mi ven­gono in mente sono:

• azioni intrin­se­ca­mente non annullabili;
• undo mul­ti­pli.

Come esem­pio banale del primo caso pos­siamo pen­sare al riav­vio della mac­china o all’invio di un’email senza sog­getto; in que­sti casi il van­tag­gio dell’uso esteso dell’undo è che rimar­rebbe solo un insieme piut­to­sto cir­co­scritto di casi in cui gli avvisi sono indi­spen­sa­bili, pre­ser­van­done l’efficacia.

Il secondo caso è più com­pli­cato ed è qui che si dovrebbe vedere qual­che solu­zione di design intel­li­gente: con­sen­tire all’utente di annul­lare la terza ope­ra­zione delle cin­que che ha fatto nell’ultima ora, può richie­dere qual­che sforzo pro­get­tuale in più rispetto al but­tare tutti i file nel cestino e lasciare all’utente il com­pito di ritro­vare quel pre­ciso file.