M Cap.11: Progettare per l'errore

8/3/2019 M Cap.11: Progettare per l'errore

1/18

11.Progettare per lerrore

Sintesi del capitolo

Questo capitolo discute la nozione di errore umano nel dialogo uomo-macchina e presenta alcune linee guida per il

trattamento degli errori compiuti dallutente, approfondendo quanto gi detto nel Capitolo 10. Dopo una classificazione dei

principali errori in lapsus e sbagli, si descrivono le principali tecniche di prevenzione a disposizione del progettista. Si

discutono poi le linee guida per una corretta diagnosi degli errori. Infine si descrivono i processi di ripristino,

suddividendoli in due tipologie: forward recovery e backward recovery. Il capitolo contiene numerosi esempi.

Lerrore umano

Nel Capitolo 10 abbiamo elencato le raccomandazioni fornite dallo standard ISO 9241-110 per la realizzazione disistemi error-tolerant, cio quei sistemi che consentono allutente di raggiungere facilmente gli obiettivi desideratinonostante gli errori compiuti nellinterazione. Questo capitolo tratta in modo pi dettagliato questo argomento che,

nonostante la sua grande importanza pratica ai fini dellusabilit di un sistema, viene spesso trascurato dai progettisti.

Anche lutente pi esperto commette degli errori. Questo inevitabile, se si pensa che spesso, nei compiti quotidiani,c un solo modo di fare le cose nel modo corretto, ma molti modi di sbagliare. Pensiamo al compito di cuocere un uovosodo: si tratta di un processo elementare, ma la lista dei possibili errori piuttosto lunga. Possiamo romperlo per unmovimento troppo brusco mentre lo prendiamo dal frigorifero, se lo immergiamo nellacqua bollente quando troppofreddo il guscio tende a incrinarsi, possiamo sbagliare il tempo di cottura o rovinarlo mentre lo sgusciamo. Ci pucadere per terra mentre lo portiamo in tavola. Infine, possiamo non accorgerci, prima di assaggiarlo, che si tratta di unuovo rancido.

Il progettista deve innanzitutto comprendere che lutente che sbaglia non un utente sbagliato, ed evitare dicolpevolizzarlo, o pretendere da lui unimpossibile perfezione. Deve accettare il fatto che lutente sbaglia perch ilsistema gli consente di sbagliare e questo, in ultima analisi, un difetto ascrivibile a cattiva progettazione. Il progettistadeve allora predisporre tutti gli accorgimenti per evitare, per quanto possibile, questa eventualit e gestirla nel modo picorretto quando si verifica.

A questo scopo, deve innanzitutto comprendere meglio la natura dellerrore umano. Che cosa significa errore? Secerchiamo nel dizionario la definizione di questo termine, troviamo, per esempio:

Atto, e effetto di allontanarsi dalla verit o dalla norma convenuta1

Questa definizione non di grande aiuto, perch troppo generale. Noi siamo interessati a comprendere lerrore umanodal punto di vista psicologico e operativo, non filosofico. Un errore compiuto dalluomo e in particolare dallutente diun sistema interattivo - pu avere cause diverse e produrre effetti differenti: se conosciamo le cause possibili, possiamocercare di prevenirlo; se ne conosciamo gli effetti, possiamo cercare di limitarli. Fortunatamente lerrore umano statoampiamente analizzato dagli studiosi di scienze cognitive. James Reason, nel suo libro Human Errorne d la seguentedefinizione operativa:

Errore sar inteso come un termine generico per comprendere tutti i casi in cui una sequenza pianificata di

attivit fisiche o mentali fallisce il suo scopo, e quando questo fallimento non possa essere attribuito

allintervento di qualche agente casuale2.

Nello stesso libro, si trova una classificazione molto utile per i nostri scopi, illustrata nella . In questo schema,un'azione considerata corretta quando si verificano tre condizioni: 1) lutente aveva l'intenzione di agire, 2) l'azione proceduta come desiderato, 3) l'azione ha ottenuto il suo scopo. Se non si verificano tutte queste tre condizioni, si hanno

1 dal dizionario Garzanti della lingua italiana.2 James Reason,Human Error, Cambridge University Press, 1990, pag.9 (nostra traduzione).

1


2/18


3/18

agire. Per esempio, quando qualcuno ci lancia improvvisamente un oggetto e, quasi per un riflesso automatico, loafferriamo al volo, o ci proteggiamo con le mani. Lazione non era prevista, ma ci siamo trovati nella necessit dicompierla. Unazione spontanea non necessariamente deve essere classificata come errore: tale solo quandoproduce effetti indesiderati.

Azione involontaria

In questo caso, lazione del tutto non intenzionale. Per esempio, quando urtiamo involontariamente una personaoppure quando, mentre a tavola ci versiamo del vino, rovesciamo il bicchiere.

