Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Porfirio Tramontana » 17.Progettazione dell'interfaccia utente


Separazione tra UI e sistema

Nei pattern architetturali come MVC, la user interface è implementata in un unico package che ha quindi due responsabilità fondamentali:

  1. Mostrare le informazioni agli utenti
    • agire come interfaccia tra utente e sistema.
  2. Inoltrare le informazioni in input e avviare le elaborazioni
    • agire come interfaccia tra User Interface e interno del sistema (package model e controllare nel caso di MVC).

Fattori umani

Le persone hanno memoria a breve termine limitata;
Studi psicologici hanno valutato che le persone ricordano istantaneamente fino a 7 informazioni per volta. Se ne vengono presentate di più, aumenterà la possibilità di generare confusione nell’utente.

Le persone possono sbagliare;
Allorchè l’utente commetta un errore, se il sistema risponde con messaggi e allarmi inappropriati (o troppo generici), lo stress dell’utente aumenterà e potrebbe portarlo ad abbandonare l’utilizzo di quel software.

Le persone sono diverse tra loro;
Le persone differiscono notevolmente tra loro per abilità fisiche e attitudini. I progettisti dovrebbero tenerne conto producendo interfacce che medino tra le preferenze, oppure progettando sistemi con interfacce differenziate.

Principi di progettazione

User familiarity
L’interfaccia deve utilizzare termini e concetti che siano familiari agli utenti, piuttosto che ai programmatori.
Consistency
Comandi e menu devono avere lo stesso formato nelle varie parti dell’interfaccia, devono essere seguite le stesse convenzioni, etc.
Minimal surprise
Gli utenti dovrebbero poter essere in grado di predirre il funzionamento dei comandi riconoscendo la somiglianza con comandi che già conoscono.
Recoverability
Il sistema deve essere in grado di ripristinarsi facilmente in seguito ad un errore dell’utente. Ad esempio, il comando ‘undo’ facilita questo compito.
User guidance
Aiuti, guide in linea, suggerimenti devono aiutare l’utente nell’utilizzo migliore dell’interfaccia.
User diversity
L’interfaccia deve potersi presentare in maniera differenziata rispetto alle esigenze e alle preferenze dei diversi utenti.

Interfaccia a linea di comando

Rappresenta una modalità di comunicazione diretta ed immediata con il sistema.
È particolarmente utile per realizzare pipelines di processi.
Permette di accedere più velocemente alle funzionalità di sistema.

Dovrebbe essere sempre garantita.

Esempio: in ogni programma C++ dovrebbe essere presente un main del tipo:

int main(int argc, char *argv[]) {
If (argc==1) {//Avvia interfaccia grafica}
Else if (argc==2) {//Modalità di esecuzione con un solo parametro argv[1]}
Else if (argc==3) {//Modalità con due parametri argv[1], argv[2]}
...

Interfacce a Menu

Sono molto usabili in quanto permettono ad un utente di “scoprire” facilmente tutte le opzioni.
Alcune convenzioni sono usualmente seguite:

  • C’è un tasto (Alt nei PC Windows) per accedere da tastiera al menu;
  • È possibile che non tutte le opzioni siano tutte visibili, ma il menu si allarga andando con il mouse o con le frecce verso l’ultima opzione visibile;
  • Le opzioni che terminano con I puntini sospensivi portano a delle ulteriori finestre di dialogo; quelle senza invece sono comandi diretti;
  • Le opzioni in grigio non sono temporaneamente attivabili;
  • La lettera sottolineate nel nome di un’opzione corrisponde al comando che viene avviato se si digita quella stessa lettera sulla tastiera;
  • I menu scompaiono automaticamente quando viene selezionato qualcos’altro.

Librerie sono disponibili in molti i linguaggi per realizzare menu che seguono queste convenzioni.

Tecniche di analisi dei requisiti dell’interfaccia

Task analysis
Modellare l’interfaccia in funzione dei passi necessari al completamento dei task.

Interviewing and questionnaires
Domandare agli utenti come vorrebbero fosse l’interfaccia.

Ethnography
Osservare gli utenti mentre lavorano.

Menu generali e menu contestuali

I menu generali rappresentano delle opzioni generali riguardanti l’intera finestra.
I menu contestuali raggruppano comandi relativi all’oggetto cui si riferiscono.

Vengono attivati di solito (ad esempio in Windows) cliccando col tasto destro su di un determinato oggetto).
Possono essere visti come metodi riferiti all’oggetto grafico cui si contestualizzano.

Form

I form rappresentano uno dei metodi per la realizzazione dell’input/output nelle interfacce grafiche.
Elementi presenti nei form:

  • Label
  • Command Button
  • Checkbox
  • Option (Radio buttons)
  • Combo Box
  • Textarea
  • List

Esempio di form


Ulteriori elementi di interfaccia

  • Toolbox
    • Raccolte di pulsanti rilocabili nell’interfaccia;
  • Finestre di dialogo
    • Consentono solo risposte testuali o con un solo pulsante da premere;
  • Palette

Esempio in HTML + Javascript


Linguaggio naturale

Talvolta si consente all’utente di esprimersi direttamente in linguaggio naturale

  • Massima familiarità;
  • Grosse difficoltà di interpretazione
    • Tipicamente vengono riconosciute solo frasi estremamente semplici e ben formate.

Un linguaggio naturale “ristretto” è un query language

  • Il sistema Query by example lascia limitati gradi di libertà;
  • SQL può essere considerato come un linguaggio naturale ristretto.

Modellare la GUI

La GUI (Graphical User Interface) si contrappone alla CUI (Character User Interface) nella quale la schermata è statica e caratterizzata dalla presenza di un prompt (cursore lampeggiante) che indica la posizione nella quale siano inseriti i dati.
Per quanto GUI e CUI siano molto diverse tra loro, è possibile realizzare CUI che si comportano esattamente come le GUI.

Problema:
Come modellare le interazioni di un utente con una interfaccia utente?

Statechart diagrams

  • Agli stati corrispondono schermate (window oppure form) statiche
    • Gli stati sono implicitamente considerati stabili.
  • Le transizioni sono attivate da eventi utente (o altri eventi di sistema) asincroni
    • Per ogni evento utente nel software viene definito un gestore dell’evento (event handler) che esegue delle azioni in conseguenza del verificarsi dell’evento.
  • Una interfaccia può, quindi, essere modellata come una macchina a stati finiti (Finite State Machine – FSM).

Altro esempio


Eventi

Gli eventi asincroni che possono scatenare una transizione possono essere:

  • Eventi utente
    • Onclick – onmouseover – onmouseout – ondblclick – onmouseup – onmousedown – onkeypress – etc.
  • Eventi Timer;
  • Eventi di sistema
    • Arrivo di messaggi dalla rete – eccezioni, etc.

C’è una analogia tra la gestione delle interruzioni in un processore e la gestione degli eventi in un’interfaccia utente.
Alle Interrupt Service Routine (ISR) corrispondono gli event handlers.

Modellazione con Class Diagram

  • Ogni classe rappresenta un form;
  • Ogni evento rappresenta un metodo del form;
  • Ogni dato in input/output è un attributo del form;
  • Una window è vista come un’aggregazione di form
    • Anche una window può avere i suoi eventi e dati.
  • Questa modellazione fu proposta anche da Jim Conallen per modellare applicazioni web basate su linguaggi di scripting
    • Si tratta di applicazioni web nel quale il codice è organizzato per pagine web;
    • Applicazioni scritte in PHP o ASP seguono solitamente questo paradigma architetturale.

Esempio


Problemi

Nella modellazione a stati

  • Si è assunto finora che l’interfaccia utente fosse staticamente definita (stati stabili);
    • Come si può modellare un’interfaccia che, anzichè prevedere schermate fisse, prevede un’unica schermata che si automodifica in seguito ad eventi?

Nella modellazione a classi

  • Le pagine client generate da una pagina server sono viste come istanze di una generica classe “Pagina Client Costruita”;
  • Esse, però, possono contenere attributi e metodi diversi tra loro, per cui andrebbero considerate come specializzazioni anzichè come oggetti.

I materiali di supporto della lezione

Ian Sommerville, Ingegneria del Software, capitolo 16.

T. Catarci, Slide del corso di Human Computer Interaction, Università La Sapienza, Roma

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion