Il documento esplora l'applicazione del pattern software Model View Controller (MVC) nella progettazione di artefatti interattivi, evidenziando i suoi vantaggi nella separazione delle competenze e nella creazione di sistemi multidevice. Viene discussa la struttura dei 5 piani di design di Jesse James Garrett e il processo di Goal-Directed Design di Cooper, sottolineando l'importanza di adattare le interfacce agli utenti e ai contesti. Si presentano anche esempi pratici di applicazione del pattern nella progettazione, come un'installazione interattiva per la promozione dell'isola dell'Asinara.

1. Model view controller: un
pattern per l’interaction design
Stefano Bussolon
stefano@bussolon.it
hyperlabs.net
UXCamp: Firenze, 10 2009 – p. 1

2. Introduzione
In questo intervento si sostiene che il pattern software model
view controller pu` essere applicato alla progettazione di
o
artefatti interattivi.
Sommario:
• i 5 piani di Jesse James Garrett;
• Cooper, goal directed design, piattaforme e posture;
• il pattern model view controller;
• potenziali vantaggi del pattern nella progettazione di
artefatti interattivi;
UXCamp: Firenze, 10 2009 – p. 2

3. Jesse James Garrett: 5 piani
Nel suo “The elements of user experience” JJ Garrett
distingue 5 piani:
1. the strategy plane;
2. the scope plane;
3. the structure plane;
4. the skeleton plane;
5. the surface plane.
UXCamp: Firenze, 10 2009 – p. 3

4. The strategy plane
A questo livello si definiscono:
• i bisogni degli utenti che l’artefatto vuole soddisfare,
attraverso l’analisi degli utenti attuali e potenziali;
• gli obiettivi dei committenti:
• business goals: guadagnare soldi, risparmiare soldi,
migliorare la produttivit` ...
a
• branding, advertising: far conoscere il proprio
marchio, i propri prodotti, i propri servizi a potenziali
clienti e partner.
UXCamp: Firenze, 10 2009 – p. 4

5. The scope plane
A questo livello vengono definiti:
• le specifiche funzionali; vanno definite:
• quali funzioni vogliamo sviluppare, in che ordine di
priorit`, a che iterazione;
a
• quali funzioni non vogliamo sviluppare;
• il dominio informativo (content requirements): quali
informazioni. Strumenti:
• contenuti esistenti;
• analisi competitiva – benchmarking;
• richieste dei committenti: affinity diagram;
• coinvolgimento degli utenti: free listing, valutazione
di importanza.
UXCamp: Firenze, 10 2009 – p. 5

6. The structure plane
Vengono progettate, secondo JJG:
• l’interaction design: come il sistema si comporta in
risposta ai comportamenti dell’utente; definizione dei
flussi di processo, flussi dei compiti degli utenti
• l’architettura dell’informazione: la struttura
dell’informazione nello spazio informativo:
• la struttura gerarchica – card sorting;
• le microontologie.
UXCamp: Firenze, 10 2009 – p. 6

7. The skeleton plane
JJG definisce 3 componenti:
• l’information design: la presentazione delle
informazioni all’utente;
• l’interface design: la progettazione degli elementi
dell’interfaccia per permettere agli utenti di interagire
con l’applicazione;
• la progettazione della navigazione, che permette agli
utenti di muoversi all’interno della struttura informativa.
Uso di convenzioni, metafore, pattern, linee guida. Vengono
prodotti wireframes.
UXCamp: Firenze, 10 2009 – p. 7

8. The surface plane
A questo livello si progettano gli aspetti visuali. Gli aspetti di
cui tener conto sono molteplici:
• estetica;
• accessibilit`;
a
• branding, identity;
• consistenza interna ed esterna;
• colori, tipografia, impaginazione.
Strumenti: linee guida, checklist.
UXCamp: Firenze, 10 2009 – p. 8

