|
|
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:
- 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;
- 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;
- 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é:
- garantisce il livello di realismo, ma anche di consenso e comunicazione
sul progetto;
- 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:
- Esaminare l’intera sequenza, il Catalogo dei Pattern, che è
disponibile.
- Individuare, attraverso il nome, il Pattern che meglio identifica il
progetto/problema che si deve affrontare.
- 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).
- Leggere il Pattern successivo evidenziato sulla lista e segnare di
nuovo i Pattern inferiori a cui è correlato.
- 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.
- Si continua così fino all’identificazione di tutti i Pattern
che si vuole includere nel progetto.
- Giunti a questo punto bisogna aggiustare la lista aggiungendo, se necessario,
propri elementi.
- 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:
- Si può verificare dal Contesto, dalle Condizioni e dalla proposizione
del Problema se il Pattern è adeguato al caso in esame.
- 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.
- 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).
- 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.
- 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.
- 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.
- La lista, completa di tutte le definizioni, costituisce un documento
che può essere utilizzato per la realizzazione della funzionalità
Newsletter.
- 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
|
|
|