A seconda del tipo di problema possiamo impostare diverse interfacce utente.

I paradigmi più seguiti sono gli interpreti di righe di comando, i menù a tutto schermo, i menù pull-down, i menù stile Lotus e le combinazioni di tasti funzione e tasti control.

Se i comandi che devono essere svolti sono molti, con molte possibili varianti e parametri, l’interfaccia più usata è quella dell’interprete di command-line. In questo modo, in pratica con un piccolo linguaggio specializzato, è possibile gestire migliaia di funzioni, anche se il tempo necessario a padroneggiare il sistema è molto lungo.

All’estremo opposto troviamo i menù a tutto schermo, che permettono di accedere al massimo a una decina di opzioni senza alcun parametro. Questo schema è così semplice da essere normalmente utilizzato in sistemi che devono essere utilizzati anche senza alcuna guida da chiunque, come per esempio uno sportello Bancomat. Naturalmente il prezzo che si paga è di poter rendere disponibili solo pochissime opzioni.

I pro e contro di questi vari stili sono riassunti nello specchietto.

L’IBM ha stabilito delle linee guida per l’interfaccia utente, la Common User Access, che entra nell’architettura più generale della SAA.

Queste linee stabiliscono dei criteri comuni di interfaccia che devono avere tutti i programmi che vogliono essere considerati conformi alla System Application Architecture.

Lo scopo è di fornire agli utenti una interfaccia comune e consistente per tutti i programmi, in modo tale che i tempi di apprendimento di ogni pacchetto siano limitati. L’ideale sarebbe una conformità tale che ogni nuovo programma sia praticamente già usabile anche da chi non lo ha mai visto.

Più che entrare nei dettagli delle regole CUA, vediamo delle linee guida che portano a programmi di semplice utilizzo.

Gli obiettivi principali della CUA sono due: far si che gli utenti siano sicuri del risultato delle loro azioni e far loro controllare il flusso degli eventi.

Per far si che l’utente sia sicuro di ciò che ha fatto bisogna che l’applicazione risponda ad ogni azione in modo consistente e affidabile.

Per fare questo conviene:

Usare metafore: cercare delle attività che assomiglino a quelle svolte dall’applicazione e dare lo stesso tipo di modello. Per esempio "buttare nel cestino" per cancellare un file.

Essere consistenti: cioè far si che l’applicazione si comporti in modo simile per operazioni simili. Se bisogna scegliere da una serie di comandi, farlo o sempre con un menù o sempre con una serie di icone, non interscambiando i modi a seconda del momento. Per esempio, se la scelta di un file in una directory deve essere fatta in più punti di un programma, bisogna farlo sempre allo stesso modo, o sempre con pick-list o sempre con l’input controllato di una stringa.

Evitare le modalità: i programmi possono entrare in modalità particolari (si pensi ad un programma di videoscrittura: insert o overwrite). Conviene sempre evitare le modalità per operazioni più complesse, o quantomeno segnalare con un cambiamento del cursore che si è entrati in una serie di operazioni particolari.

Per far si che l’utente possa sempre controllare la sequenza delle operazioni i suggerimenti sono:

Visualizzare la lista delle opzioni: quando bisogna scegliere tra una serie di possibilità conviene creare delle liste visuali, o con pick-list o con una serie di icone, in modo che l’utente abbia sottomano tutte le possibilità che vengono offerte da sistema.

Dare dei segnali di risposta: se l’utente riceve costantemente un feedback dal programma ad ogni azione che viene intrapresa, sia con messaggi video o sonori, prende confidenza anche con operazioni complesse costruendole passo passo con i vari comandi di cui si compongono. Lanciare una lunga serie di opzioni o menù senza capire cosa sta succedendo o se almeno tutto va bene, scoraggia anche gli utenti più curiosi.

Incoraggiare l’esplorazione: evitare la sindrome da foglietto giallo applicato al terminale. I programmi devono essere abbastanza semplici da invitare chiunque a percorrere le strade "nuove", a scoprire le funzionalità mai usate prima. Questa spesso è una via per ridurre i costi dell’addestramento! Bisogna a questo fine includere sempre una opzione di Undo per permettere di tornare ad un punto noto senza causare particolari danni.

Le applicazioni che permettono all’utente di passeggiare qua e la devono essere particolarmente robuste, non devono cioè mai distruggere i dati su cui l’utente sta lavorando o uscire al sistema senza preavviso.