Ho aggior­nato WordPress alla ver­sione 2.3 essen­domi fatto ingo­lo­sire dal sup­porto per i tags.

Dopo l’installazione è pos­si­bile con­ver­tire le cate­go­rie usate in pre­ce­denza in tags equi­va­lenti. Il pro­cesso fun­ziona, anche se lascia indie­tro la cate­go­ria di root, ma è ina­de­guato a livello fun­zio­nale. Mentre posso sce­gliere dalle cate­go­rie esi­stenti, con i tags devo affi­darmi alla memo­ria. Mi sem­bra incre­di­bile che nes­suno si sia accorto di que­ste carenze. O mi sfugge qualcosa?

Trovo discu­ti­bile anche il fatto che venga lasciata la cate­go­ria di root, senza pos­si­bi­lità di eli­mi­narla. Capisco che ci sia qual­cuno che vuole usare i tags e le cate­go­rie ma esi­ste anche qual­cuno, come me, che vuole usare i tags in alter­na­tiva alle categorie.

La que­stione è da appro­fon­dire. In ogni caso, per qual­che giorno il sito non sarà pro­prio per­fetto, ammesso che lo sia mai stato… ;-)

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.

Bell’articolo – come spesso suc­cede con A List Apart – sull’importanza del con­te­nuto di un sito web. È bello per­ché ci ricorda che il web è nato per pro­durre con­te­nuto: solido, con­creto, utile; non è una bro­chure elet­tro­nica. Per com­ple­tare il ritorno ai fon­da­men­tali, con­si­glio anche:

• Web Design is 95% Typography (1)
• Web Design is 95% Typography (2)

Ecco un altro uso pra­tico della colo­ra­zione del testo ai fini di comu­ni­care una qual­che misu­ra­zione. In que­sto caso si tratta di Wikipedia e la colo­ra­zione del testo misura il suo grado di affi­da­bi­lità, o meglio, il grado di vola­ti­lità, dato che l’intensità del colore è cal­co­lata in base al numero di modi­fi­che effettuate.

Altre infor­ma­zioni: UCSC Wiki Lab, con rela­tive pagine di demo.

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.

Confronto fra tre diverse pro­po­ste riguar­danti il rifa­ci­mento dei ter­mi­nali di lavoro per la Bloomberg.

Vengono esa­mi­nati i pro­getti di The Happy Corp, IDEO e Ziba Design.

La pro­po­sta di Happy Corp è quella con a più alto impatto visivo, con alcune idee molto inte­res­santi – la lava lamp!! – anche se ho qual­che dub­bio sull’usabilità; altre, come le news maps, sono già viste. Quella di IDEO è molto più sobria ma anche com­pleta: l’ambiente cir­co­stante sem­bra preso in con­si­de­ra­zione in modo più attento.

Da vedere.

Uno dei modi ormai abba­stanza stan­dard per visua­liz­zare dif­fe­renze quan­ti­ta­tive è quello ispi­rato alle tag clouds: usare le dimen­sioni del testo per comu­ni­care le varia­zioni in fre­quenza – nel caso delle tag clouds vere e pro­prie – o di qual­siasi altra misurazione.

Mentre navi­gavo qua e là mi sono imbat­tuto nel drat della GLPv3: que­sta pagina usa l’intensità del colore per visua­liz­zare l’“intensità” delle modi­fi­che per un certo blocco di testo.

Sembra una buona idea per anche wiki, diff del codice…

In que­sto bell’articolo ven­gono con­fron­tati i design dei siti di CNN e USA Today, con par­ti­co­lare rife­ri­mento all’importanza della de–enfasi e della omo­ge­neità degli ele­menti strutturali.

Questa de–enfasi viene chia­mata, piut­to­sto effi­ca­ce­mente, “strut­tura silen­ziosa”. Lo scopo è quello di valo­riz­zare il con­te­nuto, senza che per que­sto il sito venga per­ce­pito come amorfo, destrutturato.

Gli ele­menti ana­liz­zati sono:

• Intestazione
• Disposizione dei con­tri­buti foto­gra­fici e testuali
• Consistenza della gri­glia d’impaginazione
• L’effetto dato dalla com­bi­na­zione di tutti que­sti elementi