Sei sulla pagina 1di 54

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

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

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 KDE 1 .

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:“

Level of support: “to fill the need for an easy to use desktop”.

Supported activity: “

E, nel secondo paragrafo:

Performers of activity (users): “

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.

is

a network

similiar

desktop

enviroment for UNIX workstation”.

to the desktop enviroments found under the MacOS

to

the average computer user

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)

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

un processo di progettazione a cascata: Analisi dei requisiti Design Implementazione Validazione Rilascio e manutenzione 4

Design

un processo di progettazione a cascata: Analisi dei requisiti Design Implementazione Validazione Rilascio e manutenzione 4

Implementazione

un processo di progettazione a cascata: Analisi dei requisiti Design Implementazione Validazione Rilascio e manutenzione 4

Validazione

un processo di progettazione a cascata: Analisi dei requisiti Design Implementazione Validazione Rilascio e manutenzione 4

Rilascio e manutenzione

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 è

presente un gran numero di differenze sia nelle funzionalità che nel look&feel 2 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
Più cicli di design
Valutazione
Analisi dei requisiti
Design/Redesign
design Valutazione Analisi dei requisiti Design/Redesign Implementazione Validazione Implementazione La principale

Implementazione

Analisi dei requisiti Design/Redesign Implementazione Validazione Implementazione La principale caratteristica del

Validazione

dei requisiti Design/Redesign Implementazione Validazione Implementazione La principale caratteristica del processo

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.

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 Report di Prototipo usabilità Redesign
Valutazione
Report di
Prototipo
usabilità
Redesign
Definizione del problema
Definizione
del
problema
Requisiti
Requisiti

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.

Analisi dei requisiti

Analisi dei requisiti Design Implementazione Validazione Rilascio e manutenzione

Design

Analisi dei requisiti Design Implementazione Validazione Rilascio e manutenzione

Implementazione

Analisi dei requisiti Design Implementazione Validazione Rilascio e manutenzione

Validazione

Analisi dei requisiti Design Implementazione Validazione Rilascio e manutenzione

Rilascio e

manutenzione

Redesign Nuovi requisiti Valutazione
Redesign
Nuovi requisiti
Valutazione
e manutenzione Redesign Nuovi requisiti Valutazione Il processo inizia con l’analisi dei requisiti: questa
e manutenzione Redesign Nuovi requisiti Valutazione Il processo inizia con l’analisi dei requisiti: questa

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.

2

L'activity theory: introduzione

L’activity theory è un framework di ricerca utilizzabile nel campo dell’ interazione uomo- macchina 3 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
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.

Konqueror Utente documenti
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
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 Windowsvenga 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

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

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

i livelli gerarchici dell’ attività. ATTIVITA’ MOTIVO AZIONE FINE OPERAZIONE CONDIZIONE Si può comprendere come

AZIONE

FINE

gerarchici dell’ attività. ATTIVITA’ MOTIVO AZIONE FINE OPERAZIONE CONDIZIONE Si può comprendere come il confine

OPERAZIONE

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à

Motivo

LIVELLO DELL’

 

ATTIVITA’

Gestire la posta elettronica

 

Fine

LIVELLO DELL’ AZIONE

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

 

Condizione

LIVELLO

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

DELL’OPERAZIONE

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

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 esperimento 4 . 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)

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.

di report usato dall’ ispettorato del lavoro danese. Per supportare una analisi di questo tipo, basata

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.

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).

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.

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

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

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.

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 Utente Comunicazione
kde
Utente
Comunicazione

Struttura dell’ attività per un utente comune

Periferiche Utente KDE Struttura dell’ attività per un utente
Periferiche
Utente
KDE
Struttura
dell’
attività
per
un
utente

professionista

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

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.

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

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.

il nome è necessario cliccare sulla voce edit name. Per inserire un indirizzo invece, è possibile

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

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.

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.

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).

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 Scenario 1

Documento

Barra

strumenti

Menù

Desktop

Login/Logout

 

Azioni

 

Narrazione

 

Preme sull' icona del desktop

Devo compilare un curriculum, quindi devo cercare un browser

 

con la scritta web browser internet (avvia Konqueror)

Compila il modulo

 

Registriamoci

Inserisce l'indirizzo nella barra

Penso che sia questo, devo familiarizzare con le icone perché non le conosco

superiore e preme invio

 

Clicca

sull’

icona che

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.

rappresenta la stampante nella barra superiore, si apre una

finestra

di dialogo, quindi

 

preme stampa. La stampante si

 

avvia.

Clicca sulla croce in altro a destra e chiude Konqueror

Chiudo.

Compare una finestra di dialogo per chiedere la conferma della

Che devo fare, devo cliccare? Clicco chiudi. Sono rimasta bloccata, non me lo aspettavo, mi aspettavo spegni il computer.

 

