Mondi su mondi, sistemi di sistemi.

Apple Store: i campi della carta di credito

Thursday, January 7th, 2010

Qualche tempo fa avevo segnalato l’analisi di Luke Wroblesky del checkout dell’Apple Store1.

Uno degli aspetti che venivano elogiati era il nuovo sistema di completamento dei dati della carta di credito. Infatti, non viene più chiesto di indicare quale carta di credito si vuole usare, dato che questa informazione è ricavabile dal numero della carta. Così, il form si limita ad evidenziare quella giusta.

Tutto bene, allora? Beh, quasi, perché poi bisogna fare i conti con le abitudini degli utenti, che, vedendo le icone delle varie carte di credito pos­sono essere indotti a cliccarci sopra, pensando di selezionare quella desiderata. La soluzione proposta su usabilitymatters è quella di renderle attive, in modo da pre­servare le vecchie abitudini 2.

Io considererei altre due pos­sibilità: cambiare le icone in modo che sia più chiaro che non sono attive; oppure, toglierle del tutto e far comparire l’icona solo quando il sistema ne ha dedotto il tipo.

Analisi del nuovo processo di checkout dell’Apple Store

Wednesday, December 16th, 2009

Luke Wroblesky analizza nel dettaglio come è cambiato il form per l’acquisto sull’AppleStore 1.

Molto bella l’eliminazione delle pagine multiple, adottando un accordion che contrae la sezione appena conclusa ed espande la succes­siva; anche l’eliminazione della pletora di pulsanti è una cosa di cui si sentiva l’esigenza; più discutibili alcune scelte come la visualizzazione delle etichette dentro i campi o l’uso di un giallo tenue per indicare gli errori.

Le etichette a scomparsa, in particolare, sono molto allettanti per il grande risparmio di spazio ma hanno evidenti carenze di usabilità. Basta immaginare form completamente compilato: non c’è più nes­suna etichetta!

Semplificare i form con i widgets

Sunday, February 24th, 2008

In questo articolo viene pre­sentato un sistema per semplificare, o forse sarebbe meglio dire compattare, un form complesso.

L’idea di fondo è quella di ridurre le diverse sezioni del form in widget espandibili e contraibili a piacere per ridurre al minimo lo spazio occupato.

A mio parere si sorvola troppo sui difetti di una soluzione del genere che sono due: le opzioni disponibili non sono tutte immediatamente visibili e il numero di click neces­sari per selezionare un’opzione. So benis­simo che è proprio lo scopo dell’articolo quello di mostrare un modo per ridurre l’affollamento dello schermo ma non dobbiamo dimenticare che ogni soluzione ha i suoi pro e contro.

Nel complesso rimane comunque un approccio piuttosto efficace, calcolando il fatto che le etichette rias­suntive pre­sentate quando l’elemento è contratto pos­sono fornire informazioni sulla selezione attiva in quel momento.

Che ne pensate? Avete usato soluzioni del genere? In particolare per applicazioni web che pre­vedono inserimenti dati massicci?

Sito del giorno (o dell’anno?): Bureau of Communication

Monday, December 31st, 2007

Ecco un sito da vedere e studiare e (perché no?) farsi anche una risata. Credo che il pros­simo lo visiterò più di una volta, per gioco e per lavoro ;-) Screen shot del sito Bureau of Communication

Piccole innovazioni nel design dei form

Monday, November 26th, 2007

L’aver aggiornato la mia pagina sui form mi ha fatto venire in mente che avevo alcuni articoli arretrati sull’argomento; ad es. questo di Khoi Vinh dove si dimostra che è pos­sibile dire qualcosa di nuovo e/o di gradevole anche nel design dei form.

Accessibilità nei form con l’elemento label

Wednesday, November 21st, 2007

Bell’articolo di 456 Berea Street sull’uso di label nei form.

In generale mi era già tutto noto, tranne alcuni dettagli:

  • è pos­sibile associare più di una label ad ogni elemento di un form;
  • IE6 rende cliccabili solo le label associate esplicitamente ad un elemento.

Analisi del linguaggio visuale di Amazon

Wednesday, November 7th, 2007

Garrett Dimon analizza i pulsanti usati da Amazon e porta alla luce il linguaggio visuale sottostante. Consigliato.

Form Design

Tuesday, August 14th, 2007

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.