feedback

Le finestre modali e le loro alternative sul web

Nota: Se siete interessati all’elenco delle alternative possibili sul web alle finestre modali, potete saltare direttamente alla fine.

Nel campo del design di interfacce si chiamano finestre modali le finestre “figlie” generate da una finestra genitore e che impediscono l’utilizzo della finestra che le ha generate. Quando compare una finestra modale, l’utente è obbligato a interagire con questa finestra prima di tornare a poter usare quella che l’ha generata. In genere, si tratta di finestre generate da un’applicazione principale e che servono a diversi scopi:

  1. Deviare l’attenzione dell’utente su una porzione di informazione rappresentata nella finestra modale
  2. Bloccare il flusso principale di azione finché l’utente non inserisce alcuni dati o non preme alcuni bottoni
  3. Presentare un insieme di funzionalità azionabili (ad esempio una finestra di opzioni o di preferenze) che abbiano effetto sulla finestra genitore o sull’applicazione più generale. O offrendo per esempio la possibilità di editare un contenuto selezionato dalla finestra genitore, senza abbandonarla.
  4. Informare dell’irreversibilità di un’operazione. Ad esempio, chiedendo all’utente se è sicuro di voler continuare.
  5. Presentare messaggi di altro tipo all’utente

Non tutte le finestre aperte dalle applicazioni principali sono modali: lo sono solo quelle che impediscono l’uso delle applicazioni che le hanno generate.

Le finestre modali sono molto criticate dagli esperti di usabilità perché disturbano l’utente senza ottenere sempre quello per cui sono progettate.

In particolare, usare una finestra modale per lo scopo 4, non garantisce che la persona sappia cosa vuole fare o che capisca il messaggio. Se sbaglia bottone e l’azione è irreversibile, l’utente ne risulterà ingiustificatamente danneggiato.

Questo ha portato diversi autori, fra cui Jef Raskin, a proporre l’abolizione di finestre modali che servono a segnalare azioni irreversibili, perché troppo a rischio di errore ed intrusive, e di preferire la possibilità di proporre agli utenti un undo (cioè la possibilità di annullare l’ultima azione), se si accorgono che le conseguenze dell’azione non erano quelle desiderate (si veda l’articolo del figlio di Jef, Aza Raskin, su alistapart a tale proposito).

Alertbox e box di dialogo

Un caso particolare di finestra modale è l’alertbox, una finestra che compare proponendo semplicemente un messaggio senza alcuna possibilità di scelta per l’utente, come quello qui rappresentato:

Un esempio di alertbox, una messaggio modale che non prevede alterative per l’utente.

Questa finestra è del tutto inutile (tecnicamente ha efficienza zero) perché l’utente non ha altra scelta che premere il tasto ok, non potendo intervenire sull’operazione (in questo specifico esempio può anche chiudere la finestra con il tasto in alto a destra, ma l’effetto è identico, non c‘è reale alternativa fra i due metodi). Se il messaggio è davvero necessario è preferibile fornirlo in maniera da non richiedere interazione, e magari proporre un undo (si veda più avanti la discussione sulle finestre transitorie).

Spesso gli alertbox vengono usati per segnalare in diretta alcuni errori nella compilazione dei form (e rientrano dunque nel caso n.5 di quelli visti sopra). Questo sistema è sconsigliato per l’invasività rispetto al flusso dell’azione. Inoltre, se un alertbox del genere compare troppo spesso, l’utente si può abituare a dare un ok in automatico, premendo ok anche nel caso compaia una finestra modale di altro tipo che preveda una scelta differente, e portando così ad errori dovuti ad un automatismo.

Specificità delle finestre modali

Le finestre modali possono essere specifiche della finestra (o della scheda di una finestra, con i browser recenti), dell’applicazione, o del sistema operativo. Nel primo caso impediscono l’interazione con la finestra che le ha generate, ma non con altre finestre della stessa applicazione. Nel secondo caso impediscono l’interazione con tutte le finestre di quell’applicazione, ma consentono di lavorare con altre finestre di altre applicazioni. Nel terzo caso impediscono di lavorare con qualunque altra applicazione finché non si risponde alla finestra modale.

