Path: Home | Publications | Manuale | Indice | Capitolo 2

Manuale per la qualità dei siti Web pubblici culturali

2 La qualità nelle Applicazioni Web: principi generali e proposte operative

2.1 Introduzione

2.2 Accessibilità e usabilità

2.2.1 Accessibilità
2.2.2 L'usabilità
2.2.3 Processo di valutazione
2.2.4 Analisi da parte di esperti di fattori umani
2.2.5 Valutazione effettuata con l’utente
2.2.6 Elaborazione dei dati e rapporto conclusivo

2.3 Criteri di usabilità per le applicazioni web culturali pubbliche (AWCP)

2.4 Pattern e linguaggio di Pattern

2.4.1 Definizioni
2.4.2 Il Catalogo dei Pattern
2.4.3 Come utilizzare i Pattern
2.4.4 Un esempio d’uso del Catalogo dei Pattern

2.1 Introduzione
La legge 9 gennaio 2004 Disposizioni per favorire l’accesso dei soggetti disabili agli strumenti informatici (cosiddetta Legge Stanca) apre nuovi scenari nel mondo dei siti web delle pubbliche amministrazioni italiane perché, per la prima volta, un testo di legge definisce e individua espressioni quali “accessibilità” e “fruibilità”, le due caratteristiche fondamentali della qualità.

Si tratta di un provvedimento assolutamente in linea con gli indirizzi formulati dall’Unione Europea, che ha proclamato il 2003 “Anno europeo del disabile”, e che, attraverso la Comunicazione COM (2000)284, indirizzata dalla Commissione al Consiglio, al Parlamento europeo, al Comitato economico e sociale e al Comitato delle Regioni, aveva indicato la prospettiva di un’Europa senza ostacoli per i disabili. La legge si applica alle pubbliche amministrazioni centrali e locali, agli enti pubblici economici, alle aziende private concessionarie di pubblici servizi, alle aziende municipalizzate regionali, agli enti di assistenza e di riabilitazione pubblici, alle aziende di trasporto e telecomunicazione a prevalente partecipazione di capitale pubblico e alle aziende appaltatrici di servizi informatici.

Il provvedimento non costituisce una semplice “dichiarazione di principi”, ma introduce una serie di obblighi con prescrizioni dettagliate in merito ai requisiti di accessibilità che devono possedere i sistemi informatici in generale e i siti web in particolare.
L’8 agosto 2005 è stato pubblicato sulla Gazzetta Ufficiale il Decreto ministeriale a firma del Ministro Stanca (completo di allegati), che stabilisce le linee guide recanti i requisiti tecnici e i diversi livelli per l’accessibilità e le metodologie tecniche per la verifica della accessibilità dei siti Internet, nonché i programmi di valutazione assistita utilizzabili a tal fine¹.
Il Regolamento² di attuazione è stato pubblicato sulla «Gazzetta ufficiale» del 3 maggio 2005, dopo essere stato firmato dal Presidente della Repubblica, il 1° marzo 2005.

2.2 Accessibilità e usabilità
Nella legge, all’articolo 2 (Definizioni), l’accessibilità è definita come «la capacità dei sistemi informatici, nelle forme e nei limiti consentiti dalle conoscenze tecnologiche, di erogare servizi e fornire informazioni fruibili, senza discriminazioni, anche da parte di coloro che a causa di disabilità necessitano di tecnologie assistive o configurazioni particolari», mentre le tecnologie assistive sono definite come «gli strumenti e le soluzioni tecniche, hardware e software, che permettono alla persona disabile, superando o riducendo le condizioni di svantaggio, di accedere alle informazioni e ai servizi erogati dai sistemi informatici».

In questa definizione sono presenti entrambe le caratteristiche, accessibilità e usabilità, che insieme contribuiscono alla qualità di un sito web.

2.2.1 L'accessibilità
Le persone con disabilità devono utilizzare le cosiddette “tecnologie assistive” per usufruire degli strumenti caratteristici della Information Technology, personal computer in primis.
Le tecnologie assistive possono essere di tipo diverso a seconda della barriera che aiutano a rimuovere:

• effettuano una conversione “equivalente” dell’informazione da un organo di senso a un altro:
  – dalla vista (schermo del PC) al tatto (Barra Braille per non vedenti)
  – dalla vista (schermo del PC) all’udito (sintesi vocale per non vedenti)
  – dall’udito (documenti audio) alla vista (documenti testuali)
• consentono un diverso modo di utilizzare taluni dispositivi, ad esempio:
  – mouse speciali (per disabili motori)
  – tastiere speciali (per disabili motori)
• consentono di sopperire a menomazioni gravi di una facoltà sensoriale, ad esempio:
  – gli ingranditori del testo sullo schermo del PC (per gli ipovedenti).

Per molte tipologie di disabilità non sono disponibili tecnologie assistive specifiche: in questi casi la rimozione delle barriere all’accesso ai servizi e alle informazioni è assicurata mediante l’utilizzo di particolari accorgimenti tecnici e redazionali nella realizzazione delle pagine del sito web. La consapevolezza delle barriere che possono frapporsi all’accesso alle informazioni e ai servizi da parte delle persone disabili, anche quando utilizzano tecnologie assistive, è alla base della definizione dei 22 requisiti che nello Studio vengono proposti per l’accessibilità dei siti web pubblici.
La conformità ad essi è il requisito minimo obbligatorio e indispensabile che un sito web pubblico deve avere per il rispetto della legge.
Nel Regolamento viene definita la verifica tecnica come: valutazione condotta da esperti, anche con strumenti informatici, sulla base di parametri tecnici.
I 22 requisiti seguenti costituiscono i parametri tecnici di riferimento.

