Usabilità ed accessibilità

1. Usabilità ed accessibilità Prof. Roberto Pirrone Corso di Fondamenti di Informatica COM1-COM5 e S.E.C.I. a.a. 2004/2005

2. Usabilità • L’obiettivo del processo di progetto e realizzazione di un sistema interattivo, quale è il web, deve essere la massimizzazione dell’usabilità del sistema. • Quali sono le caratteristiche, i metodi e gli strumenti di un processo di progetto e realizzazione orientato all’usabilità? • Come si può dimostrare e/o misurare l’ usabilità di un sistema interattivo? • Approcci empirici: tecniche di interazione tradizionalmente efficaci • Approcci formali: metodi derivati dalla psicologia, l’informatica e le scienze sociali Alan Dix, Janet Finlay, Gregory Abowd, Russel Beale, “Interazione uomo-macchina”, McGraw-Hill 2004, http://www.hcibook.com

3. Definizioni di usabilità • La proprietà che riflette la facilità di impiego di un sistema informatico (1971) • L’insieme delle seguenti caratteristiche: effettività, apprendibilità, flessibilità e atteggiamento (1991) • L’insieme delle seguenti caratteristiche: facilità di apprendimento, efficienza nell’impiego, facile da ricordare, pochi errori, soggettivamente gradevole (1993)

4. Definizioni di usabilità • Il livello di efficacia, efficienza e soddisfazione da parte degli utenti raggiunto da un prodotto che venga utilizzato da specifici utenti per raggiungere determinati scopi in determinati ambienti (1993) • L’insieme delle proprietà funzionali e non funzionali rilevanti ai fini della produttività e soddisfazione dell’utente finale (1997)

5. Definizioni standard di usabilità • Usabilità ISO-9241_11: • la capacità di un prodotto di agevolare uno specifico utente nel raggiungimento di specifici obiettivi con efficacia, efficienza e soddisfazione in uno specifico contesto d’uso • Usabilità ISO-9126 • la capacità del software di essere compreso, appreso, usato con soddisfazione dall’utente in un determinato contesto d’uso

6. Altre definizioni • Qualità del sw: • capacità intrinseca ed estrinseca del sistema sw di servire al raggiungimento dello scopo dell’Utente e della sua Organizzazione • Utenti: • utenti diretti e indiretti che si trovano ad interagire con il sistema software • Contesto d’Uso: • un insieme di condizioni reali e vincoli associati rilevabili e documentabili in cui l’Utente interagisce con il sistema software per gli scopi suddetti • Compito (task): • un insieme di operazioni svolte dall’Utente in interazione con il sistema al fine di raggiungere uno scopo rilevante per l’Utente e per la sua Organizzazione

7. Vantaggi dell’usabiltà • Permette di focalizzarsi sui bisogni dell’utente e dell’organizzazione • Riduzione dei tempi di sviluppo • Diminuzione del training necessario • Aumenta la produttività • Diminuzione degli errori dell’utente • Migliora la qualità dei prodotti • Aumento di profilo di prodotti competitivi • Diminuzione dei tempi e costi di manutenzione • Migliora la qualità della vita • Riduzione dello stress e aumento della soddisfazione dell’utente • Miglioramento dell’ambiente di lavoro • Permette di rispettare le direttive europee

8. Usabiltà e progettazione • L’usabilità misura la distanza tra il “designer model”, ovvero il modello del sistema informatico e delle sue modalità d’uso posseduto dal progettista, e lo “user model”, il modello di funzionamento del sistema che l’utente si costruisce e che regola la sua interazione col sistema stesso. • Quanto più i modelli sono vicini, tanto più il sistema è da considerarsi “usabile”.

9. La norma ISO 9241_10 • Scopo • illustrare i principi ergonomici da adottare per la progettazione e la valutazione di dialoghi utente-sistema • Contenuto • idoneità al compito • autodescrittività • controllabilità • conformità alle aspettative • tolleranza agli errori • idoneità alla personalizzazione • idoneità all’apprendimento

10. Idoneità al compito • un dialogo utente-sistema è adatto al compito quando aiuta ad eseguirlo: • presentare solo le informazioni pertinenti alla particolare fase di esecuzione del compito • progettare l’HELP in modo da renderlo sempre pertinente alla fase di esecuzione del compito • progettare le funzioni in modo da limitare l’intervento dell’utente • progettare tenendo conto dell’esperienza e della competenza dell’utente

