Progettazione dell’ interazione

Presentazione sul tema: "Progettazione dell’ interazione"— Transcript della presentazione:

1 Progettazione dell’ interazione
Metodi e Tecniche 6 lezione 19 Marzo 2004

2 Agenda Principi di Progettazione centrata sull’utente
Metodi per la Progettazione centrata sull’utente Raccolta dei requisiti Analisi dei compiti (Task Analysis) 6 lezione 19 Marzo 2004

3 Design Anche riferito ai soli sistemi di calcolo, il termine design può avere diversi significati. Jones, 1981, ne trova vari: ‘Finding the right physical component in a physical structure’ ‘A goal-directed problem solving activity’ ‘Simulating what we want to make before we make it as many times as may be necessary to feel confident with the final result’ ‘A creative activity - it involves bringing into being something new and useful that has not existed previously’ Il termine design può avere diversi significati anche quando è utilizzato nel contesto del progetto di sistemi di calcolo 6 lezione 19 Marzo 2004

4 Design ‘A Design is an information base that describes aspects of an object, and the design process can be viewed as successive elaborations of representations … and exploring alternatives’. Webster, 1988, p. 8 Webster stresses the relationship between design representation and design process. Thus ‘design’ refers to both the process of developing a product, artefact or system and the various representations (simulation or models) of the product that are produced during the design process. Esempio: progettare una brocca di ceramica identificare i requisiti Sviluppare una prima versione migliorarla finchè si è soddisfatti 6 lezione 19 Marzo 2004

5 Progettazione centrata sull’utente
Obiettivo della progettazione centrata sull’ utente è di produrre sistemi che sono facili da imparare e da usare dagli utenti ipotizzati, e che sono sicuri ed efficaci nel facilitare le attività che gli utenti vogliono intraprendere. 6 lezione 19 Marzo 2004

6 La complessità delle organizzazioni e la varietà delle situazioni in cui i sistemi interattivi vengono sviluppati ed usati fa sì che abbiano un ciclo di vita non sempre descrivibile con il modello a cascata: analisi, specifica requisiti, progetto, implementazione. 6 lezione 19 Marzo 2004

7 Ad esempio, accade che il piano di progetto parte dall'uso di sistemi esistenti, che danno risultati ulteriormente migliorabili - il sistema esistente è usato come prototipo, dalla cui valutazione derivano le specifiche di progetto. 6 lezione 19 Marzo 2004

8 Analisys or requirement gathering
Waterfall model B Analisys or requirement gathering A Initiation 1Application description C Design 2 Requirements specification D Implementation 3 System design E’ chiamato “modello a cascata” dello sviluppo di sistemi perché l’ output di ciascun processo (frecce) “casca” bene sulla attività successiva. Questa rappresentazione dello sviluppo del software ha l’ importante caratteristica che ciascun stadio dello sviluppo del prodotto può essere testato per assicurarsi che corrisponda alle richieste del cliente (validation). Questo modello facilita la gestione di un progetto fornendo punti di controllo dello stato di avanzamento e del rispetto dei tempi previsti. Ci sono vari difetti in questo modello: La relazione cliente-fornitore richiede livelli di descrizione non possibili con le tecniche disponibili (1 e 2 sono spesso descritti a parole e si prestano a interpretazioni ambigue). Molti progetti sono decisi d alto livello manageriale ed imposti alle strutture che li useranno. La manutenzione è uno delle attività più importanti e di maggior peso nel ciclo di vita di un prodotto (anche fini al 60% in grossi sistemi) Ci sono cambiamenti organizzativi dovuti all’ introduzione del nuovo sistema che non sono formalmente tenuti in conto nel ciclo di progettazione tradizionale. 4 Product E Operations and management F Validation, verification and testing 6 lezione 19 Marzo 2004

9 Ciclo di vita a stella Implementazione Analisi Funzionale
e dei compiti Prototipazione Valutazione Specifica dei requisiti modello a stella del ciclo di vita, proposto nel 1993 da Debora Hix e Robert Hartson. Progetto formale e concettuale Adattato da Hix e Hartson, 1993 6 lezione 19 Marzo 2004

