Gli authoring tools nel progetto FairsNet

Introduzione 
 2 
1992]. Questa collaborazione aiuta a rendere un sistema usabile poiché 
permette di progettare l’architettura del sistema in fase di sviluppo, 
eliminando, nel più breve tempo possibile, i difetti riscontrati. 
Il secondo è la scelta di utilizzare metodi informali per valutare i prototipi 
sviluppati precedentemente dal team di progetto. 
L’ultimo fattore di richiamo è la presenza di Tassonomie nel progetto, usate 
per facilitare la creazione di schemi comuni di classificazione, per organizzare 
e classificare gli oggetti, ad esempio informazioni, da differenti modelli di 
dominio (i profili degli utenti, i menù etc.) [Nie, 2002]. 
Nel mio lavoro ho interagito con i progettisti sia per sviluppare le interfacce 
utente degli Authoring Tool sia per verificare che tali interfacce siano usabili, 
visto che dovranno essere adoperate autonomamente dall’organizzatore di 
fiere. La tesi ha la seguente organizzazione: 
Introduzione 
 3 
Nel primo capitolo è descritta la metodologia user-centered nella comunità 
della HCI
1
; metodi, strumenti e tecniche per attuare una valutazione di 
usabilità dei sistemi software ed in particolare la metodologia “user- centered” 
e le tecniche proposte dal “Discount Usability Engineering”. 
Nel secondo capitolo sono presentate le motivazioni della scelta di un 
metodo informale per valutare i prototipi del sistema FairsNet. Dopo aver 
confrontato le diverse possibilità, infatti, si è visto che la valutazione euristica 
permette di studiare l’efficienza e l’efficacia del sistema velocemente e con un 
risparmio economico notevole [Nie, 1994]. 
Il capitolo terzo presenta una panoramica generale degli strumenti e dei 
linguaggi di programmazione usati per sviluppare i prototipi e i mock-up del 
progetto FairsNet. 
Il quarto capitolo descrive i risultati delle ispezioni di usabilità. Sono stati 
valutati il mock – up di Form Manger e i prototipi di Taxonomy Manager e 
Classification Manager.  
  
                                                 
1
 Human Computer Interaction 
Capitolo 1:                                                                            Progettazione user-centered 
 4 
Capitolo 1: 
Progettazione user-centered 
Introduzione 
 
In questo capitolo, sono presentate la metodologia “User-Centered”, che è 
stata adottata per lo sviluppo e l’implementazione del sistema FairsNet, e le 
tecniche del Discount Usability Engineering, proposte da Nielsen [Nie, 1993], 
come un semplice metodo per valutare le interfacce utente. 
Tradizionalmente le informazioni per pubblicizzare una fiera si basavano su 
volantini, mappe, etc.; con l’avvento di internet alcuni siti hanno iniziato a 
fornire informazioni, sia su eventi fieristici che sulle compagnie partecipanti ad 
essi. Questi dati, però, non erano organizzati in un modo omogeneo e 
comprensivo. 
FairsNet ha come obiettivo l’offerta di servizi innovativi on-line per 
supportare il business process delle fiere ed aiutare a gestire, in maniera più 
efficiente, un gran numero di espositori. 
Diversi sono i vantaggi di una fiera virtuale: la sua vita non è, per esempio, 
limitata nel tempo come per le fiere reali; il numero degli esibitori può essere 
illimitato e l’utente può visionare la fiera ovunque si trovi. 
La metodologia “User-Centered” mette in relazione i progettisti, che 
conoscono le tecnologie, con gli utenti, che comprendono il dominio 
applicativo, dall’inizio della pianificazione del progetto; questa collaborazione 
Capitolo 1:                                                                            Progettazione user-centered 
 5 
permette di individuare esattamente i compiti dell’utente ed i suoi obiettivi e di 
prevenire molti errori nel sistema finale. 
L’usabilità, per Nielsen, non è una proprietà unidimensionale del sistema, 
ma un insieme di più componenti; essi nella loro globalità permettono di avere 
un sistema efficiente, efficace e soddisfacente. 
 
1.1. Metodologia User-Centered 
 
I progettisti devono offrire agli utenti la possibilità di appuntare l’attenzione 
su propri compiti e non sul modo di usare gli strumenti per attuarli. Loro 
necessitano di metodologie e di tecniche per ottenere un sistema software 
usabile. 
La metodologia “User-Centered è già risultata un fattore chiave per produrre 
interfacce soddisfacenti [Rub,1994] [Pre,1994]. Essa richiede che l’utente finale 
sia coinvolto dall’inizio della fase di progetto; tale coinvolgimento ha come 
obiettivo la prevenzione di molti errori, inevitabili nella progettazione di sistemi 
innovativi, poiché il progettista dovrà pensare in termini di utilità e usabilità del 
sistema che si accinge a sviluppare. I benefici dell’approccio “User-Centered” 
riguardano principalmente le complesse funzionalità del sistema, difficili da 
ottenere, tra queste la soddisfazione dell’utente. Se si coinvolgono gli utenti 
dall’inizio è possibile conoscere che cosa essi effettivamente vogliano in un 
sistema. Specifiche povere e inadeguate possono determinare un’interazione 
difficile, e generare problemi di usabilità. 
I principi base della metodologia “User-Centered” sono: 
Capitolo 1:                                                                            Progettazione user-centered 
 6 
