10.                       Principi e linee guida

Sintesi del capitolo

Questo capitolo descrive i principi che il progettista dovrebbe seguire nella progettazione di sistemi interattivi usabili. Dopo un chiarimento su che cosa si intende per principi, linee guida, standard e standard di progetto, vengono richiamati brevemente gli standard elaborati dal comitato tecnico dell’ISO che si occupa degli standard relativi alla Ergonomics of human-system interaction. Fra questi, riveste notevole importanza il documento ISO 9241-110, che definisce sette principi molto generali, e una serie di raccomandazioni dirette al progettista di  sistemi interattivi. Il cuore del capitolo è dedicato alla descrizione di questi principi e delle relative raccomandazioni, con l’ausilio di numerosi esempi.

Principii, linee guida, regole di progetto, standard

Per aiutare il progettista di sistemi interattivi usabili, è utile fornirgli delle indicazioni che si siano dimostrate valide in progetti simili al suo. Alcune saranno di tipo positivo: “per ottenere questo risultato, puoi adottare questa soluzione”. Altre di tipo negativo: “in questa situazione, evita di fare questo”. Queste indicazioni possono essere più o meno generali (alcune sono applicabili in ogni situazione, altre in casi specifici) o più o meno coercitive  (alcune sono  semplici suggerimenti, che possono essere seguiti a discrezione del progettista, altre sono vincolanti, e devono essere seguite obbligatoriamente).

Figura 1.  Classificazione delle indicazioni per il progettista

 

Queste indicazioni possono essere classificate in quattro grandi categorie, in funzione del loro livello di generalità e coercitività, come indicato in Figura 1:

·      Regole di progetto

Sono le regole che devono essere applicate nell’ambito di uno specifico progetto. Hanno bassa generalità (possono essere anche molto specifiche), ma alta coercitività: sono imposte dal committente, e vincolanti per il progettista. Di solito  sono regole piuttosto dettagliate, che specificano le modalità d’interazione con un certo sistema, per esempio per renderlo consistente con altri sistemi della stessa organizzazione.  Esempi tipici sono le regole che definiscono l’apparenza grafica dell’interfaccia con l’utente: quali font devono essere usati, quali formati sono ammessi per i campi di input usati nei dialoghi, quali forme, dimensioni e colori dei pulsanti, e così via.

·      Standard
Sono norme di tipo generale, emesse da organismi internazionali, che definiscono le regole da applicare nei progetti di determinate classi di sistemi. Sono vincolanti per tutti i progetti che dichiarano  di essere conformi allo standard. Sono emessi da enti di standardizzazione, come per esempio l’ISO (International Standard Organization), o da altri enti indipendenti, che hanno l’obiettivo di definire delle raccomandazioni da seguire per certe categorie di sistemi. Un esempio è il W3C (World Wide Web Consortium), le cui raccomandazioni costituiscono degli standard di fatto per le tecnologie del Web. La conformità a uno standard deve essere valutabile in modo preciso, e quindi gli standard devono essere formulati con estrema cura, per evitare ogni ambiguità. Ovviamente, dovendo essere applicabili a intere classi di sistemi, gli standard sono notevolmente meno specifici delle regole di progetto.

·      Linee guida

Sono delle raccomandazioni per il design dell’interazione di specifiche classi di sistemi, espresse in modo più o meno generale, a seconda dei casi. Sono spesso corredate di esempi e motivazioni. Non sono vincolanti, sta al progettista decidere sull’opportunità di applicarle caso per caso. Particolarmente importanti sono le linee guida per l’interfaccia utente di applicazioni relative a una specifica piattaforma, per esempio Apple[1], Windows[2], Gnome, e così via. Il loro scopo principale è quello di garantire un’elevata uniformità della user experience di tutte le applicazioni sviluppate per la specifica piattaforma. Altre sono indipendenti dalla piattaforma (cross-platform guidelines). Le linee guida in circolazione sono numerose, e sono spesso raccolte in documenti voluminosi, contenenti diecine o centinaia d’indicazioni. Per esempio, le linee guida per il design di siti web elaborate dal Department of Health and Human Services statunitense contiene oltre 200 linee guida, classificate in base alla loro rilevanza e al livello di evidenza scientifica.[3]

·      Principi
Sono indicazioni generali per la progettazione di interfacce utente usabili, basate su evidenze scientifiche o sul generale consenso. Derivano dalla conoscenza degli aspetti fisiologici, psicologici e sociali degli utenti e dall’esperienza accumulata nella pratica della progettazione dei sistemi usabili. Sono indipendenti dalla tecnologia, e sono espressi spesso in forma molto generale. Particolarmente importanti, per la loro generalità, sono i principi del dialogo con i sistemi interattivi descritti nel documento ISO 9241-Part 110, che tratteremo diffusamente nel seguito di questo capitolo.

 

Gli standard della human-system interaction

L’ente principale responsabile della preparazione degli standard è l’ISO (International Standard Organization, www.iso.org ), un’associazione non governativa di enti nazionali di standardizzazione di oltre 160 paesi, con sede a Ginevra. I prodotti principali dell’ISO sono dei documenti chiamati “International Standard” (IS), che vengono redatti da appositi  comitati tecnici (Technical Commitee, TC)  rappresentativi degli interessi delle parti coinvolte  (produttori, venditori, utenti, organizzazioni dei consumatori, laboratori di prova, governi, professionisti, organizzazioni di ricerca, ecc.).

Il processo di definizione di uno standard internazionale è piuttosto lungo e complesso, per garantire la massima trasparenza del processo,  l’apertura a tutti i contributi, la coerenza tecnica all’interno del sistema degli standard e, soprattutto, il più ampio accordo fra tutti gli enti coinvolti, rappresentativi di interessi diversi. Uno standard internazionale dovrebbe, infatti, rappresentare le conoscenze e le pratiche sulle quali si raccoglie il massimo consenso fra gli esperti dei vari paesi. Pertanto, esso viene elaborato in diverse fasi, attraverso un processo formalizzato che può durare anche diversi anni: a partire da una prima proposta, vengono realizzate numerose bozze, sottoposte al commento e all’approvazione delle varie parti coinvolte, fino al Draft International Standard (DIS) che deve essere approvato per votazione dal 75% dei membri con diritto di voto.

Gli standard che interessano l’ingegneria dell’usabilità fanno capo al Technical Committee TC 159 – Ergonomics, a sua volta suddiviso in quattro sotto-comitati (Sub-Committee, SC):

TC 159/SC 1 - General ergonomics principles;

TC 159/SC 3 - Anthropometry and biomechanics;

TC 159/SC 4 - Ergonomics of human-system interaction;

TC 159/SC 5 - Ergonomics of the physical environment.

 

Nell’ambito di questo libro, il sotto-comitato di maggiore interesse è il TC 159/SC 4, che dichiara la seguente missione:

 

Standardizzazione ergonomica della interazione fra i sistemi (spesso basati su computer) e le persone che li progettano, fabbricano, usano e mantengono. Le aree di standardizzazione comprendono l’ergonomia dell’hardware (inclusi gli strumenti di input, i monitor e gli apparati interattivi), l’ergonomia del software (inclusa la progettazione del dialogo e l’interaction design) e i metodi e processi dello human-centred design (inclusa l’ingegneria dell’usabilità e i metodi di progettazione partecipativa).[4]

 

Gli standard elaborati dal TC 159/SC 4 sono numerosi. La rapida evoluzione delle tecnologie d’interazione e la maturazione delle esperienze nella costruzione di sistemi interattivi fa sì che i diversi standard debbano essere periodicamente rivisti e aggiornati. A volte i documenti già emessi vengono riscritti ex novo, o integrati con nuovi standard, di argomento più specifico. Queste attività di evoluzione e aggiornamento, unite alla lentezza intrinseca del processo di standardizzazione, creano inevitabilmente una situazione piuttosto complicata, per cui non è facile avere il quadro completo della situazione. Ulteriori difficoltà derivano dal fatto che i documenti ISO non sono in genere liberamente accessibili, ma devono essere acquistati singolarmente, a prezzi molto elevati.

I principali standard prodotti dal TC 159/SC 4 sono i seguenti:

·       ISO 13407

Si intitola Human-centred design processes for interactive systems, ed ha lo scopo di aiutare coloro che hanno la responsabilità di gestire i processi di progettazione di hardware e software a pianificare in modo adeguato le attività di progettazione human-centred.  Ne abbiamo parlato diffusamente nel Capitolo 6.

·      ISO 9241

Si tratta dello standard principale relativo alla human-computer interaction. è molto ampio, ed è composto da numerosi documenti separati, in evoluzione da una ventina d’anni.

Inizialmente, questo standard trattava essenzialmente gli aspetti ergonomici dei terminali video utilizzati per il lavoro di ufficio, e aveva infatti il titolo di Ergonomic requirements for office work with visual display terminals (VDTs). Col tempo, i suoi obiettivi si sono ampliati, e ora tratta le problematiche di usabilità dei sistemi interattivi in generale. Pertanto, è in corso un processo di revisione dell’intero standard, rinominato di recente, più genericamente, Ergonomics of Human System Interaction. In questa revisione, lo schema di numerazione dei documenti dell’ISO 9241 è stato ridefinito. Nella nuova numerazione, i documenti sono organizzati in serie tematiche:

Serie 100: Software ergonomics;

Serie 200: Human system interaction processes;

Serie 300: Displays and display related hardware;

Serie 400: Physical input devices - ergonomics principles;

Serie 500: Workplace ergonomics;

Serie 600: Environment ergonomics;

Serie 700: Application domains - Control rooms;

Serie 900: Tactile and haptic interactions.

 

Al documento iniziale di ciascuna serie (identificato col numero n00), che costituisce l’introduzione alla serie, segue un numero di documenti variabile in funzione delle esigenze dell’argomento.

Questo schema sostituisce quello originale, nel quale i documenti erano denominati “Parti” e numerati da 1 a 17. In questa fase di transizione dalla vecchia organizzazione alla nuova, la situazione risulta abbastanza confusa, perché convivono standard con la vecchia e con la nuova numerazione. I documenti pubblicati alla data di stesura di queste pagine (compresi quelli nello stato di DIS) sono elencati in Figura 2. A questi si aggiungono numerosi altri documenti in bozza. La situazione aggiornata si trova sul sito dell’ISO, nella pagina del TC/159 SC 4.[5]

 

·       ISO 14915

Si intitola Software ergonomics for multimedia user-interfaces, ed è composto da tre documenti: Part 1: Design principles and framework; Part 2: Multimedia navigation and control; Part 3: Media selection and combination.