10 Lo sviluppo di un sistema interattivo può iniziare da ogni attività (frecce unidirezionali verdi) e può proseguire in ognuna delle altre (frecce bidirezionali nere). Il risultato di ogni attività nel ciclo di sviluppo ed uso va valutato rispetto al contesto d'uso ed agli utenti che useranno il prodotto finale. La distinzione fra concettuale e fisico è fondamentale nello sviluppo di un buon sistema perché differisce in avanti nel processo di progettazione le decisioni su chi e cosa svolgano quali funzioni, o forniscano quali dati. 6 lezione 19 Marzo 2004

11 La progettazione specifica la distinzione fra:
La valutazione diventa l'attività centrale nel modello: tutti gli aspetti dello sviluppo e dell'uso di un sistema interattivo sono soggetti ad una costante valutazione da parte di esperti ed utenti, coinvolti con ruoli diversi. La progettazione specifica la distinzione fra: progettazione concettuale (che cosa è richiesto, cosa il sistema deve fare, che dati servono, cosa gli utenti devono sapere, etc) progettazione fisica (come sono ottenute le cose). La distinzione fra concettuale e fisico è fondamentale nello sviluppo di un buon sistema perché differisce in avanti nel processo di progettazione le decisioni su chi e cosa svolgano quali funzioni, o forniscano quali dati. 6 lezione 19 Marzo 2004

12 Analisi funzionale e dei compiti
L'obbiettivo è l'analisi dell'attività che l'utente sta già svolgendo, per individuare quale processo migliorare o modificare. Per compito (task) si intende l'attività dell'utente vincolata ad apparecchiature e metodologie d'interazione e motivata da uno scopo. 6 lezione 19 Marzo 2004

13 Analisi funzionale e dei compiti
L’analisi utilizza tecniche generali di rilevamento come interviste, questionari, checklists, etc. Occorre considerare: la struttura del compito; la struttura degli obbiettivi; i passi necessari; i costi di apprendimento, uso e realizzazione; le conoscenze relative al compito. 6 lezione 19 Marzo 2004

14 Metodi di analisi Hierarchical Task Analysis di natura qualitativa; legato alla struttura logica del compito da svolgere basati sul modello GOMS (Goals, Operations, Methods and Selection rules). Considera: goals: obiettivi dell'utente operations: azioni utilizzate dall'utente per raggiungere gli obiettivi; possono essere motorie, percettive o cognitive methods: definiti come composizione di operazioni elementari selection rules: regole utilizzate dall'utente per selezionare il metodo migliore (rispetto a fatica e costo ma anche ad altri fattori non facilmente determinabili) 6 lezione 19 Marzo 2004

15 Hierarchical Task Analysis
HTA usa come costrutto base la rappresentazione grafica che descrive come un task si decompone nei sottotask e nelle operazioni che lo costituiscono (si occupa della struttura logica di un task). Esempio di un controllo ortografico (structure chat notation, testo pag. 414)). * può essere ripetuta più volte ° si possono scegliere più attività --- non ci sono più azioni Decisione se la parola è sbagliata Non sbagliata ° Sbagliata ° Aggiorna il ° contesto --- ° Trova un suggerimento * Valuta il suggerimento decisione Accetta ° Rifiuta ° 6 lezione 19 Marzo 2004

16 Specifica dei requisiti
6 lezione 19 Marzo 2004

17 -richieste impossibili da soddisfare (a causa dei vincoli imposti);
L'obbiettivo è l'individuazione chiara delle richieste e dei bisogni dell'utente per il sistema interattivo da progettare. Tipicamente l'attività inizia con una vaga descrizione del sistema da parte dell'utente, oppure con l'analisi di un sistema esistente (considerato un prototipo da migliorare). Con raffinamenti successivi si giunge all'individuazione chiara delle richieste e dei bisogni dell'utente, identificando anche: -richieste impossibili da soddisfare (a causa dei vincoli imposti); -i punti delle specifiche da approfondire; -le ambiguità da eliminare. 6 lezione 19 Marzo 2004