Per ciascuno di questi tipi di errore, gli effetti possono essere molto diversi. Se tocco inavvertitamente una persona sultram, la cosa non ha grande importanza. Ma se tocco inavvertitamente il pallone con le mani nei pressi della portadurante una partita di calcio di serie A le conseguenze possono essere molto gravi. Come si vedr meglio nel corso diquesto capitolo, spesso non esiste una dicotomia netta fra errore e comportamento corretto.

Le strategie che il progettista deve mettere in atto per limitare la possibilit e le conseguenze dellerrore umano sonoriassunte nella . Innanzitutto, dovr progettare il dialogo in modo tale che lerrore risulti impossibile, o comunque pocoprobabile (prevenzione). Nel caso in cui lutente dovesse comunque commettere un errore, questo dovrebbe essere

gestito. In particolare, individuato e spiegato correttamente allutente (diagnosi), affinch egli possa correggere lasituazione (recovery). Vediamo pi in dettaglio le principali tecniche che possono essere utilizzate a questi scopi.

Figura 2. Progettare per lerrore

Prevenzione

Anche nei sistemi interattivi, prevenire meglio che curare. Prevenire lerrore (error prevention) significa progettare ilsistema in modo che la possibilit di errori da parte dei suoi utenti sia minima. In particolare, unazione dellutente nondovrebbe mai causare una caduta del sistema o un suo stato indefinito. Alcune tecniche molto diffuse per prevenire glierrori sono le seguenti:

Diversificare le azioni dellutente;

Evitare comportamenti modali;

Usare funzioni obbliganti;

Imporre input vincolati;

Non sovraccaricare la memoria a breve termine dellutente;

Richiedere conferme;

Usare default inoffensivi.

Vediamole singolarmente.

3


4/18

Diversificare le azioni dellutente

Questa tecnica serve a prevenire i lapsus. Si tratta di fare in modo che le azioni che lutente deve eseguire per effettuarecompiti diversi siano ben diversificate, in modo da minimizzare la probabilit che lutente ne esegua inavvertitamenteuna al posto dellaltra. Per esempio, bene distanziare fisicamente i pulsanti o le voci di menu di uso pi frequente dapulsanti o voci di menu relative a comandi pericolosi. Si tratta di una raccomandazione alquanto ovvia, che per non

di rado disattesa.

A volte questa indicazione in conflitto con quella, altrettanto corretta, di raggruppare fra loro i comandisemanticamente correlati. La mostra un esempio tipico di questa situazione di conflitto. Il programma Outlook dellaMicrosoft, come tutti i programmi di posta elettronica, associa a ogni messaggio che si trova nella mailbox di input lostato di Read o di Unread, a seconda che esso sia stato letto o no dallutente. I messaggi nello stato di Unread sonoevidenziati visivamente (normalmente in neretto), per permettere allutente di individuare le mail ancora da aprire. Nelmenu Edit ci sono anche due comandi (Mark as Read e Mark as Unread) che permettono di modificare questistati. Ci molto utile quando lutente, dopo aver letto un certo messaggio, decide di non rispondere subito: perricordarsi che la mail non stata evasa, potr usare il comando Mark as Unread, che la visualizzer di nuovo inneretto. Il sistema fornisce anche un comando Mark All as Read, che pone tutti i messaggi presenti nella mailbox di

input nello stato diRead. Il comando collocato immediatamente sotto gli altri due, e pu accadere di selezionarloinavvertitamente al posto del contiguo Mark as Unread, con esiti molto fastidiosi. Infatti, il sistema non consente diannullarne gli effetti, e lutente non avr pi modo di riconoscere i messaggi ancora da leggere da tutti gli altri. Questocapita di frequente a chi, come chi scrive, abbia labitudine di dare una prima scorsa alla posta per poi evaderla in unsecondo tempo. Il problema potrebbe essere evitato, allontanando il comando pericoloso dagli altri due, oppurelasciandolo dove si trova ma chiedendo conferma allutente prima di eseguirlo. Questultima soluzione, nel casospecifico, probabilmente la pi corretta, perch lascia vicini tre comandi funzionalmente correlati.

Figura 3. Un menu pericoloso (in Microsoft Outlook)

Evitare comportamenti modali

Chiamiamo modale un sistema che, a fronte di una stessa azione dellutente, si comporta diversamente a seconda dello

stato in cui si trova e questo stato non facilmente riconoscibile dallutente. Questo comportamento andrebbe sempreevitato: se lutente non in grado di identificare facilmente lo stato del sistema, sar costretto a fare delle supposizioni,

4


5/18

con unelevata probabilit di commettere errori.

Un esempio classico quello della funzione per il riconoscimento di una password in cui le minuscole sono consideratediverse dalle corrispondenti maiuscole. Una password contenente caratteri minuscoli, se digitata quando il sistema nello stato di Caps Lock,viene rifiutata. In molti sistemi, per, lo stato di Caps Lock non visibile: lutente, difronte a un rifiuto della password sar perci portato a credere di avere sbagliato a digitare, e prover di nuovo, anche