11. Autodescrittività • Un dialogo utente-sistema è autodescrittivo quando è immediatamente comprensibile • fornire sempre messaggi di conferma • utilizzare sempre terminologia comprensibile • fornire sempre spiegazioni pertinenti alla specifica fase di esecuzione del compito • progettare la messaggistica in modo da evitare i continui ricorsi a materiale di supporto (help e manuali) • fornire liste di valori di default

12. Controllabilità • Un dialogo utente-sistema è controllabile quando l’utente è in grado di scegliere in ogni punto e poter tornare indietro • progettare il dialogo in modo che sia possibile: • ritornare sempre al punto di partenza • annullare l’ultima operazione • ritornare all’ultimo punto di scelta • modificare il ritmo e la velocità di visualizzazione • selezionare i dispositivi di inserimento/selezione/puntamento più adeguati

13. Conformità alle aspettative dell’utente • Un dialogo utente-sistema è conforme se corrisponde alle caratteristiche (esperienza, conoscenza del dominio, etc.) degli utenti • progettare il dialogo in modo da rendere consistenti i passi di dialogo anche tra sistemi diversi • progettare le azioni necessarie allo svolgimento del dialogo in modo coerente

14. Tolleranza agli errori • Un dialogo utente-sistema è tollerante agli errori se nonostante gli errori commessi il risultato può essere raggiunto con poco sforzo: • fornire sempre la spiegazione degli errori • progettare sempre al fine di evitare gli errori più frequenti • se il sistema è in grado di eliminare gli errori automaticamente, lasciare comunque sempre agli utenti la possibilità di rivedere il risultato

15. Idoneità alla personalizzazione • Un dialogo utente-sistema è personalizzabile quando può essere modificato in base alle esigenze dell’utente: • fornire sempre modalità di modifica di visualizzazione dei dettagli e/o del livello di AIUTO • fornire se possibile comandi personalizzati • fornire acceleratori e macro

16. Idoneità all’apprendimento • Un dialogo utente-sistema è idoneo all’apprendimento quando guida l’utente nell’acquisizione delle modalità di utilizzo • fornire supporto a diverse strategie di apprendimento (basato su testi, esercitazione, dimostrazioni, tutorial, etc...) • fornire se possibile possibilità di accesso rapido a informazioni necessarie all’apprendimento • rendere disponibile all’utente un insieme di strumenti coerenti per acquisire conoscenza

17. La norma ISO 9241_11 • La norma 9241_11 fornisce la guida per la valutazione dell’usabilità di un sistema software. • Usabilità = Qualità in Uso: • la misura in cui un prodotto sw (o una componente interattiva del sistema sw) viene utilizzato da specifici utenti per raggiungere specifici obiettivi con efficacia, efficienza e soddisfazione in uno specifico contesto d’uso. • In questa norma si danno delle indicazioni per quella che si chiama usability engineering.

18. Definizioni • Efficacia: • l’accuratezza e la completezza con cui utenti del sistema raggiungono gli scopi per cui il sistema è stato progettato • Efficienza: • il rapporto tra l’efficacia dell’interazione e le risorse spese (tempo, lavoro, carta...) per raggiungere gli scopi • il rapporto tra la qualità dei risultati raggiunti e le risorse fisico-mentali spese

19. Definizioni • Soddisfazione: • misure oggettive: stress e carico mentale tramite osservazione psico-fisiologica • il comfort con cui l’utente svolge i propri compiti e raggiunge gli scopi senza eccessivi carichi • misure soggettive: questionari di soddisfazione dell’interazione • la piacevolezza e il benessere percepito dall’utente durante lo svolgimento di compiti al fine di raggiungere scopi specifici

20. Il piano di valutazione • I passi del piano: • identificare gli scopi del sistema ed eventualmente scomporli in attività (es. scrivere una lettera, utilizzare un correttore ortografico, etc..) • identificare il contesto d’uso del sistema (es. utenti, compiti, vincoli organizzativi e di ambiente tecnologico, etc.) • identificare dei valori/soglia di efficacia, efficienza e soddisfazione

21. La scelta delle misure • Misure di efficacia: • esse sono legate agli scopi e alle attività previste per il sistema e misurano l’accuratezza con cui il sistema permette di raggiungere gli scopi • Es. se lo scopo è “scrivere una lettera” allora le misure possibili sono: • il NUMERO degli errori ortografici • la selezione IN TEMPI BREVI (entro UN NUMERO MASSIMO DI CLICK) del formato di stampa ottimale, etc..

22. La scelta delle misure • Misure di efficienza: • esse sono legate al consumo di risorse necessarie al raggiungimento degli scopi: • Es. se lo scopo è “stampare un report” allora le misure possibili sono: • il NUMERO delle copie stampate in una unità di tempo • il RAPPORTO tra il numero complessivo delle copie stampate e il numero delle copie stampate correttamente • il NUMERO delle copie stampate non valide

23. La scelta delle misure • Misure di soddisfazione: • esse sono legate al comfort e alla soddisfazione dell’interazione: • piacevolezza nell’uso del sistema • accettabilità del carico di lavoro mentale • numero dei commenti negativi/positivi durante l’uso • scale di soddisfazione legate a: • supporto all’apprendimento • efficienza globale • supporto alla memorizzazione di passi specifici

24. User Centered Design • A supporto della usabilità sono nate le tecniche di sviluppo human centered (o user centered) che si fondano su: • l’attivo coinvolgimento degli utenti, al fine di ottenere una chiara identificazione dei requisiti utente, dei loro compiti e del contesto d’uso, ed una appropriata allocazione tra utente e sistema delle funzioni da sviluppare; • un processo iterativo di disegno della soluzione, che faccia uso per quanto più possibile di prototipi; • la presenza di competenze multidisciplinari nel team di progettazione

25. Norma ISO 13407 • Obiettivi: • definizione dei requisiti di base per la “certificazione” dei processi di produzione del software centrato sull’utente • Contenuti: • definizione delle regole di documentazione del processo sul modello dell'ISO 9000 • Applicazioni • per orientare il lavoro cooperativo e certificarlo • relazione con lo standard IS12207

26. Human-centered Design (dalla 13407) • Un approccio allo sviluppo di sistemi interattivi focalizzato specificatamente sul rendere il sistema usabile. E’ una attività multidisciplinare, che richiede competenze e tecniche specifiche di ergonomia. La applicazione di tali metodi e tecniche al disegno di sistemi interattivi ne aumenta la efficacia e la efficienza, migliora le condizioni di lavoro, contrasta possibili efffetti nocivi sulla salute dei lavoratori, sulla sicurezza e sulle prestazioni. Applicare la ergonomia al disegno di sistemi richiede di considerare fattori primari le capacità competenze, conoscenze, limitazioni ed esigenze degli utenti.

27. I Principi della norma • Principi di progettazione “centrata sull’utente”: • coinvolgimento attivo degli utenti • comprensione dei requisiti degli utenti e dei compiti • allocazione appropriata di funzioni tra gli utenti e il sistema • iterazione delle soluzioni di progettazione (prototipi) • progettazione multi-disciplinare

28. Il ciclo di sviluppo

29. Il contesto d’uso • E’ un documento che contiene: • caratteristiche degli utenti • caratteristiche dei compiti e allocazione di attività tra utenti e sistema • vincoli socio-organizzativi e di ambiente tecnologico • Il documento viene: • validato dagli utenti • rivisto ciclicamente • influenza la progettazione

30. I requisiti utente e organizzativi • E’ un documento che contiene: • la descrizione approfondita degli scopi del sistema • stabilisce la priorità tra i diversi requisiti (che possono anche essere in conflitto) • include eventuali requisiti di legge • stabilisce gli obiettivi di usabilità che guideranno la successiva valutazione • Viene validato dagli utenti

31. Le soluzioni di progettazione • Produrre diverse soluzioni (multi-disciplinari) in uno spazio di soluzioni. • Utilizzare simulazioni, “mock-up” e prototipi e documentarne l’evoluzione. • Coinvolgere gli utenti anticipatamente in modo da esplorare e validare le scelte. • Iterare le soluzioni fino ad arrivare a quella ottimale (best-fit).

32. Valutare le soluzioni • La valutazione delle scelte di progettazione è cruciale! • stilare un piano di valutazione • effettuare una valutazione durante tutte le fasi del ciclo di vita del sistema (con o senza utenti) • identificare le anomalie e i difetti più rilevanti • selezionare la soluzione di progetto migliore rispetto ai requisiti

33. I criteri di valutazione • Selezione dei metodi appropriati per il particolare stato di sviluppo del sistema • Analitici vs. Empirici • Basati su esperti • orientati alla applicazione di linee guida generali • orientati alla verifica di conformità a standard • Basati su utenti • orientati alla raccolta di feedback anticipato • orientati alla esecuzione controllata di compiti • Documentazione delle procedure e dei risultati della valutazione

