Riassunto esame Interazione Uomo Macchina, prof. Sacco Giovanni

IUM)

• L’utente non ha sempre ragione (prassi manuale spesso inefficiente e spesso l’utente non

sa esattamente cosa vuole)

Universal Design/Design for all

Sono prodotti non per una specifica persona o un gruppo, ma per qualsiasi categoria di utenti

indipendentemente da cultura, lingua o disabilità:

• Equità d’uso: usabile da persone con diverse abilità

• Flessibilità d’uso: supporta un ampio spettro di preferenze individuali

• Uso semplice ed intuitivo indipendentemente dall’esperienza

• Informazione percepibile

• Tolleranza agli errori: minimizzazione dei rischi e delle conseguenze di azioni accidentali

• Ridotto sforzo fisico

• Dimensioni e spazio adatti all’uso

Progettare non per l’utente medio ma considerare tutte le categorie di utenti è sempre necessario

coinvolgere l’utente per i motivi visti prima, MA diventa difficile selezionare un campione.

Il modello a cascata

Il modello di sviluppo classico: una inesorabile progressione senza cicli  non può funzionare

perché

• Non è possibile prevedere tutti gli aspetti di un sistema complesso che non esiste ancora 

difficoltà impreviste e anche imprevedibili

• L’utente compare (forse) solo all’inizio e non ha modo di intervenire per correggere

eventuali incomprensioni

• Ogni nuovo strumento cambia i bisogni del suo utilizzatori e genera nuovi bisogni, che

suggeriscono modifiche non previste dallo strumento stesso

Niente che coinvolge gli utenti può essere fatto così devi essere un processo iterativo che

converge ad un prodotto usabile. 23

Modello ISO 13407 Fase iniziale:

• Raccolta dei requisiti: interviste,

vedere utenti come svolgono i

compiti (verbale e imprecisa)

• Prototipo iniziale brainstorming tra

diverse rappresentazioni e selezione

di unainterfaccia iniziale

• Valutazione rivedere e valutare i vari

task nel contesto attuale e

ridisegnare se necessario

Fase intermedia:

• Messa a punto dell’interfaccia

• Disegno dello schermo (finestre, dialoghi, ecc)

• Valutazione euristica (linee guida)

• Ridisegno

Fase finale:

• Test di usabilità e ridisegno

• Test sul campo

• Alpha/Beta test

Definizione requisiti

Identificazione e descrizione di tutte le proprietà richieste o desiderabile, gli aspetti rilevanti

secondo lo standard ISO

a) Prestazioni richieste in relazione agli obbiettivi operativi ed economici

b) Requisiti normativi (sicurezza, salute, …)

c) Comunicazione e cooperazione tra utenti ed altri attori

d) Attività degli utenti: ripartizione dei compiti, benessere e motivazioni

e) Progettazione dei flussi di lavoro e dell’organizzazione

f) Gestione del cambiamento indotto dal nuovo sistema (organizzazione o addestramento)

g) Fattibilità dei diversi aspetti, compresa manutenzione

h) Progettazione dei posti di lavoro e dell’interfaccia

Il processo che segue è:

• Esplorazione che è la ricerca del maggior numero di informazioni su obbiettivi e necessità

da: committente, interviste stakeholders e analisi concorrenza

• Organizzazione che è l’analisi delle informazioni, riordino, soluzione contraddizioni e si

produce il documento di specifica dei requisiti

• Revisione ed approvazione da parte del committente

Esplorazione

Ci sono diversi tipi di problemi:

• Problemi di ambito: campo di esplorazione troppo ampio o ristretto 24

• Problemi di comprensione: gli utenti e stakeholders hanno spesso una comprensione

parziale del problema e tralasciano cose ovvie e chi raccoglie i requisiti ha spesso una

conoscenza limitata del problema e comunque usano linguaggi molto diversi

• Problemi di conflitto: stakeholders diversi hanno punto di vista diversi e a volte incompatibili

su requisiti e priorità

• Problemi di volatilità: il contesto può variare anche molto rapidamente ed in maniera

inaspettata.

Scenari d’uso

Narrazione, in linguaggio comune, di una possibile storia dell’uso del sistema da parte di uno

specifico utente, fittizio ma tipico e descritto in modo completo e realistico.

Utile per collocare il prodotto in contesti d’uso reali e per considerare il prodotto in modo più

oggettivo.

Problemi scenari significativi e non aneddotici.

Caso d’uso: Un insieme di interazioni finalizzare al raggiungimento di uno scopo utile, fra un o più

attori ed il sistema

Attori diversi (non sempre umani) come utente normale, registrato, amministratore

Es. In un sito di e-commerce  Individuare prodotto da acquistare , acquistarlo e inserire un nuovo

prodotto in catalogo.

Diagramma dei casi d’uso

Inclusione: un caso d’uso che viene utilizzato da un o più casi d’uso.

Estensione: un caso d’uso che può essere utilizzato da un o più casi d’uso.

Generalizzazione: uno o più casi d’uso o attori possono avere una rappresentazione più generale.

25

Il documento finale

1. Sommario

2. Generalità

a. Scopo del prodotto

b. Situazione attuale

c. Caratteristiche utente

d. Contesto d’uso

e. Scenari d’uso

f. Fattibilità tecnologica

3. Posizionamento