9. Cooper: goal-directed design
Se progettiamo e realizziamo prodotti attraverso
cui gli utenti possono soddisfare i propri scopi,
quelle persone saranno soddisfatte, efficaci e felici,
saranno soddisfatte di aver acquistato i nostri
prodotti, li raccomanderanno agli amici, e questo si
traduce in un successo di business. – About face 3
Il goal directed design process: tradurre i risultati della fase di
ricerca in soluzioni progettuali.
UXCamp: Firenze, 10 2009 – p. 9

10. About face: il processo
1. Research: studiare gli utenti e il dominio
2. Modeling: utenti e contesto d’uso
3. Requirements: definire i bisogni degli utenti, i requisiti
di business, i requisiti tecnici
4. Framework: definizione della struttura e dell’interazione
5. Refinement: processo iterativo di rifinitura del design,
es dai wireframes ai prototipi ad alta fedelt`
a
6. Support: collaborazione con gli sviluppatori per venire
incontro alle loro esigenze salvaguardando l’integrit` del
a
progetto.
UXCamp: Firenze, 10 2009 – p. 10

11. Piattaforme
Mentre JJG si focalizza soltanto sui siti web, About face
ipotizzano lo sviluppo per piattaforme diverse. Per
piattaforma si intende una “combinazione di hardware e
software” che permette al prodotto di funzionare. Cooper e
colleghi identificano molteplici piattaforme:
1. i siti web e le applicazioni web;
2. i chioschi interattivi;
3. sistemi interattivi montati su veicoli e automobili;
4. handhelds (smartphone, pda, fotocamere);
5. sistemi di home entertaimnent (console per giochi, TV
interattive, home theater);
6. strumenti professionali (scientifici, medicali).
UXCamp: Firenze, 10 2009 – p. 11

12. Posture
Secondo Cooper i prodotti e le piattaforme si differenziano in
base a quello che definiscono postura, ovvero alla modalit` a
prevalente di interazione. Cooper identificano tre posture:
1. la postura sovrana: l’applicazione monopolizza
l’attenzione dell’utente per un periodo prolungato;
esempi: word processor, foglio di calcolo, web mail;
2. la postura transiente: l’applicazione transiente svolge
un’unica funzione, viene invocata per svolgere quella
funzione, l’interazione ` generalmente breve, poi torna
e
sullo sfondo; esempi: widgets, controlli multimediali;
3. la postura del demone: demoni sono quelle applicazioni
che girano in background, svolgendo funzioni che non
richiedono l’interazione con l’utente, se non nella fase di
setup e configurazione.
UXCamp: Firenze, 10 2009 – p. 12

13. Case history: l’isola dell’Asinara
Contesto: progetto InDEX: Interaction Design Experience:
master di primo livello della regione Sardegna.
Classe Sassari 2.
Scopo: far conoscere l’isola dell’Asinara a visitatori potenziali
e attuali, raccontando la storia, la colonia penale, il carcere di
massima sicurezza, gli aspetti naturalistici e paesaggistici;
promuovere la conoscenza delle regole del parco naturale e
della riserva marina.
Slogan: portare l’Asinara fuori dall’Asinara.
UXCamp: Firenze, 10 2009 – p. 13

14. L’Asinara: progetti
La classe ha sviluppato 3 progetti:
1. una installazione interattiva, finalizzata a far conoscere
l’isola e a “sedurre” i potenziali visitatori, da installare in
aereoporti, fiere turistiche, traghetti;
2. una applicazione per smartphone (iPhone): guida
all’isola, ai punti di interesse; informazioni storiche e
naturalistiche, regole del parco;
3. due installazioni all’interno di un museo nell’isola,
finalizzati a raccontare la storia e l’organizzazione del
carcere.
Progetti immaginati ma non sviluppati: il sito internet, gli
opuscoli informativi.
UXCamp: Firenze, 10 2009 – p. 14

15. Informazioni condivise
Piattaforme diverse, interazioni differenti, ma informazioni
sostanzialmente condivise. L’idea: progettare una architettura
informativa comune.
UXCamp: Firenze, 10 2009 – p. 15

