leggi e principi

Progettazione: il principio di percepibilità e visibilità

Uno dei più importanti principi di progettazione centrata sull’utente è quello della percepibilità, molto simile al principio di visibilità di Norman1.

Unendo diverse definizioni potremmo dire che secondo questo principio ogni informazione e ogni comando necessario per l’utilizzo del prodotto dovrebbe essere sempre chiaramente percepibile, senza informazioni estranee o ridondanti.

Non è, come può sembrare, solo un problema grafico. Per soddisfare il principio bisogna infatti compiere due tipi di atttività:

  1. essere sicuri di quale siano il comando o l’informazione necessari
  2. renderli propriamente percepibili.

La prima attività richiede un’accurata analisi, la seconda competenze grafiche e visuali.

Cosa deve essere visibile

Il primo punto richiede di definire qual è l’informazione o il comando necessario. Per farlo dovremmo capire come l’utente intende muoversi e come capisce l’oggetto/sito. Ad esempio:

  • In una pagina di articolo deve essere presente anche un elenco di articoli correlati? Oppure l’elenco di tutti gli articoli? O altri tipi di menu?
  • In una galleria di immagini e di prodotti, quali sono gli strumenti che l’utente si aspetta di trovare per navigare fra le immagini o i prodotti? Una serie di frecce avanti/indietro? Un elenco completo di tutti i prodotti o le immagini disponibili? E in questo caso, in forma di miniatura o in forma di elenco di link?

Decidere quale informazione o quale comando sono necessari per l’utilizzo del prodotto dipende da una buona conoscenza degli utenti e da una chiara definizione dei task e degli scenari. Ecco perché progettare per la percepibilità richiede alcune attività di analisi preliminare, indispensabili per ridurre la distanza fra il modello mentale del progettista e quello degli utenti.

Le tecniche utili per affrontare queste fase sono:

  • Analisi dei requisiti
  • Interviste con utilizzatori
  • Analisi dei compiti
  • Scenari
  • Uso delle convenzioni
  • Test con utenti

Quel che c’è si vede?

Una volta compiuta la scelta più difficile, quella di stabilire quali informazioni e quali strumenti è utile inserire in un certo contesto, supposta una loro utilità per l’utente, rimane da rendere questi strumenti o queste informazioni percepibili. Il che significa:

  1. Che possibilmente lo strumento o l’informazione non dovrebbe essere del tipo “a comparsa”, cioè disponibile solo quando l’utente compie una certa azione (come nel caso di un menu a tendina); e in quel caso, comunque, il comando che attiva la presentazione dell’opzione dovrebbe essere sufficientemente visibile (non un punto a caso dello schermo come capita con alcuni videogiochi, che hanno ovviamente altre logiche di interazione). Quando l’informazione diventa attiva, comunque, deve rispettare il punto 2.
  2. Che lo strumento o l’informazione abbiano dimensione e grado di contrasto percettivo sufficienti a essere percepite dagli utenti target.

Approfondiamo entrambi questi punti.

Comandi e informazioni a “comparsa”

In generale le informazioni importanti dovrebbero sempre disponibili fin da subito, perché altrimenti l’utente potrebbe non capire che ci sono e come fare ad attivarle.

Tuttavia non sempre è possibile o utile presentare tutto ciò che potrebbe essere usato dall’utente, perché lo spazio disponibile nell’interfaccia è limitato. Per questa ragione e per aiutare il focus dell’utente bisogna evitare le informazioni superflue, che tolgono attenzione alle componenti importanti.

Ma che fare con informazioni che non sono superflue, ma, semplicemente, servono solo in alcune circostanze? Queste possono essere attivate a comparsa, in maniera che non affollino l’interfaccia nelle operazioni di routine.

Anche qui ci vengono in aiuto attività di analisi come la definizione degli scenari d’uso più comuni. E’ bene rendere sempre visibili i comandi e le informazioni che servono in questi casi, e valutare soluzioni differenti (ad esempio a comparsa) per gli scenari più occasionali. Tuttavia, come detto, l’evento che attiva i nuovi comandi dovrebbe essere sufficientemente significativo per essere chiaramente identificato.

Informazioni a strati: la “progressive disclosure”

La tecnica di rivelare via via nuove informazioni “a comparsa” nel design di interfacce quando lo spazio disponibile è poco e le informazioni che bisognerebbe presentare all’utente sono molte è chiamata progressive disclosure. Molto usata nelle finestre di dialogo dei software, quando un tasto al termine della finestra rivela una nuova porzione “a comparsa” della finestra, la tecnica è in uso fin dagli anni ’80, anche se sulla sua efficacia mancano prove empiriche definitive.