a. Analisi della concorrenza

b. Posizionamento competitivo

4. Casi d’uso

a. Diagramma dei casi d’uso

b. Descrizione dei singoli casi d’uso

5. Altri requisiti

a. User experience

b. Prestazioni

c. Appendici

d. Glossario

e. …..

Prototipazione

L’utente può valutare/reagire a diverse possibilità di disegno solo se il sistema è concreto e visibile.

Prototipazione è la caratterizzazione/realizzazione di un sistema a basso costo per valutazione; ci

sono quindi diversi livelli di fedeltà/costo di realizzazione per diversi scopi (il ruolo nella vita

dell’utente/interazione/implementazione).

Prototipi a basse fedeltà/costo

Sketch(schizzo) Disegnare su carta le componenti e l’aspetto generale dell’interfaccia

propostaLOOK

Storyboard(sceneggiatura) sequenza di schizzi che mostra come l’interfaccia risponde ad alcune

azioni  LOOK AND FEEL (vedi figura 33 nelle slide 4)vediamo che è uno statechart con una

parte di interfaccia anche se la descrizione dinamica può essere meno completa di questi.

Statechart – Diagramma degli stati Nodi: stati, archi orientati con condizioni opzionali: transizioni

tutto questo con organizzazione modular/gerarchica (vedi foto 32 nelle slide4)

Il basso livello di dettaglio porta a concentrarsi su aspetti ad alto livello.

Questo è molto utile nelle fasi iniziali perché permette di analizzare rapidamente le diverse scelte.

Prototipi a media fedeltà su computer

Simulare le caratteristiche chiave del sistema sul pc. Dare quindi all’utente un’idea più

realistica di quello che succede (LOOK AND FEEL), e permette anche di valutare problemi più

sottili  usato nella fase intermedia dello sviluppo del sistema. Bisogna fare ATTENZIONE alle

reazioni dell’utente che sono spesso meno critiche rispetto ai prototipi su carta perché il sistema

sembra vero. Ci sono tre modi per limitare le funzionalità: 26

• Prototipi orizzontali: implementare tutto lo strato di interfaccia utente senza funzionalità o

con funzionalità molto limitate

• Prototipi a scenario: Scripts fissi di alcuni usi del sistema (impossibili da deviare già

preparati)

• Prototipi verticali: Funzionalità

completa solo per alcuni funzioni.

Permette però di valutare

completamente l’interazione per le

funzioni implementate (spesso le più

critiche)

Prototipo e prodotto

• Prototipo “usa e getta” : Serve solo per test (se su PC usato strumenti rapidi come prototipi

wireframe o ipertestuali)

• Prototipo evolutivo : Il prototipo viene modificato in ogni fase fino a diventare il prodotto

finale (usa sempre ambiente di sviluppo dell’applicazione)

• Prototipo wireframe : Contenitore vuoto ma navigabile, un layout ma senza contenuti e

grafica

• Prototipo ipertestuale : interazione simulata mediate aree ipertestuali (pagine html o

powerpoint)

Il vantaggio della prototipazione è la diminuzione dei costi di implementazione.

I prototipi devono essere “usa e getta” e a basso costo fino a che il disegno non diventa stabile

(all’inizio si prototipa velocemente per alternative diverse). È un errore usare un prototipo evolutivo

quando il modello di interazione non è stabile perché i costi alti tendono a “congelare” l’interazione

e quindi a scoraggiare le modifiche le modifiche tendono a essere effettuate in maniera “quick and

dirty” e risultano spesso una cattiva ingegnerizzazione del sistema finale.

Prototipazione alla Mago di Oz

La simulazione di funzioni complesse è affidata ad un essere umano nascosto che interpreta

l’input dell’utente e produce l’output secondo un algoritmo, questo è usato spesso per applicazioni

di intelligenza artificiale (riconoscimento parlato o agenti intelligenti).

Studi di fattibilità: verificare le aspettative dell’utente e l’interazione PRIMA di implementare

algoritmi complessi Es. IBM voice editor, input vocale da parte dell’utente tradotto in testo sul

computer.

Valutazione dell’usabilità

Usabilità

1. Efficacia: accuratezza e completezza con cui certi utenti possono raggiungere certi

obbiettivi in ambienti particolari

2. Efficienza: le risorse spese in relazione all’accuratezza e completezza degli obbiettivi

raggiunti

3. Soddisfazione: comfort e accettabilità del sistema di lavoro per i suoi utenti e le altre

persone influenzate dall’uso

4. Facilità di apprendimento: l’utente deve raggiungere buone prestazioni in tempi brevi 27

5. Facilità di memorizzazione: l’utente deve poter interagire con un’interfaccia anche dopo un

lungo periodo di inattività, senza dover ricominciare da zero per forza.

6. Sicurezza e robustezza all’errore: l’impatto dell’errore deve essere inversamente

proporzionale alla probabilità d’errore.

Ci sono diversi tipi di valutazione dell’usabilità come:

• Analitica/Empirica: rispettivamente  ragionamento e analisi /osservazioni o misure

• Formativa/Sommativa: rispettivamente (fase iniziale) valuta e raffia idee/(fase avanzata)

testa e valuta sistemi

• Quantitativa/Qualitativa: rispettivamenteinformazione non numerica (testi e immagini) su

un piccolo numero d