Questo standard descrive principi e raccomandazioni per la progettazione di sistemi multimediali. In particolare, tratta l’interfaccia utente di applicazioni che incorporano, integrano e sincronizzano media differenti, statici (testo, grafica o immagini) o dinamici (audio, animazioni, video o media correlati ad altre modalità sensoriali).

 

Oltre agli International Standard, l’ISO può  produrre altri tipi di documenti, con un livello di consenso inferiore: ISO Technical Specification (ISO/TS), ISO Public Available Specification (ISO/PAS) e ISO Technical Report (ISO/TR).  In particolare, il TC/159 SC 4 ha prodotto questi documenti aggiuntivi:

 

·       ISO/TR 16982: Ergonomics of human-systems interaction – Usability methods supporting human-centred design;

·       ISO/PAS 18152: Ergonomics of human-systems interaction – Specification for the process assessment of human-system issues;

·       ISO/TR 18529: Human-centred lifecycle process descriptions.

 

Figura 2.  Documenti dell’ISO 9241 pubblicati al marzo 2010

 

Come si intuisce da questo sommario elenco, gli standard emessi dal TC/159 SC 4 sono di tipologie diverse. Alcuni sono standard di processo: definiscono, cioè, le caratteristiche di determinati processi di lavoro (per esempio, nel caso dell’ISO 13407, il processo di progettazione dei sistemi interattivi). Altri sono standard di prodotto:  specificano, cioè, le caratteristiche che devono possedere determinate categorie di prodotti. Appartengono a questa categoria vari documenti dell’ISO 9241, come per esempio la Parte 4, che stabilisce i requisiti ergonomici delle tastiere. Molti documenti, inoltre, hanno lo scopo di definire la terminologia da usarsi in un determinato ambito. Anche questo è un compito importante dei comitati di standardizzazione, che permette ai vari operatori di utilizzare un linguaggio comune in modo non ambiguo. Il compito può sembrare banale, ma è reso molto complicato dalla necessità di mantenere una coerenza terminologica fra i numerosi documenti, che evolvono separatamente lungo l’arco di molti anni.[6]

I principi del dialogo secondo la ISO 9241-110

Fra i numerosi documenti che compongono l’ISO 9241, vogliamo qui occuparci della Parte 110, Dialogue principles. Si tratta di uno documento breve,  ma  molto importante dal punto di vista concettuale. Esso descrive sette principi del dialogo, ovvero sette caratteristiche che ogni dialogo fra un utente e un sistema interattivo dovrebbe possedere. In questo documento, il termine  dialogo viene usato, come abbiamo già visto, nel senso ampio di “l’interazione fra un utente e un sistema interattivo, intesa come sequenza di azioni dell’utente (input) e di risposte del sistema (output) per raggiungere un obiettivo”. Le azioni dell’utente includono quindi l’immissione di dati, ma anche tutte le azioni di navigazione e di controllo del sistema. Anche il termine sistema interattivo è usato in modo generale, come “una combinazione di elementi hardware e software che ricevono degli input da un utente umano, e gli comunicano degli output, allo scopo di supportare l’esecuzione di un compito”.

I sette principi del dialogo sono i seguenti[7].

·       Adeguatezza al compito (suitability for the task)

Un sistema interattivo è adeguato al compito se supporta l’utente nel completamento del compito, cioè quando la funzionalità del sistema e il dialogo sono basati sulle caratteristiche del compito, piuttosto che sulla tecnologia scelta per eseguirlo.

·       Auto-descrizione (self-descriptiveness)

Un dialogo è auto-descrittivo se agli utenti risulta evidente, in ogni momento,  in che dialogo si trovano, a che punto si trovano all’interno del dialogo, quali azioni possono compiere e come queste possono essere eseguite.

·       Conformità alle aspettative dell’utente (conformity with user expectations)

Un dialogo è conforme alle aspettative dell’utente se corrisponde alle necessità dell’utente, prevedibili in base al contesto e a convenzioni comunemente accettate.

·       Adeguatezza all’apprendimento (suitability for learning)

Un dialogo è adeguato all’apprendimento se supporta e guida l’utente nell’apprendimento del sistema.

·       Controllabilità (controllability)

Un dialogo è controllabile se l’utente è in grado di iniziare e tenere sotto controllo la direzione e i tempi  dell’interazione fino al raggiungimento dell’obiettivo.

·       Tolleranza verso gli errori (error-tolerance).

Un dialogo tollera gli errori se, nonostante evidenti errori negli input, i risultati desiderati possono essere ottenuti senza o con minime azioni correttive. La tolleranza per gli errori si ottiene attraverso a)- il controllo degli errori (controllo dei danni); b)- la correzione degli errori e c)- la gestione degli errori, per fronteggiare gli errori occorsi.

·       Adeguatezza all’individualizzazione (suitability for individualization)

Un dialogo è adeguato all’individualizzazione se l’utente può modificare l’interazione e la presentazione dell’informazione per adattarle alle proprie necessità e capacità individuali.

 

Questi principi sintetizzano, secondo il punto di vista adottato nello standard, gli elementi chiave che determinano la usabilità di un sistema interattivo (Figura 3). Il documento, tuttavia, non intende precludere la possibilità di altre formulazioni, affermando esplicitamente che “ci possono essere modi diversi di identificare gli aspetti chiave, che conducono a un diverso insieme di principi”.

Figura 3.  I sette principi del dialogo secondo l’ISO 9241

 

I principi elencati non sono fra loro indipendenti e possono esserci delle sovrapposizioni. In determinate situazioni essi possono essere in conflitto, e sarà quindi compito del progettista individuare il compromesso più opportuno in relazione alle specifiche caratteristiche del sistema in corso di progettazione,  per ottimizzarne l’usabilità.  Questo può non essere facile, perché la priorità da assegnare ai diversi principi può variare a seconda della specifica applicazione, delle caratteristiche degli utenti e dello stile di dialogo utilizzato. In effetti, lo standard afferma esplicitamente che l’ordine in cui i principi sono elencati non ha alcun particolare significato.

I principi dell’ISO 9241-110 sono importanti non solo dal punto di vista teorico-concettuale, ma anche dal punto di vista pratico. In sostanza, essi definiscono un modello di qualità[8] che può essere utilizzato per valutare l’usabilità di un sistema, o per confrontare l’usabilità di due sistemi simili. A questo scopo, occorrerà esaminare ciascun sistema e attribuire un “voto” al grado di applicazione di ogni principio. Sarà poi possibile visualizzare i voti ottenuti in un diagramma a stella, come nella Figura 4 (in cui si è usata una scala da 0 - voto minimo - a 4 - voto massimo) ottenendo il profilo di qualità del sistema. Nel diagramma di sinistra vediamo il profilo di un sistema che ha ricevuto il massimo dei voti nell’auto-descrizione e nell’adeguatezza all’apprendimento, ma un voto pessimo nell’adeguatezza all’individualizzazione. Nel diagramma di destra sono messi a confronto due sistemi.

Figura 4.  Profilo di qualità di un sistema basato sui sette principi del dialogo dell’ISO 9241 (sinistra) e confronto di due profili di qualità (destra)  

 

Per ciascuno dei sette principi indicati, lo standard ISO 9241-110 fornisce una lista di raccomandazioni che dovrebbero essere tenute in considerazione nella progettazione di un sistema.  Questa lista non pretende di essere esaustiva. Inoltre, le raccomandazioni non sono fra loro indipendenti, e ci sono diverse sovrapposizioni. Pur con questi limiti, si tratta d’indicazioni importanti che, se seguite con attenzione, possono evitare i problemi di usabilità più comuni. Nel seguito, per ciascun principio, descriviamo alcune linee guida che possono orientare i progettisti nel design dell’interazione, ispirandoci liberamente alle raccomandazioni dello standard, e integrandole con esempi e indicazioni tratte dalle buone pratiche consolidate nel design dell’interazione. liberamente.

Adeguatezza al compito

In sostanza, questo principio afferma che le funzionalità e le modalità d’interazione del sistema devono essere modellate sulle caratteristiche del compito che l’utente deve compiere con il supporto del sistema, e non sulla tecnologia o delle caratteristiche del sistema stesso. In pratica, il dialogo dovrà essere progettato a partire dai casi d’uso identificati nell’analisi dei requisiti. Per ogni caso d’uso, dovrà permettere all’utente di svolgere i compiti e le azioni necessarie nella sequenza più naturale per lui, e non per il software che gestisce l’interazione. Questa è l’essenza stessa dello user- centred design, e forse non è un caso che lo standard abbia elencato questo principio per primo.

Alcune linee guida coerenti con questo principio generale sono le seguenti.

 

·      Dialologo adeguato al compito

I passi del dialogo dovrebbero essere adeguati al compito: dovrebbero essere inclusi tutti i passi necessari ed evitati i passi non necessari. In particolare, il dialogo dovrebbe assegnare al sistema tutte quelle operazioni che possono essere automatizzate, senza caricare inutilmente l’utente di compiti che possono essere agevolmente svolti in modo automatico. Le operazioni assegnate all’utente dovrebbero essere da questi eseguibili con facilità, senza richiedere sforzi cognitivi eccessivi o abilità motorie particolari.

·      Informazione adeguata al compito

Questa linea guida è un caso particolare della precedente, e richiede che il sistema presenti all’utente tutte le informazioni utili per lo svolgimento del compito. Ciò può essere fatto in molti modi, ma le soluzioni migliori sono quelle in cui l’informativa all’utente varia in funzione del contesto. In questo modo, si trasmettono all’utente solo le informazioni utili nello svolgimento di un particolare passo del dialogo, e si evita di sovraccaricarlo con informazioni che gli serviranno in momenti diversi, anche se temporalmente vicini.

Per esempio, un sito di commercio elettronico, in cui il processo di acquisto si sviluppa in  più fasi, all’utente vengono fornite di volta in volta soltanto le informazioni necessarie per lo svolgimento della fase corrente. La Figura 5 mostra la prima fase (Scelta del viaggio) dell’acquisto di un biglietto ferroviario sul sito di Trenitalia. Il processo di prenotazione avviene in cinque fasi, e l’applicazione segnala all’utente in quale fasi si trova, evidenziandone graficamente il nome nella parte alta dello schermo.  In questa fase all’utente è richiesto, correttamente, di indicare soltanto il treno desiderato, dopodiché potrà procedere alla fase successiva.

 

Figura 5.  Acquisto del biglietto di un treno (www.trenitalia.it, 2009)

