Che materia stai cercando?

Anteprima

ESTRATTO DOCUMENTO

Metafore

È un modo di massimizzare il trasferimento positivo di conoscenza: esprimere un modello

mentale nuovo per analogia e affinità con un modello mentale noto e familiare , il problema

immediato è che le analogia (trasferimento positivo) devono essere maggiori delle differenze

(trasferimento negativo).

Metafore verbali

Descrivere verbalmente(manuale d’uso) un word-processor in termini di una macchina da scrivere.

Bisogna avere consistenza nella terminologia (usare la terminologia da macchina da scrivere).

Quindi avere molte somiglianze e poche differenze e non sostanziali. Un esempio potrebbe

essere il tasto backspace (cancella in un WP) ma nella macchina da scrivere torna indietro (perché

non esiste questa possibilità di cancellazione nella macchina da scrivere  utilizzare la possibilità

dello strumento).

Metafore di interfaccia virtuale

Invece di usare la metafora per formare il modello mentale, la metafora è il modello mentale:

simulazione della metafora. Come Paint e desktop publishing WYSIWYG o Desktop

stilizzazione piano scrivania.

Se simuliamo un oggetto reale e familiare con la massima fedeltà, l’utente non avrà alcun

problema, forse se non limitiamo eccessivamente le funzionalità del programma il WP

potrebbe essere come una macchina da scrivere ma in realtà a molte più funzioni molto utili che

sono impossibili nella macchina da scrivere reale. Nelle slide a seguire vedremo: calcolatrice

windows (si può “aprire”), realPlayer, telefono (permette solo di immagazzinare solo 10 chiamate

rapide, perché su telefono non si poteva di più, mentre sul PC si potrebbe dare più

spaziolimitazione della funzionalità; a cosa serve il telefono?? Modifica arbitraria della metafora,

come il cassetto è un’estensione arbitraria della metafora).

Manipolazione diretta

Gli oggetti rappresentati sullo schermo sono manipolati dall’utente analogamente al mondo reale

(metafora di interfaccia virtuale) come per esempio per cancellare un file lo si trascina sul cestino o

per tracciare una riga su Paint basta selezionare la penna e spostare il mouse.

• Visibilità immediata degli oggetti di interesse (icone)

• Azioni rapide, reversibili e incrementali

• Rimpiazza sintassi complesse permettendo di lavorare direttamente

I vantaggi sono:

• Gli utenti novizi imparano rapidamente

• Gli utenti esperti lavorano rapidamente

• Gli utenti intermittenti mantengono intatti i concetti operativi

• Feedback immediato sul raggiungimento dello scopo

• Sistema più facilmente comprensibile

• Meno ansietà le azioni sono reversibili (UNDO)

Si passa dalla selezione di azione e poi oggetto alla selezione naturale oggetto e poi azione.

Gli svantaggi sono:

• Non funziona sempre: alcuni task non possono essere descritti da oggetti concreti e non

tutte le azioni possono essere effettuate direttamente (es. ricerche in un DB) 14

