IUM20048 lezione 26 marzo 20031 LERRORE UMANO. IUM20048 lezione 26 marzo 20032 Errore Atto, effetto di allontanarsi dalla verità o dalla norma convenuta

IUM2004 8 lezione 26 marzo 2003 1

L’ERRORE UMANO


Errore

“Atto, effetto di allontanarsi dalla verità o dalla norma convenuta”

dizionario Garzanti


L’ “errore umano” riconsiderato

• Il concetto di “errore umano” è più complesso di quanto non sembri: non esiste una dicotomia semplice fra errore e comportamento corretto

• Ogni interazione uomo-macchina dovrebbe essere trattata come una procedura cooperativa, durante la quale possono nascere fraintendimenti da entrambe le parti

(D.Norman)



Tolleranza degli errori

“Un dialogo è “error-tolerant” nella misura in cui, a dispetto di evidenti errori nell’input, i risultati desiderati possono essere ottenuti senza (o con minime) azioni correttive.”

ISO 9241 - 10


Classificare gli errori

c’era laintenzione di agire?

c’era intenzionenell’azione?

NO

LAPSUSNO

AZIONE INTENZIONALE MA ERRATA

NO

l’azione è proceduta come

desiderato?

SI

l’azione ha ottenuto il suo

scopo?

SI

AZIONE CORRETTASI

AZIONE INVOLONTARIA

NO

AZIONE SPONTANEA

SI


Progettare per l’errore1. Comprendere le cause di errore, e minimizzarle

(prevenzione)

2. Facilitare la scoperta degli errori che comunque accadono, e facilitarne la correzione

3. Rendere ogni azione reversibile, o rendere difficili le azioni irreversibili (undo)

4. Cambiare atteggiamento verso l’errore: non giusto/sbagliato, ma approssimazioni verso l’obbiettivo


Prevenzione dell’errore

• Amodalità

• Funzioni obbliganti

• Avvertimenti e richieste di conferma

• Default inoffensivi

• Bypass sicuri


Amodalità

Comportamento modale:

il sistema si comporta diversamente a seconda dello “stato” (o “modalità”) corrente

• evitare comportamenti modali, oppure

• evidenziare chiaramente la modalità corrente


cursore modale :indica che sonoin modalità“matita”


Funzioni obbliganti

Progettare le varie funzioni in modo da rendere impossibili le azioni non lecite nel contesto corrente

Esempio:

La portiera dell’auto può essere chiusa solo con la chiave, non con la sicura…

… in tal modo è impossibile restare chiusi fuori per errore


Azioni prive di senso nel contesto corrente sono disattivate


Avvertimenti e richieste di conferma

Livelli di allerta:

• Tieni presente che…

• E’ proprio questo che vuoi?

• Fermo!


Note alert box

(Livello 1)

Caution alert box

(Livello 2)

Stop alert box

(Livello 3)


Richieste di conferma

Chiedere sempre conferma prima di effettuare azioni irreversibili o comunque pericolose…

… ma senza esagerare!

DANNAZIONE, SI’ !


Da: AKMail


Da: Microsoft Access 95


Ed ora?



Default

Usare per quanto è possibile default inoffensivi


Bypass sicuri

Suggerire un’azione “sicura” in alternativa ad azioni che possono condurre ad errori


BYPASS SICURO


In caso di errore...

1. ALERT“qualcosa non va”

2. IDENTIFY“è questo che non va”

3. DIRECT“ora devi fare questo”


ALERT

IDENTIFY

DIRECT



ALERT

IDENTIFY





Granularità dei messaggi di errore

Un messaggio di errore alla volta, appena ho commesso l’errore….

… oppure tutti i messaggi di errore insieme, alla fine?





Cambiare atteggiamento verso l’ errore

“Il progettista non deve concepire una semplice dicotomia fra errori e comporta-mento corretto: al contrario, tutta l’interazione uomo-macchina deve essere trattata come una procedura cooperativa fra i due, dove gli equivoci possono nascere da ambo le parti.”

Donald Norman







non tutte le azioni sono “disfabili”.

Alcuni comandi sono molto difficili da recuperare :

• es nelle e-mail: dopo una SEND per l'invio della posta elettronica, l'utente non può più recuperare lo stato precedente a tale comando

• i comandi tempo-dipendenti, in particolare, hanno SIDE EFFECTS: non si può tornare indietro nel tempo!


UndoL’utente deve sempre, per quanto è possibile, poter ripristinare lo stato precedente…

… e così via, all’indietro, “senza limitazioni”

- non sempre si individuano gli errori immediatamente

- il numero di funzioni di UNDO possibili deve essere almeno pari a quello dei comandi presenti.


Esempi di gestione di UNDO

• Flip undo• Multiple step

• Checkpoint

• Registrazione traccia

• Il copione (ACR Archer, Conway, Schneider, 1984)


Flip undo

• Un FLIP UNDO ha senso se "tutti i comandi devono essere trattati in maniera uguale". Tutti i comandi devono essere recuperati compreso l'UNDO stesso.

• FLIP-UNDO: l'ultimo UNDO annulla l'effetto dell'UNDO precedentemente effettuato.

• La ragione perché UNDO non venga trattato uniformemente è dovuta a scelte fatte dai progettisti che ritengono un UNDO relativo solamente all'ultimo comando immesso.


Multiple step

• I meccanismi di UNDO del tipo MULTIPLE-STEP (al contrario del FLIP-UNDO) consentono di eseguire UNDO un numero indefinito di volte, o almeno fino a che il sistema ha informazioni disponibili sull’interazione passata.

