Dal sempre ottimo 456 Berea Street, un articolo che spiega come usare CSS+JavaScript per usare lo spazio disponibile nei campi di testo per inserire il testo che andrebbe nelle etichette, quando queste ultime non pos­sono essere usate; tipicamente per problemi di spazio.

L’idea è quella di rendere le label invisibili spostandole con i CSS e inserire il testo nei campi con uno script, cancellandolo quando il focus è attivo.

Studio sui tempi e l’accuratezza nel completamento dei form in relazione al posizionamento dei pulsanti.

A livello molto generale le conclusioni sembrano ovvie, tuttavia, ci sono un paio di aspetti da non sottovalutare: prima di tutto si tratta di dati sperimentali e non solo di qualche ipotesi “spannometrica”, in secondo luogo viene evidenziato come i tempi di completamento del form non siano in linea con la valutazione degli utenti.

Anche se il form con pulsanti graficamente identici per le azioni primarie e secondarie è stato quello con i tempi di completamento più bassi, gli utenti hanno apprezzato maggiormente altri form dove i due pulsanti erano visivamente distinguibili. L’ipotesi dell’articolo è che si sia più pre­occupati di perdere i dati fin lì inseriti che di compilare velocemente.

Ho un unico dubbio sulla numerosità del campione: 23 soggetti mi sembrano un po’ pochi.

In questo post alcuni dettagli interes­santi sugli ostacoli durante lo sviluppo di questo componente, in particolare per Safari.

Ho raccolto in questa pagina un breve rias­sunto di alcuni articoli di Caroline Jarrett sul design dei forms. Spero possa essere utile.

Sto anche pensando di raggruppare molti dei post su argomenti simili sotto una nuova categoria – qualcosa tipo information design – più generale ma anche più pre­cisa dei vari ia, usability, ui e ux. Non che queste categorie non abbiano valore ma la maggior parte delle volte mi sembrano fuori fuoco rispetto all’argomento; information design mi sembra ottimale, no?

Designing usable forms #

Ogni form è composto da tre livelli: percettivo (lay­out), colloquiale (domande e risposte) e relazionale (la struttura del compito). A un livello più metaforico pos­siamo considerare un form come una tazza di caffé, dove la tazza è il livello percettivo, il caffé è il livello colloquiale e l’acqua quello relazionale.

Alcune domande da porsi per migliorare l’usabilità di un form:

• livello relazionale:
  • perché stai facendo queste domande?
  • È questa la domanda adatta a questo punto?
  • Puoi ottenere l’informazione richiesta in qualche altro modo?
  • Stai chiedendo all’utente di fare qualcosa che invece dovresti fare tu?
• Livello colloquiale:
  • disponi le domande nell’ordine corretto;
  • rifletti sulla provenienza delle risposte;
  • raggruppa gli argomenti in base alle risposte;
  • fornisci le risposte chiuse, se pos­sibile, ma lascia spazio per eventuali risposte personalizzate, se adeguato;
  • calibra lo spazio dedicato alla risposta in base alla sua lunghezza prevista.
• Livello percettivo:
  • usa intestazioni e colori per raggruppare le aree del form in argomenti;
  • non aspettarti che gli utenti leggano le istruzioni, tuttavia;
  • fai in modo che le istruzioni siano il più sintetiche possibile.

Quali elementi scegliere in un form? #

Ci sono quattro elementi disponibili:

1. drop–down;
2. pulsanti radio;
3. check box;
4. campi di testo.

non calcoliamo i link, i button e i submit.

1. Qual’è lo scopo principale?

Il form è inserito in una pagina di navigazione o di raccolta dati? Se la pagina è di navigazione i drop–down sarebbero da evitare perché non visualizza immediatamente tutte le opzioni ed è più laborioso di link. Tuttavia questo è il caso più banale dato che di solito i form servono a raccogliere informazioni, no?

2. Sei domande

1. È più naturale, per l’utente, l’inserimento libero che la selezione?
2. È facile sbagliare risposta?
3. È neces­sario rileggere le opzioni per capire la domanda?
4. Quante opzioni ci sono?
5. È pos­sibile scegliere più di un’opzione?
6. Le opzioni sono visivamente distinguibili?