Oggi il “read more…”, o “continua..” che si legge nelle prime pagine dei blog o dei siti di news è un’applicazione del progressive disclosure.

Molte pagine di configurazione di preferenze, sia su desktop che su web, utilizzano questa tecnica per far aprire nuove sezioni di pagina con preferenze più avanzate. E’ interessante notare come su desktop questa tecnica venga attivata normalmente da tasti, mentre sul web è più spesso risolta con dei normali link e dei puntini di sospensione.

Difficoltà di manipolazione degli oggetti a comparsa

Le considerazioni su quali informazioni rendere disponibili a comparsa devono tener conto anche di altri fattori:

  1. E’ facile per l’utente operare sul comando?
  2. E’ facile mantenere l’attivazione della funzionalità a comparsa?
  3. E’ facile operare all’interno del comando apparso?
  4. Sono evitate situazioni in cui l’utente, dopo aver attivato il comando a comparsa, non è in grado di disattivarlo e tornare allo stato precedente (come può accadere nel caso di comandi modali che attivano nuovi strumenti di interfaccia)?

I menu a tendina sono un caso particolare di questo tipo di interazione: sono spesso diffficili da manovrare per utenti non esperti, specie se non sono costruiti in maniera robusta.
Tuttavia, se ben congegnati a volte possono essere necessari, soprattutto nelle applicazioni (desktop e web), le quali hanno spesso un numero elevatissimo di funzioni che non è possibile rendere contemporaneamente visibili.

Bisogna fare attenzione però a non presentare i menu con le label di navigazione attraverso strumenti a comparsa nei siti informativi. Infatti la presenza di link verbali con gli argomenti di cui si occupa un sito offre punti di ingresso semanticamente significativi al lettore (profumo dell’informazione). In loro assenza, semplicemente potrebbe darsi che il fruitore non attivi gli strumenti a comparsa e non veda il link più adeguato ai propri bisogni informativi. La differenza con le applicazioni web qui è data anche dal fatto che su un sito informativo il comportamento è più rapido, impreciso, meno sistematico e continuo di quello che gli utenti hanno di solito su applicazioni che usano più frequentemente e con le quali apprendono strategie d’interazione.

E’ inoltre evidente che strumenti a comparsa “stabili”, che si aprono e rimangono aperti fino alla chiusura da parte dell’utente sono preferibili a strumenti “transitori”, che compaiono e scompaiono al semplice movimento del mouse. Tuttavia, questa stabilità ha dei prezzi: l’utilizzo di questi strumenti richiede un maggior numero di azioni e richiede che sia chiaro come chiudere o rimuovere quel particolare oggetto.

Percepibilità come dimensione sufficiente

Uno dei fattori principali che rende le informazioni percepibili è la loro dimensione. Gli oggetti più grandi sono meglio percepibili di quelli piccoli, naturalmente. Questo riguarda testi, bottoni e altri comandi.
Una ricerca del SURL ha comparato alcuni font tipici a diverse dimensioni: 10, 12 e 14 pixel. In sintesi, ecco i risultati:

  1. Non vi è significativa differenza né del tipo di font né della dimensione per quanto riguarda l’accuratezza della lettura e il numero di errori.
  2. Vi è invece una differenza significativa sia per il tipo di font che per la dimensione per quanto riguarda il tempo di lettura. Times e Arial si leggono in modo significativamente più rapido di Courier, Schoolbook e Georgia. E i testi a 10 pixel si leggono più lentamente dei testi a 12 pixel. Queste differenze relative al tempo di lettura sono però piccole2.

Per altri interessanti risultati che riguardano la percezione di leggibilità e di piacevolezza dei font vi rimando allo studio originale.

Percepibilità come sufficiente contrasto

La percepibilità degli oggetti è influenzata da molti principi e leggi percettive. Per brevità citeremo qui solo il più importante per la progettazione web, cioè il contrasto fra primo piano e sfondo: vale per i testi e per le immagini dotate di significati, così come per i comandi (bottoni, caselle di opzione, ecc.).

Per determinare se i colori scelti sono sufficienti sono stati sviluppati diversi algoritmi. Il più famoso è quello obbligatorio per la legge Stanca, che però è stato sviluppato attraverso una procedura sperimentale abbastanza criticabile, che teneva in considerazione solo un sottoinsieme di colori websafe e utenti che non avevano alcun deficit di percezione del colore.