18 come Per l'analisi dei requisiti si utilizzano molte tecniche, tra le quali: interviste, osservazioni sul campo ed analisi di documenti Il prodotto di questa fase è il documento di specifica dei requisiti, che può essere sostituito da un prototipo del sistema interattivo. 6 lezione 19 Marzo 2004

19 Documento di specifica
Specifiche relative all'ambiente ed al compito da svolgere (focus sul sistema) Approccio tradizionale Richieste funzionali: identificano CHE COSA deve fare il sistema persona-macchina (ad esempio, utilizzando il formalismo 'Data Flow Diagrams'), compresi tutti i VINCOLI di tempo, di budget e di tecnologia; Caratteristiche dei dati: specificano i dati e gli attributi che caratterizzano il sistema interattivo (ad esempio, utilizzando il formalismo 'Entity-Relation Diagram'); 6 lezione 19 Marzo 2004

20 Data Flow Diagrams allarmi Reactor heat level system
Display di temperature Mostra i processi (cerchi) e i dati in I/O dai processi Altri simboli sorgente o destinazione dei dati Eventuale datastore nome 6 lezione 19 Marzo 2004

21 Entity relationship diagrams
is associated with Entity A Entity B 1 M Mostra la relazione che è associata fra due o più entità di interesse nel sistema. Esempio: l’entity Persona può avere la relazione “guida” con l’ entity Auto. Persona può avere un’altra relazione “possiede” con l’ entity Auto. 6 lezione 19 Marzo 2004

22 Persona 1 1 Auto possiede Persona 1 possiede M Auto guida M 1 Persona
Molti più dettagli possono essere aggiunti alla definizione delle entità e delle relazioni. guida Auto Persona M M 6 lezione 19 Marzo 2004

23 Specifiche relative all'utente (focus sull'utente) (Approccio IUM)
Caratteristiche di usabilità (libro di testo, pag. 401) facilità di apprendimento; semplicità d'uso (throughput); propensione agli errori; facilità di correzione. Queste specifiche di usabilità si esprimono in termini di misure di performance (metriche di usabilità); esempi di metriche includono: tempo di completamento di un compito fissato, numero di errori per compito, tempo speso nella consultazione di documentazione... 6 lezione 19 Marzo 2004

24 Progetto formale e concettuale
Il progetto concettuale definisce: che cosa è richiesto al sistema persona-macchina; quali dati vanno manipolati; quali conoscenze sono richieste agli utenti. 6 lezione 19 Marzo 2004

25 Il progetto formale (o fisico) stabilisce:
l'allocazione dei compiti (quali sono svolti dall'utente, quali dal calcolatore e chi comincia l'interazione); gli stili di interazione (come il sistema appare all'utente); quali feedback esistono fra utente e calcolatore; la consistenza dell'intero sistema (se in un punto deve essere forzata, bisogna segnalarlo all'utente!). 6 lezione 19 Marzo 2004

26 Tecniche di progetto Le tecniche di progetto si diversificano a seconda di: tipologia di utente: generico o specialista; tipologia di compito: critico o non-critico (valutato sulla base del costo di non-ottimizzazione e di deduzione sbagliata); costo degli errori. 6 lezione 19 Marzo 2004

27 Prototipazione Lo sviluppo di prototipi è parte integrante del progetto centrato sull'utente. Il prototipo, un progetto incompleto e sperimentale, permette di coinvolgere l'utente facendogli verificare le soluzioni che man mano emergono nelle varie fasi del progetto. Vi sono vari tipi di prototipazione: prototipi cartacei o basati sul calcolatore; questi ultimi si distinguono in verticali e orizzontali. 6 lezione 19 Marzo 2004

28 SVANTAGGI: non permettono di dimostrare le funzionalità del sistema
Prototipi cartacei VANTAGGI: permettono di ottenere, velocemente ed a basso costo, molte informazioni. SVANTAGGI: non permettono di dimostrare le funzionalità del sistema 6 lezione 19 Marzo 2004

