minerva homepage  
home |  search |  map |  contact us

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

 
 

Manuale per la qualità dei siti Web pubblici culturali

   
 
  About MINERVA and MINERVA Plus  
  Structure  
   
  NPP  
  Good practices  
  Competence centres  
  Digitisation guidelines  
  European and national rules on Web Applications  
  Enlargement  
  Events  
  References  
  Publications
 
 
 


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

2.1 Premessa

2.2 Accessibilità dei contenuti

2.2.1 Disabilità
2.2.2 Come le persone con disabilità usano il Web
2.2.3 La Web Accessibility Initiative (WAI)
2.2.4 Le indicazioni dell’Unione Europea
2.2.5 La normativa italiana: “la Legge Stanca”

2.3 Usabilità

2.3.1 Definizioni e metodologia
2.3.2 Principi di usabilità

2.4 Criteri di usabilità per le AWCP
2.5 Pattern e linguaggio di Pattern

2.5.1 Definizioni
2.5.2 Il Catalogo dei Pattern
2.5.3 Come utilizzare i Pattern
2.5.4 Un esempio d’uso del Catalogo dei Pattern


2.1 Premessa
A dieci anni dalla sua comparsa il Web ha raggiunto la maturità di un prodotto di largo consumo.
Nato nella comunità scientifica come strumento per mettere in comune documenti tecnici e scientifici, è diventato velocemente uno strumento alla portata di tutti per comunicare, per aggiornarsi, per fare commercio, per il divertimento, per fare cultura.
Per presentare i propri contenuti, il prodotto Web ha dapprima imitato e utilizzato tecniche e metodi propri di altri strumenti di comunicazione, primi tra tutti quelli della stampa e della televisione, poi, a seguito della sua esplosiva diffusione capillare, ha scoperto tecniche e metodi nuovi che meglio si adattano alle sue caratteristiche.
Attualmente, finita la fase sperimentale e innovativa, i buoni siti Web vengono progettati e realizzati cercando di avere quella caratteristica che è comune a tutti i prodotti di successo: la qualità.
Il prodotto Web può essere inteso come complesso di informazioni digitali fruibili dall’utente tramite computer, anche in modo interattivo, mediante interfacce grafiche o testuali standard.
Si tratta, perciò, di un prodotto software al quale è possibile applicare quanto previsto nella norma ISO/IEC 9126-1 – Information Technology. Software product quality: quality model – nella quale la qualità nell’uso di un prodotto è definita: «la capacità di un prodotto di aiutare determinati utenti a raggiungere determinati obiettivi con efficacia, efficienza, sicurezza e soddisfazione, in determinati contesti d’uso».
Questa definizione mette in evidenza che la qualità di un prodotto software non è quella di essere senza difetti o ricco di funzionalità o tecnologicamente innovativo, ma che essa è raggiungibile solo tenendo conto delle esigenze degli utenti in relazione al contesto d’uso.
A differenza di altri prodotti software, il Web ha un’enorme diffusione e perciò le tipologie di utenti che possono farne uso e quella dei contesti nei quali tale uso avviene sono molteplici e possono essere molto diversi tra loro. Per affrontare questa complessità e i requisiti indicati è opportuno esaminare due caratteristiche qualitative che sono:

  • l’accessibilità dei contenuti, che tiene conto delle diverse tipologie di utenti e di contesti d’uso;
  • l’usabilità, con la quale si indicano sinteticamente i requisiti di efficacia, efficienza, sicurezza e soddisfazione.

2.2 Accessibilità dei contenuti
Un sito Web è accessibile quando il suo contenuto informativo, le sue modalità di navigazione e tutti gli elementi interattivi eventualmente presenti sono fruibili dagli utenti indipendentemente dalle loro disabilità, indipendentemente dalla tecnologia che essi utilizzano per accedere al sito e indipendentemente dal contesto in cui operano mentre accedono al sito.
Per dare un’idea di quanto sia ampia la definizione data vale la pena di riportare gli scenari descritti nell’introduzione delle Linee guida della Web Accessibility Initiative (WAI) del World Wide Web Consortium (W3C).
«Coloro che non hanno familiarità con i problemi di accessibilità che riguardano le pagine Web considerino che molti utenti possono operare in contesti assai differenti dal nostro:

  • Possono non essere in grado di vedere, ascoltare o muoversi o possono non essere in grado di trattare alcuni tipi di informazioni facilmente o del tutto.
  • Possono avere difficoltà nella lettura o nella comprensione del testo.
  • Possono non avere o non essere in grado di usare una tastiera o un mouse.
  • Possono avere uno schermo solo testuale, un piccolo schermo o una connessione Internet molto lenta.
  • Possono non parlare e capire fluentemente la lingua in cui il documento è scritto.
  • Possono trovarsi in una situazione in cui i loro occhi, orecchie o mani sono occupati o impediti (ad esempio, stanno guidando, lavorano in un ambiente rumoroso ecc.).
  • Possono avere la versione precedente di un browser, un browser completamente diverso, un browser basato su dispositivi di sintesi vocale o un diverso sistema operativo.