Per rendere conto dei limiti di questo primo algoritmo sono state proposte formule alternative. Silvia Zuffi, Giordano Beretta e Carlo Brambilla ne hanno proposto recentemente uno basato sulla luminosità. Quasi in contemporanea le wcag 2.0 ne hanno proposto uno in sostanza molto simile, reso disponibile da un test automatico su Juicy Studio.

Il consiglio è di valutare i vostri contrasti con tutti questi algoritmi.

Non esiste un modo affidabile al 100% per controllare in automatico un contrasto cromatico. Nel dubbio è meglio essere conservativi, e scegliere contrasti abbastanza alti.

Non solo testi

La percepibilità, sia per problemi di dimensione che di contrasto, riguarda come abbiamo detto anche le immagini. Sotto vediamo un esempio di mappa immagine (qui non attiva) che ha un doppio problema: le regioni d’Italia sono troppo piccole (se si clicca sul molise o sull’umbria si rischia di sbagliare) e con un difetto evidente di contrasto sia nei bordi che nello sfondo.

Carta dell'italia con le regioni non distinguibili causa cattivo contrasto cromatico
Fig. 1 – Una mappa dell’italia con contrasto e dimensioni insufficienti a garantire il principio di percepibilità.

La moda dei testi grigi

Sfortunatamente una moda recente del web design vede l’utilizzo di testi grigi, anche molto chiari, per i testi. Questo riduce di molto la leggibilità delle pagine, tanto più se i testi sono piccoli. La riduzione vale non solo per i disabili, ma anche per chi ha difficoltà di vista piuttosto comuni, usa gli occhiali o le lenti, o semplicemente affatica la vista con molte ore al monitor. I problemi si acuiscono con il procedere dell’età, dunque un numero sempre crescente di utenti ne sarà coinvolto: la moda dovrebbe tendere proprio in senso inverso!

Una conseguenza poco discussa di questa moda è che molte volte i siti mantengono il testo grigio anche nelle versioni per la stampa. Stampare il testo in grigio su carta significa creare grossi problemi di leggibilità, soprattutto se il carattere è piccolo. La retinatura effettuata da stampanti laser o a getto d’inchiostro provoca grandi ostacoli. Se non riuscite a rinunciare ad un grigio (scuro!) su monitor, è vietatissimo mantenere lo stesso colore per la stampa. Un più tradizionale nero su bianco rimane, in questo caso, una delle poche regole certe del web-design.

Conclusioni

Riassumiamo alcune linee guida pratiche:

  1. preferire dimensioni non inferiori a 10px per i testi più piccoli (testi di contorno, link minori).
  2. usare almeno la dimensione di 12px (espressa in altra unità di misura, ad esempio em o percentuali, per ragioni di accessibilità) per i testi principali.
  3. Lo stesso si dovrebbe dire di qualunque unità informativa significativa, dunque anche di comandi, bottoni, opzioni. Ma anche di piccole icone o di mappe immagine da cliccare o da leggere: se le dimensioni sono troppo piccole è molto probabile che gli utenti non riescano a percepirle correttamente o si verifichino errori.
  4. Il testo grigio è elegante ma molto meno leggibile: aumentate il contrasto, preferendo il nero, su fondo chiaro (bianco o neutro).
  5. Il testo più spesso (e più grande) solitamente è più leggibile anche se il contrasto è minore. Per i titoli o per testi più grandi ed evidenti potete dunque accettare soglie un po’ diverse, ma con grande cautela.
  6. Evitare colori troppo sgargianti come sfondo: scegliere un colore poco saturo per lo sfondo e un colore più saturo per il primo piano.
  7. Evitare motivi grafici ripetuti come sfondo sotto il testo
  8. Evitare foto, anche virate, sotto il testo. L’unico caso accettabile è usare immagini di sfondo molto leggere, come una filigrana, a condizione che la funzione sia soltanto decorativa
  9. Evitare sfumature che ostacolino la lettura del testo. Vi è attualmente la moda di creare bottoni in 3 dimensioni, un po’ nello stile dell’interfaccia Aqua del Mac: alcuni di questi contrasti sono accettabili, ma altri sono troppo violenti e ostacolanti; bisogna porre particolare attenzione al tipo di sfumatura del bottone.
  10. Nel foglio di stile per la stampa esplicitare il colore nero per i testi e il bianco per lo sfondo

1 La percepibilità è anche il primo dei cosiddetti requisiti soggettivi, ovvero principi e criteri di valutazione che possono essere adottati nel corso della verifica soggettiva (allegato B del DM dell’8 luglio 2005) all’interno della legge sull’accessibilità dei siti.
Il principio di visibilità viene proposto fra gli altri da Norman (La caffettiera del masochista, 1986), e da Constantine (Collaborative Usability Inspections for Software, 1994). ↩