Per poter correggere eventuali errori nell’utilizzo di UNDO viene inserito il comando REDO che consente di ripristinare l’azione annullata dall’ultimo comando di UNDO.


CHECKPOINT• Alcuni sistemi utilizzano CHECKPOINT o VIGILI

che consentono all’utente di riportare il sistema in una condizione precedente.Il numero di checkpoint e la scelta del momento in cui salvare un nuovo stato dipende molto dal tipo di sistema e dalle scelte dei progettisti.

Esempio di un programma di elaborazione delle immagini:

- si può pensare di salvare solo la situazione iniziale dell’immagine in questione,

- oppure di fare un checkpoint prima di eseguire una azione non disfabile (ad esempio l’applicazione di un filtro non reversibile),

- oppure ancora di eseguire un checkpoint dopo un intervallo di tempo prestabilito.


Registrazione traccia

• La traccia è una sequenza di comandi registrati nel modo in cui sono stati emessi

- possiamo compilare tale sequenza e fare degli UNDO su alcune componenti della sequenza.

Per una interfaccia grafica la traccia può essere di tipo testuale o grafico a seconda degli oggetti considerati.

Incrementa la sicurezza: se il sistema cade in crash, la sequenza registrata viene rieseguita ottenendo gli stessi risultati raggiunti.

Ovviamente l'ultimo comando, che ha provocato il crash, non deve essere eseguito.


Copione ACR

• Archer, Conway e Schneider nel 1984, suggerirono un modello di copione che considera l'utente come un "costruttore/autore del copione" ed il sistema come un "interprete della scrittura”.

L'utente esegue dei comandi, ogni azione viene scritta nel copione, ed in seguito viene sottoposta per l'esecuzione. La sequenza di comandi può essere manipolabile.


Esempio di copione

• L'utente sottopone il comando c1 poi c2 poi c3 ; l'utente ricorderà che la sua storia dell'interazione è: "... c1 c2 c3”.

-se si esegue il comando c3 e poi lo si vuole togliere, si potrà utilizzare un UNDO e si ritornerà "come se" la sequenza fosse c1 c2 (la sequenza reale è: c1 c2 c3 undo).


• Storia: nota completa di quello che l'utente ha fatto (c1 c2 c3 undo).

• Copione: nota di interazione che il sistema tratta come la sua storia effettiva. La scrittura dipende dal sistema e

può essere più semplice o più complessa della Storia. • Stato: l'equivalenza classificata di scritture (es: c1 c2

c3 undo è equivalente ad undo c2; la storia ed il copione sono diversi ma lo stato finale è lo stesso).

L'interfaccia ruota tra l'editing e l'interpretazione del copione:

• il primo generalmente termina con ENTER mentre

• il secondo termina quando il controllo ritorna all'utente.


UNDO Simbolico e Manipolativo

L'UNDO può essere simbolico: l'utente specifica un UNDO di molti comandi;

oppure manipolativo: viene manipolato il copione

Si può mostrare il nome del comando fino al quale l'utente vuole fare un UNDO oppure mostrare contemporaneamente tutto l'iter dei comandi immessi.

Si può mostrare una versione della sessione sia per l'UNDO (indietro di un comando) che per il REDO (avanti di un comando).


Difetti

Il modello del copione proposto da A.C.S. non è adeguato per un completo utilizzo di UNDO/REDO.

• Consideriamo il copione: c1c2c3

• facciamo un UNDO dei comandi c3 e c2 (salvati in uno stack tampone atto per eventuali REDO) e quindi sottoponiamo i comandi c4 e REDO c2 c3

• il risultato è un copione come:c1c4c2c3 Si supponga, ora, di voler tornare a c1c2. Il modello ACS consentirà di fare i passi descritti nella seguente figura :


Lo stato precedente c1c2 non può essere raggiunto mediante UNDO e REDO.

Il modello ACS non soddisfa queste caratteristiche in quanto propone un copione "lineare".


NOTA: Undo Skip Redo

• Il problema è stato risolto nel 1984 da Vitter introducendo le funzioni UNDO, SKIP e REDO (USR).

Un particolare comando può essere rieseguito in tempi diversi. I comandi sono visti come nodi di un grafo e la successione dei comandi viene registrata nei percorsi del grafo.


• Vitter utilizza un grafo aciclico diretto (DAG).

• Il copione di Vitter risulta essere un DAG che rappresenta solamente il percorso dei comandi successivi che vogliono essere eseguiti e non la storia completa.

• L'utente sceglie quale figlio aggiungere ad un nodo padre, evitando di immagazzinare tutte le scelte possibili.

• Si può mostrare che il modello di Vitter può risolvere l’incongruenza c1c2 precedente (http://cesare.dsi.uniroma1.it/~ium/luc6.htm).


Proprietà di Undo Skip Redo

• Le scelte offerte all'utente sfruttano le modalità inerziali: il redo di solito è in relazione all'ultimo undo eseguito.

• Effettuare n undo ed in seguito n redos porterà il sistema allo stesso stato.

• Gli utenti possono ovviare facilmente ai propri errori.

• I redo non scompaiono dal copione (altra proprietà inerziale). Il copione non si restinge mai.

Documents

IUM20048 lezione 26 marzo 20031 LERRORE UMANO. IUM20048 lezione 26 marzo 20032 Errore Atto, effetto di allontanarsi dalla verità o dalla norma convenuta