chiusura. La legge. Poi clicca chiudi. Cerca di uscire da KDE, va sul pulsante in basso a sinistra (la K)

 

Scorre il menù di KDE, poi va su “termina sessione”

“Termina sessione”, sia questo.

penso che

 

Clicca

sulla

voce

“spegni

Si, ce l’ho fatta.

 

computer”

 

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

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

Documento

Finestre di dialogo

Barra degli strumenti

Barra inferiore

Menù

Desktop

 

Azioni

   

Narrazione

Apre il browser e va all' indirizzo dal quale scaricare il file pdf

Prima devo aprire il 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 clicca su salva con nome

Trovato. Vado su salva con nome

 

Inserisce

un

nome

al

file

con

Mi creo una cartella nuova e vado su ok

estensione pdf, va subito sul 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 su documenti

 

stessa icona

 
 

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

 

Documento

Finestre di dialogo

Barra degli strumenti

Barra inferiore

Menù

Desktop

 

Azioni

 

Narrazione

 
 

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.

Programma di posta

elettronica, browser web,

ho

capito, file personali, ah

 

ecco, perché?

 
 

Lo sperimentatore spiega qual’è la relazione tra la cartella dei documenti dell' utente e l' icona che rappresenta una casa

Ah, sì giusto. Facile. Devo

convertire

il

testo

in

un

programma

di

video-

scrittura.Quale sarà?

 

Clicca sull' icona del file salvato in

Questo, legge i file pdf, acroread. Devo copiare e incollare

precedenza e apre adobe acrobat reader.

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

 

Cerca sulla barra degli strumenti

Non c'è

 
 

Cerca

tra

i

menù.

Va sul menù

Seleziona

tutto,

l'

ho

 

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 che sia questo, ma mi accorgo che non è

 

matita sulla barra inferiore.

 

Documento

Finestre di dialogo

Barra degli strumenti

Barra inferiore

Menù

Desktop

Azioni

Narrazione

 
 

Clicca su programma terminale

Cosa

è?

Ma

c'è

il

 

programma?

 
 

Scorre il menù di KDE

Vado

a

cercarlo

tra

i

 

programmi.

 

Và nel menù programmi da ufficio. Apre Kword

Videoscrittura, c'è!

 
 

Si

apre

una

schermata “crea

Crea documento, voglio un testo semplice, vuoto.

 

e documento vuoto.

documento”

seleziona

un

 

Seleziona l' icona “incolla” sulla barra degli strumenti.

Allora, c'è l'icona di incolla attiva.

 

Seleziona “Salva con nome” dal menù e inserisce un nome di file seguito dall' estensione doc.

Ora salvo il documento in

formato

doc

salva

con

nome

punto

doc, e

poi lo

 

devo inviare.

 

Scorre i menù di Konqueror, poi lo chiude

Il mio programma di posta è sempre questo, Konqueror? Questo non è un programma di posta elettronica.

 

Cerca un programma di posta elettronica. Clicca sull' icona di Kmail sulla barra inferiore (l'icona è una E con una lettera).

Giustamente,

 
 

la devo inviare il

ora file come allegato

lettera

 

Clicca sul menù messaggio e clicca su nuovo.

Creo un nuovo messaggio

 

Clicca sul menù allega e poi su “allega file”, poi seleziona il file.

Allega testo.doc

 

Va sul menù opzioni.

Adesso

devo

trovare

la

 

rubrica

 

Va sul menù strumenti.

Rubrica

ok,

questi sono i

 

contatti

aspetta

 

Documento

Finestre di dialogo

Barra degli strumenti

Barra inferiore

Menù

Desktop

Azioni

Narrazione

 
 

Clicca su file e poi su importa.

 
 

Clicca sul pulsante aggiungi in basso a sinistra, poi chiude la finestra che si è aperta.

Aggiungi, aggiungi che?

Seleziona

il

tipo

della

 

rubrica

indirizzi?

Ho

   

sbagliato.

Prova a fare copia incolla ma non

Devo prendere l'indirizzo e metterlo nella lettera. Lo copio

ottiene risultati.

Chiude la finestra.

Ho bisogno di aiuto. Non so che ho combinato, ma mi sto divertendo.

Lo sperimentatore mostra il sistema 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.

Sì, così è più semplice.

 

Invia la mail cliccando sul pulsante di invio.

Bene, ora invio il tutto.

 

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

.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

Configurazione

Barra Superiore

Voci Finestra

Finestra Di Dialogo

Menù

Opzioni

 

Azioni

   

Narrazione

 
 

Riapre il programma di posta

Credo

di

dover

usare

il

elettronica

 

programma di posta elettronica per fare questo.

 

Cerca nel menù file

 

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

 

Scorre

tutte

le

voci

di

