Esercizi - 7. Le regole di design
Qual era il problema con l’esempio di sintesi che confrontava un’interfaccia a riga di comando con un’interfaccia grafica? Potete suggerire una correzione per rendere un’interfaccia visiva più trasparente?
Risposta
Per dimostrare il principio di sinteticità all’interno dell’apprendibilità, in questo esempio si è affermato che l’interfaccia visiva per un sistema di gestione dei file fornisce informazioni immediate sulla nuova posizione di un file dopo che è stato spostato. Al contrario, un’interfaccia a linguaggio di comando richiede che l’utente ricordi la directory in cui è stato trasferito il file e immetta esplicitamente i comandi per esaminarla e verificare così la presenza del file. Per essere veramente sicuri che lo spostamento sia avvenuto, si dovrebbe controllare anche la directory originale per appurare che non contenga più il file. In queste affermazioni, però, c’è un errore: l’ipotesi che i sistemi visivi di gestione dei file forniscano sempre informazioni sulla nuova posizione di un file. Per evidenziare questo errore usando l’esempio relativo al Macintosh presente nel testo, osserviamo che se un file viene spostato da una cartella aperta (il cui contenuto è visibile all’utente) a una chiusa (il cui contenuto è nascosto), la sua posizione non viene indicata all’utente, a meno che quest’ultimo non si ricordi di aprire la cartella di destinazione per esaminarne l’interno. Questo è un esempio di trasparenza ritardata e non immediata come suggerisce l’esempio.
Potremmo risolvere questo problema di trasparenza ritardata richiedendo che la cartella di destinazione sia aperta (vincolo che probabilmente sarebbe troppo restrittivo, data la dimensione limitata dello schermo) oppure tenendola aperta temporaneamente per dimostrare che contiene il file. Anche quest’ultimo suggerimento, però, non è perfetto, perché si potrebbe voler verificare anche che il file non è più nella cartella originale; per questo occorre però essere sicuri che la nuova cartella non impedisca la vista della vecchia. In pratica, questo potrebbe essere troppo difficile da garantire in generale.
In questo capitolo è stato suggerito che la coerenza può essere considerata una proprietà importante dei principi interattivi, allo stesso livello dell’apprendibilità, della flessibilità e della robustezza. In tal caso, quali principi trattati nel capitolo supportano la coerenza?
Risposta
L’analisi della coerenza ha suggerito che quest’ultima può assumere molte forme, perché di solito si fa riferimento a essa in relazione a qualche altra caratteristica dell’interazione tra utente e sistema. Come già detto nel testo la coerenza è collegata ai seguenti principi:
Inoltre, potremmo interpretare anche altri principi come contributi della coerenza:
Alcuni altri principi per la coerenza presi dal testo e da altre fonti:
La coerenza può essere pertinente alla forma delle espressioni di input/output
relative al modello concettuale del sistema dell’utente. Un esempio nel testo
implica l’uso di chiavi le cui posizioni relative sono simili ai comandi per
i sistemi (qualsiasi insieme di quattro tasti sulla macchina da scrivere che
formano una diagonale per indicare le direzioni su, giù, a sinistra e a destra
per un comando d’input).
Come discusso nell’esercizio sull’uso del colore, la coerenza può essere
rispetto alle convenzioni sociali o culturali (per esempio, l’uso del rosso
per indicare stop o caldo, del verde come segnale per andare, del blu per indicare
freddo).
Trovate più informazioni possibili sugli standard ISO correlati all’usabilità. Suggerimento: molti standard sono decritti in termini di ergonomia. Quanti diversi standard e bozze di standard potete trovare?
Risposta
Ricerca a risposta aperta
Sapreste immaginare dei casi in cui sarebbe violata la linea guida "nome-verbo", suggerita nelle linee guida Apple per l’interfaccia del desktop? Suggerite altre linee guida astratte o principi dotati di coerenza che supportano l’esempio. Suggerimento: pensate allo spostamento dei file sul desktop.
Risposta
La linea guida nome-verbo suggerisce che possiamo visualizzare tutte le operazioni che l’utente eseguirà come costituite da un’azione (il verbo) che agisce con un argomento (il nome). Nel caso di spostamento di un file (o di copia, per quanto riguarda ciò), l’operazione (spostamento o copia) richiede più di un argomento. Il modo in cui lo spostamento viene eseguito richiede che l’utente prima selezioni l’icona per il file da muovere e poi indichi lo spostamento implicitamente trascinando l’icona selezionata nella cartella di destinazione. I nomi in questo dialogo sono il file da spostare e la cartella di destinazione. Il verbo è l’operazione di spostamento. Il modo naturale di esprimere ciò è nell’ordine nome-verbo-nome. In senso stretto, per attenersi alla linea guida nome-verbo, dovremmo indicare sia il file di destinazione sia la cartella di destinazione prima di selezionare l’operazione di spostamento. Questo sarebbe coerente, relativamente all’espressione d’input, con la maggior parte degli altri comandi sul desktop. Per l’utente, però, sono più importanti i principi di manipolazione diretta e familiarità. Spostare i file trascinandoli sul desktop è molto simile al modo in cui nel mondo fisico prendiamo un oggetto e lo trasferiamo in una nuova posizione. L’operazione di trascinamento è incrementale e facilmente ripristinabile; lo spostamento in una posizione può essere annullato all’interno della stessa operazione perché il trascinamento può continuare fino a quando il file viene rilasciato. L’esempio di spostamento dei file è leggermente artificioso perché qualcuno potrebbe sostenere che non c’è violazione della linea guida nome-verbo (quindi, lo spostamento rimane ancora coerente rispetto all’espressione d’input) poiché il verbo è "spostare nella cartella di destinazione". Forse un esempio migliore è il comando per cercare in un file system i file che corrispondono a una certa specifica. Qui, l’operazione è eseguire la ricerca qualificata e l’argomento è il nome e l’insieme di cartelle o dischi del sistema che si desidera esaminare. Tipicamente, questo tipo di operazione viene definito da una finestra di dialogo che consente all’utente di indicare in un qualsiasi ordine le specifiche dell’operazione (i parametri di ricerca) e le cartelle o i dischi da analizzare. Una volta che questo dialogo non ordinato è terminato, l’utente decide che il sistema può eseguire l’operazione. Questo tipo di dialogo "a compilazione di moduli" non rispetta né la linea guida nome-verbo né la linea guida verbo-nome; per l’utente l’ordine è più flessibile che coerente.
Sapreste immaginare dei casi in cui non viene seguita la linea guida di controllo utente suggerita da Apple? Suggerimento: pensate all’uso delle finestre di dialogo.
Risposta
La linea guida di controllo utente afferma che "L’utente, non il computer, inizia e controlla tutte le azioni". Nel caso delle finestre di dialogo, questa linea guida viene chiaramente contraddetta. Si può usare una finestra di dialogo per indicare quando si verifica un errore nel sistema. Una volta che l’errore è stato rilevato e presentato nella finestra di dialogo, l’unica azione che il sistema consente all’utente è confermare l’errore e congedare la finestra di dialogo. Il sistema a ragione attiva il dialogo dell’utente. La natura "a sospensione" della finestra di dialogo serve per assicurare che l’utente abbia realmente notato che c’era un errore. Probabilmente, gli unici errori che verranno fatti in questo modo intrusivo sono quelli che l’utente deve comunque conoscere prima di poter continuare, quindi l’attivazione autonoma del dialogo è garantita. A volte, però, le finestre di dialogo non vengono usate per indicare gli errori e impediscono all’utente di compiere azioni che altrimenti vorrebbe eseguire. La finestra di dialogo, per esempio, può chiedere all’utente di inserire informazioni per specificare i parametri per un comando; se l’utente non sa cosa digitare, la finestra resta bloccata. Spesso l’utente può scoprire le informazioni necessarie esaminando una parte del sistema, ma per far ciò deve uscire dalla finestra di dialogo (e perdere quindi le impostazioni già inserite), individuare le informazioni mancanti e ricominciare. Questo tipo di sospensione non è auspicabile. Probabilmente la linea guida di controllo utente è progettata per evitare questo tipo di azione autonoma del sistema, ma non sempre viene applicata.
Trovate un libro sulle linee guida. Elencate le linee guida che contiene e classificatele secondo l’attività nel ciclo di vita del software in cui più probabilmente saranno applicate.
Risposta
Usiamo come fonte sulle linee guida il libro di Mayhew Principles and Guidelines in Software and User Interface Design [230]. Generalmente, tutte le linee guida pongono dei vincoli all’attività di design e quindi dovrebbero essere noti durante la fase di specifica dei requisiti. Nella lista seguente, ci concentreremo sulle fasi (design architetturale, design dettagliato, test delle unità e della codifica, integrazione e test) che risultano più influenzate dalle linee guida. I numeri tra parentesi indicano il riferimento di pagina per la linea guida data.
Design architetturale
Design dettagliato
Test delle unità e della codifica
Integrazione e test
a) Definite le differenze fra principi, linee guida e standard e illustratele con degli esempi.
b) Perché il contesto è importante nella scelta e nell’applicazione di linee guida e principi per la progettazione d’interfaccia? Chiarite la vostra risposta con alcuni esempi.
Risposta accessibile
solo ai docenti
a) Perché ci sono pochi standard HCI veramente efficaci?
b) In che modo le regole d’oro e le euristiche aiutano i progettisti d’interfacce a tener conto della psicologia cognitiva? Chiarite la vostra risposta con esempi.
Risposta accessibile
solo ai docenti
Usando il linguaggio dei pattern della progettazione web in Design of Sites [356], create un progetto per un sito di commercio elettronico per vendite al dettaglio. In che modo il linguaggio dei pattern ha facilitato la progettazione?
Risposta
Progetto