• A volte a manipolazione diretta è meno efficiente (es. se target non è visibile sullo schermo

ma richiede scroll (confrontare in word spostamento diretto mediante trascinamento con

cut e paste)

• Spesso la reversibilità delle azioni non viene implementata

Drag and drop

Uno dei metodi classici di manipolazione diretta: selezionare oggetto  trascinarlo sul target,

spostando il mouse tenendo il bottone sinistra schiacciato (DRAG) rilasciarlo sul target, mediante

rilascio bottone mouse (DROP); come per esempio nel cestino e lo spostamento di file o cartelle.

Apprendimento

Processo attivo  esplorazione dell’interfaccia (affordance) cosa è possibile fare; costruzione di un

modello mentale funzionale (stabilire nessi causa effetto).

Il processo dell’utente (acquisizione dell’abilità)

Fase cognitiva (Utente inesperto)  Conoscenza dichiarativa, espressa a parole

Fase associativa  Rafforzamento delle associazione tra i vari elementi per compiere un’azione

Fase autonoma (Utente esperto)  L’abilità diventa automatica e rapida (informazione strutturata in

memoria a lungo termine).

Esigenze diverse a seconda del grado di abilità.

Problemi nell’apprendimento

Imparare è difficile: la gente impara facendo o guardando altri fare, anziché leggendo manuali. La

sistematizzazione dell’esperienza è difficile;

Mancanza di nozioni di base: Gli utenti non hanno nozioni complete su computer, software, ecc.

e quindi ignorano aspetti rilevanti del problema, il gergo informatico non aiuta.

Interpretazioni ad hoc e generalizzazioni errate della conoscenza: dovute a incomprensioni del

nesso casuale e a mismatch di metafore.

I problemi interagiscono: difficoltà nel vedere che un problema può crearne un altro

L’interfaccia può non essere semplice: affordance non comprensibile e feedback non chiaro

I sistemi di aiuto non sempre aiutano: in generale manuali e sistemi di help sono fatti male

perché orientati a descrivere cosa offre il sistema invece di descrivere il modo per risolvere i

problemi.

Difficile il mappaggio problema  soluzione.

Caso studio  Sistema pannelli autostradali (vedi bene appunti)

In UK i pannelli autostradali per segnalare limiti di velocità, condizioni metereologiche; il centro di

controllo responsabile per le segnalazioni in tempo reale. Il 10 settembre 1976 cala la nebbia e il

centro di controllo non cambia segnalazioni (34 feriti e 3 morti e autostrada chiusa per quasi 7 ore).

La colpra di chi è? Il centro dice che il sistema non accettò le istruzioni, il ministro dice che non ci

sono prove nei log e il fornitore di sistema dice che ha sempre funzionato negli ultimi 5 anni.

Secondo il tribunale l’errore è dell’operatore. Se diamo un esame più attento vediamo che l’input

avveniva in maniera criptica (codici), assenza totale di feedback, messaggi di errori

incomprensibili, come input c’era una vecchia teletype (e input illeggibile) e per finire l’operatore

aveva altri compiti, tra cui rispondere al telefono e gestire il traffico radio. 15

Lezioni apprese dalla discussione in aula

• Task analysis : quali compiti devono essere supportati e quali no, quali sono frequenti, quali

sono critici, ecc.

• Coinvolgimento dell’utente: l’utente è l’esperto del problema (non dell’interfaccia)

• Prototipazione: metodi per confrontare diverse alternative di interfaccia e per coinvolgere

l’utente

• Interfacce/viste diverse per utenti diversi, personalizzazione: meccanismi di realizzazione

(Model View Control) design pattern per permettere viste diverse e diverse interazioni

utente sugli stessi dati

• Minimizzazione degli errori: prevenire gli errori (es. ingrigire comandi non disponibili),

reversibilità dell’azione e controlli di consistenza

• Ambiente fisico in cui il lavoro si svolge: regole ergonomiche che devono essere osservate

in alcuni casi anche per legge

• Limitazioni psicofisiche dell’operatore: limitazione di visione, difficoltà nell’orientamento

spaziale,…

• Alternative a livello di organizzazione del lavoro: es. decentrare la gestione al personale dei

singoli caselli

Modelli di interazione

Modello di shneiderman

Scissione tra

• Conoscenza semantica composta da

Semantica del task: il compito da svolgere, lo scopo da ottenere (es. scrivere una

o lettera). è ad un livello molto alto, indipendente dallo specifico computer e dallo

strumento (es. scrivere a mano)

Semantica del computer: è una conoscenza astratta, basata su astrazione del

o computer e non su uno specifico computer. (es. salvataggio di un file è un’azione

astratta comune per tutti i pc, anche se fatto in modi diversi tra i vari computer). La

semantica del computer deve essere imparata ma poi è applicabile a ciascun

computer (è organizzata in diversi livelli).

• Conoscenza sintattica: come usiamo effettivamente lo specifico calcolatore (dipende dalla

macchina che usiamo, SO, app) è device dependent. L’azione definita dalla semantica del

computer deve essere mappata nei comandi specifici dell’ambiente (salva su Windows per

salvare un file).

Mappaggi

Il risultato finale è la traduzione dello scopo in un insieme di comandi; per ottenere questo bisogna

mappare oggetti e azioni dalla semantica del task a quella del pc e finalmente la sintassi. Maggiore

è la differenza tra questi, maggiore è lo sforzo.

Semantica del taskSemantica del computer

Uso di metafore di funzionamento. Nascondere ciò che non è rilevante soprattutto nei manuali e

tutorial. L’informazione deve essere focalizzata al mappaggio semantico tra il task(scrivere una

lettera) e il computer(aprire un wp, salvare,ecc) senza dettagli inutili. 16

Semantica del computerSintassi del computer

I problemi classici sono:

• Assenza di consistenza: lo stesso task astratto viene implementato con sintassi diversa

addirittura in applicazioni diverse e al limite nella stessa applicazione.

• Distanza semantica/sintassi: una semplice azione astratta viene tradotta in una lunga

sequenza di azioni a livello sintattivo

• Arbitrarità della sintassi: sintassi non uniforme quindi comandi non chiari.

Modello di Norman

Il modello di Shneiderman presenta solo una parte dell’interazione (mappaggio dal goal alle azioni

che lo attualizzano), manca la parta fondamentale  la valutazione del risultato da parte dell’utente.

Goal  scopo finale

Intenzione semantica del task (massima astrazione)

Selezione azione  mappaggio tra semantiche task e pc

Esecuzione  mappaggio tra sematica e sintassi

PercezioneOsservo il cambiamento che l’azione ha

prodotto

Interpretazioneinterpreto il risultato secondo il mio

modello mentale

Valutazioneil risultato si avvicina al goal?

Attenzione:

• È un processo iterativo

• Le fasi non sono nettamente separate

• Non tutte le fasi sono necessarie per tutti i goals

• La maggior parte dei goals richiede più azioni

• La durata varia da secondi a giorni

• I risultati possono generare altri goals

• I goals possono essere composti da sottogoals (script)

• Le intenzioni possono essere composte da sottointenzioni

• In un’attività complessa i goals intermedi possono essere dimenticati, eliminati o

riformulati.

I “golfi” di Norman La distanza indica lo sforzo che deve essere esercitata

dall’utente.

Golfo di esecuzione quanto è difficile tradurre i goals

in azioni (semantica tasksintassi computer)

Golfo di valutazionequanto è difficili valutare la

risposta in termini del goal feedback

Questi possono essere asimmetrici (es. comandi

semplici e adatti alla semantica del task più feedback

inesistente).

L’obbiettivo è la riduzione/eliminazione dei golfi. 17

Golfo dell’esecuzione

Il sistema ideale presenta dei mappaggi diretti tra intenzione e selezione/esecuzione.

Adattare la semantica/sintassi del computer alla semantica del task (task analysis per azioni

frequenti o critiche).

Ridurre il più possibile la sintassi (es. stampa di una lettera, sposta icona lettera su stampante o

clicca comando stampa).

Golfo di valutazione

Sforzo necessario per capire se ci siamo avvicinati/abbiamo raggiungo il goal Essenzialmente

feedback che coinvolge: percezione(feedback visibile, consistenza), interpretazione (feedback

chiaro in termini di modello mentale del task come WYSIWYG) e valutazione (consistenza nella

definizione dei nessi causa-effetto).

Riassumendo è necessaria facilità Esecuzione ( determinare funzioni sistema, quali azioni sono

possibili, mappaggio dell’intenzione alla selezione, determinare azione tra le varie possibili) e

Valutazione (determinare lo stato in cui si trova il sistema, mappaggio tra stato ed interpretazione e

determinare se lo stato è quello desiderato).

I quattro punti fondamentali

1. Un buon modello concettuale Adatto alla semantica del task, Metafore se appropriate,

l’immagine del sistema deve essere coerente e consistente e consistenza nella

presentazione di operazioni e risultati.

2. Rendere le cose visibili lo stato del sistema è facilmente visibile? Le azioni possibili si

trovano?

3. Un buon mappaggio Mostrare chiaramente le relazioni tra : azioni e risultati, controlli e

oggetti controllati ed effetti e lo stato del sistema e ciò che è visibile

4. Feedback continuo di risultati e azioni.

Se riusciamo a ridurre al massimo i golfi, l’interfaccia diventa trasparente, non interferisce più con

il raggiungimento dello scopo.

Linee guida per il disegno dell’interazione

Gli obbiettivi che ci poniamo sono:

• Discutere ed evidenziare una serie di problemi comuni nel disegno di interazioni e le loro

possibili soluzioni

• Evitare i più comuni e fastidiosi errori di disegno

• Checklist da tenere presente nel disegno e nella valutazione

MAI considerare il disegno dell’interfaccia come fase finale dello sviluppo L’interfaccia è la prima

cosa che l’utente vede e usa per valutare l’applicazione, differenti scelte di interazioni possono

richiedere una massiccia re-implementazione del sistema.

1. Interazione/dialogo semplice e naturale

Per dialoghi, messaggi, comandi, manualistica, ecc.

a. Usare il modello concettuale dell’utente e la semantica del task

b. Presentare solo l’informazione necessaria (anche per terminologia, lo schermo è

una risorsa limitata quindi gli oggetti al suo interno devono essere giustificati,

schermo troppo pieno è leggibile con molte difficoltà)

c. Details on demand (informazioni desiderabili ma necessarie raramente, non devono

essere sempre sullo schermo ma comparire su richiesta da un comando) 18

d. Strutturare correttamente l’informazione per migliorare la leggibilità (gestalt di

prossimità)

e. Utilizzare widgets per sfruttare lo schermo in maniera ideale (splitters variare

quantità di schermo disponibile per le varie sotto finestre), tabbed windows come

rubrica telefonica e personalizzazione che utente sceglie finestre che non devono

essere di utilità generale nella posizione desiderata).