Con l’avvento del web si sono diffuse delle varianti che potremmo considerare “finestre modali specifiche del contenuto di una pagina web”. Ne parliamo nel paragrafo il web e lightbox.

Finestre modeless e popup

Spesso le finestre modali vengono confuse con i popoup. Nel web le finestre dei browser sono finestre figlie che vengono generate tramite javascript, ma non tutte sono modali. Alcune semplicemente possono essere ignorate, perdere il focus o essere minimizzate.

Finestre che si aprono ma che non impediscono l’azione con la finestra principale (come alcuni pop-up) sono dette finestre non modali, o modeless. Le modeless windows sono state introdotte per prime da Internet Explorer 5.

Le modeless windows possono essere usate come alternativa alle finestre modali in alcune situazioni e sono di solito ad esse preferibili. Tuttavia non è una buona idea aprire finestre, anche non modali, se non è strettamente necessario. Cioè se i benefici non superano i costi. Bisogna in tal caso valutare eventuali alternative (si veda alla fine di questo articolo per una rapida rassegna dei metodi alternativi).

Finestre transitorie

In tempi recenti si sono diffuse delle alternative alle finestre modali chiamate finestre transitorie (inizialmente in sistemi operativi diversi da Windows, che fa grande uso di finestre modali). Le finestre transitorie sono di solito semitrasparenti, rimangono in cima alle altre finestre e non disabilitano le azioni sulla finestra principale. Possono essere spostate, scomparire automaticamente dopo alcuni secondi, dopo una qualche azione dell’utente oppure essere chiuse manualmente.

Un esempio del genere di messaggi che informano l’utente ma che non richiedono necessariamente una sua interazione sono i messaggi di “download completato”, di connessione con una rete, di file audio in esecuzione.

Fornire questi messaggi (che non richiedono scelte all’utente) attraverso finestre modali è improprio. In effetti negli anni recenti tutti questi messaggi vengono forniti da applicazioni e sistemi operativi attraverso sistemi non modali (come i fumetti sulla taskbar in Windows). Un’ulteriore evoluzione sono le finestre transitorie, appunto. In Mac OsX si possono scaricare e installare utilities di notifica transitorie come growl, poi reso disponibile anche per Windows.

Come detto, questi sistemi di notifica trasparenti sono stati ideati da Jef Raskin. Il figlio Aza ne porta avanti la diffusione sviluppando alcune applicazioni, come gli Humanized message, qui descritti (è possibile vederli in azione nella sua applicazione web musicale songza). I messaggi di tipo Humanized servono a notifiche importanti per l’utente, ma che non richiedono interazione: permangono sullo schermo finché l’utente non compie una qualsiasi azione e a quel punto si dissolvono. Per evitare che un’azione accidentale faccia scomparire il messaggio, o comunque che questo sparisca prima che si abbia la possibilità di leggerlo, viene previsto un sistema di archiviazione (un log dei messaggi), per recuperarli se necessario.

In tutti i casi queste soluzioni non sono invasive perché non impediscono l’uso della finestra principale.

Il drawer in Mac OsX

Spesso le finestre modali vengono usate per aprire preferenze o editare parte di un contenuto senza abbandonare la pagina di origine. Queste finestre però non devono essere necessariamente modali. Mac OsX ha proposto il cassetto (drawer) come alternativa ad alcuni tipi di finestre di preferenze (che pure vengono mantenute, non modali, nel sistema operativo). L’applicazione apre una specie di cassetto su un lato dove si trovanno le opzioni da modificare, senza influenzare la finestra principale. Questo è possibile solo con finestre non massimizzate. Ma si può pensare che equivalente a questo oggetto di interfaccia sia l’apertura della palette dei bookmark nel browser, che riduce la finestra principale e ricava uno spazio nel suo contenuto per presentare le nuove opzioni.

Le palette non sono finestre

Non si confondano le finestre modali con le palette, aperte da una barra di menu o da altre palette. Esse non hanno lo status di finestra principale, non si sostituiscono alla finestra che le ha generate, sono piccole e focalizzate, e interagiscono in tempo reale con la finestra (proprio come una barra dei menu).