16. Model view control
Model view controller ` un pattern di software design che
e
separa i contenuti, la presentazione e l’interazione.
Sviluppato allo Xerox Parc PARK di Palo Alto ed
implementato nel linguaggio ad oggetti Smalltalk-80.
MVC was conceived as a general solution to the problem of
users controlling a large and complex data set.
Secondo l’inventore di questo pattern the essential purpose of
MVC is to bridge the gap between the human user’s mental
model and the digital model that exists in the computer.
UXCamp: Firenze, 10 2009 – p. 16

17. MVC - flusso
1. Il modello codifica le informazioni e le offre attraverso
delle interfacce.
2. Una vista elabora le informazioni e le presenta all’utente.
3. L’utente interagisce con l’interfaccia offerta dalla vista.
4. Il controller ` in ascolto, in attesa degli eventi generati
e
dall’utente. Quando l’utente genera un evento il
controller lo gestisce avviando una azione, che
generalmente aggiorna il modello e-o la vista.
5. La vista interroga il modello per disporre dei dati
aggiornati in seguito all’input dell’utente.
6. Il controller si rimette in attesa degli input dell’utente.
UXCamp: Firenze, 10 2009 – p. 17

18. MVC e software design
Questo pattern ` utilizzato estensivamente nei pi` importanti
e u
framework di sviluppo software:
• SmallTalk
• Microsoft Foundation Classes (C++), .Net
• Java (Struts, Swing, SpringMVC, Cocoon)
• ActionScript
• Pyton (Zope, Plone)
• Ruby
• PHP (Drupal, Joomla!)
UXCamp: Firenze, 10 2009 – p. 18

19. Model
Il modello codifica le informazioni, privilegiando gli aspetti
implementativi.
`
E il system model di Donald Norman e l’implementation
model di Cooper.
L’informazione viene codificata generalmente sotto forma di:
• basi di dati
• documenti che usano linguaggi di markup (es xml)
• file multimediali: immagini, video, suoni, musica
UXCamp: Firenze, 10 2009 – p. 19

20. View
La vista ` una delle possibili rappresentazioni delle
e
informazioni codificate nel modello.
La rappresentazione ` generalmente visiva, anche se con
e
software di text to speech pu` essere anche uditiva (es. la
o
voce del navigatore satellitare).
La view deve adattarsi al modello mentale dell’utente.
Corrisponde al designer’s model di Norman.
La vista traduce il modello in una forma che permetta
all’utente la comprensione e l’interazione.
Uno degli assunti fondamentali del pattern mvc ` che, per
e
ogni modello, possono esserci viste differenti.
Esempio classico: una base di dati pu` essere vista in forma
o
di tabella e-o in forma di grafico.
UXCamp: Firenze, 10 2009 – p. 20

21. Controller
Il controller ` ci` che permette all’utente di agire sul sistema,
e o
attraverso dei sistemi di input.
Implementa dunque le funzionalit` del sistema, permettendo
a
all’artefatto di interagire con l’utente e di rispondere ai suoi
input.
`
E il collegamento fra l’utente e il sistema. Offre all’utente le
affordances per interagire con l’artefatto. Tecnicamente
l’interazione avviene con il modello, ma l’utente riceve un
feedback attraverso l’aggiornamento della vista.
UXCamp: Firenze, 10 2009 – p. 21

22. Software e buone pratiche
La separazione del codice deputato al modello, alla vista e al
controllo dell’applicazione costituisce una buona pratica di
progettazione nell’ambito dello sviluppo del software, in
quanto:
• utilizzano strumenti e linguaggi differenti:
1. sql, java(pojo,javabeans)-python per il modello;
2. html, jsp-asp-php per la vista;
3. javascript, servlet per il controllo;
• facilita lo sviluppo, il debug, la manutenzione;
• permette la specializzazione degli sviluppatori;
• facilita lo sviluppo di applicazioni accessibili.
UXCamp: Firenze, 10 2009 – p. 22

