Activity Theory e KDE: analisi di usabilità di una interfaccia per sistemi operativi UNIX

1

Indice 1 L'oggetto di analisi...................................................................................................................3 1.1 La metodologia di sviluppo di KDE .................................................................................3 1.2 Analisi del modello di sviluppo di KDE ...........................................................................4 1.2.1 Il processo a cascata .................................................................................................4 1.2.2 Il modello user centred design ..................................................................................6 1.2.3 Il rapid prototyping approach....................................................................................7 1.2.4 La proposta di un modello ........................................................................................7 2 L'activity theory: introduzione .................................................................................................9 2.1 Concetti chiave ................................................................................................................9 2.1.1 La mediazione ..........................................................................................................9 2.1.2 La consapevolezza..................................................................................................10 2.1.3 Lo sviluppo ............................................................................................................11 2.1.4 La struttura dell' attività..........................................................................................12 2.2 La rappresentazione degli errori .....................................................................................13 2.3 Il metodo di analisi.........................................................................................................14 2.4 Scenari: tecniche d’uso...................................................................................................16 3 Studi precedenti .....................................................................................................................18 3.1 The Linux Usability Study – Relevantive AG.................................................................18 3.1.1 Lo svolgimento dell’ esperimento...........................................................................18 3.1.2 La valutazione dei risultati......................................................................................19 3.1.3 Gruppi di utenti ......................................................................................................19 3.1.4 Risultati..................................................................................................................20 3.1.5 Critiche ..................................................................................................................21 3.2 Altri studi su software libero ..........................................................................................22 3.3 Il KDE Usability Project ................................................................................................22 3.3.1 Analisi di usabilità del KDE usability project ........................................................23 4 L’analisi ................................................................................................................................26 4.1 Documento di debriefing................................................................................................26 4.2 Scenari ...........................................................................................................................26 4.3 Fasi preliminari ..............................................................................................................27 4.4 Soggetto 1......................................................................................................................28 4.4.1 Scenario 1 ..............................................................................................................28 4.4.2 Scenario 2 ..............................................................................................................29 4.4.3 Scenario 3 ..............................................................................................................33 4.4.4 Considerazioni........................................................................................................34 4.5 Soggetto 2......................................................................................................................36 4.5.1 Scenario 1 ..............................................................................................................36 4.5.2 Scenario 2 ..............................................................................................................37 4.5.3 Scenario 3 ..............................................................................................................40 4.5.4 Considerazioni........................................................................................................41 4.6 Soggetto 3......................................................................................................................41 4.6.1 Scenario 1 ..............................................................................................................41 4.6.2 Scenario 2 ..............................................................................................................43 4.6.3 Scenario 3 ..............................................................................................................46 4.6.4 Considerazioni........................................................................................................47 5 Conclusioni............................................................................................................................48 Appendice .....................................................................................................................................49 Screenshot dei breakdown rilevati..........................................................................................49 Bibliografia ...................................................................................................................................53 Webgrafia......................................................................................................................................53 2