Hanno in comune con le finestre non modali il rischio di proliferazione: troppe palette o troppe finestre modeless (o popup) tutte insieme o addirittura successive possono creare grande confusione all’utente e rendono difficile capire la gerarchia delle finestre. E’ dunque sconsigliato aprire più finestre allo stesso tempo. Per le palette una soluzione alternativa è stata quella di raggrupparle in maniera ordinata anziché farle fluttuare sullo schermo, come nelle recenti applicazioni di Microsoft Office o Adobe.

Sul web si è sviluppata un’alternativa ai casi 1-2-3 chiamata lightbox (ma esiste un’innumerevole serie di sistemi simili). Invece di aprire le nuove informazioni o le funzionalità in una nuova finestra (modale o meno), esse vengono aperte in un un layer creato in javascript che si sovrappone al contenuto della finestra (ma non alla finestra stessa) e che impedisce l’interazione solo con il contenuto di quella finestra. Rispetto alle finestre modali – e anche ai popup – questa soluzione è preferibile perché consente all’utente di lavorare comunque con la finestra principale e di passare ad altre schede, se aperte.

E’ utile quando non si voglia abbandonare la finestra principale (perché potrebbe diventare troppo complicato ritornarci, per esempio). Non a caso ha particolare fortuna per le gallerie di immagini. Le gallerie sono spesso una parentesi nell’esperienza di navigazione, terminata la quale si vuole normalmente tornare all’indice o alla pagina che le ha generate. Se però ogni immagine di una galleria rimane su una propria pagina, ci si allontana progressivamente dall’indice, e per tornare indietro il back del browser non basta più, o va premuto troppe volte. La soluzione modale (interna al contenuto della finestra e non dell’applicazione) è in questo caso più elegante e più efficiente. Inoltre rispetto alle finestre modali vere e proprie la soluzione di tipo lightbox è più facilmente annullabile anche senza interagire con la finestra. Basta cliccare fuori dai confini del nuovo riquadro e si riprende il controllo del contenuto. Questo fa della soluzione lightbox un’alternativa preferibile alle finestre modali, anche se il suo utilizzo va verificato caso per caso.

Perché sono nate le finestre modali

Le finestre modali vengono spesso amate dai programmatori perché ritengono che così sia possibile guidare meglio gli utenti. Questo è vero fino ad un certo punto, perché gli errori sono sempre possibili. E lo svantaggio è che queste soluzioni hanno il difetto di irritare gli utenti, che non si aspettano una finestra modale ad ogni azione, perdendo così il controllo dell’interfaccia. Tanto più se, come in molte applicazioni di vecchia generazione, le finestre aperte in successione sono più d’una. Meglio progettare le applicazioni senza necessità di finestre modali, scegliendo per ciascun caso l’alternativa migliore (vedi tabella sotto). Preferire in ogni caso, se non fosse possibile farne a meno, modalità limitate al contenuto o almeno all’applicazione (mai al sistema operativo). E si tenga presente che far aprire troppe finestre testimonia più un’interfaccia mal progettata, che obbliga l’utente a decine di parentesi, piuttosto che un flusso d’azione logico.

D’altra parte ci sono situazioni (soprattutto a livello di sistema operativo) dove un evento ha l’assoluta necessità di predere il sopravvento su qualunque altro evento. In questi casi l’uso di finestre modali è inevitabile.

Cosa fare al posto delle finestre modali

