ESB Forum
ISSN: 2283-303X |
||
I siti web delle biblioteche veneteAnalisi, censimento e valutazioneversione ridotta della tesi di laurea in biblioteconomia, Corso di laurea in Conservazione dei Beni Culturali, Facoltà di Lettere e Filosofia dell'Università degli studi di Venezia Ca' Foscari, relatore prof. Riccardo Ridi, correlatore dott. Giorgio Busetto, anno accademico 1999/2000, discussa il 22 febbraio 2001. di Sara Franzoso (in linea da aprile 2001)
§9. Testing del sito
Spesso la fretta di avere un sito in linea il prima possibile non permette di
dedicare alla verifica della sua usabilità il tempo necessario, mentre
è importantissimo che la versione definitiva venga testata su un
campione di utenti prima di renderla disponibile in Rete. Anche in questo
caso la letteratura del settore fornisce numerosi esempi di griglie e
questionari da sottoporre allâutenza, allo staff ed anche a un campione di
esperti informatici e designer. Di certo è importante, per evitare i
problemi di accesso e usabilità di cui si è appena parlato, che
questi ultimi verifichino il buon funzionamento della tecnologia del sito, ma
lo è soprattutto che siano gli utenti, i veri destinatari, a confermare
la sua usabilità o suggerire dei miglioramenti.
"salvaguardare lâesperienza di visita e di uso del sito, per un verso, e contribuire ad avere successo nel conseguimento della missione del sito, per lâaltro verso"[1] perciò nel garantire, ancora una volta, lâusabilità del sito, perché chiunque possa accedervi, e ottenere ciò che cerca, facilmente. Egli, infatti, prosegue dicendo
"Questa è, ritengo, la ragione prioritaria per valutare e misurare lâusabilità: migliorare la qualità dellâesperienza del sito"[2]La misurazione dellâusabilità dei siti può essere fatta con software appositi[3], ma la cosa migliore è verificare che gli utenti, in particolare quelli abituali, che sono di certo più facili da coinvolgere, siano in grado di sfruttare al meglio tutte le potenzialità del sito e vi trovino davvero lâinformazione che cercano, senza doversi rivolgere ad altre fonti. Il testing andrebbe fatto prima di mettere il sito in linea e, successivamente, a intervalli regolari, per verificare il corretto funzionamento dei suoi diversi settori o lâinsorgere negli utenti di nuove esigenze da soddisfare. GARLOCK PIONTEK [1996][4], METZ JUNION METZ [1996][5] e VISCIOLA [2000][6] propongono delle strategie di valutazione e danno unâidea del tipo di questionario che si deve elaborare per la valutazione. Raccomandano di ripetere spesso il test, perché lâutenza cambia e si evolve, perciò il sito dovrà cambiare ed evolversi in conformità alle esigenze di questâultima. Inoltre, testando periodicamente il sito si scopriranno sempre sezioni da rinnovare, eliminare, aggiungere. Si dovrebbe preparare un test di usabilità per lâutenza e uno per lo staff, che andranno ovviamente differenziati non solo perché il tipo di risorse sul sito cui accedono le due categorie è diverso, ma anche perché differente è, sotto certi punti di vista, lâuso che ne fanno. GARLOCK PIONTEK [1996] propone due metodi di valutazione. Il primo, che non coinvolge lâutenza, parte da tre diversi punti vista per compiere lâanalisi, uno economico, che valuta quanto il sito à costato alla Biblioteca in termini di denaro e tempo, in modo da poter in seguito verificare se le spese sostenute siano state eccessive rispetto al servizio fornito; uno che prende in considerazione i benefici tratti dallo staff dallo studio delle risorse Internet al fine di applicare le conoscenze ricavate alla creazione e al mantenimento del sito, valutazione, questâultima, consigliata soprattutto quando lo staff development (sviluppo dello staff) è tra gli obiettivi del sito. Lâultimo punto di vista proposto per lâanalisi del sito considera le risorse che si sono rese disponibili su di esso, paragonandole a quelle già presenti in Biblioteca, per verificare quali si sono dimostrate inefficaci in formato elettronico e migliori in formato cartaceo e viceversa. Il secondo metodo proposto per testare il sito coinvolge gli utenti e prevede la creazione di un indirizzo e-mail o di una pagina con un form per inserire i propri commenti, tramite la quale gli utenti possano far pervenire alla Biblioteca i loro suggerimenti per migliorarlo. Questa proposta [7] si ritrova in molti altri degli autori analizzati, i quali considerano il feedback che si può ricavare da questi messaggi fondamentale perché il Web della Biblioteca si sviluppi coerentemente con le esigenze degli utenti. Le statistiche sul numero di accessi alle pagine del sito possono rivelarsi utili, anche se non bisogna dare troppo credito ai contatori di accessi, che segnalano quanti utenti sono entrati nel sito, ma non possono appurare se costoro si sono trattenuti per visitarlo e servirsene o se invece vi sono soltanto passati per accedere ad altre risorse tramite la pagina dei link verso lâesterno. Può essere utile, comunque, valutare se il sito è usato per se stesso o piuttosto come porta dâaccesso ad altre risorse della Rete. METZ JUNIONMETZ [1996] propone innanzi tutto di testare il sito prima di metterlo in linea[8], da parte dello staff e degli utenti insieme: si può formare un gruppo di valutazione che verifichi la correttezza ortografica e sintattica dei testi, la coerenza interna delle pagine, la corretta organizzazione dellâinformazione e delle varie sezioni, la facilità di recupero dellâinformazione e di visualizzazione con qualsiasi browser, il corretto funzionamento dei link (anche se questo è uno dei compiti di mantenimento che spetta allo staff responsabile)...Gli autori sono molto precisi nello stabilire le condizioni in cui il test si deve svolgere: scelto un gruppo di utenti, si deve dar loro un tempo prestabilito per visitare il sito, non troppo lungo (meno di unâora, secondo quanto consigliano gli autori[9]) perché non familiarizzino troppo con lâambiente e non siano più in grado di fornire risposte utili alla Biblioteca, ma anche perché così si potrà sottoporre il test ad un numero maggiore di utenti ed avere un riscontro più ampio dellâimpatto del sito. Gli autori propongono poi una serie articolata di domande da porre al campione di utenti, precisando che tutte richiedono una risposta articolata e non possono essere evase con un semplice "sì" o "no" e che è bene spingere sempre a completare la risposta con un suggerimento per migliorare il servizio. METZ JUNIONMETZ [1996] raccomanda di fare anche un testing con gli utenti abituali della Biblioteca[10], scegliendo tra essi dei campioni rappresentativi: persone di tutte le età nel caso di una Biblioteca pubblica, studenti di diverse facoltà, matricole e laureati, docenti e personale amministrativo per le biblioteche di ateneo. In ogni caso, si dovrà testare lâimpatto del sito sia su persone esperte nellâuso del computer e della Rete, sia su neofiti. Secondo VISCIOLA [2000], infatti,
"Il successo del sito va misurato sulla capacità di soddisfare lâutente medio con scarse o nulle competenze e abilità tecnologiche." [11]
Lâautore spiega che non si otterrà mai un sito usabile finché
mancherà "una verifica attenta dei bisogni informativi che il
sito vuole soddisfare"[12], perciò la
Biblioteca deve fare molta attenzione a tutti i suggerimenti provenienti
dagli utenti.
"[...] lâesperienza di interazione in un sito è aperta a troppe variabili soggettive per poter essere sintetizzata in valori numerici."[14]
VISCIOLA [2000] propone comunque dei metodi di valutazione dellâusabilità
del sito, come il cognitive walkthrough, che "si basa sullâ
osservazione delle modalità di esplorazione delle interfacce da parte
dellâutente finale"[15], o il walkthrough
pluralistico, che si basa invece sul confronto delle valutazioni compiute
da tre diversi esperti, ai quali viene affidata lâanalisi di un solo aspetto
del sito: per esempio la valutazione del sistema di navigazione, la
valutazione del motore di ricerca e quella dellâusabilità della
struttura delle informazioni: confrontando queste tre analisi, da compiere
nello stesso arco di tempo e secondo lo stesso metodo di rappresentazione dei
risultati, in modo da garantire la confrontabilità, Visciola ritiene
si possano ottenere dati molti utili[16]. Un altro dei
metodi proposti è la "verifica dei risultati del motore di
ricerca", il cui obiettivo è "far sì che ciò
che si otterrebbe navigando liberamente nel sito venga ottenuto, in minor
tempo e in modo esaustivo, interrogando il motore di ricerca"
[17]. Infine, lâautore spiega come realizzare il test
secondo le regole dellâingegneria dellâusabilità[18]
, specificando che bisogna decidere prima di tutto quali aspetti
dellâinterfaccia si vogliono analizzare e individuando tre fasi di lavoro:
preparazione e conduzione del test e comunicazione dei risultati. Il test
proposto prevede che si assegnino dei compiti ad un campione di utenti, che
viene lasciato libero di scegliere il modo in cui svolgerli. Nella fase di
conduzione del test è importante che lâutente sia rassicurato sul
fatto che non si sta indagando sulla sua capacità di svolgere i
compiti che gli sono stati assegnati, ma piuttosto sulla capacit dellâ
interfaccia di metterlo nelle condizioni di "portare agevolmente a
termine il proprio compito"[19].
NOTE [1] VISCIOLA [2000], p. 143144. [2] VISCIOLA [2000], p. 144. [3] Alcuni sono disponibili in Rete, come Doctor HTML, Validator del W3C o Bobby. [4] GARLOCK PIONTEK [1996], p. 6568. [5] METZ JUNIONMETZ [1996], p. 161174. [6] VISCIOLA [2000], p. 143159. [7] Si veda anche cap. I, par. 4. [8] METZ JUNIONMETZ [1996], p. 93. A questo proposito VISCIOLA [2000] propone di valutare il sito prima di metterlo in linea, durante la progettazione, cioè nei tre momenti critici di questa seconda tappa (fase dei primi prototipi, fase di sviluppo delle interfacce, fase di collocamento in Rete) e dopo, poiché "una volta che il sito ha ricevuto tutte le attenzioni necessarie per rispondere ai bisogni degli utenti finali, è opportuno verificare che tutto vada per il meglio e secondo quanto desiderato."; VISCIOLA [2000], p. 148. [9] METZ JUNIONMETZ [1996], p. 161. [10] METZ JUNIONMETZ [1996], p. 173. [11] VISCIOLA [2000], p. 145. [12] VISCIOLA [2000], p. 145. [13] SPOOL [1999], p. 14. [14] VISCIOLA [2000], p. 143. [15] VISCIOLA [2000], p. 151. [16] VISCIOLA [2000], p. 150 e 152153. [17] VISCIOLA [2000], p. 153. [18] VISCIOLA [2000], p. 154 e segg. [19] VISCIOLA [2000], p. 156. [20] NIELSEN [2000], p. 311.
|
| © ESB Forum | a cura di Riccardo Ridi | |