Gli sviluppatori devono considerare queste diverse situazioni durante la progettazione».
Negli scenari descritti risalta l’attenzione prestata agli utenti con disabilità sia con riferimento esplicito ad alcune tipologie di disabilità sia con riferimento alle tecnologie di cui gli utenti con disabilità possono disporre per utilizzare un computer in generale e per navigare il Web in particolare.
È opportuno chiarire cosa si intende per persona con disabilità.

2.2.1 Disabilità
Per le disabilità, l’Organizzazione Mondiale della Sanità (OMS) nella International Classification of Impairments, Disabilities and Handicaps (ICIDH-1, 1980) dà le seguenti definizioni:

  • menomazione (Impairment): qualsiasi perdita o anormalità a carico di una struttura o una funzione psicologica, fisiologica, anatomica;
  • disabilità: limitazione o perdita (conseguente a menomazione) della capacità di compiere un’attività nel modo e nell’ampiezza considerati normali;
  • handicap: condizione di svantaggio conseguente a una menomazione o a una disabilità che limita o impedisce l’adempimento del ruolo normale per tale soggetto, in relazione all’età, al sesso, ai fattori socioculturali.

Nel 2001 l’OMS ha presentato un nuovo documento per la definizione delle disabilità, la International Classification of Functioning, Disability and Health (ICF [ICIDH-2], 2001) nella quale, in sostanza:

  • si parla di “funzionamento umano” (functioning) in generale e non puramente di disabilità: si associa lo stato di un individuo non solo a funzioni e a strutture del corpo, ma anche ad attività a livello individuale o di partecipazione nella vita sociale;
  • si passa da conseguenze di un “disturbo” a componenti della “salute”, raggruppandole nel “dominio della salute” (health domain, che comprende il vedere, l’udire, il camminare, l’imparare) e in quelli “collegati alla salute” (health-realated domain, che comprendono mobilità, istruzione, partecipazione alla vita sociale e simili).

Il modello fornito è universale: non riguarda solo le persone con disabilità, ma tutte le persone. Ciò rende ancora più evidente la necessità di progettare e realizzare siti Web accessibili.

2.2.2 Come le persone con disabilità usano il Web
Per alcune tipologie di disabilità sono disponibili le cosiddette tecnologie compensative (o enabling). Si tratta di strumenti hardware e/o software che:

  • effettuano una conversione “equivalente” dell’informazione da un organo di senso a un altro, ad esempio:
    • dalla vista (schermo del PC) al tatto (barra Braille per ciechi);
    • dallo vista (schermo del PC) all’udito (sintesi vocale per ciechi);
    • dall’udito (documenti audio) alla vista (documenti testuali) (riconoscitore vocale per disabili motori e sordi);
  • 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 di una facoltà sensoriale, ad esempio:
    • gli ingranditori del testo sullo schermo del PC (per gli ipovedenti).

Per altre tipologie di disabilità non sono disponibili tecnologie compensative specifiche: l’accessibilità è in questi casi assicurata mediante l’utilizzo di particolari accorgimenti tecnici e redazionali nella realizzazione delle pagine del sito Web. Si pensi, tra gli altri:

  • agli utenti che hanno difficoltà nella percezione dei colori, per i quali, ad esempio, è necessario evitare di fornire informazione con il solo uso del colore e garantire un sufficiente contrasto tra testo e sfondo;
  • agli utenti affetti da epilessie fotosensibili, per i quali, ad esempio, è necessario evitare di inserire immagini in movimento con determinate frequenze che potrebbero provocare l’insorgere di una crisi;
  • agli utenti con difficoltà dell’apprendimento e del linguaggio per i quali, ad esempio, è necessario realizzare meccanismi chiari di navigazione e utilizzare un linguaggio naturale e semplice nella stesura dei documenti.