2 Potrebbe sembrare strano che prima si dica “significativamente più rapido” e poi si sostenga che le differenze siano piccole. In realtà con “significativamente” si intende che le differenze riscontrate (piccole) non sono dovute al caso. Le differenze sono piccole, ma dipendono effettivamente dal tipo di font e dalla dimensione scelti. ↩

Cos’è la legge di Fitts

Sviluppata nel 1954 dallo psicologo Paul M. Fitts, nel Journal of Experimental
Psychology, la legge di Fitts stabilisce che il tempo di raggiungimento
di un obiettivo (un’area, un bottone) in un compito di puntamento dipende
dalla distanza dell’oggetto da raggiungere e dalle dimensioni di tale
oggetto. Banalmente, più grande e vicino è l’oggetto,
più veloce sarà il compito di puntamento. Per compito di
puntamento intendiamo un movimento continuo che parta da una certa
posizione e termini sopra l’obiettivo.

Ovviamente, dire che tanto più grande e vicino è un oggetto,
e tanto più veloce sarà posizionarcisi sopra non sembra
a prima vista una gran scoperta. La legge di Fitts però definisce
in termini numerici, quantitativi, il tempo di acquisizione,
dati distanza e dimensione del target e note alcune variabili, secondo
la seguente formula:

MT
= a + b log2 (d/s +1)

dove:

MT = movement time to a target, ovvero tempo di acquisizione dell’oggetto
d = distanza tra il dispositivo di puntamento (ad esempio il puntatore
sullo schermo) e l’oggetto
s = size, ovvero dimensione dell’oggetto (misurata sull’asse del movimento).
Nella formula originale i valori di a e b erano: a = 0,230 sec; b = 0,166
sec., ma variano a seconda delle situazioni e possono essere ricavati
sperimentalmente.

Questo schema indica il compito tipico:

schema del compito di puntamento
In questo schema un puntatore (freccia bianca) deve raggiungere un obiettivo di dimensione “s” (rettangolo a destra) attraverso un percorso lineare di lunghezza “d”.

La legge di Fitts è dunque una formula che riesce a predire in
maniera piuttosto precisa il tempo di puntamento di un oggetto. E’ stata
ripetutamente confermata empiricamente.

Ambito di applicazione

E’ importante precisare i limiti entro cui questa legge vale. Si riferisce
a movimenti continui, in cui la persona ha già
deciso quale obiettivo vuole raggiungere (non si applica dunque
allo scorrimento progressivo di voci di menu per prenderle in esame ad
una ad una), e quando comunque il movimento è abbastanza piccolo
rispetto al corpo umano.

Inoltre presuppone che il compito di puntamento sia scomposto in due
momenti principali: un primo movimento ampio, rapido e non preciso, seguito
da una fase di avvicinamento fine. Originariamente la formula è
stata proposta per movimenti unidimensionali, ma si è
applicata anche a movimenti su due dimensioni, prendendo a riferimento
la dimensione dell’oggetto lungo l’asse di avvicinamento. Si è dimostrata
comunque valida anche quando il percorso di avvicinamento all’oggetto
non è lineare, ma spezzato (ad esempio secondo un tracciato noto
o vincolato).

La legge di Fitts e le interfacce utente

Le conseguenze per la progettazione di interfacce grafiche sono molte.
La più importante, probabilmente, è che il punto più
rapido da raggiungere è… quello in cui il puntatore già
si trova! E’ ovvio, perché non c’è alcun movimento
da fare, nè rapido nè lento. Questa proprietà è
implementata nel menu contestuale, quello che si attiva
cliccando il pulsante destro di un mouse.

menu contestuale nel punto in cui si trova il puntatore
Ovunque si trovi il puntatore è possibile attivare istantaneamente un menu contestuale: l’applicazione più efficiente della legge di Fitts.

A parte il punto in cui il cursore del mouse si trova, la legge di Fitts
stabilisce anche quali sono gli altri punti più rapidi da raggiungere
sullo schermo. Come qualcuno può facilmente immaginare, i punti
più rapidi non dipendono affatto da dove il cursore si trova. Si
tratta infatti di punti rapidissimamente raggiungibili da qualunque punto:
sono infatti i quattro angoli dello schermo. Il motivo
è semplice: il movimento può essere rapidissimo (si può
lanciare il mouse verso l’angolo), senza necessità di ricorrere
agli aggiustamenti fini, dato che l’angolo non consente al mouse di andare
oltre. In questo modo, è come se l’oggetto "angolo" avesse
dimensione infinita, dato che possiamo immaginarlo come un oggetto che
si estende a piacere oltre i limiti dello schermo. Sorprendentemente,
questa proprietà degli angoli dello schermo non è mai stata
sfruttata a dovere dalle interfacce grafiche, fino alla più recente
versione del sistema operativo per il Macintosh, che implementa exposé,
un sistema che consente di attivare funzioni specifiche proprio puntando
i 4 angoli dello schermo (c’è un interessante commento di Bruce Tognazzini al riguardo).

