l'errore umano
IUM L'errore umano
1. Descrivere una possibile classificazione dell'errore umano, descrivendo un esempio per ciascuna tipologia di erroreUna possibile classificazione è :
- azione involontaria
- azione spontanea
- lapsus
- azione intenzionale ma errata (mistake)
(versione alternativa) L'errore umano è classificabile nel seguente modo:
- Azione involontaria: cammino in una stanza passando vicino ad una scrivania ed involontariamente faccio cadere un libro;
- Azione spontanea: sto prendendo una bottiglia ed urto contro un bicchiere facendolo cadere;
- Lapsus: sto cercando di accendere un fornello, però ho dimenticato di aprire il contatore. ;
- Azione intenzionale ma errata: voglio raggiungere un determinato obiettivo però metto in atto delle azioni che producono il raggiungimento di un altro obiettivo.
2. La ISO 9241-10 richiede che un dialogo uomo-computer ben concepito sia "tollerante verso l'errore dell'utente". Individua, fra le funzioni del tuo PC, un esempio di dialogo (non discusso a lezione) che rispetta questo requisito, e un esempio che non lo rispetta.
Un esempio di funzione non "tollerante verso l'errore dell'utente" è la chiusura di default del browser Mozilla. Nel caso ci sia solo una scheda aperta non richiede nessuna conferma di chiusura e se l'utente avesse premuto involontariamente sulla "X" mentre stava terminando la compilazione di un modulo online, avrebbe perso tutto il suo lavoro e dovrebbe ricominciare da capo per ritornare alla situazione precedente l'errore.
Anche Firefox presenta tale inconveniente, non si comporta diversamente nemmeno explorer e tutti gli altri browser, però per ovviare a ciò nel browser Firefox è possibile installare un'estensione chiamata Session Saver che salva tutti i tab aperti (e relativi url) in modo che a una successiva riapertura il browser si ripresenterà esattamente come quando è stato chiuso.
Un esempio di funzione "tollerante verso l'errore dell'utente" è la "svuota cestino" nei sistemi MS Windows. L'operazione è irreversibile, però dopo il clic nel menù a tendina compare una finestra di dialogo che chiede conferma per proseguire.
Un'altro esempio di funzione tollerante è il tool mkreiserfs che consente di creare un file system reiser su una determinata partizione, prima di procedere con la formattazione l'interfaccia testuale informa a chiare lettere (con un messaggio evidente scritto interamente in maiuscolo) che se si accetterà di procedere tutti gli eventuali dati presenti sulla partizione verranno persi irrimediabilmente.
3. Che cosa significa "progettare per l'errore"?
Progettare per l'errore significa :
- Comprenderne le cause per eliminarle o ridurle : prevenzione dell'errore
- Progettare sistemi tolleranti verso l'errore
- Rendere facile il riconoscimento dell'errore e facilitarne la correzione
- Rendere ogni azione reversibile
- Cambiare atteggiamento verso l'errore: non giusto/sbagliato, ma approssimazioni verso l'obiettivo
4. Spiega che cosa si intende per comportamento modale di un'interfaccia utente, e perchè tale comportamento va evitato. Indica un esempio di interfaccia modale, e spiega come questa interfaccia possa essere resa più usabile.
Quando un'interfaccia si comporta in modalmente il sistema si comporta diversamente a seconda della modalità corrente, questo tipo di comportamento va evitato o va evidenziata in maniera non equivocabile il suo stato corrente perchè l'utente potrebbe compiere operazioni senza accorgersi di essere nella modalità sbagliata per compierle causando quindi un suo errore.
In GIMP 2.2 (Gnu Image Manipulation Program) tutti i bottoni relativi agli strumenti di disegno se selezionati fanno cambiare anche la forma del puntatore aggiungendo ad esso anche la forma del bottone selezionato (in modo da riconoscere chiaramente la modalità in cui si è), solo un bottone, "seleziona regioni per colore", fa apparire il puntatore come una semplice freccia, per rendere più usabile questa funzionalità si potrebbe adottare il medesimo accorgimento adottato per gli altri bottoni
(versione alternativa) Comportamento modale di un'interfaccia significa associare ad uno stesso oggetto (es. il cursore del mouse) più significati a seconda dello stato o della modalità scelta dall'utente. Questa modalità andrebbe evitata perchè richiede all'utente di tenere a mente quale funzione ha selezionato e non offre un feedback circa quello che si sta per compiere fino a dopo averlo compiuto. Un esempio di comportamento modale lo possiamo trovare in Power Point quando si seleziona una figura geometrica da disegnare nella slide. Qualsiasi scelta l'utente faccia compare una crocetta. Per risolvere questo problema sarebbe utile porre vicino alla crocetta il simbolo della figura selezionata (come avviene in Impress).
5. Che cosa si intende per "funzione obbligante"? Descrivine un esempio.
Una funzione obbligante è una funzione progettata in modo da rendere impossibili le azioni non lecite nel contesto corrente.
Ad esempio in nautilus, file manager di gnome, (ma anche in pressochè tutti i file manager grafici) quando si clicca destro su una cartella la voce "incolla i file nella cartella" è disattivata se non si è precedentemente selezionato dei file o cartelle da copiare o tagliare, in questo modo è impossibile incollare se non si è selezionato nulla.
Un altro tipico esempio sono i bottoni di avanti e indietro dei browser, appena lo si apre essi sono disabilitati in quanto è la prima pagina che visitiamo e non è possibile tornare alla precedente o andare alla successiva.
Stessa identica cosa per i bottoni di Undo e Redo negli editor e nei word processor.
(versione alternativa) Una funzione obbligante è una funzione che impedisce all'utente di compiere azioni non lecite. Un esempio di funzione obbligante si può trovare nelle taglierine elettroniche. Dopo aver posizionato la risma di fogli da tagliare è possibile procedere al taglio solamente premendo contemporaneamente due tasti. Questo impedisce all'utilizzatore di poter rimanere ferito dalla lama.
6. Quando è opportuno chiedere conferma all'utente prima di eseguire una funzione da lui richiesta, e quando non lo è?
E' opportuno chiedere conferma ogni qual volta si effettuano operazioni irreversibili o pericolose, non lo è, anzi è sconsigliato perchè rende l'uso dell'interfaccia troppo macchinoso, quando l'azione che si sta per compiere è facilmente reversibile.
Ad esempio è opportuno chiedere conferma prima della formattazione di un dischetto mentre non lo è quando si chiude un programma e tutti i dati sono già stati salvati (un esempio di quest'eccessiva premura è ben evidente in eclipse e in emule)
(versione alternativa) E' opportuno richiedere all'utente conferma di una sua operazione nei casi in cui l'azione che si compirà sarà di tipo irreversibile, spiegando le alternative possibili e le conseguenze. Non è opportuno richiedere conferma negli altri casi in cui un possibile errore può essere rimediato con uno sforzo eguale (o poco superiore) a quello di rispondere alla conferma.
7. Quali sono le caratteristiche di un buon messaggio di errore?
- Spiegare cosa non va in maniera esplicita
- Dare indicazioni su come risolvere
- Usare termini facilmente comprensibili
- Educato, esauriente e preciso
8. Quali sono le caratteristiche di un buon messaggio di errore per transazioni sul web?
- Ben visibili ed espressi in modo chiaro e comprensibile ai più
- Preservare il lavoro svolto dall'utente , ad esempio in una form se un solo campo è sbagliato, ripresentarla con tutti i dati precedenti ad eccezione del dato errato.
- Ridurre al massimo il tempo necessario a correggere l'errore
The content on this page is licensed under the terms of the http://www.gnu.org/licenses/fdl.txt.
Sidebar
Search Wiki PageName
Calendario-Filtra
|
|
Sidebar
Login
Utenti in linea
Ci sono 1 utenti online
Ultime modifiche
- Home
- Design Pattern
- ConvertTable
- IUM L'errore umano
- IUM L'utente I: percezione visiva
- IUM Progettare per l'utente
- IUM Usabilità II
- IUM Valutare l'usabilità
- IUM Aiutare l'utente
- IUM L'utente III: percezione auditiva - tatto e sistema motorio
- IUM L'utente II: il colore
- Piattaforma comune e unica per condivisione materiale
- Struttura dei cataloghi XML
- Istruzioni d'uso
- Implementazione JXTA P2P
- Peer Core
- Scambio Cataloghi
- Downloader
- A spirale
- Processo software
- Introduzione
- Modellazione del controllo
- Sviluppo iterativo e Unified Process
- Evolutivo
- Ingegneria dei sistemi
- Progettazione con riuso
- UML
- Definizione dei diagrammi della progettazione di classi
- Analisi e progettazione Object Oriented
- Progettazione architetturale
- Decomposizione modulare
- Della macchina astratta
- Client-Server
- Del deposito
- Strutturazione del sistema
- Definizione dei diagrammi d'interazione
- Definizione dei diagrammi d'iterazione
- Definizione del modello del dominio
- valutazione