34. Metodi basati sugli Utenti • User testing con utenti reali, attraverso esperimenti controllati effettuati in laboratori di usabilità • Osservazione diretta • Questionari e interviste • Focus Groups • Analisi dei files di log • Feedback • Misurazione delle performances del sistema • Thinking aloud

35. Metodi basati su eperti • Valutazione euristica (ispezione sistematica del progetto dell’interfaccia utente per verificarne l’usabilità) • Pluralistic usability walkthrough

36. Valutazione Analitica • Permette di effettuare previsioni su alcuni aspetti parziali dell'usabilità di un sistema prima che il primo prototipo del sistema stesso venga realizzato. È un metodo basato sul costruire un modello formale del sistema che permette di predire, per esempio, il tempo necessario ad un utente esperto ad effettuare un certo compito senza errori. • Purtroppo, l'utilizzo di questo metodo, oltre a richiedere l'intervento di un esperto che costruisca il modello formale, porta a risultati marginali e non tiene conto del contesto d'uso del sistema.

37. Valutazione Tramite Esperto • Sfrutta la conoscenza di un esperto nel campo della interazione uomo-macchina per effettuare previsioni sull'usabilità del sistema a partire da un prototipo che può essere anche cartaceo (cioè che simuli sulla carta possibili schermate del sistema). • Il maggior difetto di questo metodo, che pure offre il vantaggio di una analisi approfondita dei fattori che determinano l'usabilità del sistema, è quello di dipendere dal giudizio di un singolo esperto, che non è comunque l'utente finale.

38. Osservazione Diretta • Coinvolge utenti reali che vengono osservati durante l'interazione con il sistema. Per questo motivo può essere utilizzato solo quando un reale prototipo del sistema è stato prodotto. Inoltre, è preferibile non osservare direttamente le persone che interagiscono con il sistema, ma filmarle ed analizzare il film. Questo permette di evidenziare i punti critici dell'interazione. • L'aspetto più costoso di questo metodo è costituito dal tempo necessario ad analizzare i filmati sugli utenti. Per ovviare a questo inconveniente sono stati approntati degli strumenti software che aiutano nell'analisi dei filmati.

39. Questionari/Interviste • È basato sull'analisi delle opinioni, aspettative, reazioni, ecc. degli utenti, che vengono estesamente consultati tramite questionari ed interviste. I questionari possono essere usati in più fasi dello sviluppo del progetto, sia inizialmente, sia nelle varie fasi di sviluppo del prodotto per testare le reazioni degli utenti. • È essenziale progettare correttamente i questionari e le domande da porre agli utenti nel corso delle interviste. Una volta che ciò sia stato fatto, è possibile effettuare una valutazione affidabile dell'usabilità del sistema. • In particolare, per le fasi finali della valutazione esistono degli strumenti software che forniscono un ausilio nella progettazione dei questionari e nella valutazione della soddisfazione dell'utente in base alle risposte alle varie domande.

40. Esperimenti Controllati • È particolarmente valido per verificare l’usabilità di un sistema in tutte le fasi del ciclo di vita. Inoltre, permette di verificare se un cambiamento nel progetto del sistema possa inficiarne l'usabilità. Permette sia di effettuare un test sull'usabilità dell'intero sistema, che di confrontare diverse scelte progettuali locali. • In quest’ultimo caso, è preferibile applicarlo una volta che siano disponibili prototipi che presentano le varie alternative, ed è molto importante che tutti i prototipi differiscano esclusivamente nell'aspetto da scegliere.

41. Usabilità e PA • Grande varietà e quantità di utenti • operatori dei vari settori P.A. • cittadini • portatori di handicaps (problemi di accessibilità) • Mancanza di una specifica preparazione tecnica da parte dell’utenza • Varietà di applicazioni, da generiche ad altamente specialistiche

42. Usabilità e PA • Informatizzazione dei processi amministrativi, nuove tecnologie e strumenti informatici • RUPA: Rete informativa Unitaria delle Pubbliche Amministrazioni • SIU: Sistema Informativo Unitario delle pubbliche amministrazioni • Necessità di valutare gli strumenti informatici prodotti dai vari fornitori • Desiderata • trasparenza degli atti • diritto all’informazione • disponibilità dei servizi • qualità dell’informazione

