interaction-design

Social network e interfacce sociali: intervista a Gianandrea Giacoma e Davide Casali

Uno degli interventi di Better Software che si preannuncia più stimolante per chi si occupa in particolar modo di usabilità e di progettazione delle interfacce è senz’altro quello di Gianandrea Giacoma e Davide “Folletto” Casali, che si occuperanno di Interaction Design e Analisi dei Social Network. Le interfacce sociali, quelle che prevedono cioè un’interazione e una comunicazione fra gruppi per facilitare attività di carattere sociale, stanno da qualche tempo emergendo nel web grazie alla crescita dei social network e stanno ponendo nuove sfide a chi si occupa di usabilità, come abbiamo anticipato qui su Usabile.it in un recente articolo.

In quest’intervista approfondiremo con Giacoma e Casali alcune applicazioni pratiche di questa attività di progettazione, grazie alla loro esperienza diretta sul campo.

Presentatevi brevemente ai lettori: competenze, provenienze, attività principali

GIAN: Sono uno psicologo che svolge ricerca e consulenza sul Social Network Design, l’Enterprise 2.0 e Marketing dei Social Media. Mi posiziono come competenze soprattutto sul versante persona all’interno dell’interazione uomo-macchina (sempre più uomo-macchina-uomo) con un taglio particolarmente transdisciplinare utilizzando la psicologia nel suo ampio spettro di conoscenze non riducibili alla ergonomia cognitiva. Collaboro in Univ. Cattolica, Bicocca e MIP a Milano. Sono membro di Idearium e Bzaar.

DAVIDE: Sono una persona molto portata per la sintesi, il bilanciamento e l’organizzazione con una spiccata attenzione per quelle che sono le dinamiche sociali e i comportamenti delle persone. Queste doti mi hanno portato dopo un trascorso come programmatore e grafico verso l’Interaction Design, disciplina nella quale una parte rilevante delle mie competenze riesce ad esprimersi al meglio.

Al momento lavoro in Maison,the, una delle poche società italiane unicamente dedicate all’interaction design e partecipo attivamente in alcuni altri progetti come WideTag.com, Good50×70.org, Idearium, Bzaar, Tonight.eu, Stacktrace che spaziano dalla “internet of things” alla sensibilizzazione sociale alla divulgazione tecnologica alla nightlife.

Qual è l’argomento al centro del vostro seminario a Bettersoftware?

GIAN: Porteremo a Better Software la nostra esperienza e ricerca su ciò che alimenta i Social Network dal punto di vista motivazionale e di incentivi. Ormai i tempi sono maturi per andare oltre gli slogan e cercare di individuare degli standard progettuali delle dinamiche sociali, psicologiche, individuali e di gruppo che sottendono i Social Network. Essendo competenze e ambiti nuovi (ma che possono attingere a discipline ben più antiche senza riscoprie la ruota) proporremo, in una logica di continua beta, Design Motivazionale che è il modello di SN Design che abbiamo sviluppato.

DAVIDE: A Better Software porteremo una parte del nostro lavoro che riguarda le motivazioni e i principi primari che sono a fondamento di tutte le dinamiche sociali applicate a dei media tecnologici come è il web. Quello che è il nostro intento è fare capire da un lato che la componente tecnica è abilitante ma non è motivo sufficiente per innescare tutti quei meccanismi che hanno portato O’Reilly ad usare il termine Web 2.0,

Per capirsi: mettere online un forum è la parte tecnica abilitante, ma se nessuno lo usa non serve a nulla! Quali sono quindi i principi che permettono a chi progetta questi sistemi di utilizzare le dinamiche sociali? Noi forniremo risposta a questa domanda con il Design Motivazionale e i suoi 4 elementi chiave: bisogni funzionali, usabilità sociale, motivazione e flusso di attività circadiano.

Nei social network si possono osservare dei pattern di comportamento tipici, un po’ come si osservano nelle comunità e nei gruppi in genere . Quanto questi comportamenti possono essere influenzati da specifiche progettazioni dell’interfaccia? La presenza o l’assenza di strumenti specfici, la frequenza con la quale vengono pubblicate novità, o anche solo la capacità dell’interfaccia di segnalare cosa fanno gli altri, influenza (e come) l’attività degli utenti?

GIAN: Indurre determinati comportamenti degli utenti è una questione delicata. Per ora noi ci siamo mossi soprattutto nella direzione di aderire alle esigenze di un utente tipo come sistema sociale e psicologico (collocando Design Motivazionale sopra lo UCD), in quanto il difficile e delicato passo della induzione è tutt’altro che scontato. Devi tenere conto che nei Social Network si ha a che fare con sistemi super complessi dove ha più senso parlare di innesco e facilitazione che di una vera e propria induzione e manipolazione deterministica. Ovvio che l’interesse nell’individuare “meccanismi certi” almeno su grandi numeri c‘è, il punto è capire quali e come sono applicabili e utili di volta in volta. Stiamo lavorando anche su questo ma per ora non ci sbilanciamo.

DAVIDE: Inizierei con una precisazione: a mio avviso separare “social network”, “comunità” e “gruppi” come tre entità distinte rischia di essere fuorviante. Questi tre termini rappresentano più dei fattori di scala che dei cambiamenti di struttura: il fondamento di tutti questi sono i singoli individui che tramite dinamiche complesse di interrelazione e motivazioni intrinseche ed estrinseche costituiscono delle macrodinamiche osservabili, un po’ come possiamo osservare un organismo nel suo complesso (macro) oppure discendere ai singoli organi fino ad arrivare alle cellule (micro).

Il design, inteso come progettazione e bilanciamento di differenti requisiti, è un elemento fondamentale nel plasmare queste dinamiche sociali perché sul web (e non solo) comunichiamo non direttamente ma attraverso un canale e la forma di questo canale influenza le mie decisioni, anche solo semplicemente per prossimità: se un task è stato progettato per essere molto più intuitivo di un altro, questo sarà probabilisticamente più spesso intrapreso dagli utenti. Digg sarebbe la stessa cosa se per votare una singola storia si dovesse passare attraverso 3 click?

Il problema però è capire che non sono solamente caratteristiche intrinseche dell’oggetto progettato a determinarne l’utilizzo, la gestalt non basta e la piacevolezza estetica è soltanto un fattore. E’ necessario invece capire un singolo elemento come verrà percepito dall’utente finale. Si parla quindi di affordance, di aspettative e di quale motivazione porta l’utente a fare quell’utilizzo.

Ad esempio un sistema di classifica che sia basato su due pulsanti “vota a favore” e “vota contro” innesca dinamiche differenti rispetto ad un sistema di voto con solo “vota a favore”. La prima genera una competizione maggiore. Non si tratta di fenomeni trascurabili, perché seppure rappresentino sfumature di significato per il singolo, una volta inserite in un sistema complesso di socialità la loro somma porta a fenomeni rilevanti e addirittura preponderanti: una community nel giro di 6 mesi può allontanare certe categorie di persone e avvicinarne altre, trasformando sensibilmente l’ambiente.

Se le interfacce influenzano il comportamento su base statistica (se rendono cioè più probabili certi comportamenti piuttosto che altri, come anch’io credo) allora il progettista ha una responsabilità che non è più specifica del progetto, ma diventa anche una responsabilità sociale. Influenza le dinamiche collettive (un tema che ricorda, tecnologizzato, quello posto dal paternalismo libertario di Nudge, il libro di Thaler e Sunstein – che non a caso fanno molti esempi provenienti dalla Human Computer Interaction e citano spesso Donald Norman).

GIAN: Questa domanda solleva l’importante natura psicologica delle interfacce grafiche che nei Social Network non sono solo artefatti cognitivi ma artefatti sociali e psicologici che oltre ad informare permettono la creazione di identità, la costruzione e condivisione di relazioni. Manca ancora una psicologia della interazione abbastanza ampia, si tratta di unire competenze tradizionalmente distanti ma crediamo che l’interaction design avrà sempre maggiore necessità di ibridarsi con la psicologia e la sociologia.

In fine, credo che buona parte delle innovazioni legate ad internet saranno in misura diversa delle innovazioni anche sociali. Siamo in un’era, la Società della Conoscenza, dove dobbiamo fare i conti con tanti piccoli Gutenberg. Ora non è ancora completamente chiara quanta potenza avranno le applicazioni da Social Network nei prossimi anni ma con Davide sia in Elementi Teorici per la Progettazione dei Social Network che in Design Motivazionale abbiamo sempre voluto sottolineare che bisogna porre una certa attenzione ai soggetti deboli che possono usare certi strumenti.

DAVIDE: La responsabilità è sociale, ma solamente rispetto alla “società” di riferimento: un sito per 10.000 persone non rientra nella definizione comune di “responsabilità sociale”, mentre grossi siti fortemente frequentati hanno questo genere di responsabilità anche nel senso tradizionale del termine. A titolo di esempio basti vedere le implicazioni di privacy di Facebook e come questo strumento sta trasformando il senso di privato e pubblico di moltissime persone.

Sullo stesso argomento, recentemente ha scatenato un certo stupore e qualche controversia l’intervento dell’interaction designer Robert Fabricant all’IxDA 2009 di Vancouver, durante il quale ha ricordato che il ruolo dell’interaction designer è quello di modificare, guidare, supportare, elicitare, costringere e controllare il comportamento degli utenti. La cosa è stata presa abbastanza male da una parte della comunità, che non accetta di venirsi etichettare come “manipolatori” del comportamento altrui. Ma Fabricant ribadisce: se il nostro ruolo non è quello di influenzare il comportamento, che ci stiamo a fare? Semplicemente, ritiene che la cosa non sia mai stata esplicitata chiaramente.

GIAN: Forse manipolare è stato scelto volutamente in modo provocatorio per attirare l’attenzione. Ritengo più corretto dire che è importante sviluppare soluzioni per indurre gli utenti verso certi comportamenti, in una logica del condurre. Subentrerà sempre più una possibile questione etica? Credo proprio di si, come è già accaduto per esempio nei mass media, nella pubblicità, ecc..

Se dividiamo l’interazione uomo-macchia nei suoi elementi (sistema macchina, sistema uomo e il processo di interazione) è sul versante utente (persona) che c‘è oggi il maggiore interesse e necessità di crescita di competenze nell’interaction design. Stanno crescendo le competenze sugli utenti come sistemi comportamentali e psicologici, pensiamo, per esempio, al lavoro sulla tecnologia persuasiva di B.J. Fogg della Stanford University.

DAVIDE: Preferirei ripartire dalla citazione che riporta nella sua presentazione: “Technology is not our medium, behavior is!”, che ritengo essere il passaggio chiave.

Infatti la focalizzazione sul comportamento umano consente di rimuovere lo “scudo” di neutralità dietro al quale l’approccio tecnologico si nasconde facilmente. Lavorando con i numeri, è facile staccarsi da ciò che i numeri e le metriche rappresentano.

E cosa succede rimuovendolo? Che si nota che ci sono le persone prima con i comportamenti e poi con motivazioni, necessità, desideri e istinti.

E questo non è neutro. Un interaction designer anche se non lo sa prenderà sempre decisioni che influenzano il comportamento delle persone. Ritengo sia una illusione credere nella neutralità delle attività umane.

Contemporaneamente però bisogna dare il giusto peso a questo: non significa infatti che si è dei manipolatori, a priori. Il fatto di poter influenzare il comportamento è soggetto ad una scelta che sta a monte: come voglio influenzarlo?

Fortunatamente il background tecnocentrico ci aiuta in questo, solitamente la risposta è “per rendere migliore il suo lavoro, più usabili i suoi strumenti”. Ma ancora meglio sarebbe riuscire a prendere coscienza di questa possibilità e agire di conseguenza, capendo quello che si progetta e nel caso smettendo di essere dei semplici esecutori che applicano delle tecniche.

Ritengo quindi che la discussione nata all’IxDA 2009 sia molto utile per la crescita della disciplina e per smuovere molte persone che magari non avevano ancora avuto occasione di notare questo aspetto della professione.

Quali sono i metodi di studio e di analisi delle interfacce e degli utenti che distinguono il vostro approccio da quello più tradizionale in uso nello UCD?

GIAN: Design Motivazionale si colloca sopra lo UCD non ne è alternativo ma lo amplia su certi versanti. Si tiene maggior conto dei possibili agganci che può fornire l’utente come sistema non solo razionale e cognitivo ma anche emotivo e relazionale.

DAVIDE: E’ essenziale fare la premessa che il nostro metodo non si distingue dalle metodologie UCD: sappiamo che differenti realtà utilizzano in dettaglio variazioni e metodologie leggermente differenti, pur mantenendo l’idea principale di progettare intorno agli utenti.

Per questo motivo non vogliamo proporre qualcosa che obblighi un cambio di processo per i gruppi di lavoro, ma una serie di elementi che si affiancano a quanto viene già fatto come User Centered Design.

Il modello di usabilità sociale sviluppato da Giacoma e Casali.

I quattro elementi chiave della nostra metodologia (bisogni funzionali, usabilità sociale, motivazione e flusso di attività circadiano) possono essere applicati in modo semplice, per guidare le metodologie esistenti sia in fase di analisi che in fase di design.

Il nostro differenziale è quindi non sulla metodologia UCD in senso stretto, ma sugli elementi che il processo di design deve utilizzare per poter progettare realmente intorno all’uomo come individuo e come persona sociale.

Come vedete il futuro dell’interaction design?

GIAN: C‘è una difficoltà insita al mondo tecnologico di fare i conti con la natura profondamente transdisciplinare dell’interaction design per motivi culturali e di interpretazione del mercato ma, oggi, è un problema trasversale a tutta l’innovazione. E’ in atto una accelerazione degli artefatti cognitivi che rendono i nostri contenuti mentali (pensieri, progetti, desideri, ecc) capaci di essere oggetto nel mondo materiale in quanto rappresentabili, elaborabili, comunicabili, condivisibili con sempre più facilità, trasparenza, leggerezza, velocità potenza. Questo processo mi fa immaginare un interaction design sempre più legato ad una più matura psicologia della interazione.

DAVIDE:In questo momento io non ho una visione sul futuro dell’interaction design, se non che si tratta di una disciplina ibrida e intermedia fra molte altre. Mi piace pensarla analoga a quella di un produttore cinematografico, che crea l’ambiente per fare incontrare più professionalità differenti. Forse si evolverà in questo senso, non so.

Io mi sto volgendo più indietro, verso le figure di riferimento nel “design” in senso allargato e trovo continuamente riscontri in tutte le idee base di questa disciplina. Ascolto le parole di Bruno Munari per esempio e noto che tutto quello che dice lo applico o potrei applicarlo nel lavoro di tutti i giorni. Lui parlava più spesso di oggetti fisici, io più spesso di virtuali, ma alla fine l’ergonomia cognitiva è sempre presente, che cambia fra i due?

Grazie della disponibilità. L’intervento di Giacoma e Casali a Better Software si terrà mercoledì 6 maggio alle ore 12.

Siete interessati a “Better Software”? Potete leggere anche l’intervista ad Andrea Resmini sull’architettura dell’informazione.

L’usabilità dei form

I form1 sono elementi interattivi della pagina web molto importanti per tutti i siti che, oltre a presentare informazioni, hanno bisogno che l’utente fornisca informazioni e interagisca con il sito. Sia rispondendo a questionari, inviando una richiesta, acquistando qualcosa o registrandosi ad un servizio. Sono il fondamento di qualsiasi applicazione web, dove attraverso i form gli utenti modificano impostazioni, gestiscono dati in inserimento, in visualizzazione e in modifica.

Esistono form semplici e complessi, basati solo sull’HTML oppure modificati con javascript, per utenti smaliziati o novizi. Stabilire linee guida rigide per i form valide e sufficienti per tutti i casi per la mia esperienza è quasi impossibile. Può essere di aiuto distinguere diversi aspetti sui quali i form possono essere valutati, secondo linee guida o principi che vanno prima di tutto interpretati e capiti, piuttosto che applicati rigidamente: nel compiere qualunque analisi bisogna infatti capire se una certa regola può portare benefici alla specifica applicazione oppure no.