pi volte. Raramente attribuir il problema al tasto di Caps Lock, che usato raramente (ma pericolosamentevicino al tasto alzamaiuscole, che si utilizza invece molto spesso). Il problema pu essere facilmente evitato rendendoben visibile lo stato di Caps Lock, per esempio con un messaggio posto vicino al campo dimmissione, dove lutenterivolge la sua attenzione, come nelle recenti versioni di Windows.

Un altro esempio spesso citato vi, un text editor in passato molto diffuso in ambiente Unix . Esso poteva trovarsi neglistati di attesa carattere oppure di attesa comando. Digitando il carattere a, nel primo caso lo si aggiungeva al testo incorso di stesura, nel secondo caso il sistema entrava nello stato di append, e si metteva in attesa di un caratteresuccessivo. Se l'utente dimenticava lo stato corrente, non era in grado di prevedere il comportamento del sistema. Ineffetti, lo stato era segnalato sul video, ma ai bordi, in modo scarsamente visibile perch lontano dal focusdellattenzione dellutente che, ovviamente, era concentrata sulla posizione del cursore nel testo o su quella delle dita

sulla tastiera.

Il programma MacPaint della Apple, uno dei primi programmi di disegno, risolveva un problema analogo in modoelegante (). Lutente poteva selezionare da una paletta lo strumento desiderato, e il sistema cambiava stato, percompiere le funzioni associate allo strumento. Il programma evidenziava lo strumento selezionato, e quindi lo stato delsistema, sulla paletta. Inoltre, con una tecnica adottata poi da molti programmi di questo tipo, il cursore assumeva laforma dello strumento prescelto (nel nostro esempio, la matita, per tracciare linee a mano libera). In questo modo, lostato del sistema era ben visibile proprio dove lutente rivolge la sua attenzione, e cio sul cursore. Questa tecnica non usata in PowerPoint (), dove il cursore mantiene sempre la forma di una croce, qualunque sia lo strumento selezionato.Poich gli strumenti vengono selezionati da un menu a tendina, che subito si richiude, lutente non ha modo di vedere lostato del sistema, e quindi di sapere quale figura verr tracciata muovendo il cursore.

Figura 4. Cursore non modale (MacPaint, 1984)

5


6/18

Figura 5. Cursore modale (da Microsoft PowerPoint 2003)

Usare funzioni obbliganti

Donald Norman definisce obbligante (in inglese: forcing function) una funzione in cui le azioni dellutente sonovincolate in modo tale che la mancata esecuzione di un passaggio impedisca il successivo4. In tal modo, egli obbligatoa compiere le azioni nella sequenza corretta. Si tratta di una tecnica molto efficace di prevenzione degli errori.

Nella vita quotidiana incontriamo spesso delle funzioni obbliganti. A volte ci danno fastidio, perch limitano i nostricomportamenti, ma ci risparmiano problemi pi gravi. Per esempio, alcune automobili emettono un segnale dallarmequando apriamo la portiera con la chiave inserita nel cruscotto. Questo per evitare che si esca dallauto dimenticando lachiave in macchina. Negli Stati Uniti, per un certo periodo le automobili montavano un dispositivo che impediva lapartenza quando le cinture di sicurezza non erano allacciate. Il dispositivo risult molto impopolare e fu in seguito

eliminato, ma era sicuramente molto efficace per prevenire un comportamento errato del conducente.A volte non ci rendiamo conto di utilizzare funzioni obbliganti. Per esempio, quando mettiamo in moto lautomobilecon la chiave, in realt compiamo con un solo gesto complesso tre operazioni: 1)- liberiamo il bloccasterzo, 2)-attiviamo il motorino di avviamento, 3)- mettiamo in moto. Se queste azioni fossero eseguibili separatamente (come sidoveva fare un tempo), potremmo eseguirle nellordine sbagliato, con problemi evidenti.

Anche nei sistemi software le funzioni obbliganti sono importanti. Per esempio, a partire dal sistema Star della Xerox,il primo computer personale basato sulla metafora della scrivania, tutti i sistemi di questo tipo adottano il modellooggetto-azione, piuttosto che quello azione-oggetto. In altre parole, lutente seleziona prima loggetto su cui desideraoperare (per esempio, cliccando sullicona di un file), e poi la funzione che vuole compiere (per esempio, il comandoStampaper stampare il file selezionato). Questa scelta, apparentemente arbitraria, permette di realizzare funzioni