f. Minimizzare la navigazione tra le finestre (non creare troppe finestre, non

chiaramente connesse tra loro creazione finestra fatta esplicitamente da Utente).

2. Utilizzare il linguaggio dell’utente

a. Utilizzare la terminologia della semantica del task (POP3post office)

b. Se si usano metafore, usare solo la terminologia della metafora (folder, file  MAI

disco)

c. Evitare neologismi e gergo informatico (Abblencare, bytecarattere)

d. Manuali/help con lo stile corretto(quello della comunicazione tecnica/scientifica:

periodi brevi, soggetto e verbo, minimizzare uso sinonimi)

3. Minimizzare il carico di memoria dell’utente

a. Riconoscere vs ricordare: come evitare righe di comandi e usare icone, menu e

dove è necessario usare sintassi esplicita con dialog box

b. Facilitare l’input di dati quanto più formati sono disponibili (es. date  selezione

diretta)

c. Polimorfismo degli operatori (raggruppare un piccolo numero di regole da

applicarecut, copy, paste, drag&drop che sono applicabili ad oggetti diversi)

d. Meccanismi di salvataggio/ripristino del contesto (es. salvare il contesto alla

chiusura e ripristinarlo alla riapertura)

4. Consistenza

Le inconsistenze provocano errori e un ritardo nella costruzione del modello concettuale da