tutti

i

Modifica, visualizza… impostazioni

 
 

menù

 

Cerca tra i pulsanti della barra degli strumenti

Nuovo messaggio, invia …non è neanche qui

 

Chiede aiuto

 

Non so dove andare a mettere mano…cosa devo fare?

Lo sperimentatore mostra cosa fare.

Da impostazioni seleziona “impostazioni Kmail” e crea una nuova identità

Configurazione

Barra Superiore

Voci Finestra

Finestra Di Dialogo

Menù

Opzioni

 

Azioni

 

Narrazione

 

Inserisce nome e cognome

 

Ah, chiaro, pensavo di trovare qualcos’ altro…che le impostazioni fossero diverse. Bene, ma questi altri indirizzi dove vanno?

 

Va su modifica identità

 

Devo aggiungerli, dove vanno questi?

 

Chiede aiuto

 

Non

so

che

fare…mi

sono

 

bloccata.

Lo sperimentatore mostra cosa fare.

Invece che da identità accedi 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 qualsiasi per il provider, l’host è l’indirizzo del server.

differenza

 

Il soggetto compie le stesse

Adesso

la

stessa

cosa

deve

operazioni anche per impostare la spedizione.

per spedizione…host è l’indirizzo.

valere

anche

la

Chiude e cerca di scaricare la

Adesso provo a scaricare

la

mail individuando il pulsante per il download.

posta…

vediamo,

sembra

che

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

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.

4.5 Soggetto 2

4.5.1 Scenario 1

Documento

Finestre di dialogo

Barra strumenti

Menù

Barra inferiore

Desktop

 

Azioni

   

Narrazione

 

Clicca sull' icona di Konqueror

Cerco

un

programma

per

 

connettermi

 

Scorre la pagina di benvenuto

Questo non sembra quello che

 

serve a me

vediamo un po'

 

Scorre

le

icone

della

barra

Questo serve per mandare le e-

 

inferiore

mail

aiuto no

Punta su Konqueror nella barra inferiore.

Browser web, non era questo?

 

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 windows sarebbe più facile

su

 

Cerca nel menù strumenti

 

Cerco

 

Trova l' icona della stampante

Ah,

ecco

scusa

KDE,

non

 

sulla barra superiore e apre la finestra di dialogo.

l'avevo vista

Punta sui bottoni della finestra di dialogo, poi preme stampa.

Opzioni

no, stampa, si

 

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

Documento

Finestre di dialogo

Barra degli strumenti

Barra inferiore

Menù

Desktop

Azioni

 

Narrazione

 
 

Inserisce l'indirizzo del documento in Konqueror

Inserisco

l'indirizzo

 

del

documento

 

Sposta

il

puntatore

sul

Non è testo selezionabile

 

e selezionarlo senza riuscirci.

documento

cerca

di

 

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.

Chiude Konqueror e apre direttamente il file da dove era stato salvato usando Acrobat Reader.

Acrobat con

questo

credo

che

 

Cerca sulla barra superiore un modo per rendere selezionabile il testo, attivando la modalità esatta.

Ecco qua

 

Documento

Finestre di dialogo

Barra degli strumenti

Barra inferiore

Menù

Desktop

 

Azioni

   

Narrazione

 
 

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 Writer.

Openoffice e seleziono il writer.

 

Apre il menù con il tasto destro

Incolliamo.

 
 

e cerca la voce per incollare il testo.

 

Trova la voce incolla alla fine del menù e vi clicca sopra.

Fatto.

Va direttamente al menù file e seleziona salva con nome.

File/salva

 
 

Seleziona il tipo di formato dal menù a tendina.

Doc versione 97/2000/XP

 

Compare un pop-up che avvisa che salvando in questo formato alcune informazioni potrebbero andare perse

Mmm

salva comunque.

 
 

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

 

Dal

menù

allega

seleziona

Ora allega

file.

 
 

allega file.

   
 

Seleziona il file dalla finestra di dialogo

Seleziono il file da dove lo avevo salvato e via

 

Seleziona la rubrica dal menù strumenti

Ora

la

rubrica

strumenti,

 

rubrica

 

Documento

Finestre di dialogo

Barra degli strumenti

Barra inferiore

Menù

Desktop

 

Azioni

 

Narrazione

 
 

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 con il tasto destro.

Non così

 
 

Scorre il menù

 

Invia contatto

no

Torna sul menù di kmail

 

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 non è quello giusto)

Trovato, aggiungi. No.

 
 

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 sulla barra superiore

Io farei questo

 

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

