Model view controller: un pattern per l’interaction design

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

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

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

The strategy plane A questo livello si deﬁniscono: • 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

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

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

The skeleton plane JJG deﬁnisce 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

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, tipograﬁa, impaginazione. Strumenti: linee guida, checklist. UXCamp: Firenze, 10 2009 – p. 8

Cooper: goal-directed design Se progettiamo e realizziamo prodotti attraverso cui gli utenti possono soddisfare i propri scopi, quelle persone saranno soddisfatte, eﬃcaci 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

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

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 identiﬁcano 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 (scientiﬁci, medicali). UXCamp: Firenze, 10 2009 – p. 11

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

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

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

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

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

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

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

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

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

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. Oﬀre all’utente le aﬀordances 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

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 diﬀerenti: 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

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

Vantaggi (1) Competenze Il pattern permette una migliore diﬀerenziazione 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

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

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

Esempio: l’installazione per l’Asinara Nel progettare l’installazione ﬁnalizzata a pubblicizzare l’Asinara, gli studenti hanno esplorato diverse view e controller. View: • touch screen di varie dimensioni; • proiettore o coppia di proiettori per superﬁci 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

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 diﬀerenti piattaforme. UXCamp: Firenze, 10 2009 – p. 28

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

(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). Deﬁnizione di faccette di interrogazione: linea del tempo, nazionalit`, movimento artistico, stile .... a Collocazione dell’opera nello spazio ﬁsico del museo. UXCamp: Firenze, 10 2009 – p. 30

(Museo) vista: web Nel sito web possiamo immaginare • una pagina per ogni artista, che elenca le informazioni bibliograﬁche 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

(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 cuﬃe; • interazione: possibilit` di riconoscere l’opera via qrcode, a rﬁd, codice numerico, localizzazione wireless. UXCamp: Firenze, 10 2009 – p. 32

(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

(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 fotograﬁa ad alta risoluzione, scheda, descrizione; • linea del tempo; • indice degli autori e delle opere. UXCamp: Firenze, 10 2009 – p. 34

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

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

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

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

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

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

Model view controller: un pattern per l’interaction design

by Stefano Bussolon

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 23

Statistics