È molto importante che vengano sempre tenute in considerazione le limitazioni della memoria umana a breve termine, descritte nel Capitolo 4. Nell’esempio di Figura 6, tratto da una vecchia versione di Microsoft Word, il messaggio indica all’utente come può vedere le parti del suo testo che non sono state esaminate dal sistema di controllo ortografico del word processor (text set to no proofing). Il messaggio sovraccarica inutilmente la memoria a breve termine dell’utente. Infatti, per vedere quale testo non è stato esaminato dal controllore ortografico, l’utente dovrebbe memorizzare la lunga sequenza di operazioni necessarie: click Edit/Replace, click More, click Format, click Language, choose (no proofing). Dovrebbe poi premere OK per riuscire ad accedere ai menu di Word e compiere tali operazioni. Ma così facendo il messaggio scompare, ed è probabile che la sequenza di operazioni da svolgere sia stata già parzialmente dimenticata: la sequenza da ricordare è lunga, e per eseguirla l’utente dovrà compiere altre attività cognitive (per esempio, per cercare le voci di menu indicate). Come già sappiamo, questo può facilmente mettere in crisi la nostra memoria a breve termine. 

Figura 6. Sovraccarico della memoria a breve termine (da Microsoft Word 1997)

Altri esempi analoghi di sovraccarico della memoria a breve termine sono mostrati nel Capitolo 4 e nelle Figure 8 e 12 del Capitolo 11.  Questi esempi andrebbero considerati con attenzione, poiché errori di questo tipo vengono commessi di frequente dai progettisti meno esperti.

·      Dialogo essenziale

Il sistema dovrebbe evitare di presentare all’utente informazioni ridondanti. La comunicazione dovrebbe essere breve, diretta ed essenziale.  Se l’informazione è fornita attraverso testi scritti, questi dovrebbero essere redatti con i criteri di massima comprensibilità, secondo i principi del plain language che tratteremo nel Capitolo 13. Occorre sempre evitare di duplicare l’informazione. Ogni duplicazione genera dubbi nell’utente e ne distoglie l’attenzione dal compito principale. Per esempio, la Figura 7 mostra un errore frequente nei siti web: la duplicazione del menu principale nella home page. In questo caso, nella home page e in tutte le altre pagine del sito è visibile un menu verticale di cinque voci, in alto a sinistra. A scopo puramente decorativo, nella sola home page questo menu è duplicato nella parte centrale della pagina, e ridisegnato in forme tondeggianti. I due menu presenti in home page sono equivalenti: ogni coppia di voci omonime (per esempio, La Compagnie) porta alla stessa pagina del sito. Ma l’utente non lo sa per certo, e avrà il dubbio che le due voci conducano a pagine diverse. Per risolvere questo dubbio, sarà costretto a provare a cliccare i diversi link e confrontare i risultati. 

 

