Studio di usabilità di HFS 2.0

Transcript

Università degli Studi di Roma “La Sapienza”
Facoltà di SS.MM.FF.NN.
Corso di Laurea Triennale in Tecnologie Informatiche
Relazione di tirocinio
Studio di usabilità di HFS 2.0
di Massimo Melina (matricola 685565)
Responsabile interno
Emanuele Panizzi
A.A. 2005-2006
1
Indice generale
Capitolo 1.Introduzione........................................................................................................................ 2
Capitolo 2.HFS ~ HTTP File Server.................................................................................................... 3
2.1.Perché.........................................................................................................................................3
2.2.Virtual File System e suoi paradigmi........................................................................................ 4
2.3.Storia.......................................................................................................................................... 5
2.4.Casi d'uso................................................................................................................................... 6
2.5.Come si usa................................................................................................................................ 6
2.6.Com'è fatto...............................................................................................................................11
2.7.Stato attuale del progetto......................................................................................................... 11
2.8.Perché studiarlo........................................................................................................................12
Capitolo 3.Progettazione dello studio.................................................................................................13
3.1.L'usabilità.................................................................................................................................13
3.2.I metodi utilizzati..................................................................................................................... 13
Capitolo 4.Analisi euristica................................................................................................................ 15
4.1.Osservazione diretta.................................................................................................................15
4.2.Osservazione guidata............................................................................................................... 16
Capitolo 5.Focus group svolti.............................................................................................................22
5.1.Focus group semplici............................................................................................................... 22
5.2.Focus group sulla ricorsività....................................................................................................23
Capitolo 6.Definizione del profilo utenti: sondaggio online.............................................................. 26
6.1.Obiettivi del sondaggio............................................................................................................ 26
6.2.Realizzazione........................................................................................................................... 28
6.3.Analisi dei risultati...................................................................................................................28
Capitolo 7.Test usabilità..................................................................................................................... 33
7.1.Progetto.................................................................................................................................... 33
7.2.Esecuzione............................................................................................................................... 34
7.3.Analisi...................................................................................................................................... 35
Capitolo 8.Un nuovo paradigma per il vfs......................................................................................... 45
8.1.Paradigma differenziale........................................................................................................... 45
8.2.La struttura dati........................................................................................................................ 46
8.3.Implementabilità con widget standard..................................................................................... 48
8.4.Ulteriori miglioramenti............................................................................................................ 49
8.5.Operazioni................................................................................................................................49
Capitolo 9.Conclusioni e sviluppi futuri............................................................................................ 51
Ringraziamenti................................................................................................................................... 52
Bibliografia.........................................................................................................................................53
2
Capitolo 1.Introduzione
Capitolo 1. Introduzione
Trasferire file via rete è una necessità per la quasi totalità delle persone che usano un computer, ma
al giorno d'oggi non c'è una tecnologia “definitiva” che soddisfi tutte le esigenze e sia alla portata di
tutti. HTTP File Server1 (meglio conosciuto come HFS), sviluppato dall'autore del presente lavoro,
è un tassello nel quadro degli strumenti disponibili.
La sua diffusione, per quanto notevole2, è stata sicuramente ostacolata dal non aver ancora
impiegato nessuno dei numerosi metodi messi a disposizione dai recenti studi di ergonomia, in quel
campo d'indagine conosciuto come usabilità [1]. Per questo motivo ho deciso di progettare ed
eseguire uno studio al riguardo: 4 metodi standard ed eterogenei sono stati scelti per raccogliere
informazioni utili al fine di aumentare la diffusione e migliorare l'esperienza degli utenti.
Una heuristic evaluation è stata portata avanti avvalendosi del prezioso input dei numerosi utenti
del forum3 (1300 solo quelli registrati), e 6 focus group sono stati effettuati nello stesso ambiente.
Un sondaggio online pubblicizzato sul sito e sul forum è stato compilato da 137 persone; ha
permesso di delineare un profilo dell'utenza e ottenere altre informazioni quantitative utili allo
studio. Sfruttando tali risultati sono state scelte 14 persone, eterogenee ma tutte potenziali utenti,
per eseguire un test di usabilità, a fronte di un minimo di 5 consigliato da Nielsen [2].
Sono emersi dei risultati molto interessanti, e cioè che ci sono dei rilevanti problemi di usabilità.
Rilevanti non solo perché impediscono un utilizzo soddisfacente di HFS, ma perché ne impediscono
del tutto l'utilizzo per parecchi utenti. L'intera mole di risultati è comunque enorme ed è descritta in
dettaglio nei singoli capitoli.
La diretta conseguenza di questo studio è utilizzare le molte informazioni ottenute per costruire una
nuova più semplice versione del programma o, in qualche caso, per approfondire il problema. Parte
di queste modifiche sono state già apportate in una versione più recente (la 2.1), sviluppata durante
lo studio, e le restanti seguiranno nelle prossime versioni.
Un risultato di valore più ampio, che esula dagli intenti iniziali di questo studio, è un nuovo
paradigma per il virtual file system, descritto nel capitolo 8, la cui introduzione è ora pianificata per
la versione 3.0 del programma.
1 All'inizio di questo studio l'ultima versione disponibile di HFS era la 2.0, ed è questa la versione presa in
considerazione.
2 50mila utenti stimati.
3 www.rejetto.com/forum/
3
Capitolo 2.HFS ~ HTTP File Server
Capitolo 2. HFS ~ HTTP File Server
2.1. Perché
HFS conta sulla larga diffusione della tecnologia web per trasferire file in maniera compatibile 4 e
con basso overhead.
Si tratta di un software libero che si propone come strumento di scambio file alternativo a quelli
classicamente usati, che possiamo identificare in email, FTP, chat, web server, ritagliando una
nicchia di mercato lì dove questi ultimi mostrano i loro limiti, senza però essere capace di proporsi
come soluzione definitiva.
Esaminiamo velocemente questi limiti; l'email presuppone l'esistenza di 2 account, che questi siano
sufficientemente spaziosi, e inoltre ha un alto overhead (33%) dovuto alla codifica Base64. Il
protocollo FTP è un ottimo strumento, ma non sempre il software FTP è disponibile su entrambi i
peer, inoltre richiede l'apertura di 2 porte in ascolto anziché una, richiesta che non sempre si può
soddisfare.
Con la chat intendo quei sistemi che hanno un sistema di trasferimento file integrato (IRC, ICQ,
MSN); usando questi sistemi capita spesso l'esigenza di doversi scambiare file, ma i protocolli, oltre
che a volte proprietari, non sono abbastanza scaltri per tentare (o permettere) l'apertura del socket in
direzione inversa nel caso in cui fallisca nella direzione predefinita 5. È chiaro che per trasferire un
file non ha nessuna importanza la direzione in cui il socket viene aperto, e siccome uno dei due peer
potrebbe essere impossibilitato a ricevere connessioni, varrebbe la pena tentare entrambe le
direzioni. IRC e ICQ falliscono nel compito, MSN fa uso di nodi intermedi che fungono da tunnel,
ma quando questo avviene la banda è estremamente ridotta (circa 3KB/s nella mia esperienza
personale) a causa dell'utilizzo su scala mondiale di queste risorse, senza contare la diminuzione di
riservatezza derivante dal passaggio extra.
I web server non sono progettati per scambiarsi file secondo esigenze estemporanee; ad esempio,
monitorare lo stato del trasferimento è una possibilità chiaramente desiderabile, ma praticamente
mai offerta, o ancora, siamo costretti a pubblicare l'intera directory lì dove vogliamo trasferire un
singolo file.
4 Compatibile perché la tecnologia web esiste sulla maggioranza delle piattaforme.
5 Ad esempio, a deve dare un file a b, il socket viene aperto necessariamente da a verso b.
4
Usando HFS i problemi descritti prima non sussistono: non sono necessari account, lo spazio usato
è direttamente quello su cui giace il file scambiato, l'overhead è praticamente zero (solo l'header
HTTP), il software client è già disponibile su qualunque sistema (il browser), è sufficiente una sola
porta in ascolto, ed essendo capace sia di inviare che ricevere, si può evitare di chiedere di aprire la
porta ad un utente che per qualche ragione non può farlo6.
Inoltre, nascendo già con queste esigenze in mente, HFS ha centinaia di strumenti pensati per chi
deve scambiare file, come il monitoraggio dei trasferimenti in corso, l'integrazione con la shell di
sistema, il conteggio dei download, etc.
2.2. Virtual File System e suoi paradigmi
I paradigmi
Ciò che caratterizza principalmente HFS è un virtual file system (vfs d'ora in poi) particolarmente
flessibile. Se osserviamo i vfs presenti in vari prodotti sul mercato troviamo due distinti paradigmi,
che chiameremo minima virtualizzazione e completa virtualizzazione.
Minima virtualizzazione
Quello della minima virtualizzazione è probabilmente il paradigma più diffuso, se non altro per la
sua semplicità di implementazione. Si tratta di avere una lista o un albero, i cui nodi sono puntatori
a directory del disco. Ha pochi nodi, perciò richiede poca memoria ed è veloce nello svolgere
operazioni, ma non possiamo lavorare suoi singoli file; la struttura interna delle directory rispecchia
necessariamente quella del disco e pertanto è poco flessibile. Lo troviamo in prodotti come Apache
httpd, e molti server FTP.
Completa virtualizzazione
Il paradigma completa virtualizzazione lo troviamo facilmente in programmi di masterizzazione,
come Nero Burning Rom, e consiste nel duplicare interamente in memoria la struttura delle
directory che vengono aggiunte. È un albero i cui nodi sono file o directory, e ha il vantaggio di
poter apportare modifiche ad ogni elemento in maniera abbastanza intuitiva: in pratica si agisce sul
file system virtuale come se fosse quello reale, ma le modifiche non vengono scritte su disco,
rimangono in memoria ed è ciò che vede l'utente finale.
L'operazione di duplicare la struttura del disco in memoria può risultare molto onerosa. Questi
6 Ad esempio, in Italia, un utente della rete Fastweb, in quanto non possiede un indirizzo valido su Internet.
5
sistemi hanno il vantaggio di poter gestire singoli file, che è una feature spesso desiderata da chi
deve inviare un file e non vuole essere costretto a mostrare l'intera directory. Una volta duplicata la
struttura, questa rimane completamente slegata dal disco, anche per questioni di efficienza, ma non
sempre questo è desiderabile: se aggiungiamo file in una cartella, o ne rinominiamo alcuni, affinché
questi cambiamenti siano riflessi nel vfs è necessario ripetere manualmente sul vfs ciò che abbiamo
già fatto sul disco.
Paradigma
Pro
Contro
Minima virtualizzazione
Poca memoria, veloce
Poco flessibile
Completa virtualizzazione
Molto flessibile
Molta memoria, lento
Tabella 2.1: paradigmi a confronto
Il sistema usato da HFS
Il vfs presente in HFS è un ibrido: è una completa virtualizzazione con la possibilità di avere dei
nodi simili a quelli della minima virtualizzazione. Questo permette di avere i vantaggi di entrambi i
sistemi, ma non allo stesso tempo: per ogni directory è necessario fissare il paradigma, e una volta
fissato, i vantaggi saranno determinati e relativi solo a quella directory. Questo implica che è
l'utente a decidere di quali vantaggi godere per ogni directory, e conseguentemente con quali
svantaggi pagare la sua scelta.
Vedremo in un altro capitolo (8) che nel corso di questo studio è stato ideato un nuovo paradigma,
unificatore, capace di avere tutti i vantaggi e nessuno svantaggio.
2.3. Storia
HFS nasce nell'estate del 2002 per una personale esigenza dell'autore.
Mi trovavo ad usare regolarmente un programma di chat di mia realizzazione, compatibile con il
network ICQ7, ma non avevo ancora realizzato il supporto per il trasferimento file. Il protocollo di
tutto il sistema era proprietario e non ufficialmente documentato; piuttosto che lavorare su un
sistema malamente documentato e che sarebbe stato utilizzabile solo in quel network, mi venne
l'idea di sfruttare il protocollo HTTP, perché tutti i sistemi diffusi di chat sono capaci di riconoscere
le URL e le rendono disponibili all'utente con un solo click.
7 Disponibile all'indirizzo www.rejetto.com/&RQ/.
6
All'epoca già usavo software server FTP e HTTP già disponibili sul mercato, ma trovavo molto
fastidioso dover spostare il file nella directory “pubblicata”, perché non solo dovevo poi ricordare di
rimetterlo a posto, ma in qualche caso nemmeno potevo spostarlo perché il file era aperto da un
processo che non potevo interrompere. Pubblicare direttamente la directory contenente il file
risolveva questi problemi, ma era sempre laborioso. Ebbi così l'idea di uno strumento che aggirasse
il problema, che permettesse la pubblicazione con soli 2 click, e come protocollo scelsi l'HTTP
perché il più largamente supportato.
2.4. Casi d'uso
●
Scambio al volo
Un utente vuole passare una canzone o una foto ad un altro utente che si trova in chat o al
telefono. Bastano 2 click per pubblicare il file, a questo punto si incolla l'indirizzo nella chat
o lo si detta al telefono. Si tratta del caso d'uso per cui è nato questo software.
●
Reperimento remoto file personali
Un utente vuole accedere ai propri file da remoto, in LAN o via Internet. È possibile
pubblicare intere unità disco, e proteggerle con password. È anche possibile predisporre una
directory in cui inviarsi i file per poi ritrovarseli a casa.
●
Pubblicatore
Un negozio di computer mette a disposizione dei clienti i driver aggiornati per i componenti
hardware venduti. Col tempo alcuni utenti hanno cominciato ad usare HFS sempre più al
posto di server web tradizionali, come Apache. Esistono alcuni domini di secondo livello a
cui risponde direttamente HFS8. Il motivo principale del successo va cercato nella facilità
con cui l'utente accede ad alcune funzionalità, sicuramente replicabili su software più
blasonati ma con molto più lavoro.
2.5. Come si usa
Siccome HFS è un vero e proprio server web, il suo “utilizzo” è meramente limitato a configurarlo e
predisporlo affinché risponda ai client secondo le nostre necessità. La parte più importante è
sicuramente la composizione del file system; andremo ad aggiungere file e cartelle secondo la
8 Ad esempio www.hoking.net, funzionante nel momento in cui scrivo.
7
struttura che desideriamo, cambieremo se necessario i permessi di browsing, download, upload. I
file si possono aggiungere in 5 modi diversi: copia&incolla, drag&drop, da menù, da linea di
comando e dal menù della shell. Grazie a questa varietà, è difficile che l'utente non “indovini” il
modo in cui si compie l'operazione.
La finestra del programma è divisa in 5 parti, rispettivamente dall'alto verso il basso:
1. una barra con i comandi,
c'è un bottone per attivare e disattivare il server, un menù da cui si accede alle maggiori
funzionalità, la porta su cui HFS risponde, e il bottone per il cambio di modalità easy/expert
che serve a nascondere le funzioni più raramente utili,
2. la barra dell'indirizzo serve a rendere ben evidente l'indirizzo da dare a chi vuole collegarsi,
3. il virtual file system, in cui metteremo i nostri file,
4. il log, in cui possiamo sapere cos'è successo finora,
5. le connessioni attualmente aperte.
1
2
3
4
5
Illustrazione 2.1: schermata iniziale di HFS
Il resto dell'interazione normalmente avviene tramite un browser.
8
Cartella
corrente
Per accedere a
risorse protette
Link alla cartella
superiore
Lista completa dei link.
Utile per operazioni speciali.
Lista dei file. Per scaricare
un file si clicca sul nome.
Illustrazione 2.2: quello che vede il client
,
Il programma ha letteralmente centinaia di funzioni, accumulate nel corso degli anni nel tentativo di
soddisfare le esigenze degli utenti. Le principali sono un sistema di account, interfaccia web basata
su template editabile, aggiornamento automatico, vari comandi per limitare lo sfruttamento delle
risorse (banda, spazio disco, etc), possibilità di agire in tempo reale sulle singole connessioni,
aggiornamento del DNS, test automatico per sapere se abbiamo problemi di router e firewall.
9
Primo caso d'uso
Voglio passare un file ad un amico. Faccio clic destro e uso il comando contestuale per inserirlo in
HFS.
A questo punto il programma ha già copiato negli appunti l'URL del file, posso tornare alla finestra
di chat o dell'email, e fare incolla. La persona che riceve l'indirizzo non dovrà far altro che cliccare
sul link e inizierà il download.
10
Secondo caso d'uso
Voglio rendere pubblica la mia collezione di foto. Apro il programma e aggiungo la cartella che le
contiene.
1
2
3
4
Ho scelto real folder perché non ho nessun bisogno
di manipolare i file. A questo punto posso rendere
pubblico il mio indirizzo così che chi voglia vedere
le foto non deve far altro che inserirlo in un
browser. L'esperienza di navigazione è identica a
quella di un sito che colleziona immagini.
11
2.6. Com'è fatto
HFS è un software sviluppato in Delphi. Utilizza una libreria di astrazione dei socket con chiamate
asincrone; la conseguenza è che è capace di gestire un buon numero di connessioni
contemporaneamente ed efficientemente facendo uso di un solo thread. Se da un lato questo può
portare a qualche limite, dall'altro porta ad avere codice più semplice, che non deve preoccuparsi
dei classici problemi della programmazione concorrente.
La gestione del protocollo HTTP è parte integrante del progetto e non è demandata a librerie.
Il progetto è nato come software libero, e i sorgenti, pensati per essere letti da collaboratori,
presentano una buona leggibilità, rispettando criteri uniformi di nomenclatura e una sufficiente
quantità di commenti tutti in lingua inglese.
2.7. Stato attuale del progetto
Ad oltre 4 anni dalla sua nascita, il progetto continua ad essere sviluppato unicamente da me. Ciò
nonostante, una parte del successo è dovuta alla fiducia per la sua natura open source, che nel caso
di un prodotto server è importante.
La stima del numero degli utenti nel momento in cui scrivo è di circa 50mila. Il metodo utilizzato
per la stima è necessariamente grossolano: non è stato usato nessun metodo invasivo per censire
l'utenza. Ciò nonostante, mi aspetto che sia capace di rendere bene l'ordine di grandezza delle cifre
in ballo.
Il metodo è il seguente: è stato sfruttato il fatto che HFS contatta automaticamente
www.rejetto.com, per chiedere alcuni servizi come l'aggiornamento automatico. Queste richieste
lasciano traccia nei log dell'host, che vengono giornalmente scansionati per raccogliere gli indirizzi
IP. Il criterio specifico usato è di contare quanti indirizzi IP diversi con firma HFS sono stati
osservati nell'arco degli ultimi 30 giorni. Per evitare che i sistemi con IP dinamico falsino troppo la
stima, l'ultimo byte dell'indirizzo non è considerato.
Benché attualmente io sia l'unico sviluppatore, c'è un gruppo di volontari che contribuiscono al
progetto scrivendo e traducendo la documentazione, creando risorse utili per gli utenti, fornendo
assistenza sul forum. Alcuni di loro, ho potuto constatare dalle statistiche con mia grande sorpresa,
passano diverse ore al giorno sul forum. L'entusiasmo di questa community, unito al mio amore per
la tecnologia, sono gli elementi trainanti di questo progetto.
12
2.8. Perché studiarlo
HFS è un lavoro nato e portato avanti senza scopi di lucro; la speranza è che possa essere utile
quanto più possibile, ma l'utilità è strettamente legata al numero di persone coinvolte, pertanto la
diffusione è di grande importanza.
Dopo circa 4 anni di sviluppo con la classica mentalità feature-oriented del programmatore[3], mi
sono reso conto di quanto questo fosse limitante per la sua diffusione. Ho deciso così di ragionare
come l'utente (task-oriented), di smettere di dare la colpa agli utenti se una funzione non viene
compresa, di costruire interfacce che non richiedano la lettura della documentazione. L'usabilità è
così finita in cima alla lista delle mie preoccupazioni, e mi tocca riparare ad anni di sviluppo portato
avanti con la mentalità sbagliata.
Quello che può sembrare uno strumento eccezionale ad un tecnico, può risultare una perdita di
tempo ad un utente che tenta di usarlo ma senza profitto. Non mi aspetto di rendere semplice
qualsiasi aspetto, ma ho potuto constatare che è possibile apportare enormi miglioramenti già con
un po' di accortezza e sensibilità.
Mind the problem è l'invito che voglio rivolgere a tutti i miei colleghi.
13
Capitolo 3.Progettazione dello studio
Capitolo 3. Progettazione dello studio
Lo scopo di questo studio è trovare una gran parte dei problemi di usabilità di HFS, o comunque
gran parte di quelli che di fatto ne limitano la diffusione.
3.1. L'usabilità
L'usabilità è l'efficacia, l'efficienza e la soddisfazione con le quali gli utenti raggiungono degli
obiettivi [4]. Si tratta di una scienza relativamente nuova, ancora in fase di formalizzazione, con
buona parte dei testi di riferimento appartenenti all'ultimo decennio. I metodi proposti spaziano tra
metodi user-based [5] e metodi expert-based [6], ma ancora molte aziende faticano ad introdurli nei
propri processi produttivi [7].
3.2. I metodi utilizzati
In questo studio abbiamo deciso di utilizzare 4 metodi abbastanza differenti tra di loro, in modo da
ottenere risultati variegati in un tempo ragionevole, pur conservando largo spazio per
approfondimenti. In tutti e 4 i metodi sono stati coinvolti gli utenti, ma con ruoli diversi di volta in
volta.
Abbiamo cominciato con una heuristic evaluation (capitolo 4), che di norma consiste in un piccolo
gruppo di esperti che valutano l'interfaccia del programma basandosi su un ristretto insieme di
regole e poi discutono assieme i propri risultati [8]. Essendo da solo a portare avanti questo tipo di
analisi, ed essendo il software molto vasto, ho agito in maniera differente: ho lavorato direttamente
nei posti del programma interessati dalle richieste di aiuto degli utenti; per utilizzare una metafora
informatica, ho sostituito il classico metodo polling con uno ad interruzione. Ricevendo un gran
numero di segnalazioni ho potuto eseguire una valutazione dell'interfaccia direttamente nei punti in
cui più probabilmente vi era un problema di usabilità. Credo nella bontà di questa scelta, per
l'elevato numero di richieste di aiuto che arrivano sul forum9, e per la libertà dello strumento (si può
scrivere anonimamente, senza prima registrarsi). Ho praticamente lavorato di meno, ma con un
rendimento elevatissimo. In una minor parte del tempo invece ho eseguito un'analisi più classica,
ma indirizzata su particolari tecnici che probabilmente sfuggivano agli utenti comuni.
Un altro metodo di analisi utilizzato sono i focus group: un gruppo di persone prendono parte ad
una discussione, su un argomento proposto da me, in maniera poco strutturata [9][10]. Nel capitolo
9 Oltre 20 messaggi al giorno da oltre 2 anni.
14
Capitolo 3.Progettazione dello studio
5 descrivo il lavoro, svoltosi online, con libera partecipazione per chiunque si collegasse al forum.
Sono stati particolarmente attivi gli utenti esperti.
Nel capitolo 6 descrivo diffusamente il sondaggio online, che mi ha permesso di delineare il profilo
utenti e altre informazioni utili allo studio. Il sondaggio era aperto a chiunque si collegasse al sito
del programma, perciò a rispondere sono stati utenti, anche occasionali.
Ultimo ed importante strumento scelto per questo studio è stato il test di usabilità: un gruppo
ristretto di potenziali utenti è stato scelto per essere osservato mentre interagisce col sistema, dei
compiti prestabiliti. Si ottengono così risultati sia quantitativi che qualitativi. [11]
Metodo
Ruolo utenti
heuristic eval.
segnalare problemi
focus group
dire la propria opinione
sondaggio
dare informazioni personali e sul
utenti del
online
programma
programma
test di
usabilità
essere osservati durante l'utilizzo
Utenti coinvolti
utenti del
programma
utenti del
programma
Tipologia
risultati
qualitativi
qualitativi
quantitativi
potenziali utenti e
quantitativi e
utenti
qualitativi
Tabella 3.1.: metodi utilizzati
15
Capitolo 4.Analisi euristica
Capitolo 4. Analisi euristica
In questo capitolo parliamo dei problemi riscontrati utilizzando alcune euristiche dettate dal lavoro
di Nielsen [12]:
1. visibility of system status,
2. match between system and the real world,
3. user control and freedom,
4. consistency and standards,
5. error prevention,
6. recognition rather than recall,
7. flexibility and efficiency of use,
8. aesthetic and minimalist design,
9. help users recognize, diagnose, and recover from errors,
10. help and documentation.
In pratica si analizza sistematicamente l'interfaccia del programma confrontandola con dei principi
prestabiliti, chiamati euristiche. Il lavoro è stato svolto in due modi: partendo da un'osservazione
non sistematica e sommaria del software, e partendo invece dalle richieste di aiuto degli utenti.
4.1. Osservazione diretta
In questa sezione vediamo alcuni problemi notevoli che sono sorti durante l'osservazione
dell'interfaccia del programma. Tra parentesi è indicata l'euristica violata.
1. Lato client, manca un link diretto alla home. (7)
2. Quasi tutte le opzioni sono accessibile tramite menù a tendina. Si tratta di una scelta fatta
quando le opzioni erano poche. Ora che dopo anni di sviluppo le opzioni sono tante, una
configurazione approfondita del programma risulta penalizzata dell'elevatissimo numero di
click necessari. (6, 7)
3. Possibile soluzione: adottare un'interfaccia per le opzioni basata su finestre come fanno la
maggior parte dei programmi.
16
4. In questa versione è stata introdotta la doppia modalità easy/expert, e c'è un relativo bottone
per cambiare modalità, la cui etichetta riporta “You are in ***** mode”. Si tratta di una
buona soluzione, abbastanza chiara, ma esistono soluzioni alternative che non sono state
valutate. Ad esempio, l'esperta di usabilità Ellen Reitmayr all'interno del progetto
Klettres [13], per un problema simile suggerisce due diversi bottoni affiancati, uno per ogni
modalità, di cui quello attivo risulta premuto. È necessario uno studio specifico, che prima
stili diverse alternative, e poi valuti il feedback degli utenti. Questo studio dovrebbe tenere
conto anche dello switch on/off presente nella finestra principale, che ha necessità simili.
Penso sia anche opportuno introdurre dei tip più chiari su questi bottoni.
5. Il programma è parco di dialog informative. Si tratta di una scelta che va bene per utenti
esperti, ma meno per chi esperto non è. Siccome esiste il problema collaterale di annoiare
l'utente esperto con informazioni che per lui sono ridondanti, si potrebbero mostrare dialog
informative diverse e/o riservate a chi usa il programma in easy mode. (1, 5)
6. Le operazioni principali di manipolazione sono sprovviste di undo. (3)
4.2. Osservazione guidata
In un lasso di tempo molto ampio, di circa 8 mesi, il supporto che veniva normalmente già da anni
fornito attraverso il forum, è diventato strumento preziosissimo per lo studio di usabilità. Il forum è
utilizzato (non assiduamente) da migliaia di utenti, e ha una media di 20 nuovi messaggi al giorno.
Ogni problema indicato dagli utenti anziché essere semplicemente risolto, è stato confrontato con le
euristiche, e 9 volte su 10 si è confermato un problema di usabilità. Il risultato di questa indagine è
un gran numero di problemi, alcuni gravi alcuni meno. Per quasi tutti sono state formulate delle
possibili soluzioni. Nei casi meno ovvi sono state proposte più soluzioni sul forum, e se n'è discusso
con gli utenti per decidere quale fosse la più appropriata10. In moltissimi casi, a breve tempo dalla
discussione, le proposte sono state implementate in versioni di test del programma per controllarne
l'efficacia tramite un ulteriore feedback degli utenti. Per alcune di esse è stata conservata la richiesta
di aiuto sul sito che ha portato l'attenzione sul problema, e ne è riportata nel seguito la URL. Tra
parentesi è indicata l'euristica violata.
Problemi di comprensibilità
1) Il concetto di root o “/” non è familiare. (2, 4)
10 In alcuni casi queste discussioni sono state considerate focus group, e spostate nel capitolo apposito.
17
Possibile soluzione: sul web è diffuso il concetto di home, tant'è che il programma mostra
una casetta come icona della root. Sostituire la dicitura “/” con “home”.
2) L'azione del bottone you are in ***** mode non è sufficientemente chiara. (4)
Possibile soluzione: aggiungere al bottone un tip che specifichi l'azione
3) Nella configurazione di default, le richieste che il server rifiuta appaiono nel log, ma senza
la relativa risposta di rifiuto. Si è portati a sospettare che siano state soddisfatte. (1, 5)
(www.rejetto.com/forum/?topic=3444.0)
Possibile soluzione: aggiungere un'opzione, per default abilitata, per registrare nel log solo
le richieste soddisfatte.
4) Non è chiaro che bisogna salvare separatamente opzioni e vfs, né il perché. (2, 5)
Possibile soluzione: prevedere un salvataggio di default che fonda entrambi i dati, e se
questo non è sufficientemente flessibile, lasciare la possibilità di salvarli separatamente.
5) Anche dal sito non si capisce quale sia l'utilizzo base del programma. (10)
Possibile soluzione: sul sito immettere delle istruzioni di base, possibilmente in più formati
(testuale, immagini, video) così che l'utente scelga quello che preferisce.
6) Apparente incoerenza di use comment as realm. (4)
Quando il browser fa richiesta di una risorsa protetta, presenta all'utente una dialog per
inserire la password. Per il server è possibile comunicare al browser una stringa da far
comparire nella dialog, e il protocollo HTTP chiama questa stringa realm. HFS permette di
impostare il realm su un nodo, e questa caratteristica viene ereditata da tutti i sottonodi. Il
motivo della ricorsività del realm è che tutte le funzioni di protezione sono ricorsive. Sui
nodi si può impostare anche un commento, ma questo non è ricorsivo. Infine, esiste
un'opzione che fa sì che il commento specificato venga riutilizzato come realm, ma così
facendo perde la sua caratteristica ricorsività, cosa che l'utente può percepire come
incoerenza.
Possibile soluzione: risolvere l'incoerenza modificando uno dei 2 comportamenti.
7) La default action (quella in grassetto) del menù contestuale è dentro un sotto-menù.
L'utente non è abituato e si confonde. (4)
18
(www.rejetto.com/forum/?topic=3195.msg1016509#1016509)
Possibile soluzione: riarrangiare le voci del menù in modo che l'azione di default finisca nel
livello superiore del menù. Inoltre aggiungere la shortcut Ctrl+C, che è lo standard per le
azioni di copia come questa.
8) È presente un menù chiamato IP address, visibile anche nella modalità “easy”, che permette
di scegliere da una lista di indirizzi di rete: quelli associati alla macchina server. Scegliere
un indirizzo da questo menù influisce unicamente sulla costruzione delle URL all'interno
della barra dell'indirizzo. L'utente può essere indotto a credere che abbia effetto anche sul
comportamento che ha HFS in rete, ad esempio per farlo rispondere alle richieste
provenienti solo da uno specifico NIC11. (2, 5)
Possibile soluzione: visto che le funzionalità di questo menù e quelle del menù URL
encoding sono logicamente associate, potrebbero essere messe assieme in un menù che
abbia un nome più chiaro.
Altra possibile soluzione: specificare, con un'etichetta all'interno del menù, che l'azione è
limitata alla formazione delle URL.
9) Nel self test la dialog dice “If you use HFS in a LAN this is not for you”: è ambiguo, perché
in realtà è inteso per chi usa il programma soltanto in LAN, e non anche in LAN. (9)
Possibile soluzione: “If you are not interested in serving files over the Internet, this is not for
you.”
10) Molti utenti non usano il self test, anche se gli serve. Probabilmente la dicitura “self test”
non fa capire a cosa serve, né invita a scoprirlo. (2)
Possibile soluzione: Cambiare dicitura in “Test Internet connection”.
Altra possibile soluzione: avere una procedura guidata iniziale in cui si invita l'utente ad
assicurarsi del buon funzionamento tramite il test.
11) Nel menù troviamo la funzione DNS updater, che serve a sincronizzare periodicamente
l'indirizzo con uno dei tanti fornitori di DNS dinamico. Per disabilitare questa funzione
bisogna fare custom e poi svuotare il campo, e non è ovvio. (2)
Possibile soluzione: aggiungere un comando per farlo.
11 Network Interface Card.
19
12) Sembra quasi che l'editor possa gestire più file, a causa della capacità di caricare e salvare su
file. (5)
(www.rejetto.com/forum/?topic=3285)
Possibile soluzione: introdurre un'etichetta informativa.
13) Le virtual folder esistono anche in IIS12 ma quelle di HFS sono molto diverse, questo causa
confusione in chi ha già esperienza con IIS. (4)
Possibile soluzione: il problema sparirà una volta introdotto il nuovo paradigma (capitolo 8).
14) Nel template editor c'è un campo di testo libero seguito da un bottone find. Gli standard
prevedono che il significato dei campi di input sia chiarito da un etichetta che lo precede,
non da un bottone che lo segue. (4)
Possibile soluzione: aggiungere l'etichetta.
15) Se in una real folder che contiene un file A, aggiungo un file A virtuale, mi trovo in una
situazione di ambiguità per la scelta del file che sarà poi mostrato al client. Attualmente
vengono mostrati entrambi, non c'è modo di distinguerli, ed avendo la stessa URL, di fatto
solo uno di loro è accessibile. (1, 5)
Possibile soluzione: mostrarne una sola, e decidere quale tramite uno studio statistico su ciò
che gli utenti si aspettano in una situazione simile. Sembrerebbe più opportuno mostrare
quella virtuale perché è l'unica visibile nella finestra di HFS. Anche questo problema
sparirebbe con l'introduzione del nuovo paradigma.
16) Le operazioni principali con HFS sono due: dare e ricevere file. Molti utenti che arrivano a
capire come dare, non arrivano a capire come ricevere. (2)
Possibile soluzione: nel menù principale c'è già la voce upload (per le opzioni), aggiungere
una sotto-voce molto visibile “Help - how to?”.
17) Creando degli account può sembrare che il sistema sia già protetto da password. (5)
Possibile soluzione: esplicitare il comportamento del sistema nella dialog degli account.
18) Lato client, quando si clicca upload, non è chiaro che si debba poi scegliere i file cliccando
sfoglia. (2)
12 Server web della Microsoft, secondo per diffusione solo ad Apache.
20
Possibile soluzione: sopra i campi di scelta dei file aggiungere la dicitura “Select the files
you want to upload”.
19) Non si capisce quali azioni sono ricorsive sull'albero. A questo problema è stato dedicato un
focus group nella sezione 5.2. (1)
(www.rejetto.com/forum/?topic=3134.msg1015710#1015710)
20) Lato client, la file list è in realtà una lista di link. (2, 4)
(www.rejetto.com/forum/?topic=4022.msg1020221#msg1020221)
Possibile soluzione: sostituire l'etichetta con una più adatta.
Altri problemi e soluzioni
1) Nel menù contestuale del log, c'è la funzione address2name, che serve a tradurre un
indirizzo numerico in una stringa a scelta. L'indirizzo va sempre digitato manualmente, ma
se l'utente nel log ha cliccato su un indirizzo, è ragionevole aspettarsi che questo sia
automaticamente inserito nella maschera. (7)
Possibile soluzione: inserire automaticamente l'indirizzo puntato dal cursore nel log.
2) Lato client, il bottone upload sembra poco visibile. (8)
Possibile soluzione: aumentarne la visibilità cambiando dimensioni e colori.
3) Quando si aggiunge un ban questo non è efficace da subito, mentre altre operazioni simili lo
sono (ad esempio persistent connections). (4)
Possibile soluzione: applicare subito il filtro anche sulle connessioni esistenti.
4) La configurazione del router mette in crisi molti utenti. (5)
Possibile soluzione: alcuni utenti potrebbero godere del supporto della tecnologia UPNP che
configura il router automaticamente.
5) La funzione find nel template editor è scomoda se si devono modificare le varie stringhe che
trova: si è costretti in continuazione a passare da mouse a tastiera, con un elevato tempo di
homing [14]. (7)
Possibile soluzione: mettendo un accelerator key l'azione diventa possibile direttamente
dall'editor.
21
Suggerimento addizionale: anche F3 dovrebbe richiamare l'azione, perché è considerato uno
standard de facto tra gli editor, ed è anche più accessibile perché è un tasto solo anziché una
combinazione.
6) In Custom IP address qualcuno potrebbe inserire l'indirizzo comprensivo di http:// ed è
sbagliato. (5)
Possibile soluzione: eliminarlo automaticamente anziché indicare l'errore.
7) Nel log, l'alias introdotto dalla funzione address2name è poco visibile. (8)
Possibile soluzione: mostrare l'alias in grassetto.
22
Capitolo 5.Focus group svolti
Capitolo 5. Focus group svolti
La ricerca di problemi e l'analisi di possibili soluzioni è stata effettuata anche organizzano dei focus
group con la community HFS. I focus group sono stati svolti online. Ho proposto agli utenti del
forum alcuni temi di confronto e ho moderato le discussioni che ne sono scaturite.
5.1. Focus group semplici
Per ogni focus group riporto l'URL che fa accedere direttamente alla discussione, e un breve sunto
dei risultati ottenuti.
FC1) www.rejetto.com/forum/?topic=3224
Caricando un file .vfs generato da una versione più recente del programma, vengono
mostrate delle dialog poco chiare.
Risultato della discussione: sono stati individuati insieme agli utenti dei messaggi più chiari.
La porta 80 è spesso già occupata sui PC, e in questi casi HFS usa una porta dinamica. La
porta dinamica è un problema per chi deve configurare un router, e molti non si rendono
conto che se ne può facilmente scegliere una fissa.
Risultato della discussione: introdurre altre porte standard oltre la 80, da usare nel caso in
cui la 80 sia occupata. Questo renderà molto rari i casi in cui il problema si verifica.
Scaricare un'intera cartella può essere un lavoro lungo e noioso.
Risultato della discussione: il server dovrebbe fornire un link/bottone col quale scaricare
l'intero contenuto della cartella sotto forma di file archivio. Il formato di preferenza
dovrebbe essere lo zip perché quello più diffuso, ma eventualmente potrebbero essere fornite
più opzioni. La fattibilità tecnica è stata studiata, con esito positivo.
I totali calcolati da HFS vengono di default resettati ad ogni avvio. Esiste tuttavia un'opzione
che evita il reset, ma è spesso ignorata.
Risultato della discussione: una netta maggioranza degli utenti ha espresso la preferenza di
23
avere il reset disabilitato di default.
FC5)
www.rejetto.com/forum/?topic=4213
Gli utenti che stanno dietro router, hanno difficoltà a capire che hanno due indirizzi di rete
(interno/esterno), a capire che l'indirizzo esterno non è subito disponibile ma va richiesto, e
a scegliere l'indirizzo giusto a seconda del destinatario.
Risultato della discussione: quando un router è individuato, mostrare una doppia barra
dell'indirizzo (Interno/Internet); nella barra Internet mostrare un messaggio che invita a
cliccare per ottenere l'indirizzo Internet.
5.2. Focus group sulla ricorsività
www.rejetto.com/forum/?topic=3197
Durante lo studio è emerso un problema riguardante il vfs, facilmente generalizzabile a strutture
gerarchiche che non necessariamente devono essere composte da file. Nello specifico, il problema
riguarda HFS perché alcune funzionalità agiscono in maniera ricorsiva sui sotto-alberi, mentre altre
no, e comprendere se si tratta dell'uno o dell'altro caso è demandato all'esperienza dell'utente.
Vedremo quattro esempi qui di seguito.
Il sistema presenta difficoltà per l'utente:
●
è difficile comprendere lo stato del sistema (anche successivamente ad un'indagine),
●
usa terminologia di dubbia comprensibilità,
●
richiede di ricordare molte cose,
●
predire i risultati richiede uno studio della documentazione.
Questa è una semplice lista dei criteri violati, ma è bene esaminare esattamente come si manifestano
i problemi, che io ho classificato in 4 famiglie.
1. Capire se un'opzione è ricorsiva o no, nel momento in cui andiamo a selezionarla. Dopo le
premesse fatte questo è forse il problema più ovvio.
Esempio: se applico un commento, questo è applicato unicamente al nodo/cartella in
questione. Se applico una password, questa è applicata anche ai file che vi sono dentro.
Niente nell'interfaccia mi comunica questa differenza, e per l'utente possono servire alcuni
esperimenti prima di avere le idee chiare.
24
2. Sapere quale opzioni stanno effettivamente operando su un file.
Esempio: se imposto il customized realm su una cartella, e poi vado col mouse su di essa,
viene fuori un messaggio/tip che mi conferma che questa opzione è attiva. Ma si tratta di
un'opzione che agisce ricorsivamente sui file contenuti nella cartella (senza limiti di livello),
e invece, su quei file, il tip non mi dice che c'è un customized realm operante.
3. Pur riuscendo a risolvere il problema 2, e comunicando all'utente le opzioni operanti su un
qualsiasi file, rimane impossibile distinguere quando l'opzione è impostata localmente o
ereditata da un nodo superiore. Si tratta di un'informazione fondamentale per disattivare
l'opzione.
Esempio: facendo hide tree su una cartella, questa viene nascosta, e con lei tutti i file in essa
contenuti. Se uno di questi nodi figli ha un hide tree impostato su di esso, io non vedrò
differenza con un nodo che sta semplicemente ereditando quella opzione. L'unico modo di
saperlo sarà di cercare tra le opzioni di quel file, e vedere che l'hide tree è abilitato.
4. Capire se un'opzione che andiamo ad impostare sovrascriverà la stessa opzione
eventualmente ereditata da un nodo superiore, o se invece si combinerà con essa.
Esempio: imposto index.html come file di default sulla root. Poi su una cartella imposto
default.html come file di default. Come si comporterà la cartella rispetto ai due file? Userà
solo default.html o in mancanza di esso accetterà anche index.html? Quale sia la risposta a
questa domanda è ininfluente, a noi interessa un modo per comunicarla facilmente all'utente.
Si tratta di problemi a cui non è stato banale rispondere, e infatti non sempre ho trovato risposte
soddisfacenti. Sono strutture complesse con cui non capita tutti i giorni di dover lavorare, il che
complica le cose, perché il linguaggio con cui comunicare certe cose non è largamente diffuso tra
l'utenza “domestica”. Di seguito però diamo alcune possibili soluzioni o suggerimenti, che dove non
fossero esaurienti, forniscono una base su cui approfondire lo studio.
1. Applicare un'etichetta (recursive) a tutte le opzioni ricorsive.
Si potrebbe obiettare che, essendo questo metodo applicato solo alle opzioni ricorsive,
quando non c'è ricorsività l'utente non è informato esplicitamente della cosa, e quindi
richiede esperienza. Ovviamo facilmente alla cosa applicando un'etichetta (non recursive),
ma voglio mettere in dubbio la bontà di questa scelta: potrebbe sovraccaricare l'interfaccia; è
necessario pertanto un approfondimento dello studio prima di applicarla.
25
Si può fare un'altra obiezione: quanti utenti capiranno leggendo la parola ricorsivo? Si tratta
di un'etichetta appropriata? Un'alternativa potrebbe essere applies to descendants.
2. La soluzione più ovvia è mostrare tutte le opzioni.
3. Mostrare nel tip un'etichetta (inherited) per le opzioni che sono state ereditate da un nodo
superiore, e nessuna etichetta aggiuntiva per le opzioni impostate localmente.
4. Mostrare oltre all'opzione locale, anche l'opzione ereditata, con una convenzione grafica che
faccia capire in che modo viene usata localmente; ad esempio una croce rossa sopra
potrebbe far capire che l'opzione non è in realtà applicata perché è stata sovrascritta.
Bisogna stare attenti però, perché tale pratica può facilmente portare ad un sovraccarico di
informazioni.
Un buon compromesso potrebbe essere non mostrare affatto l'opzione sovrascritta, ma solo
un'eventuale opzione ereditata combinata, con un linguaggio grafico che la distingua, come
un colore più tenue o un'etichetta inherited.
In queste soluzioni si è fatto largo uso di etichette. Sarebbe molto interessante trovare un linguaggio
iconografico per esprimere i concetti inherited, recursive e i loro opposti; purtroppo in seno a
questo studio non sono riuscito ad arrivare ad un risultato, e ritengo sia un compito arduo visto che
si tratta di concetti complessi, difficili da esprimere se non tramite l'ausilio di una legenda.
Riuscendo invece ad introdurre una legenda, che sia però di immediata consultazione in tutti i
momenti in cui questi simboli vengono usati, allora si può ovviare anche al problema sollevato
prima riguardo la comprensibilità di termini come ricorsivo, che appartengono all'esperienza di un
matematico sicuramente, ma darebbero del filo da torcere agli altri. Con una legenda potremmo
evitare di usare delle etichette così sintetiche e criptiche per far spazio a descrizioni di maggior
respiro, anche di 20-30 parole.
Concludo questa sezione segnalando questo problema come meritevole di ulteriore studio; siccome
investe molte funzionalità di questo programma, una soluzione più appropriata può determinare un
sensibile miglioramento dell'esperienza dell'utente.
26
Capitolo 6.Definizione del profilo utenti: sondaggio online
Capitolo 6. Definizione del profilo utenti: sondaggio
online
6.1. Obiettivi del sondaggio
Sapere com'è composta la base utenza di HFS ha almeno due scopi:
●
eseguire i test di usabilità su un gruppo di persone che sia rappresentativo,
●
poter formulare ipotesi su problemi di usabilità che impediscono a certe categorie di utenti
di usare il programma (nel caso la base utenza risultasse poco variegata).
Essendo HFS un prodotto principalmente reperito ed usato sul web, è plausibile affermare che un
sondaggio condotto via web raggiunga gli utenti in maniera sufficientemente uniforme, senza
barriere significative.
Ciò che ho voluto ricavare da questo sondaggio è
●
delineare il profilo dell'utente medio, specialmente riguardo la sua esperienza informatica,
●
ricevere un feedback di tipo quantitativo sull'attuale stato dell'usabilità di HFS,
●
capire meglio quali sono i casi d'uso più frequenti,
●
rivelare se alcune funzioni e aspetti chiave sono compresi o ignorati dagli utenti.
Confezionare bene tutto questo non è stato banale: doveva essere facile da capire, difficile da
sbagliare, e compilabile in 5 minuti. Quindi, poche domande, a risposta chiusa, ben organizzate,
curate nell'aspetto, che sembri un gradevole passatempo. Ho evitato domande che fossero
esplicitamente dirette a decidere l'allocazione di risorse per lo sviluppo, per non invogliare utenti
maliziosi a falsare i risultati (per esempio compilando molti finti questionari).
Il risultato di questa progettazione consiste di 23 domande ed è visibile all'indirizzo
www.rejetto.com/survey/.
27
Illustrazione 6.1: il form del sondaggio
28
6.2. Realizzazione
Ho personalmente sviluppato il software di raccolta e elaborazione dati. Per la raccolta ho prima
creato una descrizione testuale del questionario, in una forma che facilitasse il parsing.
Successivamente ho realizzato uno script PHP che effettua il parsing, dà in output un unico form, e
raccoglie i dati dopo aver controllato eventuali errori da parte dell'utente. Reso funzionante il tutto,
ho sottoposto il questionario ad un gruppo ristretto di persone, per effettuare un breve beta-test e
controllare che le domande e le risposte fossero appropriate.
Successivamente mi sono rivolto ad una persona che ha redatto molti testi tecnici in lingua inglese,
per assicurarmi della proprietà di linguaggio. Avendo così ottenuto la versione finale del
questionario, ho invitato in diversi modi gli utenti a compilare il questionario: mettendo un link
molto visibile sul sito, scrivendo un messaggio sul forum su cui risiede la community, e inviando
email agli utenti che avevano dato consenso a ricevere segnalazioni (un migliaio).
Il sondaggio è rimasto aperto tutto Dicembre 2006, circa un mese.
6.3. Analisi dei risultati
Nel momento in cui scrivo e analizzo i dati, il sondaggio è stato compilato 137 volte e rappresenta
quasi il 3 per mille della base utenza stimata. Non si tratta di un cattivo risultato se consideriamo
che solo il 2% dell'utenza stimata è stata raggiunta dall'invito a partecipare.
Feedback usabilità
Per quanto riguarda lo stato attuale dell'usabilità, troviamo dei valori abbastanza rassicuranti,
esclusivamente ed equamente distribuiti sui valori positivi. Solo una metà promuove a pieni voti
però, il che fa capire che c'è ancora largo spazio per miglioramenti. Inoltre un buon voto non
significa necessariamente che il programma presenti poche difficoltà: è possibile che le difficoltà
siano concentrate nell'approccio iniziale, in cui l'utente cerca di capire cos'è e a cosa serve. La
diretta conseguenza di questo sarebbe che chi non supera queste difficoltà abbandona il programma
subito, restando anche escluso dal questionario. Pertanto una particolare attenzione va posta sui
problemi iniziali che può incontrare l'utente.13
13 Questa che può sembrare una congettura adesso, si rivelerà fondata nella sezione 7.3.
29
Do you understand the terminology used in HFS?
is HFS easy?
Always
Often
Sometimes
Very easy
Fair
Hard
No
Very hard
Fotografia dell'utente
Il profilo che ne è uscito è netto su sesso (prevalentemente maschile) ed
Female 5
esperienza informatica, che risulta molto elevata: gli utenti si definisco
“bravi” o più spesso esperti, e oltre metà di loro ha avuto esperienze di
programmazione. Un fattore che varia molto invece è l'età: anche se il
50% si attesta tra i 18 e i 28 anni, il restante 50% è ben distribuito nei
valori a salire, con numeri significativi fino ai 60 anni, e un picco di 73.
Male 132
La fascia più piccola che includa il 75% degli utenti è invece 18-40.
Computer experience
Age
10 – 19
20 – 29
30 – 39
40 – 49
50 – 59
60 – 69
70 – 79
Low
Basic
Skilled
Advanced
Anche le percentuali sull'educazione sono ben distribuite, possiamo solo dire che gli utenti hanno
tutti ricevuto almeno un'educazione superiore.
30
Sul fronte lavoro invece è stato fatto un errore: è stato messo assieme indistintamente chi non ha
mai lavorato, con chi non lavora nel campo informatico. Solo in seguito mi è parso evidente che
distinguerli è utile al fine di delineare l'utenza: chi ancora studia e non lavora, spesso dedica più
volentieri tempo per imparare un nuovo strumento software. Per riparare a questo errore ho ideato
un metodo per stimare l'una e l'altra categoria. I parametri usati per stimare chi ancora studia sono:
età inferiore ai 19 anni, oppure inferiore ai 26 ma avendo specificato university (no degree) nel
campo education. I parametri per i lavoratori non-IT sono: età superiore ai 25, oppure superiore ai
18 ma avendo specificato in education che non è stata frequentata alcuna università. Siccome si
tratta di una stima imprecisa, diversi casi sono ricaduti in nessuna delle due stime (l'8%), perciò i
valori così ottenuti sono stati normalizzati.
Tentata così una correzione di questo errore, il risultato finale vede un buon 50% dell'utenza
appartenere al mondo IT, un 33% fuori dal mondo IT e il resto composto da giovani
prevalentemente sotto i 20 anni di età, presumibilmente studenti. E con questo abbiamo risposto al
primo dei punti che volevamo ottenere con questo sondaggio.
Highest achieved level of education
Job
Degree
University (no
degree)
Graduated
High/Secondary
school
Anything less
Programmer
System administrator
Other IT related
Non-IT related
Unemployed
Casi d'uso
Share files over
HFS viene usato da tutti per scambiare file via Internet, ma una
LAN 13
metà di questi anche in rete locale, a dimostrazione che il
Both 57
protocollo Microsoft di condivisione (SMB) non è sempre la
scelta più adeguata. Il sistema SMB è più trasparente e
performante (test comparativi effettuati personalmente), ma
Internet 66
alcuni utenti hanno dichiarato che troppo spesso hanno
difficoltà a farlo funzionare, presumibilmente a causa di scarso feedback del sistema in caso di
31
malfunzionamento.
Ben il 75% usa HFS bidirezionalmente, quindi la fruibilità della funzione
Direction
di upload non deve essere considerata molto secondaria rispetto a quella
Sending 31
più comune (download). La funzione di upload è stata introdotta solo di
Receiving 4
recente nel software, e soffre di alcuni problemi classici delle funzioni non
Both 102
previste fin dall'inizio.
Non c'è una vera prevalenza nell'uso della tipologia di cartella (real/virtual) e una grossa fetta di
utenza le usa entrambe. Questo non implica una vera presa di coscienza delle caratteristiche dei due
paradigmi; l'utente potrebbe partire sempre da uno dei due per poi
Folder kind
spostarsi sull'altro solo dopo essersi scontrato con l'inadeguatezza
del paradigma scelto. Quello che possiamo però dire è che non c'è
Real 39
da dare una priorità all'una o all'altra, e che gli utenti hanno
Both 79
bisogno delle feature di entrambe. Vediamo però nel capitolo 8
Virtual 16
come sia possibile risolvere il problema alla radice, unificandole.
Ben 9 utenti su 10 usano l'expert mode, il che dà spazio a diverse
Mode
Easy 11 Don't know 4
supposizioni: forse al sondaggio hanno partecipato principalmente utenti che
hanno molta confidenza con HFS; ma un'altra visione del risultato potrebbe
mettere in luce una cattiva distribuzione delle funzionalità tra modalità expert
e easy.
Expert 122
Dietro un router ci sono 3 utenti su 4, sicuramente
Router
NATtati, ed è notoriamente una situazione problematica come dimostrano
No 33
le innumerevoli richieste di supporto al riguardo. Facilitare l'utente
nell'utilizzo dietro un router migliorerebbe significativamente la qualità
della sua esperienza.
Yes 102
Esattamente metà dell'utenza ne fa un utilizzo
Dynamic DNS services
sporadico, mentre la restante metà tiene il server always-on, e come è
facile immaginare, questi ultimi sono un sovrainsieme di quelli che
dicono di avere un server aperto a tutti. Alta la percentuale di utenti che fa
uso di servizi di DNS dinamico, 2 su 3.
DynDNS
No-IP
CJB
Other
32
Un terzo degli utenti non usa l'importante funzionalità di aggiornamento, la cui attivazione è
demandata all'utente. Si può ipotizzare che si tratti di utenti scrupolosi che preferiscono eseguire
manualmente gli aggiornamenti, ma può darsi che il fenomeno sia da attribuire alla pigrizia. Inoltre
non appare nessun reale motivo per lasciare all'utente il compito di azionare questa funzione,
quando si potrebbe automatizzarla, lasciando la libertà di disattivarla.
Aspetti chiave
L'80% dell'utenza fa ricorso al forum per l'assistenza, un altro 80% alla documentazione, e
incrociando i dati vediamo che è il 66% ad usarli entrambi. Intanto è facile notare come si tratti di
percentuali molto alte rispetto alle normali abitudini della gente, che non sono certo di visitare
frequentemente il sito del programma o di partecipare al forum di supporto. Questi numeri si
spiegano facilmente notando che proprio forum e sito sono stati i veri promotori del sondaggio,
probabilmente solo una minor parte dei partecipanti consiste di visitatori occasionali; chi è un utente
“fidelizzato” è più propenso anche a partecipare ad una simile iniziativa. Ma anche premesso ciò, il
risultato è ambiguo, perché è difficile interpretare se una larga diffusione di questi mezzi derivi
dalla buona volontà degli utenti nell'usare il programma al pieno delle sue potenzialità, o se invece è
sintomo di una chiarezza solo parziale dell'interfaccia.
Prima abbiamo detto che 3 utenti su 4 utilizzino HFS per scambiare file in entrambi i versi, ma
sarebbe stato interessante sapere se l'utente ha capito come si fa a far funzionare il software in
entrambi i versi, oppure se si limitano entrambi i soggetti a fungere da server. La funzione di upload
difatti è in questo studio accusata di forti problemi di usabilità, e rispondere a questo dubbio farebbe
luce su quanto l'uso di questa funzionalità abbia preso piede tra l'utenza. Purtroppo il dubbio rimane
e possiamo considerare questo come un errore di progettazione del sondaggio.
Nel sondaggio era presente anche una domanda che aveva lo scopo di capire quanto l'utenza capisse
correttamente il termine file system, concetto chiave del software, ma i risultati di questa parte
dell'inchiesta sono praticamente nulli perché le risposte messe a disposizione suggerivano troppo
all'utente quale fosse la risposta giusta.
33
Capitolo 7.Test usabilità
Capitolo 7. Test usabilità
I test di usabilità sono uno strumento efficacissimo, in cui l'utente viene osservato direttamente
mentre interagisce col sistema in una situazione plausibile. Secondo alcuni studi [2] 5 è il numero di
utenti su cui fare il test per ottenere il miglior rapporto costi/benefici. In una realtà aziendale si tratta
di un importante criterio, ma per questo studio ho deciso di triplicare questo numero e ho ottenuto
risultati importanti che vedremo più avanti.
7.1. Progetto
Il test è stato concepito innanzitutto ideando lo scenario: l'utente è di fronte al computer connesso
ad Internet e parla al telefono con un suo amico, anch'egli al computer. A metà del test la
comunicazione passa dal telefono alla chat, per verificare quanto lo scambio dell'indirizzo http su
diversi mezzi sia agevole agli occhi dell'utente.
Ho di seguito ideato dei task che affrontassero punti chiave di quello che mi aspetto sia l'utilizzo
comune di HFS:
●
trasferire un file “al volo”,
●
far apparire le cose diversamente da come sono (virtual file system),
●
limitare manualmente l'utilizzo delle risorse manipolando i permessi,
●
predisporre il server ad un utilizzo di tipo persistente,
●
usarlo non solo per inviare ma anche per ricevere.
Nello specifico, i task progettati sono
1. Stai al telefono con un amico e vuoi mandargli il file cena.jpg che hai sul desktop.
Hint: se entro 4 minuti non ha portato a termine il task o si è arreso, all'utente del test viene
fornito un foglio con le seguenti istruzioni riprese e tradotte dalla sezione Introduction della
guida.
1. Far partire il programma
2. trascinare sulla finestra il file da condividere
3. dare al tuo amico l'indirizzo (address)
Fine task: chiudi HFS.
34
2. Stai sempre al telefono, vuoi mandargli una cartella (desktop\vacanze), dentro però c'è un
file privato, che non vuoi che venga visto.
Fine task: chiudi HFS.
3. Sei in chat, vuoi mostrare al tuo amico la tua collezione di mp3 (documenti\mp3), senza
permettergli di scaricare. Deve solo poterci navigare dentro.
Fine task: lascia aperto HFS.
4. Vuoi che chiudendo e riaprendo HFS la cartella degli mp3 rimanga.
Fine task: lascia aperto HFS.
5. Vuoi far sì che il tuo amico possa mettere un file mp3 nella tua cartella mp3.
Hint: se entro 4 minuti non ha capito che deve usare upload nel menù contestuale, suggerire.
I task sono stati concepiti in maniera che il test durasse circa mezz'ora, e comunque non più di
un'ora.
Prima del test, le persone sono state rassicurate sul fatto che “sotto torchio” fosse il programma e
non loro, che errori e fallimenti nel test servissero ad indicare difetti del programma, che così
scoperti sarebbero poi stati risolti. Questa ed altre azioni sono servite ad evitare che l'utente si
sentisse sotto esame, quindi stressato, inficiando i risultati.
Nella scelta degli utenti si è tenuto conto dei risultati del sondaggio descritto nel capitolo 6. Sono
così state scelte 14 persone, con conoscenza almeno di base dell'inglese, età compresa tra i 20 e i 40
anni, abituali utilizzatori di computer.
Il test è stato condotto principalmente su persone con nessuna (o trascurabile) esperienza
relativamente ad HFS, sia per per far fronte alle ipotesi formulate dopo il questionario, secondo cui
il programma presenta difficoltà soprattutto all'inizio, sia perché lo studio vuole puntare soprattutto
a migliorare l'approccio iniziale con il software, ancor più che migliorare l'esperienza dell'utente
avanzato; pertanto è stato mantenuto un rapporto 2:1 tra le persone senza e con esperienza.
7.2. Esecuzione
Per facilitare l'adesione dei partecipanti al test, ho evitato di ricorrere all'uso di un laboratorio, ma
ho lasciato scegliere loro la sede di volta in volta. Per questo mi sono avvalso della seguente
strumentazione:
35
●
un laptop,
●
un microfono,
●
un software14 per registrare gli eventi (schermo, audio, etc),
●
un mouse, per coloro che non fossero avvezzi al touchpad,
●
un cronometro,
●
un blocco note, su cui annotare problemi, commenti e dati rilevanti,
●
suggerimenti prestampati, da fornire nei momenti prestabiliti.
La procedura per il test è stata raffinata durante le varie prove. Dal principio non sapevo quali
informazioni mi sarebbero state più utili, così a diversi giorni di distanza ho dovuto riguardare
alcuni dei filmati registrati per estrarle.
Ho potuto inoltre constatare come è importante fornire un ambiente di test privo di
personalizzazioni, e come sia difficile ripristinare l'ambiente manualmente con accuratezza ogni
volta. Ad esempio, un utente tramite il drag&drop ha creato un link ricorsivo in una cartella, senza
che io me ne accorgessi; quando l'utente successivo ha sottoposto quella cartella ad HFS, il
processo è entrato in loop infinito. Col senno di poi ricorrerei forse alle virtual machine, a prodotti
come VMware o Virtual PC, così da poter semplicemente duplicare la VM ad ogni test.
7.3. Analisi
Terminate le varie prove, ho riportato in maniera schematica le informazioni ottenute, alcune
quantitative in tabella, altre in elenchi.
14 Per la registrazione è stato usato Morae della TechSmith, www.morae.com
36
Nome
Alessio
Andrelia
Angelo
D1d0
Daniela
Eleonora
Francesco
Jake
Leo
Pako
Simonpietro
Valerio
Walter
Willi
Esperienza
Visto
Mai visto
Mai visto
Utente
Mai visto
Utente
Mai visto
Mai visto
Utente
Visto
Visto
Utente
Visto
Utente
Medie
Inglese
Tempo totale
Ottimo
35
Sufficiente
35
Sufficiente
22
Ottimo
15
Buono
90
Ottimo
25
Scarso
60
Scarso
45
Ottimo
15
Ottimo
27
Buono
22
Ottimo
30
Buono
15
Buono
17
Buono
T1 T2 T3 T4
!7
1
1
1
?5
2
2
2
2
4
3
1
0,5 0,5
1
2
2
5
5
3
0,5 0,5
3 !5
4
1
7
1
?5
2 !4
1
1
1
2
1
1
1
2
1
1
3
3 0,5
1 0,5
1 0,5
2
1
1
1
1
1 0,5 0,5
T5
0,5
?6
2
1
?5
?5
!7
?4
1
1
0,5
0,5
1
0,5
32,4 1,5 1,7 2,4 1,2 0,9
Falliti+Hint 1+2
0
1
1 1+4
Tabella 7.1: i test in numeri
●
T1, T2, T3, T4, T5 sono i task, e i numeri sotto rappresentano la durata in minuti.
●
! indica un task fallito per resa dell'utente
suggerimento.
? indica un task portato a termine solo dopo il
7
6,5
6
Alessio
5,5
Andrelia
Angelo
D1d0
Daniela
Eleonora
Francesco
Jake
Leo
Pako
5
4,5
4
3,5
3
2,5
Simonpietro
Valerio
Walter
Willi
2
1,5
1
0,5
0
T1
T2
T3
T4
T5
Illustrazione 7.1: tempi in minuti per ogni task
37
7.3.1. Risultati quantitativi
I test sono durati circa mezz'ora, come previsto. Quello da 90 minuti riportato in tabella è stato il
primo test, che ha sofferto di tutti i problemi tecnici dovuti all'inesperienza.
Due valori in tabella sono di particolare interesse:
il numero di fallimenti sul task 1 e sul 5 sono
abbastanza elevati. I valori nella forma A+B
5
4
stanno ad indicare il numero di fallimenti totali
(A) e il numero di successi conseguiti solo in
3
seguito al suggerimento (B). Le persone che non
conoscevano il programma erano 9, e 3 di queste
hanno fallito il primo task, che è quello sulla
2
1
funzionalità di base. È un chiaro segno che il
programma presenta grandi difficoltà a farsi capire
dai nuovi utenti, e che i timori già sorti col
0
T1
T2
T3
T4
T5
Illustrazione 7.2: numero fallimenti dei task
sondaggio online sono reali.
L'altro punto critico per i fallimenti è il task 5. Si tratta di un task la cui difficoltà era chiara fin dalla
fase di progettazione, e tuttavia è stato incluso per formalizzarne l'esistenza, essendo un problema
che investe una funzionalità importante del programma: la bidirezionalità. Metà delle persone senza
esperienza, ma anche uno degli utenti abituali del programma, hanno fallito questo task.
Ho ritenuto interessante studiare statisticamente un paio di aspetti dei task svolti: il metodo usato
dagli utenti per aggiungere i file, e il metodo usato per nasconderli. Il punto in questione è che sono
risultati che possono essere raggiunti in svariati modi diversi dall'utente, ed è sicuramente
interessante per lo sviluppatore conoscere quali sono i modi più diffusi, quelli che sorgono più
naturali ad un primo utilizzo.
38
24
22
20
18
16
14
12
10
8
6
4
2
0
Menu principale
Menu contestuale
Menu shell
Drag & Drop
Illustrazione 7.3: metodi usati per aggiungere file/folder (T1, T2, T3)
5
4
3
2
1
0
Hide
Remove
Togliere il file dalla
cartella
Aggiungere i file selettivamente
Illustrazione 7.4: metodi usati per nascondere il file (T2)
È facile notare come il drag&drop sia un metodo di interazione largamente diffuso. Benché non sia
il metodo più efficiente tra quelli messi a disposizione da HFS, gli utenti sanno di poterci contare
senza dover consultare un complicato menù.
Per quanto riguarda il task 2, vediamo come non ci sia una particolare preferenza sul metodo, se
non uno sfavore nei confronti del comando remove. Possiamo ipotizzare che gli utenti novizi,
ancora non avvezzi al paradigma del vfs, abbiano paura che il file venga rimosso dal supporto su cui
risiede fisicamente, e preferiscono pertanto usare il più rassicurante hide, o addirittura aggirare il
problema agendo direttamente sul file system reale, sistema macchinoso che dimostra ancora una
volta come l'abitudine vinca sull'efficenza.
39
Problemi rilevati
Riesaminando tutti i test svolti, ho ottenuto una lista dei problemi cui sono andati incontro gli
utenti. I problemi sono raccolti in una ventina di classi e ulteriormente raggruppati; per alcuni ci
sono note aggiuntive e/o soluzioni suggerite. Oltre alla descrizione del problema, tra parentesi è
possibile trovare il task in cui si è manifestato il problema (preceduto da una T), o anche il numero
di utenti che hanno incontrato il problema (preceduto da una N).
Problemi riguardo il meccanismo di base: “dare l'indirizzo”
●
Crede che l'indirizzo visto nel log (comprensivo di porta) sia l'indirizzo da comunicare.
Possibile soluzione: partendo dal ragionevole assunto che l'indirizzo mostrato nel log,
all'utente inesperto serve solo a poter ricostruire i vari flussi di operazioni, che nel log sono
elencati in un'unica area di testo, intrecciati, si può pensare di dipanare questi flussi in
maniera diversa. Un esempio è usando i colori: si attribuisce un colore diverso ad ogni
connessione15; oppure possiamo pensare ad un “multi-log”, composto da più aree di testo,
una per ogni connessione.
●
Crede di aver bisogno di sapere l'IP dell'utente.
●
Non capisce che deve dare l'indirizzo. (N3)
●
Anche se capisce che deve dare l'indirizzo all'altra persona, non capisce che si tratta di un
indirizzo da usare in un browser.
Tutti questi problemi sono legati, e possono essere affrontati probabilmente con un'unica azione che
renda più chiaro che bisogna comunicare l'indirizzo presente nella barra in alto, e l'altro utente deve
scriverlo nel browser. Si tratta probabilmente del più macroscopico problema di usabilità del
programma, e visti i numeri della sezione precedente posso azzardare una stima dell'utenza “persa”
a causa del problema: 20-30%.
Ho provato a proporre ad un paio di utenti di cambiare la dicitura Address in Give this address (o
simile), ma uno di loro mi ha detto che non gli basterebbe comunque per capire. A posteriori mi è
venuta l'idea di aggiungere alla dicitura anche l'icona del software browser, che darebbe un
suggerimento.
15 Il colore può essere scelto da una palette fissa, ma ovviamente questo introduce nuove difficoltà: non si possono
usare troppi colori perché l'occhio umano non riuscirebbe a carpirne le differenze, ma pochi colori implicano un
riutilizzo frequente, e allora per evitare che l'utente confonda due connessioni che a breve distanza usano lo stesso
colore, ci troviamo a dover anche comunicare in qualche modo quando un colore viene riutilizzato.
40
Un utente ha proposto di mostrare un'introduzione al primo avvio del programma. Sembra una
soluzione di grande potenzialità, ma bisogna da subito valutare la possibilità che l'utente la salti. Ho
notato infatti che gli utenti si muovono abbastanza precipitosamente tra le dialog, spesso senza
leggerle, evitandole quando possibile. Ci si sofferma solo quando è già sorto un problema. Pertanto
si può facilmente immaginare che è necessario permettere all'utente di riaccedere all'introduzione in
un secondo momento. E qui sorge un ulteriore problema: esiste già nel menù di HFS una voce
Help → Introduction, ma in pochi gli hanno dato importanza. In almeno un paio di casi ho
osservato l'utente lasciar perdere l'introduction per lanciarsi alla consultazione della Full guide,
perdendosi nella vastità della documentazione. Posso ipotizzare dunque che il bottone per
riaccedere alla introduzione andrebbe messo in una posizione più visibile che in un sottomenu, e
pure andrebbero nascoste altre “attraenti” voci di aiuto che poco si confanno alle esigenze
dell'utente inesperto.
Problemi di ordine nel menù
●
Non fa save file system, ma invece autosave vfs on exit. (T4) (N7)
Nota: autosave si trova prima di save nel menù.
●
Crede che proteggere il file lo nasconda anche.
Nota: il comando che protegge si trova prima di hide nel menù.
●
Let download è poco visibile. (N2)
Nota: il comando si trova in fondo al menù.
●
Pensa che don't count as download sia utile per non far scaricare. (T2, T3) (N2)
Nota: questa funzione si trova prima di let download nel menù.
●
Pensa che deve aggiungere un utente (o mettere password) per permettere l'upload. (N2)
Nota: la “protezione” nel menù si trova prima dell'upload.
Ho notato che gli utenti procedono nel leggere il menù dall'alto verso il basso, banale ma vero, e
questo dà una spiegazione a tutti i problemi qui sopra: in tutti i casi infatti, l'operazione cercata si
trovava dopo l'operazione che ha tratto in inganno (e che è stata scelta). In questi casi dovrebbe
essere sufficiente scegliere un ordine dei comandi in cui si preferisce la funzione di più largo
utilizzo, oppure la funzione meno ambigua, che minimizzi la confusione generata nell'utente.
41
Altri problemi riguardanti i menù
●
Cerca nel menù principale una funzione che sta nel menù contestuale. (N4)
Ho notato che alcuni utenti, nella ricerca di una funzione, si concentrano o sul menù
contestuale, o più spesso sul menù principale. A volte addirittura non arrivano mai a
cambiare il menù in cui ricercano la funzione.
Possibile soluzione: aggiungere dinamicamente al menù principale il menù contestuale del
file correntemente selezionato. Si pone il problema di come chiamare questo menù: il nome
potrebbe essere dinamico, a seconda di ciò che è selezionato (file|files|file/folders).
La funzione di upload è una di quelle che si trova solo nel menù contestuale e alcuni utenti
invece la cercano nel menù principale. Vista l'importanza della funzione, è da valutare la
possibilità di far comparire un riferimento anche nel menù principale stesso.
●
Non nota le funzioni load/save. (N3)
Possibile soluzione: spostarle più in cima.
Possibile soluzione: porre le funzioni in un sottomenu.
Possibili soluzione: mostrarle anche nel menù contestuale.
●
Ci sono comandi di rara utilità con icona, e altri di frequente utilità senza icona; questo fa sì
che l'attenzione vada facilmente sul comando sbagliato.
Tra i vari casi è possibile citare new link (rara utilità, con icona) e add folder (frequente
utilità, senza icona).
Possibile soluzione: individuare i vari casi, e dare al comando più utile uguale o superiore
visibilità.
●
A volte la pagina sul browser non rispecchia le modifiche. (N6)
Questo problema ha causato molti disastri durante il test. Ad esempio gli utenti davano
permessi di upload, ma poi non avevano un feedback visivo sul browser, ed erano convinti
di aver sbagliato qualcosa. Molti non arrivavano a capire la natura del problema e si
arrendevano.
Possibile soluzione: inviare al browser un comando no cache che gli suggerisca di non
mostrare la pagina senza averla scaricata nuovamente dal server.
42
Problemi dovuti al doppio paradigma virtual/real folder
●
Non è possibile gestire il contenuto delle real folder da dentro HFS. (N3)
Gli utenti, se hanno davanti una cartella, sono abituati a poterla espandere per vedere e
manipolare i file contenuti. Anche coloro che possono avere familiarità con altri vfs dove le
cartelle non si espandono, non capiscono come mai il limite si applichi solo alle real folder.
Possibile soluzione: se viene fatto doppio-click su una real-folder, mostrare una dialog che
spiega succintamente il problema all'utente.
●
L'attesa durante il caricamento delle virtual folder non è chiara (non compare la cartella).
Possibile soluzione: mostrare la cartella aggiunta fin da subito, l'utente ha così il necessario
feedback visivo dell'operazione compiuta.
●
Aggiungendo una virtual folder, non c'è un indicazione sufficiente per comprendere quanto
manca alla fine del lavoro.
●
Non si capiscono le caratteristiche che differenziano real e virtual folder. (N4)
43
Un utente ha proposto di aggiungere informazioni negli hint dei bottoni nella dialog di scelta
real/virtual.
Possibile soluzione: tutti i problemi elencati in questa sezione trovano soluzione implementando il
il paradigma proposto nel capitolo 8.
Altri problemi
●
Il nome “file system” fa paura, sembra qualcosa che toccandolo può compromettere la
stabilità del sistema.
Possibile soluzione: rinominarlo in “file project”, o altra terminologia equivalente. Prima di
applicare tale provvedimento però è necessario svolgere ulteriori indagini; essendo “file
system” il nome più appropriato da un punto di vista tecnico, gli utenti più avanzati
potrebbero non gradire il cambiamento.
●
Non ricollega il termine upload con l'intento di farsi dare un file. (T5)
●
La nomenclatura download/upload è ambigua e trae in inganno.
Effettivamente si tratta di una nomenclatura che dipende dal punto di vista: quando un entità
fa un upload, l'altra corrispondentemente sta facendo un download. HFS fa fronte a questo
problema parzialmente usando la dicitura in/out dove possibile, ma in alcuni contesti è
inappropriato ed è stato lasciato download/upload.
Possibile soluzione: usare send/receive potrebbe essere meno fuorviante, ipotesi che però
andrebbe verificata con uno studio specifico.
●
L'indirizzo indicato nella barra superiore non funziona in locale. (N2)
44
Ci sono alcuni casi in cui l'indirizzo scelto non funziona se usato in locale. Un esempio è
quando si è usato find external address e il router è programmato per non rigirare le
richieste che vengono dalla LAN ma solo quelle da Internet.
Possibile soluzione: il comando browse può mandare direttamente su localhost.
Proposte degli utenti
Agli utenti è stato data l'opportunità di fare proposte e note che non avessero necessariamente a che
fare con i problemi osservati da me durante il test. Io ho raccolto, valutato, classificato, e il risultato
è l'elenco che segue.
●
Aggiungere un bottone add file in testa al vfs.
●
Nel menù contestuale nascondere i seguenti comandi quando si è in easy mode: comment,
icon, switch to real/virtual, new link, rename, browse it.
●
Siccome let download e hide riguardano la protezione, metterli vicino a set user/pass.
●
Mettere un'icona vicino alle cartelle che hanno disabilitato let download.
●
Rendere il bottone browse della barra degli strumenti più visibile, ad esempio spostandolo a
sinistra e chiamandolo browse address con la stessa icona del browser.
●
Il menù delle icone è scomodo in verticale, e non si capisce nemmeno come aggiungerle.
●
Non tenere tutto in un menù, ma averne più di uno, come gli altri programmi.
●
La dicitura del bottone you are in ... mode è troppo lunga.
Nota: benché sembri ragionevole, credo che l'utente non abbia valutato i vantaggi derivanti
dalla maggior chiarezza della frase rispetto ad un semplice easy mode, che può indicare lo
stato attuale o lo stato in cui porta la pressione del bottone; in sostanza è ambiguo.
Nell'evoluzione del programma, la nuova dicitura è stata introdotta proprio per diminuire la
confusione tra gli utenti, constatata sul forum.
●
La guida dovrebbe rispondere al tasto F1 e [?], dovrebbe essere contestuale, e disponibile
anche offline che si aggiorna automaticamente.
●
Disponibilità del programma in italiano (più lingue).
45
Capitolo 8.Un nuovo paradigma per il vfs
Capitolo 8. Un nuovo paradigma per il vfs
Nella sezione 2.2 abbiamo parlato di due paradigmi per il vfs, e più volte in questo documento
faccio riferimento ad un risultato importante ottenuto in questo studio, che qui espongo.
L'avere un doppio paradigma per il vfs è uno dei maggiori problemi del programma. La mancanza
di chiarezza dilaga tra nuovi utenti come tra gli esperti, e non c'è da meravigliarsi: non c'è un diretto
collegamento tra il paradigma/strumento e la necessità dell'utente. Per scegliere, l'utente è costretto
a imparare e comprendere entrambi gli strumenti, per poi costruire nella sua testa una soluzione
basata su di essi. Scegliere uno dei due infatti non sempre basta; a volte per ottenere ciò che vuole
l'utente è costretto a far ricorso ad una soluzione composita. Poter avere avere un solo strumento
che va bene in tutti i casi sarebbe chiaramente preferibile.
Come sviluppatore di questo software, più volte mi sono chiesto negli anni se non fosse possibile
unificare i due paradigmi in uno solo, e ogni volta che me lo chiedevo, da buon informatico, tentavo
di esplorare le risposte possibili alla ricerca di una che avesse una sua coerenza e implementabilità.
Si tratta comunque di un problema abbastanza complesso, e non ho mai trovato soluzioni fino a
quando non ho investito le necessarie risorse di tempo e dedizione, cosa che è avvenuta all'interno
di questo lavoro. Il risultato è un nuovo paradigma, che ho battezzato differenziale.
8.1. Paradigma differenziale
Il concetto dietro il paradigma differenziale è che l'albero in memoria rappresenta la differenza tra il
vfs che l'utente sta disegnando e il contenuto del disco. Esempio: se aggiungo una cartella, e poi
virtualmente rinomino un file dentro di essa, le informazioni che ho in memoria sono la cartella e il
file rinominato, il resto viene caricato on-demand dal disco, e pertanto la struttura è sincronizzata
col disco stesso.
Quando si aggiunge una cartella dal disco al vfs, si crea un nodo che punta alla cartella sul disco.
Nonostante i file della cartella non vengano letti né aggiunti all'albero, il nodo della cartella appare
espandibile, dando all'utente l'illusione che i file siano già stati aggiunti. Quando si espande il nodo,
questo viene popolato con i file che non abbiamo precedentemente letto; questa operazione però
viene fatta tenendo conto delle informazioni “differenziali” contenute nel nodo cartella,
informazioni che riguardano file cancellati e rinominati.
46
8.2. La struttura dati
Si tratta di un albero composto da due tipi di nodi: cartelle virtuali slegate dal disco, e cartelle/file
che hanno un riferimento al disco. Fin qui la descrizione è esattamente equivalente al sistema misto
attualmente usato da HFS, la differenza sta nel modo in cui vengono gestiti questi nodi, e nel fatto
che all'utente non è richiesto di scegliere nulla. Difatti, la struttura dati in sé non è molto dissimile,
ma il suo valore semantico sì, come anche gli algoritmi applicati.
L'esempio visto poco prima è molto semplice; ora immaginiamo di aggiungere una cartella linkata
al disco, la espandiamo, poi espandiamo una sua sotto-cartella, rinominiamo un file interno ad essa,
e concludiamo collassando il tutto.
Cartella aggiunta dall'utente,
linkata ad una cartella del disco
Sottocartella “fantasma”,
serve a reggere il file
A
B
File rinominato virtualmente
C
Illustrazione 8.1: esempio di struttura
L'informazione minima che dobbiamo conservare è chiaramente costituita dal puntatore alla cartella
iniziale, e dal nuovo nome da applicare al file. Ma in definitiva, che informazioni conserviamo?
Come le strutturiamo? Potremmo semplicemente tenere un'unica lista globale delle differenze, ma i
problemi sorgono quando andiamo a valutare la complessità algoritmica di un tale sistema. Esiste
una soluzione intermedia, che è di avere una lista di differenze per ogni cartella linkata, che includa
le differenze anche delle sue sotto-cartelle. Ma per entrambe queste soluzioni vorrei far notare che
stiamo parlando di alberi, e il numero di sotto-nodi può crescere velocemente.
La soluzione che scala meglio consiste nell'utilizzare una struttura ad albero anche per le differenze.
La mossa “furba” sta nel non avere un albero di differenze dentro l'albero del vfs, ma un solo albero
47
capace di fare entrambe le cose. Ho analizzato tutte le operazioni/modifiche possibili, e mi sono
accorto che queste ben si prestavano a essere memorizzate come normali file/folder. In pratica
invece di memorizzare il rename in sé come operazione, memorizzo il file rinominato, codificando
il fatto che lo tengo in memoria solo perché è stato rinominato. Se il file si trova non nella cartella
di base, ma in una sotto-cartella, allora questa sotto-cartella andrà mantenuta in memoria,
codificando il fatto che sta lì unicamente per “contenere” il file rinominato, nel senso che serve a
codificare la struttura del ramo.
Per ottenere questo risultato, ho dovuto diversificare le tipologie di nodi, così da codificare
l'informazione. Ho identificato le seguenti categorie.
●
Static, sono i nodi che sono stati aggiunti a mano dall'utente. Può contenere un link ad un
file fisico o meno16.
●
Fake, sono nodi che servono a impedire che una cartella sia realmente vuota, in modo che
sia sempre possibile espanderla, cosa che l'utente percepisce vedendo vicino al nodo il
caratteristico segno
. Nei componenti visuali più diffusi, i nodi senza figli non dispongono
della possibilità di espandersi, ma noi abbiamo le cartelle inizialmente vuote che verranno
riempite con i file solo quando l'utente chiederà l'espansione. Questo tipo di nodo non deve
essere visualizzato, e non ha un corrispondente fisico sul disco.
●
Temp, sono nodi che vengono aggiunti all'espansione di una cartella, e vivono finché
la
cartella non viene richiusa (collassata), a quel punto vengono cancellati automaticamente.
Ha sempre un riferimento ad un file fisico.
●
Mod, erano nodi temp che sono stati modificati (ad esempio rinominati), pertanto non
vanno più cancellati automaticamente (come i temp) quando la cartella collassa. Se però le
modifiche vengono in qualche modo annullate, riportando di fatto il nodo in sincronia col
disco, allora vengono riclassificati come temp. Ha sempre un riferimento ad un file fisico.
●
Removed, erano nodi temp che sono stati cancellati. Deve rimanere nascosto graficamente.
Ha sempre un riferimento ad un file fisico.
●
Semitemp, si tratta di una cartella e ha sempre un riferimento ad un file fisico. Era un nodo
temp, con figli temp, ma ad un certo punto un figlio è diventato mod oppure removed. Non
dimentichiamoci che i temp vengono cancellati automaticamente al collassare della nodo; se
16 Quelli senza link sono anche chiamati virtuali per sottolinearne la natura. Non sono previsti file virtuali, ma solo
cartelle. La funzionalità di una cartella virtuale è di raggruppare file che sul disco sono dislocati in cartelle diverse.
48
un nodo temp ha come figlio un nodo mod o removed, necessariamente dobbiamo evitare
che il padre venga cancellato, per non perdere il figlio, ed è per questo che il nodo padre
viene riclassificato da temp in semitemp. Ritornerà ad essere temp nel momento in cui tutti i
suoi figli saranno temp17.
Avendo tutte queste tipologie di nodi riusciamo ad avere una struttura ad albero che rappresenti la
differenza tra il vfs e il contenuto del disco.
La struttura dati finale è così composta:
●
resource, tipo stringa, puntatore al file su disco,
●
name, tipo stringa, nome virtuale,
●
kind, tipo enumerato (static, fake, temp, semitemp, mod, removed),
●
flags, altre informazioni utili, come sapere se si tratta di una cartella o meno.
8.3. Implementabilità con widget standard
Voglio far notare che questa rappresentazione richiede che esistano nodi invisibili, nodi che fanno
parte dell'albero ma che non vengono mostrati a video, funzionalità non disponibile nel componente
visuale (widget) fornito da Windows XP. Ho utilizzato nella prima stesura un widget molto più
avanzato, il Virtual TreeView18, un progetto open source che da solo consta di 1MB di codice. Una
volta giunto ad un'implementazione soddisfacente, ho pensato che era interessante vedere se questa
tecnologia poteva facilmente essere implementata utilizzando un widget molto più semplice come
quello disponibile nei vari Windows.
Nella prima implementazione i nodi invisibili erano usati sia per i tipi fake e removed. Ho studiato il
problema e la soluzione che né è venuta fuori è:
●
i nodi removed vengono sostituiti da una lista di nomi all'interno del nodo padre: la lista
contiene i nomi dei file cancellati,
●
i nodi fake non vanno sempre lasciati in vita per le cartelle, e non sono invisibili ma
riportano l'etichetta empty; vanno creati quando la cartella è vuota, e distrutti quando la
cartella presenta almeno un nodo di tipo diverso.
17 Oppure fake. Anche i nodi fake sono ammessi, in quanto, proprio come i temp, vengono cancellati al collassare della
cartella. Essendo nodi “di servizio”, sono stati tenuti fuori dal ragionamento per non appesantirlo.
18 http://www.delphi-gems.com/VirtualTreeview/
49
Con questi due accorgimenti e con leggere differenze grafiche, si ottiene un ottimo risultato
basandosi sul widget standard, che è la versione finale che ho presentato durante il corso di questo
studio.
Illustrazione 8.2: nodi fake nella seconda implementazione
8.4. Ulteriori miglioramenti
Essendo le cartelle dei link al disco, e presentando lo stesso contenuto, l'utente probabilmente si
aspetta che le modifiche sul disco siano riflesse in tempo reale, e non semplicemente aggiornate
quando viene espanso il nodo. Un comportamento simile (tempo reale) è infatti offerto dalle dialog
di sistema per la scelta di file e cartelle.
Per ottenere questo risultato, i nodi con riferimento al disco sono continuamente monitorati.
Poniamo il caso di una cartella A aggiunta sul vfs. Se rinominiamo la cartella sul disco, il software
se ne accorgerà e provvederà ad aggiornare il riferimento presente nel nodo. Se poi il nodo è
espanso e sono mostrati i file in esso contenuti, quando sul disco andiamo ad aggiungere un file a
quella cartella, il software provvederà ad aggiungere il relativo sotto-nodo.
Siccome tutti gli elementi contenuti in una cartella comprendono nel loro path completo il path
della cartella stessa, aggiornare il riferimento di una cartella implica l'aggiornamento di tutti i suoi
discendenti, il che può essere molto oneroso. Così ho deciso di usare un riferimento “relativo” per i
nodi non-static. Riprendendo la struttura dell'illustrazione 8.1, immaginando che il riferimento di A
sia C:\altro\A, il riferimento di B sarà semplicemente B e quello di C sarà C. Per conoscere il
path assoluto di un nodo qualsiasi (esempio C:\altro\A\B\C) servono al più depth passi.
Quando un nodo viene aggiunto, il suo nome non viene più memorizzato in una variabile name, ma
viene calcolato runtime dal riferimento. Esiste invece una variabile customName che viene usata
solo nel caso che il file venga rinominato virtualmente.
8.5. Operazioni
Esistono delle operazioni di servizio della struttura (sotto-albero), chiamate fix e unfix, che servono
50
a convertire i nodi temp in semitemp. Il concetto è che se faccio qualcosa che va ricordata all'interno
di una sottocartella temp, devo far in maniera che la sovrastruttura permanga e non venga
cancellata, e questo avviene con un'operazione fix che converte i nodi da temp a semitemp.
Ora vediamo come un'operazione possa essere molto più complessa dal punto di vista del sistema,
con il paradigma differenziale rispetto alla completa virtualizzazione19. Nell'ultimo caso la
cancellazione di un nodo avviene semplicemente deallocando la memoria. Nel differenziale invece,
●
●
se non si tratta di uno static,
○
il suo nome viene registrato nella lista dei file cancellati del padre,
○
eseguiamo una fix sulla struttura del padre,
altrimenti
○
eseguiamo una unfix la struttura del padre,
●
deallochiamo
●
aggiungiamo eventualmente un nodo fake al padre se è rimasto senza figli,
●
rimuoviamo un eventuale monitor piazzato sul nodo cancellato.
Altra operazione interessante è l'aggiunta di un file sotto una cartella: se il file corrisponde ad un
file che era stato precedentemente aggiunto alla lista dei file cancellati, va rimosso da questa lista e
aggiunto come temp, altrimenti va aggiunto come static.
19 Nella minima virtualizzazione cancellare un file non è possibile.
51
Capitolo 9.Conclusioni e sviluppi futuri
Capitolo 9. Conclusioni e sviluppi futuri
Conclusioni
I problemi di usabilità di HFS evidenziati mediante questo studio sono tanti; circa metà di questi
sono di facile soluzione e richiedono solo un intervento estetico. In altri casi è evidente che il buon
senso del programmatore non è stato sufficiente a creare un'interfaccia che guidi l'utente dal
problema alla soluzione: gli strumenti sono
tutti perfettamente a disposizione, ma mancano gli
indizi su quali strumenti usare. È necessario disseminare l'interfaccia di questi indizi, e costruire
delle dialog che siano più orientate al task che alla feature. Importantissimo è anche ripensare il
programma, fin dal sito web che lo distribuisce, affinché sia ben chiaro al nuovo utente quali sono
le mosse base da compiere per ottenere il trasferimento dei file.
Il lavoro di reingegnerizzazione del vfs da solo ha richiesto molti sforzi in ambito di progettazione,
e molti altri ne richiederà per riuscire ad integrare i risultati all'interno del software, ma da solo può
risolvere decine di problemi di usabilità.
Sviluppi futuri
Questo studio è tutt'altro che completo. Alcune delle soluzioni proposte sono opinabili e andrebbero
vagliate con ulteriore feedback; altre non sono soluzioni concrete ma idee e linee di pensiero da
tradurre.
La quasi totalità dell'indagine è stata portata avanti relativamente all'insieme delle finestre di
dialogo del programma stesso, ma altrettanti sforzi andrebbero indirizzati sul lato browser, dove si
svolge una parte altrettanto rilevante dell'attività dell'utente.
52
Ringraziamenti
Ringraziamenti
I miei genitori, che hanno saputo aspettare.
Emanuele Panizzi, per la pazienza e la fiducia.
Leonardo De Luca, Gerardo Carrieri, Stefano Salsano, che mi hanno aiutato a testare e migliorare
il comportamento del nuovo virtual file system.
Peter Herbert, che si è assicurato della proprietà di linguaggio nei testi in lingua inglese.
Giuliano Strapponi, per avermi insegnato cosa significa essere veramente umile.
Tutti i ragazzi del test, i nomi sono in tabella, d'ora in poi sono storia.
Chi mi ha ospitato, chi mi ha accompagnato, chi si è preso cura di me.
53
Bibliografia
Bibliografia
• 1: Mirko Corli, Usabilità: un tentativo di definizione, 2002,
http://www.nousab.org/usabcreat/usabdef.htmlx
• 2: Nielsen J., Why You Only Need to Test With 5 Users, 2000,
http://www.useit.com/alertbox/20000319.html
• 3: David M. Nichols and Michael B. Twidale, The Usability of Open Source Software, 2002,
http://www.firstmonday.org/issues/issue8_1/nichols/
• 4: International Organization for Standardization, Ergonomic requirements for office work with
visual display terminals, 1997,
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=21922
• 5: Foraker Design, Usability testing, 2002,
http://www.usabilityfirst.com/glossary/main.cgi?function=display_term&term_id=470
• 6: Foraker Design, Usability inspection, 2002,
• 7: Maurizio Boscarol, L'usabilità tra il dire e il fare, 2002, http://www.usabile.it/142001.htm
• 8: Nielsen J., Heuristic Evaluation, 1994, http://www.useit.com/papers/heuristic/
• 9: Nielsen J., The Use and Misuse of Focus Groups, 1997,
http://www.useit.com/papers/focusgroups.html
• 10: Foraker Design, Focus group, 2002,
• 11: Foraker Design, Usability testing, 2002,
• 12: Nielsen J., Ten Usability Heuristics, 1994,
http://www.useit.com/papers/heuristic/heuristic_list.html
• 13: Ellen Reitmayr, Klettres dual mode, 2005,
http://www.openusability.org/forum/message.php?msg_id=427
• 14: Deborah Abratt, Wayne Mallinson and Antonet Bekker, Usability Testing: Recipe for
Success, 2003,
http://www.stickyminds.com/getfile.asp?ot=XML&id=7072&fn=XDD7072filelistfilename1.pdf
&ei=XO_XRabeGYOgASXoeT6CA&usg=__ReAPP1vga2IMWAjOni5YmRQxaio=&sig2=Ogqq6lBNmZddBwRP3
-nGtg
54

Studio di usabilità di HFS 2.0

Transcript

Documenti analoghi

indice generale

Cedam - Il reato aberrante di Dacqui` Giuseppe - Libri

Centrostiledesign di Davide Cipriani

Capitolo 4 - L`allestimento del laboratorio nella scuola G.Marcati

Le persone colte non-frequenti e la musica oggi. Senti Questo di

Scarica

Scarica la guida

Ripristino portatile senza aver fatto i dischi di ripristino e partizione

File Leggimi per Kodak ML-500 digital photo

Comune di Guspini

AIRT Lab - Università Politecnica delle Marche

4pp