Alcuni con­si­gli sulla pro­get­ta­zione dei form.

Layout dei form

Quando il form dev’essere com­pi­lato velo­ce­mente e con dati che sono fami­liari all’utente, la dispo­si­zione più adatta è quella con eti­chette ver­ti­cali.
Vantaggi: pro­ces­sa­mento rapido; legame visivo fra eti­chette e campi. Svantaggi: incre­mento dello spa­zio ver­ti­cale.
Le eti­chette andreb­bero evi­den­ziate con l’uso del grassetto.

Se i dati da com­pi­lare non sono fami­liari, l’uso di eti­chette alli­neate a sini­stra rende più sem­plice capire cosa viene richie­sto: l’utente può con­cen­trarsi sulle eti­chette senza essere inter­rotto dai campi.
Vantaggi: facile scan­sione delle eti­chette; spa­zio ver­ti­cale ridotto. Svantaggi: il legame visivo fra l’etichetta e il campo viene indebolito.

Un’alternativa è quella di alli­neare a destra le eti­chette.
Vantaggi: legame visivo fra eti­chetta e campo; spa­zio ver­ti­cale ridotto. Svantaggi: minore leg­gi­bi­lità delle etichette.

Uso di ele­menti visuali

I van­taggi del lay­out alli­neato a sini­stra può indurre ad aggiun­gere aiuti visivi per com­pen­sarne i difetti, ad esem­pio, tra­mite colori di sfondo e gri­glie. Tuttavia, l’aggiunta di ele­menti tende a distrarre l’occhio e non pro­duce il risul­tato desiderato.

Azioni pri­ma­rie e secondarie

Ogni form ha (o dovrebbe avere) un’azione prin­ci­pale, come “Submit”, “Save”, “Invia” ecc. ed even­tual­mente altre azioni di impor­tanza minore. In que­sti casi l’azione prin­ci­pale deve avere un peso visivo mag­giore rispetto a tutte le altre.

Bell’aned­doto sulle aspet­ta­tive di spesa di un pro­getto web, che può avere vali­dità generale.

Penso sia capi­tato a tutti quelli che lavo­rano nello svi­luppo di incon­trare un cliente, intel­li­gente, pre­pa­rato, ecc. che, al momento di sta­bi­lire il bud­get da desti­nare al pro­getto pensa a cifre ridi­col­mente basse.

Attenzione! non lo fa per “tirare sul prezzo” – non solo, almeno – ma pro­prio per­ché non ha un’idea delle com­ples­sità che si nascon­dono nello svi­luppo di un pro­getto soft­ware, sia esso un “sem­plice” sito o un qual­che tipo di applicazione.

Il luogo comune che, nell’IT, esi­sta sem­pre una ver­sione che “è pra­ti­ca­mente uguale” ma che costa però pochis­simo, che io chiamo la “logica del clone”, rende spesso dif­fi­cile far capire la ragione di certi pre­ven­tivi; per non par­lare del fatto di tutti que­gli ambienti di lavoro dove si è speso di più in piante e archi­tetto che per il bac­kup dei dati.

Spesso le infor­ma­zioni neces­sa­rie per for­nire un aiuto con­creto alla com­pi­la­zione dei form sono troppo lun­ghe, com­pro­met­tendo l’usabilità dei form. In que­sto caso pos­siamo gene­rare in modo dina­mico l’aiuto for­nito, in modo che sia visi­bile solo quando occorre. Ci sono diverse possibilità.

Esposizione in–line

L’aiuto viene mostrato quando il focus di un ele­mento del form è atti­vato e/o quando il focus è all’interno di un gruppo di ele­menti.
Il difetto prin­ci­pale di que­sto metodo è che l’utente non sa della pre­senza dell’aiuto fino a quando il focus non viene attivato.

Aiuti in–line atti­va­bili dall’utente

Prendo spesso la forma di icone piaz­zate in posi­zione adatta, vicino agli ele­menti del form, che mostrano un aiuto solo se ven­gono atti­vati espli­ci­ta­mente dall’utente.
La quan­tità di testo non dovrebbe essere tale da scon­vol­gere il lay­out del form; in alter­na­tiva si pos­sono usare dei rol­lo­ver, che hanno però il difetto di poter essere fasti­diosi visto che si atti­vano ogni volta che il mouse ci passa sopra.

Sezioni di aiuto atti­va­bili dall’utente

Alcuni mostrano l’aiuto in posi­zioni rego­lari e non accanto i sin­goli ele­menti del form, alle­viando i pro­blemi di lay­out senza sacri­fi­care troppo la pos­si­bi­lità di for­nire infor­ma­zioni dettagliate.

Articolo ori­gi­nale

