Home | Search | Help  
Home Page Università di Genova

"Linee guida" per la progettazione di interfacce per il web

Non esistono linee guida universalmente riconosciute per la progettazione delle interfacce interattive; si tratta piuttosto di principi generali che devono essere interpretati ed applicati rispetto ad un particolare contesto. Si tratta quasi sempre di principi nati in epoca "pre-web" nell'ambito delle applicazioni tradizionali (off-line) che fanno uso di interfacce grafiche.

Nell'ambito del web molti di questi principi sono ancora validi, altri devono essere rivisti (si veda l'elenco degli articoli suggeriti al fondo della pagina).
  1. Usare un dialogo semplice e naturale
  2. Usare il linguaggio dell'utente
  3. Minimizzare il carico di memoria dell'utente
  4. Essere consistenti
  5. Fornire feedback
  6. Fornire uscite chiare
  7. Fornire scorciatoie
  8. Gestire gli errori
  9. Curare la manualistica e fornire meccanismi di help
  10. Fornire possibilità di personalizzazione

  1. Usare un dialogo semplice e naturale
    Il linguaggio che si usa (ad esempio nei messaggi di errore, nelle finestre di dialogo, nei manuali on-line) deve essere semplice.
    • Le metafore devono essere usate in modo consistente. Si devono scegliere delle metafore che aumentano la comprensione da parte dell'utente e si deve evitare di "rompere" la metafora. Nel Macintosh, per esempio, si usa il cestino (metafora del desktop) per la cancellazione dei file ma la stessa metafora è usata anche per estrarre i dischetti.
    • Nei manuali on-line si deve usare un linguaggio tecnico e si devono evitare i sinonimi. Ad esempio, non si dovranno alternare frasi del tipo:
      1. registrare un file
      2. salvare un file
      3. memorizzare un file
      ma sceglierne una ed usare sempre la stessa (per un utente non esperto le tre frasi potrebbero rappresentare azioni diverse!).
    • Si devono scrivere solo le informazioni necessarie: si deve sempre ricordare che lo schermo è una risorsa limitata.
    • L'informazione deve essere strutturata (organizzata in gruppi omogenei, come succede ad esempio nei menu) e ordinata (l'utente è sensibile anche a piccole variazioni di allineamento).
    • L'informazione non rilevante deve essere nascosta (ad esempio mediante l'uso di widgets quali list box e scroll bar) in modo tale che l'utente non sia distratto da troppe informazioni.

  2. Usare il linguaggio dell'utente
    • Chi usa l'interfaccia non deve conoscere il gergo informatico. Ad esempio, va bene carattere, mentre non va bene byte.
    • Si deve usare una terminologia basata sul task (cioè sul compito che l'utente vuole svolgere). Supponiamo di voler prelevare del denaro da un Bancomat momentaneamente sconnesso dalla rete. Possiamo avere messaggi di tipo diverso.
      1. Un esempio messaggio errato è:   "Il bancomat non è connesso, si usino i limiti locali"   perchè all'utente non interessa se manca o meno la connessione e non necessariamente conosce i limiti locali del bancomat.
      2. Un esempio di messaggio corretto è:   "Prelievo limitato a XXX euro"
    • Alcuni studi hanno messo in evidenza che è difficile dedurre delle conclusioni corrette a partire da proposizioni che contengono una negazione. Quindi nei messaggi è meglio non usare negazioni. Sempre con riferimento al caso del bancomat:
      1. Un esempio di messaggio errato è:   "Non comporre una cifra che non sia multiplo di 50"
      2. Sarà invece opportuno fornire la seguente informazione:   "Prelevare denaro in multipli di 50"
    • Per aumentare la comprensione dei messaggi si possono usare le icone

  3. Minimizzare il carico di memoria dell'utente
    • Riconoscere è più facile che ricordare e quindi si devono rendere visibili gli oggetti e le azioni che si possono compiere su di essi.
    • Prevedere valori di default che siano significativi (i valori di default permettono di limitare alcuni errori di battitura).
    • Mantenere la storia passata.
    • Applicare un piccolo numero di regole a oggetti di tipo diverso (es copy, paste, cut, ...)

  4. Essere consistenti
    La consistenza è forse il principio più importante: gli utenti vogliono interfacce consistenti, cioè vogliono usare sempre lo stesso nome per lo stesso comando, invocare i comandi sempre nello stesso modo, usare acceleratori con lo stesso significato, ...
    • Non usare sinomini
    • Non usare ambiguità linguistico/grafiche
      Ad esempio, le icone, le posizioni dei pulsanti, le loro etichette devono essere sempre le stesse. Anche l'uso dei font e dei colori deve essere consistente.
      Il colore non dovrebbe essere usato come mezzo principale per segnalare un messaggio ma come mezzo per sottolineare il messaggio stesso perchè alcuni utenti non riescono a distinguere facilmente certi colori (ad esempio i daltonici)
    • È altrettanto importante essere inconsistenti per rappresentare oggetti e azioni che sono diversi tra loro: bisogna poter facilmente distinguere oggetti che si comportano in modo diverso.

  5. Fornire feedback
    Bisogna sempre fornire un feedback all'utente, soprattutto quando le risposte dal sistema richiedono del tempo. Nell'ambito della ricerca su Human Computer Interaction (studi su Human Factors) si possono classificare i tempi di risposta come segue

    0.1 sec azione percepita come istantanea
    1 sec ritardo, ma l'attenzione rimane focalizzata
    10 sec perdita di attenzione da parte dell'utente
    più di 10 sec panico!

    Se si segnala il progresso dell'operazione (mediante cursori - clessidra/orologio - o una progress bar) l'utente può fare qualcosa di diverso.
    Ovviamente, si deve conoscere il tempo necessario ad eseguire un'operazione e nel caso di collegamento a siti internet non sempre è possibile stimare questo tempo. Nell'articolo di Jakob Nielsen Guidelines for multimedia on the Web si parla di una tolleranza di 15 sec. di attesa perchè gli utenti di Internet sono sono stati abituati a soffrire!


  6. Fornire uscite chiare
    L'utente deve poter uscire da qualunque situazione.
    • Nei dialoghi si introducono i pulsanti Cancel, Reset
    • Si deve prevedere l'uscita immediata dall'applicazione mediante il pulsante di Exit
    • Si deve anche prevedere un meccanismo di Undo. Si tratta di un meccanismo complicato da realizzare ma è molto utile perchè l'utente, grazie all'uso di azioni reversibili, è in grado di imparare dai propri errori mediante la sperimentazione.
      Se non è possibile avere un meccanismo di Undo, si deve prevedere un dialogo con domande del tipo Sei sicuro di voler cancellare questo file?, Sei sicuro di voler interrompere la computazione?, almeno per le azioni più critiche.

    A proposito dell'uso dei pulsanti di Cancel, Reset, ecc. sulle interfacce per il web si veda l'articolo di Jakob Nielsen del 16 aprile 2000.

  7. Fornire scorciatoie
    • Prevedere acceleratori per velocizzare l'interazione (ad esempio Ctrl-X, Ctrl-S per Windows; Alt-X, Alt-S per Unix).
      Gli acceleratori devono mantenere sempre lo stesso significato per non violare il principio sulla consistenza.
    • Doppio clic del mouse per selezionare le azioni di default.
    • Meccanismo di history per l'accesso diretto ad un'azione già eseguita nella sessione corrente (un esempio è il menu Go del Navigator).

  8. Gestire gli errori
    Gli errori si dividono il slip (errori di distrazione, caratteristici di utenti esperti) e mistake (azioni errate caratteristiche di utenti inesperti).

    Esempi di slip
    1. Errori di cattura: un'azione frequente "cattura" l'azione corrente perchè diventa un automatismo. Bisogna differenziare il più possibile le azioni.
      In Unix, quando si scrive un file di testo con l'editor vi è possibile salvare il documento usando il comando :w, oppure salvare e uscire dal documento con il comando :wq. Anche gli utenti esperti scambiano spesso questi due comandi a causa della loro similarità.

    2. Errori di descrizione: eseguire l'azione corretta sull'oggetto sbagliato.
      Ad esempio, nel caso di copia di un file, spostare un file sull'icona del cestino anzichè sull'icona della directory di destinazione.

    3. Errori di modalità: eseguire l'azione corretta ma nella modalità sbagliata.
      Ad esempio, eseguire l'azione di paste senza aver fatto l'azione di copy. Bisogna cercare di ridurre le modalità e renderle facilmente visibili.

    Si possono prevenire alcuni errori, per esempio
    1. disattivando alcune funzionalità (si osservino per esempio i pulsanti nelle barre dei tool e le voci dei menu: sono in grigio più chiaro quando i comandi associati sono disabilitati).
    2. validando i valori in input medianti controlli di consistenza (controlli immediati non appena si immettono valori di input).

    Se gli errori non possono essere evitati, bisogna comunque fornire dei messaggi all'utente, evitando di dare delle informazioni non utili per la soluzione del problema: i messaggi devono indicare il problema e suggerire una possibile soluzione in modo costruttivo.
    1. Un esempio messaggio errato è:   "errore 27, consultare il manuale"
    2. Un esempio messaggio corretto è:   "non riesco ad aprire il documento XXXX perchè questo formato non è tra quelli riconosciuti"


  9. Curare la manualistica e fornire meccanismi di help
    Solitamente gli utenti non leggono i manuali perchè li trovano incomprensibili. Inoltre, molto spesso i manuali non sono aggiornati. Per problemi di costi, i manuali cartacei non si producono quasi più. Per quanto riguarda quelli in linea, tipicamente sono organizzati in modo ipertestuale. Si possono anche prevedere dei tutorial, cioè delle guide abbastanza brevi per permettere ad un utente inesperto di iniziare a lavorare con il sistema.
    Altri meccanismi di aiuto per l'utente sono i tooltip, cioè quelle scritte che compaiono quando si posiziona il mouse su un'icona, i tip of the day, cioè le finestre con i suggerimenti sull'uso del sistema che di solito compaiono quando si fa partire il sistema stesso, gli assistenti che monitorano l'attività dell'utente dandogli suggerimenti (sono piuttosto fastidiosi).

  10. Fornire possibilità di personalizzazione
    È una caratteristica delle interfacce moderne e permette all'utente di creare un ambiente di lavoro personalizzato secondo i propri gusti (scelta dei colori, tipo di caratteri, posizione delle icone). In questo caso si parla di adattabilità facendo riferimento alle capacità dell'utente di modificare l'interfaccia (solo a livello superficiale). Nel caso di modifica dell'interfaccia da parte del sistema in risposta al comportamento dell'utente si parla di adattività. Nel primo caso l'utente ha un ruolo attivo, nel secondo caso ha un ruolo passivo: il sistema "osserva" il suo comportamento e modifica di conseguenza l'interfaccia.




Articoli
I principi generali precedenti sono stati proposti prima dell'avvento del World Wide Web. Alcuni sono ancora validi, altri devono essere riadattati, nuovi principi devono essere introdotti per rendere questo potente mezzo di comunicazione davvero facile da usare e per risolvere i piccoli/grandi problemi dovuti ai diversi browser che permettono di accedere alle informazioni. In rete si trovano moltissimi consigli. Sulla base degli articoli seguenti provate a definire il vostro elenco di linee guida perchè l'interfaccia del vostro progetto, oltre a funzionare correttamente, sia anche facile da usare.

Dal sito di Jakob Nielsen ...
  The Department | Research | Education | People | Contacts