23. MVC e user experience design
La proposta ` di adattare il pattern MVC al modello di
e
progettazione di artefatti interattivi.
UXCamp: Firenze, 10 2009 – p. 23

24. Vantaggi (1) Competenze
Il pattern permette una migliore differenziazione delle
competenze:
• il modello sarebbe di esclusiva competenza
dell’architettura dell’informaizione. Anzi, il modello
rappresenterebbe il core dell’IA
• il controller sarebbe di competenza dell’interaction
design (il core dell’ID)
• la vista sarebbe di competenza prevalente
dell’information design - visual design, con la
collaborazione dell’IA per la navigazione e dell’ID per gli
aspetti legati all’interazione.
UXCamp: Firenze, 10 2009 – p. 24

25. Vantaggi (2) Sistemi multidevice
una pi` facile progettazione di sistemi informativi multidevice,
u
ovvero fruibili da web, da smartphone e da altri dispositivi: il
modello rimane, la vista e il controller cambiano.
UXCamp: Firenze, 10 2009 – p. 25

26. Vantaggi (3) Design creativo
Lo sviluppo di viste differenti pu` permettere al designer di
o
sviluppare, a fianco delle interfacce pi` tradizionali e
u
codificate, soluzioni creative ed innovative. Se gli utenti
hanno la possibilit` di decidere quale fra le differenti
a
interfacce usare, protranno scegliere quella che pi` si adatta
u
alle loro caratteristiche, esigenze, prefrenze, tenuto conto
anche del contesto.
UXCamp: Firenze, 10 2009 – p. 26

27. Esempio: l’installazione per l’Asinara
Nel progettare l’installazione finalizzata a pubblicizzare
l’Asinara, gli studenti hanno esplorato diverse view e
controller. View:
• touch screen di varie dimensioni;
• proiettore o coppia di proiettori per superfici pi` grandi.
u
Controller:
• interazione collocata sul pavimento (physical computing)
• interazione con il touchscreen;
• interazione con touchwall (physical computing)
• interazione con consolle (trackball e pulsanti)
• scenario futuribile: interazione con movement
recognition.
UXCamp: Firenze, 10 2009 – p. 27

28. Scenario 1: Gruppo editoriale
Editore di quotidiani (La Repubblica, Il Corriere, The New
York Times). Attualmente questi gruppi distribuiscono le
informazioni attraverso molteplici canali:
• il quotidiano cartaceo;
• il sito web;
• il sito per il dispositivo mobile / l’applicazione per
iPhone-Android;
• broadcast via radio (Radio Capital, Radio24), TV, web
TV;
• futuro prossimo: e-readers.
Stesse notizie, livello di approfondimento diverso.
Soluzione: un CMS capace di generare viste e interazioni
diverse per le differenti piattaforme.
UXCamp: Firenze, 10 2009 – p. 28

29. Scenario 2: Museo d’arte
Scenario: un museo organizza una mostra temporanea. Deve
sviluppare - aggiornare:
• il sito internet del museo, con una sezione dedicata alla
mostra;
• le guide interattive al museo, che utilizzano handhelds
multimediali;
• gli opuscoli gratuiti distribuiti all’interno del museo;
• gli exibit interattivi;
• il catalogo delle opere.
UXCamp: Firenze, 10 2009 – p. 29

30. (Museo) modello: ontologie
Lo sviluppo del modello si focalizzer` su due tipologie di unit`
a a
informative:
• gli artisti;
• le opere.
`
E possibile usare dei microformati per rappresentare queste
informazioni. Esempio, per gli artisti, il microformato foaf
(friend of a friend).
Definizione di faccette di interrogazione: linea del tempo,
nazionalit`, movimento artistico, stile ....
a
Collocazione dell’opera nello spazio fisico del museo.
UXCamp: Firenze, 10 2009 – p. 30

31. (Museo) vista: web
Nel sito web possiamo immaginare
• una pagina per ogni artista, che elenca le informazioni
bibliografiche e l’elenco delle opere;
• una pagina per ogni opera, con foto, autore, data,
collezione, informazioni;
• una linea del tempo interattiva;
• una mappa che geotagga il luogo di creazione delle
opere;
• una pianta del museo con la collocazione delle opere.
UXCamp: Firenze, 10 2009 – p. 31

32. (Museo) vista: guida interattiva
La guida interattiva pu` prevedere
o
• una schermata per ogni artista;
• una schermata per ogni opera, con foto, autore, data,
collezione, informazioni; descrizione audio dell’opera in
formato mp3, da ascoltare con cuffie;
• interazione: possibilit` di riconoscere l’opera via qrcode,
a
rfid, codice numerico, localizzazione wireless.
UXCamp: Firenze, 10 2009 – p. 32

33. (Museo) vista: exibit interattivo
L’installazione interattiva pu` permettere all’utente di giocare
o
con le opere esposte, ad esempio usando un programma di
image editing per ritoccare una copia della fotografia dei
quadri.
Oppure creare dei quiz e questionari sulla conoscenza delle
opere e degli artisti, utilizzando in maniera flessibile le
informazioni presenti a livello del model.
Pu` permettere agli utenti di visualizzare il processo di
o
restauro di un quadro, visualizzando le differenze fra le
condizioni pre e post restauro e i dettagli dell’intervento.
Anche in questo caso queste stesse attivit` possono essere
a
presentate anche sul sito web.
UXCamp: Firenze, 10 2009 – p. 33