Dopo i 4 angoli, ovviamente i punti più rapidi da raggiungere
sono i lati: anche se in una direzione sola, anche per loro vale l’assunzione
di dimensione infinita. E’ per questo motivo che l’interfaccia del Mac
ha fin dalle sue prime versioni le barre di menu confinanti con il limite
dello schermo. Una caratteristica che rende molto agevole il raggiungimento
delle voci di menu.

la barra dei menu nel mac
La barra dei menu nel mac ha le voci attaccate al bordo superiore dello schermo. E’ possibile selezionare la voce di menu anche posizionando il puntatore contro il bordo dello schermo, contrariamente a quanto avviene con le versioni di Windows precedenti a XP.

Un errore commesso da tutte le versioni di Windows
e in parte corretto solo con la versione XP è che distanzia
di pochi pixel dal margine dello schermo le voci disposte sulla
barra dei compiti, in basso, unito al fatto che distanzia, sempre di pochi
pixel, anche il bottone di avvio, che invece potrebbe
trarre giovamento dalla posizione angolare.

Giova specificare che il fatto che gli oggetti siano staccati di pochi
pixel dal bordo non li rende "solo un po’" meno rapidi da raggiungere.
Rende infatti necessario controllare i movimenti fini (che sono quelli
che fanno perdere tempo) e dunque gli oggetti, sebbene vicini ai bordi,
sono oggetti come tutti gli altri a tutti gli effetti. O sono disposti
esattamente sul bordo, o non trarranno alcun vantaggio dalla legge di
Fitts, rispetto ad altri oggetti di pari dimensione.

Altre conseguenze per le interfacce web

Ovviamente, per come è fatto il web, nessuna pagina può
giovarsi dal posizionare bottoni o link adiacenti al margine dello schermo,
semplicemente perché le finestre del browser hanno un margine di
pochi pixel che rende vano il tentativo (recentemente Safari per Mac ha
eliminato completamente i margini laterali, ma la finestra fluttua sullo
schermo e dovrebbe essere l’utente a posizionarla esattamente sul bordo,
prima di poter trarre vantaggio da eventuali link posizionati sul lato).
Tuttavia, una supposizione statistica che si può fare (e che abbiamo
fatto nel design di questo sito) è che il puntatore del
mouse gravita mediamente più spesso vicino alla barra di scorrimento
della finestra del browser, sulla destra. E’ per questo motivo che abbiamo
inserito una colonna di menu e comandi sulla destra, e anche il tab menu
orizzontale è spostato verso destra: perché la distanza
necessaria per raggiungere quei link è mediamente
minore che se stessero da qualche altra parte. Ovviamente il guadagno
è piccolo e non merita vincoli di design molto rigidi: ma è
pur sempre una considerazione mirata alla facilità d’uso. Oggigiorno,
con il diffondersi delle rotelle sul mouse, il puntatore sarà meno
probabilmente relegato nella zona destra dello schermo, e anche i vantaggi
di questo posizionamento diminuiranno lentamente. Inoltre, passata la
prima schermata (quando i menu spariscono), il vantaggio scompare.

La legge di Fitts può essere ancora utilmente sfruttata nella
progettazione, anche di pagine web. Infatti, molto semplicemente, ci ricorda
che i comandi e le funzioni più importanti e frequenti dovrebbero
essere più grandi ed evidenti. I comandi meno usati, o che potrebbero
dar vita a conseguenze pericolose, dovrebbero invece essere più
piccoli e distanti nella pagina.
Fondamentalmente questo si traduce nella pratica consigliata di ingrandire
le aree cliccabili dei link principali. Un tempo si poteva fare usando
delle immagini, mentre ora, con l’uso dei css, si può ottenere
lo stesso risultato con la proprietà display: block;
applicata alle ancore, cioè all’elemento <a hfref>
che definisce il link, quando questo è contenuto in elementi di
lista. L’effetto è quello che si può notare su questo sito con i menu
laterali.

Fitts e gli errori di puntamento

