PROGETTAZIONE DI INTERFACCE UTENTE

[Estratto dal capitolo 5 del libro di Shneiderman]

Fase di progettazione

E' sensato stendere un progetto completo dell'interfaccia prima di iniziare ad implementarla, anche se e' certo che durante l'implementazione si dovra' cambiare qualcosa.

Elementi chiave

Stato interno

Quali informazioni descrivono lo stato corrente:

• variabili dell'applicazione (es. in un word processor, se sto scrivendo in grassetto o in corsivo, con che font e dimensione di carattere...)
• variabili aggiuntive dell'interfaccia (es. se al momento e' visualizzato il righello oppure no, con che fattore ingrandimento sto mostrando il testo...)

Che valore hanno queste variabili all'inizio.

Operazioni

Quali operazioni l'utente deve poter compiere attraverso l'interfaccia:

• operazioni dell'applicazione sottostante (es. cambiare font...), bisogna individuare la funzione applicativa che va chiamata (o la sequenza di chiamate a funzioni applicative)
• operazioni sull'interfaccia stessa (es. mostrare o nascondere il righello...)

Di che parametri hanno bisogno queste operazioni.

Pensare in che modo l'utente invochera' queste operazioni tramite l'interfaccia (tramite bottone, menu'...) e in che modo immettera' i parametri. Questo determina quali dispositivi dovranno essere presenti nell'interfaccia.

L'esecuzione di queste operazioni come modifica lo stato dell'applicazione? e lo stato dell'interfaccia?

Errori

Le operazioni hanno sempre senso o ci sono stati in cui certe operazioni non hanno senso?

Ci sono vincoli sui parametri?

Pensare quali controlli sono necessari su operazioni invocate e parametri immessi.

Considerare se opportuno disabilitare i dispositivi corrispondenti a certe operazioni quando nello stato attuale non sono sensate.

Considerare quando e' necessario mostrare messaggi di errore o avvertimento e in che modo.

Quali azioni di ricovero bisogna prevedere? (es. in quali casi offrire possibilita' di tornare indietro con "undo")

Layout dell'interfaccia

Stabilito quali dispositivi servono nell'interfaccia, decidere come organizzarli sullo schermo.

Decidere quali finestre comporranno l'interfaccia, che cosa conterra' ciascuna finestra e come sara' collocato nello spazio della finestra.
Strutturare lo spazio della finestra modularmente secondo una gerarchia di zone e sotto-zone, fino ai singoli dispositivi.

Attivita'

Individuare un insieme di attivita' applicative di interesse, chiamate anche task.

Ogni attivita' per essere portata a termine richiede una serie di operazioni (azioni dell'utente, che provocano reazione dell'interfaccia / applicazione).

La complessita' della serie di operazioni necessaria a compiere un'attivita' e' un indicatore per valutare l'interfaccia relativamente ai fattori umani (facilita' di apprendimento, comodita' d'uso, incidenza di errori).

Bisogna che le attivita' scelte per valutare l'interfaccia siano significative!

Strumenti per descrivere il progetto

Sono stati elaborati vari formalismi, per lo piu' grafici, per descrivere un'interfaccia progettata.

Screen layout

Schizzi di come appaiono le finestre dell'interfaccia, quali dispositivi contengono e come dislocati.
Utili a fornire descrizione statica dell'apparenza dell'interfaccia.