1 L'oggetto di analisi
Si definisce Open Source (OSS) una filosofia di sviluppo di sistemi informatici il cui assioma fondamentale è la disponibilità pubblica dei codici sorgenti del software. Questo è un modello opposto rispetto a quello dei software commerciali, che si basano sulla segretezza dei codici sorgenti dei programmi. Sulla base di questa filosofia di progettazione è stato sviluppato quello che viene definito il free software (software libero), che ha generato un sistema operativo completo, GNU/Linux (di cui Linux è solamente il kernel, cioè la parte del codice dedita a dialogare con l'hardware), che è sostanzialmente un clone del sistema operativo UNIX e con esso compatibile. GNU/Linux (d'ora in poi solo Linux per brevità) eredita le caratteristiche di UNIX; la sua interfaccia si basa principalmente sulla riga di comando (o shell). Un sistema così concepito è per lo più dedicato a utenti esperti con elevate competenze informatiche con alle spalle un periodo di addestramento abbastanza lungo. In tempi recenti la possibilità di distribuire liberamente un sistema operativo quale Linux ha spinto parte dei programmatori che scrivono software libero a creare un ambiente desktop per questo sistema in modo che esso potesse essere utilizzato anche da utenti comuni. Parallelamente sono stati sviluppati software di utilizzo comune (produttività di ufficio, grafica, multimedia) che presentano un vario grado di integrazione (sia a livello tecnologico che per quanto riguarda la coerenza e coesione dell' interfaccia) con gli altri componenti del sistema. Esistono due sistemi desktop grafici per Linux: GNOME e KDE1. L' analisi che si effettuerà si baserà sostanzialmente su KDE. KDE è il progetto partito per primo (attualmente è alla versione 3.3), è quello che vanta maggiori consensi, è ritenuto più veloce e stabile, con un maggior numero di utenti e di sviluppatori, usa un toolkit più evoluto (le librerie QT della TrollTech). Sul sito di kde possiamo trovare un problem statement (Newman & Lamming 1995, p. 13), cioè un periodo che definisce l'oggetto del design: KDE is a network transparent contemporary desktop environment for UNIX workstations. KDE seeks to fill the need for an easy to use desktop for Unix workstations, similar to the desktop environments found under the MacOS or Microsoft Windows. [...] It is our hope that the combination UNIX/KDE will finally bring the same open, reliable, stable and monopoly free computing to the average computer user that scientist and computing professionals world-wide have enjoyed for years. Rileviamo quindi all’ interno del primo paragrafo le parti in cui si è soliti suddividere il problem statement: • Form of solution:“..is a network...desktop enviroment for UNIX workstation”. • Level of support: “to fill the need for an easy to use desktop”. • Supported activity: “..similiar to the desktop enviroments found under the MacOS...” E, nel secondo paragrafo: • Performers of activity (users): “...to the average computer user...” Lo scopo dichiarato è dunque quello di creare un ambiente desktop per UNIX facile da usare al pari di MacOS® o Windows® per l'utente comune. Bisogna dunque creare una interfaccia grafica a manipolazione diretta che consenta di effettuare tutti i tipi di task che gli utenti comuni sono abituati a svolgere con le altre interfacce che utilizzano la metafora della scrivania.

1.1 La metodologia di sviluppo di KDE
Il fatto che il sorgente di KDE sia liberamente disponibile e scaricabile da internet fa sì che in teoria chiunque abbia delle nozioni di programmazione sufficientemente avanzate possa apportare delle
1

KDE: acronimo per Kommon Desktop Enviroment (il Common Desktop Enviroment fu un tentativo di creare un' interfaccia grafica unificata per UNIX negli anni 80 dal consorzio OpenGroup)

3

modifiche al progetto, sottoporle al team ufficiale (più propriamente il maintainer, che è il programmatore che decide quale codice incorporare nel rilascio ufficiale della versione stabile di KDE) che ne vaglia la validità. Questo modello comporta vantaggi e svantaggi. Uno dei vantaggi è la disponibilità di centinaia di validi contributor per il codice. Inoltre vi è la convinzione che più persone hanno accesso al codice, più sarà veloce la ricerca di errori e la loro correzione. Tra gli svantaggi vi è il fatto che i contributi di numerosi sviluppatori possono avere difficoltà ad integrarsi tra di loro. A questo scopo è preposto appunto il mantainer del codice, ovvero colui che decide le feature da implementare nella versione corrente e quali contributi esterni al team adottare.

1.2 Analisi del modello di sviluppo di KDE
Il modello di sviluppo di KDE è abbastanza insolito. Nel mondo del software commerciale normalmente a ciascuno sviluppatore viene affidato un compito preciso da portare a termine, e ciascuno sviluppatore si concentra esclusivamente sulla parte dell' interfaccia di sua competenza attenendosi alle indicazioni date dagli esperti di usabilità. Come gli stessi sviluppatori di KDE dichiarano, più che un progetto preciso si preferisce avere tutte le volte un' implementazione funzionante del progetto. Dal momento che il sistema viene sviluppato da professionisti volontari non pagati, non è presente una gerarchia precisa in cui i quadri dirigenti decretano chi debba svolgere quale lavoro. Il miglior modo per favorire la creatività dei programmatori è lasciarli liberi di implementare liberamente le loro idee, e poi rifinirle attraverso più cicli di design. Questo causa una riduzione dell' efficienza, ma si ritiene che essa venga colmata dall' ampio numero di sviluppatori. In sintesi, i principi chiave dello sviluppo possono essere così riassunti: • fallo funzionare, subito! • focalizzare (si intende concentrarsi sul problema) • usa gli strumenti disponibili piuttosto che reinventare quelli esistenti • migliora con l'iterazione • comincia con delle funzionalità e configurabilità ragionevoli, e migliorale nel tempo.

1.2.1

Il processo a cascata

Il processo a cascata è un modello di progettazione con le seguenti caratteristiche: gli utenti si confrontano con il sistema solo alla fine della progettazione, quando il processo di design è terminato; i requisiti (l'enunciato che definisce cosa deve essere progettato, costruito e messo al servizio dell' utente) possono essere congelati per lunghi periodi, duranti i quali le necessità degli utenti possono essere cambiate. Inoltre è difficile che le esperienze accumulate possano influenzare il processo e i requisiti. Ecco come può essere rappresentato graficamente un processo di progettazione a cascata: Analisi dei requisiti Design Implementazione Validazione Rilascio e manutenzione 4

L'analisi dei requisiti comprende la definizione del problema da affrontare. Il design invece si occupa di come viene sviluppato l'artefatto atto alla soluzione del problema. L' implementazione è la fase in cui l'artefatto viene effettivamente realizzato. Nel nostro caso si tratta nella fase in cui avviene la stesura del codice in un linguaggio di programmazione (il C++). La validazione consiste in una fase di beta testing in cui il codice viene rilasciato pubblicamente, ma non come codice stabile, per cui il suo uso è sconsigliato in ambienti di produzione, nei quali non è proponibile l'uso di un sistema instabile. In questa fase vengono corretti soprattutto errori nel codice responsabili di crash, o problemi comunque gravi. Arrivati a questo stadio del processo è difficile che i programmatori siano disponibili a modificare il codice per risolvere problemi di usabilità; si tende soltanto a correggere i bugs più gravi, a seconda della priorità delle segnalazioni inserite in bugzilla (il sistema di gestione dei bugs adottato dalla comunità), che suddivide i bugs in sei categorie (dal più grave al meno grave): 1.critical 2.grave 3.major 4.crash 5.normal 6.minor 7.wishlist Normalmente si dedica più attenzione alle prime cinque categorie, mentre gli ultimi due tipi di bugs vengono generalmente tralasciati. In particolare il termine wishlist sta ad indicare i desideri degli utenti in fatto di funzionalità. Si tratta però di una classe di bugs che può contenere problemi di usabilità anche molto gravi che bisognerebbe correggere subito. Tuttavia queste segnalazioni vengono sottostimate perché si tratta appunto di segnalazioni degli utenti di cui i programmatori non riconoscono ancora la validità: in primo luogo perché può trattarsi di falsi problemi, inoltre perché è difficile che gli sviluppatori percepiscano il problema, dal momento che si tratta di una interfaccia che corrisponde al loro modello mentale. Anche se il team di sviluppo riconoscesse la presenza di un problema di usabilità l' analisi di una soluzione verrebbe posticipata nel prossimo processo di design, attendendo un feedback più consistente dagli utenti che utilizzeranno la versione stabile che presenterà comunque il bug. Nell' ultimo stadio del processo avviene dunque il rilascio della versione stabile e la manutenzione, cioè il rilascio di patch critiche inerenti la sicurezza del sistema. A prima vista può sembrare che lo sviluppo di KDE segua il modello di processo a cascata. Infatti è difficile che il codice che implementa nuove funzionalità venga corretto o rivisto in base al feedback ricevuto dagli utenti: vi è infatti una forte tendenza al conservatorismo all’ interno della comunità degli sviluppatori: difficilmente un programmatore permetterà che il suo codice venga rimosso o accetterà di modificarlo. Dalla sua ottica esso risponde al suo modo di operare, per cui richieste di cambiamento determineranno una risposta standard: “fix it yourself!”. Certamente proporre agli utilizzatori finali di modificare da sé il codice non è esattamente un approccio amichevole verso l’utente. Se si analizza l’arco di tempo che precede il rilascio di una singola versione del sistema il processo a cascata sembra essere il modello che meglio descrive lo sviluppo di KDE. Tuttavia il modello del processo a cascata presenta delle discrepanze con il modello del processo di KDE. Innanzitutto il processo a cascata prevede che l’analisi dei requisiti sia immutabile: questo presuppone che gli utenti sappiano descrivere con esattezza le loro necessità e quindi è possibile definire fin dalle prime fasi tutte le funzionalità che saranno implementate nel sistema. Questo è in netto contrasto con l’evidenza rilevabile analizzando i documenti del processo di sviluppo (mailing list innanzitutto): se si assume che gli utenti riescano a far percepire in modo corretto le loro necessità agli sviluppatori allora non si può spiegare come mai tra le varie versioni di KDE vi è 5

presente un gran numero di differenze sia nelle funzionalità che nel look&feel2 dell’ interfaccia grafica; questa ipotesi renderebbe vana la creazione di successive versioni corrette per adattarsi meglio alle necessità degli utenti. Ciò significherebbe che gli sviluppatori si adeguano fin da subito ai modelli mentali, mentre si evince che la prima cosa su cui si concentra il programmatore è la creazione di funzionalità, lasciando alla progettazione dell’ interfaccia una parte marginale del tempo a disposizione basandosi esclusivamente sulla propria percezione personale. Questo quindi non spiegherebbe tutto il feedback ricevuto dagli utenti in merito al design di KDE. Un altro assunto è che sia possibile progettare tutto il sistema senza aver scritto un sola linea di codice: questo è in palese contrasto con quanto detto sopra, in quanto generalmente si tende a creare codice senza condurre una analisi approfondita, in modo da avere a disposizione un prototipo funzionante da testare.

1.2.2

Il modello user centred design

Al modello del processo a cascata si contrappone il modello del processo User Centred Design (UCD).
Più cicli di design

Valutazione

Analisi dei requisiti Design/Redesign

Implementazione Validazione Implementazione La principale caratteristica del processo dell’ user centred design consiste nell’ esecuzione di più iterazioni per l’analisi dei requisiti: in questo caso essi non vengono percepiti come immutabili, ma possono essere messi in discussione e ridefiniti durante lo sviluppo del sistema. I requisiti possono essere individuati e descritti in forme dettagliate oppure in termini più generici; generalmente vengono distinti in due categorie: di alto livello e di basso livello. I requisiti di alto livello si occupano di descrivere le funzionalità che il sistema dovrà rendere disponibili agli utenti, quelli di basso livello descrivono le tecnologie e le modalità di implementazione che saranno adottate dagli sviluppatori. In generale nei sistemi a sorgente aperto l’ovvia tendenza è di dedicare maggior tempo alla definizione dei requisiti di basso livello e utilizzare una serie di periodi generici per la descrizione di quelli di alto livello, che verranno affinati nelle versioni successive del sistema. L’analisi dei requisiti si suddivide in due sottoprocessi: l’analisi dell’ attività e la definizione dei requisiti. L’ analisi dell’ attività ha lo scopo di individuare gli utenti per i quale è progettato il sistema, indagare l’attività e identificare il contesto d’uso. Nel caso di KDE i metodi più usati sono lo story telling e i focus group.
2

Per look&feel si intende l’aspetto esteriore dell’ interfaccia. Durante la prototipazione del look&feel ci si preoccupa soltanto delle caratteristiche estetiche, tralasciando la progettazione dell’ interazione e dell’ tecnologia che la rende possibile. Per una trattazione estesa dell’ argomento si veda Houde & Hill 1997.

6

Lo story telling è la raccolta di storie raccontate dagli utenti finali: in questo caso gli sviluppatori riuniscono i resoconti inviati dagli utenti che raccontano delle attività che svolgono con il sistema. Il focus group è un incontro tra i partecipanti al progetto, moderato da un mediatore. Dato che il mezzo di comunicazione più utilizzato dagli sviluppatori di KDE è internet si ha occasione di confrontarsi con mezzi come la mailing list.

1.2.3

Il rapid prototyping approach

Neanche il modello User Centred Design è adatto a descrivere il processo di sviluppo di KDE: esso prevede che l’iterazione effettuata per l’analisi dei requisiti e il redesign sia fatta all’ inizio del processo di sviluppo, prima di avere un prototipo completo sia per quanto riguarda il look&feel che per la struttura dell’ interazione e la tecnologia implementata: infatti come è si visto la tendenza è di scrivere subito codice funzionante appena si è avuta un idea piuttosto che testare le soluzioni sugli utenti finali, e posticipare la soluzione in un secondo tempo. Un modello di sviluppo che corrisponde più da vicino a quello di KDE è il rapid prototyping approach (Newman e Lamming 1995 p. 113). In alcuni casi per misurare tutti gli aspetti di usabilità è necessario costruire un prototipo funzionante: esso viene testato sugli utenti ed è trattato come la definizione del sistema. Il design viene migliorato valutando il prototipo e facendo dei miglioramenti direttamente su di esso. Quando il prototipo soddisfa il problema allora vengono definiti i requisiti (quelli che Newman e Lamming chiamano le specifiche del design).

Valutazione

Definizione del problema

Prototipo

Report di usabilità

Requisiti

Redesign

Tuttavia neanche questo modello corrisponde perfettamente a quello reale di KDE. Infatti nel modello appena visto il redesign e la costruzione di un nuovo prototipo sono attività strettamente legate tra di loro, soprattutto dal punto di vista temporale. Esse non portano alla creazione di un prototipo definitivo, ma solo alla definizione dei requisiti. In KDE invece la fase di redesign avviene effettivamente più volte, ma in un arco temporale più vasto che comprende il rilascio di nuove versioni che implementano le nuove soluzioni progettate in seguito al feedback ottenuto dagli utenti.

1.2.4

La proposta di un modello

A questo punto si può tentare l’elaborazione di un modello che rappresenti il processo di sviluppo di KDE basandosi sui modello già presi in considerazione.

7

Analisi dei requisiti

Design

Implementazione

Redesign

Validazione

Nuovi requisiti

Rilascio e manutenzione

Valutazione

Il processo inizia con l’analisi dei requisiti: questa fase comprende sia la scelta degli strumenti informatici che l’individuazione delle caratteristiche chiave del progetto e le attività che deve supportare. Il design comprende la fase in cui si definiscono sia le caratteristiche del codice (definizione di variabili, struttura delle classi e dei metodi) che quelle dell’ interfaccia. Immediatamente dopo si incomincia a scrivere del codice funzionante, che la cui stabilità verrà testata per correggere errori di programmazione. Alla fine il programma viene rilasciato come versione stabile e si correggono gli errori di programmazione che non sono stati individuati durante la fase di beta testing. A questo punto viene effettuata una valutazione del risultato ottenuto. Questa parte non coinvolge soltanto gli sviluppatori: anche gli utenti hanno un ruolo da svolgere in questa fase. Il feedback ricevuto da essi è vario e comunque sostanzioso. Gli utenti sottopongono o analisi informali di usabilità effettuate da loro stessi oppure descrizioni dei problemi che hanno incontrato. Da questi risultati vengono individuati nuovi requisiti che specificano meglio l’attività dell’ utente e portano ad una riprogettazione del sistema che viene implementata nella nuova versione di KDE, che viene ampliato e migliorato attraverso più iterazioni di queste operazioni.

8

2 L'activity theory: introduzione
L’activity theory è un framework di ricerca utilizzabile nel campo dell’ interazione uomomacchina3 che si basa sugli studi della psicologia storico-culturale compiuti da Vigotsky durante gli anni venti e trenta del novecento. I suoi studi sono stati continuati da Leontiev, che per primo ha usato il termine activity. In breve, l’activity theory è un framework interdisciplinare per lo studio delle attività umane viste come processi di sviluppo, in cui i livelli individuali e sociali sono in relazione tra loro. Essa è stata spesso criticata per la difficoltà della sua applicazione in casi studio reali, tuttavia è utile nel nostro caso, poiché essa è stata concepita con lo scopo di descrivere l’attività umana invece che predirla. Essa analizza la pratica, cioè il fare e l’attività. In senso stretto essa non è una teoria vera e propria, quanto un insieme di principi base che costituiscono un sistema concettuale che può essere usato per sviluppare teorie più specifiche.

2.1

Concetti chiave

L’attività è l’unita base di analisi: nella psicologia tradizionale le azioni umane vengono percepite come isolate. Secondo l’activity theory invece esse devono essere sempre inserite in un contesto per avere significato; l’attività (o activity) è l’unità di analisi nella quale è presente un contesto: essa non può essere capita senza la comprensione del ruolo svolto dagli artefatti nella pratica di ogni giorno. In termini più semplici l’attività può essere definita come l’impegno che un agente umano, definito soggetto, mette verso uno scopo definito come oggetto.

2.1.1

La mediazione

Normalmente in natura l’attività non è mediata: l’azione tra il soggetto e l’oggetto è diretta e non comprende l’utilizzo di strumenti. Nella maggior parte dei contesti umani invece le attività vengono mediate da strumenti stabiliti dalla cultura: procedure, linguaggi o artefatti fisici che fungono da mediatori tra il soggetto, cioè colui che compie l’attività, e l’oggetto, che ne è il fine o scopo, per ottenere un risultato. L’oggetto non è manipolato direttamente dal soggetto ma attraverso l’artefatto e i limiti che esso comporta. L’artefatto stesso, come l’attività, è passibile di evoluzioni che consentono di superare i limiti precedentemente imposti, in modo da ristrutturare l’attività. Il triangolo di mediazione semiotica rappresenta questa relazione: Artefatto

Soggetto

Oggetto

Outcome (Risultato)

Come si vede la relazione tra il soggetto e l’oggetto non è diretta (linea tratteggiata), ma è mediata da uno strumento o artefatto, che può essere sia esterno (mouse, periferiche varie) che interno (concetti o euristiche). Cerchiamo di analizzare la mediazione inquadrandola nell’ ambito di KDE. Come già detto il soggetto che dovrebbe avere a che fare con KDE è un utente comune che non ha una cultura informatica particolare. Il suo scopo, ad esempio, può essere la gestione dei suoi documenti attraverso un file manager: in questo caso Konqueror, che è l’artefatto per la gestione dei file.

3

L’activity theory è applicabile, oltre che all’ interazione uomo-macchina, anche nell’ antropologia, nelle scienze sociali, nella ricerca culturale, l’educazione e i progetti scientifici.

9

Konqueror

Utente

documenti

La visione di uno sviluppatore si rivela differente. Lo sviluppatore tende a inserire più funzionalità possibili al fine di dimostrare la propria capacità tecnica. Da questo punto di vista quello che per un utente comune è il mezzo o artefatto, per un programmatore è il punto di arrivo per ottenere come risultato approvazione sociale all’ interno della comunità di sviluppo.

Strumenti per lo sviluppo

Sviluppatore

Konqueror

Approvazione sociale

Quella che si vede è effettivamente la struttura dell’ attività che qualunque programmatore ha durante la fase di sviluppo. Il problema in questo caso specifico consiste nel fatto che questa visione permea anche la fase di sviluppo dell’ interfaccia durante la quale il risultato non dovrebbe essere l’implementazione di tutte le funzionalità che si vorrebbero, ma la creazione di una interfaccia usabile da utenti comuni.

2.1.2

La consapevolezza

L’activity theory si concentra sullo sviluppo e sulla funzione della consapevolezza individuale (consciousness). Vigotsky (cit. in Nardi 1995, p.17) definisce la consapevolezza come un fenomeno che unifica attenzione, intenzione, memoria, ragionamento e discorso. Un essere umano non interagisce mai direttamente con l’ambiente, ma per mezzo di artefatti , che possono essere segni o strumenti. Interagendo con altri esseri umani durante le attività comuni l’individuo internalizza i mezzi della cultura: norme, modi dell’ azione, artefatti tecnici. Quindi la consapevolezza non è un insieme di atti cognitivi separati e non è situata all’ interno dell’ individuo, ma durante l’interazione, nella pratica quotidiana. Cerchiamo di chiarire quale è il rapporto tra la consapevolezza ed una interfaccia grafica: una interfaccia viene definita trasparente quando essa supporta l’attività dell’ utente e non ne richiede l’attenzione, non è intrusiva. Gli utenti esperti di un sistema operativo o di una interfaccia dispongono di skill o abilità affinate e perfezionate con la pratica, grazie alle quali sono in grado di interagire in modo fluido con il sistema. Gli utenti inesperti non dispongono di abilità così sviluppate, quindi la loro interazione non sarà fluida e automatizzata come per gli utenti più esperti, ma richiederà la loro attenzione per eseguire una serie di operazioni che con il passare del tempo diventeranno sempre più automatizzate, utilizzando meno risorse cognitive per l’uso dell’ interfaccia e riservandone altre per concentrarsi sull’ attività vera e propria. Poniamo che un utente abituale di Windows® venga a contatto per la prima volta con KDE: la sua esperienza con il sistema operativo che utilizza di solito gli suggerisce di cliccare su un pulsante in basso a sinistra per scorrere la lista dei programmi. In quel punto dello schermo è abituato a trovare il pulsante “start”. In KDE il posto viene occupato da un pulsante di dimensioni più grandi con una “K”, la cui funzione è esattamente la stessa. L’ utente potrebbe avere fatta propria la regola secondo la quale il pulsante in basso a destra apre l’elenco delle applicazioni, e quindi potrebbe eseguire la 10

stessa operazione anche in KDE senza porsi ulteriori problemi. Nel caso in cui l’utente avesse memorizzata l’azione in modo più specifico egli potrebbe andare alla ricerca di un pulsante in basso a sinistra con la scritta start: in questo caso l’ operazione non è più automatica; l’utente potrebbe scegliere di procedere per prove ed errori, oppure semplicemente bloccarsi. In questo caso se avesse scelto di procedere, allora avrebbe comunque ottenuto il risultato che si attendeva dalla sua operazione, e avrebbe potuto procedere con la sua attività. In un altro caso l’utente potrebbe non essere in grado di individuare subito la parte dell’ interfaccia che corrisponde all’ operazione che vuole intraprendere. Prendiamo ad esempio un elaboratore di testi. Le voci che prevedono l’inserimento di particolari tipi di testo come le note a piè di pagina si trovano nel menù inserisci. Quando si vuole inserire un elenco numerato tocca invece andare a selezionarlo nel menù formato. Un utente potrebbe trovare più naturale andare ad esplorare il menù inserisci, e dovrebbe quindi spostare il focus sulla ricerca della voce desiderata che si trova altrove; in questo caso l’utente ripeterà l’errore fino a quando la procedura verrà codificata e automatizzata in maniera soddisfacente. Un problema di usabilità più grave si viene a creare quando compare uno step non previsto che richiede ogni volta l’attenzione dell’ utente. Un errore di questo genere è presente nella funzionalità di drag&drop di KDE, che tuttavia viene segnato come “feature”. Normalmente quando si effettua il drag&drop con uno o più file questi vengono copiati se la loro destinazione è una unità di memoria esterna a quella in cui si trovano, spostati se invece l’unita di destinazione è la stessa di quella di origine. In KDE invece al momento del trascinamento viene aperto un piccolo menù accanto all’ icona rappresentante la destinazione che chiede di scegliere tra l’operazione di spostamento o quella di copia. Finché l’utente non seleziona una delle due opzioni non viene effettuata alcuna operazione. In questo caso l’attenzione dell’ utente viene spostata su una operazione non prevista che non può essere automatizzata, perché richiede ogni volta di scegliere l’opzione desiderata. L’unica alternativa per evitare il menù è utilizzare i tasti shift e control durante l’operazione di trascinamento rispettivamente per la copia e lo spostamento, ma si tratta di una caratteristica documentata solo nel manuale e nella guida in linea.

2.1.3

Lo sviluppo

Un altro punto fondamentale è lo sviluppo: le attività hanno una propria storia, esse mutano e si evolvono con il passare del tempo: la creazione e l’evoluzione di un nuovo artefatto amplia l’orizzonte dell’ attività, permettendo così di raggiungere obiettivi altrimenti inarrivabili. Cerchiamo di comprendere come si sia sviluppata l’attività di un utente di KDE che ne abbia fatto uso sin dalle versioni preliminari. Si provi a pensare al passaggio dalla riga di comando ad un sistema con una interfaccia grafica: dal punto di vista dell’ utente comune si è passati da una interfaccia testuale, che richiede un periodo di apprendimento sia per la sintassi che per la semantica del linguaggio, ad una interfaccia grafica a manipolazione diretta decisamente più intuitiva, dopo aver compreso i principi base del suo funzionamento: questo ha permesso di passare da una situazione in cui l’utilità del sistema era praticamente nulla in una situazione in cui l’utente aveva almeno compreso in che modo interagire con il sistema e riceverne un ritorno in termini di produttività. Poiché le versioni preliminari avevano un set di funzionalità estremamente ristretto la possibilità di utilizzarlo come sistema desktop erano molto limitate: non era possibile utilizzare realmente KDE per eseguire una attività il cui oggetto fosse esterno al computer stesso. Le prime versioni di KDE non costituivano una interfaccia completa come nelle versioni attuali o come sono state le interfacce proprietarie fin dalla prima versione: si trattava di un window manager, ovvero di un programma che permetteva di visualizzare più terminali e applicazioni grafiche non integrate tra di loro, in modo da rendere più agevole l’amministrazione del computer stesso, poiché si trattava di sistemi adibiti ad uso server piuttosto che desktop; la gestione stessa del computer costituiva l’attività, invece che essere lo strumento per il raggiungimento di uno scopo esterno. In seguito invece lo sviluppo di ulteriori applicazioni, l’implementazione di nuove 11

funzionalità, la maggiore attenzione verso l’utente e l’usabilità ha reso possibile l’esecuzione di ulteriori attività il cui scopo non ha relazioni dirette con il sistema, che ne costituisce soltanto l’artefatto.

2.1.4

La struttura dell' attività

Si è detto che l’attività è l’unità base dell’ analisi dell’ activity theory: essa è il contesto nel quale le azioni acquisiscono significato. Questo però non vuol dire che essa sia un’ unità inscindibile. Infatti l’oggetto a cui si indirizza l’attività viene trasformato in un risultato (outcome) attraverso varie fasi. Le attività vengono realizzate da uno o più soggetti che condividono lo stesso oggetto o fine eseguendo azioni (actions) consapevoli che hanno uno scopo (goal) immediato, ma che non possono essere comprese al di fuori del quadro di riferimento creato dall’ attività. Una attività può essere eseguita attraverso differenti azioni a seconda della situazione; d’altra parte le azioni possono appartenere a differenti attività: in questo caso le azioni avranno un significato diverso per la persona che le esegue, a seconda dello scopo prefisso dall’ attività. Tuttavia le azioni, che sono processi consapevoli, devono essere pianificate consapevolmente usando un modello, in una fase che viene chiamata orientamento (orientation). Il modello adottato per l’esecuzione delle azioni non è rigido e immutabile, bensì incompleto, poiché si procede per tentativi. Le azioni non sono unità inscindibili, ma sono formate da catene di operazioni (operations), eseguite a livello inconscio. Il fine di una operazione è il raggiungimento di condizioni necessarie per passare all’operazione successiva. Inizialmente, quando il soggetto non possiede skill sufficientemente mature per l’esecuzione dell’ azione, le operazioni sono eseguite consapevolmente. Quando il modello dell’ azione è consolidato e il soggetto ha acquisito sufficiente esperienza, le operazioni vengono automatizzate ed eseguite ad un livello inconscio: viene quindi creata una azione con uno scopo più esteso, formata da operazioni come sotto-parti. Le azioni e le operazioni formano quindi i livelli gerarchici dell’ attività.

ATTIVITA’

MOTIVO

AZIONE OPERAZIONE

FINE CONDIZIONE

Si può comprendere come il confine tra azioni e attività non sia netto ma sfocato: lo scopo di una attività può essere perso di vista e diventare una azione; a sua volta una operazione può essere trasformata in una azione nel caso in cui il modello adottato si riveli inadatto e non si verifichino le condizioni previste per il successo delle operazioni. Un altro assunto fondamentale è l’internalizzazione-esternalizzazione: il soggetto e l’oggetto dell’ attività sono in una relazione reciproca: il soggetto influisce sull’ oggetto per mezzo dell’ artefatto; l’oggetto penetra nel soggetto e lo trasforma. Per chiarire meglio il rapporto tra i tre livelli dell’ attività portiamo un esempio completo, facendo riferimento a KDE.
Livelli dell' attività LIVELLO DELL’ ATTIVITA’

Motivo

Gestire la posta elettronica

12

Fine LIVELLO DELL’ AZIONE Usare una applicazione che consenta l’invio di
testi, video e altri contenuti, scrivere messaggi testuali

Condizione LIVELLO DELL’OPERAZIONE
Usare la tastiera per l’immissione di testo, usare il mouse per accedere alle funzionalità del programma.

Più operazioni vengono eseguite inconsapevolmente senza dedicargli attenzione, dal momento che esse sono altamente automatizzate; queste vanno a formare una azione; più azioni concorrono a formare una attività. Le attività non sono dunque statiche, ma dinamiche: lo sviluppo si verifica a tutti i livelli; nuove operazioni sono formate da azioni precedenti quando le skill dell’ utente aumentano; lo scopo delle azioni si allarga, e azioni totalmente nuove sono inventate e vengono sottoposte a verifica per testarne l’efficacia; le attività a loro volta espandono il loro oggetto o motivo.

2.2

La rappresentazione degli errori

Gli errori o disguidi che si verificano tra gli elementi all’ interno di una attività o tra diverse fasi di sviluppo di una singola attività vengono chiamati contraddizioni (contradictions): si tratta di rotture, problemi, breakdown. Un breakdown si verifica quando il lavoro viene interrotto: è possibile che lo strumento non abbia funzionato secondo le aspettative dell’ utente: in questo caso lo strumento diventa l’oggetto delle nostre azioni; il nostro fine è quello di far sì che esso risponda in maniera adeguata. Si tratta quindi di un errore dovuto al malfunzionamento di una applicazione. Un focus shift è un cambio dell’ oggetto intenzionalmente dovuto all’ utente, che avviene spesso durante l’addestramento. A questo punto ci si può chiedere come l’activity theory può essere utilizzata nell’ analisi di tecnologie informatiche e di KDE in particolare. Innanzitutto la tecnologia, in particolar modo quella informatica, ha avuto da principio lo scopo di automatizzare le operazioni: in questo modo essa può diventare parte di una attività e ampliare lo scopo delle azioni eseguibili dagli utenti. A livello delle attività può flessibilizzare una attività o rendere possibile il raggiungimento di un obiettivo altrimenti inarrivabile. Ovviamente questo è lo scopo che qualunque artefatto vorrebbe raggiungere; un artefatto può anche irrigidire una attività cambiandone la forma: se da un lato l’artefatto abilita delle funzioni ne limita anche delle altre. Fin dall' inizio i computer sono stati utilizzati per permettere l’automatizzazione di operazioni: ci si chiede se è possibile allo stesso modo supportare la formazione di azioni: è lecito chiedersi se ci siano stati casi in cui la formazione di nuove operazioni eseguite inconsciamente, partendo da vecchie azioni, abbia favorito il raggiungimento degli scopi allargati di nuove azioni. Questa dinamica operazione-azione dovrebbe essere una prerogativa di tutti gli applicativi di computer. Tuttavia questo si è verificato in casi assai rari. Qualcosa del genere avviene in programmi che hanno scorciatoie per utenti esperti, oppure nel caso dei comandi da tastiera digitabili in sistemi operativi UNIX, che possono interagire tra di loro tramite vari operatori, o linguaggi di scripting per suite da ufficio (come VBA per MS Office) che consentono di automatizzare in un una operazione processi che richiederebbero più fasi. Questi esempi non sono soddisfacenti per la realizzazione di una dinamica operazione-azione: infatti si tratta di operazioni che non hanno nulla in comune con le operazioni originarie; non si tratta del collasso di una azione conscia in una operazione automatizzata. Non si tratta di un percorso naturale che si percorre acquisendo maggiore esperienza, bensì di un ulteriore processo di apprendimento. Per supportare la dinamica operazione-azione in 13

maniera adeguata è necessario che la fase di orientamento si mimetizzi, ma che il feedback della vecchia azione sia ancora presente per dare il via alla prossima operazione. E’ possibile portare questa dinamica all’interno di una interfaccia grafica? Si potrebbe verificare se in KDE questa cosa sia stata resa possibile, dal momento che essa presenta al suo interno tracce del mondo UNIX: si tratta effettivamente di una dinamica operazione-azione, o semplicemente della presenza di elementi confusi all’ interno di una interfaccia non ancora perfettamente coerente? Quali sono le differenze tra la visione di KDE degli sviluppatori e quella degli utenti finali? Condividono davvero lo stesso oggetto o motivo? Un utente abituato ad usare una interfaccia Windows riuscirebbe a mantenere la sua attenzione sull’ attività che sta svolgendo, o dovrebbe ripetere la fase di orientamento per certe operazioni che in KDE non hanno successo come su Windows? Quali difficoltà incontrerebbe e a cosa sarebbero dovute: quali sarebbero le cause di eventuali breakdown o focus shift? Nel caso in cui una persona scegliesse di adottare KDE come interfaccia grafica per il suo computer, sarebbe necessario un addestramento? Vi sono tante domande a cui si è tentato di dare risposta. Vari studi, effettuati da persone con diversi background culturali (soprattutto informatici di professione, assai più raramente di esperti di usabilità) hanno tentato sottoporre ad indagine l’interfaccia di KDE, ma senza basarsi su un framework preciso con il quale analizzare i risultati ottenuti. Quando si tratta di valutare interfacce complesse è difficile effettuare una analisi progettando un esperimento controllato o anche un quasi esperimento4. La complessità e il grande numero di variabili da tenere sotto controllo restringerebbe eccessivamente il campo di indagine, impedendo una valutazione sufficientemente ampia, o costringerebbe a creare un disegno sperimentale estremamente complesso. Per questi motivi non resta che usare un approccio più informale, ma basandosi sempre su un framework come l’activity theory per analizzare i risultati.

2.3 Il metodo di analisi
Bødker (1995) propone un metodo per la rappresentazione e l’analisi dei focus shift che si basa sulla video analysis; per capire in quali situazioni essi possono verificarsi è opportuno distinguere differenti aspetti delle applicazioni per computer basati sulla caratterizzazione dei differenti focus nell’ attività in questione: • L’aspetto fisico: gli aspetti fisici sono le condizioni per la manipolazione degli artefatti in quanto oggetto fisico. A questo livello i focus shift si verificano quando la presenza di una componente fisica inadatta impedisce la formazione di certe operazioni. • Gli aspetti della manipolazione (handling aspects): riguardano il supporto per le operazioni verso l’applicazione; a questo livello la presenza di un breakdown sposterà l’attenzione dell’ utente dall’oggetto verso l’artefatto. Riguardano le condizioni per la trasparenza dell’ artefatto che permette all’ utente di concentrarsi sugli oggetti reali. • Gli aspetti diretti verso il soggetto/oggetto: riguardano le condizioni per le operazioni dirette verso gli oggetti o i soggetti che affrontiamo nell’ artefatto o attraverso esso. Nel caso di KDE, trattandosi solamente di una interfaccia, la maggior parte dei focus shift riguarderanno gli aspetti della manipolazione e del soggetto/oggetto. Bødker ha utilizzato la video-analisi, combinando così studi etnografici con l’analisi dell’ interazione: una annotazione cronologica degli eventi della registrazione video fornisce una descrizione e una cronologia degli eventi osservati. Successivamente si procede con la trascrizione delle sequenze dell' attività di particolare interesse, concentrandosi nei punti in cui si verificano focus shift e breakdown. A questo punto viene effettuato un mapping dell’ attività: ciò consiste nel tracciamento di una griglia nella quale in una dimensione vengono riportati gli oggetti sui quali si è
4

Si ha un esperimento controllato quando lo sperimentatore ha il pieno controllo su tutte le variabili. In un quasi esperimento invece lo sperimentatore non può controllare l’assegnazione dei soggetti alle condizioni: essi sono selezionati da gruppi già esistenti (McBurney 1995, pag. 319)

14

focalizzato l’utente, nell’ altra una descrizione dell’ evento supportata da una trascrizione delle parole del soggetto. I focus shift vengono rappresentati come punti che si spostano da un oggetto all’ altro. A titolo esemplificativo inseriamo il caso riportato da Bodker per l’analisi di VIRK, un programma per la generazione di report usato dall’ ispettorato del lavoro danese.

Per supportare una analisi di questo tipo, basata su focus shift e breakdown, Bodker propone una checklist: per ogni focus ci si deve chiedere: • Qual è lo scopo dell’ attività (o delle azioni) per l’utente? • Quale oggetto viene focalizzato dall’utente? Dove può essere localizzato (all’interno dell’applicazione, al suo esterno o nel mezzo?) • Qual è lo strumento? Dove può essere localizzato (all’interno dell’applicazione, al suo esterno o nel mezzo?) Una analisi estesa e completa di KDE richiede una lunga serie di test, poiché non si tratta di una applicazione, ma di un intero sistema desktop composto da più applicazioni che interagiscono tra di loro. Una soluzione è creare un numero ridotto di test che comprendano al loro interno l’uso e l’analisi del maggior numero di componenti (menù, dialoghi, pannelli). Lo scopo non è quello di testare l’utilizzo di una singola applicazione in modo da poter valutare l’attività che viene compiuta per mezzo di essa, ma di testare KDE cercando di includere più aspetti possibili dell’ interfaccia, facendo compiere al soggetto una attività che lo metta a confronto con quasi tutte le funzionalità e caratteristiche di KDE. Il quesito che ci si pone è: una persona abituata all’ uso di una interfaccia come windows o macos può compiere le stesse azioni senza doverle ristrutturare? Le operazioni saranno ugualmente valide? L’uso di KDE come artefatto per il raggiungimento di vari scopi è trasparente come per altre interfacce proprietarie? Se ci sono problemi o breakdown, in che punto dell’ attività sono localizzabili e a cosa sono dovuti? Per effettuare questo genere di analisi, basandosi sull’ activity theory e seguendo la metodologia proposta da Bodker, è una buona idea usare la tecnica degli scenari.

15

2.4 Scenari: tecniche d’uso
Gli scenari permettono viste multiple di una interazione, diversi generi di dettagli. Possono essere astratti e categorizzati: possono essere utili nella fase di design per riconoscere e catturare le generalizzazioni. Essi hanno il pregio di promuovere le comunicazioni tra tutti coloro che vengono coinvolti nel processo di design, in modo che le attività di design risultino più accessibili a vari generi di expertise. Nel design basato sugli scenari la rappresentazione lavorativa del design è formata dalla descrizione di come le persone eseguono dei task. Gli scenari sono descrizioni che documentano tipiche attività prima che esse abbiano luogo nella realtà. Essi mettono in luce gli scopi suggeriti dal comportamento del sistema. Sono quindi ideali per indirizzare l’utente verso l’investigazione dell’ interfaccia senza predeterminare le sue scelte nell’azione. Ovviamente per operare una investigazione su vaste aree di expertise è necessaria la formulazione di più scenari differenti per setting (il setting rappresenta uno stato iniziale per l’episodio descritto) e per agenti (agents o actors, cioè persone reali coinvolte nello svolgimento delle azioni.) che perseguono degli scopi o objectives (terminologia analoga a quella impiegata nel framework dell’ activity theory). All’ interno degli scenari si possono raggiungere dei subgoal: si tratta cioè di sottoscopi corrispondenti alle actions definite nell’ activity theory. Dal momento che ogni scenario ha una trama o plot, all’ interno includono varie possibilità di azione: alcune possono essere irrilevanti per lo svolgimento dell’ attività, altre possono costituire delle contraddizioni. Come evidenzia Carrol azioni ed eventi possono spesso cambiare gli scopi di uno scenario. E’ evidente quindi di come la tecnica dello scenario sia particolarmente adatto per una analisi basata sul framework dell’ activity theory. Dopo la formulazione di scenari d’uso, è possibile evolverli in prototipi, attraverso varie rappresentazioni come storyboard o video (quindi anche studi etnografici). In seguito, durante l’analisi dell’attività gli scenari possono essere astratti usando teorie dell’attività umana (come, per l’appunto, l’activity theory). Uno scenario può essere doppiamente utile, sia per la revisione del design che per la valutazione dell’ approccio formativo. Lo scenario sarà fondamentale per l’analisi del sistema preso in esame, poiché non espone soltanto le funzionalità del sistema (cosa comunque necessaria per la pianificazione delle funzionalità da implementare), ma come l’utente vi accederà e cosa sperimenterà, esplorando gli scopi che l’utente adotta. Da questo punto di vista lo scenario non è una lista astratta di scopi o di requisiti, ma una unità nella quale essi acquisiscono un senso per l’utente. Gli scenari sono quindi particolarmente adatti per mettere in discussione il design, poiché predicono alcuni dettagli grezzi sui compiti da eseguire, lasciando all’ utente la scelta delle sue interazioni a basso livello e la definizione dei dettagli. Gli scenari sono particolarmente utili all’ interno di un gruppo di design instabile e non formalmente organizzato come quello di KDE, dal momento che i requisiti tendono a variare con frequenza, poiché gli scenari sono accessibili a vari stakeholders o membri del team, sia che si tratti di persone che hanno una posizione definita nella gerarchia di sviluppo che di contributor non stabili; gli scenari permettono di stabilire un quadro di insieme dei task eseguibili dall’ utente nonostante la frequenza dei cambiamenti dei requisiti. Una importante testimonianza a favore del processo di sviluppo di KDE ci viene da Ackoff (cit. in Carrol 1999) , che ha coniato la definizione di idealized design, cioè un processo di pianificazione del sistema nel quale i designer rimpiazzerebbero il sistema se fossero liberi di farlo: un processo così organizzato incrementa la partecipazione tra i membri del team, è un modo per concentrarsi sulle articolazioni delle possibilità e la discussione delle conseguenze. Nelle prime formulazioni degli scenari le relazioni causali tra le entità dei casi presenti nelle situazioni d’uso vengono lasciate implicite; tuttavia può essere necessario renderle esplicite nei cicli successivi nel caso in cui si verifichino contraddizioni o errori per fornire una visione ulteriormente specificata. In tal modo, grazie alla flessibilità degli scenari, è possibile focalizzarsi o spostarsi su prospettive di design differenti: ad esempio spostarsi dal design delle interazioni a quello visuale (riconoscimento icone, nomenclature e simili). 16

Affinché via sia una esperienza di apprendimento le attività e le scoperte devono avere un senso per l’utente e devono supportarne gli obiettivi: durante il testing l’utente vuole usare cose che conosce già, in modo da poter valutare criticamente quello che imparano e le nuove abilità acquisite. Questo sembra essere stato tenuto in conto nella progettazione di KDE in quanto nonostante non si sia trattato di una clonazione di interfacce precedenti, non si è voluto rompere il legame con comportamenti e conoscenze già cristallizzati.

17

3 Studi precedenti
Come si è detto uno dei punti più deboli del software sviluppato secondo la metodologia OSS è il mediocre livello di usabilità raggiunto a causa della propensione degli sviluppatori a scrivere applicazioni ed interfacce per programmatori, ponendo in prima linea le caratteristiche tecniche e tralasciando la costruzione di interfacce di buon livello, basandosi sull’ uso linee guida generali e escludendo un processo di testing per l'interfaccia alla pari di quello effettuato per il codice. Questo è reso difficile dal fatto che essendo lo sviluppo di software OSS distribuito attraverso internet è difficile creare e coordinare test con utenti reali. Inoltre la partecipazione di esperti di usabilità è resa difficoltosa dal fatto che generalmente i programmatori sono poco propensi ad accettare suggerimenti da chi non è in grado di scrivere codice, preferendo dedicarsi al bugfixing delle funzionalità del programma. Quindi restano scarsi anche i tentativi di creare dei test di usabilità affidabili. Alcuni test sono stati effettuati su componenti marginali e scarsamente usati di KDE, mediante l'uso di guide linea e comunque mai con l'ausilio di utenti reali. Carente invece è sempre stata l'analisi del centro di controllo, componente delicato e soggetto a varie critiche, per cui si prevede un restyling nella quarta versione di KDE.

3.1

The Linux Usability Study – Relevantive AG

Il più noto tentativo di effettuare un' analisi con una prospettiva più ampia, dedicandosi alla quasi totalità dei componenti di KDE è il “Linux Usability Report Study” (http://www.relevantive.de), effettuato con utenti reali dalla AG Relevantive, una azienda di consulenza e design tedesca che ha messo alla prova KDE e Microsoft Windows XP, sottoponendo a test di usabilità 60 utenti su un sistema con KDE 3.1.2 e 20 utenti su Windows XP come gruppo di controllo. Un così alto numero di utenti, ottanta in totale, è stato voluto per differenziare la tipologia di utenti. E’ opportuno specificare che un test di questo genere non ha lo scopo di trovare problemi, bensì di rilevare differenze statisticamente significative nell’ uso di diverse intefacce. Come si legge nel preambolo, lo studio indaga su quanto siano usabili applicazioni desktop su Linux, come una forte attenzione sull’ uso nelle aziende e nelle pubbliche amministrazioni. Un questionario preliminare è servito per rilevare le competenze precedenti. Sono seguiti i test veri e propri, realizzati tramite la tecnica degli scenari, con il moderatore disponibile a dare aiuto nel caso l'utente non fosse in grado di completare il compito. Tutti i test sono stati condotti come una intervista faccia a faccia. Il moderatore ha introdotto i test ai soggetti e vi è stato vicino durante tutto il tempo dell’ esperimento. Durante l’esecuzione il moderatore ha preso nota dei problemi rilevati, gli approcci dei partecipanti, gli errori e i task non completati.

3.1.1

Lo svolgimento dell’ esperimento

I soggetti sono stati così introdotti all’ esperimento: “Immagina che nuovi computer con un nuovo sistema operativo siano stati introdotti nella tua azienda. E’ il tuo primo giorno di lavoro con il sistema”. Gli è stato poi consegnato un foglio con le proprietà specifiche del sistema, principalmente: • Il nome utente e la password per l’accesso • Il percorso della cartella per i documenti personali • La segnalazione della presenza di un drive per cd-rom • Il nome dei programmi più usati durante il test • Il fatto che le applicazioni e le impostazioni possono essere trovate premendo la “K” nell’ angolo il basso a sinistra, facente la funzione del solito pulsante di “start” o avvio. L’esperimento prevedeva che si creasse una situazione simile a quella di una azienda. Questo significa che gli utenti hanno una competenza generale nell’ uso di windows, che non hanno diritti amministrativi sul computer (non è quindi possibile applicare modifiche all’ impostazione del 18

sistema); il computer viene assegnato dopo essere già stato configurato, il suo uso è generalmente ristretto a una serie di applicazioni specifiche, e gli utenti possono usufruire del supporto tecnico se si verificano problemi. I task sono stati scelti cercando di coprire tipici compiti da ufficio: in genere si trattava di avviare delle applicazioni e di avere a che fare con finestre di dialogo del sistema, impostazioni e accesso a unità removibili e stampanti. Il tempo previsto per lo svolgimento di tutti i task, stabilito con un test preliminare, è di circa un’ora: nel caso il tempo impiegato fosse stato di più, allora il punteggio sarebbe stato più basso. I task da eseguire erano: 1. Configurare il salvaschermo 2. Usare un’ applicazione di videoscrittura per la battitura di un breve testo da formattare, salvare e mandare in stampa. 3. Ascoltare un cd e impostarne il volume di ascolto 4. Operare con dei file e delle cartelle (creazione e copia) 5. Ricercare e ordinare dei file secondo criteri già assegnati 6. Masterizzare dei file su un cd 7. Caricare delle immagini e impostarle come sfondo del monitor 8. Impostare un programma per la visualizzazione di file in formato .pdf 9. Scrivere una mail ad un soggetto i cui dati sono inseriti nella rubrica, e allegare un file 10. Ricevere una mail che contiene accordi per un appuntamento e dare un’ occhiata all’ organizer per vedere se si è liberi per quella data: in caso affermativo prendere nota nell’ organizer. La valutazione è stata effettuata su dati quantitativi (tempi e questionari), oltre alle registrazioni fatte dai moderatori.

3.1.2

La valutazione dei risultati

I risultati sono stati analizzati tenendo conto dei tempi di risposta come variabile dipendente. Da questi sono derivate le distribuzioni di frequenza per i vari task, unico dato di natura statistica. In seguito sono stati raccolti i risultati dei questionari somministrati all’ utente dopo l’esperienza con KDE, che chiedevano di dare un giudizio sulla difficoltà dei compiti assegnati e giudizi qualitativi sulla gradevolezza dell’ interfaccia e dell’ uso che erano riusciti a farne. Oltre ai dati ottenuti dagli utenti sono stati utilizzati i dati rilevati dalle annotazioni dei moderatori, riguardanti le difficoltà degli utenti. Grazie a questi dati sono stati elaborati dei suggerimenti generici per il design, riguardanti la classificazione dei problemi e le loro possibili soluzioni. I problemi rilevati riguardano, oltre che mancanze nella progettazione generale dell’ interfaccia, giudicata troppo povera per casi come quelli dell’ organizer integrato, problemi legati soprattutto alle voci e alla nomenclatura utilizzata per menù, dialoghi, struttura dei menù e altre parti dell’ interfaccia. In questo caso i nomi utilizzati si sono rilevati o fuorvianti in quanto non era possibile associarvi l’azione collegata, o ancora legati a livelli inferiori del sistema operativo, e quindi contenenti termini tecnici non facilmente comprensibili.

3.1.3

Gruppi di utenti

Il vantaggio principale di questo studio, oltre ad ottenere indicazioni utili per un redesign delle applicazioni, è stata la categorizzazione degli errori ottenuti in base alle categorie di utenti rilevate durante la fase di test. Gli utenti sono stati classificati in tre categorie: • Utenti inesperti: questo genere di utenti non è in grado di distinguere tra vari sistemi operativi, interfacce desktop e applicazioni. Infatti la loro inesperienza è tale da non consentirgli di identificare un programma in base a certe sue funzioni particolari: questo può essere d’aiuto nel caso ci si trovi davanti ad un sistema che non sia quello che per tutti gli 19

altri è quello riconosciuto come universale, in quanto non è necessario ristrutturare le proprie azioni, poiché esse sono ancora sotto forma di operazioni non ben formate, data la poca esperienza dell’ utente. Le abilità di questi utenti sono state acquisite in sistemi eterogenei tra di loro, con una limitata libertà d’uso e un parco di applicazioni ristretto. Essi tendono ad usare soprattutto menù di programma e menù contestuali solo dove essi erano già usati prima, ma non in altri contesti. Per esempio, un utente può essere consapevole della possibilità del drag&drop, cioè dello spostamento dei file trascinandoli in altre finestre, all’ interno del file manager, ma non sa che è possibile usare questo principio in altri contesti, come aprire un file trascinandolo sopra un’ applicazione. Questi utenti inoltre non usufruiscono di modalità d’uso alternative: questo può rendere confuso l’uso di KDE, dove spesso opzioni e comandi sono replicati in più parti dell’ interfaccia. Il principale problema è che essi tendono a usare lo stesso modello anche quando questi si rivela fallimentare: questi utenti si trovano quindi in difficoltà quando si tratta di attuare la dinamica operazione-azione, poiché non sembrano in grado di ripetere la fase di orientamento quando una azione si rivela inadatta allo scopo. Di solito c’è bisogno di un lungo periodo di tempo affinché gli utenti comprendano che l’azione non è quella giusta, poiché sono riluttanti a trovare nuovi modi di fare una cosa. Da questo punto di vista il cambiamento per questi utenti può risultare difficoltoso. Questo gruppo ha avuto difficoltà in particolar modo con la nomenclatura, visto l’intenso uso che essi fanno dei menù: questo è avvenuto quando la voce che si aspettavano di trovare non era presente o non era nella posizione attesa. Inoltre i messaggi di errore e i feedback del sistema gli hanno resi incerti, e questo ha causato l’interruzione dell’ azione. • Utenti esperti: essi hanno abbastanza esperienza con differenti sistemi operativi e sono orientati a raggiungere la soluzione per prove ed errori. La loro conoscenza è piuttosto vasta ma incompleta. Essi usano diverse alternative d’uso ma non le prendono in considerazione in speciali contesti. A differenza della categoria precedente, sono interessati a comprendere come funziona l’applicazione. Nel caso in cui l’azione intrapresa non sia quella giusta, si mettono alla ricerca di un modo alternativo per raggiungere il loro scopo. E’ interessante notare che questo genere di utenti ritenga che la causa di errore non sia il computer, ma il loro comportamento. • Utenti professionali: Questi utenti cercano di capire il modello di funzionamento del sistema in modo da essere preparati per casi speciali. Per ogni task, essi hanno un’insieme di modalità d’uso che vengono valutate per verificarne l’efficacia. Per questo genere d’utente quindi è importante stabilire quale sia il modo migliore per raggiungere uno scopo, mentre il gruppo degli utenti senza esperienza punta a raggiungere l’obiettivo senza comprendere come. Essi pianificano le loro azioni cercando di prevedere i modi in cui il sistema può rispondere. Sono quindi sempre pronti a mettere in discussione il modello dell’ attività che si erano prefigurati. Inoltre sono in grado di individuare gli errori o le inadeguatezze del sistema.

3.1.4

Risultati

E’ ovvio che il primo gruppo di utenti, essendo costituito da quelli meno esperti, è stato quello che ha incontrato più difficoltà con KDE: essendo questi un ambiente concepito per privilegiare le funzionalità rispetto alla semplicità è ovvio che la presenza di più comandi e funzioni alternative disorienti l’utente che non è capace di padroneggiare e comprendere funzionalità avanzate. Inoltre la volontà di restituire un feedback dettagliato dal punto di vista tecnico rende l’utente spaesato di fronte alla terminologia informatica. Gli altri due gruppi invece sono più propensi alla risoluzione dei problemi e alla ricerca di soluzioni alternative. Gli utenti esperti si avvicinano di più all’ utente modello di KDE, in quanto disponibili alla ricerca di soluzioni alternative e a ridefinire il loro modello mentale del sistema.

20

Il terzo genere di utenti, i professionisti, sono quelli che più corrispondono alla definizione dell’ utente tipo di KDE. Nonostante il progetto definisca KDE come una interfaccia per tutti gli utenti, una tacita convenzione tra gli sviluppatori implica che questo genere di utenti è quello più utile per lo sviluppo e il progresso di KDE. Infatti questi utenti possono facilmente diventare contributor, ovvero contribuire allo sviluppo con la segnalazione e la risoluzione dei problemi che hanno riscontrato durante l’uso dell’ interfaccia. Applicando il punto di vista dell’ activity theory si nota quindi una discrepanza tra la struttura dell’ attività dei tre gruppi di utenti. Lo scopo degli utenti inesperti è di raggiungere il loro oggetto in qualunque modo; gli utenti esperti tendono a raggiungerlo nel modo che ritengono più performante. L’ultimo genere di utente è anomalo per quanto riguarda la struttura dell’ attività rispetto agli altri due. Infatti gli utenti inesperti e quelli esperti, seppur con tragitti differenti, puntano al raggiungimento del loro obiettivo usando un’ interfaccia come KDE come artefatto per raggiungerlo. L’ultimo tipo di utente invece arriva a porre come obiettivo non il raggiungimento del motivo dell’ attività ma il funzionamento dell’ artefatto stesso.

kde

Periferiche

Utente

Comunicazione

Utente

KDE

Struttura dell’ attività per un utente comune

Struttura dell’ professionista

attività

per

un

utente

In altre parole un utente professionista spesso tende ad assumere un atteggiamento da sviluppatore o da beta tester: a volte egli stesso effettua un focus shift sull’ artefatto per l’apprendimento. Al termine si conclude che gli sviluppatori di KDE devono integrare la prospettiva dell’ utente nel processo di sviluppo, promuovendo sforzi come il KDE Usability Project. Ne deve seguire un impegno verso determinati aspetti dell’ interfaccia: • Creare una nomenclatura comprensibile e consistente • Migliorare la gerarchia delle informazioni e la categorizzazione • Migliorare l’uso dei menù contestuali • Inserire suggerimenti (o tooltips) significativi • Inserire guide (o wizards) per i task più complessi • Inserire documentazione ben strutturata seguendo una impostazione orientata ai task • Coinvolgere i traduttori nel processo di sviluppo

3.1.5

Critiche

I task sono stati progettati per avere lo stesso livello di difficoltà. In questo modo è stato possibile stabilire il grado di esperienza raggiunta dagli utenti per comprendere i punti deboli del sistema. L’esperimento si colloca a metà strada tra un quasi esperimento con un gruppo di controllo e un esperimento di usabilità informale con lo scopo di individuare problemi. Tuttavia i task assegnati erano indipendenti l’uno dall’ altro, non avevano una priorità particolare e non consentivano di valutare l’operato di un utente nel contesto di una normale giornata lavorativa. Rappresentavano azioni discrete isolate da un contesto d’uso; insieme non concorrevano allo svolgimento di una attività complessa con un obiettivo o motive ben preciso. Solo il task che è stato segnato come n. 10 prefigurava la formazione di una attività che concatena l’uso di più applicazioni Quello che si intende effettuare in seguito è una analisi di una activity vera e propria con uno scopo ben definito 21

che necessiti della messa in opera di varie activities che mettano l'utente a confronto con KDE non come applicazioni separate a se stanti, ma come un sistema desktop integrato che si ispira alla classica metafora delle scrivania, utilizzabile tramite la manipolazione diretta. Comunque in generale i risultati ottenuti vengono dichiarati oltre le aspettative. In quasi tutti gli scenari KDE si pone con uno svantaggio molto leggero nei confronti di Windows.

3.2

Altri studi su software libero

Studi in ambiti più ristretti sono stati compiuti con metodi più strettamente statistici su programmi più specifici come OpenOffice, che si configura come un insieme di programmi da ufficio (videoscrittura, foglio di calcolo, presentazioni, database) paragonabili a Microsoft Office. Seklund, Feldman, Maryt (2003) e Everitt e Lederer (2001) hanno messo a fronte Staroffice Calc 6.0 (precedente denominazione di OpenOffice) e Staroffice Writer rispettivamente con MS Excel 2000 e MS Word 2000. Lo scopo è quello di determinare quali parti dell' interfaccia di Staroffice supportano od ostacolano gli utenti abituali di MS Office, che sono stati selezionati tra persone dotate di diversi livelli di skill con Microsoft Office, per comparare il grado di soddisfazione degli utenti con i due sistemi, per poi elaborare suggerimenti di design per lo sviluppo futuro, basandosi su dati sia qualitativi che quantitativi. Sono stati creati due scenari per un totale di quindici task, raggruppabili in quattro categorie (formattazione di base, formattazione avanzata, creazione di formule e creazione di grafici). Le variabili che sono state misurate sono: • • • • • • • • • Facilità d’uso Comprensibilità Apparenza visiva Compatibilità Facilità nel cambiamento Soddisfazione Comparabilità Utilità Gradevolezza

Per ogni variabile sono stati osservati il tempo, la difficoltà dei task (come misura qualitativa) e il numero di errori commessi dai partecipanti. In generale i risultati sono stati simili a quelli ottenuti nello studio della Relevantive: leggero svantaggio delle performance con i task eseguiti con Staroffice, ma con una differenza statisticamente significativa in due task su quindici e uno svantaggio. Metodologie e risultati analoghi sono stati ottenuti nella comparazione tra Staroffice Writer e MS Word 2000.

3.3

Il KDE Usability Project

IL KDE Usability Project è stato creato per identificare problemi di usabilità in KDE e fornire uno spazio in cui è possibile analizzare e proporre design alternativi. Lo scopo è di fornire un' area di comunicazione comune tra gli sviluppatori di KDE, gli scrittori della documentazione, gli artisti che si occupano della creazione di temi e icone e chi è in grado di contribuire alla creazione di software usabilile; creare e mantenere report di usabilità su applicazioni e componenti; discutere e sviluppare miglioramenti di usabilità che verranno inclusi nei rilasci successivi di KDE; eseguire test di usabilità con utenti con vari livelli di esperienza e abilità; sviluppare metodi di analisi per il testing di KDE; riunire e analizzare il feedback raccolto da terze parti.

22

Il progetto si basa, oltre che sul sito web (raggiungibile su http://usability.kde.org) sulla mailing list ad accesso pubblico kde-usability@kde.org, dove utenti, sviluppatori e beta tester possono usufrire di uno spazio di discussione comune. Il sito fornisce inoltre una serie di linee guida per l'usabilità, le KDE Human Interface Guidelines, cui gli sviluppatori devono attenersi per sviluppare applicazioni e fornire patch che siano coerenti con il resto dell' interfaccia.

3.3.1

Analisi di usabilità del KDE usability project

Come si è detto il KDE usability project raccoglie anche analisi di usabilità effettuate su varie componenti di KDE. L’ intento è di per sé corretto, il problema consiste nella povertà di indicazioni fornite per effettuare test di usabilità validi. Il sito stesso suggerisce di prendere come modello le analisi sottoposte alla mailing list, ma questo non è esattamente un riferimento attendibile, soprattutto se si considera che chi cerca informazioni su come condurre test di usabilità è un utente desideroso di contribuire al miglioramento dell’ usabilità che non è esperto dei metodi per il testing delle interfacce. Oltre a questo viene suggerito di tener conto delle linee guida di usabilità fornite sul sito; in altre parole si tratta di verificare se le interfacce dei programmi che si vogliono prendere in analisi seguono le linee guida indicate. Questo può essere utile per verificare la coerenza delle interfacce di diversi programmi, ma non è utile per questioni più complesse che trascendono le linee guida. Inoltre non permettono di verificare la validità delle linee guida stesse; non è detto inoltre che linee guida siano valide in tutti i casi. Può infatti accadere che i programmatori debbano deliberatamente violare le linee guida per ottenere una maggiore usabilità. Passiamo al vaglio almeno un report sottoposto al progetto per cercare di identificarne le modalità di testing. 3.3.1.1 Kaddressbook 3.2 - Ellen Reitmayr, relevantive AG Kaddressbook è il gestore dei contatti di KDE. Questa analisi si basa su una valutazione euristica dell’ interfaccia, ma non riporta un testing effettuato con utenti reali che non siano lo sperimentatore stesso. Trattandosi di una applicazione di piccole dimensioni è stato possibile analizzare tutte le sue parti, sia per quanto riguarda il look&feel che l’interazione. Nella valutazione sono stati passati al vaglio la schermata principale, analizzando le azioni che l’utente compie quando deve aggiungere, modificare o eliminare un contatto, la funzione di ricerca e il menù contatti. Dopo aver elencato i problemi riscontrati ne viene proposta una possibile soluzione o correzione. 3.3.1.2 Analisi dei problemi La finestra principale è divisa in due parti: quella a sinistra riporta un elenco dei contatti: quella destra visualizza i dettagli del contatto selezionato nella parte sinistra. Il problema consiste nel fatto che la parte dedicata ai dettagli è troppo ampia, in modo tale da impedire la corretta visualizzazione dei contatti riportati nella parte sinistra. Quando l’utente necessita di inserire un contatto, allora si trova davanti ad un wizard il cui testo è allineato al centro. Quando si tratta di modificarlo, la dimensione verticale del wizard è troppo corta, rendendo necessario lo scorrimento del testo per visualizzare tutte le opzioni. In questi due wizard il look&feel è inconsistente, poiché è completamente differente per testi, dimensioni delle icone e disposizione di pulsanti. Come si vede, questi problemi riguardano tutti il look&feel ed è probabile che siano tutti reali problemi di usabilità che non necessitano di un test utente per essere rilevati ma soltanto di una correzione in tempi rapidi. Quando si tratta di cancellare un contatto l’utente deve selezionarlo e premere il bottone nella barra superiore che corrisponde alla cancellazione. In questo caso il modo di operare viene definito insolito, perché secondo l’autrice dello studio l’utente si aspetta di trovare una finestra di dialogo riportante una lista di nomi dalla quale selezionare quelli che si vogliono cancellare. La soluzione 23

originaria è più veloce, ma non viene riportata nessuna evidenza del fatto che un utente preferisca la soluzione alternativa proposta. L’analisi della soluzione si basa non su linee guida o su test reali, bensì su un giudizio personale. Segue poi la valutazione dell’ editor dei contatti, che serve per l’inserimento o la modifica dei dati. Si presuppone che la prima cosa che si inserisce è il nome dei contatti. In questo punto invece l’ interfaccia è più confusa (basta dare uno sguardo alla figura) e per modificare il nome è necessario cliccare sulla voce edit name.

Per inserire un indirizzo invece, è possibile cliccare sulla voce edit address, il che è perfettamente normale, ma lo stesso effetto si ottiene anche cliccando sul campo di testo soprastante, in evidente contrasto con le linee guida. L’inserimento di numeri telefonici è altrettanto disorientante: è necessario selezionare il tipo di numero (casa, lavoro, cellulare) da un menù a tendina e poi inserire il numero, ma in caso di errore non è sufficiente cambiare il tipo di numero modificandolo tramite il menù a tendina, ma è necessario cliccare sulla voce edit phones. Per quanto riguarda i menù viene consigliato di inserire come menù generici i normali file/edit/settings (si parla della versione inglese), affiancato dal menù contacts nel quale raggruppare le varie funzioni legate alla gestione dei contatti. 3.3.1.3 Conclusioni Per quanto riguarda l’applicazione stessa, buona parte dei problemi è imputabile al look&feel che presenta alcuni errori di programmazione. I problemi riguardanti l’interazione derivano da due fattori: la miopia verso l’utente, causata da un ridotta fase di valutazione effettuata prima del rilascio dell’ applicazione, e la volontà di inserire molteplici funzionalità senza curarsi degli effetti che questo può avere sull’ usabilità del programma. L’ editor dei contatti vorrebbe offrire un maggiore controllo delle informazioni in una unica schermata, ma questo ha causato la creazione di una interfaccia confusa. La valutazione effettuata individua senz’ altro problemi realmente esistenti, ma si basa su valutazioni personali che a volte non sono guidate neanche da guide euristiche preesistenti. Questo non costituisce un problema di metodo per questioni semplici riguardanti il look&feel, ma non può essere ammesso quando si vuole fornire delle soluzioni per problemi complessi come l’editor dei contatti. In casi come questo non è sufficiente fornire una soluzione utilizzando una valutazione 24

basata sull’ esperienza dello sperimentatore, ma è necessario far eseguire lo stesso percorso a più utenti, e allora proporre una soluzione di design che dovrà essere nuovamente testata su utenti reali.

25

4 L’analisi
Dopo aver discusso il modello di sviluppo di KDE, introdotto il framework dell’activity theory e analizzato gli sforzi già compiuti per l’usabilità di KDE e del software libero passiamo all’analisi vera e propria, basandoci su quanto è stato esposto nel paragrafo 2.3. Sono stati creati tre scenari che differiscono per la loro difficoltà. Per mezzo di essi è stato condotto un test d’usabilità informale su nove soggetti in totale, utilizzando tre soggetti per ogni scenario. Al soggetto che si è prestato al test è stato presentato un breve elaborato scritto che riassume gli obiettivi del test e quello che si sarebbe trovato di fronte. E' utile anche per infondere calma nei soggetti e per metterli a proprio agio, per non indurli in uno stato di ansia, dal momento che si trovavano in una condizione che avrebbe potuto evocare test o esami di cui si hanno ricordi sgradevoli. Il test è stato effettuato con KDE 3.3.4 con la distribuzione GNU/Linux Yoper. L’attività eseguita dall’utente è stata filmata con una videocamera, in modo da poter catturare tutti suoi commenti espressi durante il thinking aloud e da poter dedicare tutta la propria attenzione al soggetto nel caso si fossero verificati dei problemi.

4.1 Documento di debriefing
Benvenuto. Quello che stai per vedere è un’interfaccia grafica per computer. Il suo nome è KDE. Il suo funzionamento è simile a quello di Windows: ci sono icone, finestre, menù. Tuttavia noterai delle differenze, ad esempio le icone saranno diverse, così come i nomi dei programmi ed altre cose. Il suo scopo è rendere l'uso del pc facile e intuitivo come se usassi Windows. Stiamo cercando di migliorare l'esperienza che puoi avere usando KDE. Il modo migliore per farlo è chiedere ai suoi potenziali utilizzatori di provarla e di esprimere le loro impressioni e i loro dubbi. Questo non è un test di psicologia, o un test di intelligenza. Niente del genere. Chi è sotto test è KDE. Se incontrerai problemi la colpa è nella progettazione di KDE: quindi si tratta di errori nostri, non tuoi. La tua esperienza con KDE e i problemi che potresti incontrare aiuteranno noi a capire dove abbiamo sbagliato e come rimediare, in modo da rendere l'uso di KDE più semplice e più piacevole. Sotto troverai un piccolo brano che descrive quello che farai con KDE: sono attività simili a quelle che fai di solito con il tuo computer. Ti abbiamo fornito un nome utente ed una password che serve per entrare nel sistema, che servono per impedire ad estranei di accedere al sistema ed evitare sgradite sorprese. Non vederle come un ostacolo ma come una misura per migliorare la tua sicurezza. Sei libero di agire come meglio credi. Mentre usi KDE ti chiediamo di esprimere ad alta voce quello che vedi. Prenditi tutto il tempo che ti serve. La persona al tuo fianco non interferirà con te, ma ti darà aiuto se incontrerai problemi che ti bloccano. Se hai domande chiedi pure. 4.2

Scenari

• Scenario 1 (principiante) Hai da poco un nuovo pc, e su di esso, al posto di Windows, trovi KDE. Oggi scade il termine per l'invio dei curricula ad una azienda che si occupa della ricerca del personale. Conosci l'indirizzo di un sito web (http://www.azienda.it/curr.html) dove è presente un modulo che dovrai compilare, stampare e inviare via posta ordinaria. Cerchi quindi un programma per la navigazione web, vai all’indirizzo, compila il modulo (o form) presente nella pagina e stampalo sulla stampante che è accanto a te.

26

• Scenario 2 (Intermedio) La tua azienda ti ha fornito un nuovo pc con installato KDE. Oggi sono usciti i piani di sviluppo, disponibili sul sito web dell’azienda (in formato pdf), che è impostato come pagina principale del browser web. Dopo aver aperto il browser salvi quindi il file in una cartella a tua scelta. Poiché il tuo pc è l'unico che ha accesso al world wide web, è compito tuo inviarlo via e-mail ai tuoi colleghi, i cui indirizzi sono già nella rubrica del tuo programma di posta. I tuoi colleghi non hanno installato un lettore per i file pdf, quindi devi convertire il testo in un file che possa essere letto con word copiando il testo dal lettore di file pdf e incollandolo in cui programma di videoscrittura, salvandolo in formato word (con estensione doc). A questo punto utilizzi un programma di posta elettronica per inviare il file come allegato ai tuoi colleghi. • Scenario 3 (Esperto) Dopo aver comprato un computer portatile con Windows da utilizzare per lavoro, decidi di provare ad installare Linux sul tuo computer da scrivania e di scegliere KDE come interfaccia grafica. Un tuo amico ti ha inviato via e-mail un invito per sottoscrivere un nuovo indirizzo di posta elettronica con gmail, che offre un gigabyte di spazio disponibile per i tuoi messaggi. Decidi quindi di utilizzare questo indirizzo di posta esclusivamente da Linux. Apri un browser web e accedi quindi alla tua solita casella e utilizzi i dati che ti sono stati inviati per e-mail per configurare un programma di posta elettronica per scaricare direttamente le mail sul pc senza dover accedere all’interfaccia web. Dopo aver aperto un programma di posta elettronica imposti i dati che riguardano la tua identità, oltre agli indirizzi dei server pop3 e smtp per lo scaricamento e l’invio della posta.

4.3 Fasi preliminari
KDE è altamente personalizzabile. E’ possibile modificarne molti aspetti con relativa facilità: icone, combinazione di tasti, temi del desktop e altro ancora. Nonostante ciò nello svolgimento del test si è preferito mantenere le impostazioni predefinite, in modo da riprodurre realisticamente la situazione in cui si troverebbe un utente nel caso in cui venisse a contatto con una installazione standard di KDE. Operando in questo modo inoltre si evita di aiutare KDE durante il test ottenendo risultati non realistici: l’esperimento ha lo scopo di trovare problemi di KDE, e modificando arbitrariamente delle impostazioni si rischierebbe anche di crearne di nuovi. Ci si troverebbe nella stessa situazione degli sviluppatori di KDE, supponendo di essere in grado di correggere gli errori senza basarsi sull’ esperienza degli utenti. Le modifiche effettuate sono state minime: è stato installato il supporto per la lingua e la tastiera italiana; inoltre sono state installate due suite da ufficio: koffice (nativa di KDE) e il più diffuso OpenOffice. E’ stato installato anche l’ Adobe Acrobat Reader per Linux, necessario per il supporto dei file pdf. Una particolare affinità lega la seconda parte dello scenario numero due con l'analisi di usabilità effettuata nell' ambito del KDE usability project vista nel paragrafo 3.3.1.1. In essa è stata analizzata la rubrica dei contatti di KDE, kaddressbook: si è trattato però di una ispezione fatta direttamente dallo sperimentatore, basandosi su linee guida euristiche piuttosto che sull' esperienza riportata dall' utente. Poiché l'uso della rubrica è necessario per completare il secondo scenario è una buona occasione per vedere quali sono le differenze che si riscontrano tra una analisi basata sull' uso delle euristiche e una svolta con l'uso di soggetti reali. Il tempo impiegato per completare gli scenari non è stato tenuto in considerazione, poiché ci si basa su dati qualitativi. Il flusso dell’ attività è stato rappresentato in una griglia. Essa è leggermente diversa da quella utilizzata da Bødker per l’analisi di VIRK. Bødker stessa ha elaborato una griglia adatta per il mapping di interfacce più complesse come Windows e Wordperfect (Bødker 1995, p.165).

27

In una dimensione vengono riportati i punti dell’ interfaccia su cui si concentrano i soggetti, nell’ altra la narrazione diretta dell’ utente e la descrizione delle azioni fisiche che questi compie (puntamento, trascinamento ed altre).

4.4 Soggetto 1
4.4.1
Documento

Scenario 1
Login/Logout

Azioni

Narrazione

Barra strumenti

Desktop

Menù

• • •

Preme sull' icona del desktop Devo compilare un curriculum, con la scritta web browser quindi devo cercare un browser internet (avvia Konqueror) Compila il modulo Registriamoci...

Inserisce l'indirizzo nella barra Penso che sia questo, devo superiore e preme invio familiarizzare con le icone perché non le conosco Clicca sull’ icona che rappresenta la stampante nella barra superiore, si apre una finestra di dialogo, quindi preme stampa. La stampante si avvia. Pare facile, devo controllare che la stampante sia attiva. La stampante selezionata è quella giusta? Devo familiarizzare con le icone perché è tutto diverso. Per mia abitudine uso sempre le barre degli strumenti, mai dai menù perché per me è più semplice.

Clicca sulla croce in altro a Chiudo. destra e chiude Konqueror Compare una finestra di dialogo per chiedere la conferma della chiusura. La legge. Poi clicca chiudi. Cerca di uscire da KDE, va sul pulsante in basso a sinistra (la K) Che devo fare, devo cliccare? Clicco chiudi. Sono rimasta bloccata, non me lo aspettavo, mi aspettavo spegni il computer.

• •

Scorre il menù di KDE, poi va “Termina sessione”, penso che su “termina sessione” sia questo. Clicca sulla computer” voce “spegni Si, ce l’ho fatta.

In questo primo caso il soggetto ha completato lo scenario senza breakdown. Il processo non è stato interrotto e il soggetto è sempre riuscito a focalizzarsi sulle parti giuste dell’ interfaccia. Solo alla fine, quando il soggetto ha autonomamente deciso di uscire, si è trovato in difficoltà, poiché non ha 28

trovato quello che si sarebbe aspettato. Il soggetto ha dichiarato di andare alla ricerca di una voce simile a “spegni il computer”; tuttavia alla fine ha eseguito l’azione corretta individuando la voce “termina sessione” nel menù di avvio di KDE. Si tratta di un breakdown riguardante gli handling aspects, cioè quegli aspetti delle applicazioni per computer che supportano le operazioni verso l’applicazione stessa. In questo caso un breakdown costringe l’utente a focalizzarsi sull’ artefatto come oggetto, cercando di individuare l’operazione corretta da effettuare.

4.4.2 Scenario 2
Barra degli strumenti

Azioni
Barra inferiore

Narrazione

Finestre di dialogo

Documento

Desktop Apre il browser e va all' indirizzo Prima devo aprire il dal quale scaricare il file pdf browser e salvare in una cartella, quindi adesso inserisco l'indirizzo nella barra. Ho memorizzato che quella è l'icona del browser Va sul primo menù da sinistra e Trovato. Vado su salva con clicca su salva con nome nome Inserisce un nome al file con Mi creo una cartella nuova estensione pdf, va subito sul e vado su ok pulsante della finestra di salvataggio che crea una nuova cartella, compare la scritta “crea cartella” in sovrimpressione e vi clicca, poi va su salva. Riapre Konqueror sempre dalla Apro il file, dovrei andare stessa icona su documenti Chiude Konqueror e prova a Non trovo...ho sbagliato cliccare tutti i pulsanti che ci sono sul desktop Scorre tutto il menù di KDE Devo trovare l'esplora risorse, ma è come se non lo trovo...vediamo, c'è tutto qui tranne quello che dico io, aspetta che devo memorizzare ...

• •

Menù

29

Barra degli strumenti

Azioni
Barra inferiore

Narrazione

Finestre di dialogo

Documento

Desktop

Menù

Va sulla barra inferiore, osserva i tips di ogni icona, poi preme sull' icona di una casa su cui compare “file personali”, quindi apre Konqueror in modalità file manager nella cartella dell' utente. Lo sperimentatore spiega qual’è la relazione tra la cartella dei documenti dell' utente e l' icona che rappresenta una casa

Programma di posta elettronica, browser web, ho capito, file personali, ah ecco, perché?

Ah, sì giusto. Facile. Devo convertire il testo in un programma di videoscrittura.Quale sarà?

Clicca sull' icona del file salvato in Questo, legge i file pdf, precedenza e apre adobe acrobat acroread. Devo copiare e reader. incollare.. Cerca di selezionare il testo con il cursore del mouse, ma acrobat è in modalità di lettura, per selezionare il testo deve essere selezionata l'icona “T” sulla barra degli strumenti. Io faccio così, trascino sul testo..non fa..non riesco a selezionare il testo. Seleziono tutto il file, poi trovo le icone piccole del copia incolla, ma non ci sono, devo trovare un altro sistema, esce la manina... Non c'è... tutto, l' ho

• •

Cerca sulla barra degli strumenti

Cerca tra i menù. Va sul menù Seleziona modifica e seleziona la voce trovato. “seleziona tutto” Copia il testo dal menù modifica

Di solito vado dalla barra, non trovo le icone...copia...adesso incolla in un programma di videoscrittura.

Clicca sulla icona con il piano e la Vedo questa matita e penso matita sulla barra inferiore. che sia questo, ma mi accorgo che non è...

30

Barra degli strumenti

Azioni
Barra inferiore

Narrazione

Finestre di dialogo

Documento

Desktop

Menù

• • • • • •

Clicca su programma terminale Scorre il menù di KDE

Cosa è? Ma programma?

c'è

il

Vado a cercarlo tra i programmi.

Và nel menù programmi da ufficio. Videoscrittura, c'è! Apre Kword Si apre una schermata “crea Crea documento, voglio un documento” e seleziona un testo semplice, vuoto. documento vuoto. Seleziona l' icona “incolla” sulla Allora, c'è l'icona di incolla barra degli strumenti. attiva. Seleziona “Salva con nome” dal Ora salvo il documento in menù e inserisce un nome di file formato doc...salva con seguito dall' estensione doc. nome...punto doc, e poi lo devo inviare. Scorre i menù di Konqueror, poi lo Il mio programma di posta chiude è sempre questo, Konqueror? Questo non è un programma di posta elettronica. Cerca un programma di posta Giustamente, la elettronica. Clicca sull' icona di lettera...ora devo inviare il Kmail sulla barra inferiore (l'icona file come allegato è una E con una lettera).

• • • • •

Clicca sul menù messaggio e clicca Creo un nuovo messaggio.. su nuovo. Clicca sul menù allega e poi su Allega..testo.doc “allega file”, poi seleziona il file. Va sul menù opzioni. Va sul menù strumenti. Adesso devo trovare la rubrica Rubrica..ok, questi sono i contatti...aspetta 31

Barra degli strumenti

Azioni
Barra inferiore

Narrazione

Finestre di dialogo

Documento

Desktop

Menù

• •

Clicca su file e poi su importa.

...

Clicca sul pulsante aggiungi in Aggiungi, aggiungi che? basso a sinistra, poi chiude la Seleziona il tipo della finestra che si è aperta. rubrica indirizzi? Ho sbagliato. Prova a fare copia incolla ma non Devo prendere l'indirizzo e ottiene risultati. metterlo nella lettera. Lo copio... Chiude la finestra. Ho bisogno di aiuto. Non so che ho combinato, ma mi sto divertendo.

Lo sperimentatore mostra il sistema Sì, così è più semplice. più semplice: clicca sul pulsante con i puntini di sospensione accanto alla casella di testo degli indirizzi dei destinatari, poi seleziona gli indirizzi ai quali si vuole inviare il documento.

Invia la mail cliccando sul pulsante Bene, ora invio il tutto. di invio.

In questo caso la situazione è più complessa. Il soggetto riesce a individuare immediatamente la voce giusta per memorizzare il file, ma poi non riesce più a ritrovarlo, o meglio a trovare una applicazione per la gestione dei file. Comincia quindi a spostare la sua attenzione su tutte le parti del sistema, esplorando l’interfaccia : cerca tra il menù, le icone del desktop e quelle della barra inferiore. Alla fine trova l’icona del file manager nella barra inferiore grazie al tooltip riportante la dicitura “file personali”. L’icona ha la forma di una casa: a questo punto si ha un focus shift per l’apprendimento e il soggetto chiede quale è la relazione tra l’icona e i file personali. Anche questo breakdown può essere considerato legato agli handling aspects. Dopo aver ritrovato il file esso viene automaticamente aperto in Adobe Acrobat Reader. Il soggetto non deve aver avuto molta esperienza con questo programma. Secondo le impostazioni di default del programma il mouse viene usato per trascinare e spostare la pagina; per poterlo selezionare è necessario attivare una apposita icona a forma di T. Il soggetto ha tentato di selezionare il testo con il mouse ma non vi è riuscito, quindi ha cercato anche le icone copia e incolla sulle barre degli strumenti, affermando che le preferisce ai menù. Solo dopo comincia a focalizzarsi anche sui menù esplorandoli uno ad uno. A questo punto trova le voci copia e seleziona tutto all’ interno del menù modifica. Dopo aver copiato il testo il soggetto si mette alla ricerca di un programma in cui salvare il testo in un formato come il 32

.doc. La prima cosa su si concentra è la barra inferiore, in cui vengono riportati i programmi di più frequente utilizzo. Nota quindi una icona che rappresenta un piano con una matita sopra. L’icona in questione rappresenta il desktop: cliccandovi sopra tutte le finestre vengono nascoste. La stessa icona, con dimensioni più piccole e leggermente differente, è presente anche nell’ interfaccia di Microsoft Windows. A questo punto decide di esplorare il menù di KDE. Nella voce più in alto del menù è presente un riferimento a OpenOffice; gli altri programmi invece sono classificati secondo la loro categoria. Si posiziona nel menù ufficio e trova la voce kword (videoscrittura) dove tra parentesi è evidenziato il genere di programma. Aperto Kword crea un documento vuoto e vi incolla il testo utilizzando l’icona incolla presente sulla barra degli strumenti, che viene prontamente individuata. Dal menù file clicca quindi la voce salva con nome e inserisce il nome del file seguito dall’ estensione .doc. Questa operazione in realtà non è corretta. Nei sistemi operativi UNIX (e anche MacOS) l’estensione di un file non ne determina il formato, ma è puramente indicativa. L’azione corretta è selezionare il tipo di file dal menù sottostante. Questo breakdown, del quale l’utente non è neanche consapevole, è da riferirsi agli aspetti diretti verso il soggetto/oggetto: non si verificano cioè le condizioni per le operazioni dirette verso l’oggetto al quale tende il soggetto, cioè il documento. Successivamente il soggetto ha correttamente identificato l’icona che avvia un programma di posta elettronica, ha facilmente creato un nuovo messaggio e vi ha allegato il file. Si è però trovato in difficoltà in merito alla rubrica. La rubrica è stata individuata in pochi passi, ma l’azione corretta da effettuare è stata trovata solo con un aiuto esterno. Il soggetto ha provato a cliccare ed esplorare tutta la rubrica, ma non ha trovato il pulsante corretto, che è situato al di fuori della rubrica. Dopo questo step l’utente ha subito individuato il pulsante per la spedizione presente sulla barra degli strumenti.

4.4.3 Scenario 3
Finestra Di Dialogo

Azioni

Narrazione

Barra Superiore

Configurazione

Voci Finestra

Opzioni Riapre il programma di posta Credo di dover usare il elettronica programma di posta elettronica per fare questo.

• • • •

Menù

Cerca nel menù file

Devo creare un nuovo indirizzo, quindi provo su file, nuovo…no

Scorre tutte le voci di tutti i Modifica, visualizza… menù impostazioni..no. Cerca tra i pulsanti della barra Nuovo messaggio, invia …non è degli strumenti neanche qui Chiede aiuto Non so dove andare a mettere mano…cosa devo fare?

Lo sperimentatore mostra cosa Da impostazioni seleziona fare. “impostazioni Kmail” e crea una nuova identità 33

Finestra Di Dialogo

Azioni

Narrazione

Barra Superiore

Configurazione

Voci Finestra

Opzioni

Menù

Inserisce nome e cognome


Va su modifica identità Chiede aiuto

Ah, chiaro, pensavo di trovare qualcos’ altro…che le impostazioni fossero diverse. Bene, ma questi altri indirizzi dove vanno? Devo aggiungerli, dove vanno questi? Non so che fare…mi sono bloccata.

Lo sperimentatore mostra cosa Invece che da identità accedi fare. alla voce “rete” e da lì alle voci spedizione e ricezione.

Inserisce i dati dei server nelle Nome…e host.. metto l’indirizzo impostazioni di ricezione. in nome, ma host cosa è? Cosa devo metterci? Lo sperimentatore spiega la Il nome è un identificativo differenza qualsiasi per il provider, l’host è l’indirizzo del server.

• •

Il soggetto compie le stesse Adesso la stessa cosa deve operazioni anche per impostare valere anche per la la spedizione. spedizione…host è l’indirizzo. Chiude e cerca di scaricare la Adesso provo a scaricare la mail individuando il pulsante posta… vediamo, sembra che per il download. sia questo…scarica. Si. Fatto.

In questo caso lo scenario si è rivelato difficile da eseguire per l’utente. Esso ha cercato di impostare un nuovo indirizzo cercando di esplorare l’interfaccia e seguendo un modello che si era creato. L’utente ha avuto difficoltà principalmente nella ricerca della giusta voce di menù per la creazione e l’impostazione di nuovi indirizzi e-mail: per questo è stato necessario un’ aiuto esterno. Entrato nella voce identità, il soggetto ha inserito nome e cognome, ma ha poi affermato che non aveva idea di dove inserire gli altri dati forniti. E’ stato quindi nuovamente necessario l’intervento dello sperimentatore. Ha correttamente inserito gli indirizzi dei server per la ricezione e la spedizione della posta elettronica, avendo solamente qualche perplessità sulla voce host, che non è stata tradotta in italiano.

4.4.4 Considerazioni
Questo utente non ha una esperienza particolare con il computer, ma è riuscito a completare gli scenari senza troppe difficoltà. Corrisponde approssimativamente al primo gruppo di utenti descritti nel paragrafo 3.1.3. Questo utente non vede una differenza particolare tra due sistemi come 34

Windows e KDE. Le sue operazioni non sono già tutte azioni trasformate, eseguite inconsapevolmente. Grazie a questo l’utente è facilitato poiché non è legato ad azioni ben consolidate. Se non si considerano i breakdown più seri come quello della rubrica nello scenario 2 e in generale lo scenario 3, rivelatosi impegnativo per questo genere di utente, l’esperienza è stata positiva. Lo stesso soggetto ha più volte dichiarato sia durante il test che dopo che quello che serviva era fare esperienza con l’interfaccia, al fine di impratichirsi con certe caratteristiche come le icone. Secondo quanto affermato dall’ utente alla fine dell’ esperimento la sua esperienza è stata piacevole ed è rimasto positivamente impressionato da KDE.

35

4.5 Soggetto 2
4.5.1 Scenario 1
Finestre di dialogo

Azioni
Barra strumenti Barra inferiore

Narrazione

Documento

Desktop Clicca sull' icona di Konqueror Cerco un programma connettermi Scorre la pagina di benvenuto

Menù

• • • • • • • • •

per

Questo non sembra quello che serve a me.. vediamo un po'

Scorre le icone della barra Questo serve per mandare le einferiore mail... aiuto no... Punta su Konqueror nella barra Browser web, non era questo? inferiore. Si accorge della barra dell' Ah, la barra, non me ne ero indirizzo e inserisce la accorto. destinazione. Cerca un modo per stampare Stampo sulla stampante, cerco nella barra degli strumenti un' icona che non trovo... su windows sarebbe più facile Cerca nel menù strumenti Cerco..

Trova l' icona della stampante Ah, ecco... scusa KDE, non sulla barra superiore e apre la l'avevo vista... finestra di dialogo. Punta sui bottoni della finestra Opzioni.. no, stampa, si.. di dialogo, poi preme stampa.

36

Ecco un nuovo soggetto. In questo caso lo scenario è stato eseguito in maniera differente. L’ utente ha correttamente identificato l’ icona del browser, ma è rimasto disorientato dalla pagina di benvenuto che si è trovato di fronte. A questo punto ha chiuso la finestra, ha esplorato la barra inferiore e da lì lo ha nuovamente riaperto, notando la barra dell’ indirizzo. Subito dopo ha cercato l’icona che corrisponde alla stampa sulla barra delle applicazioni, ma non l’ha notata. Ha cercato la voce stampa tra i menù, in particolare tra il menù strumenti. Il soggetto ha affermato che si sarebbe aspettato di trovarla nel menù file, ma in KDE questa voce è stata sostituita da indirizzo, il che ha lasciato interdetto l’utente. Successivamente ha individuato l’icona della stampante sulla barra superiore che aveva già esplorato, ed ha avviato la stampa senza problemi.

4.5.2 Scenario 2
Barra degli strumenti

Azioni
Barra inferiore

Narrazione

Finestre di dialogo

Documento

Desktop

Menù

• • • • • •

Inserisce l'indirizzo documento in Konqueror

del Inserisco documento

l'indirizzo

del

Sposta il puntatore sul Non è testo selezionabile... documento e cerca di selezionarlo senza riuscirci. Cerca sulla barra superiore. Non esistono questi comandi...perché non c'è il comando salva come su windows?

Cerca tra i menù di Konqueror. ....Non esiste.. Va sul menù indirizzo. Indirizzo... qui di solito trovo file... vediamo salva con nome... si. questo credo

Chiude Konqueror e apre ...Acrobat..con direttamente il file da dove era che.. stato salvato usando Acrobat Reader. Cerca sulla barra superiore un Ecco qua.. modo per rendere selezionabile il testo, attivando la modalità esatta.

37

Barra degli strumenti

Azioni
Barra inferiore

Narrazione

Finestre di dialogo

Documento

Desktop Seleziona tutto il testo con il Ora devo trovare un puntatore del mouse. programma per scrivere nel formato giusto.. Va sul menù di kde e seleziona Openoffice e seleziono il writer. OpenOffice Writer. Apre il menù con il tasto destro Incolliamo. e cerca la voce per incollare il testo. Trova la voce incolla alla fine Fatto. del menù e vi clicca sopra. Va direttamente al menù file e File/salva... seleziona salva con nome. Seleziona il tipo di formato dal Doc versione 97/2000/XP menù a tendina. Compare un pop-up che avvisa Mmm... salva comunque. che salvando in questo formato alcune informazioni potrebbero andare perse Apre il programma di posta Questo l'ho gia visto prima, elettronica apro il programma di posta elettronica Seleziona il pulsante “nuovo Mmm...sarà questo? Nuovo... messaggio” dalla barra degli strumenti

• • • • • • • • • • • •

Menù

Dal menù allega file.

allega

seleziona Ora allega...file.

Seleziona il file dalla finestra di Seleziono il file da dove lo dialogo avevo salvato e via... Seleziona la rubrica dal menù Ora la rubrica ... strumenti, strumenti rubrica...

38

Barra degli strumenti

Azioni
Barra inferiore

Narrazione

Finestre di dialogo

Documento

Desktop

Menù

Clicca due volte su un contatto

• • • • • • •

Ecco, vedi, su outlook se clicco due volte lo inserisce automaticamente tra i destinatari.

Seleziona il contatto e vi clicca Non così... con il tasto destro. Scorre il menù Torna sul menù di kmail Invia contatto...no.. Aggiungi contatto, vediamo tra strumenti, impostazioni, allega, opzioni, visualizza...

Scorre i pulsanti della barra Nuovo messaggio, ricevi... superiore. Ritorna nella rubrica l'unica soluzione deve essere dalla rubrica

Trova il pulsante aggiungi (ma Trovato, aggiungi. No. non è quello giusto) Il soggetto cerca aiuto. Mi dà un aiuto?

Lo sperimentatore mostra la Si clicca sul pulsante con i soluzione adeguata. puntini di sospensione e si aggiungono gli indirizzi...

Clicca sul pulsante di invio Io farei questo..inviato. sulla barra superiore

Il soggetto ha inserito l’indirizzo del file nel browser, quindi il file si è aperto direttamente nel visualizzatore integrato di Konqueror. Invece di salvarlo in una cartella, ha cercato di selezionarlo con il mouse, ma senza riuscirvi. Questo non è una operazione possibile con il visualizzatore integrato di Konqueror. L’unico modo è aprire separatamente Adobe Acrobat Reader. Si tratta quindi di un breakdown legato agli aspetti diretti verso il soggetto/oggetto, visto che non è possibile effettuare l’operazione richiesta verso l’oggetto, cioè il documento. A questo punto l’utente è andato sul menù indirizzo, dove si aspettava di trovare comunque la voce file, e ha individuato la voce “salva con nome”. Dal menù dei programmi di KDE ha trovato poi Acrobat Reader. E’ riuscito a selezionare il testo attivando la modalità corretta. Si è poi spostato nel menù dei programmi ed ha subito individuato OpenOffice come programma di videoscrittura 39

(l’utente lo conosceva già). Il testo è stato incollato scegliendo la voce incolla dal menù aperto con il tasto destro: un modo di operare molto diverso dal soggetto precedente, che evidenzia una maggiore esperienza. Dal menù file è poi stata selezionata la voce salva con nome; da qui l’utente ha inserito il nome del file, selezionando il formato dal menù a tendina. Dopo aver fatto ciò viene aperto pop-up che informa che il salvataggio in questo formato potrebbe causare la perdita di alcune informazioni. Dopo aver accettato il pop-up l’utente si è messo alla ricerca di un programma di posta elettronica per inviare il messaggio. Apre dunque kmail, che aveva già notato nella barra inferiore, poi seleziona la voce nuovo messaggio. Dopo aver allegato il file senza difficoltà entra nella rubrica dal menù strumenti. Qui si verifica un altro breakdown legato agli handling aspects; l’utente non è in grado di individuare l’azione corretta; egli esegue la stessa operazione che effettua con outlook: clicca due volte per inserire il nominativo tra i destinatari, ma questo non accade. L’operazione ben consolidata di cliccare due volte per inserire i destinatari non causa la condizione per il proseguimento dell’ attività. Deve quindi eseguire questa operazione come una azione cosciente. Esplora allora il menù aperto con il tasto destro, senza successo, poi esce dalla rubrica e esplora menù e pulsanti della finestra principale di KDE. Allora torna nuovamente alla rubrica, e nota il pulsante aggiungi; tuttavia non è quello giusto. Cerca quindi aiuto e lo sperimentatore mostra le operazioni corrette da eseguire. Adesso il soggetto è in grado di individuare correttamente il pulsante per l’invio e termina lo scenario.

4.5.3 Scenario 3
Finestra Di Dialogo

Azioni

Narrazione

Barra Superiore

Configurazione

Voci Finestra

Menù

• • • • • •

Apre kmail e va sul menù Sarei andato su strumenti se si fosse strumenti. trattato di outlook Va su impostazioni / configura. Impostazioni...configura... Si posiziona su “nuova identità” Queste sono le identità...inserisco il ed inserisce i dati. mio nome e indirizzo e-mail Va su modifica identità. Cerca nella voce avanzate. Devo modificarlo sicuramente. Qua avrei dovuto mettere i server..

Inserisce gli indirizzi nei campi Metto qui, ma sono dubbioso. della tab “avanzate”. Si evidenzia che la scelta Dove andavano messi? corretta non è quella giusta.

40

Finestra Di Dialogo

Azioni

Narrazione

Barra Superiore

Configurazione

Voci Finestra

Menù L'utente individua la scelta Ah, rete...non dovevo andare su corretta nella voce rete posta identità.. sotto la voce identità. Imposta gli indirizzi nella voce Host..deve essere l'indirizzo... ricezione. Imposta gli indirizzi per la Spedizione..host per la spedizione spedizione. Scarica la posta con il pulsante A posto... corretto sulla barra superiore.

• • • •

Al contrario del soggetto precedente, questo utente è stato in grado di trovare la voce di menù in cui inserire i dati richiesti per l’ impostazione di un nuovo indirizzo di posta elettronica. Dopo aver creato correttamente una nuova identità l’utente ha inserito gli indirizzi dei server per la ricezione e la spedizione nei campi errati, dichiarandosi non sicuro di quello che stava facendo. Allora lo sperimentatore è intervenuto spiegando le operazioni corrette da effettuare, quindi il soggetto ha correttamente inserito i dati forniti.

4.5.4 Considerazioni
Questo utente ha una esperienza più lunga di quello precedente. Lavorando spesso con Windows ne ha fatti propri i principi di funzionamento, cercando di ritrovarli anche durante l’uso di KDE. Le sue operazioni sono altamente automatizzate, per cui nei punti in cui l’interfaccia si è rivelata diversa da quella a cui era abituato si sono verificati numerosi focus shift e breakdown legati agli handling aspects. A parità di esperienza, questo è stato l’utente che ha avuto maggiori difficoltà con l’uso di KDE. Per permettergli di padroneggiare meglio l’interfaccia sarebbe necessario un periodo di apprendimento più lungo per la creazione di nuove azioni e nuove catene di operazioni.

4.6 Soggetto 3
4.6.1 Scenario 1
Finestre di dialogo

Azioni
Barra strumenti

Narrazione

Documento

Desktop

Menù

41

Finestre di dialogo

Azioni
Barra strumenti

Narrazione

Documento

Desktop

Menù

• • • • • • • •

Avvia Konqueror ed espande la Vedo sul desktop l'icona browser, finestra ed inserisce l'indirizzo quindi...uso questo per la navigazione.. Compila il modulo Scorre i menù superiori Va sul menù impostazioni Registriamoci... Leggo..indirizzo, visualizza... modifica,

Se devo stampare mi viene automatico andare sul menù impostazioni, provo un po' tutto..

Va sull' icona della stampante Ecco, c'è l'icona...però nella barra degli strumenti Va sul menù indirizzo e vede la Ah, ecco, indirizzo. File, giustamente voce stampa in italiano..essendo abituato all' inglese...stampa Controlla la stampante È la laser..

Va sulla voce proprietà e Vediamo la voce proprietà, si è controlla le voci simile...tutto a posto. Va su opzioni di sistema Sbircio su opzioni di sistema, per curiosità. Si può anche modificare, modifiche avanzate, non sono standard, non sono immediate di comprensione. Vabbè, clicca su stampa.

• •
Clicca su stampa

Questo soggetto ha eseguito lo scenario con una attenzione maggiore. Non ha avuto difficoltà ad individuare il browser, ma ha avuto difficoltà quando si è trattato di dover stampare il documento. Prima ha cercato nel menù impostazioni invece che nel menù indirizzo, poi ha trovato l’ icona della stampante nella barra degli strumenti. Successivamente ha esplorato tutte le opzioni della finestra di dialogo della stampa, non perché non riuscisse a trovare il pulsante di stampa, ma per iniziativa personale.

42

4.6.2 Scenario 2
Menù applicazione Finestre di dialogo

Azioni
Barra strumenti Menù desktop Programmi

Narrazione

Documento

Va sul menù indirizzo

• •

Devo salvarlo, quindi vedo se c'è qualcosa sulla barra dei menù, indirizzo, salva con nome

Seleziona l'icona del desktop Voglio salvare sul desktop per dalla finestra di salvataggio essere più veloce, leggo desktop, quindi mi fido... Punta sull' icona crea nuova cartella, attende finché non esce il tip in sovrimpressione, poi inserisce il nome di una nuova cartella Va sul menù superiore e cerca di selezionare modifica /seleziona tutto, ma sono inattivi. Esce l'aiuto, si capisce, inserisco il nome, ora sono dentro una cartella, inserisco il nome e premo salva, non uso “filtri”, perché non capisco a cosa si riferisca. Ora, visto che il browser legge direttamente i pdf, cosa strana.. mi sembra che qui è proprio integrato, non faccio nulla. Adesso faccio modifica/seleziona tutto..è inattivo Menù visualizza, strumenti, no..

• • • • • •

Prova con altri menù

Cerca di selezionare il testo con No, non è selezionabile. il mouse Scorre il menù dei programmi Individua la voce Acrobat Reader Cerco un programma fatto apposta.

Adobe Acrobat, questo legge i pdf! tutto,

Clicca su seleziona tutto dal Seleziona seleziona menù modifica. modifica, lo copio..

Cerca un programma di Ora dovrei copiarlo in word o videoscrittura, quindi cerca nel qualcosa del genere, quindi menù alla voce “editor”5 cerco un editor di testo..

5La differenza tra un editor e un programma di videoscrittura come word o OpenOffice Writer è sottile ma sostanziale. Un editor apre e salva qualunque file come se fosse puro testo. E' per lo più usato per editare file contenti solo testo senza formattazione, come file di configurazione o codice sorgente. Non si tratta quindi di programmi adatti allo scopo.

43

Menù applicazione

Finestre di dialogo

Azioni
Barra strumenti Menù desktop Programmi

Narrazione

Documento

• •

Apre più editor di testo e prova Non ci sono le interlinee, a selezionare.doc come questo non salva in .doc o formato. altro.. Cerca nel menù un programma OpenOffice, questo lo fa.. di videoscrittura e seleziona Openoffice Writer. Va sul menù modifica e clicca Quindi incollo e vado su incolla modifica e quindi incolla..fatto, è molto simile all' office, ma la grafica è un po' diversa e c'è qualche menù di aiuto in più. Va su file e poi su salva con Salvo, propone lui le estensioni nome. quindi sono sicuro di salvare in formato doc..è intuitivo, salva. Cerca un’ icona che permetta di inviare il file via mail senza avviare il programma di posta elettronica. Potrei usare un programma di posta per inviarlo, però potrei vedere se c'è un interfacciamento con il programma, mi aspetto..le icone bisogna conoscerle. Sarà nel menù strumenti.

• • •

Va sul menù strumenti

Va sulla voce mail marge e la Mail merge... esplora. Alla fine quando gli viene richiesto di connettersi ad un database, esce. Va nel menù file, poi modifica e visualizza. Ritorna nel menù file, poi trova la voce invia e invia per e-mail, quindi apre la finestra di composizione di kmail Attiva kmail Do' un' occhiata veloce.. esporta, visualizza, qui non me lo aspetto..manda, manda per e-mail...c'era il tastino, ho sbagliato io. Io vedo che ha messo l'allegato, quindi è stato facile.

44

Menù applicazione

Finestre di dialogo

Azioni
Barra strumenti Menù desktop Programmi

Narrazione

Documento

Preme il pulsante con i puntini di sospensione accanto ai campi che contengono i destinatari, e cliccando su “a” trasferisce gli indirizzi nella casella degli indirizzi selezionati.

Aggiungo i destinatari, a, e clicco, ok, meglio che nell' outlook questa cosa, riconoscimento automatico.

Clicca sul pulsante invia, senza Inviato. esitare.

Questo soggetto ha effettuato questo compito in modo del tutto differente rispetto agli altri utenti. L’ utente ha cercato di selezionare il testo direttamente dal visualizzatore di file pdf, facendo uso del menù modifica/seleziona tutto (inattivo). Poi ha cercato tra gli altri menù, infine ha provato a selezionare il testo con il mouse. Si tratta dello stesso tipo di breakdown legato agli aspetti diretti verso il soggetto/oggetto. L’utente comprende che l’operazione non è eseguibile e cerca un altro metodo: cerca un programma adeguato nel menù dei programmi. Trova quindi Adobe Acrobat Reader, e con l’utilizzo del menù modifica copia il testo. Si mette quindi alla ricerca di un programma di videoscrittura. Esplora il menù dei programmi di KDE partendo dall’ alto, ignora il link ad OpenOffice e va nella voce editor. Prova quindi vari editor come Kwrite e Kate, ma si accorge che questi programmi non sono adatti a salvare in formati come il .doc ma solo in .txt, ovvero puro testo senza formattazione. In questi programmi tutte le operazioni legate agli handling aspects sono state eseguite correttamente, ma non sono in grado di portare a termine il compito: si tratta di breakdown legati agli aspetti diretti verso il soggetto/oggetto. Dopo aver compreso il problema l’utente ha trovato OpenOffice nel menù dei programmi ed ha incollato il testo dal menù modifica. Dopo aver salvato il file ha cercato un modo per inviarlo. Invece di andare alla ricerca di un programma di posta elettronica, dopo aver visto il grado di integrazione dell’ interfaccia, ha pensato di trovare un modo per inviare il file direttamente da OpenOffice. Trova dunque una voce mail merge nel menù strumenti. Non si tratta dell’ operazione corretta. Solo quando si è trovato di fronte ad una finestra che gli ha chiesto che tipo di database voleva importare allora ha rinunciato. Solo allora ha notato nel menù file la voce invia per e-mail6. Da questo punto ha aperto una finestra di composizione di un nuovo messaggio di kmail, in cui il file salvato in formato doc è stato allegato in automatico. Allora ha cliccato sui pulsanti con i puntini di sospensione accanto ai campi di testo con i nomi dei destinatari, esprimendo anche la sua soddisfazione. Questo soggetto non ha avuto bisogno di passare dalla rubrica per inserire gli indirizzi dei destinatari, quindi quello che per gli altri soggetti è diventato un breakdown per lui è stata una operazione facilmente eseguibile. L’utente ha quindi inviato il file individuando facilmente il pulsante corretto.

6

Questa voce è presente nello stesso menù anche in Microsoft Office.

45

4.6.3 Scenario 3
Finestra Di Dialogo

Azioni

Narrazione

Barra Superiore

Configurazione

Voci Finestra

Opzioni

Menù

• • • • • • • • • • •

Apre kmail. Va sul menù file. Esplora i menù.

Io seguo le impostazioni di outlook, file/nuova identità no...no... Modifica, visualizza, strumenti, impostazioni...o è file nuova finestra... finestra No, no...impostazioni di kmail trovato,

Apre una identifica.

nuova

Apre le impostazioni e va su Gestione identità, identità, seleziona identità con nuova identità. campi vuoti. Inserisce e cognome. Nome. Indirizzo elettronica. di

posta

Va su tutte le altre tab e esplora Cartella posta inviata, questa è le opzioni... nuova, non ho mai...va tutto bene. Clicca su modifica sezione identità. Clicca su profili... nella Ora se devo gestire le impostazioni.. dovrei fare modifica, non è... deve stare in carica profilo, no...

Va sul menù file e su altri menù Controlla posta...no Torna alle impostazioni e va Ok, rete...ricezione, spedizione, nella voce “rete”. tutto compreso qua dentro, perfetto..è quello che mi interessa Va su aggiungi e poi su smtp. Inserisce l'indirizzo del server. Va su ricezione e poi pop Chiude la impostazioni finestra Aggiungi...smtp... Allora..qua è il nome host..no? Questa cosa è più facile. Ricezione, aggiungi, memorizza la password.. delle Chiudo.. 46 pop,

• • • •

Questo soggetto è stato l’unico in grado di eseguire questo scenario senza alcun aiuto esterno. Per prima cosa anche questo utente ha cercato una voce appropriata dal menù file, passando poi ad esplorare gli altri menù, fino ad individuare la voce corretta nel menù impostazioni. Ha quindi creato una nuova identità, esplorando anche tutte le opzioni di propria iniziativa. In seguito ha cercato di capire dove impostare gli indirizzi per la ricezione e la spedizione. Qui si è verificato un altro breakdown riguardante gli handling aspects. Ha cercato di modificare l’identità creata, o di caricare un profilo utente, poi ha controllato gli altri menù della schermata principale di kmail. Alla fine nella finestra delle impostazioni ha individuato la voce rete, e attivandola ha scoperto le tab ricezione e spedizione. Ha inserito gli indirizzi dei server e ha anche esplorato tutte le opzioni presenti.

4.6.4 Considerazioni
Questo soggetto è probabilmente quello più interessante. Si tratta dell’ utente con più esperienza e corrisponde al gruppo degli utenti professionali di cui si è parlato nel paragrafo 3.1.3. Il soggetto ha cercato di capire come funzionasse l’interfaccia e di individuare percorsi alternativi più brevi per raggiungere lo scopo, ad esempio quando ha cercato di allegare il file direttamente da OpenOffice senza passare da un programma di posta elettronica. Il soggetto è stato l’unico in grado di completare tutti gli scenari senza alcun aiuto esterno. Alla fine il risultato è stato raggiunto, ma in alcuni punti l’oggetto non era il documento su cui si lavorava, ma l’interfaccia stessa: l’utente è andato alla ricerca di problemi, alternative e opzioni di propria volontà senza che si verificassero problemi. Stava compiendo autonomamente dei focus shift per l’apprendimento. Alla fine infatti è stato prolifico di osservazioni, consigli e critiche. Questo soggetto sarebbe l’utente ideale di KDE, dato lo spirito critico e la capacità di cercare nuove soluzioni.

47

5

Conclusioni

Bødker (1995, p. 157) scrive: “employees used VIRK in may ways . Some people used the full capabilities, but only a few knew what these full capabilities were…VIRK could provide many of the functions that the people asked for, but they did not know how to access them.” KDE si trova in una situazione non molto dissimile. Esso è pieno di funzionalità, ma gli utenti non sono in grado di individuarle. La domanda iniziale che ci si è posti nel paragrafo 2.3 chiedeva se fosse possibile migrare da una interfaccia proprietaria come Windows a KDE senza traumi eccessivi. In altre parole l’ipotesi iniziale dell’ esperimento era “è possibile che utenti abituati ad una interfaccia grafica proprietaria possano interagire in modo fluido e trasparente con KDE senza dover ristrutturare le loro azioni e cambiare le catene di operazioni che le compongono?” La risposta, detta in una sola parola, è no. Ma questa affermazione è completa solo per rispondere all’ ipotesi iniziale. Lo scopo dell’ analisi effettuata non era solo ottenere una risposta univoca: sarebbe bastato anche un solo errore di un solo soggetto per falsificare l’ipotesi. Quello che si voleva trovare erano dati qualitativi sull’ uso di KDE. Bisognava scoprire non solo se ci fossero problemi, ma dove fossero localizzati, perché esistevano, da cosa fossero causati e soprattutto quali utenti correvano il rischio di incontrarli e di vederli come problemi insormontabili. I maggiori problemi sono causati dalla differenza tra KDE e le interfacce cui la maggior parte delle persone è abituata. Avendo associato certe icone o menù a certe operazioni all’ inizio può risultare difficile abituarsi a KDE. L’unica cosa di cui si ha bisogno è la pratica quotidiana. La pratica è ciò su cui si concentra l’activity theory, è ciò che automatizza le operazioni e affina le skill degli utenti. L’importanza dell’ esperienza è stata sottolineata dai soggetti stessi che si sono prestati per il test. Questo è valido per i compiti e i task più semplici e meglio definiti. Il problema di KDE nasce invece dove si vogliono inserire più funzionalità possibili, magari con l’intento di essere competitivi. Tuttavia l’entusiasmo che si ha nella programmazione delle funzionalità porta a tralasciare problemi importanti. Le funzionalità avanzate devono essere inserite con cura e soprattutto separate da quelle fondamentali: l’utente comune non dovrebbe trovarsi di fronte ad impostazioni avanzate senza volerlo, ma l’esperto dovrebbe essere in grado di trovarle facilmente. Le impostazioni avanzate dovrebbero fornire comunque degli aiuti ulteriori: per esempio termini tecnici intraducibili in altre lingue dovrebbero essere accompagnati da delle perifrasi. Non c’è una ricetta per far migliorare l’usabilità di KDE. Si può comunque affermare che questo miglioramento sta veramente avvenendo. Il rapido rilascio di nuove versioni e la partecipazione di nuovi stakeholder al progetto porta i suoi frutti. E’ necessario che i programmatori per primi percepiscano il problema dell’ usabilità fin dal concepimento dei loro programmi, se vogliono veramente che il loro uso non sia destinato ad una nicchia ristretta. La maggior attenzione verso l’utente finale e il feedback degli utenti faranno il resto. Non si insiste a discutere se KDE sia un programma valido, e non si intende fare proselitismo. Se KDE vale davvero qualcosa, allora lo dimostrerà da solo.

48

Appendice
Screenshot dei breakdown rilevati.

Fig. 1 – Pop-up con richiesta di conferma all’uscita del browser Konqueror

Fig. 2 - Barra inferiore di KDE (l’icona a forma di casa rappresenta i file personali)

Fig. 3 – Icona della stampante nella barra degli strumenti di Konqueror

49

Fig. 4 – Le opzioni copia e incolla non sono attive

Fig. 5 – Schermata principale di Konqueror

50

Fig. 6 – La configurazione di nuove identità in kmail

Fig 7 – Impostazioni per la ricezione dell’ e-mail

51

Fig. 8 – Aggiunta degli indirizzi al campo dei destinatari

Fig.9 – Invio del file direttamente da OpenOffice 52

Bibliografia
• Carrol, John M. Five Reasons for scenario-based design, Proceedings of the 32nd Hawaai International Conference on System Sciences, 1999 • Carrol, John M. Requirements development in scenario based-design, IEEE Transactions on software engineering, vol. 24 no. 12, december 1998 • • • Eco, Umberto Come si fa una tesi di laurea, Bompiani 2004 McBurney, Donald H. Metodologia della ricerca in psicologia, Il Mulino 2001 Nardi, Bonnie A. (a cura di) Context And Consciousness - Activity theory and HumanComputer Interaction, The MIT Press 1996 • Newman, William M., Lamming, Michael G., Interactive System Design, Addison Wesley 1995 • Save, Luca Cognizione umana e procedure: un approccio storico-culturale al design dei processi produttivi, Tesi di dottorato in Telematica e Società dell’Informazione (XV Ciclo), Università di Siena 2003

Webgrafia
• AA. VV. KDE: Unix for the user http://developer.kde.org/~ctibirna/altlin/conf/index.html • AA.VV. GNOME Usability Study Report http://developer.gnome.org/projects/gup/ut1_report/report_main.html • AA.VV. KDE Human Interface Guideline http://developer.kde.org/documentation/standards/kde/ style/basics/index.html • Eklund, Susanne, Feldman, Michal, Trombley, Mary StarOffice Calc v. MS Excel: Improving the Usability of an Open Source Spreadsheet Application, School of Information Management and Systems, University of California, Berkeley 2001 http://www.sims.berkeley.edu/courses/is271/f01/projects/StarCalc/Final_Report.pdf • Everitt, Katherine, Lederer, Scott A comparision of Sun StarOffice Writer 5.2 vs. Microsoft Word 2000, School of Information Management and Systems, University of California, Berkeley, 2001 http://www.sims.berkeley.edu/courses/is271/f01/projects/WordStar/wordvstar.pdf

53

Horstmann, Jutta, Muehlig, Jan, Brucherseifer Eva, Ackermann Ralf Linux Usability Study Report Version 1.01, Relevantive 2003 http://www.linux-usability.de/download/linux

Job-Sluder, Kirk, Hanek, Greg, Zhang, Hong R685 Final Project Report, User needs for bibliographic software http://www.jobsluder.net/~kirk/OpenSource/OpenOffice_User_Needs03050 9.pdf

Nielsen, Jacob Are users stupid? http://www.useit.com/alertbox/ 20010805.html Nielsen, Jacob First Rule of Usability? Don’t Listen to Users http://www.useit.com/alertbox/20010204.html Nielsen, Jacob Ratings for Usability Problems http://www.useit.com/papers/heuristic/ severityrating.html

Pastel, Robert Desktop Environment as a Problem Solving Tool http://www.cs.mtu.edu/~rpastel/Research/Documents/DesktopEnvironmentasaProblemSolvi ngTool.pdf

Roe, Benjamin Usable GUI design: a quick guide for F/OSS Developers http://benroe.com/files/gui.html

Rogers, Ivonne New theoretical approaches for hci, Interact Lab, School of Cognitive and Computing Sciences, University of Sussex 2004, http://www.slis.indiana.edu/faculty/yrogers/papers/ARIST_Rogers.pdf

Spolsky, Joel User Interface Design for Programmers, Apress 2001 http://www.joelonsoftware.com

Turner, Jonathan KDE 3.3 Usability Study and Review http://www.userinstinct.com/viewpost.php? postid=kde33review, 2004

Twidale, Michael B., Nichols David M. Usability Discussions in Open Source Development, Department of Computer Science, University of Waikato, Hamilton, New Zealand 2004 http://opensource.mit.edu/papers/twidalenichols.pdf

Twidale, Michael, B., Nichols David M. Usability and Open Source Software,Department of Computer Science, University of Waikato, Hamilton, New Zealand 2004 http://opensource.mit.edu/papers/nicholstwidale1.pdf 54