Studio di usabilità di HFS 2.0

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 Server 1 (meglio conosciuto come HFS), sviluppato dall'autore del presente lavoro, è un tassello nel quadro degli strumenti disponibili. La sua diffusione, per quanto notevole 2, è 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 forum 3 (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

Capitolo 2.HFS ~ HTTP File Server 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ò farlo 6. 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

Capitolo 2.HFS ~ HTTP File Server 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 ICQ 7, 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

Capitolo 2.HFS ~ HTTP File Server 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 HFS 8. 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

Capitolo 2.HFS ~ HTTP File Server 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

Capitolo 2.HFS ~ HTTP File Server 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

Capitolo 2.HFS ~ HTTP File Server 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

Capitolo 2.HFS ~ HTTP File Server 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 Capitolo 2.HFS ~ HTTP File Server 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 Capitolo 2.HFS ~ HTTP File Server 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 forum 9, 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 Utenti coinvolti Tipologia risultati heuristic eval. segnalare problemi utenti del programma qualitativi focus group dire la propria opinione utenti del programma qualitativi sondaggio online dare informazioni personali e sul programma utenti del programma quantitativi test di usabilità essere osservati durante l'utilizzo potenziali utenti e utenti quantitativi e 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

Capitolo 4.Analisi euristica 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ù appropriata 10. 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

Capitolo 4.Analisi euristica 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

Capitolo 4.Analisi euristica (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 NIC 11. (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

Capitolo 4.Analisi euristica 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 IIS 12 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

Capitolo 4.Analisi euristica 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

Capitolo 4.Analisi euristica 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. FC2) www.rejetto.com/forum/?topic=3636 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. FC3) www.rejetto.com/forum/?topic=2777 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. FC4) www.rejetto.com/forum/?topic=4111 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

Capitolo 5.Focus group svolti 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

Capitolo 5.Focus group svolti 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

Capitolo 5.Focus group svolti 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

Capitolo 6.Definizione del profilo utenti: sondaggio online Illustrazione 6.1: il form del sondaggio 28

6.2. Realizzazione Capitolo 6.Definizione del profilo utenti: sondaggio online 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

Capitolo 6.Definizione del profilo utenti: sondaggio online is HFS easy? Do you understand the terminology used in HFS? Very easy Fair Hard Very hard Always Often Sometimes No Fotografia dell'utente Il profilo che ne è uscito è netto su sesso (prevalentemente maschile) ed esperienza informatica, che risulta molto elevata: gli utenti si definisco Female 5 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. La fascia più piccola che includa il 75% degli utenti è invece 18-40. Male 132 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

Capitolo 6.Definizione del profilo utenti: sondaggio online 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 Unemployed System administrator Other IT related Non-IT related Casi d'uso HFS viene usato da tutti per scambiare file via Internet, ma una Share files over LAN 13 metà di questi anche in rete locale, a dimostrazione che il protocollo Microsoft di condivisione (SMB) non è sempre la Both 57 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

Capitolo 6.Definizione del profilo utenti: sondaggio online malfunzionamento. Sending 31 Receiving 4 Direction Both 102 Ben il 75% usa HFS bidirezionalmente, quindi la fruibilità della funzione di upload non deve essere considerata molto secondaria rispetto a quella più comune (download). La funzione di upload è stata introdotta solo di recente nel software, e soffre di alcuni problemi classici delle funzioni non 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 spostarsi sull'altro solo dopo essersi scontrato con l'inadeguatezza del paradigma scelto. Quello che possiamo però dire è che non c'è Real 39 Folder kind da dare una priorità all'una o all'altra, e che gli utenti hanno bisogno delle feature di entrambe. Vediamo però nel capitolo 8 come sia possibile risolvere il problema alla radice, unificandole. Virtual 16 Both 79 Mode Easy 11 Don't know 4 Ben 9 utenti su 10 usano l'expert mode, il che dà spazio a diverse 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. Dynamic DNS services Esattamente metà dell'utenza ne fa un utilizzo Yes 102 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

Capitolo 6.Definizione del profilo utenti: sondaggio online 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

Capitolo 7.Test usabilità 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

Capitolo 7.Test usabilità un laptop, un microfono, un software 14 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

Tabella 7.1: i test in numeri Capitolo 7.Test usabilità Nome Esperienza Inglese Tempo totale T1 T2 T3 T4 T5 Alessio Visto Ottimo 35!7 1 1 1 0,5 Andrelia Mai visto Sufficiente 35?5 2 2 2?6 Angelo Mai visto Sufficiente 22 2 4 3 1 2 D1d0 Utente Ottimo 15 0,5 0,5 1 2 1 Daniela Mai visto Buono 90 2 5 5 3?5 Eleonora Utente Ottimo 25 0,5 0,5 3!5?5 Francesco Mai visto Scarso 60 4 1 7 1!7 Jake Mai visto Scarso 45?5 2!4 1?4 Leo Utente Ottimo 15 1 1 2 1 1 Pako Visto Ottimo 27 1 1 2 1 1 Simonpietro Visto Buono 22 1 3 3 0,5 0,5 Valerio Utente Ottimo 30 1 0,5 1 0,5 0,5 Walter Visto Buono 15 2 1 1 1 1 Willi Utente Buono 17 1 1 0,5 0,5 0,5 Medie Buono 32,4 1,5 1,7 2,4 1,2 0,9 Falliti+Hint 1+2 0 1 1 1+4 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? indica un task portato a termine solo dopo il suggerimento. 7 6,5 6 5,5 5 4,5 4 3,5 3 2,5 2 1,5 1 0,5 0 T1 T2 T3 T4 T5 Illustrazione 7.1: tempi in minuti per ogni task Alessio Andrelia Angelo D1d0 Daniela Eleonora Francesco Jake Leo Pako Simonpietro Valerio Walter Willi 37

Capitolo 7.Test usabilità 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 stanno ad indicare il numero di fallimenti totali (A) e il numero di successi conseguiti solo in 5 4 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 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 sondaggio online sono reali. 2 1 0 T1 T2 T3 T4 T5 Illustrazione 7.2: numero fallimenti dei task 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

Capitolo 7.Test usabilità 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 Illustrazione 7.4: metodi usati per nascondere il file (T2) Aggiungere i file selettivamente È 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

Capitolo 7.Test usabilità 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 connessione 15 ; 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

Capitolo 7.Test usabilità 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

Capitolo 7.Test usabilità 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

Capitolo 7.Test usabilità 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

Capitolo 7.Test usabilità 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

Capitolo 7.Test usabilità 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 Capitolo 8.Un nuovo paradigma per il vfs 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 A Sottocartella fantasma, serve a reggere il file 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

Capitolo 8.Un nuovo paradigma per il vfs 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 meno 16. 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

Capitolo 8.Un nuovo paradigma per il vfs 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 temp 17. 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 TreeView 18, 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

Capitolo 8.Un nuovo paradigma per il vfs 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