Uno schizzo per ogni finestra (finestra principale, finestre di dialogo...). Gli elementi di interfaccia non permanentemente visibili (es. menu') sono descritti a parte.

Indicare anche, per ogni elemento attivo di interfaccia, l'operazione o la serie di operazioni compiute nella sua callback.

Alberi di menu'

Descrivono la struttura di menu' a cascata (menu' e sotto-menu').

Analoghi gli alberi per finestre di dialogo a cascata. In pratica descrivono la relazione di dipendenza funzionale tra finestre.

Diagrammi di transizione di stato

Rappresentazione a grafo dove:

• nodi rappresentano gli stati del sistema
• archi orientati rappresentano le possibili transizioni di stato

Un'altra variante etichetta gli archi con la frequenza (in percentuale) con cui l'utente compie quell'azione.

Esiste anche versione modulare dei diagrammi di transizione di stato (statecharts).

Un grafo ad alto livello considera uno stato semplificato, dove non si tiene conto di certe variabili.

Un nodo del grafo ad alto livello si puo' espandere in un sottografo che fornisce descrizione piu' dettagliata dello stato, tenendo conto anche delle variabili che non erano state considerate al livello piu' alto.

Notazione ad azioni dell'utente (UAN = user action notation)

Adatto a descrivere il comportamento di interfacce che usano manipolazione diretta.

Descrive le attivita' (task) in termini di sequenza di azioni dell'utente e relativo feedback fornito dall'applicazione.

Per ogni task si compila una tabella a tre colonne (azione dell'utente, feedback dell'interfaccia, cambiamento di stato del sistema). Nella tabella si elencano le azioni (con relative reazioni e cambiamenti di stato) che compongono il task, in ordine di tempo.

Per esprimere le azioni e i feedback sono stati proposti linguaggi formali. Noi qui usiamo linguaggio naturale (piu' facile da capire e da ricordare, anche se meno veloce da scrivere).

Importante pero' che il linguaggio usato sia non ambiguo e preciso.
Specificare bene in che cosa consiste l'azione compiuta dall'utente / il feedback reso dall'interfaccia e quali sono gli oggetti sui quali l'azione / il feedback vengono applicati.

Esempi di oggetti sui quali si compie l'azione o il feedback:

• icone
• posizioni all'interno di un'area (coppie di coordinate x,y)
• elementi di un disegno (punti, triangoli...)

Esempi di azioni dell'utente: muovere puntatore su un oggetto, premere / rilasciare tasto del mouse...

Esempi di feedback: evidenziare un oggetto, spostarlo, cancellarlo...

Esempio: task per cancellare un file F tramite manipolazione diretta.

Descriviamo un'interfaccia per un'applicazione "calcolatrice" con le operazioni binarie di addizione, sottrazione, moltiplicazione, divisione.

Dispositivi e Layout

Una sola finestra. In alto un campo di testo (non editabile) che mostra il valore corrente.
In basso, sistemati secondo uno schema a griglia 4 x 4:

• 10 bottoni per le cifre
• 4 bottoni per le operazioni binarie di addizione, sottrazione, moltiplicazione, divisione (simboli + - * /)
• 1 bottone per l'esecuzione dell'operazione impostata (simbolo =)
• 1 bottone per l'azzeramento del valore corrente (simbolo C)

Dagli schizzi del layout poi si ricavera' la gerarchia di contenitori necessaria per realizzare le finestre l'interfaccia.

Stato interno

Variabili dell'applicazione:

• a1 = primo operando, che e' anche il risultato dell'ultima operazione (se per ultima cosa e' stata fatta un'operazione), puo' non esistere
• a2 = secondo operando, puo' non esistere
• op = operazione impostata (una tra le quattro), puo' non esistere

Variabili dell'interfaccia:

• vv = il numero visualizzato, che e' il secondo operando se esiste, altrimenti il primo se esiste, altrimenti niente

Stato iniziale: Non esitono ne' i due operandi ne' l'operazione. Non visualizza nulla.

Stati possibili

Dai vincoli imposti sono possibili solo 4 stati:

• s0: non ho nulla
• s1: ho solo il primo operando a1 che e' anche visualizzato in vv
• s2: ho il primo operando a1 che e' anche visualizzato in vv e l'operatore op
• s3: ho il primo operando a1, e l'operatore op e il secondo operando a2 che e' anche visualizzato in vv

Attivita' (task) e azioni

Task "operazione isolata": l'utente immette il primo operando, poi l'operazione, il secondo operando ed infine il comando di esecuzione.

Task "operazioni successive": essendo gia' presente il primo operando (dato dal risultato dell'operazione precedente), l'utente immette solo l'operazione e il secondo operando, e cosi' via...

Task "azzeramento": in qualsiasi momento l'utente puo' cancellare tutto e tornare allo stato iniziale, come se non avesse ancora eseguito nessuna operazione.

Se consideriamo la calcolatrice nella sua realizzazione "tradizionale" (10 bottoni per le 10 cifre e gli operandi immessi cifra per cifra), abbiamo le seguenti azioni dell'utente:
immettere una cifra (0..9), immettere un'operatore (+-*/), immettere comando di azzeramento (C), immettere comando di esecuzione (=).

A un piu' alto livello di astrazione, possiamo considerare l'immissione di un numero come un'azione unica (anche se di fatto realizzata con una sequenza di azioni): l'immissione di un numero e' un sotto-task.

Il sotto-task per immissione di un numero inizia quando l'utente preme la prima cifra, continua finche' l'utente preme cifre, termina quando l'utente preme un bottone diverso da una cifra.

Azioni e transizioni di stato

Descriviamo le transizioni di stato in modo modulare:

• un diagramma a livello superiore di astrazione che non dettaglia il task per l'immissione del numero
• un diagramma a livello superiore di astrazione inferiore che descrive il task per l'immissione del numero

Diagramma di transizione a livello superiore:

Per non appesantire la notazione, le frecce dell'azione di azzeramento (che da ogni stato portano in s0) sono state omesse.

Diagramma di transizione a livello inferiore che descrive l'immissione di un numero cifra per cifra. Di fatto dettaglia il funzionamento interno degli stati s1 ed s3. Facciamo un solo diagramma "parametrico" sullo stato di riferimento:

s e' uno stato fra s1 ed s3, a e' il numero che sto costruendo (a1 se sono in s1 e a2 se sono in s3).

Gestione degli errori

In ogni stato le azioni corrispondenti a transizioni non previste (es. immettere l'operazione negli stati s0 e s2) sono impedite all'utente disabilitando i relativi bottoni.

Sugli archi del grafo posso annotare anche le abilitazioni / disabilitazioni eseguite.

Quanto scritto sugli archi del grafo confluira' poi nel corpo delle callback per i vari dispositivi.

Esempio: la callback di un bottone operazione prima determina in che stato siamo (sono possibili solo s1 ed s3 in quanto negli altri stati il bottone e' disabilitato). Poi secondo il caso esegue quanto riportato sull'arco s1 --> s2 o s3 --> s2.

Nota

Ovviamente in un progetto piu' grosso non si dovra' scendere a questo livello di dettaglio nella descrizione.