parte dell’utente, queste sono comuni nei programmi scritti da gruppi o in programmi che si

sono evoluti nel tempo

a. Niente sinonimi (memorizzare un file, salvare, registrare…)

b. Stessa posizione e layout (stessa gabbia e posizione per i bottoni, stesso font e

corpo per oggetti analoghi)

c. Stessa modalità di interazione (stessa azione fatta sempre nello stesso modo)

d. Utilizzare gli standards della piattaformai (widget e style-guides uniformità e

consitenza inter-applicazioni)

5. Feedback Chiaro e continuo

a. Sullo stato/modalità in cui il sistema si trova (es. Paint seleziono matita il cursore è

una matita)

b. E quindi su come il sistema interpreta le azoni dell’utente (es. cursore matita gli

spostamenti tradotti in segni di matita sullo schermo

c. Specificità dell’informazione (dare il massimo di informazione utile per chiarire

l’azione ed evidenziare il contesto) 19

d. Gestire i problemi di ritardo

6. Fornire uscite chiare

Una cosa frustante per l’utente è essere intrappolato all’interno del sistema, l’utente deve

poter uscire da qualsiasi situazione.

a. CANCEL per uscire dai dialoghi o da operazioni lunghe

b. RESET nei dialoghi e property sheet per rispristinare i valori di default

c. Uscita immediata dall’applicazione senza dover chiudere tutte le finestre aperte

d. UNDO universale (disfare le azioni fatte nell’ordine inverso dell’esecuzione)

Copia di backup (indietro una sola volta), salvare lo stato prima di eseguire il comando e

mantenere un log delle azioni eseguite (e di ogni azione una inversa) semplice nel single-

user ma complicato nelle multi-user

7. Scorciatoie

Aumento della produttività mediante minimizzazione dello sforzo manuale

a. Acceleratori (es. CTRL+S per salvare, sforzo mnemonico ma è più rapido)

b. Doppio click Azione di default (azione più comune o la più sensata)

c. Toolbars per comandi frequenti

d. Tasti di scorrimento task_oriented  scorrimento continuo + scorrimento pagina

Permettere all’utente di personalizzare le scorciatoie

Per interfacce a comandi : Abbreviazione comandi, completamento automatico dei

comandi/testi e tasti funzione

e. Minimizzare l’input (valori di defalut come date o meccanismi con ultimi argomenti

ecc.)

f. Permettere salti di navigazione (Meccanismi di storia della navigazione, lista di

finestre aperte)

8. Gestione degli errori

Errore: azione errata conscia dovuta ad un modello mentale errato (da utente inesperto)

Slip: errore di distrazione dovuto ad interferenze (da utente esperto)

StrategieUNDO universale e verifica dell’azione per azioni potenzialmente distruttive e non

reversibili.

Ci sono diversi tipi di slips:

• Errore di cattura: un’azione frequente si sovrappone all’azione corretta (digitare wq

al posto di w ) Differenziare le azioni il più possibile con icone, posizione

• Errore di descrizione: azione corretta ma sull’oggetto sbagliato, spesso vicino a

quello corretto (come spostare oggetto sul cestino e non sulla stampante)evitare

prossimità se può condurre a gravi errori 20

• Errore di modalità: azione corretta ma in modalità sbagliata (input di testo al posto

che di comando o viceversa)eliminare le modalità o renderla visibile

• Errore di attivazione: si dimentica lo scopo di una sequenza di azione goals

frequenti o critici devono essere realizzati direttamente e tenere un log delle azioni

effettuata disponibile a richiesta

• Errore pilotato dai dati o di associazione: interferenze esterne/interne che si

sostituiscono all’oggetto corrente (es. salvare un file con un nome che compare

sullo schermo ) log delle azioni effettuate disponibile a richiesta

Per superare questo tipo di errori ci sono tre strategie

1. Prevenire: evitare che l’errore si possa verificare (ingrigire bottone o comandi non

utilizzabili , cambiare cursore quando il target drag and drop non è valido, non

accettare dati non corretti in input e evitare la digitazione (scelta file dal file system))

2. Impedire di proseguire (es. immissione sbagliata della password)

3. Verificare ed avvertire: magari mediante suoni o msgbox solo quando non è

possibile prevenire, troppe segnalazioni sono irritanti e stimolo cancellato  msg

BOX “positive” cioè evitare di offendere l’utente e di dare informazioni inutili e

invece offrire soluzioni

4. Altre strategie potrebbero essere offrire un dialogo ma sono su richiesta se no è

noioso.

9. Help

Assistenza per utenti inesperti  Formare modello mentale, capire le possibilità e acquisire

esperienza

Assistenza per utenti esperti/intermittenti  ricordare le modalità per operazioni infrequenti

a. Gli utenti non leggono i manuali (imparano guardando o “giocando” direttamente

b. Se leggono i manuali non li capiscono (secondo il modello strutturale e non la

semantica del task con uso eccessivo di sinonimi o gergo informatico e scritti quasi

come “Punizione”

c. Se li capiscono non sono aggiornati

d. Manuali cartacei (tipicamente disponibili come file elettronico da stampare a

richiesta perché su carta è troppo costoso e difficilmente aggiornabile , non risponde

alle esigenze di immediatezza dell’utente e non si trova quando serve!!

e. Manuali/help on-line (disponibili subito e organizzati in maniera ipertestuale o per

argomento, sezioni how to e funzioni di ricerca per parola e anche le differenze

rispetto alle versioni precedenti) spesso inadeguati per formare un modello mentale

f. Tutorials: guide brevi per permettere all’utente inesperto di iniziare a lavorare

rapidamente con il sistema (sequenziali per task, brevi esercizi sui compiti principali,

demo e/o filmati) rapidi e sintetici perché l’utente non ha tempo

g. Training: lezioni con esercizi utili quando l’utente deve diventare esperto in breve

tempo  corsi tradizionali o interattivi o CBT esercizi in cui l’attività dell’utente viene

monitorata continuamente dal sistema che consce goal e evidenzia errori e fornisce

suggerimenti.

Altri tipi di help potrebbero essere

h. Informazione sull’interfaccia con tooltips o what is this o tip of the day 21

i. Interazione guidata  serie di dialoghi sequenziali che guidano l’utente verso dei

goal dove servono molte azioni e con la possibilità di tornare indietro (spesso per

installazioni programmi)

j. Suggerimenti on-line  aiutanti come figura stilizzate che offrono suggerimenti con

personalità diverse , DEVE essere escludibile e limitare l’animazione che disturba

l’azione e diventa presto irritante

10. Personalizzabilità

Possibilità da parte dell’utente di adattare l’interfaccia o interazione alle proprie esigenze come:

• Colore: variare colore (importante per daltonismo ) o per l’ambiente

• Point size: possibilità di variare la dimensione dei caratteri

• Suoni: attivarli o disattivarli e regolare il volume

• Disegno speciale per portatori di handicap

• Layout possibilità di modificare l’interfaccia e i suoi elementi

• Toolbars: variazione dei tools e della loro posizione e come sono raggruppati

• Finestre: possibilità di nascondere/mostrare delle finestre accessorie, ancorate in

posizione diverse

• Interazione: scopo è pigiare un bottone per un goal che non è però sempre possibile

• Automatizzazione di compiti ripetitivi (macro che implementano le azioni per

raggiungere goal)

• Modelli: scelte predefinite di stili o risultati intermedi preconfezionati (es. foglio

bianco word)

User-Centered Design

Conoscere e coinvolgere l’utente Cosa farà?

TASK ANALYSIS /Casi d’uso  non sono azioni elementari ma azioni definite a livello di semantica

del task che possono essere: frequenti (da ottimizzare), critici (possibili errori) e non frequenti

(decidere se supportarli e meno visibili degli altri).

• Quali sono le esperienze precedenti dell’utente?  Tipo di metafore, trasferimento positivo

della conoscenza.

• Limitazioni individuali Handicaps, limitazioni percezione e cognizione.

Anche se fittizia una persona deve essere: resa concreta, sintesi di caratteristiche presenti negli

utenti reali e descritta da un profilo che elenchi tutto ciò che ritiene rilevante per caratterizzare il

prodotto (competenze, comportamenti, preferenze, vita sociale).

• Chi utilizzerà il sistema? Utenti inesperti (interfaccia intuitiva e rapida acquisizione del

modello mentale), utenti esperti (tecniche per migliorare produttività come scorciatoie,

utenti intermittenti (rendere facile il ri-orientamento dell’utente)

• Ambiente: disturbi esterni (utente svolgi anche altri compiti o ambiente fisico rumore)

• Come verrà utilizzato il sistema? compiti di emergenza o vigilanza

• In quale organizzazione si trova l’utente?  cambiamenti organizzativi troppo radicali sono

controproducenti

Chi è l’utente?

Tipi di prodotto: 22

a) Prodotto su commessa (es. gestore pannelli autostradali e chi userà sistema

b) Prodotto generale localizzato (es. metro di Torino, campione di utenti effettivi simili)

c) Prodotto innovativo e/o universale (es. Google glasses un campione potenziale di utenti)

Questo ha dei PRO:

• Gli utenti sono in grado di valutare differenti alternative di disegno rispetto alle proprie

esigenze se sono concrete e visibili (a,b,c).

• L’utente è l’esperto del contesto di lavoro e conosce il problema dei compiti, la passi e lo

svolgimento (a,b)

• Gli utenti sono “i clienti” del sistema e bisogna tenere conto delle loro necessità che

significa aumentare “vendibilità” del sistema (a).

Hanno anche dei CONTRO:

• Difficile trovare un buon campione di utenti rappresentativi (riluttanti a essere coinvolti)

• L’utente non deve essere responsabile della definizione dell’interazione (NON è esperto di

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 di utenti e il loto contesto / informazione numerica dove è possibile fare

confronti tra grandi numeri di utenti o misurare aspetti specifici

Valutazione qualitativa dell’usabilità

Otteniamo un’indicazione non numerica dell’usabilità, che può però essere soggettiva. Questa è

molto meno costosa delle tecniche classiche di sperimentazione quantitativa (gruppi controllo,

campioni casuali) ma è anche molto meno affidabile I risultati sono replicabili? Il campione è

rappresentativo?

Valutazione senza l’utente

1. Introspezione (Analitica/Formativa/Qualitativa): progettista impersona utente svolgendo i

taskmolto utile per evidenziare rapidamente problemi importati nell’uso normale MA è

completamente soggettivo e il progettista NON è un utente tipico

I PRO sono: Facile da fare, non sono necessari strumenti costosi, relativamente veloce,

feedback immediato e formativi (fasi iniziali senza sistema implementato).

I CONTRO sono: Scarsa riproducibilità e poco oggettiva.

2. Cognitive walkthroughs (Analitica/Formativa/Qualitativa): progettisti e utenti valutato il

sistema sulla base di task specificamente disegnati per verificare l’intuitività

dell’interazione: un utente inizia subito a lavorare senza alcuna informazione.

a. Una task analysis che specifica la sequenza di azioni richiesta per eseguire un task

e le risposte alle azioni

b. Progettisti, sviluppatori (e utenti) eseguono in gruppo la sequenza verificando 4

domande

• L’utente capisce questo passo ed è necessario per lo scopo?

• L’utente capisce che l’azione corretta è disponibile? (Bottone visibile)

• L’utente capisce qual è l’azione per eseguire questo passo? (es. icona

comprensibile o etichetta)

• L’utente ottiene un feedback sufficiente?

I PRO sono: Le 4 domande sono uno standard, si identificano errori di progettazione che

impattano sulla performance degli utenti, si tendono a evidenziare i problemi gravi, utili per

utenti “walk-up-and-use”.

I CONTRO sono: Determinare la scelta di scenari chiave e si trovano meno problemi

rispetto alla valutazione euristica.

3. Valutazione euristica (Analitica/Formativa/Qualitativa): esperti di IUM usano e criticano il

sistema sulla base di linee guida (problemi di usabilità). In media 5 valutatori sono

sufficiente per evidenziare il 75% dei problemi. 28


ACQUISTATO

4 volte

PAGINE

34

PESO

553.41 KB

AUTORE

Fabioz95

PUBBLICATO

+1 anno fa


DETTAGLI
Corso di laurea: Corso di laurea in informatica
SSD:
Università: Torino - Unito
A.A.: 2017-2018

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher Fabioz95 di informazioni apprese con la frequenza delle lezioni di Interazione uomo macchina e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Torino - Unito o del prof Sacco Giovanni.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Corso di laurea in informatica

Riassunto esame Reti I
Appunto
Formulario Matematica discreta
Appunto
Architettura degli elaboratori - Appunti
Appunto
Ricerca operativa - Problemi di mix
Esercitazione