Requisito n. 1
Realizzare le pagine e gli oggetti al loro interno utilizzando tecnologie definite da grammatiche formali pubblicate, nelle versioni più recenti disponibili quando sono supportate dai programmi utente. Utilizzare elementi ed attributi in modo conforme alle specifiche, rispettandone l’aspetto semantico.
In particolare, per i linguaggi a marcatori³ HTML (HypertText Markup Language) e XHTML (eXtensible HyperText Markup Language):

1. Per tutti i siti di nuova realizzazione, utilizzare almeno la versione 4.01 dell’HTML⁴ o preferibilmente la versione 1.0 dell’XHTML⁵, in ogni caso con DTD (Document Type Definition - Definizione del Tipo di Documento) di tipo Strict;
2. Per i siti esistenti, in sede di prima applicazione, nel caso in cui non sia possibile ottemperare al punto a) è consentito utilizzare la versione dei linguaggi sopra indicati con DTD Transitional, ma con le seguenti avvertenze:
   1) evitare di utilizzare, all’interno del linguaggio a marcatori con il quale la pagina è realizzata, elementi e attributi per definirne le caratteristiche presentazionali (per esempio, caratteristiche dei caratteri del testo, colori del testo stesso e dello sfondo ecc.), ricorrendo invece ai Fogli di Stile CSS⁶ (Cascading Style Sheets) per ottenere lo stesso effetto grafico;
   2) evitare la generazione di nuove finestre; ove ciò non fosse possibile, avvisare esplicitamente l’utente del cambiamento del focus;
   3) pianificare la transizione dell’intero sito alla versione con DTD Strict del linguaggio utilizzato. Il piano di transizione va presentato alla Presidenza del Consiglio dei Ministri — Dipartimento per l’innovazione e le tecnologie da parte del responsabile della accessibilità informatica (art. 9 Regolamento).

Requisito n. 2
Non è consentito l’uso dei frame nella realizzazione di nuovi siti.
In sede di prima applicazione, per i siti esistenti già realizzati con frame è consentito l’uso di HTML 4.01 o XHTML 1.0 con DTD frameset, ma con le seguenti avvertenze:

1. evitare di utilizzare, all’interno del linguaggio a marcatori con il quale la pagina è realizzata, elementi ed attributi per definirne le caratteristiche presentazionali (per esempio, caratteristiche dei caratteri del testo, colori del testo stesso e dello sfondo ecc.), ricorrendo invece ai Fogli di Stile CSS (Cascading Style Sheets) per ottenere lo stesso effetto grafico;
2. fare in modo che ogni frame abbia un titolo significativo per facilitarne l’identificazione e la navigazione. Se necessario, descrivere anche lo scopo dei frame e la loro relazione;
3. pianificare la transizione a XHTML almeno nella versione 1.0 con DTD Strict dell’intero sito. Il piano di transizione va presentato alla Presidenza del Consiglio dei Ministri — Dipartimento per l’innovazione e le tecnologie da parte del responsabile della accessibilità informatica (art. 9 Regolamento).

Requisito n. 3
Fornire un’alternativa testuale equivalente per ogni oggetto non di testo presente in una pagina e garantire che quando il contenuto non testuale di un oggetto cambia dinamicamente vengano aggiornati anche i relativi contenuti equivalenti predisposti. L’alternativa testuale equivalente di un oggetto non testuale deve essere commisurata alla funzione esercitata dall’oggetto originale nello specifico contesto.

Requisito n. 4
Garantire che tutti gli elementi informativi e tutte le funzionalità siano disponibili anche in assenza del particolare colore utilizzato per presentarli nella pagina.

Requisito n. 5
Evitare oggetti e scritte lampeggianti o in movimento le cui frequenze di intermittenza possano provocare disturbi da epilessia fotosensibile, disturbi della concentrazione o che possano causare il malfunzionamento delle tecnologie assistive utilizzate. Qualora esigenze informative richiedano comunque il loro utilizzo, avvisare l’utente del possibile rischio prima di presentarli e predisporre metodi che consentano di evitare tali elementi.

Requisito n. 6
Garantire che siano sempre distinguibili il contenuto informativo (foreground) e lo sfondo (background), ricorrendo a un sufficiente contrasto (nel caso del testo) o a differenti livelli sonori (in caso di parlato con sottofondo musicale). Un testo in forma di immagine in genere è da evitare ma, se non è possibile farne a meno, deve essere realizzato con gli stessi criteri di distinguibilità indicati in precedenza.

Requisito n. 7
Utilizzare mappe immagine sensibili di tipo lato client piuttosto che lato server, eccetto nel caso in cui le zone sensibili non possano essere definite con una delle forme geometriche predefinite indicate nella DTD adottata.