ScopoSoluzione alternativa per pagine web
Deviare l’attenzione dell’utente su una porzione di informazione rappresentata nella finestra modale Usare un messaggio visivo (riquadro, freccia, boxino) a comparsa nel contenuto (usando div nascosti), contestualmente a dove l’informazione è necessaria
Bloccare il flusso principale di azione finché l’utente non inserisce alcuni dati o non preme alcuni bottoni (password, conferme) Impedire semplicemente di proseguire nell’azione, presentando un messaggio d’errore esplicativo contestuale, colorato ed evidente come nel caso precedente; accertarsi di mantenere i dati fin lì forniti dall’utente.
Presentare un insieme di funzionalità azionabili (ad esempio una finestra di opzioni di preferenze) che abbiano effetto sulla finestra genitore o sull’applicazione più generale. Offrendo per esempio la possibilità di modificare un contenuto selezionato dalla finestra genitore, senza abbandonarla Usare un layer a comparsa; valutare la possibilità di far andare in un’altra pagina se la procedura è semplice.
Preferire una soluzione tipo lightbox. Non moltiplicare queste finestre oltre un livello.
Informare dell’irreversibilità di un’operazione. Ad esempio, chiedendo all’utente se è sicuro di voler continuare. Evitare operazioni irreversibili. Minimizzare la dimensione e la rilevanza di bottoni dagli effetti distruttivi. Fornire undo e chiari messaggi su quello che si sta per fare e che si è fatto.
Per presentare messaggi all’utente Usare messaggi contestuali in pagine successive a quelle dell’azione. Valutare l’uso di messaggi transitori.

Quando il tempo di caricamento è troppo lento? Tempi di risposta e aspettative dell’utente

Una delle questioni più dibattute – e dei luoghi comuni più duri a morire – del web design è quella relativa ai tempi di caricamento delle pagine. Il mantra è: "se la pagina non si caricherà velocemente, l'utente abbandonerà il sito". E seguono numeri variabili: c'è chi ritiene che una pagina deve caricarsi in 5 secondi, chi in 10, chi (solitamente i web designer…) è più generoso e "concede" alle pagine caricamenti anche nell'ordine dei 20-30 secondi. Ma come stanno realmente le cose? Cosa dicono le ricerche a questo riguardo? E come si possono applicare questi risultati ad un ambito così particolare com'è quello del web?

(Nota del 13 novembre 2008: Abbiamo pubblicato su questo sito un commento alla notizia che le home page dei blog sarebbero troppo pesanti proprio alla luce dell'analisi svolta in questo articolo).

Nell'ambito dell'interazione uomo-macchina, vi sono alcune indicazioni fornite da studiosi come Miller, Bailey e persino Ben Shneiderman, uno dei padri di questa disciplina. Secondo questi studiosi, che si basavano su ricerche condotte comunque fino alla prima metà degli anni '80, il computer avrebbe dovuto rispondere alle azioni dell'uomo in un tempo non superiore ai due secondi. Tuttavia, questa indicazione generica non tiene efficacemente conto del compito. Se si tratta infatti di attribuire relazioni di causalità fra un'azione e la sua conseguenza, allora i tempi fra causa ed effetto dovrebbero addirittura ridursi fino all'ordine dei decimi di secondo. Se invece si considerano compiti come l'inserimento di dati al computer, un'attività ripetitiva che non richiede la costruzione di complessi modelli mentali e di relazioni causali, alcuni autori hanno riportato che scendere sotto ai due secondi di attesa per i tempi di risposta della macchina non provoca significativi miglioramenti della prestazione, mentre si ha un effettivo peggioramento per tempi più alti (Martin e Corl, 1986).

Usare il web non assomiglia però che in rari casi ai compiti di inserimento dati. Le situazioni possono essere in qualche modo paragonate ai compiti di problem-solving, ovvero alla risoluzione di problemi. Valutare gli oggetti presenti in una pagina, la loro congruenza con gli obiettivi di navigazione, effettuare una scelta d'azione fra le alternative disponibili è in effetti un compito complesso e che pone ogni volta problemi in parte diversi. Gli stessi Martin e Corl hanno così trovato che per compiti di problem solving non ci sono significative differenze nella prestazione con tempi di risposta fino ai 5 secondi. Una tolleranza maggiore, seppur di poco, rispetto a quella del semplice inserimento di dati. Oltre ai 5 secondi la prestazione peggiora.

Aspettative di attesa e complessità percepita del compito

Lo stesso Nielsen, d'altra parte, non si sbilancia più di tanto in cifre, e parla più ragionevolmente di "tempi di risposta prevedibili": ovvero, l'utente deve poter prevedere all'incirca quanto tempo ci vorrà per avere una risposta (il caricamento di una pagina, di un file, la risposta di un'applicazione), e questa risposta dovrebbe essere il più possibile costante nel tempo. Sul web si sviluppano comportamenti adattivi in relazione ai tempi particolarmente lenti delle reti telematiche. Lo stesso Bailey osserva come in effetti in relazione a compiti diversi, le aspettative degli utenti verso un tempo di risposta accettabile da parte del computer variano. La cosa interessante è che queste aspettative sembrano variare in funzione della complessità percepita della richiesta. In altre parole, gli utenti sarebbero disposti ad aspettare di più se pensano che il compito sia particolarmente impegnativo per il computer.