obbliganti. Infatti, selezionando prima l'oggetto su cui operare, il sistema in grado di disabilitare tutte quelle voci dimenu che corrispondono ad azioni che non hanno senso su tale oggetto. Se saltiamo il primo passaggio (la selezionedelloggetto), il secondo non pu essere eseguito, perch la voce corrispondente del menu disabilitata. Questo nonsarebbe stato possibile selezionando prima il comando e poi il suo argomento. Cos, in , che rappresenta il primoMacintosh della Apple, tutte le voci che operano su file (Apri, Stampa, ecc.) sono disabilitate, perch nessun file stato selezionato.

4Cfr. Donald Norman,La caffettiera del masochista, Giunti, 1990, pag.171 e segg.

6


7/18

Figura 6. Finder (Apple Macintosh, 1984)

Imporre input vincolati

Questa tecnica, che generalizza quella delle funzioni obbliganti, consiste nel permettere allutente di fornire solo valoridi input corretti.

In vediamo diversi modi di chiedere limmissione di una data. In (a), il sistema non pone alcun vincolo al formato delladata. In (b), (c) e (d) il sistema pone vincoli via via pi stringenti. Quale soluzione in grado di prevenire meglio glierrori di digitazione? Possiamo facilmente scartare la (a), perch troppo libera, e la (b), perch la (c), pi informativa, sicuramente migliore. La (c) lascia ancora molta libert allutente, che pu digitare date formalmente scorrette. Nella(d), invece, i valori selezionabili dai tre menu a tendina sono preimpostati, e quindi sempre corretti. Non per ovvio

quale delle due ultime soluzioni sia la migliore. Per deciderlo, non basta unanalisi a tavolino: dovremmo fare delleprove duso con un sufficiente numero di utenti. Infatti, la (d), che a prima vista ci sembrerebbe la pi sicura, evitasicuramente che lutente digiti una data illecita, ma introduce un altro problema, che nellaltra soluzione non si pone. Inun menu a tendina molto lungo il mouse pu scivolare facilmente su una voce vicina a quella desiderata, soprattuttoquando si deve selezionare una delle voci pi in basso. Nel nostro esempio, le voci dei mesi sono soltanto 12, ma quelledei giorni 31, un numero abbastanza elevato. Quante sono quelle degli anni? Si inizia dal 1900? E qual lannoimpostato come default nel campo? Se fosse lanno meno recente, la probabilit di dover selezionare una voce moltolontana sarebbe alta, e la probabilit di errore pi elevata.

Figura 7. Esempi di input pi o meno vincolati

7


8/18

Non sovraccaricare la memoria a breve termine

Nel Capitolo 4 sono state brevemente descritte le caratteristiche della memoria a breve termine delluomo, in particolarela sua capacit limitata e la breve persistenza dellinformazione. Dialoghi che sovraccaricano la memoria a brevetermine risultano faticosi per lutente, e aumentano la probabilit che egli commetta degli errori. Tipico il caso deimessaggi pre-registrati dei call-center. A chi telefona viene letto un elenco di servizi disponibili, che spesso troppo

lungo per essere facilmente ricordato. Quando, durante lenumerazione delle alternative disponibili, lutente neidentifica una che potrebbe ragionevolmente fare al caso suo, la deve memorizzare e proseguire nellascolto,nelleventualit che ne vengano annunciate altre ancora pi pertinenti. Arrivato alla fine dellenumerazione, non raroil caso che, avendo dimenticato le alternative presentate allinizio, lutente debba rifare la telefonata e ascoltare da capolelenco.

Figura 8. Sovraccarico della memoria a breve termine

Richiedere conferme

Il sistema dovrebbe sempre avvertire l'utente quando questi richiede lesecuzione di azioni irreversibili o comunquepotenzialmente pericolose, e domandare conferma.

Le richieste di conferma devono essere formulate in modo semplice e non ambiguo. Un esempio corretto mostrato in, in cui il messaggio chiaro e le tre alternative ben distinte. Questo non il caso del messaggio dib, causata dallarichiesta di uscire da un computergame senza avere prima salvato lo stato del gioco. Sarebbe preferibile una forma piesplicita, che spiegasse meglio gli effetti delle tre alternative, senza usare negazioni. Per esempio: Warning: thegame was not saved e, sui tre pulsanti: Exit without saving Save and exit Cancel.

Il sistema non deve costringere lutente a conferme troppo complicate, come quella di c: qui non ci si accontenta dirichiedere allutente un semplice clic su un pulsante di OK, ma lo si obbliga a digitare le tre lettere che compongono laparola YES. Evidentemente, il progettista ha pensato che, cos facendo, si elimina la possibilit che lutente confermiper errore, ma la soluzione pu essere considerata alquanto vessatoria.

Le richieste di conferma dovrebbero essere limitate ai soli casi di operazioni per le quali leventuale annullamento fosseimpossibile, o richiedesse molto tempo. infatti inutile intralciare il lavoro dellutente richiedendogli di confermareoperazioni che, se effettuate per errore, potrebbero essere facilmente annullabili.

