Sviluppo delle interfacce nelle applicazioni

Introduzione 2 
Teoria 
Per tracciare il modello, che consente di aiutare chi progetta le applicazioni nelle fasi 
d’ideazione dell’interfaccia, facciamo riferimento principalmente alla teoria cognitiva 
dell’azione elaborata da Donald Norman (Norman – 2000), che spiega lo schema di 
comportamento delle persone e che applichiamo all’interazione con i prodotti informatici. 
Egli, infatti, nota che l’uso di alcuni strumenti per eseguire dei compiti spesso è causa di 
impedimento e frustrazione perché eseguiamo delle operazioni che non corrispondono alle 
nostre intenzioni. Se per aprire un porta, ad esempio per entrare all’interno di un locale, è 
necessario tirare verso di sé una maniglia, può succedere che le persone invece tentino di 
spingere la maniglia. Commettiamo degli errori perché non ci è chiaro il funzionamento 
degli oggetti o non ci è possibile capire la funzione per cui sono stati progettati; questi errori 
nascono da un cattivo design, ossia da una cattiva progettazione del prodotto. Il fatto di non 
riuscire ad utilizzare uno strumento, ad esempio un videoregistratore, si può spiegare quindi 
in termini di cattiva progettazione e non in termini d’inadeguatezza dell’utilizzatore. 
Questa teoria descrive l’azione umana durante l’esecuzione di determinati compiti (task). 
Per utilizzare uno strumento le persone pianificano le proprie azioni e per ogni scopo che 
l’utente vuole raggiungere esistono due momenti principali: la fase di esecuzione e quella di 
valutazione. Nel primo caso per raggiungere un determinato scopo, ad esempio spegnere la 
luce in una stanza, gli individui elaborano degli enunciati, ad esempio alzarsi dalla sedia e 
raggiungere l’interruttore, per trasformarli in azioni ed eseguirle. Dopo aver eseguito le 
azioni, percepiscono, nella fase della valutazione, il risultato delle proprie azioni, le 
interpretano, e verificano che il risultato soddisfi i propri scopi iniziali. 
Norman inoltre parla di golfi dell’esecuzione e della valutazione: per questi due momenti 
dell’agire umano gli errori più frequenti sono dovuti al fatto che nel primo caso gli scopi 
non hanno una corrispondenza con le possibili azioni, cioè non esiste o è mal rappresentato 
Introduzione 3 
il comando che consente di realizzare gli obiettivi (golfo dell’esecuzione); ad esempio non 
è possibile premere un interruttore per spegnere la luce e quindi in questo caso l’utente non 
sa cosa può fare per raggiungere il proprio scopo. 
Analogamente, nell’altra fase, in seguito ad un’azione non viene mostrato che cosa è 
successo, così non viene segnalato il risultato che ho ottenuto; l’utente quindi non può 
verificare che l’azione che ha eseguito va nella direzione giusta per soddisfare le proprie 
esigenze (golfo della valutazione), come ad esempio nel caso in cui premendo l’interruttore 
l’azione risultante non fosse manifesta e la luce non fosse accesa. 
Per progettare correttamente un programma che consenta un’interazione efficace con una 
persona è necessario ridurre al minimo la distanza cognitiva fra ciò che voglio fare e ciò che 
si può effettivamente fare, e diminuire il divario fra ciò che penso che sia successo e ciò che 
effettivamente è successo. 
Questo modello ci aiuta, nella sua forma schematica, a capire come le persone agiscano per 
azioni ed interpretino le reazioni e ci consente di applicare questo modello alla 
progettazione di un’interfaccia. Riferendo questo schema dell’interazione umana alle fasi 
della progettazione di un’applicazione possiamo delineare i momenti della progettazione 
dell’interfaccia. 
Introduzione 4 
Progettazione 
Il punto centrale del problema è ciò che l’utente vuole fare e ciò che percepisce; la fase 
preliminare della progettazione dell’interfaccia analizzerà quindi le funzioni del programma 
scorporando i compiti, eventualmente dividendoli prima in sottocompiti, in azioni e 
reazioni. Ad esempio per un programma che consente di ascoltare la musica si definiscono 
gli obiettivi generici (task) che l’utente vuole raggiungere: ascoltare un brano, interrompere 
la riproduzione e così via. 
E’ necessario definire quali sono le azioni che aiutano l’utente a soddisfare gli scopi e 
rendere visibili, per ogni schermata dell’interfaccia, i possibili comandi per rendere minimo 
il golfo dell’esecuzione, cioè per permettere di capire con il minimo sforzo come 
raggiungere gli scopi prefissati. Nell’esempio del riproduttore audio il comando “Play” 
corrisponde all’intenzione “ascoltare un brano”. 
Dopo aver definito le azioni, si stabiliscono le reazioni dell’interfaccia, cioè si mostra che il 
comando è stato eseguito correttamente e si verifica che i risultati ottenuti soddisfino 
l’esigenza iniziale. In questa maniera si cerca quindi di rendere minimo il golfo della 
valutazione, cioè di rendere immediatamente visibile qual’è stato il risultato del comando: 
questo permette all’utente di valutare se effettivamente è stato eseguito un comando e se 
questo è indirizzato verso gli scopi iniziali. 
A questa fase iniziale segue la fase progettuale ricalcata dalle indicazioni di Piro (Piro - 
1997): viene infatti descritto il funzionamento dell’applicazione sotto un aspetto statico e 
uno dinamico. Il primo è lo storyboard che descrive ogni schermata che verrà mostrata 
durante l’esecuzione del programma priva di ogni contenuto informativo e, per ognuna di 
esse, vengono evidenziati i comandi che rappresentano le azioni possibili. Ogni schermata 
rappresenta il luogo dell’interazione con l’utente, l’interfaccia, e ad ogni comando 
corrisponde un’altra schermata che visualizza il risultato ottenuto. Nel caso del programma 
Introduzione 5 
di riproduzione audio ci sono due schermate ognuna delle quali contiene un comando; la 
prima rappresenta il comando che permette di riprodurre mentre la seconda il comando per 
interrompere l’esecuzione del brano. Ognuna di esse visualizza il risultato del comando 
dell’altra schermata in modo esclusivo. 
In seguito si traccia il comportamento dell’utente attraverso una mappa dell’interazione 
che permette di avere una visione globale dell’interazione uomo – macchina. Questo 
diagramma rappresenta graficamente le singole schermate, definite nello storyboard, e delle 
frecce che le collegano rappresentando i comandi dell’interfaccia. 
La fase successiva è la verifica che il progetto iniziale sia valido attraverso la realizzazione 
di un prototipo dell’applicazione che consente di valutare il grado di efficacia del prodotto 
informatico nel suo aspetto pratico; così facendo, infatti, viene effettuata una misura 
ergonomica dell’interazione attraverso il controllo con alcuni utenti della sua efficacia. Il 
tasso di errore nell’esecuzione di determinati compiti consente di capire quali sono i punti 
deboli dell’applicazione e, attraverso una verbalizzazione dell’esperienza, vengono 
evidenziati i golfi più ampi, cioè gli aspetti di esecuzione o valutazione che non rispondono 
alle esigenze iniziali dell’utente. 
Segue quindi una fase iterativa che consente di perfezionare il progetto iniziale per 
successive modificazioni. Nel caso la verifica dell’usabilità del software evidenzi per 
l’utilizzatore delle incongruenze, il progetto iniziale viene modificato e creato un ulteriore 
prototipo a cui segue una nuova verifica sul campo; questa fase viene quindi ripetuta fino a 
quando il prodotto soddisfa le caratteristiche di usabilità, cioè consente di eseguire dei 
comandi con efficacia e soddisfazione.  
Conclusa la fase progettuale si passa alla fase di implementazione del prodotto definivo, che 
non è argomento di discussione in questa tesi. 
Introduzione 6 
Applicazione 
Per controllare che questo schema di progettazione e di verifica di usabilità sia corretto, 
delineiamo le fasi di realizzazione dell’interfaccia di un’applicazione che richiede 
l’intervento dell’utente; il prodotto ARCO è un sistema di consulenza armonica per 
chitarristi di ausilio nella didattica.  
Il software in oggetto consente di realizzare due obiettivi principali: quello di fornire la 
diteggiatura, ossia le posizioni della mano, per suonare un accordo e di sperimentare un 
sistema che simula, attraverso un modello di sintesi sonora avanzato, l’esecuzione 
dell’accordo. In pratica si tratta di realizzare due compiti principali: rappresentare un 
accordo sulla tastiera e ascoltare la sua esecuzione. 
La progettazione dell’interfaccia del programma è indipendente dallo studio informatico già 
convalidato in alcuni studi precedenti che evidenziano alcune peculiarità di questo sistema 
modulare. Nel nostro caso l’aspetto principale è l’interazione con l’utente. 
Innanzitutto si nota che il progetto dell’applicazione non prevedeva, nella sua forma 
iniziale, l’interazione con l’utente ma implementava un’interfaccia che ne ricalcava 
l’utilizzo in fase di sviluppo. In pratica il programma poteva essere utilizzato solo dal 
progettista. Ciò rende quindi evidente la differenza fra il modo di immaginare il 
funzionamento del programma fra l’utilizzatore e chi ha progettato il prodotto. 
In seconda battuta vengono enunciati i compiti dell’utente suddivisi per scopi principali: 
per quanto riguarda lo studio della posizione delle dita sulla tastiera della chitarra, è 
possibile decidere la nota base dell’accordo da studiare (tonica), la denominazione 
dell’accordo (terze e quinte) e le eventuali ulteriori alterazioni (settime e none ed 
undicesime), l’eventuale posizione di partenza sul manico della chitarra preimpostata sulla 
prima. 
Introduzione 7 
Nel caso invece della riproduzione audio i comandi sono quelli relativi all’esecuzione: 
l’utente può iniziare la riproduzione e interromperla mentre i parametri che consentono di 
regolare il suono sono impostati con valori medi come la grandezza della corda o la forza da 
applicare su di esse nell’esecuzione. 
Ad ogni azione viene attribuito un comando e la reazione ne mostra il risultato secondo lo 
schema illustrato precedentemente. 
Alla progettazione segue la fase di verifica dell’usabilità del software: per accertarsi della 
semplicità di utilizzo Arco viene provato in maniera empirica da alcune persone cercando di 
capire quali siano i compiti difficili da eseguire; questo può essere fatto, ad esempio, 
contando il numero di errori, minore è il numero, maggiore risulta essere l’usabilità. Dopo 
aver eseguito il compito si ricercano gli eventuali impedimenti nell’uso del programma 
attraverso la verbalizzazione dell’esperienza. 
In definitiva nel processo di ideazione dell’interfaccia di un’applicazione è necessario 
rendere l’azione dell’utente il fulcro della progettazione. Attraverso una corretta 
pianificazione delle possibili azioni e di ciò che ne risulta, i programmi possono diventare 
un strumento utile anziché ostico. E’ necessario far capire all’utente ciò che è possibile 
fare e ciò che è stato fatto.