2.2.3 La Web Accessibility Initiative (WAI)
Per raggiungere l’accessibilità dei contenuti di un sito Web, si fa costantemente riferimento alle Linee guida definite nell’ambito dell’iniziativa WAI.
Il WAI tratta dell’accessibilità del Web in senso lato e cioè non solo dei contenuti ma anche degli strumenti con i quali realizzare le pagine Web, dei browser e più in generale delle tecnologie per l’accesso al Web.
Per l’accessibilità dei contenuti, sono di particolare importanza le Web Content Accessibility Guidelines (WCAG) versione 1.0, pubblicate il 5 maggio 1999.
Si tratta di 14 linee guida, in ciascuna delle quali sono presentati scenari tipici che possono creare una difficoltà per utenti con disabilità. In ogni linea guida è definito un certo numero di punti di controllo (checkpoint) che spiega in che modo la specifica linea guida è applicabile nello sviluppo dei contenuti. Le linee guida introducono il concetto di priorità e il conseguente concetto di conformità. Entrambi i concetti sono così spiegati nelle WCAG: «A ciascun punto di controllo è stato assegnato dal Gruppo di Lavoro un livello di priorità basato sull’impatto che tale punto possiede sull’accessibilità.

Priorità 1
Lo sviluppatore di contenuti Web deve conformarsi al presente punto di controllo. In caso contrario, a una o più categorie di utenti viene precluso l’accesso alle informazioni presenti nel documento. La conformità a questo punto di controllo costituisce un requisito base affinché alcune categorie di utenti siano in grado di utilizzare documenti Web.

Priorità 2
Lo sviluppatore di contenuti Web dovrebbe conformarsi a questo punto di controllo. In caso contrario per una o più categorie di utenti risulterà difficile accedere alle informazioni nel documento. La conformità a questo punto consente di rimuovere barriere significative per l’accesso a documenti Web.

Priorità 3
Lo sviluppatore di contenuti Web può tenere in considerazione questo punto di controllo. In caso contrario, una o più categorie di utenti sarà in qualche modo ostacolata nell’accedere alle informazioni presenti nel documento. La conformità a questo punto migliora l’accesso ai documenti Web.
Il rispetto di quanto indicato nei vari punti di controllo porta al concetto di conformità:

Livello di conformità “A”:
conforme a tutti i punti di controllo di Priorità 1.
Livello di conformità “Doppia-A”:
conforme a tutti i punti di controllo di Priorità 1 e 2.
Livello di conformità “Tripla-A”:
conforme a tutti i punti di controllo di Priorità 1, 2 e 3.”

Nel Repertorio 2 è riportata la Lista dei punti di controllo delle WCAG 1.0, nella quale i punti di controllo sono raggruppati per priorità e per tipologia di elementi che possono essere presenti in una pagina Web.
La lista è utile, innanzi tutto, in fase di progettazione delle pagine perché consente di identificare quali ostacoli e barriere all’accesso possono presentare le varie funzionalità che si intendono utilizzare nella realizzazione.
La lista, inoltre, va utilizzata per valutare il livello di conformità raggiunto nella realizzazione della pagina.
Per la valutazione dell’accessibilità dei contenuti di un sito Web, oltre alla lista, sono utili gli strumenti di valutazione disponibili sul mercato. Va ricordato che questi strumenti automatici non bastano mai da soli a garantire la conformità al livello di accessibilità richiesto. Molte linee guida, infatti, richiedono valutazioni soggettive che nessuno strumento automatico è in grado di fornire.

2.2.4 Le indicazioni dell’Unione Europea
L’Unione Europea dà una grande importanza all’accessibilità dei siti Web delle pubbliche amministrazioni.
Nel Piano d’Azione eEurope 2002 (giugno 2000) si scrive espressamente che: «I siti Web delle pubbliche amministrazioni degli Stati membri e delle istituzioni europee e i relativi contenuti devono essere impostati in maniera tale da consentire ai disabili di accedere alle informazioni e di sfruttare al massimo le opportunità offerte dal sistema di amministrazione on-line» (obiettivo 2, punto c).
Successivamente, in più Risoluzioni, il Consiglio d’Europa ha invitato gli Stati Membri a porre in essere misure specifiche per raggiungere l’obiettivo dell’accessibilità dei siti Web delle pubbliche amministrazioni e ha indicato nell’adozione delle Linee guida del WAI una di queste misure.
Sebbene non tutti gli Stati Membri abbiano formalmente adottato le WCAG 1.0 per la realizzazione dei siti Web pubblici, è universalmente accettato il fatto che essi debbano essere conformi almeno al Livello A, come definito nelle Linee guida.

