Jamboo's Webs and Blogs

Una Piattaforma WEB per la Scuola con Drupal un potente CMS Open Source

[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:

• Navigare nella sezione “Collection” del sito della National Gallery di Washington ( www. - nga.gov ) e identificare 2 single topics e 1 multiple topic.
• Navigare nel sito Munch und Berlin ( www.munchundberlin.org ) e identificare almeno due relazioni semantiche e mostrare i link sulla pagina che permettono di attivarle.
• Navigare nel sito Munch und Berlin ( www.munchundberlin.org ) e identificare almeno due group of topic e mostrare le due schermate corrispondenti.

L'information Architecture: Pagine e strutture, la progettazione logica

Introduzione a I.D.M.

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:

• Information architecture gerarchica per i primi livelli di navigazione (2-3)
• Information architecture ipertestuali per la navigazione “profonda” tra i contenuti.

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:

• Che cosa può essere detto?
• Quali sono i cambi di argomenti rilevanti?
• Quali sono le diverse strategie per organizzare il dialogo, cioè l’interazione con l’applicazione?

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:

• Facilitare l’attività di brainstorming tra i progettisti;
• Tenere traccia e paragonare i requisiti (in termini di obiettivi ed esigenze dei diversi stakeholder) con le scelte progettuali strategiche;
• Stimolare la discussione con gli stakeholder.

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:

• Il numero di concetti è estremamente limitato. Questo facilita l’apprendimento degli elementi di base per cominciare a progettare.
• Nonostante il loro limitato numero, tali concetti sono estremamente espressivi e ricchi per descrivere la complessità delle applicazioni interattive moderne che supportano dialoghi informativo-argomentativi.
• Tali concetti sono direttamente correlati con la nostra esperienza quotidiana di essere protagonisti di numerosi dialoghi. Proprio per questo, gli elementi di progettazione possono essere più facilmente appresi da persone che non hanno una formazione informatica o ingegnieristica.
• I concetti di IDM concettuale si trovano a un livello d’astrazione che permette di paragonare in modo semplice le scelte progettuali con i requisiti dell’applicazione, quindi facilitano la tracciabilità.

Di seguito riportiamo la versione testuale sintetica del progetto IDM concettuale del sito MUB.

• EXHIBITION: la descrizione della mostra temporanea sulle stampe di Edvard Munch.
• MUNCH: una breve introduzione a Edvard Munch.
• CONTACT US: indirizzi e punti di contatto degli organizzatori della mostra.
• MUSEUM: un breve profilo del museo nazionale di Berlino che ha ospitato la mostra sulle stampe di Edvard Munch.
• CREDITS: contatti e breve profilo del gruppo di progetto dell’applicazione.

• PRINT: la descrizione di una stampa della mostra.
• PERIOD OF LIFE: la descrizione di un periodo significativo della vita di Munch.
• ARTIST: la descrizione di un artista che ha particolarmente influenzato l’arte di Munch.
• ARTISTIC MOVEMENT: la descrizione di un movimento artistico contemporaneo a Munch.
• TECHNIQUE: la descrizione di una tecnica che Munch usava per realizzare le stampe.

• MADE DURING: se si sta parlando di una stampa, tale relazione collega la stampa al periodo della vita di Munch in cui quella stampa è stata realizzata.
• MADE WITH: se si sta parlando di una stampa, tale relazione collega la stampa alla tecnica usata da Munch per crearla.
• USED FOR: se si sta parlando di una tecnica, tale relazione collega una tecnica alle stampe realizzate con quella tecnica.
• INFLUENCED BY: se si sta parlando di un periodo della vita di Munch, tale relazione collega il periodo ai movimenti artistici più importanti in quel periodo.
• REPRESENTED BY: se si sta parlando di un movimento artistico, tale relazione collega il movimento artistico agli artisti rappresentativi di quel movimento.
• BELONGING TO: se si sta parlando di un artista, tale relazione collega l’artista al movimento artistico cui l’artista apparteneva o faceva riferimento.

• MASTERPIECES: le stampe che il curatore considera le più rappresentative della mostra.
• ALL PRINTS: tutte le stampe della mostra.
• TECHNIQUES: tutte le tecniche usate da Munch per creare le stampe esposte.
• MUNCH’S LIFE: l’insieme di tutti i periodi della vita di Munch.

• PRINTS OF THE SAME THEME: l’insieme delle stampe associate a uno dei temi fonte di ispirazione per l’opera di Munch.

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

• Lo schema C-IDM è molto semplice anche per progettisti inesperti e non necessita di molto tempo per essere definito (qualunque strumento di elaborazione di testo e immagini permette di farlo).
• Lo schema descrive tutti gli aspetti rilevanti (dal punto di vista dialogico-informativo) di un’applicazione interattiva complessa.
• Lo schema comunica le idee e le strategie sull’interazione, senza per questo vincolarsi a uno specifico canale di fruizione.
• Lo schema può essere usato in modo efficace ed efficiente per attività di braistorming, per generare e discutere idee sull’applicazione e per valutare alternative.

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.

Topic e Multiple Topic

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:

• EXHIBITION
• DATE OF BIRTH
• MUNCH
• SELF-PORTRAIT WITH A BOTTLE OF WINE.
• SEPARATION II (BREAKING AWAY / PARTING)
• STREETWORKERS (WORKERS DIGGING)
• PRINT NAME
• CONTACT US
• INTRODUCTION TO PRINT
• SIZE
• DRYPOINT
• ENGINEER FRØLICH
• FRIEDRICH NIETZSCHE
• GALLOPING HORSE
• YEAR
• MUSEUM
• THE DAY AFTER
• MOONLIGHT. NIGHT IN ST. CLOUD
• BIG PICTURE
• CREDITS
• DESCRIPTION
• COMMENT

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:

• Il numero mimino. Quante stampe ci saranno almeno?
• Il numero massimo. Quante stampe ci saranno al massimo?
• Il numero atteso. A regime, quante sono le stampe previste?

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:

• Childhood and youth in Norway (1863 – 1880),
• The beginning of his artistic career (1881 – 1884),
• Stays in Paris and first exhibition 1885 – 1891,
• Berlin period (1892 – 1895),
• Success and crisis (1896 – 1907),
• Return to Norway (1908 – 1944).

Relevant Semantic Relation

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.

Group of Topics

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:

• Decidere di quali contenuti parlare e sceglierli;
• Localizzarli;
• Metterli a tema (iniziare a parlare di tali contenuti).

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:

• Per farsi un’idea della quantità di argomenti;
• Per farsi un’idea della profondità con cui sono trattati i contenuti;
• Per trovare un contenuto specifico che si ha già in mente;
• Per trovare qualcosa di interessante da cui partire con la lettura;
• ecc.

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: tutte le stampe della mostra;
• MASTERPIECES: le stampe che il curatore considera maggiormente rappresentative.

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:

• Possono aiutare l’utente a farsi un’idea degli argomenti di cui si può parlare.
• Per utenti che visitano l’applicazione per la prima volta, i group of topics possono suscitare curiosità, interesse, e possono attrarre verso i contenuti dell’applicazione, e quindi fornire una motivazione in più per proseguire il dialogo. Molto spesso la percezione dei contenuti che l’utente si fa sulla homepage di un sito Internet è cruciale per decidere se abbandonare l’applicazione o prolungare la visita. L’homepage (come vedremo) è un elemento del dialogo che è basato (tra vari altri elementi) anche su un’opportuna scelta di group of topics.
• Permettono di reperire informazioni puntuali.
• Permettono di esplorare l’applicazione senza una meta precisa in cerca di qualche cosa di interessante.
• Permettono di dare diverse chiavi di lettura con cui consultare l’applicazione, offrendo percorsi alternativi per mettere a tema uno stesso contenuto.
• Permettono di guidare l’utente a scoprire nuovi contenuti di cui egli non conosceva l’esistenza, ma che possono inaspettatamente incontrare le sue esigenze.

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.