Requisito n. 8
Se vengono utilizzate mappe immagine lato server, fornire i collegamenti di testo alternativi necessari per poter ottenere tutte le informazioni o i servizi raggiungibili interagendo direttamente con la mappa.

Requisito n. 9
Per le tabelle dati usare gli elementi (marcatori) e gli attributi previsti dalla DTD adottata per descrivere i contenuti e identificare le intestazioni di righe e colonne.

Requisito n. 10
Per le tabelle dati usare gli elementi (marcatori) e gli attributi previsti nella DTD adottata per associare le celle di dati e le celle di intestazione che hanno due o più livelli logici di intestazione di righe o colonne.

Requisito n. 11
Usare i fogli di stile per controllare la presentazione dei contenuti e organizzare le pagine in modo che possano essere lette anche quando i fogli di stile siano disabilitati o non supportati.

Requisito n. 12
La presentazione e i contenuti testuali di una pagina devono potersi adattare alle dimensioni della finestra del browser utilizzata dall’utente senza sovrapposizione degli oggetti presenti o perdita di informazioni tali da rendere incomprensibile il contenuto, anche in caso di ridimensionamento, ingrandimento o riduzione dell’area di visualizzazione e/o dei caratteri rispetto ai valori predefiniti di tali parametri.

Requisito n. 13
Qualora si utilizzino le tabelle a scopo di impaginazione:

• garantire che il contenuto della tabella sia comprensibile anche quando questa viene letta in modo linearizzato,
• utilizzare gli elementi e gli attributi di una tabella rispettandone il valore semantico definito nella specifica del linguaggio a marcatori utilizzato.

Requisito n. 14
Nei moduli (form), associare in maniera esplicita le etichette ai rispettivi controlli, posizionandole in modo che per chi utilizza le tecnologie assistive la compilazione dei campi sia agevolata.

Requisito n. 15
Garantire che le pagine siano utilizzabili quando script, applet o altri oggetti di programmazione sono disabilitati oppure non supportati. Se questo non è possibile:

• fornire una spiegazione testuale della funzionalità;
• garantire una alternativa testuale equivalente in modo analogo a quanto indicato nel requisito n. 3

Requisito n. 16
Garantire che i gestori di eventi che attivano script, applet o altri oggetti di programmazione o che possiedono una propria specifica interfaccia, siano indipendenti da uno specifico dispositivo di input.

Requisito n. 17
Fare in modo che le funzionalità e le informazioni veicolate per mezzo di oggetti di programmazione, oggetti che utilizzano tecnologie non definite da grammatiche formali pubblicate, script e applet siano direttamente accessibili.

Requisito n. 18
Qualora un filmato o una presentazione multimediale siano indispensabili per la completezza dell’informazione fornita o del servizio erogato, predisporre una alternativa testuale equivalente sincronizzata in forma di sotto-titolazione e/o di descrizione vocale, oppure predisporre un riassunto o una semplice etichetta per ciascun elemento video o multimediale, tenendo conto del livello di importanza e delle difficoltà di realizzazione nel caso di presentazioni in tempo reale.

Requisito n. 19
Rendere chiara la destinazione di ciascun collegamento ipertestuale (link) con testi significativi anche se letti indipendentemente dal proprio contesto oppure associare ai collegamenti testi alternativi che possiedano analoghe caratteristiche esplicative. Prevedere meccanismi che consentano di evitare la lettura ripetitiva di sequenze di collegamenti comuni a più pagine.

Requisito n. 20
Se per la fruizione del servizio erogato in una pagina è previsto un intervallo di tempo predefinito entro il quale eseguire determinate azioni, è necessario avvisare esplicitamente l’utente, indicando il tempo massimo utile e fornendo eventuali alternative per fruire del servizio stesso.

Requisito n. 21
I collegamenti presenti in una pagina devono essere selezionabili e attivabili tramite comandi da tastiera, tecnologia in emulazione di tastiera o tramite sistemi di puntamento diversi dal mouse. Per facilitare la selezione e l’attivazione dei collegamenti con queste tecnologie assistive è anche necessario garantire che:

• la distanza verticale di liste di link e la spaziatura orizzontale tra link consecutivi sia di almeno 1 em;
• le distanze orizzontale e verticale tra i pulsanti di un modulo (form) sia di almeno 1 em;
• le dimensioni dei pulsanti in un modulo (form) siano tali da rendere chiaramente leggibile l’etichetta in essi contenuta, per esempio utilizzando opportunamente il margine tra l’etichetta e i bordi del pulsante;

Requisito n. 22
In sede di prima applicazione, per i siti esistenti, in ogni pagina che non possa essere ricondotta al rispetto dei presenti requisiti, fornire un collegamento a una pagina che li rispetti, contenga informazioni e funzionalità equivalenti e sia aggiornata con la stessa frequenza della pagina originale, evitando la creazione di pagine di solo testo. Il collegamento alla pagina accessibile deve essere proposto in modo evidente all’inizio della pagina non accessibile.
La sintesi estrema dei requisiti è che essi richiedono che una pagina web sia realizzata:

• con la netta separazione tra struttura, presentazione e comportamento
• nel rispetto degli standard
• con particolare attenzione alle necessità degli utenti disabili, sia nel caso di utilizzo di tecnologie assistive sia quando queste non sono disponibili.