Propongo qui, partendo dalla mia personale esperienza di analisi, oltre che dalla letteratura di settore, una serie di aree di valutazione distinte, che possono non essere sempre applicabili a tutti i form, ma che possono aiutare a costruire un proprio insieme modulare di linee guida, adattato al proprio sito e alla propria situazione. In seguito integrerò queste analisi con link e spunti di approfondimento ad altri siti. Le aree di analisi che per convenienza distinguo sono nove:

  1. Comprensibilità linguistica
  2. Operabilità
  3. Messaggi e recupero dell’errore
  4. Comprensibilità della procedura
  5. Percepibilità
  6. Organizzazione spaziale
  7. Semantica convenzioni/affordance
  8. Punti di azione

Comprensibilità linguistica

Usare per ogni form testi introduttivi che spieghino esattamente cosa è necessario fare.

I testi introduttivi sono quelli che vengono presentati in cima al form, subito dopo il titolo, per spiegarne eventualmente il senso e il funzionamento. In tutti i form abbastanza complessi dovrebbero essere presenti, ma essere estremamente sintetici e focalizzati a chiarire. Non dovrebbero essere testi che “vendono”, ma che spiegano all’utente cosa e perché.

Usare per ogni campo etichette verbali chiare per l’utente.

Ogni campo dovrebbe avere un’etichetta verbale che spieghi il dato che l’utente deve inserire o selezionare, in maniera chiara e non ambigua.

Presentare informazioni di supporto sensibili al contesto per i diversi campi, o per i più ambigui.

Spesso un’etichetta iniziale non è sufficiente a spiegare quale dato viene richiesto o perché viene richiesto. A volte il dato è chiaro ad utenti esperti ma non ad utenti inesperti. È utile prevedere fin dall’impaginazione la possibilità di inserire testi ulteriori per spiegare meglio il dato richiesto. Due soluzioni, a seconda dei casi, sono particolarmente efficaci:

  1. Inserire il testo in punto fisso dell’impaginato
  2. Inserire il testo in elementi a comparsa attivabili dall’utente.

Il modulo di iscrizione a Blogger è un esempio di come una colonna intera del modulo viene riservata ad un testo esplicativo.

Esempio di testo esplicativo contestuale per form
Esempio di testo esplicativo per ogni campo da Blogger.com

In altri casi il testo esplicativo può invece venir presentato a comparsa, cliccando o passando sopra un simbolo con il punto interrogativo o il simbolo della “i” di informazioni. Naturalmente è importante che questi testi siano perfettamente comprensibili per l’utente.

Operabilità

Assicurarsi che sui campi e sui bottoni si possa sempre operare con facilità.

Non parliamo tanto degli errori in inserimento del form, ma di selezione del campo. Tendine che non consentono di scorrere le voci, che si chiudono prima che l’utente riesca a spostarsi, campi che cancellano (o che non cancellano quando lo si vuole fare…) quello che si è scritto, selezioni non deselezionabili… tutte cose che vanno testate con cura e accuratamente evitate. E’ un tipo di errore che può capitare solo in certi punti del form o ripetersi spesso: diverse valutazioni di questo errore, diverse cause e diverse soluzioni sono di conseguenza possibili.

Non aprire nuove finestre senza motivo.

Non è un ordine tassativo (si veda l’articolo sulle finestre modali). Ma mi capita spesso di utilizzare o analizzare form che aprono nuove finestre, a volte a dimensione intera (in modo che se l’utente non se ne accorge non funziona più il tasto back del browser), altre di dimensioni più piccole. In alcuni casi particolarmente problematici, vi sono 5 o 6 finestre che si aprono in successione. Al punto che si perde facilmente la relazione fra di esse. Inutile dire che vi sono altri modi per chiedere informazioni specifiche, come riferiamo in un precedente articolo, e che vanno dove possibile preferiti.

Messaggi e recupero dell’errore

I messaggi d’errore dovrebbero essere presentati in pagina, contestualmente al punto in cui l’errore si verifica.

Non dovrebbero essere cioè presentati solo con un alertbox, che non ha alcun riferimento al contesto della pagina2. In ogni caso, a beneficio di tutti, gli errori devono essere segnalati in prossimità del campo interessato.

In questo esempio i messaggi di errore sono pertinenti ai singoli campi. Un riepilogo dell’errore può comunque essere utile in cima a tutti i campi.

Quando presentare l’errore? Vi sono due soluzioni a seconda delle tecniche che si usano. Con tecniche lato server (php, asp, ecc.) gli errori sui campi vanno presentati al ricaricamento della pagina dopo il tentativo di invio. Con tecniche lato client (ajax, javascript) è possibile presentare i messaggi di errore contestualmente. E’ possibile provvedere anche alla validazione del campo in maniera asincrona (si vedano alcune tecniche Ajax per questo). Per ragioni di accessibilità è bene duplicare i controlli anche con tecnologie lato server.

I messaggi di errore devono essere presentati in un linguaggio chiaramente comprensibile e spiegare all’utente cosa dovrebbe fare.

Il linguaggio deve spiegare in maniera comprensibile quale sia l’errore e soprattutto cosa dovrebbe fare l’utente a quel punto. Luca Chittaro presenta un evidente esempio di violazione di questa linea guida in uno degli ultimi post del suo blog, riguardante il sito della Ryanair.

Dovrebbe essere possibile tornare indietro a modificare senza difficoltà i passaggi precedenti.

Vale per i form suddivisi in più pagine. In quei casi ci dovrebbe essere un tasto “indietro”, sulla sinistra in cima e/o in fondo alla pagina, opposto ad un tasto “avanti” che dovrebbe stare sulla destra, per consentire di tornare a modificare le impostazioni precedenti.

In quel caso, anche i dati inseriti dall’utente nella pagina che poi non ha completato, dovrebbero essere mantenuti quando egli vi ritorna.

Un esempio di layout di form
Un esempio di presenza di tasti “indietro” e “continua” (qui preferito ad “avanti”) in un form su più pagine. Non viene presentato però alcun riferimento a quante pagine si devono compilare. Inoltre è particolarmente mal riuscito il layout visivo.

Il sistema dovrebbe tollerare più formati per l’inserimento dei dati oppure vincolare chiaramente al formato necessario

Il problema è particolarmente complesso per tutti i dati di tipo numerico, come date o codici. Ma è importante approfondirlo anche per altri tipi di interfaccia. Si vedano per esempio le soluzioni di tre mascherine per le mappe, che richiedono quindi in input un indirizzo:

Interfaccia di input per le mappe di Google
L’interfaccia per le mappe di Google consente l’inserimento in formato testo. Accetta un’unica stringa, e si incarica di interpretare via e città.
Tuttocittà invece richiede di spezzare i dati su più campi.
Anche Mappy richiede di spezzare i dati su più campi. Ma se lo compilate dopo esservi abituati a Tuttocittà rischiate di sbagliare l’inserimento, perché il layout visivo è simile, ma l’ordine dei campi è cambiato. Che senso ha usare un layout simile alla concorrenza, ma cambiarne il funzionamento? Se esiste un precedente diffuso, è meglio per gli utenti che anche i concorrenti mantengano questo standard. Oppure, che usino uno standard chiaramente diverso e più efficiente, come nel caso della linea unica di Google Maps.

Complessità della procedura

Dovrebbero essere richieste solo le informazioni strettamente necessarie

Compilare i form è noioso e a rischio di errore. Perciò i form dovrebbero essere semplici. Se ci sono informazioni che possono essere dedotte dal sistema da altri dati inseriti dall’utente (ad esempio il codice fiscale qualora fossero già stati inseriti luogo e data di nascita) bisognerebbe evitare di chiederle. Ma soprattutto se ci sono informazioni opzionali, che non sono necessarie al sistema, andrebbero omesse. Minore è il numero di campi, meglio è per l’utente. Questo è tanto più vero quanto più il form è complesso.

Per procedure che si articolano su più pagine, dovrebbe esser chiaro in ogni momento quanti passaggi sono necessari e a quale punto della procedura ci si trova.

Spesso i form sono articolati su più pagine senza anticiparlo all’utente con strumenti che consentano di anticiparsi quanti passaggi saranno necessari. Un esempio positivo di chiara segnalazione dei passaggi della procedura viene da blogger.com:

Un esempio di indicazione dei passaggi successivi in Blogger

Si faccia attenzione a rendere cliccabili i punti precedenti della procedura solo se è previsto che l’utente possa tornarci. Spesso i punti successivi non sono cliccabili perché l’utente ci può arrivare solo dopo aver effettivamente inserito i dati.

I form complessi dovrebbero essere raggruppati in aree tematiche affini, in modo da diminuirne la complessità, attraverso spazi, allineamenti, o eventualmente cornici o sfondi.

Il marcatore fieldset può essere usato per raggruppare fra loro gruppi di campi che sono tematicamente affini all’interno di in un’unica pagina. Ad esempio, si possono raggruppare tematicamente i campi per richieste anagrafiche, separandoli, in marcatura e visivamente, dai campi sulla professione. In questo modo si danno degli agganci visivi all’utente che rendono la pagina più affrontabile, un po’ come quando si separano i paragrafi di testo, con pause interne che aiutano inoltre a rafforzare la coerenza semantica dei diversi gruppi. Questa linea guida vale sia come espediente di organizzazione visiva che di rafforzamento semantico.

Dovrebbero essere chieste per prime informazioni semplici, che l’utente possa fornire senza sforzo.

Mi è capitato durante le mie analisi di incontrare moduli di finanziamento che richiedono prima il codice fiscale (o altri dati astrusi) del nome dell’utente. Questo è ostacolante: può darsi che l’utente non abbia sottomano il codice fiscale, mentre è improbabile che non si ricordi il suo nome. Poi offre una cattiva immagine, come se l’azienda considerasse gli utenti dei numeri e dei codici, anziché delle persone. Okay, anche se è così, non è detto che la cosa migliore sia esplicitarlo…

In generale, le prime informazioni dovrebbero essere semplici per incoraggiare l’utente. Una volta iniziato a compilare, è meno probabile che un utente abbandoni. Se invece vi è un ostacolo fin dall’inizio, è più probabile un abbandono.

Percepibilità

E’ preferibile utilizzare sfondi bianchi o neutri

Questo aumenta di solito la leggibilità dei form, come in qualunque altra pagina: ecco un esempio di linea guida generale che è bene applicare specificatamente anche ai form

E’ preferibile usare un colore di primo piano con forte contrasto, preferibilmente nero.

Ovviamente fa il paio con la precedente linea guida. Spesso per attutire il contrasto si usano testi grigi nella presunzione che siano più eleganti, ma sono anche estremamente meno leggibili, soprattutto per chi ha il minimo problema di vista.

I testi hanno una dimensione sufficiente per garantire la migliore leggibilità

Come per tutti i testi, dovrebbe essere scelta una soglia di leggibilità minima sufficiente a farsi leggere senza problemi da tutti (10-12 pixel). Il problema è forse meno urgente a causa del recente metodo di ingrandimento delle pagine usato dai nuovi browser (ingrandiscono l’intera pagina e non solo il testo). Non abbiamo però alcun dato su quanti utenti conoscano e usino, alla bisogna, la funzione di ingrandimento dei browser stessi.

Ridurre al minimo il rumore visivo del form

Ad esempio eliminando o riducendo colori, bordi, sfumature inutili o ridondanti: bastano già etichette e campi a creare affollamento visivo. Riducete al minimo tutto il resto.

Il modulo qui sopra è ordinato, ma i bordi e gli sfondi appesantiscono visivamente il modulo.
Già solo eliminando le bodature nere, senza altri interventi, l’impatto visivo ne viene migliorato. Naturalmente questo è solo un primo passo di una necessaria ristrutturazione del form, ma dimostra quanto alcuni dettagli visivi possano essere importanti.

Organizzazione spaziale

Le etichette verbali dovrebbero essere alllineate coerentemente fra loro e rispetto ai campi

Sull’allineamento delle etichette esiste uno studio di Matteo Penzo che trova come la soluzione più efficiente sia l’allineamento sopra il campo; o, se deve essere un allineamento a lato, è preferibile l’allineamento a destra (come nella seconda immagine di questo articolo), in modo da mantenere così una distanza costante fra le label e i campi. In ogni caso questo allineamento deve essere coerente in tutto il form.

La ricerca riguarda il tempo di lettura ed è stata condotta con l’eye-tracking in una pagina priva di design: i risultati, per ammissione dello stesso autore dovrebbero essere ulteriormente verificati in casi più complessi e reali. Ma è certamente utile capire che minore è la distanza fra label e inizio del campo, migliore è la percezione da parte dell’utente.

I campi dovrebbero essere di larghezza uguale, od omogenea, per quanto è possibile.

Uno degli aspetti visivamente meno gradevoli dei form sono i campi di lunghezza differente, caoticamente disallineati uno sull’altro. E’ preferibile scegliere da due a 4 dimensioni standard per i campi (a seconda del tipo di dato) e utilizzarli coerentemente, in modo da avere campi allineati ordinatamente per quanto possibile. L’esempio di blogger in cima all’articolo offre un’idea di quel che si intende.

Appropriatezza semantica dei comandi, delle funzioni e utilizzo delle convenzioni/affordance

Accertarsi di utilizzare check box, select e radio button in maniera appropriata al tipo di domanda.