La legge tiene conto del tempo di acquisizione, ma non parla di tasso
d’errore. In teoria, naturalmente le zone che sfruttano al massimo la
legge di Fitts, come il menu contestuale, gli angoli o i lati hanno tassi
di errore bassissimi o nulli. Ma tutte le altre aree sono soggette all’errore
dell’utente, che può sbagliare a posizionarsi, e cliccare fuori
dalla zona sensibile. Va precisato che questo succede con maggiore probabilità
quanto meno la legge di Fitts viene rispettata. Ovvero, succede di preferenza
con link e bottoni troppo piccoli e/o lontani.

Talvolta, la necessità obbliga a inserire molte icone e tasti
in poco spazio, riducendone le dimensioni e aumentando in tal caso il
tasso di errore. Se le icone troppo piccole sono adiacenti, allora un
errore può far sì che si clicchi il tasto sbagliato, facendo
partire un’azione indesiderata. Per ridurre questo rischio i
progettisti talvolta usano inserire un piccolo spazio (pochi pixel sono
sufficienti) non cliccabile fra icona e icona, detto area di buffer.
L’area di buffer non riduce l’errore: fa sì che l’errore non produca
conseguenze indesiderate.

Esempio di area di buffer inserita fra alcune icone
La barra degli strumenti di WordPad prevede delle piccole aree di buffer (zone di salvaguardia di pochi pixel non cliccabili) fra gruppi di icone, ma non all’interno dei gruppi, dove le icone sono adiacenti. Difficile dire se lo scopo dei progettisti era però in questo caso quello di evitare click per funzioni non simili, o semplicemente quello di separare visivamente i diversi gruppi logici di icone…

In generale, comunque, l’inserimento di una manciata di pixel come zona
di buffer fra due zone sensibili, ovviamente va contro la legge
di Fitts (infatti serve a non far cliccare…). Il motivo è
evidente: dato un certo spazio disponibile e un certo numero di oggetti
(tasti, icone), l’inserimento di zone di buffer riduce la dimensione
degli oggetti. Se lo spazio viene invece aggiunto e non sottratto,
si mantengono inalterate le dimensioni dell’oggetto, ma si introducono
piccole distanze (aumentando d nella formula vista sopra).
In entrambi i casi si va contro la legge di Fitts. Bisogna inoltre ricordare
che inserire arbitrariamente spaziature fra tutti gli elementi può
ostacolare fenomeni percettivi come il raggruppamento o l’allineamento,
che facilitano l’interpretazione dell’interfaccia.

Le zone di buffer dovrebbero dunque essere inserite con una certa
cautela, solo dove i target siano piccoli e i rischi
di errore possano dar vita ad azioni indesiderate. In ogni caso
non dovrebbero essere superiori a pochi pixel. Laddove è possibile,
il tasso di errore si riduce semplicemente rendendo più
grandi le singole zone cliccabili, cosicché sia più
improbabile per un utente cliccare sul margine e più probabile
cliccare al centro.

Fitts e la Fisheye view

Un caso particolarmente controverso di applicazione della legge di Fitts
riguarda il Dock del Macintosh, o molti altri simili sistemi di menu fatti
in flash, dove all’avvicinarsi del cursore gli oggetti del dock (o le
voci del menu) si ingrandiscono (expanding targets), sfruttando un effetto
di ingrandimento selettivo che diminuisce progressivamente per le zone
vicine, simulando in parte la tecnica che viene chiamata Fisheye view,
vista grandangolare.

Il Dock del mac in azione
Un esempio del funzionamento del dock del macintosh. Una serie di icone disposte sul bordo inferiore dello schermo si ingrandiscono al passaggio del mouse nel tentativo (riuscito?) di facilitare il click. Così facendo però fanno muovere anche le icone attorno, con un leggero effetto di disorientamento. Il Dock ha diviso gli appassionati: alcuni lo trovano divertente in sè, quasi come gadget, altri lo trovano irritante e disattivano la funzione di ingrandimento. Tognazzini ritiene pragmaticamente che sia stata un’ottima trovata di marketing…

L’ingrandimento dinamico degli oggetti mentre ci
si avvicina, però, comporta la considerazione di diversi casi particolari.
Ad esempio, l’ingrandimento di una zona può avvenire in molti modi:
sottraendo spazio agli elementi vicini, o aggiungendo spazio all’intero
gruppo. In generale, i benefici dell’ingrandimento sono molto minori di
quel che appare a prima vista (ed è dimostrabile geometricamente)
mentre si sono evidenziati problemi dovuti al fatto che l’utente si
disorienta vedendo muoversi gli oggetti che si ingrandiscono
o rimpiccioliscono, facendo variare il contesto dell’azione. L’argomento
è molto complesso, così come sono molti e diversi i sistemi
(ognuno con specifici vantaggi e svantaggi) che sfruttano il medesimo
principio. Per chi volesse approfondire, un’ottima analisi del Dock si
trova in questo lavoro sperimentale di Zhai et al. (in formato pdf).

