Con Drupal è possibile realizzare diversi tipi di siti Web o intranet, per pubblicare articoli, circolari, news, insiemi di messaggi/commenti, forum di discussione, blog, raccolte di immagini etc.
Drupal è Open Source a costo ZERO, e può essere liberamente scaricato, distribuito ed installato.
Drupal è un applicazione Web. Questo significa che i contenuti vengono inseriti e visualizzati attraverso un Web browser (Internet Explorer, Mozilla Firefox, Opera etc.). È possibile realizzare siti Web pubblici o locali (intranet).
Drupal consente agli utenti di registrarsi e autenticarsi in modo da tenere traccia di chi è autore di ogni singolo contenuto, e permettere agli amministratori di consentire livelli di accesso differenziati a seconda dei ruoli (utente, moderatore, amministratore, etc.).
Drupal consente di organizzare i contenuti in base a:Punti di forza di Drupal sono sicuramente l'ampia flessibilità e configurabilità, la robustezza e la gestione della sicurezza.
Drupal è realizzato in modo modulare, consentendo di aggiungere numerose funzionalità aggiuntive al sistema di base.
La facilità di inserimento dei contenuti è a prova di principiante, è sufficiente saper realizzare un testo digitandolo su una tastiera di computer e conoscere le funzioni di copia/incolla. Una utile soluzione al problema della immediatezza ed efficienza nelle operazioni di divulgazione delle informazioni viene offerta dalla possibilità di attivazione di newsletters automatiche (distribuzione periodica di circolari e documenti).
La possibilità di realizzare aree a protezione differenziata consente di pubblicare con tutta sicurezza documenti riservati solo a particolai utenti.
Altra caratteristica importantissima che Drupal ha nel campo della distribuzione dinamica delle informazioni è quella che è in grado di realizzare automaticamente flussi di informazione categorizzati trasmessi come feed RSS consentendo agli utenti di acquisire automaticamente le informazioni senza aver bisogno di accedere ai siti che le hanno pubblicate.
SitografiaRisorse, Strumenti e Soluzioni
Accesso alla Mailing list del gruppo
Modulo 1: La produzione di risorse per il WEB
ore di laboratorio: 12 (4 incontri)
ore on-line (Esercizi): 8
Date delle 4 lezioni: 23 aprile, 7/14/21 maggio.
Abilità nell’uso del computer richieste al corsista: elaborazione testi, navigazione su internet, utilizzo della posta elettronica, installare e disinstallare programmi, operazioni su files e cartelle.
Contenuti del modulo 1:
Modulo 2: La realizzazione di siti web dinamici
ore di laboratorio: 30 (6+24) 10 incontri (2+8)
ore on-line (Esercizi): 20 (4+16)
Prima fase ore: 6 (2 incontri)
Date delle lezioni: 28 maggio e 4 giugno.
Abilità nell’uso del computer richieste al corsista: tutte quelle previste dal modulo 1
Contenuti:
Seconda fase ore: 24 (n. 8 incontri)
Date delle lezioni
17 e 24 settembre
1, 8, 15, 22, 29 ottobre
5 novembre
Contenuti:
Modulo 3: Il sito web della scuola
ore di laboratorio: 18 (6 incontri)
ore on-line (Esercizi): 12
Date delle lezioni
12, 19, 26 novembre
3, 10, 17 dicembre
Abilità nell’uso del computer richieste al corsista: tutte quelle previste dal modulo 2
Il corsista deve essere già in possesso di un sito internet attivo e funzionante realizzato su piattaforma Drupal aggiornata all’ultima versione.
Contenuti:
Date delle lezioni:
23 aprile
7/14/21 maggio.
Il modulo 1 prevede attività di auto formazione con scrittura a mano di codice XHTML, fogli di stile, validazioni, accessibilità e usabilità.
Obiettivo: Acquisire dimestichezza nella scrittura di codice.
XHTML[ i ]: Il codice standard utilizzato per la creazione di pagine web
Date delle 2 lezioni: 23 aprile e 7 maggio.
L'XHTML (acronimo di eXtensible Hypertext Markup[ i ] Language, Linguaggio di marcatura di ipertesti estensibile) è un linguaggio di marcatura che associa alcune proprietà dell'XML[ i ] con le caratteristiche dell'HTML[ i ]: un file XHTML è un pagina HTML scritta in conformità con lo standard XML.
Il linguaggio prevede un uso più restrittivo dei tag[ i ] HTML sia in termini di validità che in termini di sintassi, in modo da descrivere solo la struttura logica della pagina, mentre il layout e la resa grafica sono imposti dai fogli di stile a cascata (Cascading Style Sheets, CSS[ i ]).
L'XHTML è nato ufficialmente il 26 gennaio 2000 come standard del World Wide Web Consortium (W3C[ i ]), e può essere definito tecnicamente una riformulazione dell'HTML 4.01 in XML 1.0; è una sorta di "ponte" tra questi due linguaggi.
da Wikipedia http://it.wikipedia.org/wiki/XHTML
La Guida su HTML.it
http://xhtml.html.it/guide/leggi/52/guida-xhtml/
Specifiche del W3c
http://www.w3.org/markup
Riferimenti e risorse
http://www.mariovarini.it/drupal/specifiche_del_w3c
http://www.mariovarini.it/drupal/specifiche_del_w3c_in_italiano
http://www.diodati.org/w3c/
w3schools.com
http://www.w3schools.com/
HTML http://www.w3schools.com/html/default.asp
XHTML http://www.w3schools.com/xhtml/default.asp
TAG http://www.w3schools.com/tags/default.asp
Esercizi http://www.w3schools.com/html/html_examples.asp
Altre risorse
http://www.mariovarini.it/drupal/accessibilit_e_usabilit
Link e Libri
http://xhtml.html.it/guide/lezione/1745/risorse-xhtml-e-xml-sul-web/
http://xhtml.html.it/guide/lezione/1746/libri-su-xhtml/
<!--break-->
Separare la forma dal contenuto: CSS[ i ], lo standard per la realizzazione dei fogli di stile
Date delle 2 lezioni: 14 e 21 maggio.
I fogli di stile a cascata, meglio noti con l'acronimo CSS (dall'inglese Cascading Style Sheet) e detti anche semplicemente fogli di stile, vengono usati per definire la rappresentazione di documenti HTML[ i ], XHTML[ i ] e XML[ i ]. Le regole per comporre i fogli di stile sono contenute in un insieme di direttive (Recommendations) emanate a partire dal 1996 dal W3C[ i ].
L'introduzione dei fogli di stile si è resa necessaria per separare i contenuti dalla formattazione e permettere una programmazione più chiara e facile da utilizzare, sia per gli autori delle pagine HTML che per gli utenti.
da Wikipedia http://it.wikipedia.org/wiki/Cascading_Style_Sheet
La guida di HTML.it
http://css.html.it/guide/leggi/2/guida-css-di-base/
Specifiche del W3c
http://www.webstyles-italian.info/Style/CSS/
http://www.diodati.org/w3c/css2/cover.html
w3schools.com
http://www.w3schools.com/
http://www.w3schools.com/css/default.asp
http://www.w3schools.com/css/css_examples.asp
Altre risorse
http://www.mariovarini.it/drupal/css_fogli_di_stile
http://www.mariovarini.it/drupal/formattazione_testo
http://www.mariovarini.it/drupal/download_esempi_css
<!--break-->
Per gli esercizi proposti vengono riconosciute numero 8 ore on-line
Scrivere codice XHTML e CSS pulito e validato è di fondamentale importanza. Quando vi troverete a gestire veramente il sito della vostra scuola, vi accorgerete che la totalità dei documenti che vi saranno consegnati per la pubblicazione dovrà essere convertita in HTML e vi accorgerete pure che l'operazione non sarà per voi indolore! Se non conoscete e mettete in atto i rudimenti del codice in breve tempo vi troverete ad avere a che fare con un sito con grosse difficoltà di distribuzione dell'informazione: pagine pesanti piene di codice proprietario ed inutile e inaccessibili ai disabili psicosisici e tecnologici.
Non ultimo, la conoscenza del codice permette di poter effettuare le modifiche ai moduli di Drupal che spesso si rendono necessarie per raggiungere la validazione del documento e la sua conformità agli standard.
Vi consiglio di non trascurare per nessun modivo questi importanti competenze senza le quali verrà vanificato tutto il vostro impegno nella realizzazione di un sito di qualità, accessibile, usabile e in armonia con i principi della progettazione universale.
Buon lavoro.
Scrittura di codice XHTML
Effettuare la conversione da file .doc a .htm senza l'utilizzo di editor html (Es. Dreamweaver)
Validare il documento .htm sul w3c
Consegna esercitazione: trasmettere il file cognome_nome_11.htm (via email a Mario Varini): entro il 7 maggio 2009
Ore di autoformazione: 1
Contenuti dell'esercizio
Scrittura di codice XHTML
effettuare la conversione da file .doc a .htm senza l'utilizzo di editor html (Es. Dreamweaver)
Validare il documento.htm sul w3c
Consegna esercitazione: trasmettere il file cognome_nome_12.htm (via email a Mario Varini): entro il 14 maggio 2009
Ore di autoformazione: 1
Contenuti dell'esercizio
Utilizzo dei fogli di stile 2
Ore di autoformazione: 1
Consegna esercitazione: entro il 28 maggio 2009
Modalità di consegna: realizzare la pagina proposta, inserire contenuti minimi e trasmetterla in un file zip unitamente a eventuali immagini e fogli di style correlati.
Materiali: Scarica lo zip d'esempio.:
[documentazione ed esempi a cura di http://www.constile.org ]
In questo esercizio vedremo come formattare l'articolo mostrato nella pagina di esempio rivolgendo particolare attenzione ai paragrafi, alle immagini e alle citazioni.
Per realizzare il titolo e la descrizione sono stati utilizzati gli header H1 e H2, per indicare l'autore è stato utilizzato un div con un identificatore.
Questa parte non necessita di particolari commenti poiché ci siamo limitati a specificare i font, i colori, gli allineamenti ed margini e bordi. Il codice utilizzato è il seguente:
CSS
h1 {
font:italic 900 5em/1em georgia, serif;
color: #F93;
display: block;
margin:50px 0 0 0;
border-top: 5px double #F93;
border-bottom: 2px solid #F93;
padding-left: 50px;
}
h2 {
font: italic 900 1.5em/1em verdana, helvetica, sans-serif;
display: block;
margin:10px 0;
text-align: right;
padding-right: 100px;
}
#autore {
font: .70em verdana, helvetica, sans-serif;
text-align: right;
margin:1px 0;
padding-right:50px;
border-style: solid none;
border-width: 1px;
border-color: #F93;
}
(X)HTML
<h1>Titolo dell'articolo</h1>
<div id="autore">di Pinco Pallino</div>
<h2>Spazio dedicato ad una breve
introduzione per descrivere l'argomento
trattato nell'articolo</h2>
#articolo {
font: 1em georgia, serif;
margin:0 50px 50px 50px;
padding-bottom:2em;
border-bottom: 2px dotted #F93;
}
Il corpo dell'articolo è stato racchiuso in un DIV identificato dal selettore #articolo. Oltre a specificare margini per distanziare il testo dal bordo, la visibilità del testo è stata aumentata utilizzando un carattere serif di dimensioni sufficientemente grandi.
#articolo p {
text-indent: 2em;
text-align: justify
}
Per migliorare l'identificazione dei diversi paragrafi all'interno dell'articolo, abbiamo indentato il paragrafo e giustificato il testo. Un esempio è riportato nella seguente immagine:
![[Immagine: Esempio di paragrafo giustificato con un'indentazione di 2em]](http://www.constile.org/images/tutorial/come_formattare_un_articolo/paragrafo.gif "Esempio di paragrafo giustificato con un'indentazione di 2em")
Spesso negli articoli il primo paragrafo, specialmente la prima lettera, è formattato diversamente dal resto dell'articolo. Nel nostro caso si è scelto di formattare differentemente la prima riga e la prima lettera del primo paragrafo.
I CSS mettono a disposizione lo pseudo-elemento first-child che permetterebbe di riconoscere il primo paragrafo dell'articolo attraverso il selettore #paragrafo p:first-child, ma purtroppo solo i browser basati su Geko sono in grado di riconoscere lo pseudo-elemento first-child. Dovremo dunque introdurre un nuovo identificatore, #primo-paragrafo, da utilizzare nel selettore #articolo p#primo-paragrafo. La prima lettera e la prima riga del primo paragrafo saranno selezionati attraverso i seguenti selettori: #articolo p#primo-paragrafo:first-letter e #articolo p#primo-paragrafo:first-line.
#articolo p#primo-paragrafo:first-letter {
font-size: 3em;
font-style: italic;
float: left;
background: #F93;
color: #FFF;
margin:0 5px 5px -50px;
padding: 5px 5px 5px 50px;
line-height:1em;
}
La prima lettera del primo paragrafo è alta il triplo del testo dell'articolo ed è in corsivo. Attravero la proprietà float:left si ottiene l'effetto di circondare la lettera col resto dell'articolo. Ulteriore risalto è dato specificando un colore di background e del testo differenti dal resto dell'articolo.
Specificando un margine sinistro pari (ma negativo) al margine specificato per il corpo dell'articolo (50px) e un padding sinistro pari (positivo) al margine sinistro (-50px) si ottiene un effetto a "linguetta". Affinché l'effetto funzioni correttamente, il primo paragrafo non deve essere indentato, per fare ciò si utilizza la seguente regola:
#articolo p#primo-paragrafo { text-indent: 0em; }
La prima lettera del primo paragrafo apparirà come nella seguente immagine:
![[Immagine: Esempio di come appare la prima lettera, maggiori dettagli sono disponibili nell'articolo]](http://www.constile.org/images/tutorial/come_formattare_un_articolo/primalettera.gif "Esempio di come appare la prima lettera, maggiori dettagli sono disponibili nell'articolo")
Per la prima riga del primo paragrafo si è scelto di utilizzare il maiuscoletto, il codice CSS utilizzato è il seguente:
#articolo p#primo-paragrafo:first-line {
font-variant: small-caps;
}
#articolo blockquote {
width:20%;
font: .70em/2em verdana, helvetica, sans-serif;
word-spacing: .2em;
padding: 2.5em 1em;
margin: 0 0 2em 2em;
border:1px solid #F93;
float:right;
}
#articolo blockquote span.special-quote {
color: #F93;
font: italic 900 2em/1em georgia, serif;
}
Per le citazioni si è utilizzato il tag BLOCKQUOTE. Attraverso la proprietà float: right si permette al resto dell'articolo di disporsi attorno al box della citazione. La larghezza è stata impostata al 20%, margini e padding sono stati regolati per fornire un aspetto più ordinato al box. Il carattere è diverso da quello dell'articolo per meglio rappresentare la separazione fra articolo e citazione.
Affinché le virgolette fossero evidenziate è stata creata la classe special-quote. Dimensioni dei font e interlinea sono stati impostati al fine di avere un insieme armonico. Si noti ad esempio che l'interlinea dell'elemento BLOCKQUOTE è stato impostato al valore 2em che è la dimensione scelta per le virgolette della classe special-quote, la cui interlinea è pari a 1em e quindi coincidente a quella del testo (La classe special-quote ha un'interlinea pari al 100% della dimensione del prorprio font che è il 200% del font del testo dell'elemento BLOCKQUOTE che ha un'interlinea pari al 200% della dimensione del font, dunque le due interlinee sono uguali). Un'esempio è riportato nella seguente immagine:
![[Immagine: Esempio di come appare il box delle citazioni, maggiori dettagli sono disponibili nell'articolo]](http://www.constile.org/images/tutorial/come_formattare_un_articolo/citazione.gif "Esempio di come appare il box delle citazioni, maggiori dettagli sono disponibili nell'articolo")
#articolo div.immagine {
width:200px;
padding:5px;
font: .70em verdana, helvetica, sans-serif;
margin:0px 10px 10px 0px;
border:1px solid #F93;
float:left;
}
#articolo div.immagine img {
border-bottom:3px solid #F93;
display:block;
padding-bottom:1px;
}
Per le immagini è stata specificata la classe immagine da utilizzare col tag div. Attraverso la proprietà float: left si permette al resto dell'articolo di disporsi attorno all'immagine. La larghezza è stata impostata a 200px, supponendo di utilizzare immagini larghe 200px. Margini e padding sono stati regolati per fornire un aspetto più ordinato al box. Il carattere del commento dell'immagine è diverso da quello dell'articolo per meglio rappresentare la separazione fra articolo e commento all'immagine.
Attraverso il selettore #articolo div.immagine img è possibile specificare le caratterisitiche dell'immagine, in particolare si è usata la proprietà display: block affinché il testo descrittivo sia posto sotto l'immagine. Nella parte inferiore dell'immagine è stato specificato un bordo di 3 pixel separato dall'immagine da un padding di 1 pixel. Un'esempio è riportato nella seguente immagine:
![[Immagine: Esempio di come appare un'immagine col suo commento, maggiori dettagli sono disponibili nell'articolo]](http://www.constile.org/images/tutorial/come_formattare_un_articolo/immagine.gif "Esempio di come appare un'immagine col suo commento, maggiori dettagli sono disponibili nell'articolo")
Con questo articolo abbiamo dimostrato come, senza l'utilizzo di tabelle e altri artifici, sia possibile formattare un articolo rendendolo piacevole e senza influenzare in alcun modo l'accessibilità della pagina. A tale proposito si osservi come la stessa pagina priva dei CSS appaia usabile e accessibile con tutti i disposotivi per l'accesso a internet.
Utilizzo dei fogli di stile 2
Ore di autoformazione: 1
Consegna esercitazione: entro il 28 maggio 2009
Modalità di consegna: realizzare la pagina proposta, inserire contenuti minimi e trasmetterla in un file zip unitamente a eventuali immagini e fogli di style correlati.
Materiali: Scarica lo zip d'esempio.:
[documentazione ed esempi a cura di http://www.constile.org ]
In questo esercizio vedremo come realizzare un layout a tre colonne sfruttando il posizionamento assoluto invece della proprietà float. Attraverso tre diversi CSS, col medesimo codice XHTML, otterremo tre diversi tipi di layout: a larghezza prefissata, liquido con colonne laterali di larghezza prefissata, completamente liquido.
Come detto utilizzeremo lo stesso codice XHTML per ottenere le tre versioni. Ciò non deve sorprendere poiché i CSS sono stati creati per separare i contenuti dal modo in cui questi sono presentati. Il codice utilizzato per il body è il seguente:
<body>
<!-- testa -->
<div id="testa"><h1>NomeSito</h1></div>
<!-- /testa -->
<hr />
<!-- corpo -->
<div id="corpo">
<div id="corpo-colonna1">[...]</div>
<hr />
<div id="corpo-colonna2">[...]</div>
<hr />
<div id="corpo-colonna3">[...]</div>
</div>
<!-- /corpo -->
<hr />
<!-- pie' di pagina -->
<div id="piedipagina"><p>pié di pagina</p></div>
<!-- pie' di pagina -->
</body>
La pagina è così strutturata:
id="testa"id="corpo", suddiviso in tre colonne:
id="piedipagina"La struttura, come evidenziato dal codice, è stata ottenuta attraverso dei tag DIV, identificati attraverso l'attributo ID. Fra le varie sezioni sono stati inseriti degli HR, il cui scopo è quello di evidenziare la separazione dei contenuti anche quando il browser non è in grado di leggere o interpretare il foglio di stile.
Come detto i tre diversi layout saranno applicati attraverso tre diversi fogli di stile. In tutti e tre i casi, in luogo della proprietà float, come nel precedente articolo sul layout a tre colonne, si è fatto uso del posizionamento assoluto.
Il principio su cui si costruiscono i tre layout è basato su quanto segue. Innanzitutto si posiziona in maniera relativa il corpo (id="corpo") affinché ogni posizionamento assoluto, di elementi al suo interno, si riferisca al corpo stesso e non a tutta la pagina. In seguito si creano le colonne laterali, impostandone la larghezza e posizionandole in maniera assoluta. A questo punto, le colonne laterali si troveranno sovrapposte alla colonna centrale. Per evitare tale sovrapposizione sarà sufficiente impostare i margini laterali della colonna centrale.
Questa tecnica offre vantaggi rispetto al classico uso della proprietà float (trascurando i soliti vantaggi rispetto l'uso delle tabelle), ma presenta anche uno svantaggio, nulla di grave per fortuna. I vantaggi più evidenti sono la possibilità di disporre le colonne nell'ordine preferito. Ad esempio è possibile scrivere nel codice XHTML prima i contenuti della colonna centrale e poi quelli della colonna laterale, ovvero è possibile spostare tutte e due le colonne sulla destra o tutte e due sulla sinistra della colonna centrale. Nella struttura della pagina, infatti, si è generalizzato parlando di colonna 1, colonna 2, colonna 3, senza specificare quale fosse la colonna di sinistra o di centro o di destra. Un secondo vantaggio consiste nella maggiore robustezza del metodo ai capricci dei browser, che potrebbero "spingere"la colonna di destra sotto quella di sinistra. Lo svantaggio consiste nel fatto che la colonna centrale deve essere sempre più alta di quelle laterali. Questo vincolo in genere può essere facilmente rispettato, poiché la colonna centrale è quella che presenta i maggiori contenuti. Qualora il vincolo non possa essere soddisfatto, è sufficiente aggiungere del padding inferiore (padding-bottom) alla colonna centrale. Il vincolo è dovuto al fatto che le colonne laterali sono posizionate in maniera assoluta, dunque non sono più in grado di influire sulla disposizione degli altri box della pagina. Il piè di pagina si trova posto sotto il corpo, la cui altezza è determinata da quella della colonna centrale (priva di posizionamento assoluto) e del tutto indifferente all'altezza delle colonne laterali, poiché posizionate in maniera assoluta. Se il vincolo non fosse rispettato, le colonne laterali si sovrapporrebbero al footer.
Detto questo, è possibile illustrare i tre CSS utilizzati per la realizzazione dei differenti layout.
Vedremo ora come realizzare il codice per il layout a larghezza prefissata.
Eliminiamo i margini e il padding predefiniti dal browser per il tag BODY, eliminiamo anche gli horizontal-rule, inutili nel layout che realizzeremo.
body { margin:0; padding:0 }
hr { display:none }
Impostiamo la larghezza assoluta, pari a 760 pixel, per #testa, #corpo e #piedipagina. Tutte e tre le sezioni saranno poste al centro della pagina.
body { text-align:center }
#testa {
width:760px;
margin:1em auto;
text-align:left
}
#corpo {
width:760px;
margin:1em auto;
text-align:left
}
#piedipagina {
width:760px;
margin:1em auto;
text-align:left
}
Per posizionare le colonne laterali in maniera assoluta, prendendo come riferimento la sezione #corpo, quest'ultima deve essere posizionata in maniera relativa.
#corpo {
position:relative;
}
Adesso è possibile posizionare le colonne laterali. La prima colonna sarà posta a sinistra e larga 160 pixel:
#corpo-colonna1 {
position:absolute;
top:0; left:0;
width:160px;
}
Il posizionamento assoluto (position:aboslute) consente di porre il nel punto desiderato indipendentemente dagli altri elementi della pagina. Le proprietà top:0; left:0, se associate alla proprietà position:absolute, stabiliscono che il box sia posto esattamente in alto a destra rispetto al box della sezione #corpo, essendo questa posizionata in maniera relativa.
La terza colonna sarà posta in alto a sinistra e sarà larga 200 pixel:
#corpo-colonna3 {
position:absolute;
top:0; right:0;
width:200px;
}
Il codice è praticamente lo stesso di quello usato per regolare la posizione della prima colonna. L'unica differenza (altre al valore della proprietà width) consiste nell'uso della prorietà right:0 in luogo di left:0.
A questo punto le colonne laterali, essendo disposte indipendentemente dagli altri elementi della pagina, saranno sovrapposte alla colonna centrale, poiché questa si sviluppa per tutta la larghezza del corpo. Per evitare questa sovrapposizione è sufficiente impostare i margini della seconda colonna in modo tale da avere a destra e a sinistra lo spazio necessario per contenere comodamente le due colonne:
#corpo-colonna2 {
margin:0 200px 0 160px;
}
Il margine sinistro è largo 160px, proprio come la prima colonna, mentre il margine destro è largo 200px come la terza colonna.
Si ottiene così una struttura come quella rappresentata dalla seguente immagine.
![[Immagine: Figura 1] Il risultato ottenuto col codice finora illustrato.](http://www.constile.org/template/nuovo_layout_a_tre_colonne/figura1.png)
Nell'immagine si vede la struttura con l'intestazione, le tre colonne e il piè di pagina. Per completare il layout, ormai è sufficiente definire i bordi e i colori di sfondo delle varie sezioni.
Gli unici problemi, in questa fase, si presentano con le colonne. Queste non si sviluppano in altezza come la colonna centrale, dunque se i bordi e i colori di sfondo fossero definiti nelle regole per i selettori #colonna-1 e #colonna-3 si avrebbe l'effetto mostrato nella seguente figura:
![[Immagine: Figura 2] Sono evidenziate l'interruzione delle colonne subito dopo i contenuti](http://www.constile.org/template/nuovo_layout_a_tre_colonne/figura2.png)
Si nota che le colonne s'interrompono subito dopo i contenuti.
Il problema è di facile soluzione. Per quanto riguarda i bordi è sufficiente impostarli non nelle colonne laterali ma in quella centrale:
#corpo-colonna2 {
border-left:1px solid #000;
border-right:1px dotted #000;
}
Per quanto riguarda il colore dello sfondo delle colonne, la soluzione è molto semplice. Invece di agire direttamente sullo sfondo delle colonne, si agisce sullo sfondo del corpo e della colonna centrale, lasciando lo sfondo delle colonne trasparente:
#corpo {
background:#f0f0f0;
}
#corpo-colonna2 {
background:#fff
}
In questo modo le colonne laterali, essendo trasparenti, appariranno come se avessero uno sfondo grigio chiaro (#f0f0f0), mentre la colonna centrale avrà uno sfondo bianco. Qualora si volesse che le due colonne non siano dello stesso colore, potremmo sfruttare un'immagine (GIF o PNG) monocromatica (un grigio leggermente più scuro, ad esempio #e0e0e0), larga come la colonna di sinistra (160 pixel) e alta un solo pixel. Impostando quest'immagine come sfondo che si ripete solo verticalmente per il corpo, avremo due colonne di differente colore. Il codice sopra riportato va così modificato:
#corpo {
background:#f0f0f0 url(sfondo_colonna1.png) repeat-y;
}
#corpo-colonna2 {
background:#fff
}
Il risultato del codice finora prodotto è illustrato nell'immagine seguente:
![[Immagine: Figura 3] Il layout quasi completo](http://www.constile.org/template/nuovo_layout_a_tre_colonne/figura3.png)
Ormai manca solo l'impostazione del padding, per allontanare i contenuti dai bordi. Ricordando che il padding destro e quello sinistro vanno a sommarsi alla larghezza del box, non possiamo impostare tali proprietà direttamente nelle regole per le tre colonne, il padding superiore e quello inferiore possono invece essere regolati comodamente:
#corpo-colonna1 {
padding:1em 0;
}
#corpo-colonna2 {
padding:1em 0;
}
#corpo-colonna3 {
padding:1em 0;
}
Come fare dunque ad allontanare i contenuti delle colonne dai bordi? La risposta è semplice se consideriamo che le colonne sono solo dei contenitori per i contenuti. Questi contenuti saranno dei testi racchiusi da paragrafi (tag P), ovvero saranno a loro volta racchiusi in altri contenitori, come ad esempio liste, box e così via. Nella pagina d'esempio, i contenuti sono porzioni del codice CSS adottato, racchiusi nel tag CODE. L'allontanamento dai bordi è stato ottenuto impostando i margini di tal elemento:
code {
font:80% verdana,helvetica,sans-serif;
display:block;
margin:0 1em .5em 1em;
}
Il risultato finale, di cui è disponibile un esempio, è una pagina con intestazione, piè di pagina e un corpo a tre colonne, tutto con larghezza fissata in modo assoluto.
L'unica differenza col layout precedentemente illustrato è nella larghezza dell'intestazione, del corpo e del piè di pagina. In questo caso infatti gli elementi della pagina si allargano per occupare sempre la stessa porzione dello spazio disponibile. Per maggiore chiarezza si veda l'esempio.
Volendo, ad esempio, che il layout occupi il 90% dello spazio disponibile, sarà sufficiente modificare il codice precedentemente illustrato come di seguito riportato:
#testa { width:90%; }
#corpo { width:90%; }
#piedipagina { width:90%; }
Il resto del codice può restare tranquillamente invariato.
L'ultimo layout che sarà considerato in questo articolo è quello totalmente liquido. Rispetto al layout liquido con colonne laterali di larghezza prefissata, in questo caso le colonne avranno anch'esse una larghezza espressa in percentuale.
Si voglia ad esempio che la prima colonna sia larga il 20% del corpo e la terza colonna sia larga il 25%. Per maggiore chiarezza si veda l'esempio. La larghezza delle colonne laterali e i margini della colonna centrale andranno adattati di conseguenza.
Rispetto alla versione liquida con colonne laterali di larghezza prefissata, il codice CSS va dìmodificato come segue:
#corpo-colonna1 { width:20% }
#corpo-colonna3 { width:25% }
#corpo-colonna2 { margin:0 25% 0 20% }
Con queste modifiche però, non è nota a priori la larghezza delle colonne. Non è più consigliabile l'utilizzo di una immagine di sfondo per impostare il colore di una delle due colonne. Il codice CSS riguardante lo sfondo del corpo sarà modificato come segue:
#corpo { background:#f0f0f0; }
I template sono stati testati con successo con IE5.5 e IE6, Mozilla 1 (Netscape Navigator 6), Opera 6, Opera 7 (BETA), Konqueror 3.0.4. L'unico problema si è verificato con Opera 6, il quale non interpreta correttamente il margine fra testa, corpo e piè di pagina.
Consegna esercitazione: trasmettere, via email a Mario Varini, l'URL del sito e la Checklist per l'accessibilità realizzata entro il 30 giugno 2009
Ore di autoformazione: 2
Scegli un sito scolastico a tuo piacimento ed effettua una indagine al fine di verificare il rispetto degli standard definiti dalle linee guida del W3c e dalla legislazione italiana (vedi Legge Stanca).
I risultati dell'indagine e la relativa analisi sugli interventi da porre in essere al fine di migliorare l'accessibilità del sito saranno condivisi in un'apposita area in appendice alle esercitazioni.
Requisito indispensabile per sviluppare siti accessibili è sapere innanzitutto cosa si intende con i termini "accessibile" e "accessibilità". Ma da dove prendere queste definizioni? A quali riferimenti tecnici si ispirerà la nascente legge italiana? Benché il progetto di legge Stanca preveda l'istituzione di un'apposita commissione tecnica, a cui sarà demandato il compito di definire materialmente le regole di accessibilità valide per i siti italiani interessati dall'applicazione della legge, possiamo essere sufficientemente sicuri che la fonte tecnica normativa a cui le specifiche italiane si ispireranno saranno le raccomandazioni internazionali sull'accessibilità prodotte dal WAI.
WAI è l'acronimo di Web Accessibility Initiative, ovvero "Iniziativa per l'Accessibilità del Web". Si tratta di una sezione del World Wide Web Consortium (meglio noto come W3C). Quest'ultimo è l'organismo internazionale senza fini di lucro, che - ormai dal lontano 1994 - ha il compito di definire i linguaggi e le procedure standard per rendere il Web uno strumento realmente democratico ed universale.
I gruppi di lavoro creati all'interno del WAI hanno prodotto negli anni una serie di raccomandazioni tecniche, mirate a dare agli sviluppatori gli strumenti per rendere accessibili non solo i contenuti del Web, ma anche i programmi per navigare in Rete nonché quelli utilizzati per produrre e pubblicare contenuti. Ai fini di questa guida, poiché il nostro scopo è dare indicazioni su come creare pagine web e siti accessibili, le raccomandazioni che ci interessano sono le Web Content Accessibility Guidelines (in italiano "Linee guida per l'accessibilità dei contenuti Web"), più brevemente conosciute come WCAG e giunte attualmente alla versione 1.0, rilasciata dal WAI-W3C come documento ufficiale con valore normativo in data 5 maggio 1999.
Occorre a questo punto precisare che è ormai in avanzata fase di elaborazione la versione 2.0 delle WCAG, consultabile come bozza di lavoro ("working draft", in inglese) sul sito del W3C. Ci occuperemo più avanti di fornire qualche anticipazione su questa nuova versione delle linee guida per l'accessibilità dei contenuti Web, con particolare riguardo alle differenze introdotte rispetto alla versione 1.0. Per il momento, tuttavia, l'unico documento normativo del W3C sull'accessibilità restano le WCAG 1.0.
Come anticipato più sopra, riteniamo che saranno con ogni probabilità proprio queste linee guida i riferimenti tecnici che trapasseranno più o meno integralmente nella normativa italiana. Ciò non solo perché il Parlamento Europeo ha già indicato le raccomandazioni prodotte dal WAI-W3C come le regole di accessibilità da applicare per i siti europei (con l'esplicita richiesta di raggiungere almeno la conformità al livello Double-A) , ma perché un lavoro di completa ridefinizione degli standard di accessibilità da parte di una commissione tecnica italiana richiederebbe non meno di uno o due anni di lavoro, con il conseguente slittamento a data da destinarsi dell'obbligo di applicare la legge. Non solo: con il rischio di ritrovarsi alla fine con delle regole di accessibilità proprietarie, di efficacia tutta da verificare sul campo, non omogenee rispetto allo standard internazionale rappresentato dalle WCAG del WAI-W3C. Uno standard, quest'ultimo, che è sicuramente perfettibile ed in larga misura ancora trascurato, per quanto riguarda la sua applicazione da parte della massa degli sviluppatori, ma che tuttavia rappresenta un notevole patrimonio di conoscenze e di esperienza, oltre che un lodevole tentativo di uniformare a livello mondiale il modo di approcciare il problema dell'accessibilità.
Non crediamo, insomma, che all'Italia convenga intraprendere lo stesso cammino percorso dagli Stati Uniti, che, con le sedici regole della famosa Section 508 , hanno di fatto riscritto l'accessibilità a uso esclusivo delle Pubbliche Amministrazioni USA, con risultati che - a detta di esperti come Emily Dixon di Usablenet, che li conoscono bene dall'interno - sono stati finora tutt'altro che entusiasmanti.
Ci auguriamo invece che la commissione tecnica italiana, che sarà istituita con la prossima legge sull'accessibilità, recepisca lo standard internazionale rappresentato dalle WCAG, focalizzando il proprio lavoro non tanto sulla riscrittura delle regole quanto sul loro adeguamento all'uso concreto da parte degli sviluppatori italiani: si preoccupi soprattutto, cioè, di metterne in luce le ambiguità e i problemi, fornendo soluzioni pratiche e supporto tecnico a chi avrà l'obbligo di rendere il proprio sito conforme al dettato della nuova legge.
Questa non è una lista definitiva. Ci sono probabilmente molti elementi che potranno essere aggiunti.
1. Qualità del codice
2. Grado di separazione tra contenuto e presentazione
3. Accessibilità per gli utenti
4. Accessibilità per i dispositivi
5. Usabilità di base
6. Gestione del sito
Consegna esercitazione: trasmettere, via email a Mario Varini, l'URL del sito e la Checklist per l'usabilità realizzata entro il 31 luglio 2009
Ore di autoformazione: 2
Scegli un sito scolastico a tuo piacimento ed effettua una indagine al fine di verificare il rispetto dei principi definiti nel Sun Usability Lab.
I risultati dell'indagine e la relativa analisi sugli interventi da porre in essere al fine di migliorare l'usabilità del sito saranno condivisi in un'apposita area in appendice alle esercitazioni.
Alcuni controlli per verificare l'usabilità di una pagina o un sito Web:
Cos'è Drupal e cosa può fare per me
Date delle lezioni:
28 maggio
4 giugno
pausa estiva
17 e 24 settembre
1, 8, 15, 22, 29 ottobre
5 novembre
Drupal è un CMS, ovvero un gestore di contenuti e di siti Web dinamici realizzato in PHP. Con Drupal è possibile realizzare diversi tipi di siti Web o intranet, per pubblicare articoli, insiemi di messaggi/commenti, forum di discussione, blog, raccolte di immagini etc. Drupal consente agli utenti di registrarsi e autenticarsi in modo da tenere traccia di chi è autore di ogni singolo contenuto, e permettere agli amministratori di consentire livelli di accesso differenziati a seconda dei ruoli (utente, moderatore, amministratore, etc.).
Drupal consente di organizzare i contenuti in base alla tipologia (pagina, messaggio del forum, immagine, etc) e alla categoria assegnata dall'amministratore: una singola pagina può essere per esempio classificata come articolo, documentazione, descrizione prodotto, etc. Questo consente di dividere i contenuti in modo estremamente flessibile, rendendone semplice l'inserimento e la visualizzazione, e consentendo di realizzare uno schema di navigazione del sito estremamente funzionale Drupal è Open Source, e può essere liberamente scaricato, distribuito e installato. Gli amministratori con esperienza di programmazione PHP possono liberamente accedere al codice sorgente per modificare l'applicativo in base alle loro esperienze. Punti di forza di Drupal sono sicuramente l'ampia flessibilità e configurabilità, la robustezza e la gestione della sicurezza. Drupal è realizzato in modo modulare, consentendo di aggiungere numerose funzionalità aggiuntive al sistema di base.
È disponibile la sezione Drupal: il video-corso.
FINE prima parte. Si riprende nel mese di settembre.
Avvertenze
Il video corso è relativo alla installazione della versione 5.6 di drupal, ma tutte le operazioni possono essere riferite anche all'attuale versione 6.10 aggiornata al febbraio 2009
Preleva i video del corso in formato swf per una comoda consultazione off-line.
I Video possono essere liberamente utilizzati anche in pubblico con l'indicazione che non possono essere venduti o acquistati. le immagini di inizio e fine riportano l'indicazione dell'autore e sono parte integrante del video.
Buon divertimento
jamboo
<!--break-->
Consegna esercitazione: comunicare a Mario Varini via email l'URL del proprio sito unitamente alle credenziali amministrative (user e password del sito, dello spazio web e del server MySql) entro il 4 giugno 2009
Ore di autoformazione: 2
Consegna esercitazione: comunicare a Mario Varini via email di aver terminato l'esercitazione entro il 11 giugno 2009
Ore di autoformazione: 2
Il sito web della scuola: layout, sezioni, servizi, sicurezza e policy
Date delle lezioni:
12, 19, 26 novembre
3, 10, 17 dicembre
Contenuti:
Esempi, modelli e soluzioni su http://www.minervaeurope.org/structure/workinggroups/userneeds/prototipo/scuolaweb.html
L'area è dedicata agli approfondimenti ed alle esercitazioni a carattere generale da effettuare in autoformazione. Nell'area trovano altresì spazio letture a carattere generale.
Richard Saul Wurman coniò il termine “Information Architecture” (architettura dell’informazione) per la prima volta nel 1975 e definì se stesso un “architetto dell’informazione” (frontwheeldrive.com 2002). L’architettura dell’informazione si riferisce alla struttura o all’organizzazione di un sito web e specialmente a come le singole pagine siano relazionate tra loro. Coinvolge fattori come l’analisi e la pianificazione del contenuto, l’organizzazione della pagina, le etichette, le tecniche di ricerca e la creazione della navigazione. I principi dell’architettura dell’informazione sono radicati nella creazione di banche dati e nel ricupero dell’informazione con forti influenze provenienti dai campi dell’HCI (Human-Computer Interaction), della scienza libraria, delle tecniche di scrittura e della psicologia (organizzazione di concetti e categorie).
Raramente esiste una singola organizzazione logica dell’informazione, e anche se ce ne fosse una sola questa potrebbe non essere quella adatta all’utente. La stessa informazione può assumere svariate strutture logiche secondo come le persone la pensano, ne parlano o la usano. Una organizzazione dell’informazione psicologica o basata sull’uso, riconosce i limiti della mente umana come la capacità della memoria e la necessità di assimilare informazioni attraverso blocchi sequenziali e ben definiti.
Un visitatore del web può riconoscere il genere di un sito web dal suo contenuto, ma il riconoscimento attraverso il solo contenuto potrebbe costare più tempo del riconoscimento attraverso l’espressione e la forma. È un dato di fatto che l’espressione e la forma sono riconosciute a livello di processi sensoriali più immediati rispetto al contenuto. La densità del testo o elementi che lampeggiano possono ad esempio essere captati dalla nostra mente attraverso il semplice sguardo, un processo più semplice della lettura. Il contenuto testuale, di contro, implica l’attivazione di processi più profondi e complicati che riguardano il livello semantico. Analizzare il significante occupa più tempo del solo guardare. Ne risulta che gli utenti afferrano il genere del sito web valutando la sua espressione e la sua forma, e il contenuto testuale serve successivamente a correggere o a perfezionare il loro giudizio iniziale. Un sito web è più al centro dell’utente quanto più il suo contenuto, la sua espressione e la sua forma siano compatibili tra di loro.
Il contenuto dona al genere la sua esclusività e copre argomenti inerenti al tema del sito web. Secondo la natura dell’informazione il contenuto può essere presentato come storia, saggio, recensione, notizia, dato, statistica ecc. Quando l’utente capisce l’argomento del contenuto, può concludere che il sito appartenga al genere dell’informazione appena recepita.
Figura 1 L’utente, attraverso la lettura del contenuto, può ben intuire che il genere del sito appartiene alle librerie on-line.
Nella Figura 1 ( www.bol.com) il contenuto del sito web ci mostra il genere a cui questo appartiene attraverso la recensione di un libro. L’utente può ben intuire, a prescindere dagli altri elementi, che il genere appartiene alle librerie online.
L’espressione del genere è il modo in cui si comunica con l’utente target. Il contenuto di un sito web può essere espresso mediante il testo, la grafica, il suono, la voce, l’animazione ecc. Una delle principali caratteristiche dell’espressione di un contenuto è lo stile. Il volto di una persona che parla, i suoi gesti e l’intonazione della sua voce rappresentano alcuni comportamenti esterni che l’ascoltatore recepisce come parte della componente espressiva del suo messaggio. L’espressione dei comportamenti esterni di chi parla, e non solo le parole, è dunque la componente essenziale che forma una identità unica.
Lo stesso vale per il web. Ciò che distingue un genere da un altro è la combinazione di elementi che definiscono la loro espressione. L’essenza espressiva di una pagina di notizie, ad esempio, sarà la presentazione testuale. L’attenzione cadrà quindi sui dettagli di ciò che fa di essa una buona presentazione testuale. Le foto informative sono ad esempio un buon supporto per il testo delle notizie. I siti web di genere ludico invece si esprimono mediante l’enfasi sulla stilizzazione, sulla luminosità e vivacità dei colori e su immagini generosamente colorate che spesso usano animazioni per suggerire attività di intrattenimento.
La forma del genere è data dal modo in cui gli elementi di un genere di sito web sono arrangiati. Spesso l’arrangiamento dell’informazione in un sito è un indizio circa l’identità del sito stesso. Alcune strutture o arrangiamenti di elementi tendono ad essere prevalenti nella maggioranza dei siti di un dato genere. Ciò è identificativo per quel genere. Ad esempio, nei siti di notizie è ormai comune a tutti il piazzamento di link di notizie correnti al centro e in alto della pagina così come il piazzamento di altre notizie di varia natura nella colonna a destra. Un’altra caratteristica comune ai siti di notizie è la lunghezza della riga testuale secondo che il testo debba essere letto o scansionano. Il testo della riga da scansionare, quello che si trova sotto le intestazioni principali nella Home Page ad esempio, non supera solitamente i 35 caratteri, mentre il testo della riga da leggere è di lunghezza completa.
È importante tuttavia capire che la forma del genere, più del contenuto e dell’espressione, può variare secondo quanto più informazioni si posseggano sulle abitudini e le caratteristiche dell’utente target.
Per delineare l’architettura di un sito web è necessario raccogliere tutto il materiale di cui si è in possesso e organizzarlo secondo una struttura che aiuti l’utente a navigare efficientemente. Per far ciò è utile esporre le informazioni che si hanno a disposizione in un sito non in linea o un diagramma che avrà la funzione di guidare lo sviluppo del sito. Questo processo deve basarsi sull’analisi dei requisiti del sito, le relazioni inerenti al contenuto e l’analisi dell’utente target.
Alcune tappe fondamentali dell’architettura dell’informazione sono:
È necessario identificare i pezzi di contenuto del sito web è realizzare quali informazioni si posseggono e quali informazioni sono necessarie all’utente, cercando di specificare e creare i contenuti mancanti. È inoltre importante valutare la qualità e la completezza del proprio contenuto.
È necessario creare una organizzazione del contenuto basata sulla struttura dell’informazione, sulla struttura del compito da svolgere da parte dell’utente, sul tipo di utente, sullo Scenario (ibidem). Per far ciò bisogna decidere quali pezzi di contenuto vanno insieme in una pagina. La struttura che ne viene fuori dovrebbe funzionare prima ancora che siano stati inseriti indizi orientativi, meccanismi di supporto per l’utente o motori di ricerca.
Quando sono stati individuati i compiti primari del sito è buona regola ottimizzare l’architettura in funzione di questi. Si può fare ciò, ad esempio, creando delle vie secondarie più brevi e ponendo ridondanza sui link più utilizzati. Oppure aggiungendo meccanismi di aiuto per l’utente come ad esempio un tasto Aiuto, una mappa del sito o un motore di ricerca.
Bisogna creare una barra di navigazione e inserire informazioni orientative come l’intestazione o il titolo della pagina. Poiché la presentazione della barra di navigazione può avere un forte effetto sulla mappa concettuale dell’utente e sulla sua abilità a scansionare le opzioni, sarebbe opportuno quando possibile testare la versione di sito creata fino a questo momento su utenti reali. In seguito si possono stabilire le etichette definitive e la grafica.
I due approcci principali per sviluppare una iniziale architettura di un sito web sono quello che va dal basso verso l’alto e quello che va dall’alto verso il basso.
Nella struttura dall’alto verso il basso si parte dalla definizione di categorie principali, individuando per ogni categoria delle sottocategorie. Se consideriamo ad esempio un sito che appartenga al genere della poesia, possiamo individuare come categorie principali le voci Poeti, Poesie, ecc. Possiamo suddividere la categoria Poeti in Paese, Periodo storico o Nomi, mentre possiamo suddividere la categoria Poesie in Sonetti, Versi liberi, Canzoni ecc. così procedendo fino a quando non riteniamo di avere tutti gli argomenti di cui abbiamo bisogno. Partiamo quindi da un livello di categoria alto scendendo giù verso l’unità minima di informazione.
Nella struttura dal basso verso l’alto, invece, avviene il processo inverso. Si parte dal raccogliere tutto il materiale che si ha a disposizione per poi successivamente determinare come questo materiale si può raggruppare. Si parte, dunque, dall’unità minima di informazione salendo su verso categorie alte.
La topologia di un sito definisce le relazioni e i collegamenti tra le singole pagine. Si può denominare “nodo” l’unità base delle strutture dell’informazione. Un nodo può corrispondere a qualunque pezzo di informazione. Denominare i pezzi di informazione nodi e non pagine o documenti, significa applicare un linguaggio e una serie di concetti strutturali comuni a diverse tipologie di problemi.
I nodi possono essere arrangiati secondo strutture gerarchiche, strutture matrix, strutture organiche o strutture lineari (J. J. Garrett 2003).
La più comune struttura di nodi è la struttura gerarchica o ad albero. Nonostante le strutture gerarchiche non sono adatte a tutti i tipi di informazione, possiedono importanti vantaggi: la navigazione attraverso una gerarchia di pagine implica un numero basso di azioni, è relativamente facile indicare in quale punto della gerarchia l’utente si trovi, infine le gerarchie si possono facilmente espandere per includere ulteriori blocchi di informazione.
Figura 2 La struttura gerarchica del sito implica un numero basso di azioni. È facile indicare la posizione dell’utente e sono facilmente espandibili con nuovi blocchi di informazione.
La scelta di una struttura matrix può essere appropriata quando l’informazione varia lungo due dimensioni o segue una mappa bidimensionale. Questa struttura è raramente utilizzata da sola. L’informazione può essere raggiunta come un ibrido tra una gerarchia e un matrix. Ad esempio, in un database di prodotti l’utente dovrebbe essere in grado di vedere una lista di prodotti e potere cliccare su ciascun singolo prodotto (struttura gerarchica), ma dalla pagina del singolo prodotto l’utente potrebbe cliccare per vedere un altro colore di quel dato prodotto o vedere il prodotto successivo.
Figura 3 La scelta di una struttura matrix può essere appropriata quando l’informazione varia lungo due dimensioni o segue una mappa bidimensionale.
A volte l’informazione non si adatta ad una struttura formale, quindi una struttura organica o arbitraria risulta essere la più appropriata. Lo stesso World Wide Web sembra assumere questo tipo di struttura, con siti che si collegano vicendevolmente senza una struttura dominante. Una struttura organica è adatta all’esplorazione di una serie di temi le cui relazioni non sono chiare o in continua evoluzione. Tuttavia questa tipologia di struttura non permette all’utente di possedere un saldo senso dell’orientamento circa la posizione in cui si trova e può essere di poco aiuto quando l’utente ha bisogno di ritornare in un pezzo di contenuto. È adatta a siti di intrattenimento e istruttivi.
Figura 4 Una struttura organica è adatta all’esplorazione di una serie di temi le cui relazioni non sono chiare o in continua evoluzione. Lo stesso World Wide Web sembra assumere questo tipo di struttura.
In una struttura lineare le pagine sono organizzate secondo una sequenza ordinata. Questa tipologia di struttura funziona soprattutto quando l’utente deve completare un processo secondo un ordine specifico, come ad esempio un processo d’acquisto. Molti altri tipi di dati, come una lista di prodotti, potrebbero sembrare naturalmente lineari, ma risultano meglio organizzati secondo una struttura gerarchica. È necessario evitare di forzare gli utenti alla visualizzazione di dati in uno specifico ordine a meno che non sia assolutamente necessario proseguire in quell’ordine per completare un processo.
Figura 5 Struttura lineare. Questa tipologia di struttura funziona soprattutto quando l’utente deve completare un processo secondo un ordine specifico.
Spesso le topologie di un sito non sono assolutamente pure. È anche bene creare dei collegamenti che vanno da un sottolivello di una gerarchia ad un altro e così facendo si può scoprire che un sotto livello di una gerarchia potrebbe costituire di uno dei rami principali della gerarchia che a sua volta comprende due serie di sottolivelli e così via. Le costruzioni ibride spesso hanno più senso degli approcci puri.
A prescindere dal criterio di strutturazione del sito, la percezione delle varie categorie può essere fortemente influenzata dalla terminologia usata per etichettare le categorie. Alcuni utenti eviterebbero volentieri di cliccare su una etichetta del tipo “compra un libro” perché potrebbero trovarsi su quel sito solo per guardare, mentre seguirebbero volentieri un link del tipo “libri” poiché non necessariamente restituisce l’idea di comprare qualcosa. È necessario dunque fissare le etichette delle categorie stabilendo le precise aspettative dell’utente.
L’ordine delle categorie in una barra di navigazione guida l’utente alla comprensione dell’intera organizzazione del sito e può avere una maggiore influenza sulla velocità di navigazione.
L’ordine degli argomenti influenza l’ordine di scansione degli utenti e la capacità di questi di memorizzare gli oggetti. Quando gli argomenti non hanno un particolare ordine, gli utenti scansionano gli oggetti dal primo all’ultimo o dall’ultimo al primo. E’ stato largamente accertato che in una lista di elementi, i primi e gli ultimi elementi componenti la lista sono quelli ad essere ricordati meglio. La spiegazione più comunemente accettata è che gli elementi che si trovano all’inizio dell’elenco non hanno alcuna interferenza derivante da elementi precedenti. Il vantaggio mnemonico degli elementi finali della lista è dovuto alla loro presenza nella memoria a breve termine o memoria lavorativa (On-line memory experiment: Serial Position Curve Dept. Of Psychology, University of Essex – http://www.essex.ac.uk/psychology/experiments/memtask.html.
Quando gli argomenti sono posti in un ordine prevedibile, come ad esempio una lista alfabetica o cronologica, l’utente può scansionare più velocemente gli oggetti che gli interessano. I prodotti, quindi, possono essere elencati alfabeticamente o per ordine di prezzo. Tuttavia, e specialmente al livello superiore del sito (Home Page), solitamente non è possibile alcun ordine logico. In questo caso l’ordine dovrebbe essere reso dalla priorità dei compiti da svolgere.
Mentre la maggior parte del sito è probabilmente organizzata attorno al nocciolo del contenuto, una varietà di pagine dovrebbero essere fornite per facilitare gli utenti nell’utilizzo del contenuto e nel completare i loro compiti. Queste includono pagine dedicate alla navigazione, pagine di aiuto e pagine di errore.
Le pagine dedicate alla navigazione o pagine “router” sono costruite per aiutare gli utenti a navigare verso la loro destinazione. Queste pagine includono la Home Page, le mappe del sito, l’indice dei contenuti e pagine intermedie dove gli utenti scelgono tra opzioni.
Alcune pagine di aiuto possono ritrovarsi nella struttura del sito, come ad esempio le pagine di referenza, le FAQ (Frequently Asked Questions), le pagine di supporto per i clienti e le pagine per i contatti personali. Questo tipo di pagine possono essere incluse nella topologia del sito web indipendentemente dall’architettura principale del sito e si possono indicare semplicemente ponendo un segno o un asterisco sulle pagine dove è necessario un aiuto.
Allo stesso modo, le pagine di errore possono essere incluse in diversi punti del sito. Queste dovrebbero essere considerate come casi speciali nell’architettura del sito. Mentre molti siti lasciano queste come pagine predefinite fornite dal server, la creazione propria esse potrebbe aiutare l’utente a correggere i suoi errori più efficacemente. Gli errori tipici degli utenti nel web includono dati mancanti, l’inserimento di valori non validi e l’inserimento di password non corrette.
Le barre di navigazione sono molto comuni nei siti web. Esse forniscono il meccanismo principale attraverso cui gli utenti sfogliano un sito, quindi l’apparenza di una barra di navigazione stabilisce la mappa concettuale dell’utente necessaria per capire come un sito è organizzato. In altri termini una barra navigazionale è un sommario dell’intera organizzazione del sito. Stabilire quali elementi includere nella barra di navigazione è un m0mento critico nel processo di design.
Troppi link creano confusione, pochissimi link rendono i percorsi più lunghi rallentandone la navigazione. Tipicamente gli utenti hanno bisogno di arrivare da qualunque punto essi si trovano sulla Home Page, su qualunque pagina si trovi prima della pagina corrente e sulla prima pagina della sezione corrente. Secondo il tipo di compito gli utenti hanno anche bisogno di accedere alla pagina successiva o alla pagina precedente secondo una sequenza.
Nella sua forma minima, una mappa del sito o una Home Page può contenere collegamenti a tutte le pagine del sito, e ciascuna pagina necessita di un solo link (il link Home per tornare indietro).
In un sito dalla struttura gerarchica si può risparmiare un po’ di tempo fornendo la lista di link che conducono alle sotto pagine della pagina corrente. Quando si sfogliano i singoli prodotti è utile avere i link “precedente” e “successivo” per muoversi fra i vari prodotti, o anche un link che conduca all’inizio della categoria più recente.
Questo approccio minimale fornisce uno schema di navigazione che necessita di poca manutenzione. Per aggiungere una pagina o rimuovere una pagina si può semplicemente aggiungere o rimuovere il singolo link dalla categoria in cui è contenuto. Da un lato la navigazione è breve e facile da intuire, dall’altro essa non indica chiaramente come è organizzato il sito.
Le briciole mostrano la gerarchia delle pagine lungo un percorso che parte dalla Home Page sino alla pagina corrente. Questa è una concisa rappresentazione della struttura del sito e della posizione corrente dell’utente nella struttura.
Sei qui: Home > Prodotti > Informatica > Schede video
oppure
Home > Prodotti > Informatica > Schede video (Sei qui)
Alcuni utenti possono confondere questa lista con una barra di navigazione tradizionale dove ciascuna delle opzioni si trova sullo stesso livello. Il simbolo > (maggiore di) aiuta a capire che le briciole indicano una relazione di ordine.
Le briciole facilitano e rendono più veloce la navigazione su ogni livello della gerarchia. Nei siti dove sono presenti dei database è possibile elencare il percorso attuale che un utente ha intrapreso per arrivare al punto corrente piuttosto che la gerarchia ideale rappresentata nelle briciole tradizionali. Questo si può attuare ad esempio nelle pagine di un sito alle quali si può accedere seguendo svariati percorsi. Facendo ciò si forniscono all’utente opzioni più rilevanti, ma si perde la possibilità di indicare la struttura del sito.
Fornire la lista delle categorie di livello superiore aiuta l’utente a definire lo scopo del sito e facilita l’accesso alle informazioni primarie del sito.
Home > Chi siamo > Prodotti > Dove siamo > Contattaci
Schede video: Ati > Nvidia
La sottobarra di navigazione è mostrata per la pagina corrente, ma le categorie intermedie sono omesse (Informatica – Schede video). Ciò rende la navigazione concisa, ma la rende anche difficile per quanto riguarda le categorie intermedie. Infatti questo procedimento funziona solo per i siti poco profondi, a uno
o due livelli di navigazione. Nei siti più profondi l’assenza della navigazione intermedia potrebbe creare confusione.
Uno dei più comuni stili di navigazione è quello di mostrare una lista di opzioni contenente una serie di categorie che si espandono quando vengono selezionate.
Home Chi siamo Prodotti
Informatica Schermi Masterizzatori Schede video
-Ati
-Nvidia Arredamento Articoli da regalo
Dove siamo Contattaci
Questo approccio aiuta l’utente a crearsi una buona mappa concettuale dell’organizzazione del sito. È l’alternativa più vicina al mostrare in maniera semplice tutti i link di un sito fornendo all’utente una veloce navigazione delle opzioni presentate. Il problema dei profili che si espandono è che la lista diventa incontrollabile quando il numero delle opzioni si allarga. I profili che si espandono sono adatti per siti a tre livelli di navigazione, mentre a quattro o più livelli di navigazione lo spazio può non essere più sufficiente.
Quando alcune pagine seguono una sequenza lineare naturale è una convenzione comune utilizzare una lista di pagine con pagine Precedenti e Successive:
1 2 3 4 5 6 7 8 9 – Precedente Successiva
Questo tipo di lista è comune nei risultati dei motori di ricerca o negli articoli che si dividono in più pagine.
Nei siti molto grandi bisogna analizzare attentamente il filo conduttore di ogni informazione. Un approccio tipico è il seguente:
Sei qui: Home > Prodotti > Informatica > Schede video [Contattaci] [Mappa del sito] Home > Chi siamo > Prodotti > Dove siamo > Contattaci Schede video: Ati > Nvidia
Il seguente approccio include le briciole, le pagine utili (Contattaci e Mappa del sito), la barra di navigazione principale (categorie di livello superiore) e la sottobarra di navigazione che elenca le sotto pagine della pagina corrente. Ciò evita confusione ma impiega all’utente un po’ di tempo in più per capire il meccanismo poiché la barra di navigazione deve essere interpretata.
Quando il sito diventa troppo grande, una strategia è quella di creare dei sottositi a sé stanti dove si può includere un link che riporta alla Home principale dell’intero sito web oppure la briciola. Il sottosito si presenta come se fosse un sito indipendente, con la sua Home Page e il suo sistema di navigazione, così riducendo l’apparente complessità per l’utente.
Fornendo una ulteriore barra di navigazione testuale a piè di pagina si crea una ridondanza utile nella pagina. Se la barra di navigazione principale è costituita da una serie di link grafici, le immagini grafiche non possono essere accessibili da parte di quegli utenti che sospendono il caricamento delle immagini attraverso le funzionalità del loro browser oppure di quegli utenti che usano gli screen readers. Inoltre se una pagina è lunga, è più conveniente trovare la barra di navigazione in basso alla pagina in modo che lo scroll non sia necessario per navigare.
Tuttavia , se le pagine sono corte o variano nella loro lunghezza, questa barra di navigazione testuale ridondante potrebbe non essere necessaria confondendo gli utenti, i quali potrebbero desumere che se vedono due barre di navigazione nella stessa pagina ci deve essere una significativa differenza tra di loro.. Per ridurre questo problema sarebbe necessario assicurarsi che non ci siano inconsistenze tra le due versioni.
Se le pagine sono sempre corte e la barra di navigazione principale è presentata come testo HTML, allora non c’è alcun bisogno di una barra ridondante.
Quando si parla di creare un sito per il Web, si pensa soprattutto alla progettazione e alla realizzazione dell’aspetto grafico. Si dimentica spesso che anche la tipografia, ovvero la tecnica della disposizione dei caratteri, ha un valore visivo, e non solo verbale: infatti il lettore prima scansiona le forme nella pagina e poi eventualmente decide di leggere il contenuto. In questo senso l’utente stabilisce quasi inconsciamente se approcciare la lettura del testo o meno in base alla convenienza e l’attrazione del testo, ovvero secondo la sua “usabilità.”
Le stesse tecniche e convinzioni della tipografia che sono applicate per la stampa vengono adottate anche per Internet, però il risultato finale, come viene reso il testo, è diverso poiché diverso è il mezzo usato. Per quanto riguarda riviste e giornali, il testo è reso minimamente a 1200 dpi (dots per inch), mentre lo schermo può mostrarlo a 72-o 96-dpi. Per questo motivo alcuni font sono più o meno adatti per essere letti sullo schermo o stampati su carta. Ad esempio alcuni font come Times, Times Roman, Helvetica, Arial sono stati propriamente creati per la stampa, mentre altri, come Verdana, Georgia, Times New Roman, Geneva and New York, sono stati ottimizzati per essere più leggibili sullo schermo.
La caratteristica più notevole per quanto riguarda la tipografia per il Web è la sua variabilità in quanto il testo viene “ricreato” dall’interazione tra il sistema operativo, il monitor, il browser[ i ], e le impostazioni del browser dell’utente. L’utente potenzialmente non vedrà il sito per come lo si è progettato, né per quanto riguarda il layout né per la tipografia, i quali devono essere considerati come dei suggerimenti su come si dovrebbero visualizzare le pagine. Non si può mai sapere con precisione cosa l’utente vedrà sul suo schermo.
Occorre dunque avere qualche base sulla tipografia in generale per potere sfruttare al massimo le potenzialità del testo come oggetto usabile di un sito, forse il più importante di una pagina Web in quanto informativo per eccellenza.
Il tipo di font che si utilizzerà per il testo molto spesso già porta con sé del significato. Il lettore spesso ha già associato già un significato al tipo di carattere che viene utilizzato. Nell’esempio che segue, si crea un certo disagio nella lettura perché la nostra cultura ha già associato un certo significato a questi due tipi di font, cioè perché l’esperienza passata ha associato questo tipo di carattere a un concetto. Il significato semantico della parola è in forte contrasto con il significato connotativo dei caratteri.
In modo simile un carattere può suggerire qualcosa di meno legato alla cultura e più pertinente alla cognizione dell’uomo. Un carattere con forti aste o messo in grassetto stimola sensazioni diverse rispetto a uno dai contorni più sotti
li. Una lettera con le grazie provoca uno stimolo diverso rispetto ad una senza. Vari associazioni vengono fatte secondo le tante differenze: forma, contorno, spessore, simmetria, e così via.
Storicamente vi sono vari tipi di classificazioni dei tipi di caratteri, ma quello che interessa maggiormente a noi è quella per quanto riguarda i caratteri per il Web, ovvero i font. Il W3C[ i ] ha genericamente raggruppato i font in cinque famiglie, cioè un gruppo di font che hanno delle caratteristiche simili, sebbene delle variazioni di stile:
Serif: con le grazie, o i tratti ornamentali ai piedi delle aste del carattere. Spesso hanno sia dei tratti spessi sia sottili. e.g. Times New Roman, Garamond, Georgia.
Sans-Serif: senza le grazie, quindi tratti geometrici più retti o curvilinei, e spesso i tratti sono sempre dello stesso spessore. e.g. Verdana, Arial.
Cursive: questi caratteri ricordano la scrittura in corsivo, quindi più o meno uniti dall’uno e l’altro glifo. Alcuni font sono sempre cursive, come quelli usati per rendere l’arabo. e.g. Adobe Poetica, Sanvito, Zapf-Chancery.
Fantasy: quei caratteri “fantasiosi” e quindi molto ornamentali e decorativi, sebbene rappresentano sempre delle lettere. Spesso sono utilizzati per titoli, e non per testo. e.g. Allegro BT , Geometrique, Cottonwood.
Monospace: ogni carattere ha una dimensione fissa di larghezza (ad es. nonostante la “i” è più stretta della “M” occuperà lo stesso spazio orizzontale). Rassomigliano molto al testo prodotto dalle macchine da scrivere e vengono usati spesso per rappresentare linguaggi informatici, come l’HTML. e.g. Courier, MS Courier New, Prestige.
Un modo facile per attirare l’attenzione dell’utente durante la scansione iniziale di una pagina Web è aggiungendo dell’enfasi tipografica, creando anche un testo interessante da vedere. Se si pone enfasi su molti elementi tuttavia, non molto sarà messo in evidenza. È bene aggiungere un parametro di enfasi alla volta: se si vuole porre enfasi ad un sottotitolo, non bisogna metterlo in una dimensione grande, in maiuscolo o in grassetto. Basta soltanto creare contrasto rispetto al testo.
Il grassetto è un ottimo modo per dare enfasi perché il colore del testo in grassetto contrasta con il testo semplice. Bisogna fare attenzione però a non creare blocchi troppo grandi in grassetto in quanto ciò non crea un buon grigio tipografico. Il grassetto è efficace soprattutto nei titoli e sottotitoli.
Il corsivo attira per il suo contrasto di forma. Convenzionalmente il corsivo viene usato per i nomi di libri o riviste, per parole in lingua straniera, o per mettere enfasi su una parola. Bisogna avere cura a non usare il corsivo con un font di dimensione troppo piccola in quanto spesso, per motivi di risoluzione, non risulta molto leggibile.
Per le pagine Web non conviene mai usare la sottolineatura perché potrebbe essere confusa con i collegamenti ipertestuali. La sottolineatura è stata scelta come espediente per denotare un collegamento perché solo il colore blu del testo/link non era ovvio per i daltonici o per persone con schermi monocromatici.
Il maiuscolo (o maiuscoletto) è un pessimo espediente per creare enfasi. Quando si legge una parola o una frase, l’occhio riconosce la forma della parola, e il lettore fa scorrere gli occhi sulla parte superiore della riga. Quando si mette un blocco di testo tutto in maiuscolo non c’è una forma distintiva, quindi diventa meno leggibile
Lo spazio bianco attorno al testo è importante per dare più contrasto al grigio tipografico. Se questi spazi, chiamati margini, vengono usati con consistenza, possono dare struttura alla pagina ma danno anche un interesse particolare mettendo in risalto lo spazio positivo della pagina (testo, grafica) distinguendolo dallo spazio negativo (sfondo).
Blocchi di testo hanno dei margini particolari a secondo il loro allineamento. Molti editori di testo, come MS Word, danno la possibilità di allineare il testo in modo giustificato. In questo modo, con l’utilizzo della sillabazione delle parole, possiamo ottenere un blocco simmetrico e rettangolare di testo. Sebbene è possibile allineare il testo in modo giustificato per uso sul Web, la visualizzazione è lontana dall’essere esteticamente piacevole, in quanto le parole non possono essere sillabate dal browser e spesso viene inserito troppo spazio tra le parole per dare l’effetto dell’allineamento a destra e a sinistra. Per il futuro imminente l’allineamento giustificato sembra poco pratico e poco usabile in quanto la sillabazione automatica non è una priorità per i produttori di browser.
Testi allineati a destra o al centro sono anch’essi difficili da leggere. Durante la lettura da sinistra a destra, l’occhio ha più difficoltà a trovare l’inizio di ogni riga, in quanto i margini a sinistra sono irregolari. L’allineamento a sinistra è il più prevedibile e l’irregolarità del margine destro dà varietà e interesse alla pagina, senza comunque disturbare la lettura.
Per quanto riguardano i titoli, anche essi dovrebbero essere allineati a sinistra per il testo destinato al web per evitare asimmetria o sconforto durante la lettura.
C’è un motivo fondamentale perché le righe di testo di riviste e giornali sono abbastanza brevi, e questo ha una spiegazione cognitiva. L’area della retina usata per alta acuità visiva è la macula, che costituisce circa il 15 per cento dell’area della retina. Ad una distanza di lettura normale, la larghezza di fuoco acuto dell’occhio è di circa 7-8 cm. Se una riga è superiore a questa larghezza, il lettore deve spostare la testa o sforzare i muscoli oculari per potere scansionare una riga di maggiore lunghezza, ed è possibile oltretutto che perda il segno dell’inizio della riga successiva. Parecchi studi mostrano che una lunghezza di riga minore costituisce maggiore leggibilità del testo.
In questo spirito conviene mantenere le righe del testo a 50-70 caratteri (1012 parole circa) per riga. Il modo più facile per ottenere questo è creare una tabella invisibile (BORDER=”0”) con una larghezza non superiore ai 365 pixel. Lo stesso si può ottenere con i CSS[ i ], stabilendo la larghezza del testo (ad esempio, p {width: 365 px} ). Inoltre con i CSS è possibile anche aumentare l’interlineatura, cioè lo spazio bianco verticale tra una riga e un’altra, che talvolta può aumentare la leggibilità in quanto i discendenti dei caratteri di una riga e gli ascendenti della successiva potrebbero anche confondersi. Se si sceglie di mantenere delle righe di testo più lunghe, è consigliabile aumentare l’interlineatura.
Gli inventori dell’HTML erano scienziati che volevano condividere documenti di fisica, e non importava loro se la presentazione fosse esteticamente gradevole o meno. Molta critica è stata fatta sul fatto che non hanno considerato neanche minimamente le tradizioni di tipografia e redazione. Per questo motivo l’HTML risulta molto rigido, e molti web designer non utilizzano i tag[ i ] standard per le intestazioni (H1, H2, etc.) perché sembrano troppo esagerati in dimensioni. L’unica priorità inizialmente era quella di avere una gerarchia nel documento per capire la struttura dell’informazione.
I fogli di stile CSS riconciliano struttura e presentazione. Così ad esempio puoi ridefinire i tag H1, H2 etc. in modo personalizzato, così che si può mantenere la logica visiva senza sacrificare la struttura del contenuto. Inoltre i CSS permettono più controllo tipografico utilizzando meno codice rispetto all’HTML, e aiutano a mantenere una consistenza visiva nel sito intero.
Convenzionalmente si sceglie un serif (Times New Roman o Georgia) per il testo e un sans-serif (Arial o Verdana) per titoli e intestazioni. Vari studi sono stati fatti a proposito, ma i risultati sono inconcludenti: non necessariamente questa convenzione deve essere una regola e non sempre presenta una leggibilità ottimale. Si può solo suggerire di provare vari tipi di font nel contesto della pagina e del sito web, e con l’aiuto di altre persone, in particolar modo degli utenti a cui è destinato il progetto, verificare la migliore combinazione tipografica.
In ogni caso non è consigliabile utilizzare troppi font nella stessa pagina: basta una sola famiglia di font con vari dimensioni e spessori per distinguere il testo da un testo con enfasi (i.e. grassetto), e non più di un serif e di un sans-serif per pagina.
[La seguente lettura fa parte dei materiali di studio utilizzati durante i corsi D.O.L. - Politecnico di Milano a.s. 2007/2008]
Nota - Integrare la lettura con la navigazione nei seguenti link:
L’information architecture gerarchica ha dei vantaggi (efficiente organizzazione di contenuti – se in numero limitato) e degli svantaggi (rigidità della navigazione e non flessibilità all’aumentare della quantità di materiale da organizzare); al contempo, l’approccio puramente ipertestuale ha da parte sua dei vantaggi (supporto alla navigazione più “libera”, per associazione e percorsi trasversali) e degli svantaggi (rischio di disorientamento e confusione per il lettore).
Il paradigma “ad albero tramato” tenta di ovviare agli svantaggi dei due approcci ma con conseguenze non sempre positive per l’esperienza dell’utente (si è sballottati da un ramo all’altro dell’albero senza criterio, perdendo l’orientamento e il senso della navigazione). Le applicazioni interattive complesse (basate su web, ad esempio) presentano caratteristiche “miste” a tutti questi paradigmi, e principalmente adottano:
Vediamo un esempio di questa combinazione di paradigmi strutturali nello schema.
I primi livelli di navigazione (ad albero) consentono all’utente di accedere (trovare, cercare) i contenuti di interesse. La navigazione più libera, basata su paradigma ipertestuale scatta invece quando l’utente ha raggiunto i contenuti e ne permette l’esplorazione e la navigazione. Come si fa a progettare una struttura di information architecture che combini in modo coerente e ottimale questi due paradigmi?
In questo modulo introduciamo una tecnica di progettazione (IDM) che permette in modo semplice, intuitivo ed efficiente di progettare information architecture complesse ed articolate (che adottano il paradigma illustrato), e che sono alla base delle applicazioni interattive moderne.
IDM (Interactive Dialogue Model) è un metodo di progettazione orientato al dialogo, che nasce dal connubio di ricerca del campo del design di applicazioni web e delle scienze linguistico-comunicative. L’attività di progettazione con IDM segue tre linee di indagine:
A queste domande è possibile rispondere in modo dettagliato e preciso quando consideriamo uno specifico canale di comunicazione per il dialogo (definendo caratteristiche come la dimensione dello schermo, la banda a disposizione, o i meccanismi di puntamento). Tuttavia, decisioni importanti possono essere prese prima di determinare questi fattori, in ciò che chiamiamo “IDM Concettuale” (C-IDM). Il livello di progettazione legato allo specifico canale (sia esso il web, il palmare, o telefonini di terza generazione) è considerato da “IDM logico” (L-IDM), dove i dettagli della meccanica dell’interazione sono definita sulla base dei vincoli e potenzialità dello specifico canale. Uno schema concettuale IDM dovrebbe comunicare le strategie dialogiche dell’applicazione, senza (e prima di) specificare in modo dettagliato le caratteristiche legate alle scelte tecnologiche. In particolare, lo schema concettuale permette di:
La progettazione concettuale con IDM è caratterizzata dalla definizione di tre semplici elementi: temi del dialogo (topic), relazioni rilevanti tra temi (relevant relation) e gruppi di argomenti (group of topics). Un’applicazione interattiva, infatti, può parlare di un argomento (tema del dialogo), può consentire di cambiare tema a partire da quello di cui si sta parlando (correlando temi tra loro), oppure può permettere di esplorare un insieme di temi (gruppi di argomenti). Queste idee molto semplici e intuitive si traducono in una serie di concetti utili al progettista di information architecture:
Topic: ciò che può essere il soggetto della conversazione tra l’utente e l’applicazione. Nel sito MUB (già analizzato nel modulo propedeutico), alcuni esempi di topic sono la stampa “Il malato e il bambino”, oppure la tecnica “Drypoint”.
Multiple Topic (o Kind of Topic): una categoria di possibili soggetti di conversazione. PRINT, oppure TECHNIQUE sono multiple topic, poiché possiamo avere diverse stampe, diverse tecniche ecc. THE SICK CHILD è un esempio di PRINT.
Relevant Semantic Relation: un cambio di argomento che permette di passare da un topic all’altro. MADE WITH è una relazione tra PRINT e TECHNIQUE che permette di passare da una stampa alla tecnica con la quale è stata realizzata quella stampa.
Group of Topics: un gruppo di possibili argomenti di conversazione. “I capolavori” è un gruppo particolare di stampe, che raccoglie alcune tra le stampe più rappresentative di Munch.
Multiple Group of Topics: una famiglia di group of topics. Le stampe, ad esempio, possono essere raccolte per tema (la gioia, la natura, la nostalgia ecc.). Tutte le stampe dello stesso tema costituiscono un group of topics. “Le stampe del tema X” è un gruppo di argomenti multipli, dal momento che ci saranno tanti di questi gruppi quanti saranno i temi.
Queste astrazioni sono alla base della progettazione concettuale con IDM e il loro uso ha numerosi vantaggi rispetto ai metodi di progettazione esistenti:
Di seguito riportiamo la versione testuale sintetica del progetto IDM concettuale del sito MUB.
TOPICS:Si noti come in pochi passaggi è stata tratteggiata l’essenza dell’applicazione dal punto di vista dialogico. L’equivalente grafico di tale descrizione testuale è mostrato in Figura 3.1. Lo schema rappresenta in modo sinottico le principali strategie per il dialogo con l’utente. Si può iniziare a parlare di un topic, quindi di Munch, del Museo, della mostra, oppure si può iniziare a parlare di tutto ciò che è “group of topics”, quindi dei capolavori, dei temi delle stampe, di tutte le stampe, e di tutte le tecniche. Scelto un group of topics, è possibile esplorare i diversi multiple topics, quindi le diverse stampe, oppure le tecniche, i movimenti artistici, e così via. Le relazioni tra i topic consentono di cambiare argomento, quindi di passare dalla stampa alla tecnica, dalla tecnica alle stampe, dall’artista al movimento artistico, e così via.
In estrema sintesi, possiamo così descrivere i principali vantaggi dell’uso delle primitive e della notazione C-IDM (Figura 3.2):
Nei prossimi paragrafi approfondiremo una ad una le primitive progettuale di C-IDM, offrendo al progettista linee guida per sfruttare al meglio le potenzialità della progettazione concettuale.
Un topic è un possibile argomento del dialogo tra l’utente e l’applicazione. Per argomento del dialogo intendiamo ciò di cui il dialogo parla ovvero il contenuto d’interesse per l’utente. Per quale motivo un utente potrebbe essere interessato a visitare l’applicazione, oppure a ritornarci? Per le applicazione interattive, dove i contenuti sono il patrimonio più importante da condividere con l’utente, la risposta a questa domanda ha come oggetto principale uno o più contenuti di interesse per l’utente, quindi, in termini IDM, uno o più topic.
L’architettura informativo-navigazionale di un’applicazione che supporta un dialogo informativo-argomentativo è funzionale alla comunicazione di uno o più topic; tutte le scelte progettuali “ruotano” attorno ai topic, che costituiscono i contenuti veri e propri dell’applicazione. Oltre ai vari topic che abbiamo visto per MUB possiamo considerare esempi da vari settori in cui l’elenco dei topic descrive in modo sintetico i contenuti principali dell’applicazione.
Consideriamo, ad esempio, il sito di una libreria online. Esempi di topic sono le schede informative di tutti i libri in vendita, tutti i commenti degli utenti che hanno pubblicato sul sito la propria impressione sui libri acquistati e letti, la presentazione della libreria, le schede con i profili dei vari clienti del sito, e così via. Notiamo che abbiamo topic di diverso tipo e non tutti hanno la stessa importanza per tutti i tipi di utenti. Vi sono i topic che costituiscono la ragione stessa dell’esistenza dell’applicazione, o il motore informativo che sta alla base del modello di business della libreria online: le schede dei libri.
Senza informazioni dettagliate sui libri non si tratterebbe di una vera a propria libreria online, e sarebbe difficile pensare di vendere un libro ad una persona senza dare la possibilità di capire di che libro di tratta.
Vi sono poi altri topic non così strategici dal punto di vista del dialogo con l’utente, ma che comunque possono avere un impatto sulla qualità dell’applicazione. Si tratta, ad esempio, dell’informazione sull’azienda, che (apparentemente secondaria) potrebbe essere un contenuto importante per aiutare l’utente a raccogliere gli elementi per capire se ci si può fidare o no nell’eseguire transazioni commerciali. Come scegliere i topic?
La scelta dei topic è strettamente correlata a requisiti di contenuto, cioè a quell’insieme di messaggi che gli stakeholder intendono comunicare ai propri utenti attraverso l’applicazione. Un topic, per essere tale, deve costituire un nucleo coeso e autonomo di contenuti interessanti per l’utente. Un topic, cioè, deve avere un senso per l’utente, indipendentemente dal resto dell’applicazione.
Per definire i topic dell’applicazione è utile porsi la domanda: “Di cosa voglio parlare all’utente?”. Per applicazioni di media-elevata complessità, la risposta a questa domanda, tenendo conto dei requisiti (se sono stati definiti), dovrebbe essere una serie di possibili topic. Tutti i contenuti dell’applicazione sono riducibili a dei topic? La risposta è no.
Un topic è un argomento del dialogo e quindi ha una sua ricchezza informativa. Vi sono altri contenuti che non sono topic (ad esempio dei frammenti di informazione). Consideriamo la seguente lista di contenuti:
Alcuni di questi contenuti del sito sono topic (gli elementi in grassetto). Si considerino ad esempio le diverse stampe: SELF-PORTRAIT WITH A BOTTLE OF WINE, SEPARATION II (BREAKING AWAY / PARTING),STREETWORKERS (WORKERS DIGGING), THE DAY AFTER, MOONLIGHT. NIGHT IN ST. CLOUD, e così via.
È chiaro che si tratta di veri e propri topic, nel senso che l’applicazione parla esplicitamente di queste opere d’arte di Munch, avendo qualcosa di specifico da raccontare su ogni stampa. Ogni stampa, quindi, è un possibile soggetto di conversazione del dialogo e costituisce un oggetto di interesse indipendentemente dagli altri contenuti. Altre informazioni (gli elementi non in grassetto) sono considerate contenuti presenti ed importanti per l’applicazione, ma non sono topic, poiché non possono costituire un argomento di conversazione di per sé.
Si consideri ad esempio DATE OF BIRTH (data di nascita), elemento con il quale intendiamo la data di nascita di uno degli autori che ha influenzato Munch. Si tratta di un frammento informativo il cui senso si comprende all’interno di un contesto dialogico più ampio, cioè all’interno del discorso di un artista importante per il periodo in cui Munch è vissuto. Ma di per sé, la data di nascita non è definibile come un topic del dialogo, ma piuttosto come un frammento di contenuto, proprio perché non è possibile che costituisca una riposta accettabile alla domanda: “Di che cosa parla l’applicazione?”. Altri contenuti di questo tipo sono PRINT NAME (il nome di una stampa non può costituire oggetto di conversazione), SIZE
(la dimensione di una stampa), BIG PICTURE (immagine a tutto schermo della stampa), COMMENT (commento sul tema della stampa), e così via. Sarebbe un errore progettuale considerare queste informazioni come topic, poiché non possono essere messi a tema i per sé, ma sono micro-unità informative di cui si può parlare all’interno di un dato topic (ad esempio, quando si sta parlando di una stampa). Questo argomento verrà ripreso nella progettazione logica (più di dettaglio). Per ora ci basti comprendere che un topic non è da confondersi con un dato, o frammento informativo.
Vi sono topic di cui vi è un solo esemplare nell’applicazione. Per esempio, nel caso di MUB, si tratta del topic THE EXHIBITION, CONTACT US, MUNCH. Di mostra, infatti, ve ne è solo una (quella appunto che è messa a tema dall’applicazione). Di Edvard Munch ve ne è solo uno, l’artista, appunto, le cui opere sono raccontate dall’applicazione.
Vi sono invece topic che rappresentano un argomento generico, e l’applicazione presenta diversi esemplari di questo tipodi argomento. È il caso, ad esempio, di PRINT; nell’applicazione possiamo parlare di diverse decine di stampe. Ciascuna stampa specifica (ad esempio SELF-PORTRAIT WITH A BOTTLE OF WINE, STREETWORKERS, THE DAY AFTER, MOONLIGHT. NIGHT IN ST. CLOUD) è un topic, ed esse sono esemplari di un argomento generico del dialogo che è PRINT.
La categoria di topic PRINT quindi è un multiple topic, poiché nel dialogo possiamo parlare di diversi argomenti appartenenti a questo tipo. In altre parole, un multiple topic è un argomento di conversazione di cui possono emergere diversi esemplari durante il dialogo. Nel sito MUB non si parla di PRINT in generale: si parla invece delle singole stampe in esposizione.
Quindi il multiple topic si concretizza nel dialogo attraverso i suoi vari esemplari. Si tratta di un’astrazione utile al progettista per identificare un generico argomento di conversazione che potrà essere incarnato da una serie di argomenti specifici a seconda dei contenuti che si deciderà di pubblicare. Durante la progettazione concettuale, alla domanda “Di che cosa parlerà l’applicazione?” potremo rispondere dicendo: “L’applicazione parlerà delle stampe di Munch, delle tecniche usate, dell’esposizione, dei movimenti artistici, e così via”.
Gli argomenti del dialogo cioè sono dichiarati in forma di categorie di possibili argomenti, e non specificando fin da subito esattamente di quante e quali stampe si parlerà, di quante e quali tecniche si parlerà, e così via. La scelta delle singole stampe di cui l’applicazione dovrà parlare, infatti, non spetta al progettista, ma piuttosto al curatore della mostra. Il compito del progettista è quello di decidere quali categorie di contenuti prevedere per l’applicazione. Tali categorie di contenuti sono appunto i multiple topic. Il curatore della mostra dovrà scegliere quali stampe pubblicare, e fornire i contenuti corrispondenti.
Analogamente, il multiple topic TECHNIQUE prevederà una serie di esemplari di tecniche (ad esempio ETCHING, DRYPOINT, LITHOGRAPHY, WOODCARVING). Le singole tecniche sono dei topic; il progettista tuttavia non ha pensato ad ogni singola tecnica, ma ha previsto la classe di argomenti TECHNIQUE, assumendo che tutte le varie tecniche di cui si potrà parlare siano esemplari di questa classe.
Per ciascun multiple topic è opportuno definire la cardinalità, cioè quanti saranno (più o meno) gli esemplari di questo tipo di argomento del dialogo. Di quante stampe si potrà parlare? Di due, cinque, cento? Di quante tecniche si potrà parlare? Di quanti movimenti artistici? La cardinalità è un indice importante della quantità dei contenuti e permette ai responsabili del progetto, al progettista e agli sviluppatori di dimensionare le risorse per il progetto. Infatti, il costo dei contenuti è il costo maggiore di ogni applicazione interattiva che intende stabilire un dialogo informativo o argomentativo con l’utente.
Se la cardinalità del multiple topic PRINT è 50, e il tempo stimato dall’autore dei contenuti per confezionare il contenuto richiesto per ogni stampa (testi, immagini) è di 4 ore, possiamo facilmente calcolare il costo della produzione dei contenuti per le 50 stampe presenti nell’applicazione:
50 (cardinalità PRINT) x 4 (ore per produrre contenuti di 1 stampa) = 200 ore
Sono necessarie dunque 200 ore di lavoro (cioè 25 giorni/uomo) per produrre i contenuti definitivi delle stampe. Calcolando 200 euro come costo medio giornaliero per la produzione dei contenuti, il costo totale ammonta a circa 4.000 euro.
Chiaramente questo sarebbe il costo per la sola produzione dei contenuti per tutte le stampe. Un calcolo analogo sarebbe da stimare per tutti i movimenti artistici, le tecniche e gli autori che si intendono pubblicare sull’applicazione. Si può facilmente comprendere, dunque, quanto la cardinalità sia un elemento importante da definire per ogni multiple topic, per la gestione complessiva del progetto. Dal momento che è quasi impossibile definire a priori la cardinalità esatta di ogni multiple topic, la cardinalità può essere definita da tre indicatori diversi:
La cardinalità è un indicatore utile sia ai progettisti del dialogo, per poter meglio organizzare l’esperienza di visita delle stampe, che per gli sviluppatori, al fine di configurare e dimensionare al meglio la base di dati necessaria per l’applicazione.
Quanti multiple topic progettare? La capacità del progettista sta nel definire una serie di multiple topic rilevanti a partire dal materiale disponibile e delle indicazioni emerse durante l’analisi dei requisiti. Un numero elevato di multiple topic (20-30) può richiedere un notevole sforzo progettuale e un alto costo per la produzione e alla gestione dei contenuti (come appena visto). D’altro canto un numero esiguo o nullo di multiple topic (1, 2) potrebbe non risultare adeguato ai requisiti emersi e ridursi a un’applicazione banale o molto povera.
A parità di requisiti e di contenuti disponibili, la stessa scelta tra definire un topic o un multiple topic è una scelta tattica e non assoluta. Ad esempio, il materiale disponibile sulla vita di Munch poteva essere considerato un argomento di estremo interesse per il dialogo.
Definire un topic MUNCH’S LIFE avrebbe dunque avuto senso. Tuttavia, esplorando meglio il contenuto disponile su questo argomento, ci si è accorti che la vita di Munch poteva essere raccontata per periodi significativi e ciascuna opera di quelle esposte alla mostra era riconducibile ad uno di questi periodi della sua vita. Inoltre, in ciascun periodo, diversi movimenti artistici avevano influenzato la sua arte, portandolo a compiere scelte artistiche e tematiche specifiche. Infine, la visione fortemente “storicizzata” del fenomeno artistico perseguita dai committenti dell’applicazione ha contribuito a considerare il “periodo della vita” di Munch un elemento catalizzatore di interessi.
Ciascun periodo della vita di Munch inizia così a prendere forma come nucleo informativo autonomo di interesse per l’utente all’interno dell’intera economia dei contenuti del dialogo. Ogni periodo della vita è inoltre “descrivibile” allo stesso modo, attraverso una contestualizzazione biografica e storica, gli incontri significativi di Munch e una galleria di immagini.
Per queste ragioni si è deciso di definire un multiple topic PERIOD OF LIFE, con cardinalità 6:
Abbiamo visto che l’insieme dei multiple topic e dei topic costituisce il nucleo di contenuti portanti dell’applicazione e che tali contenuti definiscono gli argomenti principali di cui si può parlare nel dialogo. Il dialogo, tuttavia, sarebbe sterile se finisse nel momento in cui un contenuto di interesse è stato esaurito. A partire da un argomento della conversazione di interesse per l’utente, il dialogo può proseguire e ampliarsi passando ad altri argomenti correlati, permettendo così all’utente di esplorare nuove tematiche. Si tratta quindi di gestire un cambio di argomento “guidato” durante il dialogo, in cui si dà la possibilità all’utente di spostare il contesto della conversazione (in termini informativi) e di iniziare a parlare di qualcosa d’altro strettamente connesso al tema della conversazione.
Supponiamo che stiamo parlando all’utente della stampa THE DAY AFTER. Dopo aver raccontato del tema dell’opera e della circostanza che ha ispirato Munch, l’applicazione offre all’utente la possibilità di parlare della tecnica con cui è stata eseguita la stampa. Se l’utente acconsente a questo cambio di argomento, la conversazione abbandona il tema della stampa THE DAY AFTER e prosegue il dialogo concentrandosi sulla tecnica dell’ETCHING, raccontando in cosa consiste questa tecnica e dell’uso particolare che ne faceva Munch: è avvenuto un cambio di argomento.
Sfruttando una relazione profonda tra una stampa e un altro argomento del dialogo correlato (la tecnica in questo caso), l’argomento del dialogo è cambiato, mettendo così a tema un nuovo contenuto d’interesse. Una relevant relation è la possibilità di passare da un topic a un altro grazie all’attivazione di un significato che soggiace alla relazione tra i due elementi. Nel caso delle relazione PRINT-TECHNIQUE, il significato è MADE WITH, che si legge: a partire da una “stampa” si può parlare della “tecnica” con cui è stata fatta quella stampa.
Notiamo quindi che abbiamo generalizzato la relazione illustrata nell’esempio del cambio di argomento dalla stampa THE DAY AFTER alla tecnica ETCHING. Infatti, mentre nell’esempio la relazione è a livello di topic (un esemplare di stampa è collegato ad un esemplare di tecnica), nella progettazione concettuale possiamo definire relevant relation tra multiple topic, indicando così che la relazione vale per ogni esemplare dei multiple topic coinvolti in tale relazione.
Definendo una relevant relation tra PRINT e TECHNIQUE, si stabilisce la regola che da ogni stampa di cui si può parlare nel dialogo si può passare a parlare della tecnica corrispondente.È importante a questo punto capire che nella definizione di una relevant relation bisogna sempre tenere in considerazione il punto di partenza del cambio di argomento. In altri termini, da una stampa posso iniziare a parlare della tecnica (relevant relation PRINT-TECHNIQUE), ma mentre sto parlando di una tecnica posso iniziare a parlare di tutte le stampe fatte con quella tecnica (relevant relation TECHIQUE-PRINT). Si tratta, infatti, di due relazioni diverse.
Il significato della relevant relation tra TECHNIQUE e PRINT è USED FOR: ogni tecnica è connessa alle stampe fatte con quella tecnica. Ma “quante” stampe sono state fatte con una certa tecnica? Come per i multiple topic, anche per le relevant relation è necessario stabilire una cardinalità. La cardinalità in questo caso definisce il numero di esemplari dei multiple topic a cui conduce una relevant relation. Nel caso della relazione tra TECHNIQUE e PRINT, la cardinalità è:
1,n
intendendo cioè che a partire da una TECNICA è possibile parlare di una o più stampe (create con quella tecnica). Nel caso della relazione tra STAMPA e TECNICA, la cardinalità è:
1.1
intendendo cioè che a partire da una STAMPA è possibile parlare di una o una sola tecnica (quella con cui è stata eseguita la stampa, appunto). Il primo valore di cardinalità indica il numero minimo di topic che possono essere il nuovo argomento del dialogo. Il secondo valore ne indica il numero massimo. Un multiple topic può essere oggetto di più relevant relation. Si consideri lo schema complessivo di Figura 3.1. Il multiple topic ARTISTIC MOVEMENT è collegato al multiple topic ARTIST secondo la relevant relation REPRESENTED BY. Il multiple topic PERIOD OF LIFE è pure connesso a ARTISTIC MOVEMENT secondo la relazione INFLUENCED BY. Infine, da ARTIST è possibile passare a ARTISTIC MOVEMENT seguendo la relazione BELONGING TO.
Questi cambi di argomento rendono il dialogo più vivace e ricco, permettendo all’utente di arricchire la propria conoscenza sugli argomenti trattati. Come si scelgono le relevant relation? Si parla di “relevant” relation poiché il cambio di argomento si fonda una relazione tra topic che il progettista decide di far emergere perché interessante per l’utente (cioè che arricchisce la sua esperienza dialogica) sulla base dei requisiti raccolti e dell’economia complessiva del dialogo. Non si tratta, quindi, di stabilire relazioni “necessarie” tra i contenuti, ma di decidere quali relazioni sfruttare ai fini della qualità del dialogo.
Tra due oggetti, infatti, nel mondo reale possono esserci moltissime relazioni: pensiamo ai multiple topic STAMPA E AUTORE. Possiamo immaginare relazioni come: una stampa è piaciuta ad un autore, una stampa è stata fatta da un autore, una stampa ha ispirato un autore, una stampa è stata copiata da un autore, una stampa è stata criticata da un autore ecc. Il progettista definisce una o più relazioni tra i multiple topic se e solo se tali relazioni sono rilevanti per il progetto (cioè per gli obiettivi dell’applicazione, per i contenuti a disposizione, per gli utenti ecc.).
Dal momento che una relevant relation permette di stabilire da quali esemplari di un multiple topic a quali altri esemplari di un altro multiple topic (o eventualmente lo stesso) è consentito cambiare argomento, non è possibile stabilire relazioni tra single topic e multiple topic. Ad esempio, non avrebbe senso definire una relevant relation tra CONTACT US e PRINT poiché esiste un solo topic CONTACT US e quindi la relevant relation non serve a scegliere un cambio di argomento. Come vedremo nelle prossime sezioni, i topic singoli sono tutti candidati per essere punti di partenza del dialogo
(sempre accessibili). Analogamente, non avrebbe senso stabilire relevant relation tra topic singoli, ad esempio tra THEMUSEUM e THE EXHIBITION. È sempre possibile cambiare argomento tra topic singoli e dunque le relevant relation non servono in questo caso.
Da dove inizia il dialogo? Quali sono i possibili punti di partenza? Il dialogo umano può cominciare, ad esempio, a partire da una domanda da parte di uno dei due interlocutori, sollecitando l’altro a rispondervi e a prendere la parola, oppure perché uno dei due inizia un discorso e introduce un argomento da trattare. Nel tipo di dialogo stabilito con un’applicazione interattiva, l’utente non ha la libertà assoluta di mettere a tema gli argomenti di cui parlare.
Nel momento in cui l’utente decide di voler iniziare un dialogo con un’applicazione (si collega ad un sito Internet, per esempio), egli inconsciamente delega agli stakeholder di quell’applicazione la responsabilità di mettere a tema gli argomenti del dialogo e di incominciare a trattarli. Sono gli stakeholder quindi che, attraverso l’applicazione, decidono ciò di cui si può parlare con gli utenti. L’iniziativa dell’utente sta nell’aver scelto di cominciare un dialogo, ma gli argomenti possibili sono stabiliti dall’applicazione.
Durante il dialogo, l’utente potrà scegliere ciò di cui parlare all’interno dell’insieme di argomenti previsti dagli stakeholder. Come gli argomenti possono essere messi a tema dall’applicazione e “offerti” all’utente? In ogni artefatto comunicativo costituito da un materiale informativo ricco, strutturato e complesso, il progettista tipicamente prevede dei meccanismi di accesso ai contenuti che devono permettere all’utente di:
Pensiamo ad un film in DVD. Le (poche) possibilità interattive che offre un film in DVD rispetto ad un film in videocassetta (o ad un film visto in TV o al cinema) sono costituite essenzialmente (oltre che dalla presenza di contenuti extra, come inserti speciali, backstage ecc.) da elementi di accesso ai contenuti: l’indice delle scene, ad esempio, è una (banale) modalità di selezione dei contenuti. Lo stesso menù principale costituisce un punto di partenza del dialogo, un momento dell’interazione
in cui si l’utente può decidere ciò di cui parlare (tra le limitate possibilità offerte). Pensiamo ad un libro. Se gli argomenti del libro sono i contenuti dei vari capitoli, l’indice è un tipico momento di scelta dei contenuti. L’indice può essere usato per diversi scopi:
L’indice quindi non è un contenuto (topic) ma una rappresentazione più o meno sintetica di un gruppo di contenuti (tutti i contenuti del libro in questo caso). Dal punto di vista di un progetto in IDM, i punti di partenza del dialogo possono essere o dei topic direttamente accessibili, come ad esempio i topic MUNCH (si inizia a parlare della vita di Munch), THE EXHIBITION, o THE MUSEUM, oppure dei momenti espliciti di scelta degli argomenti che in IDM vengono detti group of topics.
I group of topics sono dei raggruppamenti di argomenti del dialogo (topics) che costituiscono importanti punti di inizio del dialogo. Abbiamo visto infatti che i multiple topic possono essere parecchi (si rammenti il concetti di cardinalità): se possiamo parlare all’utente di 40 stampe di Munch, da quale stampa possiamo o vogliamo iniziare? Tra le decisioni progettuali più importanti vi è, infatti, la scelta di come organizzare l’accesso alle stampe, cioè di come raggruppare le stampe per renderle raggiungibili, per permettere all’utente di metterle a tema nel dialogo. Facendo riferimento allo schema di Figura 3.1, si considerino i seguenti group of topics per le stampe:
ALL PRINTS è un tipico group of topics che svolge una funzione analoga a quella che abbiamo visto per l’indice di un libro: si tratta del raggruppamento di tutte le stampe in esposizione. Il progettista ha deciso di offrire all’utente la possibilità di scegliere direttamente di parlare di una qualunque delle stampe presenti nell’applicazione. Tale group of topics è frutto di una decisione progettuale che, tuttavia, corrisponde ad una scelta quasi “obbligata” per un’applicazione ricca di contenuti come MUB. Infatti, dal momento che le stampe costituiscono il contenuto più importante dell’applicazione, non può mancare un momento del dialogo in cui si presentano all’utente tutte le stampe in esposizione. Si tratta di una scelta importante in cui si dà visibilità alla ricchezza (in termini di quantità del materiale) della mostra. Questo group of topics tuttavia non serve molto agli utenti che non conoscono Munch e le sue stampe e vorrebbero essere aiutati a scegliere da dove iniziare.
Il group of topics MASTERPIECES (capolavori) raccoglie le stampe che il curatore considera le più rappresentative della mostra. Si tratta quindi di un sottoinsieme di ALL PRINTS, che propone all’utente solo una decina di opere rappresentative (a detta del curatore). Vengono messe in evidenza alcune stampe per aiutare l’utente a orientarsi nella complessità del materiale, suggerendogli quali sono le cose da non perdere e quindi offrendogli dei punti di partenza “sicuri”. Con il group of topics MASTERPIECES il curatore della mostra è come se dicesse all’utente: “Guarda, se è la prima volta che visiti la mostra, io ti posso guidare: innanzitutto ti suggerisco di iniziare a guardare queste stampe di Munch, che sono tra le più rappresentative dell’intera mostra”.
Ovviamente la scelta di alcuni capolavori e non di altri è operata dal curatore della mostra: si tratta di una scelta soggettiva, che potrebbe risultare in un groupof topics con stampe differenti se ci fosse un altro curatore. Tuttavia, proprio questa soggettività rende interessante questo group of topics per l’utente che, se lo desidera, può affidarsi all’interpretazione del curatore che lo può guidare attraverso una materia complessa e non sempre intuitiva qual è quella delle opere a stampa di un artista come Edvard Munch. La rilevanza di un group of topics come MASTERPIECES è tanto maggiore quante più sono le stampe presenti nel group of topics ALL PRINTS. Se le stampe raccolte in ALL PRINTS fossero tre o quattro, capiamo bene che basterebbe ALL PRINTS a dare all’utente un’idea di ciò che si potrebbe visitare (un numero molto limitato di stampe) e il group of topics MASTERPIECES non avrebbe senso.
Ci rendiamo conto, quindi, che la definizione dei group of topics è d’importanza fondamentale per poter fare uso dell’applicazione, cioè per poter dialogare in modo efficace con l’applicazione. In applicazioni di media o elevata complessità (con diversi multiple topics ciascuno con cardinalità dell’ordine delle decine) i groups of topics costituiscono l’unica strategia per poter fruire dei contenuti, cioè per mettere a tema i contenuti che rappresentano la ricchezza dell’applicazione.
Senza groups of topics l’utente non avrebbe alcuna possibilità di accedere ai contenuti in modo significativo ed organico. I contenuti sarebbero totalmente inaccessibili oppure messi a tema in modo causale, disordinato e senza alcuna logica. Come vedremo, i groups of topics possono assumere scopi e stili diversi di dialogo con l’utente. In generale essi svolgono un compito cruciale che è possibile riassumere come segue:
La natura dei group of topics può essere molto varia. Una prima distinzione che possiamo fare è tra group of topics più “oggettivi” e altri più “soggettivi”. In un museo che colleziona diverse tipologie di opere artistiche, un tipico raggruppamento di topics si basa su un classico criterio di catalogazione per “genere”: sculture, quadri, stampe, disegni ecc. Il criterio di raggruppamento è in questo caso piuttosto oggettivo, cioè dettato, desunto dalla natura stessa dei contenuti, o da una percezione immediata delle differenze tra contenuti.
Dentro il group of topics “pitture” potremmo organizzare l’accesso ai dipinti per autore: dipinti di Leonardo, dipinti di Caravaggio, dipinti di Raffaello ecc. Oppure potremmo organizzare un accesso per periodo storico: dipinti del 400, dipinti del 500, e così via. Anche i criteri di questi raggruppamenti sono criteri incontestabili, cioè nel momento in cui il progettista scegli di adottarli, il risultato che ottiene è necessariamente uno e uno soltanto. Non c’è modo di mettere in discussione che un quadro appartiene ad un periodo storico, o che è stato fatto da un certo autore (tranne in casi eccezionali), oppure che è un quadro e non una statua.
Un altro tipico esempio di group of topics “oggettivo” è ALL PRINTS oppure ALL TECHNIQUES. Si tratta di raggruppamenti che si basa sul criterio “tutti i…”. L’obiettivo del progettista in questi casi è quello di supportare scenari d’uso in cui il visitatore desidera reperire un elemento specifico del gruppo (conoscendo uno dei suoi tratti identificativi, come il nome, o l’immagine) oppure in cui il visitatore vuole farsi un’idea delle quantità di materiale da visitare. Anche in questo caso, il criterio “tutti i…” – group of topics essenziale per supportare questi scenari di uso – non presenta al progettista particolari scelte da compiere nel merito dei contenuti.
Dato l’insieme delle stampe dell’esposizione, il group of topics ALL PRINTS darà luogo di necessità a una lista di tutte le stampe esposte. Diverso è il caso in cui la definizione di un group of topics dipenda da un’interpretazione (soggettiva) dei contenuti che si intende mettere a tema. MASTERPIECES vuole presentare all’utente una selezione delle stampe “migliori” di Edvard Munch. Quali sono le opere migliori? Chi decide il criterio di selezione? Chiaramente in questi casi il progettista dovrà coordinarsi con un esperto di contenuti (ad esempio, il curatore della mostra), che si occuperà di decidere quali sono le stampe che sono da considerarsi “capolavori” e che quindi saranno selezionate per il group of topics MASTERPIECES.
In modo analogo, il group of topics THEMATIC TOUR è basato su un criterio interpretativo delle stampe: le stampe sono state associate a temi ricorrenti nella vita artistica di Munch: la morte, gli autoritratti, la giovinezza, la malattia, i paesaggi ecc. Il curatore della mostra, sulla base delle proprie conoscenze, definirà i temi e li assocerà alle stampe (si noti che una stampa può riguardare più temi) dando così origine ad un group of topics potenzialmente interessante per un visitatore che intende esplorare le stampe seguendo una chiave di lettura con cui leggere e interpretare le stampe.
Dal punto di vista dialogico, i group of topics “soggettivi” conferiscono al dialogo con l’utente un aspetto molto più comunicativo e coinvolgente (tipico del dialogo umano, in cui una persona di fronte a noi formula e modula in modo soggettivo gli argomenti di cui parlare a seconda dei nostri interessi e delle nostre reazioni) rispetto ad una “fredda” esposizione oggettiva, per la quale sarebbe sufficiente un lungo elenco alfabetico di tutti gli argomenti a disposizione.
Categoria: Accessibilità:
Sezione: Disabilità visive
Consegna esercitazione (via email a Mario Varini): entro il 31 agosto 2009
Ore di autoformazione: 4
Argomento: Interpretare l’interazione tra un essere umano e un’applicazione in termini di dialogo.
Il flusso informativo tra una macchina e una persona manifesta infatti chiaramente una natura dialogica, ma per lo più estremamente pesante e complessa.
La ragione è la natura visiva del Web, i cui contenuti sono spesso immagini e grafica. Inoltre, la concezione delle pagine web (il layout, la scelta delle icone, la disposizione dei contenuti e dei link, ecc.) e l’uso dei meccanismi di puntamento (quali il mouse) si basano essenzialmente sull’uso della vista.
Questo fatto rischia di escludere dalla fruizione delle infinite possibilità del Web una fascia socialmente rilevante della popolazione, quella dei disabili alla vista, che non riescono ad utilizzare le interfacce grafiche delle moderne applicazioni (mentre riuscivano ad usare benissimo le interfacce a carattere della precedente generazione di applicazioni).
Inoltre, il pesante utilizzo del supporto visivo impedisce di trasportare le attuali tecniche di design a nuovi mezzi quali palmari, UMTS, PDA.
Proposta di ricerca:
Indagine della “linguistica del web”, ad oggi inesplorata;
Un nuovo design basato sul dialogo; dal punto di vista pratico;
Obiettivo dell'esercitazione:
Date consegna esercitazioni modulo 1
Date consegna esercitazioni modulo 2
Date consegna esercitazioni in Approfondimenti a carattere generale
Elenco dei siti realizzati dai corsisti durante le esercitazioni.