Bisogna rispettare il significato di ogni widget, di ogni oggetto di selezione di un form. In particolare, è bene distinguere quando usare i radio button (pulsanti di opzione) o i checkbox (caselle di spunta: non sono la stessa cosa. I radio button servono a selezionare opzioni esclusive. E in quel caso è bene fornire anche un metodo per deselezionare l’opzione nel caso di campo opzionale (si/no/nessuna selezione, per esempio), perché altrimenti dopo una selezione accidentale non è più possibile deselezionare l’opzione

I checkbox sono invece utili nel caso di più risposte valide contemporaneamente, e non hanno bisogno di opzioni di deselezione perché si possono deselezionare ricliccandoci sopra.

Il select, nella variante a tendina o a box, può sostituire tutte e due queste opzioni, a seconda dell’uso o meno dell’attributo multiple. Tuttavia va valutato bene quando usare il select e quando radiobutton o checkbox, perché il select tende ad essere più difficile da manovrare e ad occultare le voci. E dunque è necessaria un’ulteriore linea guida…

Evitare l’elenco a tendina per un numero di opzioni inferiore a 4-5

…L’uso delle tendine (elemento select) è consigliato quando ci sono più di 4-5 opzioni, e l’uso dei radio button (cui il select nella versione base è sostanzialmente equivalente) rischia di occupare troppo spazio. Usare il select per 4/5 voci soltanto è invece inappropriato perché rischia di occultare le opzioni (a meno di non usare il select box). La tendina è inoltre più complicata da usare per gli utenti inesperti.

Quando è molto importante (ad esempio per il profumo dell’informazione, per dare suggerimenti sui contenuti) far vedere le singole opzioni, può essere preferibile usare radiobutton o checkbox anche per più di 5 opzioni.

I campi obbligatori devono essere identificati in maniera chiara e univoca

E’ sorprendente, ma dopo anni di web esistono ancora molti form professionali di servizi finanziari, che dimenticano di indicare fin da subito quali campi sono obbligatori e quali non lo sono. L’indicazione deve essere esplicita per ogni campo, a meno che tutti siano obbligatori od opzionali, nel qual caso va indicato in cima al form.

I campi obbligatori dovrebbero essere evidenziati usando non soltanto il colore (ad esempio con un asterisco o con un la dicitura “richiesto”)

L’uso del solo colore porta ad ovvi problemi di accessibilità.

Punti di azione

E’ chiaro dalla home page qual è il link, il tasto o il punto di partenza del form

Uno degli aspetti meno chiacchierati e discussi di un form è che spesso non è affatto chiaro come si arriva al form. Spesso nella home page di un sito importante, che richiede agli utenti di compilare un form, c‘è un link piccolisssimo o seminascosto che è l’unico modo per andare alla pagina del form. Se il vostro form è importante, rendete più evidente il punto di partenza del form fin dalla home page. Meglio ancora…

Rendete possibile fin dalla home page l’inserimento dei primi dati nel form

…Iniziate il form in home page, magari con solo due o tre campi. In questo modo è più probabile che l’utente lo noti, e magari inizi a compilarlo.

E’ sempre chiaro in ogni fase del flusso d’azione quale è il prossimo oggetto che attiva l’azione?

Spesso i messaggi testuali invitano l’utente a compiere un’azione (proseguire, riprovare), ma nell’interfaccia non è chiaro come l’utente dovrebbe compiere questa azione. Magari perché non è presente un bottone! Nell’esempio sotto, mancano completamente bottoni o altri inviti all’azione per trasformare la prenotazione in acquisto.

Come trasformare la prenotazione in acquisto? Cliccando su un link che non sembra un link!

In realtà l’utente deve cliccare sul link con il codice alfanumerico, per andare ad una pagina dalla quale fare un acquisto. Totalmente incomprensibile. Ho personalmente osservato utenti arenarsi a questo punto di una procedura d’acquisto.

Altre fonti sui form

  • Le basi per costruire form in html accessibili e usabili sono fornite ad esempio dal sito del LAU del Csi Piemonte. Se volete potete provare a scaricare anche un mio vecchio modello di pagina per form html accessibili costruito per il mio libro. Un po’ datato, ma può essere un punto di partenza per chi non ha esperienza.
  • Marlenek (Daniele Vietri) pubblica sul suo blog due interessanti esempi reali di problemi con i form, che ricadono in alcune delle categorie già viste.
  • Claudio Garau commenta un articolo di Gerry McGovern sull’uso dei tasti Ok/cancel negli alertbox (in breve, “Ok” va usato solo quando è appropriato al contesto: per segnalare un errore far premere ok è fuorviante e alla lunga può portare a errori: non c‘è niente di ok nel segnalare un errore, e l’utente finisce per premere il tasto per abitudine, non perché capisce quello che viene comunicato).
  • Può essere interessante anche un riepilogo di Nielsen sul perché il più delle volte è bene evitare il tasto Reset nei form (foriero di errori non eliminabili…)
  • Su Html.it vi è la traduzione di un articolo presente su Alistapart per migliorare i propri form.
  • Luke Wroblewski ha pubblicato un libro dedicato interamente ai form. Sono disponibili anche delle sue interessanti slide (è un PDF di quasi 4MB) presentate ad un convegno del 2007.
  • Se siete amanti delle soluzioni di codice, Peter Paul Koch spiega come migliorare i form nascondendone alcuni finché non diventano necessari agli utenti attraverso javascript e l’uso del Dom del W3C.
  • Molto interessante infine la pagina di usability.gov sul processo di creazione di un form, dalla carta ai test di usabilità. Consigliatissimo.

1 Uso il genere maschile per il termine “form”, seguendo le indicazioni secondo le quali si dovrebbe assegnare il genere della corrispondente parola italiana per le parole straniere che vengono introdotte. Trovo più appropriata la traduzione di form con “modulo”, che con altre alternative come “mascherina” o “scheda”, che sono comunque sinonimi accettabili. Come sottolinea l’Accademia della crusca, anche l’uso di “la form”, al femminile, può essere corretto, e dunque non ne faccio una questione decisiva: spiego solo la ragione per cui adotto la forma maschile. ^

2 Alcuni utenti ciechi mi hanno segnalato durante alcuni test di gradire l’alertbox come mezzo di segnalazione di errori in linea, direttamente sul singolo campo durante la compilazione. Perché se l’errore viene segnalato solo nella pagina successiva, essi devono riposizionarsi sul campo dell’errore, e farlo sequenzialmente in una pagina complessa è più difficile che per coloro che ci vedono. La segnalazione degli errori dovrebbe dunque essere migliorata, probabilmente, anche per ragioni di accessibilità, offrendo segnalazioni multimodali e, in una pagina di riepilogo, inserendo anche forse dei link interni in cima alla pagina per segnalare il punto dell’errore. Tuttavia, queste soluzioni andrebbero studiate e validate, e vanno prese per ora solo come spunto di approfondimento. ^

Usabilità, ostacoli percettivi, schemi mentali e conoscenze precedenti: un caso reale

Talvolta è opportuno, per chi si occupa di usabilità, osservare da vicino il comportamento degli utenti in situazioni reali, cioè non sottoposti a test. Tali osservazioni vanno fatte in maniera non intrusiva. Non sono indicative del comportamento di tutti gli utenti, ma riescono a compensare un problema tipico dei test di usabilità: la mancanza di motivazione reale.

Recentemente ho avuto modo di seguire il tentativo di iscrizione online ad un corso universitario da parte di uno studente. E’ uno di quei casi che si testano sempre con difficoltà in laboratorio, dato che bisogna informare i sistemi informativi dell’università del test per utilizzare un’identità fittizia ed evitare che dati di test vengano inseriti davvero nel sistema.

L’iscrizione in questo caso avveniva online. Lo studente, il 29 settembre, dopo aver trovato la pagina sulla quale iscriversi al corso di “servizi sociali”, si è trovato di fronte alla seguente tabella (freccia rossa aggiunta per chiarezza):

In questa tabella l’utente non capiva perché la voce “Immatricolazione” indicata dalla freccia non risultasse cliccabile.

Molti link “immatricolazione” erano attivi, mentre il testo “immatricolazione” per alcune facoltà non era cliccabile. In una situazione ideale, l’utente legge il testo sulla riga sottostante e capisce che l’iscrizione sarà disponibile solo dal 30 settembre. Si rende conto di essere il 29 settembre, e decide di riprovare il giorno successivo. Nella realtà, tutto questo non è avvenuto, e l’utente si è trovato a telefonare in segreteria lamentando che l’iscrizione “non funziona”.

Solo in seguito ad una segnalazione esterna (non della segreteria!), si è reso conto che la scritta indicava che l’iscrizione sarebbe stata disponibile dal giorno successivo.

Cos’è andato storto? E’ esclusivamente colpa della distrazione dell’utente?

Anche, ma non solo. Le questioni qui sono molte, e riguardano un tipico intreccio di motivazioni reali, conoscenze, credenze precedenti e disservizi. E’ stato possibile ricostruirle a posteriori con il contributo dello studente stesso.

  1. Conoscenze precedenti e cattive informazioni da parte della segreteria hanno contribuito a creare una precisa aspettativa, grazie all’autorevolezza della fonte. Una modalità di iscrizione scadeva infatti il 26 settembre, e vi era l’aspettativa da parte dello studente di potersi iscrivere secondo un’altra modalità, dal giorno successivo. Nessuno aveva segnalato in precedenza che invece la nuova modalità di iscrizione sarebbe stata attiva solo a partire dal 30. Tanto che persino durante la successiva telefonata informativa l’impiegato ha segnalato di “non sapere”, senza spiegare dunque che il meccanismo avrebbe funzionato di lì a qualche giorno.
  2. La scarsa rilevanza percettiva della data (si veda il principio di percepibilità e visibilità per una discussione più generale). Perché le date attive sono scritte in verde, colore molto rilevante, e le date future in grigio pallido, rendendo disagevole la lettura a chi abbia problemi di vista?
  3. La presenza della medesima parola, “immatricolazione”, in forma linkata e non linkata. Perché scrivere “immatricolazione”, se tale iscrizione non era al momento possibile? Negli altri casi quella parola rappresenta un invito all’azione, ma in questo caso sembra semplicemente non attiva.

Schemi, gabbie mentali e esperienze precedenti

All’opera ci sono due questioni: “gabbie mentali” unite a difetti progettuali che non fanno abbastanza per indicare “l’uscita dalla gabbia”. Lo studente cioè arriva sul sito con una convinzione pregressa: che ci si potesse sicuramente iscrivere. Lo sa da fonti esterne, glielo hanno confermato, non c’è alcuna ragione per lui immaginabile affinché ad alcune facoltà ci si possa iscrivere in certe date e ad altre facoltà in altre. Questo lo porta ad avere un “modello mentale” della situazione. L’utente è convinto che il sistema funzioni in un modo, si aspetta che funzioni in quel modo. Le caratteristiche dell’interfaccia sono ambigue: in alcune parti (alcune facoltà) il sistema sembra confermare il suo modello mentale, mentre in altre no. Qui si innesta l’esperienza precedente dell’utente. “In passato già il sito non funzionava a dovere, ho pensato ad un errore”, ha riferito in seguito.

Di fronte ad una difficoltà, è inevitabile formarsi un’idea della possibile soluzione. L’esperienza pregressa entra in gioco come possibile spiegazione, prendendo il sopravvento sullo stimolo (il testo che spiegava la data di apertura dell’immatricolazione).

Questo avviene più spesso di quanto non si creda, soprattutto in siti procedurali (dove si devono seguire procedure per portare a termine un’attività). A me è capitato di vedere ai test di usabilità utenti saltare completamente righe di testo dove si trovavano le informazioni o le funzioni da essi cercate. I problemi possono essere percettivi (testi troppo piccoli o con colori poco evidenti) o di modello mentale: l’utente non si aspetta che l’informazione sia lì; o, infine di conoscenza lessicale: non conosce l’esatto wording, i termini con i quali l’informazione si presenta. Più spesso dipendono dall’interazione di diversi livelli di problema.

Casi del genere capitano a tutti, in situazioni particolari. Forse il miglior equivalente è l’esperienza, che tutti abbiamo probabilmente provato, di controllare e ricontrollare delle equazioni algebriche precedentemente svolte a scuola senza successo, senza riuscire a trovare l’errore (che magari ci salta all’occhio mezz’ora dopo). Assai simile anche all’esperienza di non riuscire a vedere errori di ortografia su un testo appena scritto nonostante lo si fosse letto e riletto più volte. Si crea una situazione di framing, nella quale non riusciamo più a vedere la possibile soluzione che sta davanti ai nostri occhi. Siamo incapaci di cogliere lo stimolo esterno, e diamo retta alle nostre rappresentazioni mentali più di quanto dobbiamo.

Avviene una sorta di “prevalenza dello schema sullo stimolo”. Un errore cognitivo molto frequente, ma difficile da osservare nei laboratori di usabilità per una ragione molto precisa: mancano le motivazioni reali e le situazioni contestuali che portino alla formazione di uno schema pregresso.

Possibili soluzioni

Cosa può fare un progettista in questi casi? Se l’utente non riesce a notare o a prendere in considerazione lo stimolo (gli elementi corretti dell’interfaccia) nonostante sia presente, che speranze abbiamo di modificare la nostra interfaccia per evitare che questi errori si presentino?

Non possiamo eliminare del tutto la probabilità di errori, ma possiamo ridurla, operando in modo che il minor numero di elementi dell’interfaccia possa contribuire a formare o a confermare schemi errati.

Nel nostro caso, potremmo intervenire su tre elementi:

  1. Il colore del testo con la data – l’uso di un grigio, formalmente corretto perché indica “disattivazione” in molte interfacce, non è corretto perché ostacola la lettura; perché non si tratta solo di una funzione disattivata, ma di un’informazione da fornire; e anche perché le date “attive” non sono nere, ma verdi. Per veicolare il significato opposto, allora, in questo caso è opportuno usare il colore rosso, che è molto evidente e che simbolicamene richiama l’opposizione al verde
  2. La presenza inutile e fuorviante della scritta “immatricolazione”, senza il link – la scritta ha senso se attiva un comando, ma altrimenti perché inserirla? Dà davvero l’idea di un errore: la scritta in altre righe indica un comando, ma qui no. Inoltre, se proprio vogliamo seguire coerentemente la convenzione usata per la data, resa grigia, perché non rendere almeno grigia anche la parola “immatricolazione”, per dare l’idea che l’intera casella della tabella sia disattivata? Meglio ancora, però, togliere del tutto la scritta, lasciando solo la data.
  3. Esplicitare – Infine, per quale ragione non spiegare meglio, con parole esplicite, che l’iscrizione sarà semplicemente disponibile domani, o dopodomani… 30 settembre? In questo modo è decisamente più improbabile che lo studente non si accorga del problema di data. Ma soprattutto non deve essere consapevole di quale giorno è quello nel quale sta operando e non deve confrontarlo con quello presentato.

La prevalenza dello schema, del proprio modello mentale di come l’azione dovrebbe essere, è talmente forte che l’errore potrebbe anche capitare lo stesso. Ma almeno l’interfaccia (o meglio, il suo progettista) non avrebbe nulla da rimproverarsi.

Una possibile soluzione migliorativa sarebbe quella di eliminare il testo “Immatricolazione” e di usare il colore rosso per evidenziare la data. Già questo riduce la probabilità di non vedere o di non capire. Nel testo si suggerisce anche un’altra soluzione (punto 3). Provate come esercizio a produrla ed eventualmente a migliorarla. Il file con l’immagine a dimensione originale è disponibile qui.

Generalizzare il caso specifico

Questo è un caso specifico. È possibile stabilire linee guida generali? Be’, possiamo almeno indurre delle linee guida da questo caso per applicarle a tutta l’interfaccia:

  1. Fare attenzione a non usare convenzioni differenti all’interno della stessa “unità di significato” (e possibilmente in tutta l’interfaccia). La tabella per le iscrizioni è un tutto che dovrebbe essere semanticamente coerente. Invece sono usati per oggetti simili (la casella con il link per l’immatricolazione) due convenzioni differenti:
    • L’uso del verde per gli elementi attivi (che avrebbe il suo complementare nel rosso, per gli elementi dal significato opposto)
    • L’uso del grigio per gli elementi inattivi (che ha il suo complementare nel normale colore di primo piano, qui il nero, per gli elementi attivi)
  2. Non modificare il ruolo funzionale di oggetti simili. Il link “immatricolazione” è un oggetto che “chiama all’azione”. Ripeterlo, ma modificando una proprietà (il link) senza spiegare perché crea confusione.
  3. Inserire le informazioni verbali nella forma più esplicita possibile. Un testo che spieghi che un servizio sarà attivo in futuro dovrebbe essere esplicito, non solo indicare una data. In caso contrario l’utente dovrà compiere un’inferenza, una comparazione, che è un’occasione di incomprensione e di errore in più.
  4. In generale, la cosa forse più importante è conformare l’intera procedura al modello mentale dell’utente. Far sì che il sistema funzioni proprio come si attende l’utente. In questo caso, aver reso possibile l’iscrizione fin dal 27 settembre avrebbe reso ovviamente irrilevante tutto il resto.

Va ricordato che in situazioni di assenza di pressione psicologica (come in un’iscrizione fittizia) non si sarebbero forse verificati questi errori. Ecco perché l’osservazione in casi reali, oltre ai test di usabilità, ci offre importanti spunti di analisi e di miglioramento delle nostre interfacce.

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 gli errori degli utenti devono determinare modifiche dell’interfaccia?

Un lettore, riprendendo un discorso fatto qualche tempo fa su questo sito, pone sul suo blog un quesito interessante: se è vero che gli utenti comettono errori perché “usano prima di capire”, dice, non sarà bene sfruttare i loro errori per progettare le varie funzionalità? Interpretare cioè i loro errori come consulenze gratuite? Attraverso l’errore l’utente ci suggerisce come si aspetta di usare il sistema. Ci insegna il suo modello mentale.

Questo è proprio il punto di forza dell’usabilità: imparare empiricamente dall’utente. Nei commenti di quel sito però qualcuno ammonisce: assecondare sempre l’utente può dar vita ad incongruenze. Ed è vero anche questo. Dovremmo “assecondare” gli errori che hanno un’elevata probabilità di essere commessi anche da altri (sebbene non da tutti) a patto di non introdurre modifiche peggiorative.

Ma come capire quali errori devono dar vita a modifiche e quali sono idiosincratici, o, peggio, ci porterebbero a fare modifiche dagli effetti collaterali negativi?

Il caso delle caselle di input che non comunicano chiaramente la propria funzione

Un esempio può aiutare a capire meglio. Supponiamo che io scambi la casella di iscrizione alla newsletter per la casella di ricerca di un sito e invece di inserirci il mio indirizzo email ci inserisca il termine che voglio ricercare, commettendo così un errore.

Può darsi che quel giorno io sia mezzo addormentato, cosa non improbabile, oppure che ci sia un problema dell’interfaccia. Se lo stesso errore viene commesso da diversi utenti, probabilmente quella casella è mal disegnata. Ma anche se non viene commesso da molti utenti può darsi che la casella sia comunque migliorabile. Come capirlo?

Analizzando posizione, forma, colori, testi utilizzati. Forse è posizionata dove molti si aspettano un motore di ricerca. O forse c’è una cattiva comunicazione del formato del dato, o magari etichette verbali confondenti. Una casella senza anticipazione del formato (ad esempio attraverso il testo di segnaposto) o con messaggi generici è più “fraintendibile”:

Fig. 1 – Nonostante il titolo “newsletter”, un utente distratto può scambiare questo elemento per un search box, se posizionato in posizione ambigua, complice anche l’assenza di informazioni sul dato nella casella e la genericità del bottone. Infatti, mentre il titolo può essere “sorvolato”, casella e bottone hanno maggiori probabilità di essere visti.
Fig. 2 – In questa alternativa, il contenuto dell’input box riduce la probabilità di errori
Fig. 3 – In quest’ultimo esempio, il formato del dato viene esemplificato e il verbo nel bottone cambiato, riducendo al minimo l’ambiguità.

L’errore, se viene rilevato, deve sempre dar vita ad un ripensamento. Ma non tutti gli errori devono dar vita ad una modifica dell’interfaccia. Se cambiare l’interfaccia significa sconvolgere le aspettative degli altri utenti – ad esempio invertendo le posizioni di casella di iscrizione alla newsletter e casella di ricerca, per venire incontro al mio incauto errore – potremmo addirittura peggiorare le cose. Ad esempio, potremmo scoprire che ora è la maggioranza degli utenti che inserisce l’indirizzo email nella casella di ricerca! Al contrario, la modifica illustrata nelle immagini qui sopra è sicuramente migliorativa, perché non introduce altre ambiguità, ma, anzi, le elimina.

Gli errori vanno insomma filtrati e analizzati. Ed è questa è la parte più difficile del lavoro.

Per questa ragione rilevare gli errori solo attraverso procedure “tecniche” come l’analisi dei file di log, senza cioè avere la possibilità di osservare l’utente che commette l’errore ed eventualmente interagire con lui, è estramamente limitante. Se interagiamo con l’utente possiamo discretamente approfondire le ragioni cognitive per cui l’errore si è verificato, ricostruendo i processi mentali con tecniche di rispecchiamento e con interviste post-test. In ogni caso, se possibile, non con domande dirette, perché l’utente tenderà in quel caso a dare una spiegazione qualsiasi, anche se non è consapevole delle ragioni della difficoltà. Ma se non interagiamo con l’utente e ci limitiamo ad analisi tecniche disponiamo solo di una mole di dati sporchi, senza possibilità di capire cosa sia un errore e cosa non lo sia, e cosa abbia determinato quei comportamenti.

L’utente “tipo” non esiste, eppure ci assomiglia

Una delle critiche che vengono rivolte all’usabilità è che:

“ogni utente è diverso, non esiste l’utente tipo, perciò il designer deve prendersi le sue responsabilità e progettare, non farlo fare all’utente”.

Vero. Ma alcuni errori curiosamente ricorrono. Dipendono anche dall’interfaccia e possono essere evitati. E gli utenti hanno in comune molto più di quanto si pensi:

  • Il verde e il rosso nella nostra cultura hanno più o meno lo stesso significato simbolico un po’ per tutti, anche se ciascuno di noi è diverso.
  • Il verso di lettura è sempre da sinistra a destra e dall’alto in basso.
  • Il fuoco dell’attenzione, fino alla prossima mutazione genetica, è sempre uno solo.
  • Le regole di organizzazione percettiva sono simili.
  • E molto altro…

Certo, poi ci sono le differenze. Di conoscenze, di ragionamento, di attenzione. A volte queste differenze generano problemi, altre solo diversi modi di usare l’interfaccia, perfettamente accettabili. Alcuni “heavy users” di Gmail non si rendono ad esempio conto che esistono le label e che è possibile filtrare le mail, mentre altri utenti che a rigor di classificazione dovremmo chiamare “inesperti” le usano quotidianamente con gran successo e senza difficoltà di comprensione. Questo non impedisce però a Gmail di essere usata proficuamente da entrambi i gruppi di utenti.

Per queste ragioni le modifiche delle interfacce sulla base degli errori devono essere del tipo “win-win”, come si dice in epoca di globalizzazione… Fare il bene di alcuni utilizzatori senza penalizzarne degli altri, o almeno fare in modo che il saldo finale fra facilitati e penalizzati sia positivo. E per far questo bisogna discriminare, analizzare, verificare.

Un’eccezione sono le modifiche targettizzate. Cioè, quando non ci curiamo se qualche gruppo di utenti viene penalizzato, perché non fa parte del nostro target. Bisognerebbe essere sicuri che lo stiamo facendo consapevolmente, però, e che non ci siano soluzioni migliori. Il più delle volte, non vedo né tener conto degli errori degli utenti, né pesare i pro e i contro delle scelte. Pensate a tutti i siti che due anni fa sono passati al 1024 × 768 senza considerare il 20% allora esistente di utenti che navigavano con l’800×600. Ma d’altra parte non vedo neanche progettare piazze e ponti non scivolosi…

Come valutare gli errori dell’utente

Se proviamo a stilare alcune linee guida o, meglio, dei criteri euristici su come valutare quando gli errori dell’utente debbano portare veramente a modifiche dell’interfaccia, otteniamo un elenco del genere:

  1. Quando l’errore, qualunque esso sia, è compiuto da più di un utente. Se più di un utente in un test commette l’errore, è assai probabile che molti altri lo faranno nella realtà.
  2. Quando l’analisi dell’errore evidenzia una scarsa chiarezza delle label verbali, siano esse testi, titoli, etichette di bottoni, testi interni ad elementi dei form, link. Una label verbale ambigua genera nel migliore dei casi dei rallentamenti dovuti a dubbi, nel peggiore dei casi errori.
  3. Quando l’analisi mette in evidenza che vi sono segnali non verbali, ma dotati di valore semantico (icone, colori, posizioni) poco chiari. Si fa presto a fare un test di comprensibilità delle icone. Mettetele fuori contesto e chiedete a una decina di persone di scrivere sotto a ciascuna di esse cosa significhino secondo loro, senza dire altro. I risultati parleranno da soli.
  4. Quando l’analisi dell’errore mette in evidenza che la causa potrebbe essere una mancata coerenza dell’interfaccia. Ad esempio, un elemento che assomiglia ad un altro, presente altrove, che si comporta in un modo diverso, e che dà vita a conseguenze diverse. Bottoni che cambiano colore, labeling o posizione, menu che cambiano ordine delle voci o fanno sparire voci, sono esempi di incoerenze che possono creare errori.
  5. Quando l’errore si può eliminare con una modifica ovvia e poco costosa dell’interfaccia.
  6. Tutto questo a patto che la modifica, rianalizzata, non introduca uno dei casi precedenti.

Più difficile è stabilire quando non cambiare l’interfaccia. Ecco alcuni casi tipici:

  1. Quando non si è capito perché avviene l’errore; in tal caso è necessario approfondire le ragioni prima di ipotizzare la soluzione.
  2. Quando la soluzione non rende l’interfaccia più chiara.
  3. Quando la modifica interferisce con altre convenzioni diffuse o introduce ambiguità semantiche.
  4. Quando la modifica penalizza qualche altro gruppo di utenti (elimina o modifica funzionalità gradite o usate dagli altri) che noi non vogliamo penalizzare.

I limiti dell’osservazione degli errori dell’utente

Queste “linee di condotta” si applicano a modifiche puntuali, focalizzate, dell’interfaccia. Non riguardano i cambi completi di modello concettuale, ovvero del funzionamento complessivo del sistema. Le “rivoluzioni”, quelle che modificano il nostro modo di lavorare con un software.

Un software consolidato difficilmente può permettersi modifiche di tali portate, perché deve tener conto degli utilizzatori già acquisiti, che hanno dunque imparato alcuni automatismi che la “rivoluzione” renderebbe inefficaci, innalzando, almeno inizialmente, il tasso di errore e di insoddisfazione. E’ accaduto anche per una delle recenti versioni di Microsoft Office, per esempio, con l’introduzione del ribbon, che all’inizio pare abbia disorientato qualche utente, anche se si tratta sicuramente di una modifica utile dell’interfaccia, una volta appresa.

Per quanto riguarda i siti di contenuti, un redesign solo estetico o piccole modifiche architetturali dovrebbero portare a problemi contenuti, perché tali siti sono meno orientati ai task e i cambiamenti interferiscono meno con la memoria procedurale.

Tra le applicazioni (desktop o web), quelle nuove hanno la possibilità, esordendo sul mercato senza la preoccupazione di perdere vecchi utenti, di proporre nuovi modi per svolgere attività vecchie. In quel caso, la rivoluzione riguarda l’intera interfaccia e non va applicato un modello “incrementale” di modifica come quello qui sottinteso. Questo modello va però applicato anche in queste nuove applicazioni a partire dalle successive iterazioni del progetto, per migliorarlo e raffinarlo.

Gli errori degli utenti sono in definitiva importanti strumenti di “consulenza gratuita” a patto che siano elaborati correttamente e non presi – ma nessuno lo pretende – come unica risorsa progettuale. A rendere più morale la (quasi) gratuità della consulenza – non dimentichiamo infatti che ai test gli utenti vanno in qualche modo compensati – c‘è il fatto che i maggiori beneficiari di questa consulenza dovrebbero essere, alla fine, proprio gli utenti stessi.

Usabilità e motori di ricerca

Uno dei problemi più ricorrenti che gli utenti incontrano nei test di usabilità riguarda l’uso dei motori di ricerca interni ai siti che visitano. Di solito questi motori offrono risultati irrilevanti e non consentono di trovare ciò che viene cercato. In una parola: sono terribili. La cosa è confermata un po’ da tutti i professionisti. Addirittura Nielsen nel suo più recente libro trova che il tasso di successo nei compiti di ricerca sia del 33% contro il 66% della generalità dei compiti.

In alcuni test, coloro che hanno usato in precedenza il motore di ricerca interno ad uno specifico sito e non l’hanno trovato soddisfacente, dichiarano di non volerlo più usare, preferendo utilizzare il motore generalista (Google, Yahoo, ecc.) anche per trovare documenti interni ad uno specifico sito: la probabilità di successo è molto più alta!

Eppure i motori di ricerca interni ai siti dovrebbero avere un compito molto più facile, dovendo indicizzare un numero molto inferiore di pagine. Come si spiega una prestazione così negativa? Le possibili cause sono molte e l’argomento è complesso sia dal punto di vista tecnico che da quello dell’interfaccia. Scusandoci per l’eccessiva semplificazione, metteremo qui in luce tre aspetti in particolare.

La lemmatizzazione

La prima ragione è che i motori di ricerca interna ai siti costruiscono indici secondo algoritmi differenti rispetto ai motori generalisti. Compilano un elenco di lemmi e li associano ad un elenco delle pagine che li contengono. La ricerca viene effettuata poi scorrendo l’indice anziché i documenti.

Questo va bene per costruire ricerche lessicali: trovare una parola o una serie di parole nel corpus dei testi. Ma spesso questi motori di ricerca (specialmente se interni ai CMS con cui vengono gestiti i contenuti del sito) non tengono conto della lemmatizzazione (stemming). E’ un’operazione che si fa su tutte le parole al momento di costruire l’indice che il motore userà nella ricerca. Serve a ridurre le parole alla forma più generale presente nel dizionario (da “mangiai” o “mangiando” a “mangiare”). In questo modo quando si cerca una parola si tiene conto delle possibili forme variabili o derivate: i verbi coniugati, i nomi con numero e genere differenti, eccetera. I motori di ricerca della maggioranza dei siti, cioè quelli messi a disposizione dai blog-tool e dai CMS di uso comune (ma anche alcuni strumenti dedicati), compiono spesso una ricerca solo sulle parole inserite e non sui termini che ne stanno alla radice, insomma. Cosa che invece i motori di ricerca generalisti fanno regolarmente.

Il Latent Semantic Indexing

Anche se compiono la lemmatizzazione, la grande differenza fra motori di ricerca interni ai siti e motori tipo “Google” è che questi ultimi usano, fra le altre cose, un sistema di indicizzazione semantica (Latent Semantic Indexing). Ne abbiamo già parlato a proposito dell’usabilità semantica: è un metodo che ricostruisce, grosso modo, le co-occorrenze delle parole in un corpus di testi (le pagine da indicizzare). Così facendo riesce a tener conto dei contesti nei quali le parole si presentano più frequentemente, e accorgersi, per esempio, che “Materazzi” si presenta spesso associato a “Zidane”, ma solo da una certa data in poi. Questo sistema viene chiamato “semantico” perché da queste regolarità nelle co-occorrenze è possibile dedurre “tracce di significato” (che ci sia stato qualche evento in comune fra Materazzi e Zidane, per esempio, attorno ad una certa data).

Il sistema non è “intelligente”: le correlazioni vengono fatte automaticamente, senza intervento umano. E tuttavia questo consente una miglior disambiguazione di alcuni termini di ricerca in rapporto a possibili risultati, in base al contesto. Il risultato migliora se l’utente scrive più parole (e migliora di molto se si tiene traccia delle sue ricerche passate, come Google fa…). Inoltre è meno sensibile ad alcuni trucchi usati per ingannare i motori di ricerca basati sull’aumento artificioso della frequenza delle parole in un testo. Riesce cioè ad eliminare un po’ di falsi allarmi dalla ricerca.

La LSI (o LSA, Latent Semantic Analysis: Google usa una variante brevettata) è molto più complessa di così, ma ciò che ci preme sottolineare è che fa grande differenza rispetto alla qualità dei risultati. Oltretutto la LSA è più efficace su un corpus di contenuti grande e dunque meno adatta a siti piccoli. I motori di ricerca interni, anche se la adottassero, avrebbero molte meno pagine da analizzare rispetto ai motori generalisti, il che porterebbe comunque a risultati di minor precisione.

La popolarità esterna delle pagine

Infine, come sappiamo, i motori generalisti usano la loro conoscenza sulla struttura dei link nel web per valutare la reputazione delle nostre pagine. Non basta che una pagina sia fortemente correlata alle chiavi di ricerca: a parità di correlazione, vengono privilegiate le pagine che hanno molti link in ingresso, cioè che altri hanno linkato sulle loro pagine, giudicandole, si presume, interessanti.

Perchè non possiamo sfruttare queste conoscenze per migliorare i piccoli motori di ricerca usati sui nostri siti? Be’, la lemmatizzazione potrebbe abbastanza facilmente essere introdotta in qualunque motore di ricerca interno ad un sito (si fa per dire: diciamo che è una tecnica abbastanza consolidata). La LSI (o LSA) anche, ma è meno nota, esiste un minor numero di implementazioni diffuse e c’è il limite del minor numero di pagine da indicizzare che porta a risultati meno precisi. La barriera maggiore è probabilmente l’uso dei link esterni come stima della reputazione delle pagine: decisamente fuori portata per la maggior parte dei siti. Queste ragioni spiegano abbastanza bene perché i motori generalisti sono in grado di fare regolarmente meglio rispetto ai motori interni dei siti.

Nessun motore di ricerca è meglio di un cattivo motore di ricerca

Se questi limiti sono difficili da superare, come migliorare l’esperienza degli utenti? Per siti non molto grandi, la soluzione migliore può addirittura essere paradossale: non inserire alcun motore di ricerca. Se il tasso di successo medio della ricerca è infatti più basso rispetto ai compiti basati sulla navigazione, inserire il motore vorrebbe dire abbassare il tasso medio di successo, e toglierlo vorrebbe dire aumentarlo!

Tuttavia, vi sono siti che hanno necessità o traggono vantaggio, per il tipo di materiale e per la sua organizzazione, da un buon motore di ricerca interno. L’indicazione è in questi casi di investire in un servizio dedicato di una terza parte che abbia qualità paragonabile a quella dei motori che i vostri utenti usano di solito.

Linee guida per il motore di ricerca

Per quanto riguarda l’usabilità della funzione di ricerca e della pagina dei risultati, semplificando molto il tema, il consiglio principale è di rimanere aderenti alle convenzioni che gli utenti conoscono meglio. E dunque:

  1. Inserire una casella di ricerca semplice, composta da un unico campo
  2. Inserire un bottone chiaramente visibile che senza ombra di dubbio sia riconoscibile come il bottone che dà il via all’azione
  3. Evitare le ricerche estese a tutto il web: se gli utenti vanno sui motori generalisti anche per cercare nel vostro sito, è improbabile che vogliano fare l’inverso
  4. Evitare opzioni inutili (caselle di spunta, tendine, ecc): vanno tutte interpretate, cosa che gli utenti in fretta di solito non fanno; vietatissimo inoltre usare opzioni impostate di default in senso restrittivo o anomalo.
  5. Mantenere la casella di ricerca abbastanza lunga (Nielsen suggerisce una trentina di caratteri): il motore di ricerca è un’interfaccia a riga di comando, e, sebbene molti utenti inseriscano poche parole, è bene provare ad indurli ad usarne di più, perché migliorerà la qualità del risultato
  6. Il punto precedente, naturalmente, prevede che il motore funzioni di default con un AND logico e non con l’OR. In questo modo tutte le parole chiave prese insieme concorreranno al risultato. L’uso dell’OR fa aumentare irragionevolmente i risultati diminuendone la rilevanza. Se cerco “usabilità dei motori di ricerca”, non ha senso che mi compaiano tutte le pagine che includono la parola “usabilità”, poi quelle che includono “motori”, poi quelle che includono ricerca, poi quelle che includono le diverse combinazioni di queste parole… Se avete pochi contenuti e di conseguenza soffrite di horror vacui, eliminate il motore e concentratevi sul miglioramento della navigazione, finché non avrete più pagine
  7. Offrite opzioni di suggerimento se l’utente non trova risultati o se i termini di ricerca sono anomali, anche con algoritmi di suggerimento ortografico
  8. Ripresentate nei risultati il termine di ricerca usato, già inserito nella casella per successive modifiche
  9. La pagina dei risultati dovrebbe contenere per ogni risultato tre informazioni basilari:
    1. Il titolo della pagina del risultato, linkato alla risorsa; di solito per il testo viene usato il tag TITLE dell’html, dunque per gli autori di contenuti è vitale scegliere accuratamente soprattutto le prime parole del title, quelle che gli utenti scorrono per valutare i risultati
    2. Tre-quattro righe di estratto del testo della pagina, compreso un frammento che contenga la chiave di ricerca; è meglio usare come testo il contenuto della pagina piuttosto che un metatag di descrizione, perché quest’ultimo potrebbe non essere ugualmente significativo per tutte le chiavi di ricerca che riguardano quella pagina; ed è bene che questo testo contenga informazioni ulteriori rispetto al titolo, che consentano all’utente una migliore valutazione del risultato
    3. L’indirizzo della pagina di destinazione.
  10. Poiché l’ordinamento dei risultati dall’alto al basso dovrebbe già seguire un ordine di rilevanza, è pleonastico (e può risultare confondente) indicare percentuali di rilevanza.

Altre linee guida vanno naturalmente tenute in considerazione per specifici aspetti e casi dell’interazione, come la paginazione dei risultati, i messaggi di errore e di feedback in generale, nonché per tipi particolari di ricerca, ma ci ritorneremo eventualmente con maggior dettaglio in un successivo articolo.

La ricerca avanzata

Un’ulteriore considerazione la merita la ricerca avanzata. Benché utile in specifici casi (banche dati, utenti professionalizzati, ricerca su un corpus definito di testi, consultazione di orari), sulla maggior parte dei siti è una complicazione inutile. Inoltre, laddove possibile, è bene seguire la tendenza generale dei principali motori di ricerca sul web, che è quella di utilizzare un unico campo per tutte le selezioni, riducendo al minimo la necessità di spostarsi fra i campi e di interpretarne il ruolo e il formato.
Ad esempio, una selezione per data può essere fatta scrivendo direttamente gli estremi nella casella della ricerca, anziché manipolando diverse tendine. Per esempio scrivendo “usabilità e motori di ricerca, agosto 2008-settembre 2008”.

Questo sistema a campo unico è più efficiente. Si noti per esempio come si possono cercare località su Google Maps usando un unico campo rispetto, per esempio, all’insieme di campi su siti come Mappy o Tuttocittà.

Esempi:

In questo esempio tratto da Google Maps, tutti i parametri della ricerca possono essere scritti in un unico campo, senza spostare le mani dalla tastiera, compiere operazioni mentali specifiche per le selezioni dei diversi campi, controllare l’esattezza del formato, e così via.
In questo caso, da tuttocitta.it, l’inserimento deve essere fatto passando fra campi successivi, di cui è necessario capire il significato e il formato utilizzabile
In quest’ultimo esempio, tratto da mappy.it, non solo si devono usare più campi, ma l’ordine è diverso da tuttocitta.it, nonostante la configurazione visiva del form sia identica! Dunque chi è abituato ad un sito è probabile commetterà errori nell’altro…

La tendenza comune è quella di usare la casella di ricerca in maniera più possibile “intelligente”, cioè interpretando virgole, numeri, inferendo indirizzi, relazioni e formati. Il tutto è chiaramente reso possibile da un motore che non sia soltanto lessicale, ma che incorpori delle informazioni ulteriori: di tipo e formato del dato sulla base del contesto, di clustering semantico, di scopo. La supremazia dei motori generalisti si spiega anche così.

L’usabilità e le interfacce sociali (e ubique)

Negli ultimi anni il web si è rivelato per quello che fin dall’inizio ci si sarebbe potuti aspettare fosse: una piattaforma sociale. Era nelle intenzioni di Tim Berners-Lee (che parlava di “intercreatività”) e d’altra parte studi su alcuni aspetti sociali dell’interazione uomo-computer datano fin dagli anni ’60.

Ciononostante, l’esplosione del web sociale e in particolar modo dei siti di social network è giunta relativamente inaspettata. I social network (siti come Facebook e Myspace) sono strumenti per la gestione di gruppi e di relazioni basate su interessi e gusti comuni. Ve ne sono di diversi tipi e coprono esigenze differenti, sebbene alcune funzionalità siano sostanzialmente comuni (mantenere una rete di relazioni e di messaggistica, ad esempio).

Ciò che è sorprendente non è l’avvento di questi strumenti, ma il fatto che sia stato imprevisto. Una delle ragioni è probabilmente la tendenza iniziale dei grandi gruppi a vedere il web come uno strumento di pubblicazione e distribuzione di contenuti prodotti dall’industria culturale. Si ritenne a torto che gli utenti avrebbero pagato per i contenuti e che il web sarebbe stato usato come canale distributivo di contenuti a pagamento con componenti di personalizzazione. Nel 1996 Bill Gates scrisse un memorabile articolo chiamato “Content is King”, in cui sosteneva che non nella vendita di software, ma in quella di contenuti, l’industria avrebbe ricavato le maggiori revenue. L’articolo oggi è introvabile online (un paio di anni fa era ancora disponibile all’indirizzo: http://www.microsoft.com/billgates/columns/1996essay/essay960103.asp).

L’ossessione sul contenuto (a dispetto della storia e di un’analisi seria del mercato, come dimostrò Andrew Odlyzko nel 2001) fu una delle determinanti (non l’unica) dei fenomeni speculativi alla base della new economy.

I “reality show” del web?…

Eppure già all’epoca alcuni modelli di business di grandi portali avevano intuito il potenziale dello user-generated content, i contenuti generati dagli utenti stessi. Ci furono tentativi di creare dei portali a costo zero dove offrire spazi agli utenti perché scrivessero i loro contenuti (ad esempio le proprie ricette o le recensioni ai film) gratis in modo che i gestori traessero beneficio dalla pubblicità senza dover pagare per produrre contenuto in proprio. Era troppo presto e soprattutto non si era tenuto conto della necessità di fornire strumenti di relazione, prima che di contenuto: gli utenti sono più interessati a quella che ai contenuti in quanto tali, almeno intesi in senso tradizionale.

I siti di social network sono ora proprio la realizzazione del sogno di alcuni gestori: utenti che ritornano frequentemente sul proprio sito, di propria spontanea volontà, non per trovare contenuto (peraltro costoso da produrre), bensì per gestire profili, instaurare relazioni e condividere risorse da essi stessi controllate. I gestori tentano di guadagnare con la pubblicità, anche se la monetizzazione è per ora deludente.

Si tratta tuttavia di una strada facile da percorrere, perché i social network sono relativamente poco costosi da produrre e mantenere e generano un’elevata loyalty, tanto che alcuni analisti li hanno paragonati ai “reality show” del web (PDF, 88 KB). Utenti che mettono in piazza le loro relazioni in un ambiente relativamente controllato ed economico.

Un altro motivo di interesse per i gestori è la possibilità di archiviare dati sui gusti e i comportamenti degli utenti per trarne utili informazioni di marketing. Questo pone naturalmente enormi problemi potenziali sull’anonimità dei dati e addirittura sulla liceità di queste pratiche, su cui ancora non abbastanza, forse, di si discute.

I limiti dell’usabilità tradizionale

A dispetto di questa realtà, l’usabilità sembra fornire un contributo per ora timido alla progettazione di questi prodotti. Se si effettua una ricerca con i termini “social network usability” si noterà una relativa povertà dei contributi, di metodi, di linee guida specifiche. Addirittura Jakob Nielsen se la prende con i siti 2.0 perché pieni di errori di usabilità. Il punto che sfugge alla sua analisi è che questi siti sono, dal punto di vista degli utenti raggiunti, un successo!

A spiegare questa apparente contraddizione, notata anche da altri, vi sono ragioni storiche e metodologiche. Nel campo della Human-Computer Interaction (HCI) l’usabilità ha senza dubbio, in particolare dagli anni ’80, fornito contributi decisivi, sia a livello di ricerche, sia a livello di metodi di ausilio alla progettazione. In particolare ha avuto un certo successo prima l’ingegneria dell’usabilità, e poi l’approccio “a prezzi scontati” della “Discount usability” nielseniana, ideato per abbattere la barriera d’accesso all’usabilità. Un successo accompagnato da un buon filone di critiche per lo scarso rigore quantitativo dei risultati.

In tutti i casi, i metodi incorporati in questi approcci provenivano da una visione che affonda le radici nello studio dell’utente singolo, alle prese con compiti parcellizzati, in cui è soprattutto l’efficienza (cioè il compiere le azioni con il minor dispendio di energia e di mezzi e la riduzione del numero di errori) ad essere al centro dell’attenzione. Questo approccio è perfettamente sensato in una varietà di situazioni. Da quelle in cui l’utente è inserito in un ambiente ad alta produttività, ed esegue ripetutamente gli stessi compiti nel corso della giornata e delle settimane, fino a quelle che coinvolgono la possibilità di rischi per la salute delle persone, come nel caso di pannelli di controllo in aziende pericolose, di piloti di aerei, eccetera.

L’efficienza non è tutto

Di scuola tipicamente nordamericana, questo approccio all’usabilità ha il demerito di sovrastimare i problemi di efficienza rispetto alle altre componenti del concetto multidimensionale di usabilità che comprende l’efficacia e soprattutto la soddisfazione dell’utente, e trascura addirittura sfacciatamente i contesti d’uso. Tanto che lo stesso socio di Nielsen, Donald Norman, ha concentrato la sua attenzione in anni recenti sul “Design emotivo” e sulla disseminazione del computer nella vita di tutti i giorni.

In effetti, il punto di arrivo del social web sembra proprio essere nell’ubiquità. Cioè nella sempre più crescente interazione fra web e mondo reale, mediata soprattutto da dispositivi portatili sempre più capaci, interoperabili con altri dispositivi inseriti nel mondo fisico e con strumenti di georeferenziazione e di identificazione delle informazioni e degli oggetti (come gli strumenti RFID).

In queste situazioni, non solo gli strumenti tradizionali dell’ingegneria dell’usabilità si rivelano parzialmente inadeguati per l’eccessiva enfasi sull’efficienza a scapito soprattutto della soddisfazione: essi sono anche inadeguati a cogliere gli aspetti sociali dell’interazione con i computer, perché si limitano o a modellare rigidamente pochi compiti, o a studiare l’utente da solo in condizioni di laboratorio. Questo riduce la possibilità di cogliere le implicazioni relazionali, le motivazioni reali degli utenti, le tipologie degli scambi che avvengono con persone diverse in condizioni variabili. Elementi che però sono al centro degli usi presenti e futuri di molte applicazioni sul web.

Differenze fra interfacce individuali e interfacce sociali

Per rendere l’idea useremo un esempio fatto da Joel Spolsky in un’analoga analisi sull’inadeguatezza dei metodi tradizionali dell’usabilità nella progettazione di interfacce sociali. Supponiamo, dice Spolsky, che in un social network o in un’applicazione sociale un utente tenti di inserire un messaggio non desiderabile, ad esempio la pubblicità del Viagra. Secondo le regole dell’usabilità, il sistema dovrebbe capire che l’utente sta compiendo un atto inaccettabile e segnalarglielo. Ad esempio, con un messaggio del tipo “Attenzione: l’argomento Viagra non è fra quelli consentiti”. Feedback all’utente. Perfetto. O no? Evidentemente no, perché in questa situazione l’utente sta in realtà tentando di portare un danno al sistema (e di ottenere un illecito beneficio personale). Se segnaliamo in questo modo l’abuso, tramite un tradizionale feedback, l’utente non farà altro che imparare a ingannare il sistema, inserendo ad esempio un messaggio che pubblicizzi il… V1agra! Sistema ingannato, grazie proprio al suo feedback!

Come dovrebbe comportarsi, dice Spolsky, un sistema socialmente intelligente? Dovrebbe ingannare l’ingannatore. Cioè, riconoscere il messaggio illecito, e mostrarlo all’utente che lo ha inserito come se fosse regolarmente stato inviato. Ma in realtà non inoltrarlo agli altri utenti. Dopo un po’, l’utente non trarrà beneficio dalla sua condotta fraudolenta e abbandonerà il sistema.

L’interfaccia cioè dovrebbe essere autorizzata ad ingannare gli utenti, se questo va a beneficio del sistema. Privilegiare la salute del gruppo rispetto a quella dei singoli, nei casi in cui questi possano danneggiare il gruppo. Sistemi del genere non sono perfetti, dice Spolsky, ma riducono notevolmente la percentuale di comportamenti dannosi.

Non buttare il bambino con l’acqua sporca

I metodi tradizionali dell’usabilità naturalmente non vanno gettati nel cestino, e Nielsen ha delle ragioni quando attacca alcune frivolezze “2.0”. Vi sono esempi di pattern d’interazione tipici e consolidati nei quali l’usabilità “efficientista” può chiaramente offrire importanti contributi. Ad esempio, nell’aiutare a ridisegnare la procedura di login ad un servizio. L’efficienza è ancora importante e tutti i social network potrebbero essere grandemente migliorati sotto molti aspetti.

Quello che però è bene ricordare è che l’usabilità da sola non è in grado di garantire il successo di un’applicazione. L’applicazione ha successo per un insieme, spesso imprevedibile, di ragioni. Ad esempio, perché risponde ad un bisogno sociale, latente o meno, e non vi sono alternative migliori disponibili.

Ne consegue che anche applicazioni poco usabili possono avere successo! Certo, questo avviene solo a certe condizioni. Ovvero, quando lo strumento offre altri evidenti benefici agli utilizzatori in assenza di alternative. In un mercato maturo, l’usabilità costituisce un fattore competitivo fra i prodotti. Ma sono le feature, le funzionalità disponibili, a decidere se il pubblico adotterà il prodotto.

Sebbene l’usabilità tradizionale, dunque, possa offrire importanti contributi, è necessario riconoscere che stiamo assistendo ad un cambio di impostazione nella progettazione delle applicazioni informatiche, che (oltre a molte altre cose già discusse in passato…) va verso una maggior socialità e una maggior ubiquità. Efficienza e soprattutto soddisfazione (che dipende dall’utilità del sistema e dalla sua piacevolezza) dovrebbero passare al centro degli studi e dei metodi dell’usabilità. Considerando in maniera crescente gli aspetti sociali.

Quali proposte di metodo per una “social usability”?

Spolsky nota, nel 2004, che una disciplina che metta al centro la socialità delle interfacce ancora non c’è. Quattro anni dopo non è cambiato molto, forse anche per la lentezza con cui il mondo dell’usabilità sta reagendo a questo cambio di paradigma. Tuttavia alcuni contributi ci sono, e vanno approfonditi.

Pirkka Hartikainen, dell’Università di Helsinki, per esempio (PDF, 668 KB), compie un’ottima analisi e arriva a suggerire, sulla base di alcune ricerche, delle proposte di metodo.

Design basato sui bisogni sociali

Invece di considerare “task” e “funzioni”, il livello di analisi dovrebbe partire dai concetti di “struttura sociale”, “comportamento” e “bisogni”. Ad esempio, costruire uno strumento di comunicazione portatile richiede analisi diverse a seconda che ci si rivolga ad un gruppo di adolescenti, o a dei malati di un ospedale che devono comunicare con i parenti attraverso dispositivi portatili dedicati.

Design per i comportamenti emergenti

Questo approccio parte dall’osservazione e l’analisi dei cosiddetti “comportamenti emergenti imprevisti” in gruppi e strutture sociali, per guidare successive iterazioni del design. I comportamenti emergenti non vengono considerati come “inevitabili” conseguenze o come dati immodificabili nel sistema, ma ci si chiede quali funzionalità del sistema stiano innescando questi comportamenti emergenti, e quali conoscenze dovrebbero essere applicate alle successive tornate di design.

Capire i limiti del multitasking

Le funzioni progettate su dispositivi portatili hanno conseguenze sociali impreviste, come si può notare da una conferenza nella quale i partecipanti sono intenti più a comunicare sul loro laptop che a seguire l’oratore. Simili problemi sono molto comuni in contesti lavorativi, quando sullo stesso computer un impiegato deve svolgere la sua normale attività, ma anche rispondere a dei messaggi in chat, alle email, e contemporaneamente rispondere al telefono d’ufficio e agli sms sul cellulare. Il multitasking cui siamo quotidianamente sottoposti è un’arma a doppio taglio e sono necessari progressi nella ricerca per comprendere a fondo i costi e i benefici di questa modalità di lavoro tanto diffusa.

Capire le differenze dei contesti individuali e sociali

Le funzioni che sono utili in contesti individuali possono portare a disagi in situazioni sociali. Gli esempi sono all’ordine del giorno. La suoneria del cellulare è perfetta per capire che qualcuno ci sta chiamando, ma è disastrosa in un cinema o in un teatro. La vibrazione e le modalità silenziose sono state introdotte proprio per questi contesti, e non avrebbero senso sui telefoni casalinghi.

Altri metodi sono proposti, per i quali si rimanda al paper originale. Aggiungo qui alcuni strumenti direttamente applicabili nello studio delle interfacce sociali, che secondo la mia esperienza potrebbero essere direttamente utilizzabili nella progettazione di applicazioni sociali.

Studiare i contesti sociali e le motivazioni dell’utente

Il contesto sociale e i comportamenti relativi di un utente possono essere studiati in almeno due modi:

  1. Attraverso studi di tipo etnologico, osservando sul campo le interazioni. Questo metodo appartiene tradizionalmente all’usabilità, ma viene poco utilizzato per la difficoltà di identificare target specifici di utenti. Tuttavia, per applicazioni rivolte a pubblici definiti come i teenager, vi è la possibilità di identificare una serie di rappresentanti tipici e invitarli a partecipare ad una ricerca sul campo, con diari di attività, interviste, resoconti, filmati. Si tratta di una tradizione poco presente in Italia, ma che offre la possibilità di importanti insight per capire come vengono usati gli oggetti nel contesto quotidiano
  2. Attraverso metodi di autoracconto o di espressione delle idee e delle motivazioni. Qui possono tornare in aiuto le tecniche di intervista, singole o in gruppo, e persino i focus group. Tuttavia, in tempi recenti in settori affini si sono sviluppate tecniche di progettazione partecipata che prevedono metodi differenti, strutturati su più livelli, di coinvolgimento e ascolto attivo dell’utenza, che prevedono tecniche di gruppo con moderatori esperti, raccolta di opinioni, valutazione delle opinioni (attraverso metodi come il Delphi, per esempio, ma anche con sistemi più informali).

Esperimenti controllati in rete

Infine, vi è un’ulteriore possibilità. Quella di studiare le dinamiche di rete ad un livello macro, attraverso analisi matematiche di comportamenti reali registrati con grandi moli di dati. Vi sono negli ultimi due anni esempi crescenti di questo tipo di ricerche. Ad esempio, quelle che hanno portato ad identificare una legge matematica in grado di spiegare il numero di click che gli utenti compiono su un sito e la distribuzione degli hit, cioè degli accessi alle diverse pagine (metodo alla base anche degli studi sull’information-foraging di cui abbiamo parlato discutendo dell’usabilità semantica).

Infine, la rete offre la possibilità di svolgere dei veri e propri esperimenti dal vivo, approntando versioni diverse delle interfacce e sottoponendole casualmente in maniera controllata a diversi utenti, valutando poi le variazioni nei pattern comportamentali.

Di alcune di queste ricerche parleremo nei prossimi articoli. Quel che emerge alla fine di questa discussione è che, per venire incontro alle mutate esigenze di progettazione di interfacce sociali e ubique, l’usabilità ha necessità di rinnovare non tanto i suoi strumenti concettuali (la definizione ISO 9241 è sufficientemente generale da valere anche in queste situazioni) ma i metodi usati. Alcuni dei metodi tradizionali possono ancora essere impiegati, ma devono essere integrati in un approccio che unisca l’osservazione dell’utente (livello micro) con la comprensione delle dinamiche sociali coinvolte (livello macro).

La comunità internazionale, o una parte di essa, ha iniziato da poco a riconoscere il problema, e stanno iniziando a nascere i primi tentativi di definire nuovi approcci. Continueremo a raccontarli e a seguirli nei prossimi mesi.

Card sorting per lo User-Centered Design

Il card sorting è un metodo di classificazione usato spesso nello user-centered design per definire architettura informativa o schema di navigazione di un sito. È un metodo empirico che ha una tradizione molto lunga in campi diversi delle scienze sociali. Vediamo qui, attraverso una serie di domande e risposte, alcuni concetti base per capire meglio i pro e i contro del card sorting, gli strumenti utilizzabili e i pregi e i limiti dello strumento.

Cos’è il card sorting?

È un metodo di coinvolgimento degli utenti per definire raggruppamenti (classificazioni, categorizzazioni) di contenuti. Si scrive ogni contenuto su un cartoncino e si chiede a diversi utenti di classificarli per somiglianza.

Ad ogni gruppo gli utenti possono assegnare un titolo.

Si possono compiere poi diverse analisi sui raggruppamenti ottenuti. Fra queste:

  1. Cluster analysis
  2. Analisi a coppie (pairwise analysis)
  3. Label analysis
  4. Analisi del consenso fra i partecipanti

Queste analisi possono servire a formarsi un quadro più chiaro di come gli utenti immaginano lo spazio concettuale relativo ai contenuti.

Come si definiscono i contenuti da sottoporre a card sorting?

Se il sito è già esistente, si fa un inventario dei contenuti già esistenti o di quelli in previsione.
In caso contrario, i contenuti devono essere definiti attraverso indagini con gli stakeholder. Fra questi, i committenti del sito, gli utilizzatori, gli autori di contenuti.

I metodi che consentono di raccogliere un elenco di contenuti da considerare sono:

  • Free-listing
  • Interviste
  • Focus group

I contenuti raccolti vanno poi confrontati. Contenuti sovrapponibili vengono uniformati e viene formata una lista finale da sottoporre agli utenti.

Quanti contenuti/cartoncini è bene utilizzare?

Sebbene si possano fare card sorting con un numero indefinito di contenuti, è probabilmente bene limitarsi ad un numero fra 50 e 70, più che altro perché oltre questo numero (ma già sopra i 50) il processo di ordinamento diventa lungo e oneroso per gli utenti. Tuttavia non vi sono dei chiari limiti in letteratura. Si tratta di indicazioni empiriche.

Se si parte da un elenco molto numeroso, può dunque essere utile utilizzare soltanto i primi 50 contenuti. In quel caso è necessario procedere ad un ordinamento di importanza.

E cos‘è l’ordinamento di importanza?

L’ordinamento di importanza è un metodo con il quale si chiede a degli utenti di dare un giudizio di importanza (su una scala a intervalli di tipo Likert, da 1 a 5 o da 1 a 7) a ciascuno degli argomenti della lista. I giudizi degli utenti vengono sommati per ogni elemento e i primi 50 elementi per ordine di importanza vengono utilizzati per l’ordinamento finale.

L’ordinamento si fa in sessioni singole o collettive?

Ogni utente deve ordinare da solo i contenuti, ma niente vieta di ospitare più utenti contemporaneamente, su tavoli diversi.

A mano non è una cosa lunga?

Abbastanza. Soprattutto è abbastanza lungo l’inserimento dei dati nel computer per le analisi statistiche. Esistono perciò anche dei software che consentono di automatizzare le operazioni di ordinamento con un’interfaccia grafica, di registrare automaticamente i raggruppamenti e le etichette assegnate ad ogni gruppo dagli utenti e infine di compiere alcune analisi.

Come si fa a trattare poi i dati?

Bisognerebbe riportare in una matrice i gruppi creati e associare ad ogni cartoncino il gruppo in cui è stato inserito per ogni utente.
Un altro modo per trattare i dati è creare matrici di similarità. In sostanza, si considera quante volte a ogni cartoncino è stato inserito in uno stesso gruppo dai diversi utenti. Se due cartoncini sono stati sempre classificati insieme da tutti gli utenti, la loro somiglianza sarà del 100%.

Al contrario, la matrice di dissimilarità assegna valore 0 a elementi molto simili, e valore 1 a elementi molto differenti.

A partire dalla matrice di dissimilarità o di similarità si possono compiere diverse analisi. La più diffusa è l’analisi dei cluster gerarchica (a partire dalla matrice di dissimilarità), ma si possono usare altre tecniche di analisi multivariata che mirano ad estrarre dei fattori comuni latenti che spiegano la variabilità di ordinamento dei cartoncini, cioè i gruppi. Molte tecniche non tengono conto delle etichette creati per i gruppi dai vari utenti, ma creano gruppi simili di oggetti a cui poi lo sperimentatore deve assegnare un nome.

E i titoli che vengono assegnati dagli utenti ai diversi gruppi?

Possono venir utilizzati per analisi ulteriori o per una valutazione esperta. Ad esempio, Donna Maurer, un’esperta di card sorting e autrice (assieme a Todd Warfel) di un ottimo articolo in materia, consiglia di operare una cosiddetta standardizzazione delle categorie. Cioè, può darsi che a gruppi molto simili (che contengono cioè le stesse carte) due utenti diversi abbiano dato nomi differenti. Ma nell’analisi finale queste due classificazioni potrebbero essere sostituite da un’unica etichetta. Questa etichetta potrebbe poi essere usata in un’analisi successiva.

Tuttavia, ancora più interessante è il metodo chiamato label analysis e implementato/ideato da Jorge Toro per il software CardZort. In pratica, per ogni gruppo ottenuto con la cluster analysis, il software presenta una serie di etichette con una percentuale che rappresenta quanto quell’etichetta sia coerente con quel gruppo di voci. In pratica, se nel gruppo che stiamo esaminando tutte le voci sono state etichettate in quel modo, l’adeguatezza è del 100%. Altre voci possono essere associate al gruppo con coerenza minore. Spetta poi al ricercatore giudicare le diverse etichette usate per quelle voci e scegliere una sintesi adeguata che rappresenti al meglio il gruppo.

Ho sentito parlare di card sorting aperto e chiuso. Di che si tratta?

  • Nel card sorting aperto caso l’utente è libero di classificare le voci in quanti gruppi ritiene opportuno ed etichettarli a piacere. Così otteniamo informazioni sulle rappresentazioni mentali “spontanee” dell’utente.
  • Nel card sorting chiuso l’utente è chiamato a inserire le voci in alcune categorie prestabilite. Spesso si legge che questo metodo consente non di creare la classificazione ma di verificarne (o validarne) una esistente. Tuttavia Donna Maurer sottolinea che l’unica cosa che consente di verificare una classificazione esistente è chiedere a degli utenti di trovare cose usando quella classificazione e che dunque il card sorting chiuso sarebbe inutile. O meglio, servirebbe solo quando l’obiettivo è costruire una classificazione il cui scopo sarebbe quello di supportare dei compiti di classificazione. Ad esempio: dove inserirebbero la propria pagina alcuni autori di un’intranet?

Quando va eseguito il card sorting durante la progettazione di un sito?

Va eseguito prima della definizione dell’architettura informativa o degli schemi di navigazione del sito durante il processo di design.

Come si possono leggere e visualizzare i risultati? Non dovrò mica leggere matrici con numeri in percentuale?

Volendo sì. Altrimenti si possono usare dei grafici ad albero (dendrogrammi), o delle heat map.

esempio di grafico ad albero prodotto da un card sorting
Nell’immagine un esempio di dendrogramma derivato da un card sorting sugli articoli di questo sito. A seconda della soglia di correlazione scelta (riga rossa nell’immagine) vengono formati gruppi di articoli più o meno somiglianti, rappresentati dalle strisce colorate orizzontali

Nei dendrogrammi normalmente è possibile decidere una o più soglie di correlazione fra le voci, e determinare così dei gruppi, che sarebbero diversi se cambiassimo la soglia di correlazione. Meno sono somiglianti i gruppi, meno essi saranno numerosi e composti da un maggior numero di voci, e viceversa.

La scelta della soglia di correlazione spesso è oggetto di prove e di errori.

Che fare con i cartoncini che non possono essere classificati o che non risultano appartenere ad alcun gruppo?

Il mio consiglio è di non associarli fra loro: si tratta di voci singole, particolari, da mantenere isolate dal resto. Talvolta significa che quelle voci sono di natura diversa dal resto del corpus. Se si sta costruendo uno schema di navigazione, allora queste voci andrebbero fatte emergere a parte.

Cosa si può fare con i risultati del card sorting?

Spesso si dice che i risultati servono a definire l’architettura informativa o il sistema di navigazione. Ma questi due concetti non sono sovrapponibili.
L’architettura dell’informazione è il modo in cui il sito stabilisce delle relazioni fra i contenuti. Queste relazioni possono anche essere latenti, per esempio rappresentate con metadati invisibili all’utente (ma sensati per altri scopi).

Il sistema di navigazione invece è l’elenco delle voci che compongono uno o più menu di un sito. Un menu non corrisponde necessariamente all’albero o alla struttura di un sito. Ad esempio, un sito può essere organizzato per tipologie (saggi, articoli, interviste, recensioni), e una categorizzazione per argomenti può attraversare tutte le tipologie. Una categorizzazione per faccette per esempio non si sovrappone mai alla struttura logica del sito.
Struttura, categorizzazione e navigazione non sono la stessa cosa. Così non lo è l’architettura.

Il card sorting può aiutare ad esplorare o definire uno o più di questi strumenti concettuali. Può cioè essere usato per capire un modo latente di assegnare metadati ai contenuti, o per definire un menu di navigazione, o una struttura logica. Dipende dal progetto. L’importante è essere consapevoli dello scopo.

Inoltre il card sorting raramente può venir automaticamente tradotto in una qualsiasi delle strutture concettuali appena citate. Spesso l’output di un card sorting deve venir analizzato e adattato da un ricercatore, ma è un punto di partenza più vicino al mondo mentale dell’utente di quello che si otterrebbe facendo decidere agli esperti.

Quanti utenti sono necessari per ottenere risultati affidabili?

Secondo una ricerca1 del 2004, con 30 utenti si ottengono risultati affidabili al 95%. Nielsen consiglia 15 utenti per i progetti più comuni, che portano ad un’affidabilità del 90%, più che sufficiente. Non è stata però esplorata la relazione fra il numero di cartoncini e il numero di utenti.

Ma il card sorting funziona davvero?

Dipende. Devono essere rispettati alcuni criteri. In particolare, gli utenti devono capire il significato delle voci, e dovrebbero essere capaci di esplicitare i loro criteri di classificazione. Ci sono casi in cui questo si verifica e altri no. Meglio gli utenti conoscono un argomento, più è probabile che i requisiti siano rispettati. In ogni caso, usare un metodo come questo, empirico, consente anche di esplorare eventuali problemi legati al contenuto e al modo in cui gli utenti lo vedono, perciò è spesso consigliato, soprattutto se si hanno facilmente a disposizione gli utenti come nel caso di intranet o di applicazioni a dominio controllato o chiuso: call center, sistemi di faq, ecc. In questi ultimi casi, è particolarmente importante che lo schema di categorizzazione corrisponda al mondo mentale degli utenti, visto che dovranno quotidianamente lavorarci.

In quali progetti è meglio usare il card sorting?

Io li ho trovati particolarmente utili nella progettazione di ambienti chiusi, come intranet o call center che si appoggino a basi di dati da sfogliare, come detto. Ma anche in ambienti dai domini complessi per cui non esiste un metodo di classificazione condiviso.

Può essere utile anche per valutare distanze fra categorizzazioni esistenti e categorizzazioni dal basso, cioè costruite dagli utenti.

Inoltre di particolare utilità è usare il metodo per valutare quanto sono disperse queste classificazioni fra diversi utenti, o, in alternativa, quali singole voci sono più disperse. In pratica, di quali voci gli utenti fatichino a dare una collocazione univoca. Questo dà indicazioni utili su possibili criteri alternativi (ad esempio, uso di faccette) nella classificazione di alcuni elementi del corpo dei contenuti.

Quanto costa fare un card sorting?

Be’, dipende. Tenete conto che i costi principali sono quelli del reclutamento degli utenti e il tempo perso a condurre le sessioni di ordinamento. Poi, se dovete inserire i dati a mano nel computer, i tempi si allungano ancora. Ma se utilizzate dei software fin dall’inizio (questa ricerca di Bussolon, Del Missier e Russi, 108KB, in pdf, indica che c‘è un buon grado di somiglianza fra i due metodi), i tempi si accorciano molto. Il tempo per l’analisi dei dati dipende più che altro dalla vostra familiarità con il metodo.

Piuttosto che dare cifre, è bene dire che in un tempo che va dai 2 ai 5 giorni è normalmente possibile concludere un card sorting. I tempi possono naturalmente allungarsi in casi particolari, e spesso le giornate non riescono ad essere consecutive, il che complica sia la pianificazione che il budget. Ma questo si può dire praticamente di qualunque attività progettuale…

Quali software esistono per eseguire più rapidamente il card sorting?

Molti, come si può vedere da alcune risorse disponibili in rete. Esistono anche tool online, come websort o netsorting dell’italiano Stefano Bussolon (che li ha usati per progetti specifici descritti anche nel sito). Fra i tool da scrivania, invece, esiste un tool sviluppato da IBM e che è probabilmente il più famoso, EZSort. Però ha alcuni bachi (ogni tanto si chiude improvvisamente) e limiti nel numero di cartoncini. Ma, soprattutto, non è più supportato. Ne è ancora disponibile una copia su webarchive.

Qui parlo di quelli che ho usato più di recente e che secondo me sono i migliori per il mondo Mac e per il mondo Windows.

Per il mondo Windows: CardZort

Attualmente per Windows il migliore (sebbene non esente da bachi e piccoli problemi che possono anche diventare fastidiosi, specie nei primi utilizzi) è probabilmente CardZort, un tool a pagamento (150 dollari per computer) scritto da Jorge Toro per la sua tesi di dottorato e che però soffre di una tipologia di licenza molto vincolante (legata alla macchina: se cambiate computer perdete il programma!…). Consente una facile costruzione del set e un’agile esecuzione da parte degli utenti, anche se non offre la possibilità di creare sottogruppi.

Il pregio maggiore è probabilmente il fatto di essere l’unico software attualmente noto a compiere anche la label analysis, secondo un algoritmo ideato dallo stesso autore, che fornisce indicazioni di grande utilità per una prima valutazione dei termini usati dagli utenti.

Per il mondo Mac: xSort

Per il mondo Mac è molto convincente (e di usabilità nettamente superiore a tutti gli altri) xSort, un tool anch’esso a pagamento sviluppato da iPragma (licenze convenienti, a partire da 29 euro aggiunta di ottobre 2008: il software è ora gratuito!) che consente la creazione di veri e propri set sperimentali, con definizione di gruppi di utenti (in modo da analizzare rapidamente le differenze di classificazione, poniamo, fra maschi e femmine, o fra giovani e anziani), la possibilità di creare tramite drag & drop quanti gruppi si vuole e organizzarli anche in sottogruppi. Interessante anche la possibilità di generare in automatico sia analisi che report multipli (questi ultimi però solo in inglese). Se includesse anche una funzione per la label analysis sarebbe un tool perfetto.

Se usati da operatori esperti, questi strumenti automatizzano il lavoro e consentono di compiere analisi e confronti molto rapidamente, ma sono divertenti anche per i principianti, perché consentono di sperimentare la tecnica. Sarebbe però utile un tool che unisse i pregi di entrambi quelli citati. Attualmente dovete invece decidere quale operazione vi serve di più e usare il tool più appropriato, a meno di non convertire i dati (xSort ha una feature di importazione di dati in XML, ma cardZort usa un formato diverso, perciò dovrete lavorarci a mano o scrivere un’utility di conversione).

E se volessi analizzare i dati a mano?

È possibile farlo, ma è bene conoscere alcune basi statistiche che riguardano la correlazione fra variabili nominali. Joe Lamantia ha predisposto un file excel, con un articolo di istruzioni sull’uso. Donna Maurer ne ha proposto un’altro. Il metodo è comunque un po’ macchinoso e a mio parere suscettibile di errori, proprio a causa dell’inserimento manuale ripetuto. Personalmente lo consiglio solo ad esperti che vogliono compiere analisi raffinate.
Per gli altri, è meglio forse usare un software fra quelli disponibili, che generano facilmente dei dendrogrammi, i grafici che consentono di comunicare meglio i risultati anche al management.

Alcuni link utili

1 Tullis, T., and Wood, L. (2004), “How Many Users Are Enough for a Card-Sorting Study?” Proceedings UPA’2004 (Minneapolis, MN, June 7-11, 2004). ^

Cos’è lo User-Centered Design (UCD)

Lo User Centered Design (UCD) è un modo per progettare e costruire siti o applicazioni tenendo conto del punto di vista e delle esigenze dell’utente. Lo UCD è un processo composto di più attività. Si basa sull’iterazione di diversi strumenti di analisi od osservazione, progettazione e verifica. In italiano questo processo è noto anche come “Progettazione Centrata sull’Utente”.

Il processo è stato definito e descritto da diversi autori e persino da alcune norme ISO, come la 13407, Human-centered design process. Diverse fonti descrivono processi leggermente diversi, ma guidati dalla stessa filosofia: fondare il progetto sulle esigenze degli utenti.

La ISO 13407

Questa norma ISO stabilisce quattro attività principali per il processo di UCD:

  1. Specificare il contesto d’uso
  2. Specificare i requisiti
  3. Creare delle soluzioni progettuali
  4. Valutare il design

Solo quando le soluzioni progettuali rispecchiano i requisiti, allora il prodotto può essere rilasciato e pienamente realizzato.

Appare evidente l’importanza che viene data a ben due fasi di analisi prima della creazione effettiva di soluzioni progettuali. Il contesto d’uso è necessario per identificare quali persone useranno il prodotto, cosa ci faranno e in quali condizioni lo useranno.

I requisiti si concentrano a questo punto sia sui compiti che gli utenti dovranno portare a termine che sugli eventuali obiettivi di business.
Solo a questo punto il prodotto può iniziare a essere pensato e progettato, in forma di prospetto, schema, prototipo, fino ad un modello completo.

Ma il passo davvero fondamentale è l’ultimo, ovvero la verifica del prodotto, in particolare con utenti reali attraverso i test di usabilità, anche se non solo: interviste, questionari, analisi ispettive e secondo linee guida possono altresì essere utili.

Gli strumenti

Nelle diverse fasi del ciclo di progetto vengono portate avanti diverse attività con diversi strumenti.

Nella fase di analisi (1 e 2) tipicamente si compiono le seguenti attività:

  1. Incontri con gli stakeholder (portatori di interessi) per capire vincoli e aspettative
  2. Analizzare i prodotti esistenti
  3. Conduzione di osservazioni sul campo
  4. Conduzione di interviste con potenziali utenti
  5. Conduzione di workshop con potenziali utenti
  6. Questionari
  7. Creazione di profili di utente
  8. Creazione di elenchi di compiti
  9. Creazione di scenari
  10. Definizione di team multidisciplinari

Aggiungo che è bene fin dall’inizio creare dei modi agili per comunicare fra i diversi componenti dello staff, e non rigidi e immodificabili. In un lavoro di UCD non dovrebbero esistere membri del gruppo di lavoro che decidono indipendentemente dalle opinioni altrui.

Nella fase in cui si lavora alla creazione di soluzioni progettuali si usano i seguenti strumenti:

  1. Brainstorming, riunioni e discussioni libere
  2. Creazione di modelli e schemi di navigazione
  3. Creazione di bozzetti e schermate, anche carta e matita
  4. Conduzione di analisi e simulazioni cognitive sui bozzetti
  5. Creazione di prototipi a bassa o alta fedeltà

Si può notare che accanto ad attività più propriamente progettuali (che comprendono il disegno dell’interfaccia con vari strumenti) si inizia già a condurre delle valutazioni e delle analisi sulla base dei documenti predisposti nella prima fase (scenari, compiti)

La valutazione avviene prima e durante l’implementazione vera e propria del sistema, attraverso:

  1. Test con utenti
  2. Questionari
  3. Analisi euristiche e ispettive
  4. Simulazioni cognitive

Alla fine il prodotto viene corretto e implementato con:

  1. La modifica del sistema
  2. La realizzazione definitiva di Html, css, grafica e programmazione

La fase di valutazione idealmente non finisce qui, perché si possono mettere a punto fasi di monitoraggio del sito o del software, grazie a:

  1. Meccanismi di segnalazione di problemi
  2. Questionari
  3. Studi sul campo
  4. Ulteriori test di usabilità per controllare gli obiettivi.

In definitiva, lo UCD è sia una filosofia che un processo che adottano una serie variabile e sufficientemente flessibile di strumenti.

Giova ricordare che tutti i prodotti vengono realizzati secondo un qualche processo. Questo può essere casuale o molto formalizzato. Attività di UCD possono essere inserite sia nell’uno che nell’altro caso, ma molto spesso non lo sono.

Perché lo UCD è raro?

Perché in Italia, ma anche in buona parte del mondo, i processi aziendali non vengono orientati alle esigenze dell’utente, con attività specifiche come quelle elencate qui sopra, anziché solo a parole? Per almeno 2 ragioni:

  1. Perché lo UCD è una filosofia relativamente giovane e poco insegnata. Non è il modo di gestire tradizionalmente il processo di realizzazione di software e di siti. Non è il modo in cui funzionano le software house in Italia, ed è un metodo che capi-progetto e manager non sanno bene come gestire
  2. Perché viene visto come un costo. Al contrario, vi sono stime che indicano che i processi UCD beneficiano di una rapida focalizzazione sui requisiti e le soluzioni giuste, evitano allungamenti di tempi legati a imposizioni o discussioni improduttive, e portano ad un prodotto soddisfacente in un tempo minore (Landauer, 19961)

Inserire lo UCD nel processo di progettazione richiede un cambio di mentalità e di procedure nelle aziende, che le renda più flessibili. Questo è abbastanza difficile in aziende grosse, perché, proprio come McDonald ha bisogno di standardizzare le procedure per produrre panini di identica qualità media, le grandi aziende hanno bisogno di standardizzare molto i processi per produrre software e siti di qualità standard qualunque sia la formazione e il grado di competenza dei dipendenti.

Tuttavia adottare l’UCD aiuta anche le aziende grosse a evolversi e a mettere in discussione le proprie rigidità.

Formazione

E’ urgente inserire lo UCD nelle scuole e nei corsi di webdesign. Negli anni 90 partecipai a corsi che non menzionavano in alcun modo queste attività. Negli anni 2000 ho insegnato in vari corsi che menzionavano tutt’al più l’usabilità. Lo UCD è più dell’usabilità: è l’applicazione di una filosofia tutta centrata e rivolta a identificare i bisogni dell’utente, nel rispetto di quelli di business.

Si fonda sulla credenza che sia possibile identificare i bisogni e i difetti di un prodotto attraverso l’analisi e il test. E che le evoluzioni siano misurabili. Richiede un cambio di mentalità verso la trasparenza e la chiarezza: le attività di test condotte durante il processo testimoniano l’evoluzione del prodotto e possono essere usate per vincere le resistenze di alcuni decisori.

Diversi autori hanno fatto evolvere il bagaglio di strumenti utilizzabile dentro procedure di UCD. Fra questi ricordiamo Alan Cooper, che ha ridefinito e migliorato il concetto di scenario e di personaggi (personae o personas).

UCD e accessibilità

La legge italiana sull’accessibilità cita una metodologia progettuale durante la quale dovrebbero essere effettuate alcune valutazioni che dovrebbero portare alla cosiddetta valutazione soggettiva. La metodologia indicata, identificata da un gruppo di lavoro diretto da Sebastiano Bagnara, uno dei pionieri dell’ergonomia in Italia, è né più né meno che un’applicazione dello UCD.
Questo sarebbe il modo giusto di progettare siti non solo tecnicamente accessibili, ma adeguati ai bisogni informativi e d’uso degli utenti, anche disabili. Anche all’estero si inizia a capire che l’accessibilità può esistere solo all’interno di una procedura di UCD.

Purtroppo, nonostante le iniziali speranze, questa legge ha marginalizzato questa procedura, rendendola non obbligatoria. Non solo: un recente chiarimento del CNIPA ha specificato che la valutazione soggettiva addirittura non deve essere fatta per i siti pubblici, con argomenti di difficile comprensione. Non ha speso una parola per sostenere l’applicazione di procedure di UCD nella progettazione di siti pubblici, sprecando così l’occasione di un salto storico nella mentalità progettuale dei siti pubblici.

Noi non perdiamo la speranza e sosteniamo che quella indicata nella metodologia sia la giusta procedura di progettazione dei siti, e auspichiamo che successive modifiche della legge, o successivi e più ponderati chiarimenti del Cnipa restituiscano a questa procedura la centralità necessaria.

Modi per orientare la vostra azienda allo UCD

E’ essenziale formare l’azienda alle procedure di UCD. Queste attività devono essere condivise non solo dagli esecutori (grafici, progettisti, programmatori), ma dai vertici dell’azienda, senza il contributo dei quali agli esecutori arriveranno sempre indicazioni contraddittorie. Per questa ragione le attività che hanno dimostrato di funzionare nel cambiare l’attitudine di un’azienda verso l’UCD sono le seguenti:

  1. Incontri e workshop sul design centrato sull’utente con i diversi stakeholder: manager, dipendenti, eventuali politici di riferimento
  2. Formazione specifica su specifici strumenti di UCD
  3. Richiami periodici di verifica e risoluzione dei problemi

Potere contattarci per avere ulteriori informazioni circa queste attività. Ed è bello notare che anche altre realtà in Italia stanno lavorando per sostenere l’UCD: è il segno che qualcosa si sta muovendo e che tutti assieme possiamo raggiungere l’obiettivo di avere un web moderno, progettato attorno alle esigenze delle persone che lo useranno e non dei progettisti.

Altre risorse:

1 Landauer, Thomas K. “The Trouble with Computers”, MIT Press, Cambridge, 1996 ^

Il design della navigazione

Lo scopo principale degli strumenti di navigazione di un sito, come
abbiamo visto, è quello di fornire all’utente indicazioni su
dove è e su dove può andare. Devono poter contenere informazioni
anche sui contenuti: ‘dove posso andare’ significa infatti ‘verso quali
contenuti/servizi posso andare’. Gli strumenti di navigazione devono
quindi farsi carico di compiti di comunicazione di struttura, contenuti
e funzionalità del sito, in maniera completa e al tempo stesso
flessibile. Vediamo attraverso quali passaggi è possibile ottenere
questi risultati. Al termine verificheremo i vantaggi pratici di un
piano di navigazione ben riuscito con un esempio reale.

Il primo passo: decidere la struttura.

Alla base di ogni scelta di navigazione vi sono accurate decisioni
che riguardano l’architettura delle informazioni, ovvero il modo in
cui avete deciso di suddividere logicamente le informazioni del vostro
sito. L’architettura informativa dà l’indispensabile struttura
al vostro sito, ed è di vitale importanza riflettere bene su
questo aspetto perché inciderà pesantemente su tutte le
scelte successive.

Non vogliamo riassumere in un breve articolo i metodi necessari ad
una buona progettazione dell’architettura informativa. Ci limitiamo
a descriverne uno dei più diffusi: il card sorting.

Secondo questa tecnica, ogni voce o unità informativa che si
intende comprendere nel sito andrà scritta su un cartoncino o
un foglietto, utilizzando una descrizione verbale semplice e significativa
per l’utente finale. Una semplice trasposizione delle attività
aziendali in gergo manageriale può non essere una buona idea,
perché il vostro utente potrebbe non avere le competenze adatte
per capire di che si tratta.

Una volta descritti tutti i contenuti sui diversi cartoncini, bisogna
dare ordine al caos. In una parola: raggruppare le voci. Il card sorting
prevede che questa attività di raggruppamento venga svolta da
diversi soggetti rappresentativi dalla vostra "utenza-tipo".
In realtà è più frequente che venga svolta da colleghi
o da persone di più facile reperimento… Chiedendo agli utenti
di raggruppare e denominare i contenuti nella maniera per loro più
significativa, comunque, vi assicurerete di evitare errori dovuti ad
una visione troppo centrata sulla vostra azienda o sui processi di management,
che solitamente sono troppo specialistici per l’utenza media.

Il vantaggio di utilizzare diversi soggetti tratti dall’utenza reale
è quello di verificare se il criterio di raggruppamento utilizzato
sia comune e condiviso. In caso affermativo, è molto probabile
che quello sia il criterio migliore per la vostra utenza.
In caso di difformità, invece, dovrete chiedervi a cosa possano
essere dovute. Forse i soggetti sono troppo disomogenei fra loro, o
forse i foglietti presentano nomi di difficile comprensione. In tal
caso, dovrete rivedere il processo, meglio se con l’ausilio di un professionista.

Qualunque tecnica utilizziate, è bene non sottovalutare questa
fase, perché un errore a questo punto del processo si rifletterebbe
negativamente sul prodotto finito, che sarà molto più
costoso correggere.

I problemi del labeling

Una volta trovati i criteri di raggruppamento del materiale che comporrà
il vostro sito, trovate i nomi giusti per indicare i diversi gruppi.
Anche siti che hanno una navigazione elementare possono presentare problemi
di labeling. Ad esempio, per la sezione di Usabile che elenca tutti
gli articoli pubblicati, voi quale voce scegliereste? Indice, Archivio,
Articoli, Elenco, o altro ancora?… L’indice può sembrare l’indice
del sito, l’archivio qualcosa che raccoglie documenti imprecisati, articoli
in italiano può richiamare articoli in vendita, mentre elenco
è decisamente generico…

Vogliamo fare un po’ i pignoli, ma non troppo: non sono rari i siti
ricchi di contenuti interessanti che utilizzano label (etichette verbali)
fantasiose ma ben poco significative per l’utente, che quindi non capisce
assolutamente dove cercare le cose che più lo interessano. Ponete
dunque l’adeguata attenzione a questa fase.

Se il raggruppamento è stato condotto appropriatamente, vi troverete
con alcune categorie concettuali di navigazione chiare e coese. Tipicamente,
potrebbero essere:

  • Categorie nelle quali sono suddivisi i contenuti o i prodotti (ad
    esempio: libri, cd, dvd, software, ecc…)
  • Elementi di community (forum, mailing list, newsletter, caselle e-mail,
    aree riservate)
  • Features del sito (helps, tour guidati, mappe del sito, contatti)

Tenete presente che in alcuni casi potreste aver bisogno di spazio
per una navigazione locale o secondaria: ad esempio, in una categoria
dei prodotti potreste trovar utile inserire ulteriori suddivisioni;
o ancora, potresete dover presentare informazioni accessorie e contestuali.
Accertatevi di prevedere nel layout finale lo spazio relativo.

Stabilire delle gerarchie

A questo punto inizia il processo di gerarchizzazione. Dovete decidere
quale di questi gruppi di link è più importante. In alcuni
casi è possibile che non riusciate a scegliere: ad esempio in
siti molto compositi come quelli delle pubbliche amministrazioni, o
in siti che si sono sviluppati in maniera disomogena nel tempo: volendo
dare importanza a tutto, finite per far competere gli elementi nel catturare
l’attenzione del visitatore. Ricordate: l’attenzione è una risorsa
limitata!

Se non ce la fate a stabilire delle chiare gerarchie, forse è
il segnale che dovete ripetere il processo di raggruppamento e categorizzazione
delle voci. Utilizzate altri criteri: da quello oggettuale a quello
funzionale, per esempio. Invece di elencare i tipi di prodotti, elencate
le possibili azioni che gli utenti possono voler fare. In pratica, se
utilizzando i nomi (es: alberghi, ristoranti, agriturismi, farmacie,
ospedali) non ottenete un risultato sintetico, attraverso una diversa
categorizzazione potreste migliorare notevolmente la vostra navigazione
(es. ospitalità, sanità, ecc.). In questa come in tutte
le fasi, la cosa migliore è chiedersi di cosa può aver
bisogno un utente reale visitando il nostro sito: orientate la navigazione
in maniera che sia un ausilio per le scelte d’azione dell’utente, piuttosto
che perché sia onnicomprensiva dell’azienda o dell’ente. Un sito
non è una brochure: non è fatto per essere guardato, ma
utilizzato con scopi precisi. Solo se non vi è niente che sia
possibile fare sul sito, un approccio ‘da guardare’ può essere
quello più adeguato.

I gruppi di voci istituzionali (relativi all’azienda o al ‘chi siamo’)
dovrebbero essere ben distinti da quelli relativi alle offerte o alla
struttura informativa. Il che non impedisce una certa ridondanza: è
possibile che vi sia un indice complessivo dei prodotti in un gruppo
di navigazione, e un elenco delle diverse categorie di prodotti a costituire
un altro gruppo. Fornire più vie d’accesso ai contenuti è
normalmente un aiuto per l’utente, a patto che i criteri delle diverse
categorizzazioni siano ben distinti e non si possano confondere.
Detto in maniera più semplice: non dovrebbero esserci due voci
possibili per la stessa azione, ma solo due voci per arrivare allo stesso
punto attravero azioni ed intenzioni differenti. Consultare un
indice è ben diverso dal cercare all’interno di una precisa categoria
dei prodotti, ma in entrambi i modi posso giungere al prodotto.

Tuttavia il percorso logico che indicherà la strada delle varie
pagine rimarrà sempre lo stesso (non si modificherà a
seconda della via d’accesso). Infatti il path, o ‘percorso a briciole
di pane’ indica il posizionamento logico del file nella struttura
complessiva: non la strada che l’utente ha fisicamente seguito per
arrivarci.

Strumenti di organizzazione visuale

Comunque venga scelta, la gerarchia dev’essere rappresentata in maniera
visualmente significativa: non lasciate che gruppi di navigazione diversi
competano fra di loro. Gli strumenti visuali che avete a disposizione
sono potenti e ben codificati. In generale interventite su: dimensioni,
forme, posizionamento relativo e colori. Ma il colore dovrebbe essere
l’ultima ratio, un mero elemento di stile: il vostro layout dovrebbe
funzionare anche in grigio, solo con il posizionamento relativo e l’aspetto
delle voci e dei gruppi. Vi sono regole di organizzazione percettiva
che ogni buon grafico dovrebbe conoscere, e che non è questa
la sede per illustrare. Le più importanti comunque sono:

  1. Vicinanza: è il primo criterio di raggruppamento figurale:
    voci vicine sono percepite come un’unità. Attenzione però:
    le voci non dovrebbero essere così vicine da creare difficoltà
    nell’atto di cliccare! E’ bene rinunciare in parte al concetto di vicinanza,
    piuttosto che creare menu con voci talmente piccole e fitte che richiedano
    molta attenzione per essere correttamente selezionate. L’utenza media
    non è così abile nel manovrare il mouse, e spesso neanche
    l’utenza esperta…
  2. Somiglianza: voci dall’aspetto simile sono più facilmente
    percepite come un gruppo. Pertanto le voci dello stesso gruppo dovrebbero
    avere un aspetto simile. Evitare se possibile voci troppo più
    lunghe delle altre e disposte magari su due righe: contrastano l’effetto
    di somiglianza.

Altre regole di organizzazione percettiva vi saranno certamente suggerite
da un buon grafico web.Guardate il vostro layout: la gerarchia è
chiara? Ci sono elementi che competono fra loro per rilevanza visuale?
Che creano ‘rumore di fondo’ ostacolando la leggibilità? La loro
eliminazione passa per un buon design della navigazione, a cui l’usabilità
e le regole di organizzazione figurale possono offrire un contributo
realmente decisivo.

Un esempio: Adobe.com

Un progetto di navigazione particolarmente ben riuscito è il
redesign (risalente alla scorsa estate) del sito www.adobe.com,
opera di Hillman
Curtis, un noto Flash designer che però dimostra di essere
prima di tutto un designer tout-court. Il lavoro è tanto più
significativo se consideriamo che non è stato modificato il precedente
layout (presumibilmente per non disorientare gli utenti abituali, oltre
che perché, oggettivamente, non se ne evidenziava la necessità).
La pagina si presenta così organizzata:

Esame della home page di adobe.com, con diverse sezioni evidenziate

Notiamo come la software house dedicata alle soluzioni per la grafica
professionale abbia individuato dei sistemi logicamente e visivamente
ben distinti per il proprio sistema di navigazione.

Accanto al logo, nella barra nera che sovrasta le pagine, vi sono due
gruppi di navigazione distinti senza orpelli grafici (cornici, fondini),
ma con il solo variare dei rapporti di vicinanza fra le voci. Vi è
anche una variazione di colore, ma è ridondante: non necessaria
per la comprensione. Il primo gruppo presenta quella che potremmo chiamare
la navigazione principale, istituzionale, costituita da sole 4 voci:
store, products, support e corporate. Queste 4 voci consentono un efficace
instradamento degli utenti sulla base delle categorie concettuali di
informazione cui sono interessati.

Il secondo gruppo consiste in tre voci (due nella versione italiana,
che non presenta la traduzione di Adobe Studio, una sezione del sito
dedicata a consigli d’uso per gli utenti dei propri prodotti, una specie
di magazine con compiti di community) che non sono altro che facilities
del sito: Adobe Studio, ricerca e contatti. In un sito ampio e complesso
come quello della Adobe, la funzione di ricerca testuale è particolarmente
importante per tutti gli utenti che abbiano esigenze molto specifiche.
Da notare che, a differenza del gruppo precedente, in questo secondo
gruppo di navigazione le voci sono divise da una barra verticale ( "|"
). Un vezzo?

Tutt’altro. Si tratta di una scelta funzionale, resasi necessaria proprio
per la presenza della voce "Adobe Studio": si tratta dell’unica
etichetta verbale composta di due parole! Per raggruppare le due parole
in maniera che non sembrassero due link ma uno solo, si è scelta
la barra verticale come spaziatore, dato che la sola vicinanza poteva
in questo caso indurre delle ambiguità.

La parte centrale della pagina è dedicata alle notizie, alle
offerte, alle ultime release. Notiamo ancora all’opera il principio
di vicinanza nel rapporto fra le immagini rotonde e il testo relativo.
Non si fa uso di altri espedienti per il raggruppamento delle informazioni.
Nessuna cornice, nessun fondino colorato (a parte quello che domina
l’intera pagina, e che rafforza la coerenza visiva dell’insieme). Eppure
non vi sono difficoltà nell’attribuire ogni testo alla relativa
immagine.

Sulla destra, infine, un’ulteriore lista di voci categoriali, che rappresentano
le categorie di prodotti: per il web design, per la stampa, l’animazione,
ecc. In questo modo si presume una segmentazione degli interessi dell’utenza
all’interno del più generale interesse per la grafica. Invece
di scegliere la voce ‘prodotti’ nella barra orizzontale, si consente
a chiunque di approfondire la sezione che più gli interessa.
Inoltre viene sdoppiata la voce Adobe Store (già presente nella
navigazione principale): un chiaro segnale che si tratta di una sezione
che sta particolarmente a cuore alla Adobe.

A parte questo sdoppiamento, è da notare che le strade per raggiungere
le informazioni sono logicamente diverso nelle tre sezioni di navigazione:
secondo una rigida struttura ad albero nel primo caso, secondo una modalità
di ricerca testuale nel secondo, attraverso il tipo di prodotto nel
terzo. In più, le novità sono sempre adeguatamente segnalate
nella parte centrale della pagina.

Questo sistema è significativo per molti motivi, fra i quali
sottolineiamo i seguenti:

  1. Economia visiva: non vi sono orpelli inutili
  2. Completezza: tutto è catalogato e raggiungibile in qualche
    modo
  3. Ridondanza: vi sono diversi possibili modi di accedere alle stesse
    informazioni

L’apparente semplicità del sito Adobe è il risultato
di un attento design della navigazione, che poggia su un’accorta profilazione
degli utenti e su una solida architettura informativa, pur essendo il
sito composto di svariate centinaia di pagine. L’utilizzo di espedienti
di raggruppamento figurale è messo al servizio di una struttura
logica, economica, efficace ed efficiente, senza trascurare uno stile
figurativo elegante e sintetico, perfettamente funzionale agli scopi
del sito.

Non è tutto oro…

Il sito della Adobe presenta tuttavia alcuni problemi minori di usabilità
(non di design) che potrebbero essere risolti per migliorare definitivamente
l’interfaccia. Vediamoli in dettaglio:

  1. La tagline (lo slogan che accompagna il logo e che serve per definire
    l’azienda) è: "Everywhere You Look" (ovunque guardi:
    è un chiaro riferimento alla fornitura di strumenti per la creazione
    di qualunque tipo di prodotto visuale). E’ un ottimo slogan pubblicitario,
    ma non spiega di che si occupa l’azienda a chi non la conosce già.
    E’ probabile che il target Adobe non risenta di questa carenza, ma si
    tratta tuttavia di un aspetto che potrebbe forse essere rivisto.
  2. Le scritte della navigazione sono costituite da immagini gif! Tale
    discutibile pratica è una consuetudine deprecabile dello stesso
    Hillman Curtis, che la utilizza anche per il suo sito (e la porta addirittura
    allo spasimo: là tutti i testi sono immagini!…), forse perché
    riesce a ottimizzare le gif in maniera da ottenere immagini meno pesanti
    del corrispondente codice. Più probabilmente, il motivo è
    da ricercare nel maggior controllo sulla visualizzazione. Ma su web
    bisognerebbe tenere separati contenuto e visualizzazione! Se l’utilizzo
    di immagini per il testo può essere considerato accettabile nel
    caso di titoli che abbiano una particolare cura estetica impossibile
    da riprodurre via html (e, per quanto riguarda l’antialiasing, anche
    via css), non è spiegabile quando imitano proprio i testi html
    come in questo caso! Infatti le voci di menu su campo nero potrebbero
    essere fissate attraverso i css, garantendo maggior accessibilità
    e maggior standardizzazione del codice attraverso una separazione fra
    forma e contenuto. La presenza degli attributi ‘alt’ minimizza comunque
    l’impatto di questo problema. Anche i testi della parte centrale della
    pagina sono immagini gif, mentre non lo sono le descrizioni relativi
    alle voci di menu sulla destra.
  3. Al link per la ricerca testuale è normalmente preferibile
    il box di ricerca, nel quale l’utente può direttamente iniziare
    la ricerca, risparmiando un click. E’ semmai possibile linkare una voce
    dedicata all’eventuale funzione di "ricerca avanzata".

Nonostante questi problemi (peraltro, insistiamo: poco o nulla rilevanti
per il target specifico del sito), il design della navigazione di Adobe
rimane un ottimo esempio di organizzazione logica e visiva di un sito
ampio e complesso attraverso sistemi eleganti e flessibili