2.2.2 L’usabilità
La definizione di accessibilità contiene un importante elemento di novità: essa è strettamente collegata al concetto di fruibilità dei servizi e delle informazioni offerti da un sistema informatico.
Nel Regolamento, agli articoli 1 e 2, la fruibilità è definita come: «la caratteristica dei servizi di rispondere a criteri di facilità e semplicità d’uso, di efficienza, di rispondenza alle esigenze dell’utente, di gradevolezza e di soddisfazione nell’uso del prodotto» ed essa si caratterizza con:
«1) facilità e semplicità d’uso, assicurando, fra l’altro, che le azioni da compiere per ottenere servizi e informazioni siano sempre uniformi tra loro;
2) efficienza nell’uso, assicurando, fra l’altro, la separazione tra contenuto, presentazione e modalità di funzionamento delle interfacce, nonché la possibilità di rendere disponibile l’informazione attraverso differenti canali sensoriali;
3) efficacia nell’uso e rispondenza alle esigenze dell’utente, assicurando, fra l’altro, che le azioni da compiere per ottenere in modo corretto servizi e informazioni siano indipendenti dal dispositivo utilizzato per l’accesso;
4) soddisfazione nell’uso, assicurando, fra l’altro, l’accesso al servizio e all’informazione senza ingiustificati disagi o vincoli per l’utente».
Le definizioni date nel Regolamento riprendono quasi alla lettera quanto previsto nella definizione contenuta nella Norma ISO 9241-11 Ergonomic requirements for office work with visual display terminals - Guidance on usability” nella quale l’usabilità è «il grado in cui un prodotto può essere usato da specifici utenti per raggiungere specifici obiettivi con efficacia, efficienza e soddisfazione in uno specifico contesto d’uso».
L’introduzione del concetto di usabilità come caratteristica fondamentale di un sito web pubblico comporta la questione di come valutarne l’effettiva applicazione.
Il Regolamento, all’articolo 1, parla di: «verifica soggettiva: valutazione del livello di qualità dei servizi, già giudicati accessibili tramite la verifica tecnica, effettuata con l’intervento del destinatario, anche disabile, sulla base di considerazioni empiriche».
Da questa definizione, in sostanza, si evince che la progettazione delle interfacce, dei modi di interazione e dell’organizzazione dei contenuti di un sito web deve essere “centrata sull’utente” (user-centered): nessuno conosce competenze, cultura, bisogni, limiti, atteggiamenti degli utenti reali meglio degli utenti medesimi, e pertanto è necessario prevedere il coinvolgimento degli utenti in tutte le fasi della progettazione, realizzazione e gestione di un sito web.
Nello Studio predisposto dalla Segreteria tecnico-scientifica vengono proposti 12 criteri essenziali da rispettare e la metodologia per la loro valutazione. Riportiamo di seguito il testo che descrive criteri e metodologia.
I criteri essenziali da rispettare sono:
percezione: le informazioni e i comandi necessari per l’esecuzione dell’attività devono essere sempre disponibili e percettibili;
comprensibilità: le informazioni e i comandi necessari per l’esecuzione delle attività devono essere facili da capire e da usare;
operabilità: informazioni e comandi sono tali da consentire una scelta immediata della azione adeguata per raggiungere l’obiettivo voluto;
coerenza: stessi simboli, messaggi e azioni devono avere gli stessi significati in tutto l’ambiente;
salvaguardia della salute (safety): indica le caratteristiche che deve possedere l’ambiente per salvaguardare e promuovere il benessere psicofisico dell’utente;
sicurezza: indica le caratteristiche che l’ambiente deve possedere per fornire transazioni e dati affidabili, gestiti con adeguati livelli di sicurezza;
trasparenza: l’ambiente deve comunicare il suo stato e gli effetti delle azioni compiute. All’utente devono essere comunicate le necessarie informazioni per la corretta valutazione della dinamica dell’ambiente;
apprendibilità: indica le caratteristiche che l’ambiente deve possedere per consentire l’apprendimento del suo utilizzo da parte dell’utente in tempi brevi e con minimo sforzo;
aiuto e documentazione: fornire funzioni di aiuto come guide in linea e documentazione relative al funzionamento dell’ambiente. Le informazioni di aiuto devono essere facili da trovare e focalizzate sul compito dell’utente;
tolleranza agli errori: l’ambiente deve prevenire gli errori e, qualora questi accadano, devono essere forniti appropriati messaggi che indichino chiaramente il problema e le azioni necessarie per recuperarlo;
gradevolezza: indica le caratteristiche che l’ambiente deve possedere per favorire e mantenere l’interesse dell’utente;
flessibilità: l’ambiente deve tener conto delle preferenze individuali e dei contesti.
La metodologia di progettazione dei siti web centrata sull’utente prevede le fasi iterative di:

• Definizione degli obiettivi del prodotto web
• Analisi del contesto d’uso
• Definizione delle specifiche
• Elaborazione di un primo prototipo (mockup)
• Sperimentazione e valutazione di soluzioni alternative (punto di iterazione)
• Adozione della soluzione
• Sviluppo del prodotto web
• Valutazione sperimentale (punto di iterazione)
• Eventuali correzioni
• Rilascio del prodotto web
• Valutazione con l’utente nel contesto d’uso (punto di iterazione)
• Eventuali correzioni ed indicazioni per l’aggiornamento
• Monitoraggio (punto di iterazione).