8


9/18

Figura 9. Alcune richieste di conferma, da sistemi degli anni 90:a) da Microsoft Word, b) da un computer game per Apple Macintosh, c) da AK-Mail per PC

Usare default inoffensivi

Questa tecnica consiste nell'usare, per quanto possibile, valori di default inoffensivi. Il sistema, in altre parole, nondovrebbe mai intraprendere per default lazione pi pericolosa tra quelle possibili in un determinato contesto. Peresempio, la richiesta di stampa di un documento di Microsoft Word 2007 ha come default lopzione Pagine dastampare = Tutte. Non viene richiesta alcuna conferma, nemmeno nel caso di documenti molto lunghi. A chi scrive capitato varie volte, durante la stesura di questo libro, di avviare per errore la stampa di tutto il documento (un file dioltre 200 pagine!), invece che della sola pagina corrente, come desiderato. Un lapsus costoso, le cui conseguenzeavrebbero potuto essere evitate da una semplice richiesta di conferma.

DiagnosiAnche se il progettista adotta le tecniche di prevenzione pi appropriate, rester sempre la possibilit che lutentecommetta un errore. Pertanto, il sistema deve sempre controllare linput e, nel caso che si riveli scorretto, dovr fornireallutente una spiegazione adeguata, che gli permetta di recuperare la situazione in modo rapido, senza incertezze esenza stress.

Sono tre le funzioni che un messaggio di errore ben progettato deve svolgere:

Allertare, cio segnalare che qualcosa non va;

Identificare, cio indicare che cosa non va, e perch;

Dirigere, cio spiegare all'utente i passi che deve compiere per ripristinare una situazione corretta: "oradevi fare questo".

9


10/18

In vediamo alcuni esempi di messaggi di errore. In (a), sono presenti, anche se in forma molto sintetica, le tre funzionisopra indicate. Lutente viene allertato per mezzo di unicona ben visibile (un grosso punto di domanda su fondobianco), lerrore viene correttamente identificato con un testo breve ma chiaro (The selected printer is notavailable), e viene indicata la possibilit di selezionare unaltra stampante: Do you want to select a differentprinter? Non si dice ancora come fare, si chiede soltanto di specificare le intenzioni: presumibilmente, in caso di

risposta affermativa, seguiranno ulteriori indicazioni. Nel complesso il messaggio accettabile, anche se, a ben vedere,descrive che cosa non va, ma non spiega il perch. Infatti, lindisponibilit della stampante potrebbe avere causediverse, tipicamente: 1)- lutente ha dato il comando di stampa senza modificare la stampante di default, che noncorrisponde a quella collegata al sistema, oppure 2)- la stampante selezionata quella corretta, ma spenta. Anche se ilsoftware non fosse in grado di discriminare fra queste due situazioni, potrebbe almeno indicare nel messaggio il nomedella stampante selezionata:The selected printer: is not available. In questo caso lutente potrebbecomprendere immediatamente la causa del problema e porvi rimedio.

Il messaggio dib corrisponde a una situazione di errore simile alla precedente (la stampante richiesta non disponibile).La scelta del colore dellicona di allerta (giallo) vuole correttamente segnalare che la situazione probabilmenterecuperabile. Il messaggio didentificazione dellerrore (Printer not found) sintetico ma chiaro. Le opzioniproposte allutente sono per incomprensibili. Lopzione Retrynon ha senso se lo stato del sistema non cambia per

esempio accendendo la stampante nel caso fosse spenta. Ma allutente non viene data alcuna indicazione in tal senso: seegli non fa nulla per correggere la situazione, la riesecuzione del comando di stampa non pu che portare allo stessorisultato. Osserviamo le altre due opzioni: qual la differenza fra Ignore e Abort? La prima, probabilmente,corrisponde a una presa datto del messaggio e, implicitamente, alla richiesta di tornare allo stato precedente allarichiesta di stampa. Ma allora sarebbe stato meglio usare il termine OK, oppure Cancel, a seconda delle convenzioniutilizzate negli altri messaggi dello specifico sistema. Se questa interpretazione del messaggio corretta, allora Abort inutile, e non corrisponde ad alcunaltra situazione possibile. Lintestazione del messaggio (System error) poiincomprensibile. Chi ha richiesto una stampante che non c: lutente o il sistema?

Lultimo esempio (c) usa correttamente unicona di colore rosso, per segnalare che stato rilevato un errore grave. Ilsimbolo usato dallicona (una croce a x, come quelle usate per segnalare i passaggi a livello) ci sembra pi corretto del

punto esclamativo del messaggio precedente, che possiede una certa connotazione di rimprovero. Ma la descrizionedellerrore che identifica analiticamente la causa del problema - espressa in linguaggio tecnico, comprensibile soloai programmatori che hanno sviluppato lapplicazione.