1) analisi dell’utente e dei suoi compiti; 
2) progettazione ed implementazione del sistema attraverso prototipi di 
complessità crescente; 
3) valutazione delle scelte e dei prototipi con gli utenti. L’approccio 
“User-Centered” richiede di capire realmente chi userà il sistema, 
dove, come e per quale scopo. 
Il sistema, poi, è sviluppato iterativamente attraverso un ciclo di 
progettazione-implementazione-valutazione; in questo modo è possibile 
eliminare seri errori e risparmiare tempo nella re-implementazione poiché, sin 
dal primo progetto, ci si basa su una conoscenza empirica dell’utente e delle 
sue necessità e aspettative. 
Il processo di produzione del Software è un modo per definire lo sviluppo 
che permette di costruire, arricchire e far evolvere un prodotto software 
[Ghe,1993]. Questo processo è generalmente chiamato ciclo di vita del 
software. Diversi modelli di cicli di vita del software sono stati proposti.  
Prendiamo per esempio il tradizionale modello a cascata, in cui ciascuna 
attività chiama la successiva: le specifiche sono raccolte all’inizio, poi, queste 
informazioni sono “processate” e convertite in un disegno generale il quale, nel 
passo successivo, viene scomposto in modelli dettagliati che saranno 
implementati, integrati e testati. Le attività del classico modello a cascata sono i 
blocchi bianchi in Fig. 1.1 
Capitolo 1:                                                                            Progettazione user-centered 
 7 
 
Analisi dei 
requisiti 
Progettazione 
Architetturale 
3 Prototipo & 
Test 
Progettazione 
Dettagliata 
3 Prototipo & 
Test 
Codifica  
& Test 
Integrazione 
& Test 
Revisione 
&  
Manutenzione 
1 Analisi 
dell’Utente 
2 Scenario & 
Interfacce utente 
 
Fig. 1.1. Il ciclo di vita a cascata rivisitato.  
 
 
Capitolo 1:                                                                            Progettazione user-centered 
 8 
In questo ciclo, che è incentrato sull’utente, l’usabilità non è presente. Esso 
presenta, poi, alcuni problemi; per esempio, il sistema è testato solo alla fine 
del ciclo, quando sfortunatamente è troppo tardi per recuperare le discrepanze 
con i requisiti dell’utente. Un altro problema riguarda la raccolta dei requisiti; 
essi sono discussi con i committenti che spesso non sono coloro che 
utilizzeranno il sistema. I committenti sono coloro che negoziano con i 
progettisti le caratteristiche del futuro sistema, mentre gli utenti o utenti finali 
sono coloro che realmente useranno il sistema progettato [Cos, 2001]. 
Una diretta conseguenza della natura restrittiva della raccolta dei requisiti 
dell’utente e del sottoporre a “Test” il sistema solo alla fine dello sviluppo, è la 
produzione di un software incompleto e quindi non usabile. 
Di conseguenza per creare un sistema software interattivo, è necessario 
arricchire il tradizionale ciclo di vita con espliciti riferimenti all’usabilità. I riquadri 
grigi in Fig. 1.1 indicano alcune attività che devono essere inserite per spostare 
la visione dal progetto centrato sul sistema, tipico del modello a cascata, al 
progetto centrato sull’utente che permetterà di generare sistemi usabili.  
Il riquadro grigio denotato da 1 indica che è obbligatorio integrare la fase dei 
requisiti con un'analisi attenta degli utenti reali, delle mansioni che svolgeranno 
e degli ambienti in cui lavoreranno. Inoltre, le fasi classiche del disegno 
architettonico e del disegno dettagliato dovrebbero includere esplicitamente il 
disegno dell'interfaccia di utente che non sarà più rinviata alla conclusione dello 
sviluppo del sistema. 
 
 
Capitolo 1:                                                                            Progettazione user-centered 
 9 
Come indica  il riquadro 2 l’uso di scenari [Pre, 1994] permette di generare 
un'interazione fra un utente ed il sistema e contribuisce creare una interfaccia 
usabile [Cos, 2001]. 
Una metodologia centrata sull’utente richiede un ciclo iterattivo di 
progettazione-esecuzione-valutazione.  
Il riquadro 3 è inserito nel modello a cascata in modo da rendere esplicito 
che sia la progettazione architettonica sia quella dettagliata dei moduli devono 
essere realizzate con lo sviluppo dei prototipi valutati poi, insieme con gli utenti 
finali per controllare la validità del sistema. Questo ciclo continuerà finchè le 
richieste dell’utente non saranno soddisfatte.  
In più, questo approccio iterativo implica che, per ciascuna fase, all’interno 
del ciclo di vita, è possibile tornare indietro, in particolare alla fase iniziale del 
modello, cioè all’analisi dei requisiti, come indicato dalle frecce in Fig. 1.1.  
La prototipizzazione dell'interfaccia consiste nella realizzazione di un 
'emulatore' (cartaceo o software) del prodotto finale da utilizzare per la 
valutazione fatta dagli utenti. Lo scopo è di verificare, prima della realizzazione, 
l'adeguatezza dell'interfaccia alle caratteristiche e alle esigenze degli utenti 
finali. 
Come Nielsen precisa, "gli utenti hanno capacità infinita di fare 
interpretazioni errate ed inattese degli elementi dell’interfaccia e di svolgimento 
del loro lavoro in modo differente da ciò che voi immaginate" [Nielsen, 1993]. 
In altre parole "la migliore ipotesi del progettista non è mai abbastanza 
buona".