Questa metodologia si fonda su quattro principali condizioni:
a) la costituzione di un gruppo rappresentativo di utenti o panel: nel panel devono essere presenti utenti con diversi tipi di disabilità e anche i diversi ruoli e scopi per cui un utente ha interesse ad entrare nel sito;
b) la costruzione di scenari d’uso: definire contesti, scopi, e modi di interazione con il sito. È sulla base di questi scenari che il sito viene immaginato, progettato, valutato e continuamente aggiornato e migliorato;
c) la progettazione evolutiva: il sito va sottoposto a valutazione da parte del panel sulla base di più scenari complessi. La valutazione è finalizzata alla definizione dei nuovi requisiti e delle nuove finalità. La definizione delle nuove finalità va condotta in modo iterativo attraverso la produzione di prototipi anche a bassa fedeltà, ma che consentono di valutare le soluzioni, individuare vincoli e stabilire la fattibilità. Il confronto continuo con il panel consente una valutazione in progress delle soluzioni e anticipa la valutazione finale del progetto. Infine il panel diventa un osservatorio dell’uso del sito finalizzato all’aggiornamento e al miglioramento continuo;
d) Il monitoraggio: poiché, come già ricordato, è importante assicurarsi che il sito non rimanga identico a se stesso nei contenuti per troppo tempo, è necessaria una azione continua di monitoraggio per il costante miglioramento in funzione della dinamica dei bisogni e degli interessi.
La costituzione del panel è quindi l’elemento centrale della metodologia perché:
a) garantisce il livello di realismo, ma anche di consenso e comunicazione sul progetto. Potrebbe avere, da questo punto di vista, due dimensioni di rappresentatività: disabilità e categorie professionali;
b) produce dati e idee e consente di prendere decisioni empiricamente fondate. Da quest’ultimo punto di vista il panel è un luogo di sperimentazione delle opportunità, ma anche dei vincoli delle tecnologie dedicate di accesso e di interazione.

2.2.3 Processo di valutazione
Il processo di valutazione della rispondenza di un ambiente ai criteri essenziali si concentra nei punti di iterazione indicati nella metodologia e viene condotto con le seguenti modalità:

1. analisi da parte di uno o più esperti di fattori umani;
2. test con gli utenti;
3. elaborazione dei dati da parte dell’esperto e rapporto conclusivo con l’indicazione del livello di qualità raggiunto.

2.2.4 Analisi da parte di esperti di fattori umani
La valutazione da parte di uno o più esperti di fattori umani consisterà essenzialmente nel metodo della simulazione cognitiva (cognitive walkthrough) attraverso il quale l’esperto costruisce scenari d’uso dell’ambiente e dell’interfaccia che simulano a livello cognitivo il comportamento dell’utente.
Si tratta in sostanza di valutare se una certa azione per raggiungere un obiettivo da parte dell’utente è resa possibile dall’ambiente o se ne è da questo ostacolata.
L’esperto di fattori umani dovrà quindi conoscere quali servizi l’ambiente intende erogare, quali informazioni offrire, le azioni richieste all’utente per raggiungere tali obiettivi per mezzo dell’interfaccia, le informazioni sugli utenti potenziali e sulla loro esperienza e conoscenza richieste per interagire con l’ambiente.
Questa parte della valutazione si conclude con l’assegnazione a ciascuno dei dodici criteri indicati di un giudizio su una scala crescente di valori da 1 a 5 in cui:
1 = nessuna rispondenza dell’ambiente al criterio in esame;
2 = poca rispondenza dell’ambiente al criterio in esame;
3 = sufficiente rispondenza dell’ambiente al criterio in esame;
4 = molta rispondenza dell’ambiente al criterio in esame;
5 = moltissima rispondenza dell’ambiente al criterio in esame.

2.2.5 Valutazione effettuata con l’utente
La seconda parte della valutazione prevede la costituzione del panel di utenti con la partecipazione di utenti disabili che utilizzano le proprie tecnologie assistive.
Il panel esegue una serie di test basati sulla interazione con l’ambiente. I test potranno essere svolti:

• in forma libera: l’utente naviga il sito senza compiti specifici;
• per obiettivi: l’utente esegue compiti specifici.

Nell’esecuzione dei test, il panel utenti è guidato dall’esperto di fattori umani.
Quando il test riguarda la navigazione libera, l’esperto raccoglie i commenti dell’utente e le osservazioni del suo comportamento in un modulo.
Quando il test avviene su compiti specifici, l’esperto registra il tipo di compito, la quantità di tempo impiegata per svolgerlo e gli eventuali errori commessi nonché annota le osservazioni sul comportamento ed i commenti dell’utente.

Anche questa parte si conclude con la valutazione su scale soggettive analoghe a quelle descritte nel punto precedente.

2.2.6 Elaborazione dei dati e rapporto conclusivo
La valutazione si conclude con la predisposizione di un rapporto nel quale l’esperto di fattori umani indica:

• la valutazione su scale soggettive ricavata dalla simulazione cognitiva effettuata;
• le sue considerazioni qualitative;
• i dati relativi alle prestazioni degli utenti in relazione ai compiti affidati: misure di performance, commenti, osservazioni comportamentali;
• le risposte a questionari di valutazione compilati dagli utenti;
• la valutazione complessiva del livello di qualità raggiunto secondo il seguente schema:
  – valore medio complessivo minore di 2 = assenza di qualità;
  – valore medio complessivo maggiore o uguale a 2 e minore di 3 = primo livello di qualità;
  – valore medio complessivo maggiore o uguale a 3 e minore di 4 = secondo livello di qualità;
  – valore medio complessivo maggiore o uguale a 4 = terzo livello di qualità.

2.3 Criteri di usabilità per le applicazioni web culturali pubbliche (AWCP)

Per la definizione di un quadro per la qualità delle AWCP, l’applicazione dei principi di usabilità per la progettazione e la realizzazione di siti web ha portato, nell’ambito del Progetto MINERVA, alla selezione di alcune Categorie che rappresentano esigenze degli utenti e che devono essere soddisfatte. Le riportiamo a titolo esemplificativo:

1. Far percepire i contenuti

1.1 Riconoscere di essere in un sito che è una AWCP
1.2 Riconoscere gli scopi del sito
1.3 Farsi una idea sul contenuto generale del sito, per poter poi eventualmente accedere ai particolari
1.4 Poter fruire di contenuti di qualità

2. Presentare i contenuti

2.1 Layout funzionale
2.2 Elementi grafici funzionali
2.3 Elementi multimediali funzionali

3 Far navigare il sito

3.1 Chiarezza dei link
3.2 Validità dei link
3.3 Copertura dei link
3.4 Validità dei percorsi all’indietro
3.5 Chiarezza del contesto rispetto al sito
3.6 Validità del controllo sui media
3.7 Chiarezza del controllo sui media

4 Fare effettuare ricerche

4.1 Comprensibilità dei moduli di ricerca
4.2 Comprensibilità dei risultati delle ricerche
4.3 Navigabilità dei risultati delle ricerche

2.4 Pattern e linguaggio di Pattern

Un approccio ai problemi concreti di progettazione e realizzazione di siti web di qualità è quello di far uso dei pattern, che si propongono di risolvere problemi ricorrenti mediante soluzioni note e consolidate. Il prodotto web ha ormai raggiunto un grado di maturità tale che le soluzioni ad alcuni problemi legati al suo utilizzo sono ormai ritenute patrimonio comune a tutti i progettisti.
Inoltre, i pattern possono essere un utile riferimento per coloro che si devono interessare di siti web, pur non essendone esperti. In questo caso, infatti, i pattern possono costituire un comune linguaggio di comunicazione con i professionisti per indicare cosa si vuole e perché, indipendentemente dal come la soluzione sia realizzabile tecnicamente.

I pattern non eliminano né sostituiscono la necessità del coinvolgimento degli utenti di cui si è parlato precedentemente: al contrario esso si giova, per definizione, di esperienze concrete fatte con gli utenti.

2.4.1 Definizioni
Il paradigma dei Pattern è stato sviluppato alla fine degli anni Settanta da Christopher Alexander, professore di Architettura all’Università di Berkeley, per far fronte ai complessi problemi connessi alla progettazione urbanistica ed edilizia. Secondo Alexander la scarsa qualità dell’architettura degli anni Sessanta era dovuta anche alla mancanza di metodi formali di progettazione. In pratica, egli rilevò che i progetti urbanistici e di edifici non tenevano conto delle esperienze concrete che man mano andavano maturando e senza le quali i progetti stessi finivano per essere estranei alle esigenze reali degli utenti. Di qui l’idea di definire dei Pattern che stabiliscono una relazione tra un contesto, un insieme di condizioni (o vincoli) legate a quel contesto e una soluzione che risolve il problema con quelle condizioni e in quel contesto.
Dalla metà degli anni Novanta l’idea di usare linguaggi di Pattern come supporto ai progettisti ha avuto un nuovo slancio grazie all’enorme successo avuto dalla sua applicazione al campo dell’ingegneria del software e della progettazione object oriented. Recentemente il paradigma dei Pattern è stata applicato anche al campo della Human Computer Interface (HCI), con estensioni al mondo Web.
I Pattern ambiscono a fornire un modo rigoroso per descrivere l’esperienza di un progettista attraverso la formulazione di una soluzione a un problema comune.
Ciò che caratterizza quest’approccio è la scelta di non dare soluzioni “pre-codificate” al problema, cercando piuttosto di descrivere correttamente sia il contesto sia la soluzione, raccogliendo sotto un unico titolo le esperienze e le soluzioni adottate (anche da altri, non soltanto le proprie) in situazioni simili.
Un Pattern è costituito da una triade composta da:
Contesto: è l’insieme delle condizioni al contorno, l’ambiente nel quale si agisce; è l’insieme delle forze in azione delle quali il Pattern deve tenere conto e che vincolano la scelta della soluzione;
Problema: è una situazione che si presenta in maniera ricorrente nel contesto e che crea scompensi tra le forze in azione;
Soluzione: è un algoritmo, una tecnologia, una struttura organizzativa, un metodo noto, un modello di riferimento che risolve in maniera ricorrente quel problema in quel contesto.
Va evidenziato il fatto che un Pattern è costituito da una triade: questo implica che un problema, da solo, non è un Pattern e una soluzione, da sola, non è un Pattern.
Detto in una frase: un Pattern è una soluzione consolidata (well proven) a un problema ricorrente in un contesto specifico.
Per completare la definizione di un Pattern occorrono anche altri elementi:
Nome: un Pattern deve avere un nome significativo. Dare un nome a qualcosa è il primo passo per poterne parlare.
Condizioni: descrizione delle condizioni (o vincoli) presenti nel contesto.
Annotazioni: considerazioni (positive o negative) sulle conseguenze dell’uso del Pattern corrente.
Pattern correlati: relazioni tra il Pattern corrente e altri Pattern utilizzati nel sistema di riferimento.
Usi conosciuti: riferimenti puntuali ad applicazioni pratiche del Pattern corrente.