Sapevo dell’esistenza dell’elemento button ma, dall’alto della mia appro­fon­dita cono­scenza degli stan­dard, pen­savo fosse uti­liz­za­bile solo attra­verso JavaScript, ma mi sba­gliavo: button offre le stesse fun­zio­na­lità dell’input, aggiun­gen­doci ulte­riori opzioni per il rendering.

In que­sto arti­colo ven­gono mostrate alcune delle pos­si­bi­lità, anche se non c’è di niente di ine­dito per chi abbia un po’ di cono­scenza dei css.

Era ora! Finalmente un libro che si occupa solo del design dei form. Ho sem­pre tro­vato abba­stanza irri­tante la scarsa atten­zione a que­sto argo­mento nei vari libri in ambito web/css/javascript, anche se ne com­prendo benis­simo le ragioni: è una rogna e nes­suna giu­dica un sito dalla qua­lità dei form; eppure sono un ele­mento cruciale.

Adesso attendo un libro ana­logo per il design delle tabelle per i dati ;-)

fonte

Articolo che mostra alcuni dei pos­si­bili limiti delle folk­so­no­mies. I difetti sono reali ma ritengo che ne venga esa­ge­rata la por­tata e anzi con­ti­nuo a pen­sare che la – rela­tiva – man­canza di pre­ci­sione delle folk­so­no­mies sia un pre­gio e non un difetto.

Lou Rosenfeld spiega per­ché a suo parere la parola “rede­sign” andrebbe ban­dita. Due punti mi sem­brano importanti:

1. “[…] a web site is more envi­ron­ment than tool”. Nel con­te­sto dell’articolo que­sta frase ha una con­no­ta­zione nega­tiva, dato che viene espressa per far pas­sare l’idea – sulla quale sono d’accordo – che la parola “rede­sign” ha un sapore troppo legato alo svi­luppo soft­ware. Tuttavia, que­sta carat­te­ri­stica dei siti web è da tenere pre­sente anche se si svi­luppa una qual­che appli­ca­zione via bro­w­ser: la meta­fora del sito è più potente di quella dell’applicazione.
2. “The only thing pre­dic­ta­ble here is entropy. Why not ack­no­w­ledge this and focus on con­ti­nual tweaks and adjust­ments that respond to chan­ging con­di­tions, rather than see­king the unat­tai­na­ble para­dise of per­fec­tion?”. Se mi aves­sero detto che era una frase estratta da, diciamo, Extreme Programming Explained ci avrei cre­duto. Il post di Rosenfeld può fare il paio anche con la serie (in corso) di Chad Fowler, The Big Rewrite.

Secondo Peter Morville, la User Experience (UX) può clas­si­fi­cata attra­verso que­ste carat­te­ri­sti­che:

• Utile. Quanto lavoro mi evita?
• Utilizzabile. Quanto è facile da usare?
• Desiderabile. Quant’è impor­tante dal punto di vista emozionale/simbolico?
• (Ri)Trovabile. Quanto ci impiego ad “arri­vare al dunque”?
• Accessibile. Quanto tiene conto delle disabilità?
• Credibile. Quanto mi posso fidare del prodotto?
• Importante. Quanto mi fa gua­da­gnare? Quanto mi fa risparmiare?

Mi sem­bra un sistema utile a modu­la­riz­zare lo svi­luppo, valu­tando le diverse parti di un sistema attra­verso que­sta gri­glia, anche attra­verso una loro quan­ti­fi­ca­zione. In que­sto modo pos­siamo sta­bi­lire non solo le prio­rità all’interno delle richie­ste da svi­lup­pare, ma anche avere un cri­te­rio per deci­dere le future direzioni.

Simon Willison esa­mina alcuni svan­taggi nell’usare più URL per una stessa risorsa, ad es. http://developer.yahoo.com/python/ e http://developer.yahoo.com/python/index.html, oppure del.icio.us/giorgio_v e del.icio.us/giorgio_v/.

I pro­blemi che que­ste URL pos­sono gene­rare sono:

• Le cache diven­tano meno efficaci
• L’aggregazione dei link è meno efficace

Altri link utili:

• mod_rewrite coo­k­book
• http://no-www.org/

Le tag clouds si stanno evol­vendo e comin­ciano ad essere usate per scopi diversi dalla sem­plice visua­liz­za­zione del “peso” dei diversi tag.

Gene Smith fa notare come stiano forse diven­tando un com­po­nente dell’interfaccia più gene­rico, uti­liz­za­bile in tutte quelle situa­zione in cui c’è biso­gno di mostrare l’importanza rela­tiva fra una serie di ele­menti, siano essi tag, con­cetti espressi in un discorso o l’attinenza rispetto ad un qual­che cri­te­rio di classificazione.