Le domanda sono abbastanza banali, gli unici appunti da fare riguardano la rilettura delle opzioni e la distinguibilità visiva. Il primo punto sconsiglia di usare un drop-down e consiglia pulsanti radio o checkbox. Il secondo ci ricorda di fare attenzione a rendere distinguibili, per quanto pos­sibile, le varie risposte: meglio scrivere “uno” e ”dieci” piuttosto che “01” e “10”.

3. L’impatto del form

Una volta ristretta la rosa di elementi per ogni campo, considerato singolarmente, bisogna allargare l’analisi ai vari elementi nel loro insieme, all’interno del form. E quindi:

• evitare troppi elementi eterogenei;
• le opzioni siano poche e concise;
• curare l’ordine delle opzioni.

Evitate i form a due colonne #

• Tendono a confondere (qual’è l’ordine giusto?);
• sono poco accessibili.

Forse non era neces­sario costruirci sopra un articolo…

Due punti o no?#

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

Usare i tab? #

Il consiglio è: un form per pagina o al mas­simo un topic per pagina se il form è molto lungo. In questo caso, infatti, l’utente può arrivare ad un punto in cui non sa più esattamente a che punto si trova. Non trascuriamo però l’uso del form: se viene usato molto, dalle stesse persone, questo problema tende a pas­sare in secondo piano.

Web Form Design in the Wild Parte 1, parte 2

Questa serie di due articoli raccoglie alcuni consigli ricavati dall’analisi di alcuni form di siti “reali”, usati tutti i giorni: hotel, biglietti aerei e così via. Ovviamente rimando alla lettura degli articoli per ricavare il contesto neces­sario a mettere nella giusta prospettiva i consigli riportati qui sotto.

1. Non nascondere i form che devono essere compilati. Nell’esempio descritto il link che sembrava portare al form, in realtà conduceva l’utente alla home page, lasciandogli poi il compito di trovarlo da solo.
2. Sii esplicito nell’esporre il motivo per cui richiedi la compilazione 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 trattare i clienti come dei semplici record in un database. Questo è un punto difficile da rispettare perché non è solo una question tecnica ma coinvolge anche le sfumature legate alle parole usate e anche – perché no – all’aspetto visuale.
5. Accertati che i mes­saggi importanti abbiano un’adeguata priorità visiva.
6. Fai in modo che sia facile rimediare agli errori.
7. Fai attenzione ai dati inseriti che conservi. Da intendersi in relazione ai default, non a pos­sibili implicazioni legali.
8. Spiega la ragione per richiedere dei dati apparentemente inutili. L’esempio riportato è quello di un form per accedere al wifi di un aeroporto; una situazione in cui c’è spesso poco tempo e poca disponibilità a perdersi nella burocrazia.
9. Prendi in considerazione una validazione inline per gli inserimenti che si pos­sono facilmente sbagliare. Non è bello dover sottomettere un form cinque volte per trovare uno username non ancora usato. Attenzione alle pre­stazioni, però. La validazione via Ajax può stres­sare il backend.
10. Distingui visivamente gli errori.
11. Rimuovi tutti gli inserimenti non necessari.
12. Rendi riconoscibile il percorso di completamento di un form.
13. Rimuovi le azioni secondarie ogni volta che puoi.

Label placement in forms #

Gli studi di eye-tracking suggeriscono alcune linee guida per il disegno di un form:

• le etichette posizionate al di sopra del campo sono di solito quelle più efficienti, anche se richiedo qualche attenzione alla giusta distanza fra i vari campi;
• se le etichette sono messe accanto al campo, il testo andrebbe allineato a destra;
• le etichette in gras­setto tendono ad essere più difficili da leggere ma dipende anche dallo stile generale del form;
• le liste sarebbero da usare con parsimonia visto che tendono ad attirare molto l’attenzione;
• non usare un’etichetta separata per le liste, usa il default al suo posto.

Per un esempio di ridisegno di un form seguendo, in parte, queste indicazioni vedi “Better Web Forms: Redesigning eBay’s Registration”.

Campi con lunghezza limitata #

Dobbiamo distinguere fra due situazioni: quella con testo molto breve, dove usiamo un input e quella con testo lungo abbastanza da non potersi ragionevolmente aspettare che l’utente possa tenere il conto, dove usiamo una textarea.

Input