34. (Museo) vista: catalogo delle opere
Il catalogo pu` essere generato via pdf, e pu` prevedere
o o
• le pagine degli artisti, con descrizione;
• le pagine per ogni opera, con fotografia ad alta
risoluzione, scheda, descrizione;
• linea del tempo;
• indice degli autori e delle opere.
UXCamp: Firenze, 10 2009 – p. 34

35. Scenario: orario dell’autobus
Azienda di trasporti pubblici: orario degli autobus. Fruizione:
• via opuscolo da distribuire nelle biglietterie o scaricare
via web;
• via sito web;
• via applicazione per smartphone, sfruttando l’ora e la
geolocalizzazione via gps;
• le paline cartacee o interattive alle fermate.
UXCamp: Firenze, 10 2009 – p. 35

36. Il processo
Il flusso progettuale. L’approccio ` fortemente iterativo
e
UXCamp: Firenze, 10 2009 – p. 36

37. Il processo
Il processo prevede di separare, in fase di design, la
progettazione di modello, vista e controllo.
Il processo ` fortemente iterativo. Nella prima iterazione ci si
e
focalizza, prima e soprattutto, nello sviluppo del modello. Il
modello deve essere abbastanza flessibile da permettere di
essere interrogato da viste molto differenti.
Le diverse viste - interazioni vanno progettate in ordine di
priorit`. Alla prima iterazione la vista / piattaforma pi`
a u
semplice, testata e diffusa. Nelle iterazioni successive le viste
/ piattaforme pi` complesse o innovative.
u
UXCamp: Firenze, 10 2009 – p. 37

38. Model, api, feeds
La divisione fra modello, vista e controllo pu` portare allo
o
sviluppo delle diverse funzioni da parte di soggetti differenti.
Se il modello espone i propri dati attraverso delle A.P.I. (soap,
rest, json) permette a sviluppatori esterni di implementare
delle viste differenti e flessibili.
Chi sviluppa il view - controller interroga il server, carica i dati
grezzi e li elabora in modalit` innovative. Se pi` soggetti
a u
sviluppano viste diverse in base agli stessi dati, gli utenti
potranno scegliere l’interfaccia che riterranno pi` utile,
u
usabile, piacevole e conveniente, in base anche al contesto
d’uso.
UXCamp: Firenze, 10 2009 – p. 38

39. Conclusioni?
L’idea che ho presentato ` quella di mettere assieme due
e
metodi consolidati (la metodologia di design, il pattern
software mvc) per formalizzare qualcosa che implicitamente
gi` succede.
a
Che ne pensate?
UXCamp: Firenze, 10 2009 – p. 39

40. Grazie
www.bussolon.it
stefano@bussolon.it
http://www.linkedin.com/in/bussolon
http://www.facebook.com/stefano.bussolon
UXCamp: Firenze, 10 2009 – p. 40