2.2.5 La normativa italiana: la “Legge Stanca”
Sulla «Gazzetta Ufficiale» n. 13 del 17 gennaio 2004 è stata pubblicata la legge 9 gennaio 2004, n. 4, recante Disposizioni per favorire l’accesso dei soggetti disabili agli strumenti informatici.
La “Legge Stanca” contiene elementi che la pongono all’avanguardia nel campo della accessibilità perché:

  • obbliga l’accessibilità dei contenuti informativi e dei servizi erogati dai sistemi informatici di tutte le pubbliche amministrazioni italiane e degli enti pubblici economici, delle aziende private concessionarie di servizi pubblici, delle aziende municipalizzate regionali, degli enti di assistenza e di riabilitazione pubblici, delle aziende di trasporto e di telecomunicazione a prevalente partecipazione di capitale pubblico e delle aziende appaltatrici di servizi informatici (art. 3);
  • prevede l’obbligo per i datori di lavoro pubblici e privati di porre a disposizione del dipendente disabile la strumentazione hardware e software e la tecnologia assistiva adeguata alla specifica disabilità, anche in caso di telelavoro, in relazione alle mansioni effettivamente svolte (art. 4);
  • prevede l’obbligo dell’accessibilità del materiale formativo e didattico utilizzato nelle scuole di ogni ordine e grado (art. 5);
  • introduce le problematiche relative all’accessibilità e alle tecnologie assistive tra le materie di studio a carattere fondamentale nei corsi di formazione destinati al personale pubblico e prevede che la formazione professionale in genere sia effettuata tenendo conto delle tecnologie assistive (art. 8).

Nel Regolamento di attuazione (art. 10) e nel Decreto Ministeriale (art. 11) sono indicati principi e criteri operativi e organizzativi generali per l’accessibilità e le linee guida indicanti i requisiti tecnici necessari.


2.3 Usabilità

2.3.1 Definizioni e metodologia
La definizione è quella data nello standard ISO 9241-11 Ergonomic requirements for office work with visual display terminals - Guidance on usability, in cui 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». È una definizione molto simile a quella già citata della qualità di un prodotto software [ISO/IEC 9126-1] e per il significato dei termini in essa contenuti si può dire che:

  • l’efficacia nell’uso del prodotto indica l’accuratezza e la completezza con la quale gli utenti raggiungono determinati risultati;
  • l’efficienza nell’uso del prodotto indica le risorse spese in relazione alla accuratezza e completezza con la quale gli utenti raggiungono determinati risultati;
  • la soddisfazione indica la libertà da disagi e vincoli e la disposizione favorevole degli utenti all’uso del prodotto;
  • il contesto d’uso è l’insieme costituito da utente, compito da svolgere, risorse hardware e software utilizzate e ambiente fisico e sociale nel quale il prodotto è utilizzato;
  • il prodotto è il sito Web così come è stato precedentemente definito.

L’essenza delle norme ISO (oltre alle due già citate si deve ricordare anche la ISO/DIS 13407 – Human centered design process for interactive systems) – è 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 bisognerebbe prevedere il coinvolgimento degli utenti in tutte le fasi della progettazione, realizzazione e gestione di un sito Web.
Una metodologia di progettazione centrata sull’utente prevede i seguenti principali elementi:

  1. la costituzione di un gruppo rappresentativo di utenti o panel. Un panel è rappresentativo quando i suoi componenti sono scelti in base ai diversi ruoli e scopi per cui un utente ha interesse a entrare nel sito. Tra i componenti del panel devono essere presenti utenti con disabilità, onde verificare l’accessibilità dei contenuti;
  2. 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;
  3. 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à, che consentano però 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.

La costituzione del panel nei modi descritti è quindi l’elemento centrale della metodologia, perché:

  1. garantisce il livello di realismo, ma anche di consenso e comunicazione sul progetto;
  2. 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.3.2 Principi di usabilità
Non sempre è possibile progettare e realizzare un sito Web utilizzando direttamente la metodologia descritta perché essa richiede l’impiego di risorse umane (campione di utenti, professionisti dell’usabilità ecc.), organizzative e finanziarie non sempre disponibili.
Dalle esperienze fatte impiegando la metodologia, gli esperti di usabilità hanno proposto una serie di Principi e di Criteri che possono guidare le decisioni di progettazione per raggiungere efficacia, efficienza e soddisfazione nella realizzazione di siti Web.
I Principi di usabilità tendono a raggruppare i problemi in categorie generali. In sintesi, i principi più noti sono i seguenti:

Visibilità: mettere in condizione l’utente di riuscire a capire come usare qualcosa semplicemente guardandola.
Esempio: una parola o una frase sottolineata in blu suggeriscono l’idea di essere in presenza di un link da visitare, se la sottolineatura è di color porpora vuol dire che il link è stato visitato.

Inviti funzionali (Affordance): fare in modo che gli oggetti si comportino come il loro aspetto suggerisce.
Per svolgere la funzione a esso associata, un pulsante suggerisce l’azione di essere premuto e non, ad esempio, quella di essere selezionato.

Natural Mapping: stabilire corrispondenze concettuali tra comandi e funzioni.
Ad esempio, la struttura di un modulo per effettuare ricerche suggerisce che si deve inserire il testo da cercare nel campo di input e poi premere il pulsante “Invia”.

Vincoli: ridurre il numero di modalità con cui una certa azione può essere eseguita e progettare i comandi per eseguire l’azione in modo da renderne facile e comprensibile l’utilizzo.

Modelli Concettuali: l’utente ha una idea di come qualcosa funziona basata sulla propria esperienza e sulla propria conoscenza.
Un buon modello concettuale di un sito Web è quello nel quale le funzionalità proposte corrispondono il più possibile all’idea che l’utente ha di quelle funzionalità.

Feedback: indicare all’utente lo stato della operazione intrapresa e il suo risultato, positivo o negativo che sia.
Ad esempio, quando l’utente effettua lo scaricamento di un file indicare il tempo necessario e lo stato di avanzamento dell’operazione, ovvero quando l’utente invia una form confermare la avvenuta ricezione.

Sicurezza (Safety): limitare al massimo la possibilità che l’utente commetta errori.
In caso di errore, dare informazioni sul possibile perché e su come rimediare.

Flessibilità: dare la possibilità di svolgere un’operazione in modi diversi.
Per esempio, prevedere diversi percorsi di navigazione per raggiungere un documento.


2.4 Criteri di usabilità per le AWCP
Per la definizione di un quadro per la qualità delle WAI, l’applicazione di questi Principi alla progettazione e alla realizzazione di siti Web ha portato, nell’ambito del Progetto Minerva, alla selezione di Criteri di usabilità che approfondiscono con maggiore dettaglio questi problemi. I Criteri sono stati suddivisi in Categorie che rappresentano esigenze degli utenti e che devono essere soddisfatte. Li riportiamo a titolo esemplificativo:

Far percepire i contenuti
1.1 Riconoscere di essere in un sito che è un’WAI
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à

Presentare i contenuti
1.5 Layout funzionale
1.6 Elementi grafici funzionali
1.7 Elementi multimediali funzionali

Far navigare il sito
1.8 Chiarezza dei link
1.9 Validità dei link
1.10 Copertura dei link
1.11 Validità dei percorsi all’indietro
1.12 Chiarezza del contesto rispetto al sito
1.13 Validità del controllo sui media
1.14 Chiarezza del controllo sui media

Far effettuare ricerche
1.15 Comprensibilità dei moduli di ricerca
1.16 Comprensibilità dei risultati delle ricerche
1.17 Navigabilità dei risultati delle ricerche


2.5 Pattern e linguaggio di Pattern 1

I Principi di usabilità, in quanto generali, sono spesso difficili da applicare e i Criteri che forniscono istruzioni più dettagliate si prestano a diverse interpretazioni oppure sono legati a un particolare ambiente tecnologico. Questi problemi, seppure in misura minore, si riscontrano anche nell’applicazione delle Linee guida sull’accessibilità.
Un approccio diverso 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 questo metodo si giova, per definizione, di esperienze concrete fatte con gli utenti.

2.5.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.5.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. L’interattività, intesa come possibilità di comunicazione diretta tra cittadino e WAI diventa una funzionalità importante che non può mancare.
Nell’appendice 3 sono presentati il Catalogo dei Pattern e la loro definizione.

2.5.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.5.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] Gran parte dei Pattern presentati nel Catalogo (v. appendice n. 3) si ispira ai lavori di Martijn Van Welie (http://www.welie.com/Patterns/) 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


   
 
Copyright Minerva Project 2004-04, last revision 2004-04-27, edited by Minerva Editorial Board.
URL: www.minervaeurope.org/publications/qualitycriteria-i/indice0402/capitolosecondo0402.htm