Conclusioni

La legge di Fitts applicata al web dovrebbe farci ricordare che:

  • Tutti i link dovrebbero essere di dimensione non troppo piccola,
    perché più piccola è la dimensione, più
    tempo si impiega a cliccare e maggiore è il rischio di errore
  • I link più importanti dovrebbero stare visibili e facilmente
    raggiungibili, idealmente nella prima schermata
  • I bottoni e i menu dovrebbero avere un’area cliccabile ampia, non
    limitata al solo ingombro del testo, ma anche all’area del "bottone"
    circostante, attraverso l’uso del display: block;
  • Elementi di uso frequente o che si vogliono mettere in evidenza dovrebbero
    essere più grandi
  • Elementi di uso infrequente o che possono provocare danni dovrebbero
    essere messi lontani dalle zone principali e resi più piccoli
  • Le zone di buffer non cliccabili fra un’oggetto cliccabile e l’altro
    dovrebbero essere limitate a pochi pixel e solo nei casi in cui gli
    oggetti sono molto piccoli e numerosi, e l’azione compiuta per sbaglio
    è indesiderabile
  • Condizioni e variazioni per casi particolari (ad esempio per soggetti
    con disturbi motori) dovrebbero essere testate.

E’ particolarmente importante l’ultima considerazione: i disabili motori
non hanno tutti gli stessi problemi e non utilizzano nemmeno tutti gli
stessi dispositivi di puntamento. La legge di Fitts vale finché
il movimento è continuo e c’è una corrispondenza lineare
fra movimento fisico e movimento del puntatore virtuale. Se, per effetto
di un mancato controllo dei movimenti fini, o per l’uso di sistemi di
cursore a rotazione, o di altri meccanismi discreti di puntamento, le
premesse non vengono rispettate, non bisogna considerare attiva in quel
caso la legge di Fitts, e bisogna verificare caso per caso quali sono
i problemi di quella categoria di disabili. Purtroppo le ricerche in tal
senso non sembrano numerose, ma è importante non generalizzare
una legge che ha ambiti di applicazione ben definiti ad ambiti che non
le competono.

Feedback e conferme all’utente

Uno dei principi di usabilità più noti è senz’altro
la necessità di fornire all’utente un adeguato feedback sulle sue
azioni. Nel caso di applicazioni complesse il feedback è necessario
per valutare il risultato di azioni importanti, che possono avere effetti
decisivi. E’ importante che una serie di meccanismi riportino, attraverso
display o indicatori di vario tipo, lo stato del sistema seguente all’azione
dell’utente.

Nel web questo è un meccanismo determina molti aspetti dell’esperienza
dell’utente. Dato che è questa costituita di movimenti fra pagine
di un ipertesto del quale non si ha conoscenza finita, fornire feedback
significa in molti casi fornire meccanismi di orientamento che equivalgano
a indicazioni di stato e di posizione: titoli di pagina, path, indicatori
grafici e url sono strumenti che possono svolgere a volte queste funzioni.
Tuttavia, vi sono compiti che richiedono feedback conseguenti ad azioni
più complesse, le quali assumono importanza vitale: si tratta di
situazioni che richiedono all’utente azioni che comportano l’assunzione
di rischi e di costi. Degli esempi sono le procedure d’acquisto, l’inserimento
di dati personali nei form, l’utilizzo di conti correnti online. In questi
casi ed in altri simili, il feedback non può limitarsi a fornire
generici indicatori di posizione ed orientamento, perché l’attività
non è più e non è soltanto un movimento all’interno
di un ipertesto: il web in quel caso è diventato applicazione,
consente l’esecuzione di attività specifiche che possono avere
riflessi diretti nel mondo reale dell’utente. In quel caso il feedback
dev’essere mirato alla comunicazione efficace del corretto o erratto svolgimento
della procedura, e deve seguire il focus attenzionale dell’utente.

Ad esempio, se una procedura d’acquisto viene completata con la pressione
di un tasto, il feedback dovrà apparire (più rapidamente
possibile) nella schermata successiva, in posizione centrale, rilevante,
con un linguaggio che non lasci dubbi sull’avvenuta azione.