Un linguaggio di Pattern raccoglie Pattern che cooperano per risolvere i problemi in un certo contesto.
Il contesto generale di riferimento al quale intendiamo applicare il linguaggio dei Pattern è la progettazione e la realizzazione di WAI accessibili e usabili, vale a dire di qualità.
Stabilite le condizioni di riferimento comuni è necessario organizzare in qualche modo i Pattern per poterli utilizzare.
Il modo qui proposto sia quello di costruire un vero e proprio Catalogo di Pattern il cui scopo è quello di individuare categorie generali di problemi da affrontare. All’interno di ciascuna di queste categorie si inseriscono Pattern che definiscono e risolvono un problema particolare.

2.4.2 Il Catalogo dei Pattern
Per costruire il Catalogo dei Pattern da applicare nella progettazione e nella realizzazione di un’WAI accessibile e usabile utilizziamo le stesse categorie generali nelle quali sono stati raggruppati i Criteri di usabilità. A esse aggiungiamo anche:

Interagire con gli utenti: quando un SCP si presenta su Internet con un suo sito Web apre, di fatto, uno sportello al cittadino. La interattività, intesa come possibilità di comunicazione diretta tra cittadino e WAI diventa una funzionalità importante che non può mancare.
Gran parte dei pattern presentati nel Catalogo⁷ si ispira ai lavori di Martijn Van Welie⁸ che ha scritto pattern per il Web, con particolare attenzione ai Principi di usabilità, avendo in mente le necessità dell’utente più che quelle del progettista.

2.4.3 Come utilizzare i Pattern
Resta, infine, una questione da chiarire: come “si usano” i Pattern.
Alexander, in un capitolo del suo libro A Pattern Language, suggerisce di intraprendere un percorso al termine del quale si dovrebbe aver compilato una lista di Pattern necessari al progetto. I passi del percorso sono i seguenti:

1. Esaminare l’intera sequenza, il Catalogo dei Pattern, che è disponibile.
2. Individuare, attraverso il nome, il Pattern che meglio identifica il progetto/problema che si deve affrontare.
3. Leggerne attentamente la descrizione: in essa sono indicati i Pattern correlati a quello attuale. Si predispone, quindi, una lista segnando su di essa i Pattern di livello inferiore (più specifici) che si incontrano, tralasciando, in genere, i Pattern di livello superiore (meno specifici).
4. Leggere il Pattern successivo evidenziato sulla lista e segnare di nuovo i Pattern inferiori a cui è correlato.
5. Quando si è in dubbio sulla utilità di un Pattern questo non va incluso. Infatti la lista diverrebbe inevitabilmente troppo lunga e potrebbe confondere, e comunque sarà già sufficientemente lunga includendo solo i Pattern che più si ritengono utili.
6. Si continua così fino all’identificazione di tutti i Pattern che si vuole includere nel progetto.
7. Giunti a questo punto bisogna aggiustare la lista aggiungendo, se necessario, propri elementi.
8. Infine, si deve tenere in gran conto della necessità di adattamenti e cambiamenti dei Pattern in relazione alle esigenze proprie del progetto in corso.

2.4.4 Un esempio d’uso del Catalogo dei Pattern
In un sito già presente sul Web si vuole offrire agli utenti un servizio di Newsletter.
Nel Catalogo, sotto la categoria Interagire con gli utenti, si trova il Pattern Newsletter.
Questa è la sua definizione:

Newsletter

Contesto: i contenuti del sito trattano diversi temi. Possono esserci eventi, pubblicazioni, notizie che riguardano i temi trattati nel sito e che si ritiene siano interessanti da conoscere, anche se non si trovano nelle pagine del sito, ma in altri siti.
Condizioni: l’utente ha fiducia nel sito, ne riconosce l’autorevolezza nell’ambito dei temi trattati, vuole essere informato regolarmente sulle novità, può non voler visitare tutti i giorni il sito.
Problema: come ripagare la fiducia dell’utente?
Soluzione: predisporre una Newsletter da inviare con regolarità.
La Newsletter dovrebbe avere un formato che renda facile riconoscerne la provenienza, sia di agile lettura e non sia troppo “voluminosa”.