In uno studio sui tempi di attesa per lo scaricamento, Selvidge, Chaparro e Bender studiano gli effetti di scaricamenti di 1, 30 o 60 secondi sulla frustrazione, il successo nel compito e l'efficienza. Lo studio sembra dimostrare che, sebbene la frustrazione sia significativamente inferiore con tempi di un secondo, i dati di prestazione (successo o efficacia, ed efficienza) non sembrano variare significativamente rispetto alle condizioni di 30 e 60 secondi di attesa. Dunque il tempo di scaricamento ha effetto solo sul "gradimento", cioè un parametro soggettivo? Il risultato sembrerebbe smentire quello di Martin e Corl relativo al problem solving con tempi di attesa superiori ai 5 secondi, ma va considerato che un ruolo importante in questi risultati lo giocano con ogni probabilità la diversa natura dei compiti nelle diverse ricerche.

Un tentativo di affrontare la questione in ambito web è stato condotto da Bouch, Kuchinsky e Bhatti, 2000. Questi studiosi hanno chiesto a degli utenti di valutare, mentre eseguivano un compito, il tempo di latenza delle pagine, che poteva variare da 2 a 73 secondi. Hanno così trovato che gli utenti valutano "buono" un tempo di attesa fino ai 5 secondi (dato congruente con quello di Martin e Corl, che però era riferito alla prestazione, non alla valutazione), "medio" fra i 6 e i 10 secondi, e "scadente" oltre i 10 secondi. In un successivo studio gli stessi autori hanno trovato che gli utenti iniziavano a giudicare inaccettabile il tempo di attesa in media attorno agli 8,6 secondi.

Il caricamento incrementale

Uno degli elementi che spesso nella pratica del webdesign si considerano è quello del caricamento incrementale. Si sostiene cioè che sia meglio caricare una pagina iniziando a presentare almeno alcuni elementi (testi, ingombro delle immagini), per dare all'utente la sensazione che la pagina sia "viva", che qualcosa stia accadendo. E in effetti un altro esperimento degli stessi Bouch, Kuchinsky e Bhatti sembra avvallare questa tesi. Quando la pagina si caricava in maniera incrementale, presentando prima il banner, poi i testi, e infine le immagini, i soggetti erano molto più propensi a tollerare attese più lunghe, tanto che valutavano in quel caso "buono" un tempo di attesa fino a 39 secondi, e iniziavano a considerarlo "scarso" solo a partire dai 56 secondi! Risultati molto più tolleranti da quelli visti sopra, dove il giudizio crollava attorno agli 8-10 secondi. E' bene dunque far accadere qualcosa nella pagina, fornire un primo contenuto, in attesa del caricamento completo: questa pratica sembra rendere gli utenti molto meno severi e diminuisce la loro frustrazione.

Questo risultato conferma uno studio precedente di Ramsay, Barbesi e Preece dove utenti che attendevano più di 41 secondi giudicavano negativamente anche il contenuto delle pagine, definendolo addirittura meno interessante (ovviamente a parità di contenuto) rispetto a quelle che si caricavano più velocemente, oltre che più difficile da scorrere! E la valutazione negativa si rileva anche sui siti di e-commerce: pagine più lente suggeriscono agli utenti che i prodotti sono di qualità inferiore e che la sicurezza della transazione è più bassa.

I tempi incidono sulla valutazione e sulla fiducia percepita