Figura 7.  Ridondanza dei menu nella home page di un sito
(http://www.bruno-verdi.com )

 

·      Dispositivi di input e output adeguati al compito

La tecnologia mette a disposizione molti possibili dispositivi di input e di output per realizzare il dialogo con l’utente: tastiera, mouse, schermi tattili, voce,  video, audio, stampa, ecc. Quelli utilizzati dovrebbero essere scelti in funzione del compito specifico, e non viceversa. A volte il compito può richiedere, per una migliore efficienza, l’utilizzo contemporaneo di più dispositivi (multi-modalità).  Per esempio, in un’applicazione di grafica, l’utente potrebbe utilizzare la mano destra per disegnare, muovendo lo stilo sulla tavoletta grafica, mentre con la mano sinistra potrebbe attivare i diversi comandi premendo i  vari tasti funzione (o viceversa, se mancino). In questo caso, la scelta delle combinazioni di tasti dovrà essere tale da agevolare questa modalità di interazione.

·      Formati di input e output adeguati al compito

I formati dei dati di input e output dovrebbero essere adeguati al compito. Per esempio, un programma finanziario dovrebbe accettare valori con non più di due decimali, quando essi siano espressi in Euro. Un altro esempio significativo è costituito dai numeri di telefono. Abbastanza spesso, i siti web degli alberghi statunitensi forniscono soltanto il numero di telefono gratuito (con prefisso 800).  Ma questo è utilizzabile soltanto dagli Stati Uniti: chi volesse prenotare telefonicamente una stanza dall’Europa non lo può fare.

·      Default tipici

Una corretta impostazione dei valori di default può semplificare molto il dialogo. Essi dovrebbero essere impostati in modo da riflettere le scelte più comuni. Per esempio, in un distributore di biglietti ferroviari, la stazione di partenza di default potrebbe essere quella in cui ci si trova. In questo modo si semplifica il compito dell’utente, che nella maggior parte dei casi potrà semplicemente specificare solo la stazione di destinazione. L’usabilità e l’efficienza migliorano, e il distributore sarà in grado di servire, nello stesso tempo, un maggior numero di utenti. Lo stesso accorgimento potrà essere usato anche nei sistemi di prenotazione o di calcolo d’itinerari via Web, impostando il valore di default del punto di partenza sulla base del domicilio fornito dall’utente in fase di registrazione al sito. 

Ancora, quando in Photoshop si crea un nuovo documento, le sue dimensioni vengono automaticamente impostate alla dimensione dell’elemento che è stato oggetto dell’ultima operazione di copia, nell’assunzione che l’utente desideri poi “incollare” tale elemento nel documento appena creato, per modificarlo.

Un’adeguata impostazione dei valori di default è particolarmente importante in quelle funzionalità che richiedono all’utente di specificare molti parametri, come per esempio nei programmi di grafica più sofisticati per le operazioni di stampa o di salvataggio di file nei vari formati. In questo caso l’utente meno esperto potrebbe affidarsi ai valori di default anche quando non conosce il significato di tutti i parametri, con la garanzia che l’operazione richiesta verrà comunque portata a termine, almeno nelle situazioni più comuni, in modo corretto.

·      Compatibilità con i documenti

Questa indicazione è particolarmente importante nel progetto di sistemi informativi aziendali. Essa si applica quando un documento cartaceo è la fonte dei dati che devono essere immessi nel sistema, o quando né è la destinazione. In entrambi i casi è conveniente che il layout delle informazioni sul video e sul documento siano congruenti. Nel primo caso, per rendere più scorrevoli le operazioni di immissione dei dati, senza che ciò richieda all’operatore di ricercare ogni volta il dato richiesto all’interno del documento. Nel secondo caso, per evitare all’utente la complessità di gestire gli stessi dati visualizzati in modo diverso.

 

Auto-descrizione

In sostanza, questo principio richiede che il sistema comunichi all’utente, in ogni momento, che cosa egli possa fare e come, e che cosa sta accadendo. Ricordando il modello di Norman descritto nel Capitolo 3, ciò ha lo scopo di ridurre il golfo dell’esecuzione e il golfo della valutazione. Nella maggior parte dei casi, questa comunicazione utilizza il canale visivo, con informazioni testuali o grafiche visualizzate su un monitor. Possono però essere utilizzati anche altri canali, per esempio quello auditivo, con l’uso di messaggi acustici di vario tipo.  

Alcune linee guida da seguire nella progettazione di un dialogo autodescrittivo sono le seguenti.

 

·      Guida per l’utente

Ogni passo del dialogo dovrebbe fornire all’utente tutte le informazioni utili per proseguire. Le informazioni sono sostanzialmente di tre tipi: istruzioni operative (“che cosa puoi fare ora”), informazioni sullo stato del sistema (“ora sto facendo questo”) e informazioni di feedback (“ciò che hai fatto ha avuto questo effetto”). La guida all’utente non dovrebbe, comunque essere eccessivamente vincolante: egli dovrebbe essere sempre libero di modificare lo svolgimento del dialogo secondo le sue esigenze, in modo flessibile. Per esempio, nel processo di acquisto del biglietto ferroviario di Figura 5, l’utente dovrebbe essere sempre in grado di tornare alle fasi precedenti, per modificare liberamente alcune scelte già effettuate, senza dover riprendere l’intero dialogo dall’inizio. Questa flessibilità è così importante ai fini dell’usabilità di un sistema che l’ISO 9241 la sancisce dedicandole uno dei sette principi di base (controllabilità).

·      Interazione evidente

Questa linea guida è legata al concetto di affordance introdotto nel Capitolo 3. Raccomanda, in sostanza, che i  dialoghi siano progettati in modo che l’interazione con il sistema risulti evidente.

La Figura 8 mostra la home page di un vecchio sito del Mulino Bianco, che viola questa indicazione. La parte centrale della pagina, destinata a contenere il menu principale, è muta, ma passando il mouse su ciascuna delle tre aree tonde attorno al logo centrale appaiono le voci di un menu. Si scopre così che ciascuna area tonda corrisponde a un menu: per conoscere lo scopo del sito è necessario “esplorare” la pagina col mouse.  La figura mostra ciò che appare quando il mouse tocca l’area di sinistra. La home page “a riposo” non mostra alcun menu, né è possibile vedere i tre menu contemporaneamente. Un analogo problema di usabilità esiste nel sito di J.K.Rowling, già discusso (Figura 19, Capitolo 8).

 

 

Figura 8.   Home page del sito del Mulino Bianco (2003)

 

In molti casi questo si può ottenere adottando modalità operative già note all’utente in altri contesti. Per esempio, da molti anni i player di musica digitale utilizzano un’interfaccia molto simile, mutuata dagli apparati dell’elettronica di consumo, come negli esempi di Figura 9.

 

Figura 9.  Il mini-player di iTunes della Apple (sinistra) e di Windows Media Player della Microsoft (destra)

 

Alcune modalità d’interazione, di per sé non ovvie, possono essere ritenute ormai acquisite, considerando la loro larga diffusione. Per esempio, da tempo ci siamo abituati alla classica interfaccia dei cellulari Nokia, in cui i due tasti situati subito sotto lo schermo vengono utilizzati per confermare una delle due opzioni presentate in corrispondenza. Così, il prototipo di  Figura 10 può ragionevolmente ritenersi di utilizzo evidente.

Figura 10.     Scommesse da cellulare (prototipo didattico)

 

·      Descrizione dell’input atteso

Anche questa raccomandazione è un caso particolare della prima. Ogni volta che il sistema richiede un input all’utente, dovrebbe fornirgli informazioni adeguate su ciò che si aspetta, e sul suo formato. Quindi, sono da evitare dialoghi che contengono campi liberi, come il seguente:

 

DATA DI NASCITA: __________________

 

che andrebbero sostituiti con input guidati, per esempio:

 

        DATA DI NASCITA: __/__/____ (gg/mm/aaaa)

·      Stato visibile

Questa è una delle raccomandazioni più importanti. L’utente dovrebbe essere sempre informato sullo stato del sistema, sia quando questo è in attesa di input, sia quando ha elaborato l’input che gli è stato appena fornito. Se l’utente non conosce lo stato in cui si trova il sistema, non può prevedere come risponderà alle sue azioni.  Un sistema “muto”, che non rende chiaramente visibile il suo stato, genera incertezza e stress, anche quando va tutto bene. La regola del “silenzio assenso” non dovrebbe essere mai applicata nei sistemi usabili. Questo vale anche quando dialoghiamo con un interlocutore umano: se non ne conosciamo lo stato d’animo non sappiamo come comportarci. Di questo parleremo ancora nel Capitolo 11.

 

·      Formati descritti

Il sistema dovrebbe fornire all’utente ogni informazione sui formati e sulle unità di misura utilizzati.

 

·      Manualistica minima

Durante l’interazione, si dovrebbe minimizzare la necessità di consultare manuali d’uso o altre informazioni presenti fuori  dal sistema. Tutta l’informazione necessaria dovrebbe essere consultabile in linea, senza uscire dal sistema, preferibilmente con sistemi di help evoluti di natura contestuale. Ricordiamo, a questo proposito, le considerazioni sui manuali d’uso già fatte nel Capitolo 3.

Conformità alle aspettative

Questo principio afferma che il dialogo deve essere conforme a ciò che l’utente si aspetta, in relazione allo specifico contesto d’uso del sistema, e alle convenzioni comunemente adottate. Si tratta quindi di un principio di natura molto generale, che può essere applicato a molte situazioni diverse. Le implicazioni sono numerose: vediamone alcune.

·      Linguaggio familiare

Il sistema dovrebbe utilizzare un linguaggio che l’utente conosce bene. Questa raccomandazione è molto importante, perché la maggior parte dei dialoghi con i sistemi interattivi avviene attraverso il linguaggio. Un suo uso improprio può quindi compromettere gravemente l’usabilità. Tutti gli aspetti del linguaggio usato dovrebbero essere considerati con grande attenzione: vocabolario, sintassi e semantica. Per i sistemi che si rivolgono a utenze internazionali è particolarmente importante la qualità delle traduzioni nelle diverse lingue. Alla comprensibilità dei testi dedicheremo alcune pagine del Capitolo 13.

·      Aderenza alle convenzioni

Il dialogo dovrebbe seguire le convenzioni comunemente adottate nello specifico contesto. Per esempio, in un sito web di un paese occidentale, il menu di navigazione orizzontale è allineato a sinistra, e le voci più frequentemente usate sono incontrate per prime, leggendolo da sinistra a destra.  In un sito in lingua araba, i menu orizzontali sono allineati a  destra, e le voci si susseguono in  ordine inverso. Per esempio, la Figura 11 mostra la home page del sito della emittente televisiva Al-Arabiya, di Dubai. La versione in lingua araba, a destra, è concepita per essere letta da destra a sinistra, mentre nella versione in lingua inglese il testo, il titolo della pagina, il menu principale, i titoli delle varie sezioni e il sommario verticale degli articoli seguono le convenzioni comunemente adottate nel mondo occidentale.

 

Figura 11.       www.alarabiya.net: versione in lingua inglese (sinistra) e araba (destra)

 

·      Organizzazione abituale

La struttura del dialogo e l’organizzazione dei dati dovrebbero permettere all’utente di effettuare le operazioni secondo le modalità a lui consuete. Per esempio, le merci in vendita in un supermercato online dovrebbero essere raggruppate come normalmente lo sono in un supermercato reale.

Per seguire questa indicazione, il progettista deve tenere presente che le abitudini degli utenti si formano e si modificano rapidamente, e spesso in modo inconsapevole. Un esempio molto interessante è costituito dai layout tipici delle pagine web. Anche se la grafica dei siti web è molto variabile da sito a sito, le aspettative degli utenti per quanto riguarda la posizione dei singoli elementi si sono consolidate molto rapidamente.

In uno studio del 2001[9], a un campione di utenti venne chiesto di mostrare la posizione in cui si aspettavano di trovare alcuni tipici elementi di una pagina web: link interni ed esterni al sito, link alla home page, motore di ricerca interno, carrello per gli acquisti, campo per la registrazione al sito e così via. Nonostante la ancora giovane età del Web, si trovò che gli utenti avevano già sviluppato un sistema di aspettative comuni ben definite.  Nella Figura 12, il tono di grigio indica il numero di volte che una certa area del monitor è stata indicata dagli utenti: più il colore è scuro, maggiore è il numero delle persone che ha indicato quella posizione. Per esempio, gli utenti si aspettavano di trovare il link alla home page nell’angolo in alto a sinistra dello schermo oppure, ma con frequenza minore, nel centro del piede della pagina.  Ci si aspettava di trovare l’help in alto a destra, come il carrello degli acquisti. E cosi via, come indicato in figura.

 

 

Figura 12.       Le aspettative degli utenti sul layout delle pagine web, in uno studio del 2001 (M.Bernard)

 

·      Dialogo consistente

Le aspettative dell’utente si formano anche nell’ambito di uno stesso sistema. Se questo si comporta in un certo modo in una data situazione, l’utente si aspetterà un comportamento analogo in situazioni simili. Pertanto, tutti i dialoghi realizzati da uno stesso sistema dovrebbero avere aspetto e comportamento consistenti. Per esempio, i bottoni o le voci di menu che servono per attivare le stesse funzioni dovrebbero sempre trovarsi nella stessa posizione. Anche piccole variazioni, come nell’esempio di  Figura 13, denotano scarsa attenzione alla coerenza e andrebbero evitate. In questo caso i danni non sono gravi, ma esistono molte situazioni in cui piccole incongruenze nella grafica possono compromettere seriamente l’usabilità di un sistema. Un esempio tipico è quello dei menu che si modificano durante la navigazione.  La  Figura 14 mostra alcuni menu tratti dal sito del film The Story of Us. Il menu principale (a) occupa una buona parte della home page. Selezionando la voce The Marriage compare la pagina con la trama del film. In questa pagina, il menu principale  è posto sulla sinistra, per lasciare spazio al testo. Questo menu (b) è diverso da quello in home page: non solo è verticalizzato, ma la voce selezionata (The Marriage) è eliminata. Se ora clicchiamo, in (a) o in (b) la voce The Neighborhood, compare una nuova pagina, sulla quale il menu è ancora diverso (c), perché la voce selezionata non vi compare, mentre compaiono tutte le altre. Il menu (d), ancora differente, è quello della pagina Home Movies. Il menu, che dovrebbe costituire per l’utente, per così dire, un’ancora stabile e sicura, si trasforma continuamente, costringendolo  a una faticosa e continua rimappatura delle voci[10].

 

Figura 13.       Inconsistenza della posizione degli stessi bottoni (MS Visual Basic 5.0)

 

Figura 14.       Menu che si trasformano (http://www.thestoryofus.net, 1999)

 

Anche l’incoerenza all’interno di una stessa famiglia di applicazioni può essere dannosa. La Figura 15 mostra i pannelli per la definizione degli attributi di un carattere in Microsoft PowerPoint, Word e Excel (nella versione 2007). Al di là di minime differenze, le funzioni sono identiche, ma impaginazione, etichette e dimensioni dei campi sono notevolmente diverse. In questo caso, una maggiore attenzione alla consistenza del dialogo avrebbe non solo migliorato l’usabilità complessiva delle applicazioni di Microsoft Office, ma anche ridotto i costi di sviluppo, permettendo di riutilizzare lo stesso codice di software per tutte le applicazioni della suite.

Figura 15.       Form di definizione attributi di carattere. Dall’alto in basso:  Microsoft PowerPoint 2007, Excel 2007,  Word 2007

 

·      Feedback conforme alle aspettative

Si è già discussa la necessità che il sistema fornisca un adeguato feedback a ogni azione dell’utente. Secondo il modello di Norman, lo scopo è di permettere all’utente di superare agevolmente il golfo della valutazione (pag.20). Perciò, è utile che il feedback sia ben comprensibile e specifico: l’utente dovrebbe essere in grado di interpretarlo senza fatica. Meglio ancora, dovrebbe essere formulato nel modo che l’utente si aspetta. Come abbiamo già visto nel Capitolo 3, importante è la sua tempestività: solo così l’utente lo può porre facilmente in relazione con l’azione cui si riferisce. Infatti, risposte non immediate possono essere interpretate come eventi indipendenti da ciò cui si riferiscono: a volte bastano pochi secondi di ritardo per peggiorare significativamente l’usabilità del sistema.

Come indicazione di larga massima, si può affermare che tempi di risposta fino a 0,1 secondi sono percepiti come immediati, tempi di risposta da 0,1 a 1 secondo non sono percepiti come immediati, ma non sono sufficientemente lunghi da compromettere la continuità cognitiva del compito che l’utente sta svolgendo,  e non richiedono quindi che il sistema fornisca particolari feedback. Invece, 10 secondi costituiscono il limite massimo per mantenere l’attenzione dell’utente focalizzata sul compito in corso. Per tempi più lunghi, l’utente desidererà probabilmente dedicarsi ad altri compiti in attesa che l’elaborazione termini, ed è quindi opportuno che il sistema fornisca un feedback adeguato indicando lo stato di avanzamento dell’elaborazione.[11]

 

·       Tempi di risposta conformi alle aspettative 

L’utente si forma delle aspettative sul tempo di esecuzione delle elaborazioni richieste. Se questo dovesse deviare sensibilmente da queste aspettative, dovrebbe esserne preventivamente informato. Se la risposta del sistema ritarda troppo, o se - peggio ancora - il sistema resta “muto”, può sorgere il dubbio che si sia bloccato per qualche errore. In questi casi, l’utente spesso rinuncia, e interrompe l’operazione, anche se questa fosse correttamente in corso. Ciò capita di frequente sul Web, quando la pagina richiesta tarda ad apparire.

Le operazioni che richiedono tempi lunghi sono quindi particolarmente critiche, e il sistema dovrebbe sempre indicare chiaramente che cosa sta facendo, e quanto manca al suo completamento. Nemmeno l’esempio in Figura 16 è pienamente soddisfacente, poiché l’utente non è in grado di trasformare il dato numerico (“devono essere ancora cancellati 30 elementi”) in una previsione temporale, in presenza di elementi i cui tempi di cancellazione siano fra loro molto diversi.

 

Figura 16.       Indicatore di progresso (da Mac OS 8)

È utile tenere presente che il tempo percepito dall’utente non sempre coincide con il tempo reale. In altre parole,  in determinate situazioni l’utente può avere la sensazione che il sistema impieghi più (o meno) tempo di quello oggettivamente trascorso. Si possono quindi adottare opportuni accorgimenti per ridurre il tempo percepito, per esempio intrattenendo l’utente durante l’attesa con animazioni divertenti o altro: le soluzioni che vengono adottate, nei siti web, sono infinite. Si è anche verificato sperimentalmente che il tempo percepito dagli utenti trascorre più lentamente nelle fasi finali dell’attesa. È stato quindi suggerito di “rallentare” all’inizio la visualizzazione del trascorrere del tempo, per accelerarla nelle fasi finali, quando l’impazienza dell’utente è massima. 

·       Messaggi adeguati al contesto

La lunghezza e il tipo dei messaggi prodotti dal sistema dovrebbero essere adeguati al contesto. Non tutti i messaggi sono adatti a ogni situazione, anche se il loro contenuto è pertinente. Per esempio, se desidero attivare la funzione di controllo ortografico di un word processor e chiedo al sistema di help “dove si trova il controllo ortografico?”, dovrei ottenere una risposta breve e appropriata, e non l’elenco di tutti i capitoli del manuale che trattano l’argomento.

 

·      Messaggi in posizione appropriata

I messaggi di feedback e le spiegazioni fornite all’utente dovrebbero apparire dove si trova il focus dell’attenzione dell’utente, per non interrompere il flusso dell’interazione. Per esempio, in un sistema controllato per mezzo di un telecomando, i messaggi di feedback dovrebbero apparire dove l’utente dirige il telecomando stesso, poiché è lì che guarda.

Lo stesso principio è adottato per la digitazione dei testi in iPhone. Poiché la tastiera virtuale è molto piccola, l’utente ha bisogno di un feedback che gli confermi di avere digitato proprio il tasto desiderato. Siccome durante la digitazione l’utente guarda il tasto che sta premendo, è lì che gli viene mostrato l’ingrandimento del carattere appena digitato (Figura 17).

Figura 17.        Digitazione testi sull’iPhone (dal manuale della Apple)

Una tecnica analoga è utilizzata nel doppio slider di Figura 18, che permette di ricercare dei prodotti (in questo caso, delle fotocamere compatte) in una certa fascia di prezzo in un sito di e-commerce. I prezzi minimi e massimi selezionati (in questo caso, 300,4 e 560,3 Euro) compaiono via via sui controlli che l’utente fa scorrere sullo slider, e non altrove, perché è lì che l’utente guarda durante l’operazione. 

 

Figura 18.       Da http://www.mediaworld.it (2009)

 

 

·      Input in posizione attesa

Il sistema dovrebbe richiedere l’input all’utente nella posizione in cui questi si aspetta di doverlo fornire. Questa indicazione è simile alla precedente, e si riferisce soprattutto ai dialoghi in cui l’utente deve fornire input ripetuti.

Per esempio, durante il controllo ortografico di un testo, il word processor presenta via via all’utente le frasi da correggere, chiedendogli di accettare la correzione proposta o di confermare il testo senza modifiche. Se le frasi da correggere sono molte, la domanda viene posta ripetutamente. Per permettere all’utente di eseguire il compito con la massima efficienza, i bottoni per la conferma o la sostituzione dovrebbero apparire sempre nella stessa posizione.  In tal modo l’utente può concentrarsi sul testo da correggere, senza dover spostare lo sguardo, a ogni frase, sulla posizione dei comandi. In Microsoft Word 2007 (Figura 19), correttamente, la finestra di dialogo con i comandi di conferma o sostituzione appare sempre nello stesso posto sul video, mentre il testo da correggere è fatto scorrere, in modo che la frase esaminata (evidenziata) sia sempre visibile nel contesto in cui appare. In altri sistemi, a volte questo non succede, ed è la finestra di dialogo a spostarsi di volta in volta.  Questo costringe l’utente a cercare ogni volta la nuova posizione dei bottoni di conferma o di correzione, con notevole rallentamento delle operazioni e considerevole fastidio.[12]

 

Figura 19.       Controllo ortografico in Microsoft Word 2007

·       Stile coerente dei messaggi

Anche lo stile dei messaggi prodotti dal sistema è importante. L’utente si aspetta essi siano espressi in una forma coerente con il contesto e con le convenzioni correnti.  In particolare, essi dovrebbero essere formulati in modo oggettivo e costruttivo, evitando qualunque connotazione negativa o enfatica. Questa raccomandazione è particolarmente importante nel caso dei messaggi di errore, che non dovrebbero mai rimproverare l’utente, anche se in modo implicito, per ciò che ha fatto. La Figura 20 mostra quattro esempi di diversa formulazione del messaggio segnalato  da un web server quando l’utente cerca di accedere a una pagina inesistente del sito (errore 404). Nel primo caso, il punto esclamativo associa al testo, di per sé neutro, un tono di rimprovero – anche se lieve – che andrebbe senz’altro evitato. L’adeguatezza degli altri tre messaggi, d’identico significato ma di stile completamente diverso, non può, invece, essere valutata al di fuori dello specifico contesto. Essi possono essere considerati appropriati o del tutto fuori luogo, secondo le caratteristiche, finalità e modalità comunicative del sito in cui si trovano.  All’argomento della gestione degli errori dell’utente è dedicato l’intero Capitolo 11.

 

 

 

Figura 20.       Quattro messaggi per l’errore 404 (pagina non trovata)
(da sinistra a destra e dall’alto in basso: www.fs.fed.us, www.planetquo.net, www.jibjab.com, www.centerd.com  )

 

Adeguatezza all’apprendimento

Questo principio si riferisce alla learnability, già introdotta nel Capitolo 3. Esso auspica che il dialogo sia organizzato in modo tale da aiutare e guidare l’utente nell’apprendimento del sistema. Alcune linee guida sono le seguenti.

·      Bassa soglia di apprendimento

Ogni sistema dovrebbe essere utilizzabile, sia pure in modo elementare, anche con un livello di apprendimento minimo. L’utente inesperto dovrebbe essere comunque in grado di usare le funzioni di base con un addestramento molto limitato o, meglio ancora, senza alcun addestramento. Si è già osservato che gli utenti non amano leggere i manuali d’uso (Capitolo 3). Di fronte a un nuovo sistema, essi preferiranno provarlo direttamente, esplorandone subito almeno le funzioni più semplici. Il sistema dovrebbe quindi facilitare questa esplorazione, e fornir loro, a tempo debito, le informazioni necessarie per un utilizzo più avanzato.

Le operazioni richieste ai nuovi utenti per utilizzare i più diffusi servizi online sono spesso particolarmente semplici, e possono essere presi come esempio. Infatti, il fornitore del servizio ha tutto l’interesse a mantenere bassa la soglia d’ingresso, per acquisire il massimo numero possibile di utenti. L’iscrizione e l’accesso al servizio – almeno per le funzioni di base – sono spesso gratuiti, e richiedono da parte dell’utente pochi secondi: la digitazione del proprio indirizzo di email, la definizione di una password di accesso, e poco altro. Il tutto si risolve in pochi click.  Frequente è la disponibilità di un breve video che spiega le funzioni di base del sistema.

Per esempio, la home page di www.dropbox.com, un servizio di storage online, è minimalista (Figura 21). Agli utenti già registrati, propone semplicemente i due campi per inserire email e password. Ai nuovi utenti propone invece un video della durata di 2 minuti che illustra scopo e vantaggi del sistema, e un bottone per il download dell’applicazione che dovrà essere installata sul computer dell’utente. Sotto il bottone è specificato che il servizio è gratuito. Premendolo, all’utente vengono chiesti i (pochi) dati per la registrazione, quindi l’installazione avviene in modo pressoché automatico. Nella parte inferiore della home page sono riportati quattro gruppi di link (Dropbox, Community, Support, About us), com’è abituale per le applicazioni del Web 2.0. Ma poichè non servono ai nuovi utenti, non sono messi in evidenza, e sono in caratteri piccoli. Per vederli bisogna addirittura effettuare uno scroll verticale della pagina.

 

 

Figura 21.       Home page di http://www.dropbox.com

Una tecnica molto utile è quella di  organizzare l’interfaccia utente su due o più livelli di complessità, come nell’esempio di Figura 22, tratto da Microsoft PowerPoint 2007. L’utente può specificare gli attributi di base di un carattere di testo mediante una serie di bottoni sempre visibili sullo schermo (A). Attributi meno frequenti possono essere specificati aprendo un pannello più completo (B), mediante un apposito bottone (C).  In questo modo, le opzioni sempre visibili sono in numero limitato, sono facilmente comprensibili e permettono di trattare i casi più comuni, ma il sistema è in grado di gestire anche le richieste degli utenti più evoluti, con un’interfaccia più ricca.

Figura 22.       Organizzazione delle funzioni su due livelli (da Microsoft PowerPoint 2007)

 

Molto importanti,  per facilitare l’accesso iniziale al sistema, sono i valori di default dei principali parametri. Essi dovranno quindi essere scelti in accordo alle modalità d’uso più comuni degli utenti inesperti.

·      Aiuto alla familiarizzazione

Il sistema dovrebbe aiutare l’utente a prendere familiarità con il dialogo, fornendo tutti gli aiuti necessari. Anche in questo caso esistono ottimi esempi fra le applicazioni online più diffuse. Per esempio, www.vimeo.com , una social network per il caricamento e la condivisione di video, suggerisce all’utente una serie di compiti iniziali per familiarizzarsi con il sistema (Figura 23).

 

Figura 23.       Aiuto alla familiarizzazione in www.vimeo.com

 

 

Anche www.digg.com (un sito molto noto che permette agli utenti di segnalare e di votare notizie presenti sul Web), accoglie il nuovo utente, a conclusione del processo di registrazione, suggerendogli alcune attività iniziali (Figura 24).

 

Figura 24.       Aiuto alla familiarizzazione in www.digg.com

Funzionalità più sofisticate possono essere suggerite all’utente successivamente. Questo capita regolarmente nei servizi online, che evolvono continuamente, offrendo nuove funzionalità. Per esempio, Twitter utilizza dei riquadri di testo per comunicare cambiamenti nei servizi offerti, suggerimenti per l’uso del sistema, o altro. L’utente può chiudere questi riquadri  se non è interessato, o approfondirne il contenuto con l’uso di appositi link o bottoni (Figura 25).

 

 

Figura 25.       Annuncio di nuove funzionalità in www.twitter.com

 

·      Aiuto online

Negli esempi precedenti, è il sistema che suggerisce all’utente le azioni per prendere familiarità con le diverse funzioni. Tuttavia, è necessario anche dare all’utente la possibilità di chiedere aiuto quando è lui che lo desidera. Questo è lo scopo dei vari sistemi di help online, tradizionalmente disponibili nei prodotti software.

Per esempio, la Figura 26 mostra come, ponendo il cursore su un controllo di Microsoft Word 2007 (in questo caso il menu a tendina che permette di modificare il colore del testo), appare un messaggio che ne spiega lo scopo. È bene tenere presente che le esigenze di chi sta imparando sono diverse da quelle di un utente esperto e che non esiste una dicotomia netta fra principianti ed esperti. Infatti, uno stesso utente potrebbe conoscere bene certe funzioni del sistema e non avere alcuna esperienza di altre. Per tenere conto di questi aspetti, le spiegazioni e i feedback del sistema possono essere organizzati su più livelli di dettaglio. Così, nell’esempio di Figura 26, alla spiegazione elementare costituita da un’unica frase (Modifica il colore del testo) è associato un approfondimento (Per ulteriori informazioni, premere F1).

 

Figura 26.       Spiegazione  dello scopo di un bottone (Microsoft PoerPoint 2007)

 

Il sistema di help esemplificato in Figura 26 è del tipo più semplice: l’utente indica un oggetto presente sul video e, in sostanza, chiede al sistema: a che cosa serve questo? Ciò non basta: più frequentemente, l’utente desidera un certo risutato, ma non sa come fare per ottenerlo. Vorrebbe, in sostanza, che il sistema fosse in grado di rispondere a una domanda differente: come devo fare per…? A questo scopo sono dedicati i sistemi di help più sofisticati o, quando questi non bastano, i blog o i forum di supporto al sistema. In questo caso, la domanda viene posta direttamente al personale del supporto tecnico o agli altri utilizzatori presenti in rete. L’analisi di questi sistemi, che possono essere complessi, esula dagli scopi di questo libro. Ci limiteremo qui a ricordare che, in molti casi, ci si può limitare alla tecnica, molto più semplice, delle FAQ (Frequently Asked Question), presenti oggi in quasi tutti i servizi online.

 

·      Feedback intermedi

Il dialogo dovrebbe fornire dei feedback sui risultati intermedi e finali di un compito, in modo che l’utente possa imparare dai compiti portati  a termine con successo. Questa tecnica è utilizzata di frequente per le transazioni che avvengono sul Web. Per esempio, quando prenota una stanza d’albergo, o acquista un prodotto, l’utente riceve delle indicazioni che gli permettono di comprendere quali fasi del dialogo ha superato e quali informazioni dovrà ancora fornire per concludere la transazione. Abbiamo già visto l’esempio dell’acquisto di un biglietto ferroviari in cinque fasi (pag.9,  Figura 5). 

 

·      Modello concettuale evidente

Il sistema dovrebbe  aiutare l’utente a costruirsi un modello concettuale appropriato del sistema.  In altre parole, il sistema dovrebbe mostrare chiaramente una propria logica interna, il più possibile semplice e coerente. Lo scopo è di permettere all’utente di orientarsi  con facilità anche per l’esecuzione di compiti che richiedono funzioni non ancora utilizzate. Questo può essere fatto in tanti modi, ma la tecnica più frequente è quella di fornire un modello gerarchico delle funzioni del sistema, attraverso un sistema di menu. La tecnica è sicuramente adeguata per i sistemi più semplici. Quando però il numero delle funzionalità è molto elevato, può risultare difficile trovare quella desiderata all’interno di una struttura a menu molto ramificata, come per esempio quella della Figura 32 a pag.32. Una tecnica per risolvere questo problema è, per esempio, quella adottata dalle applicazioni di Office 2007 della Microsoft, in cui le numerose funzionalità sono rappresentate in forma iconica, in una serie di tab orizzontali che lasciano libera la parte inferiore dello schermo (Figura 27). Ovviamente, la tecnica funziona se le diverse funzioni sono collocate all’interno dei vari tab secondo un criterio che l’utente consideri “naturale”.

 

Figura 27.       Il tab Home di Microsoft Word 2007

 

·      Sperimentazione sicura

Il modo più naturale di imparare a usare un sistema è di sperimentarne l’uso. Un sistema ben progettato dovrebbe quindi permettere all’utente di provarne le funzioni, senza che ciò produca conseguenze negative. Questo si può ottenere mettendo a disposizione dell’utente una funzione di undo, che consenta di annullare le conseguenze indesiderate delle sue azioni.  In questo modo l’utente potrà esercitarsi a usare il sistema esplorandone le caratteristiche, ripristinando lo stato precedente nel caso di esito non desiderato. Le azioni che non potessero essere annullate dovrebbero essere preventivamente segnalate all’utente in modo chiaro, per esempio con un messaggio di avvertimento e una richiesta di conferma. Anche di questo parleremo più dettagliatamente nel Capitolo 11 dedicato alla gestione degli errori dell’utente.

 

·      Riapprendimento facilitato

In tutti i sistemi esistono funzioni che sono usate raramente. Per esempio, in un sistema di contabilità aziendale le funzioni relative alla compilazione del bilancio sono eseguite una sola volta  l’anno. Può accadere allora che l’utente dimentichi, nel lungo periodo di tempo fra un utilizzo e il successivo, come utilizzare queste funzionalità, e le debba quindi apprendere di nuovo. Il sistema dovrebbe quindi fornire un aiuto per questo riapprendimento, trattando le funzioni di uso non frequente in modo particolare.

Ciò è particolarmente importante nel caso di funzionalità di utilizzo raro ma di elevata criticità. In un sistema di sorveglianza domestica, le funzioni che permettono all’utente di intervenire in caso di allarme (per esempio da lontano, con un cellulare) sono usate molto di rado. Infatti, se non si verificano problemi, il sistema non invierà mai alcun allarme. È facile quindi che l’utente, dopo l’iniziale sperimentazione del sistema, si dimentichi come interagire col sistema in caso di allarme.  Poiché però un suo intervento errato in situazioni di emergenza può avere gravi conseguenze, il sistema dovrà ricordargli in modo molto chiaro - e rapidamente - come intervenire. Il progettista dovrà studiare questo dialogo con particolare cura, tenendo anche presente la condizione di stress in cui l’utente potrebbe trovarsi in questa situazione, facendogli commettere degli errori.

Controllabilità

In sostanza, questo principio afferma che è l’utente che deve guidare il sistema. Ciò significa che egli non deve essere costretto a seguire una sequenza rigidamente predeterminata di passi d’interazione: egli dovrebbe poter decidere di sospendere il dialogo quando lo desidera, per riprenderlo successivamente, e di fornire le informazioni richieste dal sistema nell’ordine che gli è più congeniale. Dovrebbe poter cambiare idea durante l’interazione, e modificare gli input da lui già forniti, una o più volte, senza vincoli. In breve, l’interazione deve essere controllata dall’utente, e non dal sistema.

Nelle interfacce semplificate del paradigma “scrivi e leggi” dei primi elaboratori (Capitolo 2), questo principio era spesso violato. Si realizzavano dialoghi del tipo domanda-e-risposta, in cui il sistema poneva una serie di domande, alle quali l’utente doveva rispondere nell’ordine stabilito, senza deroghe. Esempi tipici di questa modalità d’interazione erano i primi sistemi esperti, come quello già illustrato nella Figura 4 del Capitolo 2.

Oggi questo stile d’interazione è praticamente scomparso, e i sistemi lasciano all’utente molta più flessibilità. Per esempio, nei dialoghi guidati da form (Capitolo 2), l’utente può scegliere l’ordine di compilazione dei vari campi e, se lo desidera, può tornare indietro e correggere gli input già forniti. Tuttavia capita non di rado che il progettista, per ridurre la complessità del software da realizzare, introduca delle rigidità nel dialogo che ne compromettono l’usabilità. Per evitarlo, è importante seguire le linee guida seguenti.

·      Tempi dell’interazione controllati dall’utente

L’utente dovrebbe poter impiegare tutto il tempo che desidera per effettuare i vari passi del dialogo, senza che il sistema gli ponga dei vincoli.

I time-out imposti dal sistema, che in qualche caso sono inevitabili, andrebbero introdotti solo in casi di effettiva necessità. Questa raccomandazione può essere in conflitto con esigenze di sicurezza, come avviene per esempio in alcune transazioni sul Web. Per esempio, durante l’accesso a una banca online, dopo un periodo d’inattività da parte dell’utente l’applicazione chiude automaticamente la sessione senza chiedere conferma. Infatti, l’utente potrebbe essersene andato senza effettuare il logout. Per evitare che altri utenti non autorizzati possano subentrare ed effettuare transazioni illecite, la banca preferisce chiudere d’autorità la sessione, anche se questo può comportare un grave disagio all’utente ancora presente.

Queste indicazioni si applicano anche ai messaggi inviati dal sistema. È pratica scorretta far sì che i messaggi restino visibili solo per un tempo limitato (per esempio, alcuni secondi), e poi siano automaticamente rimossi. Infatti, non è lecito assumere che l’utente possa leggerli prima della scadenza del tempo: potrebbe essere distratto o impegnato in altre attività. Ogni messaggio inviato dal sistema dovrebbe restare visibile fino a quando l’utente non ne segnali esplicitamente l’avvenuta lettura, per esempio premendo un apposito bottone di OK.

·      Proseguimento del dialogo controllato dall’utente

L’utente dovrebbe poter decidere come proseguire nel dialogo, senza che il sistema imponga vincoli rigidi. A volte può essere opportuno permettergli di effettuare uno o più compiti secondari durante l’esecuzione del compito principale. Per esempio, quando l’utente riceve una telefonata, il cellulare potrebbe permettergli di inserire “al volo” numero e nome del chiamante nella rubrica, mentre accetta la chiamata.  Oppure, durante una telefonata, l’utente dovrebbe poter accedere alla rubrica, per comunicare un numero all’interlocutore.

·      Punto di ripartenza controllato dall’utente

Se il dialogo è stato interrotto per qualche motivo, l’utente dovrebbe poter scegliere il punto dal quale riprenderlo, se ciò è compatibile con il compito. Per esempio, se l’utente deve interrompere la compilazione di un sms per rispondere a una chiamata, il sistema dovrebbe archiviarlo automaticamente in bozza, per consentirgli di riprendere da dove era stato interrotto.

A volte il motivo dell’interruzione del dialogo è dovuto al fatto che l’utente si accorge di dover modificare qualche input da lui fornito in precedenza. Anche in questo caso, il sistema dovrebbe permettergli di ripartire dal punto desiderato, senza costringerlo a ripartire da capo.  Questa importante linea guida non è seguita, per esempio, dal sistema di prenotazione voli dell’Alitalia. Il processo è suddiviso in 6 fasi, e all’utente viene correttamente indicata la fase in cui si trova (in Figura 28, la fase corrente è Acquista). Tuttavia, se l’utente vuole tornare a una fase precedente, per esempio per modificare i propri dati (forniti nella fase Dati passeggero) o cambiare la scelta del volo (effettuata nella fase Scegli volo), il sistema non glielo permette, costringendolo a tornare alla prima fase (Modifica volo) e ripetere l’intero processo dall’inizio.

Figura 28.       Fasi dell’acquisto di un biglietto aereo in http://www.alitalia.it (2009)

 

·      Reversibilità delle operazioni

Se le operazioni sono reversibili e se il contesto d’uso lo permette, dovrebbe essere sempre possibile annullare almeno il passo più recente del dialogo (e, di conseguenza, annullare lo stesso annullamento).

La disponibilità di una funzione di undo (e redo) migliora sensibilmente la usabilità di un sistema, perché permette di eliminare le conseguenze di azioni errate, ed elimina l’ansia causata dal timore di commettere errori.

I sistemi più sofisticati permettono di annullare numerosi passi del dialogo. Per esempio, le applicazioni di Office 2007 permettono di annullare fino a 100 azioni precedenti (una o più alla volta) e di rieseguirle dopo l’annullamento.  Abbiamo appena visto, nell’esempio precedente, che nel processo di prenotazione voli di Alitalia non è disponibile una funzione di undo per tornare a una fase precedente.

·       Modalità di visualizzazione dei dati controllata dall’utente

È utile che l’utente possa tenere sotto controllo non soltanto la sequenza dei passi del dialogo, ma anche le modalità di visualizzazione dei dati necessari al compito. Questo è particolarmente importante nel caso in cui essi siano numerosi: l’utente dovrebbe essere in grado di controllare quali e quanti dati gli vengono mostrati.

Per esempio, un’agenda elettronica ben fatta, oltre a permettere viste diverse del calendario degli impegni (mensile, settimanale, giornaliero) potrebbe permettere di visualizzare tutti gli appuntamenti con uno specifico cliente.

·      Dispositivo d’interazione scelto dall’utente

All’utente dovrebbe essere permesso di scegliere uno qualsiasi dei dispositivi di input o di output disponibili, se compatibili con il compito.

Per esempio, la funzione di ricerca in un sito web potrebbe essere attivata, dopo avere immesso la parola cercata nell’apposito campo, cliccando col mouse il bottone Cerca, oppure premendo il tasto Enter.

·      Personalizzazione dei valori di default

L’utente dovrebbe essere in grado di definire nuovi valori di default in accordo alle proprie personali esigenze, se compatibili con il compito.

Per esempio, in un word processor, lo stile utilizzato come default  per il testo “normale” dovrebbe poter essere modificato dall’utente.

·      Disponibilità dei dati originali

Dopo la loro modifica, i dati originali dovrebbero rimanere disponibili all’utente, se necessari per il compito.

 

Tolleranza verso l’errore

Nell’interazione con un sistema, anche l’utente più esperto commette inevitabilmente degli errori. È compito dei progettisti concepire sistemi che riducano al minimo la possibilità che questi errori avvengano, e la gravità delle loro conseguenze. Un dialogo si dice tollerante verso gli errori (in inglese, error-tolerant) quando fornisce i risultati desiderati anche in presenza di errori dell’utente, senza (o con minime) azioni correttive da parte sua. Questa proprietà si ottiene mediante accorgimenti diversi, che permettano di prevenire gli errori per quanto è possibile (error prevention), di segnalarli con chiarezza quando avvengono (error handling), suggerendo o effettuando automaticamente le azioni correttive appropriate (error recovery[13]). Si tratta di un tema molto importante per il progettista dei sistemi interattivi. Pertanto, qui di seguito ci limitiamo a riassumere in forma schematica le raccomandazioni contenute nell’ISO 9241, rimandando al Capitolo 11 per approfondimenti ed esempi.

·      Assistenza all’utente

Il sistema dovrebbe aiutare l’utente a evitare di commettere errori negli input da lui forniti, e a scoprire quelli che comunque vengono commessi.

·      Verifica  e convalida dei dati

Prima di procedere all’elaborazione dell’input, il sistema dovrebbe verificarlo e convalidarlo.

·      Prevenzione di azioni non lecite

Il sistema dovrebbe evitare che un’azione dell’utente possa causare una caduta o uno stato indefinito del sistema. Per esempio, se si desidera stampare un documento composto da 35 pagine, il dialogo della funzione di stampa dovrebbe permettere di specificare soltanto numeri di pagina nell’intervallo compreso fra 1 e 35.

·      Richieste di conferma

Prima di eseguire azioni che possano produrre conseguenze gravi e non annullabili, il sistema dovrebbe chiedere conferma all’utente. Per esempio, quando l’utente chiede di cancellare un file.

·      Spiegazione dell’errore

Quando l’utente commette un errore, il sistema dovrebbe fornirgli una spiegazione adeguata, indicando la causa dell’errore e le modalità di correzione.

·      Spiegazioni aggiuntive

Se possibile e opportuno, il sistema dovrebbe fornire all’utente, su sua richiesta, informazioni aggiuntive sulla natura dell’errore e sulla sua correzione.

Per esempio, a fronte di un errore il sistema potrebbe emettere un messaggio conciso, contenente un link a una spiegazione più dettagliata.

·      Assistenza per il recupero

Quando l’utente commette un errore, il sistema dovrebbe fornirgli un supporto attivo per permettergli di ristabilire la situazione corretta.

·      Minimo sforzo di correzione

I passi necessari per correggere un errore dovrebbero essere semplificati al massimo.

Per esempio, a seguito di un input errato, il cursore viene posizionato automaticamente dove è richiesta la correzione.

·      Correzione differibile

L’utente dovrebbe poter rimandare la correzione dell’errore a un momento successivo, a meno che ciò non sia necessario per proseguire nel dialogo.

Per esempio, l’utente dovrebbe essere in grado di completare la compilazione di un indirizzo, anche se il codice di avviamento postale è errato, rimandando l’immissione del codice corretto a un momento successivo. Infatti, per conoscere il codice corretto, potrebbe avere la necessità di consultare una fonte al momento non disponibile.

·      Correzione automatica modificabile

Quando il sistema è in grado di correggere automaticamente un errore commesso dall’utente, dovrebbe avvisarlo della correzione effettuata e permettergli di modificarla.

Per esempio, quando il correttore ortografico di un word processor corregge una parola digitata dall’utente, questi deve essere in grado di modificare la correzione.

Adeguatezza all’individualizzazione

Come si è più volte ricordato, l’usabilità di un sistema è relativa a uno specifico utente, compito e contesto d’uso. È quindi utile che un sistema permetta all’utente di adattarne il comportamento alle proprie specifiche esigenze e capacità. Si dice allora che il sistema è personalizzabile o, nel linguaggio dell’ISO 9241-110, individualizzabile.

La personalizzazione può riguardare numerosi aspetti diversi, quali la lingua, le preferenze in relazione ai compiti da effettuare, le modalità di rappresentazione dei dati, e così via. Alcune linee guida da tenere presenti in relazione a questo principio sono le seguenti.

·      Scelta di rappresentazioni alternative

Il sistema dovrebbe permettere all’utente di scegliere fra varie forme di rappresentazione, adatte alle diverse necessità individuali. La Figura 29 mostra, per esempio, come l’utente possa scegliere il sistema di misura, la valuta, e la rappresentazione di ora, data e numeri nel sistema operativo MacOS della Apple. Queste sono solo una parte delle numerose personalizzazioni possibili, selezionabili dal menu Preferenze del sistema.

 

 

Figura 29.       MacOS Finder 10.6 (2009)

 

Particolarmente importanti sono le possibilità di scelta di rappresentazioni alternative che rendano il sistema accessibile a utenti con disabilità (visive, auditive o di altro tipo). Queste opzioni sono oggi normalmente presenti in ogni sistema operativo, ma dovrebbero essere fornite anche in ogni applicazione di pubblica utilità.

Per esempio, un sito web permette di visualizzare i testi in modalità “alto contrasto”, per facilitarne la lettura agli utenti ipo-vedenti.

·      Scelta dei formati dei dati input e output

L’utente dovrebbe poter scegliere le rappresentazioni più appropriate per il formato dei dati elaborati nello specifico contesto applicativo.

·      Vocabolario personalizzabile

In molti casi, è utile poter arricchire il vocabolario usato dal sistema, per aggiungere eventuali termini utilizzati nel contesto specifico.

Un buon esempio è fornito da http://www.ning.com, un servizio online che permette di realizzare delle social network private. Il sistema è multi-lingue: l’amministratore di ogni social network può scegliere la lingua che il sistema userà per le voci dei menu e i suoi messaggi, fra numerose possibilità. La traduzione dei testi base in inglese, però, non è rigidamente prefissata:  l’amministratore, se lo desidera, la può cambiare, semplicemente modificandola in una tabella (Figura 30).

 

 

 

Figura 30.      Personalizzazione della traduzione in www.ning.com (2009)

 

·      Scelta del livello delle spiegazioni

Il livello di dettaglio e/o la forma delle spiegazioni (per esempio, nei messaggi di errore o nei testi di help) dovrebbe essere modificabile in funzione del livello di conoscenza dell’utente.

·      Personalizzazione dei tempi di risposta

L’utente dovrebbe poter modificare i parametri relativi ai tempi di risposta dei dispositivi di input e di output, per adattarli alle proprie personali esigenze.

Per esempio, i sistemi operativi permettono normalmente di impostare vari parametri, quali la sensibilità del mouse e l’intervallo temporale accettato dal sistema per il “doppio clic”, e altri, in funzione delle preferenze dell’utente. La Figura 23 del Capitolo 4 mostra il pannello del sistema operativo del Mac che permette di regolare i parametri del mouse.

 

·      Scelta del metodo d’interazione

Quando appropriato, l’utente dovrebbe poter scegliere fra diverse tecniche di dialogo o metodi d’interazione.

Per esempio, un word processor permette di salvare un documento selezionando la voce di un menu, o cliccando su un’icona, o digitando una combinazione di tasti. Un sistema per l’acquisto di biglietti aerei permette all’utente di specificare la data selezionandola su un calendario oppure, semplicemente, digitandone il valore nel campo a essa dedicato, come nell’esempio di Figura 31 .

 

Figura 31.       Selezione della data in www.alitalia.it (2009)

·      Personalizzazione del dialogo

Se appropriato, l’utente dovrebbe poter modificare alcune componenti del dialogo, per adattarlo a specifiche necessità nell’effettuazione dei compiti.

La personalizzazione può essere più o meno spinta. Per esempio, in un word processor l’utente può scegliere quali toolbar debbano essere visualizzate. In questo modo, se l’utente non ha necessità di utilizzare strumenti di composizione grafica (per esempio, perché il documento in costruzione non contiene figure), potrà evitare di affollare il video con comandi che non gli servono.

Un altro esempio di personalizzazione, tratto dal word processor Word 2008 per Mac, è mostrato in Figura 32. L’utente può definire un proprio glossario di frasi che utilizza di frequente, che potranno poi essere inserire nel testo in costruzione semplicemente selezionandole da un menu. Riferendoci all’esempio, l’utente potrà scegliere da un menu di formule di chiusura la frase “Con i migliori saluti” e chiederne l’inserimento nel testo. La frase selezionata sarà stata da lui precedentemente inserita nel glossario utilizzando un’apposita funzione. Questo meccanismo può essere molto utile per aumentare l’efficienza della composizione di particolari tipi di testi costituiti da clausole standard ripetute di frequente, come per esempio i documenti contrattuali.

 

 

Figura 32.       Microsoft Word 2008 per Mac

 

Lo stesso word processor  permette, ancora, di personalizzare gli stessi menu dei comandi,  aggiungendo o eliminando particolari voci.

 

·      Rispristinabilità dei valori precedenti

I sistemi interattivi più evoluti forniscono di solito ampie possibilità di personalizzazione. Questo può creare delle difficoltà all’utente, che potrebbe dimenticare quali personalizzazioni ha attivato. È quindi importante che il sistema presenti  un quadro chiaro del valore dei parametri, e che l’utente possa ripristinare facilmente le impostazioni di default o quelle da lui stesso definite precedentemente. Nel caso di sistemi utilizzati da più utenti, ciascuno di essi dovrebbe poter memorizzare i parametri di personalizzazione in un proprio profilo, per poter attivare  velocemente la propria configurazione. 

 

Sintesi delle linee guida

In questo capitolo abbiamo descritto i principi dell’ISO 9241-110 e numerose linee guida per la progettazione dei dialoghi uomo-sistema, inquadrandole in questi principi.  Queste linee guida, liberamente ispirate alle raccomandazioni presenti nel documento dell’ISO, sono state illustrate con numerosi esempi tratti da sistemi di varia natura e tecnologia, realizzati in periodi diversi. Esso sono le seguenti.

Adeguatezza al compito                                                                        

·      Dialogo adeguato al compito                                          

·      Informazione adeguata al compito

·      Dialogo essenziale

·      Dispositivi di input e output adeguati al compito

·      Formati di input e output adeguati al compito

·      Default tipici

·      Compatibilità con i documenti

Auto-descrizione

·       Guida per l’utente

·       Interazione evidente

·       Descrizione dell’input atteso

·       Stato visibile

·       Formati descritti

·       Manualistica minima

Conformità alle aspettative dell’utente

·       Linguaggio familiare

·       Aderenza alle convenzioni

·       Organizzazione abituale

·       Dialogo consistente

·       Feedback conforme alle aspettative

·       Tempi di risposta conformi alle aspettative  

·       Messaggi adeguati al contesto

·       Messaggi in posizione appropriata

·       Input in posizione attesa

·       Stile coerente dei messaggi

Adeguatezza all’apprendimento

·      Bassa soglia di apprendimento

·      Aiuto alla familiarizzazione

·      Aiuto online

·      Feedback intermedi

·      Modello concettuale evidente

·      Sperimentazione sicura

·      Riapprendimento facilitato

Controllabilità

·       Tempi dell’interazione controllati dall’utente

·       Proseguimento del dialogo controllato dall’utente

·       Punto di ripartenza controllato dall’utente

·       Reversibilità delle operazioni

·       Modalità di visualizzazione dei dati controllata dall’utente

·       Dispositivo d’interazione scelto dall’utente

·       Personalizzazione dei valori di default

·       Disponibilità dei dati originali

Tolleranza verso l’errore

·       Assistenza all’utente

·       Verifica  e convalida dei dati

·       Prevenzione di azioni non lecite

·       Richieste di conferma

·       Spiegazione dell’errore

·       Spiegazioni aggiuntive

·       Assistenza per il recupero

·       Minimo sforzo di recupero

·       Recupero differibile   

·       Recupero automatico modificabile

Adeguatezza all’individualizzazione

·       Scelta di rappresentazioni alternative

·       Scelta dei formati di input e output

·       Vocabolario personalizzabile

·       Scelta del livello delle spiegazioni

·       Scelta del metodo d’interazione

·       Personalizzazione del dialogo

·       Ripristinabilità dei valori precedenti

·       Personalizzazione dei tempi di risposta.

 

Si tratta di principi e linee guida del tutto generali, che non dipendono dalle specifiche tecnologie d’interazione utilizzate, che possono essere molto diverse (Figura 4 del Capitolo 1). Il sistema ci può trasmettere informazioni attraverso il senso della vista o dell’udito, oppure (ma più raramente) generando sensazioni tattili. A sua volta, l’uomo può comunicare utilizzando le mani, attraverso l’uso di tastiere o altri dispositivi di manipolazione,  la voce (attraverso sistemi di riconoscimento vocale) oppure, anche se più raramente, con i movimenti del proprio corpo, che il sistema può rilevare attraverso sensori opportunamente collocati nello spazio o perfino con lo sguardo (utilizzando apparati di eye-tracking).

Ogni dispositivo possiede caratteristiche specifiche, e interagisce con il sistema percettivo, cognitivo o motorio dell’utente in modo diverso. Sarebbe quindi utile introdurre delle raccomandazioni specifiche per ciascuno di questi dispositivi, allo scopo di orientare il progettista verso le soluzioni di progetto più corrette dal punto di vista dell’usabilità. Questo richiede, da una parte, l’analisi delle caratteristiche tecnologiche e funzionali dei diversi dispositivi e, dall’altra,  lo studio delle abilità umane coinvolte nel loro utilizzo.

Tutto ciò ci porterebbe lontano, ed esula dagli scopi di questo libro, che ha carattere introduttivo. Ci limiteremo, pertanto, a fornire qualche indicazione generale solo per quanto riguarda la comunicazione visiva, per il suo ruolo privilegiato rispetto ad altri canali di comunicazione.  A questo argomento è dedicato il Capitolo 12 e, per quanto riguarda l’uso del testo, il Capitolo 13.

Ripasso ed esercizi

1.     Descrivi le differenze fra principi, linee guida, regole di progetto e standard.

2.     Quali sono i principali standard prodotti dal Technical Committee 159/SC 4 dell’ISO?

3.     Riassumi i sette principi del dialogo secondo la ISO 9241.

4.     Esamina, alla luce delle linee guida descritte in questo capitolo, l’interfaccia interna ed esterna dell’ascensore di casa tua. A tuo parere, il progetto di queste interfacce è coerente con queste linee guida? In caso contrario, quali sono i difetti e con quali conseguenze dal punto di vista dell’usabilità?

5.     Che cosa significa, secondo l’ISO 9241, che un dialogo è controllabile? Quali sono, a tuo parere, le motivazioni che hanno portato gli autori dello standard a inserire la controllabilità fra i principi di base del dialogo?

6.     Esamina le differenti possibilità di personalizzazione previste dal sistema di word processing che utilizzi normalmente. Quali sono? Quali potresti utilizzare e come, in funzione delle tue specifiche necessità e abitudini?

7.     Esamina i diversi sistemi di help del word processor che usi di solito, e riassumine per punti le caratteristiche salienti. Li ritieni adeguati? Perché?

8.     Esamina criticamente l’elenco delle linee guida riportato a pag.33. Ritieni che ci siano delle sovrapposizioni e delle ridondanze? Quali? Ne proporresti una semplificazione? Quale?

Approfondimenti e ricerche

1.    Scarica il documento Research-based Web Design and Usability Guidelines, citato in nota a pagina 2, che contiene oltre 200 linee guida per l’usabilità dei siti web. Confronta queste linee guida con quelle discusse nel presente capitolo, e associa ciascuna linea guida ad uno dei sette principi del dialogo dell’ISO 9241. Suggerimento: dovrebbe essere sufficiente confrontare l’elenco delle linee guida di pag.33 con l’elenco delle linee guida  riportato in testa al citato documento, esaminando la relativa scheda descrittiva solo in caso di dubbio.

2.     Le linee guida per la progettazione delle interfacce utente del Macintosh e di Windows Vista sono contenute, rispettivamente, nei documenti Apple Human Interface Guidelines, e Windows User Experience Interaction Guidelines, reperibili in rete agli indirizzi:
http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines e http://msdn.microsoft.com/en-us/library/aa511258.aspx.

Esamina questi documenti, in particolar modo le sezioni relative a icone, menu, windows, messaggi, controlli e layout.

3.     Il libro di A.Dix, J.Finlay, G.Abowd e R.Beale, Interazione uomo macchina, (ed.italiana McGraw-Hill, 2004) descrive un insieme di principi per la progettazione di buone interfacce, diversi da quelli dell’ISO 9241. Questi principi, che sono chiamati nel libro “regole di design”, sono dettagliatamente descritti nel Cap. 7 dell’edizione italiana  (pagg.253-284), organizzati in tre gruppi: Apprendibilità (composto da 5 principi), Flessibilità (5 principi) e Robustezza (4 principi). Esamina in dettaglio questi principi e costruisci una tabella che li pone a confronto con i principi ISO e con le relative raccomandazioni. Quale dei due insiemi è più comprensivo? Ci sono principi presenti solo in una delle due formulazioni? Quali?

4.     Verifica la evoluzione degli standard prodotti dal comitato TC159/SC 4, sul sito http://www.iso.org.