Nel primo caso è di solito sufficiente specificare la lunghezza mas­sima nell’html ed eventualmente aggiungere del testo esplicativo a lato.

Textarea

Nel secondo caso la questione è più articolata. Se siamo fortunati, il campo del database che conterrà il testo inserito non ha limiti pre­impostati e pos­siamo lasciare l’utente libero di inserire quanto testo vuole. È un’opzione da tenere sempre in considerazione dato che è abbastanza ragionevole pensare che non verranno mai inserite delle moli di testo veramente grandi.

Se invece abbiamo un testo lungo ma limitato, ad es. i clas­sici 256 caratteri, l’approccio consigliato dall’articolo è di lasciare pure che l’utente superi il limite mas­simo quando sta scrivendo, in modo che possa riarrangiare il testo per riportarlo alla lunghezza mas­sima consentita. Un mes­saggio vicino al campo lo informerà della situazione.

È stata rilasciata la versione 2.3 di YUI, i componenti AJAX di Yahoo!.

La novità sicuramente più importante è il rilascio di un componente per l’editing del testo che funziona su tutti i browser principali – Safari compreso. Ci sono stati anche ritocchi ai CSS; sarei curioso di fare un confronto con Blueprint, per capire le differenze di approccio a questo aspetto.

Stavo guardando questo sito, tirato fuori dal solito mazzo di link che sono “assolutamentedavedere” e, oltre ad ever trovato qualche disegno interes­sante, mi sembra doveroso segnalare come è stata risolta la problematica della paginazione. Ecco uno screenshot:

Mi piace per diversi motivi: scala benis­simo anche con tante pagine; l’effetto di “pros­simità” delle altre pagine, rispetto a quella visualizzata in quel momento, ha effetti positivi anche sulla faciltà di navigazione dato che per andare avanti e indietro non bisogna fare molta strada con il mouse, mentre solitamente i link di avanti/indietro sono agli estremi.

In questo articolo su A List Apart si analizza l’inefficaci dell’uso degli avvisi – Sei sicuro di…? – per evitare che l’utente esegua delle azioni non volute. In sostanza il problema si riduce al fatto che non esiste un sistema ragionevolmente sicuro per impedire azioni indesiderate: ci sarà sempre il giorno storto in cui daremo quell’OK assolutamente catastrofico.

La soluzione proposta è reimpostare la questione intorno all’uso degli undo, faceno sparire tutti i problemi legati agli avvisi. È ovviamente un consiglio sensato ma mi sembra che sorvoli su alcuni dettagli.

I due scenari che mi vengono in mente sono:

• azioni intrinsecamente non annullabili;
• undo multipli.

Come esempio banale del primo caso pos­siamo pensare al riavvio della macchina o all’invio di un’email senza soggetto; in questi casi il vantaggio dell’uso esteso dell’undo è che rimarrebbe solo un insieme piuttosto circoscritto di casi in cui gli avvisi sono indispensabili, pre­servandone l’efficacia.

Il secondo caso è più complicato ed è qui che si dovrebbe vedere qualche soluzione di design intelligente: consentire all’utente di annullare la terza operazione delle cinque che ha fatto nell’ultima ora, può richiedere qualche sforzo progettuale in più rispetto al buttare tutti i file nel cestino e lasciare all’utente il compito di ritrovare quel pre­ciso file.

Confronto fra tre diverse proposte riguardanti il rifacimento dei terminali di lavoro per la Bloomberg.

Vengono esaminati i progetti di The Happy Corp, IDEO e Ziba Design.

La proposta di Happy Corp è quella con a più alto impatto visivo, con alcune idee molto interes­santi – la lava lamp!! – anche se ho qualche dubbio sull’usabilità; altre, come le news maps, sono già viste. Quella di IDEO è molto più sobria ma anche completa: l’ambiente circostante sembra preso in considerazione in modo più attento.

Da vedere.

Uno dei modi ormai abbastanza standard per visualizzare differenze quantitative è quello ispirato alle tag clouds: usare le dimensioni del testo per comunicare le variazioni in frequenza – nel caso delle tag clouds vere e proprie – o di qualsiasi altra misurazione.

Mentre navigavo qua e là mi sono imbattuto nel drat della GLPv3: questa pagina usa l’intensità del colore per visualizzare l’“intensità” delle modifiche per un certo blocco di testo.

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