Si possono trarre delle conclusioni da questa parziale rassegna? E' difficile dire una parola definitiva su parametri oggettivi come efficacia ed efficienza. Manca una prova definitiva che tempi di risposta più lenti influiscano davvero significativamente sul successo e l'accuratezza della prestazione. Sembra che questa dipenda in qualche misura anche dalla natura del compito stesso, e che non tutte le operazioni svolte al computer abbiano lo stesso andamento in dipendenza del tempo di risposta della macchina.
Quel che pare però essere acquisito è che tempi di caricamento più alti incidono significativamente proprio sulla valutazione soggettiva dell'utente verso il sito e verso i suoi contenuti o i prodotti che esso vende. E questo è naturalmente di cruciale importanza nella costruzione di un rapporto fiduciario con l'utente per i siti di e-commerce. Paradossalmente, una grafica più leggera, ancorché rispettosa della coerenza aziendale, serve dunque proprio ai siti che hanno bisogno di essere giudicati meglio, e che da questo giudizio possono derivare un aumento della fiducia dell'utente e quindi delle transazioni. In sostanza, il modello Amazon: grafica semplice e rapida, ma efficace e senza fronzoli.

Alcune tecniche per il caricamento incrementale possono essere proficuamente sfruttate: inserire ad esempio nell'html il width e l'height delle immagini consente ai browser di presentare prima il testo, in attesa del caricamento completo dell'immagine. L'uso di file comuni per varie pagine del sito (immagini, css, js) consente di sfruttare la permanenza in cache dei contenuti.

In generale, è bene anche sottolineare che la lentezza delle pagine diventa tanto più frustrante quanto più a lungo un utente interagisce con il sito. Dunque mantenere le pagine leggere è comunque un vantaggio e aumenta la probabilità che l'esperienza sia piacevole, che l'utente interagisca più a lungo, e infine che ritorni in seguito sul vostro sito.

I problemi di banda non sono risolti

Fra i fattori che influenzano il tempo di caricamento non vi è soltanto la dimensione dei file che compongono la pagina, ma anche altri fattori tecnologici cruciali, alcuni dei quali dipendono dal server, altri dal client o dalla rete in genere. Fattori dei quali un designer deve comunque tener conto, sebbene siano per lo più fuori dal suo controllo.
Dal server dipendono la potenza di elaborazione, la banda disponibile e i tempi di risposta. Dal client, e comunque dalle caratteristiche della rete, dipende la potenza del computer e soprattutto la velocità della connessione.

L'aumento dell'utenza casalinga dotata di linea DSL non porta purtroppo sempre significativi aumenti nella velocità di navigazione, a causa anche dell'errato dimensionamento dell'offerta di alcuni gestori (che in un recente passato ha anche dato vita ad alcune polemiche) e dei limiti fisici della rete. Le connessioni cosiddette a banda larga riducono invece sensibilmente il tempo di scaricamento dei file in FTP. Tuttavia, né per lo streaming, né per la navigazione web come la conosciamo oggi, l'aumento delle linee DSL porterà da solo ad un miglioramento definitivo dell'esperienza dell'utente, perché spesso la velocità reale media di queste connessioni, peraltro monitorabile via PC, è inferiore (in certi periodi anche sensibilmente) agli 8/10 kB/s. Tempi che rendono comunque lento il caricamento di pagine sopra i 40KB. Le tariffe DSL sembrano convenienti soprattutto quando sono flat, cioè quando forfettizzano il tempo di connessione. Questa rimane ovviamente una convenienza soprattutto per chi si collega spesso, non per un'utenza occasionale, da un'ora di connessione al giorno.

E' dunque per il momento ancora lontano il tempo in cui la pesantezza dei file non sarà un problema per i designer sul web, allo stesso modo in cui non lo è mai stato per i designer su carta. E a complicare comunque la questione e a rendere ancora conveniente la produzione di pagine molto leggere va menzionato il fatto che stanno aumentando i servizi di hosting che offrono banda limitata, e applicano un sovrapprezzo per i Gigabyte eccedenti. La banda costa, insomma, e a dispetto del fatto che internet free sia ancora la formula preferita dagli italiani, non tutto il free alla fine è poi gratis come sembra.

Nota del 13 novembre 2008: Abbiamo pubblicato un commento alla notizia che le home page dei blog sarebbero troppo pesanti proprio alla luce dell'analisi svolta in questo articolo.

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.