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.

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.

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

Una serie di diret­tive dra­co­niane per avere un testo leggibile:

1. Font size: 100%.
2. 10–15 parole per riga. Con un lay­out liquido, con un font-size: 100%, una colonna di testo dovrebbe essere circa il 50%
3. Line height: 1.4
4. Il con­stra­sto sfondo/testo di rife­ri­mento è: #fff/#333

Grande post che demo­li­sce il rede­sign di USA Today. La cosa più inte­res­sante non è tanto la stron­ca­tura in quanto tale, ma il fatto che ven­gono elen­cati in modo chiaro i prin­ci­pali difetti.  Sul web ci sono troppe recen­sioni delle cose posi­tive ma serve anche sapere cosa non fare.

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.

Ieri accen­navo alla pos­si­bi­lità di usare dei cri­teri pro­po­sti per la valu­ta­zione della user Experience anche nell’ambito più spe­ci­fico dello svi­luppo, per asse­gnare le prio­rità alle User Stories.

In quel con­te­sto, infatti, i cri­teri pos­sono essere sud­di­visi in due gruppi: uno aiuta a deci­dere la prio­rità, l’altro aiuta a giu­di­care la qua­lità – anche sem­pli­ce­mente intesa come ade­gua­tezza rispetto alle aspet­ta­tive – dell’implementazione.

Al primo gruppo appartengono:

• Utile
• Desiderabile
• Importante

Al secondo:

• Utilizzabile
• Ritrovabile
• Accessibile
• Credibile/Affidabile

Certo, le carat­te­ri­sti­che del primo gruppo saranno influen­zate dal secondo: una data fea­ture sarà ten­den­zial­mente tanto più utile quanto meglio è stata imple­men­tata. Mi sem­bra comun­que una distin­zione utile.

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.