Tale principio può sembrare ovvio, ma la sua corretta implementazione
non lo è, perché a differenza dei compiti di navigazione
(libera o finalizzata a obiettivi di ricerca specifici) l’esecuzione di
azioni sul web riguarda molto spesso l’esecuzione di script e applicazioni
sul server. In molti casi queste applicazioni non sono realizzate dal
designer, possono essere standard e non configurabili. A volte, semplicemente,
il progettista si affida in toto al programmatore, che si occupa del corretto
funzionamento del tutto, ma non della comunicazione con l’utente. In altri
casi ancora, è addirittura il server che provvede ai messaggi di
errore quando una procedura non è andata a buon fine.

Feedback come costruzione di fiducia

Il ruolo del feedback è centrale anche nella costruzione del rapporto
di fiducia con il sito, il quale non è legato esclusivamente all’efficacia
della procedura.

Un esempio personale: poco tempo fa ho ordinato un libro online sul sito
della casa editrice. Dopo una ricerca nel catalogo, mi sono trovato nella
pagina che avrebbe dovuto consentire l’acquisto. Niente a che vedere con
i sofisticati carrelli dei siti più titolati. La pagina richiedeva
alcuni dati, compreso il numero di carta di credito, ma senza fornire,
come invece è ormai d’uso comune, informazioni sulle politiche
d’acquisto e di spedizione, né sul trattamento dei dati. Ho voluto
comunque procedere con l’acquisto. Forniti i dati, ho premuto il tasto
d’invio, certo di ricevere qualche tipo di conferma sull’avvenuta ricezione
dell’ordine. Invece, con mia grande sorpresa, sono stato trasportato su
una pagina del tutto neutra rispetto alla procedura d’acquisto. Non una
conferma. L’impressione era in tutto e per tutto ambigua: poteva darsi
che l’ordine fosse stato correttamente ricevuto (ma non avevo idea del
tempo atteso di consegna), oppure che il form non fosse stato elaborato
con successo. Niente mi permetteva di capirlo.

Ho deciso di attendere un paio di giorni prima di scrivere al responsabile
degli ordini. Con mia grande sorpresa, due giorni dopo mi vedo puntualmente
recapitare a casa il pacco con il libro richiesto. Nessuna comunicazione,
nemmeno via mail, da parte della casa editrice!

Dal punto di vista commerciale è andato tutto a buon fine: si
potrebbe essere portati a credere che una procedura del genere, benché
povera di feedback, sia comunque efficace ed efficiente, perché
ha portato al completamento della transazione. Ma così non è,
perché io non acquisterò più alcun libro dal sito
di quella casa editrice, nonostante il buon esito dell’operazione, per
i seguenti motivi:

  1. Non ho alcuna informazione sul trattamento dei miei dati
  2. Non ho ricavato un’impressione di professionalità dal sito
  3. Mi sono sentito in una situazione di forte incertezza per tutta la
    durata della procedura
  4. Il mio, benché l’interesse per il libro fosse in tutto e per
    tutto analogo a quello di un reale cliente, alla fine è stato
    solo un esperimento: se avessi avuto qualche titubanza sul libro o fossi
    meno avvezzo alla navigazione, non avrei proseguito nell’acquisto a
    causa della scarsa trasparenza.

Oltre alle informazioni sulle politiche di trattamento dati, la fiducia
dell’utente viene creata e alimentata anche dai continui feedback del
sistema. Un utente che riceve messaggi appropriati di conferma sulle proprie
azioni si sente protetto dal sistema, soprattutto quando il compito è
importante.

Il feedback diventa in questo caso strumento di costruzione della
fiducia, e in definitiva contribusce alla creazione di un’esperienza
positiva per l’utente. Per l’azienda questo si traduce in un più
solido rapporto con il cliente e in una maggior probabilità di
ritorno anche quando la procedura, per qualche motivo, viene interrotta
dall’utente.

Questo esempio dimostra come l’usabilità non sia composta solo
dall’efficacia o dalla facilità d’uso (in questo caso il compito
non era difficile da eseguire), ma anche da altri elementi che vanno a
costruire l’esperienza complessiva. Chiarezza e cura della relazione paiono
essere altrettanto importanti dell’efficacia, determinano i ritorni successivi
sul sito, anche in assenza di transazioni completate, e costruiscono la
fidelizzazione dell’utente, soprattutto quando sono riferite ad azioni
che sono potenzialmente costose per l’utente stesso.

In un successivo articolo parleremo di altri problemi legati ad errori
nei feedback procedurali.