ESB Forum ESB Forum
ISSN: 2283-303X

I siti web delle biblioteche venete

Analisi, censimento e valutazione


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

ANALISI E VALUTAZIONE

§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.
VISCIOLA [2000] si sofferma prima di tutto sui motivi che spingono alla valutazione del Web, individuandoli principalmente nel

"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 ­ JUNION­METZ [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 ­ JUNION­METZ [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.
Nonostante, però, lâimportanza attribuita ai contenuti del sito come risposta alle esigenze informative dellâutente, concetto valido sia per un sito culturale che per uno commerciale, dallâindagine di SPOOL [1999] risulta che non tutti gli utenti preferiscono i siti in cui riescono a trovare ciò che cercano, in cui, cioè, capiscono come muoversi e riescono a soddisfare le loro esigenze: molti mostrano più interesse per i siti meno usabili, giudicandoli interessanti, anche se si sono persi e non hanno ottenuto nessun risultato concreto[13]. Visciola [2000] conferma le conclusioni di Spool, affermando che la valutazione del Web è molto soggettiva, perché

"[...] 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].
Concludendo, sembra importante il suggerimento, dato da NIELSEN [2000], di fare dei test del sito anche con utenti con diversi tipi di invalidità [20]: farne valutare la grafica da persone con problemi visivi, la leggibilità con sintetizzatori vocali per persone cieche, la possibilità di navigare facilmente anche senza usare il mouse, la visualizzazione sul display di un telefono cellulare, ecc.


NOTE

[1] VISCIOLA [2000], p. 143­144.

[2] VISCIOLA [2000], p. 144.

[3] Alcuni sono disponibili in Rete, come Doctor HTML, Validator del W3C o Bobby.

[4] GARLOCK ­ PIONTEK [1996], p. 65­68.

[5] METZ ­ JUNION­METZ [1996], p. 161­174.

[6] VISCIOLA [2000], p. 143­159.

[7] Si veda anche cap. I, par. 4. [8] METZ ­ JUNION­METZ [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 ­ JUNION­METZ [1996], p. 161.

[10] METZ ­ JUNION­METZ [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 152­153.

[17] VISCIOLA [2000], p. 153.

[18] VISCIOLA [2000], p. 154 e segg.

[19] VISCIOLA [2000], p. 156.

[20] NIELSEN [2000], p. 311.


PRECEDENTE - INDICE - SUCCESSIVO
| © ESB Forum | a cura di Riccardo Ridi |