(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

Configurazione

Barra Superiore

Voci Finestra

Finestra Di Dialogo

Menù

 

Azioni

 

Narrazione

 
 

Apre

kmail

e

va

sul

menù

Sarei andato su strumenti se si fosse trattato di outlook

 

strumenti.

 

Va su impostazioni / configura.

Impostazioni

configura

 

Si posiziona su “nuova identità” ed inserisce i dati.

Queste sono le identità

inserisco

il

mio nome e indirizzo e-mail

 

Va su modifica identità.

 

Devo modificarlo sicuramente.

 
 

Cerca nella voce avanzate.

 

Qua avrei dovuto mettere i server

 
 

Inserisce gli indirizzi nei campi della tab “avanzate”.

Metto qui, ma sono dubbioso.

 
 

Si evidenzia che la scelta corretta non è quella giusta.

Dove andavano messi?

 

Configurazione

Barra Superiore

Voci Finestra

Finestra Di Dialogo

Menù

 

Azioni

   

Narrazione

 
 

L'utente individua la scelta

Ah,

rete

non

dovevo

andare

su

 

corretta nella voce rete posta sotto la voce identità.

identità

 

Imposta gli indirizzi nella voce ricezione.

Host

deve

essere l'indirizzo

 

Imposta

gli

indirizzi

per

la

Spedizione

host

per la spedizione

 

spedizione.

   
 

Scarica la posta con il pulsante corretto sulla barra superiore.

A posto

 

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

Documento

Finestre di dialogo

Barra strumenti

Menù

Desktop

Azioni

Narrazione

Documento

Finestre di dialogo

Barra strumenti

Menù

Desktop

Azioni

 

Narrazione

 
 

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

Registriamoci

 

Scorre i menù superiori

Leggo

indirizzo,

modifica,

 

visualizza

 
 

Va sul menù impostazioni

Se

devo

stampare

mi

viene

 

automatico andare

sul

menù

 

impostazioni, provo un po' tutto

 
 

Va sull' icona della stampante nella barra degli strumenti

Ecco, c'è l'icona

però

 
 

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 controlla le voci

Vediamo la voce proprietà,

si

è

 

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.

Clicca su stampa

Vabbè, 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.

4.6.2 Scenario 2

Documento

Finestre di dialogo

Menù applicazione

Barra strumenti

Menù desktop

Programmi

 

Azioni

   

Narrazione

 
 

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 essere più veloce, leggo desktop, quindi mi fido

 

dalla finestra di salvataggio

 
 

Punta

sull' icona crea nuova

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.

cartella, attende finché non esce il tip in sovrimpressione, poi

 

inserisce il nome di una nuova cartella

 

Va sul menù superiore e cerca

Ora, visto che il browser legge

di

selezionare modifica

direttamente i pdf, cosa strana

/seleziona tutto, ma sono

mi

sembra che qui è proprio

 

inattivi.

 

integrato, non faccio nulla.

   

Adesso

 

faccio

modifica/seleziona tutto è

inattivo

 
 

Prova con altri menù

 

Menù visualizza, strumenti, no

Cerca di selezionare il testo con il mouse

No,

non è selezionabile.

 

Scorre

il menù dei programmi

Cerco

un

programma

fatto

 

 

apposta.

 
 

Individua

la

voce

Adobe

Acrobat, questo legge i pdf!

 

Acrobat Reader

 
 

Clicca

su

seleziona

tutto

dal

Seleziona seleziona tutto, modifica, lo copio

 

menù modifica.

 
 

Cerca un programma di

Ora dovrei copiarlo in word o qualcosa del genere, quindi cerco un editor di testo

 

videoscrittura, quindi cerca nel menù alla voce “editor” 5

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.

Documento

Finestre di dialogo

Menù applicazione

Barra strumenti

Menù desktop

Programmi

 

Azioni

 

Narrazione

 
 

Apre più editor di testo e prova

Non

ci

sono

le

interlinee,

 

selezionare.doc come formato.

a

questo

non

salva

in

.doc

o

 

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 modifica e quindi incolla fatto, è molto simile all' office, ma la grafica è un po' diversa e c'è qualche menù di aiuto in più.

 

incolla

 

Va

su

file e

poi

su salva con

Salvo, propone lui le estensioni quindi sono sicuro di salvare in

 

nome.

 

formato doc

è

intuitivo, salva.

Cerca

un’ icona che permetta di

Potrei usare un programma di posta per inviarlo, però potrei

inviare il file via mail senza

avviare il programma di posta elettronica.

vedere

se

c'è

un

 

interfacciamento con il

   

programma,

 

mi

aspetto le

icone bisogna conoscerle.

 
 

Va

sul menù strumenti

Sarà nel 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

Do'

un'

occhiata

veloce

e visualizza. Ritorna nel menù file, poi trova la voce invia e invia per e-mail, quindi apre la

esporta, visualizza, qui non me

 

lo aspetto

manda,

manda per

 

e-mail

c'era

il

tastino,

ho

finestra di composizione di kmail

sbagliato io.