Gli elementi tipici di una Newsletter dovrebbero essere:
Intestazione: nella quale deve essere indicata chiaramente l’identità di chi la spedisce. La cosa migliore è quella di riportare nella Newsletter la stessa intestazione delle pagine del sito (Struttura della Pagina);
Estremi di pubblicazione: anno di pubblicazione, numero e data;
Indice delle notizie: titoli delle notizie pubblicate, ciascuno collegato alla notizia corrispondente;
Notizie: non più di una decina. Ogni notizia dovrebbe avere un titolo significativo (Nome significativo), una sintesi breve e scritta in linguaggio semplice e chiaro (plain language) e i collegamenti ai documenti correlati;
Istruzioni per la gestione della iscrizione: in esse devono essere previste le funzioni di cambio di indirizzo di e-mail, di cancellazione dalla Newsletter, di gestione dei dati di Registrazione (se prevista), di invio di commenti;
Modalità di uso: diritti di autore, privacy, politiche di sicurezza adottate. Può essere una dichiarazione esplicita o un collegamento a una pagina del sito appositamente predisposta (Modalità d’uso).
L’utente può iscriversi alla Newsletter compilando una Form nella quale viene richiesto l’indirizzo di e-mail al quale essa deve essere inviata. Se ritenuto opportuno si può richiedere all’utente una Registrazione. In entrambi i casi si deve Comunicare l’esito dell’operazione eseguita. Il servizio di Newsletter dovrebbe essere ben evidenziato riservando ad esso un’opportuna area nella Home page oppure come elemento della Navigazione principale. Si dovrebbe predisporre una pagina del sito appositamente dedicata nella quale si descrivono gli scopi della Newsletter, la sua periodicità e si mettono a disposizione dell’utente tutte le funzioni necessarie alla iscrizione, cancellazione, modifica dell’indirizzo, accesso all’archivio delle Newsletter pubblicate, visualizzazione on-line delle Newsletter. La pagina dedicata alla Newsletter deve comparire anche nella Mappa del sito.

Annotazioni: Il rispetto della periodicità dichiarata è un requisito indispensabile per il successo della Newsletter. La Newsletter non dovrebbe sostituire la funzione Novità del sito: il suo scopo dovrebbe essere quello di fornire sui temi di riferimento informazioni più ampie di quelle contenute nelle pagine del sito.
Pattern correlati: Form, Registrazione, Comunicare l’esito.
Esempi: www.nytimes.com, www.governo.it

Da questa definizione si ricavano molte informazioni utili per affrontare il problema:

1. Si può verificare dal Contesto, dalle Condizioni e dalla proposizione del Problema se il Pattern è adeguato al caso in esame.
2. Nella Soluzione si trovano indicazioni concrete sul come realizzare la Newsletter, sul come offrire il servizio all’utente e, come conseguenze, sui problemi organizzativi che possono nascere.
3. Nella descrizione della Soluzione sono indicati in grassetto dei Pattern: alcuni sono di livello più generale (ad esempio: Struttura della pagina, Home page, Navigazione principale, Modalità d’uso) perché si riferiscono a problemi che riguardano il sito nel suo complesso; altri sono riferiti a funzionalità che sono ritenute attinenti o simili a quella in esame (ad esempio: Mappa del sito, Novità del sito).
4. Nella Soluzione sono poi indicati i Pattern Form, Registrazione, Comunicare l’esito che sono ritenuti “collegati” al Pattern attuale. La differenza con i precedenti sta nel fatto che i Pattern correlati sono considerati essenziali per una corretta soluzione del problema attuale, mentre i Pattern indicati nel punto definiscono l’ambiente nel quale si interviene.
5. Leggendo le definizioni dei Pattern correlati (che non sono qui riportate per brevità) si ricavano ulteriori informazioni e si individuano altri Pattern correlati. Tra questi possono esserci Pattern già esaminati e pertanto verranno iscritti una sola volta nella lista.
6. Alla fine si è in grado di stilare una lista di Pattern del tipo:
   • Newsletter
   • Form
     • Input controllato
   • Registrazione
     • Login
   • Comunicare l’esito
   L’indentazione ha il solo scopo di mostrare la concatenazione della sequenza come è ottenuta in questo caso partendo dal Pattern Newsletter.
7. La lista, completa di tutte le definizioni, costituisce un documento che può essere utilizzato per la realizzazione della funzionalità Newsletter.
8. Una verifica può essere fatta visitando i siti indicati negli Esempi (gli esempi si riferiscono alla realizzazione che in essi viene fatta del Pattern o di alcuni suoi aspetti. Non si riferiscono ai siti nel loro complesso).

1] Infra, p. 243

2] <http://www.pubbliaccesso.gov.it/normative/regolamento.htm>

3] <http://www.w3.org/MarkUp/>

4] <http://www.w3.org/TR/html4/>. Traduzione in italiano: <http://www.w3c.it/traduzioni/>

5] <http://www.w3.org/TR/xhtml1/>. Traduzione in italiano: <http://www.w3c.it/traduzioni/>

6] <http://www.w3.org/Style/CSS/>

7] Infra, p. 105

8] Gran parte dei Pattern presentati nel Catalogo (v. appendice n. 3) si ispira ai lavori di Martijn Van Welie (http://www.welie.com/patterns/index.html) che ha scritto Pattern per il Web, con particolare attenzione ai Principi di usabilità, avendo in mente le necessità dell’utente più che quelle del progettista. Una bibliografia su raccolte di Pattern per il Web è consultabile in http://iawiki.net/WebsitePatterns