10


11/18

Figura 10.Messaggi di errore

Come abbiamo gi osservato alla fine del Capitolo 10, molto importante che il messaggio non contenga alcunrimprovero (anche se sottinteso) allutente. Al contrario, molte applicazioni web dellultima generazione adottano lapolitica opposta: il sito sembra chiedere scusa allutente per averlo portato a commettere un errore (self-deprecatingerror messages), come nellesempio di , o della Figura 20 del Capitolo 10 (in basso a destra).

11


12/18

Figura 11.

Tutti gli esempi discussi si riferiscono asingoli errori. Sono frequenti, tuttavia, situazioni pi complesse, in cui lutentecompie pi di uno sbaglio. Lesempio pi tipico la compilazione di una form in unapplicazione web. Lutenteimmette i valori in diversi campi, e quindi ne chiede linvio al sistema, che li dovr controllare segnalando gli eventualierrori. Poich pi di un valore pu essere errato, ne possono seguire messaggi di errore multipli, che devono possedereunadeguata granularit ed essere facilmente associabili ai valori cui si riferiscono.

La , tratta da un sito di commercio elettronico di molti anni fa, mostra un esempio prodotto artificialmente,introducendo a bella posta un errore in ogni campo della form. In questo caso, allutente risulta molto difficile associareil messaggio di errore al campo cui si riferisce. Infatti, il messaggio copre interamente la form in cui sono staticommessi gli errori. I messaggi sono troppo numerosi per essere facilmente ricordati (si ricordino le limitazioni dellamemoria a breve termine). In pratica, lutente costretto a prendere appunti sulle correzioni da effettuare, prima ditornare alla form di imputazione dati.

12


13/18

Figura 12.Messaggi di errore multipli (da un sito di e-commerce, anni 90)

La situazione di pi corretta, anche se perfettibile. In questo caso, lelenco dei numerosi errori rilevati presentatomediante un piccolo pannello sovrapposto alla form dimmissione dati, e facilmente spostabile sullo schermo perrendere visibili tutti i campi.

Figura 13.Messaggi di errore multipli (www.mediaworld.it, fine anni 90)

La soluzione di gran lunga pi corretta tuttavia quella esemplificata in . In questo caso la segnalazione di errore

13
http://www.mediaworld.it/http://www.mediaworld.it/


14/18

visualizzata immediatamente sopra il campo errato (per maggiore evidenza, il messaggio in colore rosso vivo).

Figura 14.Tecnica corretta per la segnalazione di errori su una pagina web

La spiegazione dellerrore e di come fare per correggerlo dovrebbe essere particolarmente dettagliata e chiara quando ilsistema si rivolga a utenti poco esperti. Particolarmente interessante, a questo proposito, lo stile adottato da Amazon neisuoi primi anni di esistenza, quando i siti di commercio elettronico erano ancora poco noti alla maggior parte degliutenti del Web. Le spiegazioni erano piuttosto estese, e spesso contenevano anche le motivazioni delle richieste fatte

allutente, come nellesempio di .

Figura 15.Da http://www.amazon.com (circa 1995)

Per evitare una verbosit eccessiva, pu convenire esprimere il messaggio in forma sintetica, permettendo perallutente di richiedere spiegazioni pi dettagliate.

Correzione

Quando lutente commette un errore, deve essere possibile correggerlo. Questo processo pu essere attuato, secondo icasi, dallutente o dal sistema, o da entrambi, in modo cooperativo. Le situazioni possibili sono schematizzate nella .5 Apartire da uno stato iniziale del sistema, lutente compie unazione, per esempio limmissione del valore di una data inun campo di una form. Se lazione corretta, il sistema si porta nello stato desiderato, indicato in figura come statofinale. Per esempio, la data viene accettata e registrata in un file. Se invece lazione non corretta (per esempio, perchla data contiene degli errori formali), il sistema si porta in uno stato di errore. A partire da questo stato, il processo dicorrezione pu avvenire con due strategie diverse, a seconda delle situazioni. Vediamole in dettaglio.

5