43. Centro Nazionale per l’Informatica nella PA • Il CNIPA http://cnipa.gov.it/ è il centro che si è evoluto dall’AIPA (Autorità per l’Informatica nella Pubblica Amministrazione) che segue tutte le problematiche legate all’applicazione della ICT nella PA. • Il CNIPA emette circolari e raccoglie tutta la normativa vigente in materia. Inoltre possiede un archivio di studi di settore in campo ICT ed emette un bollettino informativo periodico. • Esso ha attribuzioni in campo di: • Usabilità • Accessibilità • Controllo di qualità del software • Applicazione delle normative sul software Open Source • Sicurezza • Certificazione (PEC: Posta Elettronica Certificata)

44. Gruppo di lavoro sull’Usabilità • Il Gruppo di lavoro sull’Usabilita’ dei sistemi interattivi della PA (GLU), formalizzato dall’AIPA con deliberazione N. 53 del 22 Ottobre 1997 aveva i seguenti obiettivi: • Definizione delle linee guida per la stesura di studi di fattibilità che includano l’usabilità come parametro essenziale in termini di costi, benefici e rischi connessi alla produzione,di sistemi informatici con una significativa componente interattiva. • Conduzione di una sperimentazione con il fine di individuare le linee guida per la definizione di un sistema usabile nella Pubblica Amministrazione.

45. Gruppo di lavoro sull’Usabilità • Attività del GLU • Redazione di un documento introduttivo sull’usabilità. • Redazione di un primo documento che delinea le caratteristiche di un generico “sistema usabile” nell’ambito della P.A. • Sperimentazione di strumenti sw per la P.A. • Ministero di Grazia e Giustizia (sistema per reperire informazioni necessarie a creare documenti) • Ministero delle Finanze (sistema per reperire/scambiare informazioni tra vari uffici, per diversi scopi

46. Sperimentazioni • Obiettivi dell’analisi • Modalità di lavoro del team di progettazione • Modalità di partecipazione degli utenti PA alle varie attività di progettazione • Valutazione degli utenti riguardo l’usabilità dei prodotti • Metodologia utilizzata • Interviste al team di progettazione • Interviste agli utenti finali (dopo un test di utilizzo del prodotto) • Risultati dell’analisi • Usabilità = Costo • Carenze culturali e metodologiche • Carenze organizzative • Desiderio di partecipazione da parte dell’utenza

47. Problemi Rilevati • Carenze Organizzativo/Contrattuali • Chi commissiona il prodotto non ne sarà l’utente finale • Chi effettua i collaudi non è l’utente finale • Il coinvolgimento degli utenti non è richiesto o regolato da contratti • Nei Piani di qualità non è citata l’usabilità • I collaudi riguardano la funzionalità e l’affidabilità • La soddisfazione dell’utente non è mai rilevata • Le griglie di aggiudicazione non premiano l’usabilità • Carenze Metodologico/Culturali • Mancanza di una formazione adeguata • Processi di sviluppo che in genere non sono user-centered, non analizzano il contesto e le esigenze degli utenti • Mancanza di competenze interdisciplinari nei team di sviluppo • Scarso coinvolgimento dell’utente, soprattutto nelle fasi iniziali del progetto

48. Possibili Cause • Persistenza di vincoli tecnologici ed applicazioni obsolete • Scarso ritorno per i fornitori rispetto ad eventuali costi sostenuti per migliorare l’usabilità dei prodotti • Mancanza di conoscenza su metodologie di sviluppo avanzate “user-centered” • Mancanza di percorsi formativi adeguati • Scarsa attenzione dei committenti a problematiche legate all’usabilità • Scarso coinvolgimento e responsabilizzazione dell’utente finale nel processo di progettazione del prodotto

49. Possibili Interventi • Requisito di usabilità inserito negli studi di fattibilità • Premiare la qualità nelle gare d’appalto, adottando criteri di giudizio che tengano conto dell’utente (progettazione user-centered, test di usabilità, rilevamento della soddisfazione dell’utente) • Formare l’utenza • Prevedere il monitoraggio della usabilità e l’eventuale miglioramento del prodotto nell’ambito delle procedure di assistenza e manutenzione dopo il rilascio • Inserire la valutazione di usabilità nell’ambito del monitoraggio

50. Web usability • Per parlare di usabilità del web si deve tener conto di alcune peculiarità che il web possiede rispetto ad altri sistemi software di natura interattiva: • Accesso navigazionale all’informazione • Estrazione dell’informazione (compito spesso arduo…) • L’utente controlla la navigazione • Utenza enorme e variegata • Impatto sociale del Web Jakob Nielsen, “Web Usability – la pratica della semplicità”, Apogeo 2000, http://www.useit.com/jakob/webusability/