29 Prototipi sul calcolatore
VANTAGGI: forniscono una versione del sistema funzionalmente limitata, che però rende possibile l'interazione con l'utente SVANTAGGI: possono portare ad abbandonare troppo presto alternative diverse da quella implementata. Non vanno quindi considerati un prodotto definitivo... anch'essi devono essere buttati come i prototipi cartacei. Il loro costo è maggiore 6 lezione 19 Marzo 2004

30 Modi di prototipazione sul calcolatore esempi http://didagate. ing
prototipazione orizzontale: prevede che si forniscano le funzionalità del sistema su un sottoinsieme minimo di oggetti. E' quindi possibile costruire interfacce utente che non abbiano funzionalità al di sotto dei bottoni. La prototipazione verticale prevede che si fornisca una funzionalità specifica e se ne permetta l'applicazione su un insieme esteso di oggetti. Permette quindi di avere funzionalità sia di alto che di basso livello, per una parte ristretta del sistema. 6 lezione 19 Marzo 2004

31 Implementazione La creazione di un sistema software implica molte scelte come stabilire i linguaggi di programmazione da utilizzare, l'ambiente di sviluppo da adottare, lo stile di programmazione più appropriato... La scelta del sistema operativo è spesso determinante poiché impone la propria logica ai programmi; tale logica può vincolare in maniera significativa la struttura del programma. 6 lezione 19 Marzo 2004

32 Ambienti di sviluppo L'ambiente di sviluppo è spesso integrato da supporti software; oltre a quelli tradizionali (linker, debugger, browser, maker) si sono aggiunti strumenti per la creazione di interfacce: gli user interface toolkit (librerie di oggetti interfaccia con software per la creazione tramite manipolazione diretta di interfacce complesse), e gli interface builder (strumenti più sofisticati, con cui specificare e personalizzare le proprietà di un user interface toolkit). trattati nel corso Tecniche web 6 lezione 19 Marzo 2004

33 Due particolari ambienti di sviluppo:
UIDE (User Interface Design System): ambiente interattivo che offre facilitazioni per lo sviluppo di interfacce utente, non necessariamente finalizzati alla gestione dell'interazione stessa. Questo ambiente permette di creare interfacce senza programmare e senza conoscere i dettagli dei toolkits. UIMS (User Interface Management System): ambiente interattivo che permette al progettista di gestire o sviluppare un'interfaccia utente usando strumenti ad alto livello, con uno sforzo inferiore rispetto alla semplice programmazione. Molti UIMS includono un UIDE. 6 lezione 19 Marzo 2004

34 Valutazione 6 lezione 19 Marzo 2004

35 L'obbiettivo è la raccolta e l'analisi dei dati sull’usabilità del progetto (o del prodotto, se questo esiste). I principali vincoli sono il budget e il disturbo arrecato all'utente durante l'acquisizione dei dati. 6 lezione 19 Marzo 2004

36 Essendo fondamentalmente un'attività di misura sarà necessario l'utilizzo di metriche opportune per le misurazioni, con la relativa statistica. L'attività di raccolta dei dati può essere effettuata secondo alcune tecniche, fra le quali: osservazione e monitoraggio dell'utente (in laboratorio o sul campo di lavoro); raccolta delle opinioni dell'utente (attraverso interviste o con questionari); benchmark (necessariamente va stabilito un campione di utenti e programmi da analizzare); valutazione interpretativa (come l’uso del sistema si integra con le altre attività); valutazione predittiva, eseguita da esperti di interazione, nella quale l'utente non viene interpellato. 6 lezione 19 Marzo 2004

37 Quando e come fare la valutazione?
Durante le prime fasi di progetto si tende a: predire la usabilità del prodotto o qualche suo aspetto verificare la comprensione dei requisiti degli utenti guardando come sistemi già esistenti sono usati testare rapidamente e informalmente idee alternative Più avanti nelle fasi di progettazione si tende a: identificare le difficoltà dell’utente affinché il prodotto risponda meglio alle sue esigenze migliorare le prestazioni del prodotto (usability engineering) Qualunque tipo di valutazione di usabilità è meglio di non farne alcuna. 6 lezione 19 Marzo 2004