Cfr.Francis Jambon, Taxonomy for Human Error and System Fault Recovery from the Engineering Perspective , InternationalConference on Human-Computer Interaction in Aeronautics (HCI-Aero'98), Montral, Canada, 27-29 may 1998. pagg. 55-60.

14
http://www.amazon.com/http://www.amazon.com/


15/18

Figura 16.Ripristino dallerrore

Backward recovery

Secondo questa strategia, si tratter di annullare le conseguenze negative dellerrore commesso, e riportare il sistemanello stato iniziale, dal quale lutente potr compiere, questa volta in modo corretto, lazione che aveva sbagliato. Ilprocesso per riportare il sistema nello stato iniziale si chiama ripristino - in inglese, backward recovery.6Nel casoelementare della data sbagliata, la backward recovery consister semplicemente nel cancellare dal campo di input ilvalore scorretto. Questo compito pu essere svolto dallutente oppure effettuato dal sistema, che sbianca il campo eposiziona il cursore allinizio dello stesso, in attesa del nuovo input che si spera porter allo stato finale desiderato.

In altri casi gli interventi di backward recovery possono essere pi complessi. Per esempio, supponiamo che lutentedigiti una data formalmente corretta, ma diversa da quella che voleva immettere nel sistema e che si accorga del lapsus

solo dopo avere confermato i dati. In questo caso, il sistema avr accettato il valore, e lo avr registrato nella base dati.La backward recovery richieder quindi di modificare la base di dati: unazione molto diversa da quella di prima.

La backward recovery pu essere considerata un modo di tornare indietro nel tempo. Il modo pi semplice di farlo quello di utilizzare una funzione di undo, che annulli le conseguenze dellultima azione. I sistemi pi evolutiforniscono la possibilit di annullare le ultime n azioni dellutente, con n anche molto grande (undo a pi livelli).La realizzazione di funzionalit di undo non sempre possibile, o praticabile. Infatti, possono essere necessarie grandiquantit di memoria (per conservare gli stati precedenti), e gli algoritmi di ripristino possono essere molto complessi.Tuttavia, in alcune tipologie di sistemi, meccanismi di undo sofisticati sono indispensabili, come per esempio neiprogrammi di grafica. La mostra le funzioni di undo in PowerPoint 2007(a) e Photoshop CS3 (b). In entrambi, unpannello mostra lelenco delle ultime azioni effettuate dallutente. In PowerPoint le azioni pi recenti sono in alto,mentre in Photoshop sono in basso. In entrambi i casi possibile annullare le ultime n azioni con un solo comando. In

(a), sono state selezionate le ultime 4 azioni, che verranno annullate al rilascio del mouse. In (b), selezionandounazione, vengono annullate tutte le azioni successive. In entrambi i sistemi lundo pu, a sua volta, essere annullato(funzione di redo).

6 Recovery significa recupero, riparazione, reintegro.

15


16/18

Figura 17.Undo a pi livelli: PowerPoint 2007 (a) e Photoshop CS3 (b)

Forward recovery

Esistono situazioni in cui la correzione dellerrore avviene con un processo diverso. Invece di tornare allo stato inizialee da l ripetere lazione, si cerca di raggiungere lo stato finale direttamente dallo stato di errore, senza prima tornareindietro. Questo processo si chiama forward recovery (), e pu essere effettuato automaticamente dal sistema, orichiedere lintervento dellutente. Un sistema che attua sistematicamente strategie di forward recovery si dice error

tolerant.La mostra il comportamento del motore di ricerca di Google quando lutente compie un errore di battitura. In questocaso lutente ha digitato nel campo di ricerca la parola chiave usibilit, invece di usabilit. Poich la parola digitata nonesiste, il sistema la corregge e la interpreta come usabilit: senza nulla chiedere preventivamente allutente, porta atermine la ricerca con questa parola. Lutente avvertito a posteriori: Forse cercavi usabilit.

Figura 18.Forward recovery in http://www.google.com

La forward recovery pu essere attuata anche dallutente. Supponiamo di dover disegnare un quadrato, con PowerPoint

o altro programma di grafica. Normalmente, occorre selezionare lo strumento rettangolo e, tenendo premuto il tastoShift, tracciare la figura sul foglio visualizzato. Se lutente si dimentica di tenere premuto il tasto Shift, la figura

16
http://www.google.com/http://www.google.com/


17/18

risultante sar rettangolare. Per ottenere il quadrato potr allora scegliere fra due strategie alternative: 1)- cancellare ilrettangolo e ricominciare il disegno (backard recovery) oppure 2)- conservare il rettangolo e modificandolo fino atrasformarlo in un quadrato (forward recovery).

Ci sono casi in cui la backward recovery non possibile, e lunica strategia disponibile la forward recovery. Se peresempio rompiamo un piatto, non saremo evidentemente in grado di ripristinarlo nella configurazione iniziale: potremo

soltanto tentare di aggiustarlo incollando i vari pezzi.I due ultimi esempi mostrano che, in molti casi, la recovery imperfetta: si pu solo arrivare a unapprossimazionedello stato desiderato. Un piatto aggiustato con la colla non sicuramente uguale a un piatto integro, e un quadratodisegnato a mano libera potrebbe essere impreciso. In entrambi i casi, non si raggiunger lo stato finale inizialmentedesiderato, ma uno stato finale approssimato ().

Figura 19.Ripristino imperfetto

In ogni caso, che si tratti di recovery allindietro o in avanti, sar bene che il progettista ricordi le raccomandazioni

seguenti, che abbiamo gi menzionato nel Capitolo 10 dedicato allISO 9241-110:

Minimo sforzo di correzione: i passi richiesti allutente per correggere lerrore dovrebbero essere il pipossibile semplici, e il sistema dovrebbe porre in atto ogni accorgimento per ridurne il numero e la complessit,svolgendo automaticamente quelle operazioni che, per loro natura, non richiedono lintervento umano.

Correzione differibile: lutente dovrebbe poter rimandare la correzione dellerrore a un momento successivo.Questo, in virt del principio di controllabilit, di cui abbiamo ampiamente trattato nel Capitolo 10. Pu darsi,per esempio, che lutente non possegga tutte le informazioni per correggere immediatamente i dati di input cheil sistema non ha accettato.

Correzione automatica modificabile: quando il sistema in grado di correggere automaticamente lerrorecommesso dallutente, dovrebbe avvisarlo della correzione e permettergli di modificarla. Cos, per esempio, seun correttore ortografico modifica la parola digitata dallutente, lutente dovrebbe esserne avvertito e poternemodificare la correzione.

Conclusioni

Il senso di questo capitolo che, nel dialogo con un sistema interattivo, non esiste una dicotomia netta fracomportamento errato e comportamento corretto. Parafrasando ancora una volta Donald Norman, tutta l'interazioneuomo-macchina dovrebbe essere trattata come una procedura cooperativa fra utente e sistema, dove gli equivocipossono nascere da entrambe le parti, e devono essere risolti con chiarezza e serenit. Lerrore parte integrante delcomportamento umano, e come tale deve essere previsto e accettato.

Un sistema ben progettato non deve pretendere da chi lo usa una conformit perfetta a regole precise e non modificabili,dovr invece indicargli, nei modi e nei contesti pi opportuni in funzione delle diverse circostanze, che cosa pu o deve

17


18/18

fare per raggiungere i suoi scopi, adattandosi in modo flessibile e intelligente alle eventuali deviazioni che, in ognicaso, saranno numerose e frequenti. Questo il senso del principio di tolleranza verso lerrore che lo standard ISO9241-110 richiede ai sistemi usabili. Rispetto alla prassi corrente nellingegneria del software, e nonostante i grandiprogressi che negli ultimi anni sono stati compiuti nellusabilit dei sistemi, tutto ci richiede ancora un profondocambiamento di mentalit. La prevenzione e il trattamento degli errori una componente ineliminabile e importante del

lavoro di progettazione di un sistema, e il progettista non la deve considerare un optional, dedicato ad alcuni utentiparticolarmente inaccurati o distratti.

Ripasso ed esercizi

1. Descrivi la classificazione dell'errore umano secondo Reason, indicando un esempio per ciascuna tipologiadi errore.

2. Spiega la differenza fra lapsus e mistake, e indica due esempi di ciascuna tipologia di errore, tratti dalla tuaesperienza personale dell'uso di qualche sistema interattivo.

3. Che cosa significa "progettare per l'errore"?

4. Spiega che cosa si intende per comportamento modale di un'interfaccia utente, e perch talecomportamento va evitato. Indica un esempio dinterfaccia modale, e spiega come questa interfaccia possa

essere resa pi usabile.5. Che cosa sintende per funzione obbligante? Descrivine due esempi diversi da quelli indicati nel testo.

6. Perch, per prevenire errori, necessario non sovraccaricare la memoria a breve termine dellutente?

7. Quando opportuno chiedere conferma all'utente prima di eseguire una funzione da lui richiesta, e quandonon lo ?

8. Quali sono le caratteristiche di un buon messaggio di errore?

9. Quali sono le caratteristiche di un buon messaggio di errore per transazioni sul Web?

10. Spiega la differenza fra forward error recovery e backward error recovery, con esempi.11. Valuta la gestione degli errori nel tuo telefonino, e formulane un motivato giudizio dal punto di vista

dellusabilit.

Approfondimenti e ricerche

1. Il Web ricco di esempi di messaggi d'errore mal progettati. Costruisci una galleria di esempi di messaggisbagliati, raccogliendoli in categorie tipiche. Suggerimenti: cerca con Google, per esempio, errormessage guidelines e immagini con parole chiave error message.

2. Donald Norman, nel suo libroLa caffettiera del masochista, classifica i lapsus in varie tipologie. Dopoaver letto questa classificazione, trova un esempio di ciascuna tipologia di lapsus nelluso dei programmiche usi abitualmente con il tuo personal computer.

3. Esamina le modalit di prevenzione e di gestione degli errori dellutente in tre siti di commercioelettronico appartenenti allo stesso settore di mercato, e individuane pregi e difetti. Quale dei tre siti ha ilmiglior trattamento degli errori? Motiva dettagliatamente la tua risposta.

18

M Cap.11: Progettare per l'errore

Documents

Transcript of M Cap.11: Progettare per l'errore