Nei pattern architetturali come MVC, la user interface è implementata in un unico package che ha quindi due responsabilità fondamentali:
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.
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.
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]}
...
Sono molto usabili in quanto permettono ad un utente di “scoprire” facilmente tutte le opzioni.
Alcune convenzioni sono usualmente seguite:
Librerie sono disponibili in molti i linguaggi per realizzare menu che seguono queste convenzioni.
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.
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.
I form rappresentano uno dei metodi per la realizzazione dell’input/output nelle interfacce grafiche.
Elementi presenti nei form:
Talvolta si consente all’utente di esprimersi direttamente in linguaggio naturale
Un linguaggio naturale “ristretto” è un query language
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?
Gli eventi asincroni che possono scatenare una transizione possono essere:
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.
Nella modellazione a stati
Nella modellazione a classi
1. Introduzione
4. Casi d'uso
6. Class Diagram – parte prima
7. Class diagram – parte seconda
8. Class diagram – parte terza
9. Modellazione architetturale
10. Sequence Diagram
14. Progettazione Architetturale
15. Design Patterns – Parte prima
16. Design Patterns – Parte seconda
17. Progettazione dell'interfaccia utente
Ian Sommerville, Ingegneria del Software, capitolo 16.
T. Catarci, Slide del corso di Human Computer Interaction, Università La Sapienza, Roma