Università degli Studi di Brescia Corso di laurea magistrale in Ingegneria Informatica End-­‐user development di oggetti fisici interattivi Studente: Fabio Filisetti Matricola: 85937 Relatore: Dott.ssa Daniela Fogli Correlatore: Prof.ssa Elisa Giaccardi ANNO ACCADEMICO 2012/2013 Ringraziamenti Ne è passato di tempo da quel mattino di settembre, quando varcai per la prima volta i cancelli di Via Branze, ignaro di quello a cui andavo incontro… A quel tempo la laurea triennale sembrava un lontano miraggio, figuriamoci quella magistrale! (che all’epoca si chiamava specialistica) Invece eccomi qui a compiere l’ultima fatica prima del traguardo, che poi è anche una nuova griglia di partenza, visto che qui non si smette mai di correre. In questi anni trascorsi a ingegneria, ci sono stati sia momenti divertenti che difficili, sicuramente non sarebbe stato lo stesso senza le persone con le quali ho avuto la fortuna di condividerli (e con alcuni trascorrere interminabili ore sulle banchine della stazione ad imprecare contro Trenitalia), che desidero ringraziare: Ace, Alex, Caccia, Denis, Eros, Michela, Miglio, Nicola, Paolino, Ricky, Sera. Non dimentichiamo che esiste una vita anche al di fuori dell’università, con la quale ho trascorso, e continuo a trascorrere, bei momenti con (oltre ai nomi sopra citati): Andrea, Eda, Faio, Fra, Gaia, Lia, Luca, Maffio, Paola, Zucchi. Che per questo ringrazio. Un bel giorno mi sono messo in testa di fare la tesi all’estero, cosa che sono riuscito a realizzare grazie alla mia relatrice, dott.ssa Daniela Fogli e alla prof.ssa Elisa Giaccardi, che per questo hanno la mia più profonda gratitudine. Ho così trascorso cinque mesi indimenticabili in Olanda, a Delft, dove ho conosciuto delle persone fantastiche provenienti da varie parti del mondo, a cominciare da Giorgio che mi ha accolto con grande simpatia e disponibilità sin dai primi giorni. Ringrazio per la loro compagnia anche: Bengisu, Cansin, Ezgi, Francesca, Lara, Lorenzo, Luca, Marco, Markus, Mercedes, Nicola, Sara, Silvia, Ting, Tiziano, e tutte le persone con le quali ho scambiato anche solo 2 parole (specialmente se in inglese). Last but not least, visto che tutto quello che ho scritto sopra non sarebbe stato possibile senza il loro supporto, desidero ringraziare la mia famiglia: i miei genitori Laura e Sergio, mia sorella Serena, i nonni Paola e Sandro, la zia Silvia e Brendan. Indice CAPITOLO 1: INTRODUZIONE ............................................................................................. 6 1.1 IL CONTESTO ....................................................................................................................... 6 1.2 IL PROBLEMA AFFRONTATO .................................................................................................... 7 1.3 OBIETTIVI ........................................................................................................................... 9 1.4 ATTIVITÀ SVOLTE ............................................................................................................... 10 CAPITOLO 2: LO STATO DELL’ARTE ................................................................................... 13 2.1 GLI STRUMENTI A SUPPORTO DELLA PROTOTIPAZIONE FISICA ..................................................... 13 2.1.1 ARDUINO .................................................................................................................. 13 2.1.2 PHIDGETS .................................................................................................................. 17 2.1.3 MAX/MSP ................................................................................................................ 17 2.2 STRUMENTI DI SUPPORTO ALLA CREAZIONE DI PRODOTTI SOCIALI ............................................... 18 2.2.1 TEMBOO ................................................................................................................... 19 2.2.2 READIYMATE ............................................................................................................. 21 2.2.3 SENSE.ME .................................................................................................................. 22 CAPITOLO 3: ANALISI E SPECIFICA DEI REQUISITI .............................................................. 29 3.1 ANALISI DI SENSE.ME ......................................................................................................... 29 3.2 SPECIFICA DEI REQUISITI ...................................................................................................... 32 CAPITOLO 4: RIPROGETTAZIONE DEL SISTEMA ................................................................. 38 4.1 RIPROGETTAZIONE DELL’ARCHITETTURA ................................................................................. 38 4.2 RIPROGETTAZIONE DELLO SCHEMA DEI DATI ........................................................................... 52 CAPITOLO 5: IMPLEMENTAZIONE DEL SISTEMA ............................................................... 55 5.1 INTERFACCIA PER L’ASSOCIAZIONE DEI SENSORI ....................................................................... 55 5.2 CONFIGURAZIONE DEI COMPORTAMENTI SOCIALI .................................................................... 61 5.3 GENERAZIONE DEL CODICE PER ARDUINO ............................................................................... 62 5.4 AUTENTICAZIONE CON I SOCIAL NETWORK .............................................................................. 68 5.5 GESTIONE DELL’INTERAZIONE CON IL PROTOTIPO FISICO ............................................................ 71 CAPITOLO 6: VALUTAZIONE DI SENSE.ME 2.0 ................................................................... 83 6.1 FASE PRELIMINARE ............................................................................................................. 83 6.2 SCELTA DEL CAMPIONE DI UTENTI ......................................................................................... 86 6.3 DEFINIZIONE DELLA STRUTTURA PER LA VALUTAZIONE .............................................................. 86 6.4 RISULTATI ......................................................................................................................... 96 6.5 CONCLUSIONI ................................................................................................................. 105 CAPITOLO 7: MODIFICHE APPORTATE DOPO LA VALUTAZIONE ...................................... 108 7.1 CONFIGURAZIONE DEGLI EVENTI ......................................................................................... 108 7.2 ASSOCIAZIONE DEI SENSORI ............................................................................................... 112 7.3 PAGINA DI TEST ............................................................................................................... 114 7.4 ALTRE MODIFICHE ............................................................................................................ 116 CAPITOLO 8: CONCLUSIONI E SVILUPPI FUTURI .............................................................. 118 8.1 RISULTATI OTTENUTI ........................................................................................................ 118 8.2 POSSIBILI SVILUPPI FUTURI ................................................................................................. 119 APPENDICE .................................................................................................................... 122 A. TECNOLOGIE UTILIZZATE ..................................................................................................... 122 B. GUIDA PER IL PROGRAMMATORE .......................................................................................... 132 RIFERIMENTI BIBLIOGRAFICI .......................................................................................... 137 Cap.1 -­‐ Introduzione Capitolo 1: Introduzione In questo capitolo viene descritto il contesto nel quale è stato svolto il lavoro di tesi, il problema affrontato e gli obiettivi del progetto. Viene successivamente fornita una sintesi delle attività svolte, le quali saranno approfondite nei capitoli successivi. 1.1 I l c ontesto La seguente tesi tratta del lavoro svolto presso il dipartimento di Industrial Design Engineering, all’interno della Delft University of Technology, situata nei Paesi Bassi. Essa, denominata anche TU Delft, fu fondata nel 1842 a Delft, nella regione dell’Olanda meridionale, come accademia reale per l’educazione di ingegneri civili, da re Willem II. Nel 1864 divenne Polytechnic school, nel 1905 Institute of technology, fino ad assumere la denominazione attuale nel 1986. Con oltre 19 000 studenti e 3 300 tra professori e ricercatori, è la più grande ed antica università tecnica pubblica del paese. Al suo interno sono presenti otto facoltà, tra le quali quella di Industrial Design Engineering, dove vengono trattate discipline relative all’ergonomia ed al design di prodotto, ponendo l’enfasi sull’interazione tra questo e l’utente. Gli aspetti principali sono: l’espressività dei prodotti, l’usabilità e l’estetica, i significati che le forme assumono per gli utenti e la progettazione in un contesto socio-­‐culturale. La facoltà eroga tre corsi di laurea magistrale, tutti in lingua inglese: •
Design For Interaction (DFI): approfondisce l’interazione tra persona e prodotto, immaginando come questa possa essere supportata o arricchita utilizzando le tecnologie esistenti ed emergenti. 6 Cap.1 -­‐ Introduzione •
Integrated Product Design (IPD): si concentra sulla progettazione completa del prodotto, dall’idea iniziale al prodotto finito, in modo da bilanciare le esigenze degli utenti, dell’industria e della società. Questo corso di laurea integra aspetti tecnologici e di buisness. •
Strategic Product Design (SPD): approfondisce il processo di sviluppo di nuovi prodotti, e la commercializzazione degli stessi. Il lavoro di tesi è stato svolto all’interno del gruppo di uffici denominato ID Studio Labs 1 , una comunità di ricerca formata da oltre 40 membri, tra professori, ricercatori, dottorandi e tesisti. Le attività di ricerca svolte si concentrano sulla user experience, che viene trattata con un approccio multi-­‐disciplinare, visto il variegato background culturale del personale, che spazia dall’elettronica alla sociologia. Tra le strutture a disposizione del gruppo figurano open space, laboratori di elettronica e prototipazione, stanze per l’analisi di usabilità, sale per riunioni e presentazioni. Vengono svolte anche attività legate alla didattica, in particolare per il corso di laurea DFI. Gli insegnamenti riguardano principalmente la creazione di prototipi fisici interattivi, utilizzando strumenti come Arduino2. Il lavoro svolto durante i cinque mesi trascorsi a Delft, è la prosecuzione di quello iniziato da un altro studente di Ingegneria Informatica presso l’Università degli Studi di Brescia, all’interno dello stesso ambiente. Esso consiste nello sviluppo di un framework che supporti i designer nella creazione di prototipi che interagiscono con i social network. 1.2 I l p roblema a ffrontato 1
http://studiolab.io.tudelft.nl 2
http://arduino.cc 7 Cap.1 -­‐ Introduzione Nella progettazione di oggetti fisici interattivi, i classici prototipi cartacei sono inadeguati, in quanto non consentono di testare il loro funzionamento. Per questo motivo gli studenti di industrial design sono interessati alla creazione di prototipi basati sull’elettronica. Presso la TU Delft, questo avviene utilizzando la piattaforma Arduino, spesso accompagnata da TinkerKit 3 , che permette di semplificare notevolmente il collegamento di sensori ed attuatori al micro-­‐processore. Nonostante il linguaggio di programmazione utilizzato per programmare Arduino sia pensato per essere semplice, gli studenti, non avendo un background informatico, incontrano varie difficoltà che limitano il loro lavoro, dovendo essi concentrarsi sul linguaggio invece che sulla progettazione dell’interazione con l’utente. Inoltre sono sempre più diffusi i cosiddetti prodotti sociali, oggetti in grado di interagire con i social network, cosa che stimola i designer a voler esplorare questo campo. Quasi tutti i social network offrono delle API (application programming interface), che possono essere utilizzate dai programmatori per integrare il proprio codice con le funzionalità da essi offerte. Tuttavia gli studenti di industrial design spesso non conoscono l’esistenza di questi strumenti, e anche quando ne sono a conoscenza, non hanno le competenze adeguate per utilizzarli. Per interfacciarsi con le API dei social network infatti, prima è necessario eseguire l’autenticazione con il protocollo oAuth [1], ottenendo un token di accesso, in seguito bisogna invocare l’API desiderata, gestendone la risposta e gli eventuali errori. Come ulteriore complicazione, ogni social network gestisce l’autenticazione e l’invocazione delle API in modo diverso. 3
http://www.tinkerkit.com 8 Cap.1 -­‐ Introduzione Per cercare di aiutare gli studenti a creare prototipi che interagiscono con le reti sociali, in un precedente lavoro di tesi dell’Università di Brescia svolto all’interno degli ID Studio Labs è stato sviluppato il framework Sense.me. Nella sua prima versione, questo framework consente di creare, mediante un’interfaccia web, un prototipo che comunica con Facebook, scaricare il codice generato per Arduino e testare il prodotto risultante. Sense.me è stato apprezzato dagli studenti ai quali è stato fatto testare. Per questo motivo si è deciso di proseguire con lo sviluppo del framework, espandendone le funzionalità, tenendo conto delle esigenze sopra esposte e delle osservazioni raccolte durante i test della prima versione. 1.3 O biettivi L’obiettivo principale dell’attività di tesi è stato quello di proseguire lo sviluppo di Sense.me, espandendone le funzionalità, e inquadrando a tutti gli effetti il framework nel contesto del cosiddetto End-­‐User Development (EUD) [2], l’insieme di metodi, tecniche e strumenti che consentono agli utenti finali di un sistema software, i quali non sono sviluppatori professionisti, di creare, modificare o estendere il sistema stesso. L’obiettivo di Sense.me è quello di assistere gli industrial designer, i nostri utenti finali, nella prototipazione fisica di prodotti in grado di acquisire informazioni tramite sensori e di comunicare con i social network quando vengono rilevate determinate condizioni. Il prototipo deve essere configurato tramite un’interfaccia grafica intuitiva, che consenta al designer di concentrarsi maggiormente sull’esperienza d’uso, invece che sulla sua implementazione. Al termine della configurazione deve essere generato automaticamente il codice per Arduino, pronto per essere utilizzato senza modifiche da parte del designer. 9 Cap.1 -­‐ Introduzione Una volta che il prototipo fisico è pronto, il designer deve poter testare il suo funzionamento all’interno del framework, che si prenderà cura dell’autenticazione con i social network coinvolti e di comunicare al progettista cosa succede quando il prodotto fisico rileva un evento. 1.4 A ttività s volte Per perseguire gli obiettivi sopra descritti, sono state svolte numerose attività. Di seguito ne viene fornita una breve descrizione, approfondita successivamente nei capitoli dedicati. 1. Analisi di Sense.me Per prima cosa è stato studiato in profondità il framework, inizialmente mettendosi nei panni di un utente, e provando dunque ad utilizzare l’applicazione e testare il codice generato su Arduino. Successivamente si è cominciato ad analizzare l’organizzazione ed il funzionamento del codice. 2. Analisi dei test con gli utenti Al termine dello sviluppo della prima versione erano stati effettuati dei test con gli utenti. Per capire in che direzione muoversi per ampliare le funzionalità del sistema, sono stati analizzati i risultati ottenuti ed i commenti degli utenti. 3. Proposta di modifiche Il punto 2 ha portato alla stesura di un elenco di modifiche da apportare al sistema, per realizzare quello che è stato rinominato Sense.me 2.0. Esse sono state discusse insieme al relatore ed al correlatore, fino a raggiungere un elenco finale (descritto nel capitolo 3). 10 Cap.1 -­‐ Introduzione 4. Analisi dei social network e dei comportamenti sociali da essi offerti Una delle modifiche che si è deciso di apportare, è state quella di aumentare i social network, ed i comportamenti sociali, disponibili all’interno del sistema. Per comportamento sociale si intende un’azione che è possibile effettuare con un certo social network. Nella prima versione, ad esempio, era disponibile solo Facebook, con tre comportamenti sociali: “pubblica post”, “mostra post” e “mostra fotografie”. Per stabilire quali reti sociali aggiungere al sistema, e quali comportamenti per ognuna, sono stati stabiliti dei criteri di scelta. 5. Riprogettazione del sistema Una volta stabilito quali modifiche fosse necessario apportare, l’architettura del sistema è stata riprogettata in modo da includerle. Questa fase è descritta in dettaglio nel capitolo 4. 6. Implementazione In seguito alla riprogettazione, sono state realizzate le modifiche previste. In alcuni casi è stato modificato il codice esistente, in altri casi, come l’aggiunta di funzionalità o modifiche radicali, è stato necessario riscriverlo da zero (vedi capitolo 6). 7. Testing Durante l’implementazione le varie parti di Sense.me sono state testate per verificarne il corretto funzionamento. Dopo aver concluso la fase implementativa è stato testato l’intero sistema. 8. Valutazione con gli utenti Per verificare che la nuova versione si Sense.me soddisfacesse gli utenti, e si integrasse nella fase di ideazione di prototipi fisici, sono stati svolti dei test con degli studenti, descritti nel capitolo 7. 11 Cap.1 -­‐ Introduzione 9. Implementazione delle modifiche successive al test con gli utenti I test con gli utenti hanno evidenziato alcuni problemi nell’organizzazione dell’interfaccia, per questo motivo si è provveduto a modificarla. 12 Cap.2 – Lo stato dell’arte Capitolo 2: Lo stato dell’arte In questo capitolo vengono descritti gli strumenti hardware e software utilizzati per creare prototipi all’interno della facoltà di Industrial Design Engineering della TU Delft. Inoltre, viene descritta la prima versione di Sense.me, che costituisce la base del presente lavoro di tesi. 2.1 Gli strumenti a supporto della prototipazione fisica 2.1.1 Arduino Arduino è una piattaforma hardware open source, sviluppata presso l’Interaction Design Institute di Ivrea (Italia) a partire dal 2005, che consente di creare rapidamente prototipi che utilizzano sensori ed attuatori. L’obiettivo iniziale del progetto era quello di consentire agli studenti di design di avere a disposizione un sistema di prototipazione più semplice ed economico rispetto a quelli allora esistenti. Gli schemi circuitali della scheda sono distribuiti liberamente tramite la licenza GPLv21, cosa che ha portato allo sviluppo di numerose versioni, sia ufficiali che Arduino-­‐compatibili sviluppate da terzi. La versione base, mostrata in fig. 2.1, è composta da un microcontrollore, un regolatore di tensione, svariati pin di input e output ed un’interfaccia USB. Altre versioni comprendono, tra le altre cose, porta ethernet e scheda wi-­‐fi. Alcuni modelli recenti sono dotati di sistema operativo Linux. 1
http://www.gnu.org/licenses/gpl-­‐2.0.html 13 Cap.2 – Lo stato dell’arte Fig. 1.1 -­‐ Arduino UNO Oltre alla componente hardware, Arduino comprende un ambiente di sviluppo integrato (IDE) multipiattaforma, che consente di scrivere il codice di controllo, caricarlo sul microcontrollore, tramite la sua interfaccia USB, leggere e scrivere in formato ASCII sulla porta seriale durante la fase di runtime. Il linguaggio di programmazione utilizzato è il Wiring2, derivato da C e C++, anch’esso open source. In pochi anni Arduino ha ottenuto un notevole successo mondiale tra studenti e hobbisti, cosa che ha portato allo sviluppo di un gran numero di librerie per Wiring, le quali consentono di controllare facilmente un gran numero di sensori ed attuatori, oltre che connettere il microcontrollore con software in esecuzione sul computer al quale è collegato, come ad esempio Adobe Flash3, Processing4, SuperCollider5. Lo schema di funzionamento di Arduino prevede che all’interno di un ciclo infinito, vengano letti i valori dei sensori collegati ai pin di input. Se questi soddisfano le 2
http://wiring.org.co 3
http://www.adobe.com/it/products/flash.html 4
http://processing.org 5
http://supercollider.sourceforge.net 14 Cap.2 – Lo stato dell’arte condizioni definite nella logica di controllo, vengono attivati gli attuatori, collegati ai pin di output. Sensori S Controllore S Attuatori Fig. 2.2 -­‐ Schema funzionamento di Arduino Nonostante Arduino, rispetto a prodotti simili, semplifichi la scrittura del codice di controllo grazie al linguaggio Wiring, collegare sensori ed attuatori alla scheda non è banale, in quanto richiede delle conoscenze di elettronica. Essi infatti devono essere inseriti in un circuito, insieme ad altri componenti, come resistenze o condensatori. Per semplificare questa fase, il team di Arduino ha sviluppato TinkerKit!. Esso è costituito da una scheda che si collega all’alimentazione ed ai pin del microcontrollore, e da un insieme di sensori ed attuatori, con la loro elettronica di supporto integrata, che possono essere collegati alla scheda tramite un semplice plug-­‐and-­‐play. In questo modo l’utente non deve più preoccuparsi di creare un circuito elettronico nel quale inserire i componenti desiderati. TinkerKit! mette a disposizione anche una libreria dedicata, che permette di facilitare ulteriormente la programmazione di sensori ed attuatori, introducendo un ulteriore livello di astrazione rispetto al normale linguaggio di Arduino. 2.1.1.1 Ambienti di sviluppo software per Arduino Come accennato, Arduino mette a disposizione un ambiente di sviluppo integrato, che permette di scrivere, compilare e caricare il codice in modo semplice, essendo concepito per iniziare alla programmazione persone non esperte nel campo. 15 Cap.2 – Lo stato dell’arte L’IDE, mostrato in fig. 2.3, contiene un editor di testo per la scrittura del codice, comprensivo di controllo delle parentesi ed indentazione automatica. Sono presenti inoltre un’area dove vengono visualizzati messaggi, una console di testo, una barra degli strumenti con pulsanti per le funzioni comuni, ed una serie di menu. I file di codice sono chiamati sketch, e vengono salvati con l’estensione .ino. L’editor è in grado di compilare e lanciare l’eseguibile in un unico passaggio, senza la necessità di creare makefile o utilizzare la riga di comando. L’area dei messaggi fornisce un feedback durante il salvataggio e l’esportazione, ed è utile per la visualizzazione degli errori. La console consente di visualizzare l’output di testo, inclusi messaggi di errore ed altre informazioni. I pulsanti sulla barra degli strumenti permettono di verificare la correttezza del codice e caricarlo sulla scheda, aprire e salvare i programmi ed aprire il monitor seriale. Fig. 2.3 -­‐ L'IDE di Arduino Esistono altri ambienti di sviluppo per Arduino che consentono di programmare il microcontrollore mediante un’interfaccia visuale, senza dover dunque scrivere codice. La metafora utilizzata è quella dei blocchi ad incastro: per creare uno la 16 Cap.2 – Lo stato dell’arte logica di controllo è possibile utilizzare blocchi già pronti ed assemblarli come un puzzle. I principali sono ArduBlock10, Modkit11 e S4A12. Nonostante il semplice approccio alla programmazione che offrono questi ambienti, la loro limitatezza nella costruzione di prodotti sociali ha portato ad abbandonare l’idea iniziale di utilizzarli per realizzare l’obiettivo. 2.1.2 Phidgets I Phidgets 13 , sviluppati dall’omonima azienda di Calgary (Canada), sono dei componenti elettronici a basso costo che possono essere controllati da un personal computer tramite la porta USB. Il controllo può avvenire tramite svariati linguaggi di programmazione, per i quali il produttore fornisce le apposite API. Utilizzando la Phidgets InterfaceKit è possibile utilizzare più componenti contemporaneamente. Il vantaggio di questo strumento è quello di poter utilizzare un gran numero di sensori ed attuatori con i linguaggi di programmazione più comuni, inoltre i componenti sono plug-­‐and-­‐play, in modo simile a TinkerKit!, non richiedendo quindi la necessità di creare circuiti elettronici. Lo svantaggio, rispetto ad Arduino, è la complessità maggiore, dovuta al fatto di doversi confrontare con le API di linguaggi complessi. 2.1.3 Max/MSP Max14 è un ambiente di sviluppo grafico per la musica e la multimedialità, ideato e aggiornato dall'azienda di software Cycling '74, con base a San Francisco (California, 10
http://ardublock.com 11
http://www.modkit.com 12
http://s4a.cat 13
http://www.phidgets.com 14
http://cycling74.com/products/max 17 Cap.2 – Lo stato dell’arte USA). È utilizzato da compositori, esecutori, progettisti software, ricercatori e artisti interessati a creare software interattivo. Max è altamente modulare: la maggior parte delle sue routine esiste in forma di libreria condivisa. Una API permette a terze parti lo sviluppo di nuove routine (chiamate external objects, oggetti esterni). Grazie al suo progetto estensibile e alla sua interfaccia grafica, Max è comunemente considerato una sorta di lingua franca per lo sviluppo di software inerente alla musica interattiva. I programmi generati vengono chiamati “Patch” e sono creati collegando più oggetti tra loro. Esistono molti tipi di oggetti: alcuni generano suoni, altri effetti video, altri ancora fanno semplici calcoli o prendono decisioni. Il flusso di esecuzione avviene attraverso scambi di messaggi tra oggetti che possono ricevere degli input e generare degli output all’interno di un apposito spazio dell’ambiente di sviluppo. I messaggi possono trasportare dei dati atomici, come numeri interi, simboli, “Bang”, ecc. Un “Bang” indica un messaggio di trigger per l’oggetto a cui è collegato (il tutorial di Max lo definisce come “il messaggio che dice agli oggetti fai fare quello che devi fare”); il messaggio “Bang” è associato molte volte a bottoni. I dati scambiati possono essere anche di tipo complesso come ad esempio array numerici o informazioni XML. La programmazione avviene collegando graficamente gli output di certi oggetti con gli input di altri (in modo da rispettare la compatibilità dei tipi di dato scambiati nei messaggi) fino ad arrivare ad oggetti il cui output è, ad esempio, la produzione di un suono, di un messaggio, di un video, ecc. I Phidgets si possono interfacciare con Max attraverso la creazione di un oggetto chiamato PhidgetInterfaceKit che permette ad esempio di leggere dei valori provenienti dai sensori e utilizzarli nel Patch. 2.2 Strumenti di supporto alla creazione di prodotti s ociali 18 Cap.2 – Lo stato dell’arte 2.2.1 Temboo Temboo 15 , sviluppato dall’omonima azienda di New York City (NY, USA), è una piattaforma che consente ai programmatori di utilizzare le API di oltre cento servizi, tra cui i principali social network. Esso si pone come un livello intermedio tra il programma e le API che si desiderano invocare, permettendo allo sviluppatore di lavorare ad un livello di astrazione superiore, rispetto a quanto avverrebbe se si dovesse interfacciare con ogni singolo servizio. Temboo è costituito dai cosiddetti Choreo, ognuno di essi formato da una porzione di codice riusabile, solitamente di 4-­‐5 righe, che compie una specifica funzione. Viene offerta una libreria di Choreo, suddivisi per i vari servizi. Un esempio di Choreo è il codice per pubblicare un messaggio su Facebook. Il programmatore sceglie il Choreo desiderato, inserisce i parametri necessari (ad esempio lo stato da pubblicare e il token di autenticazione), ottenendo da Temboo il codice pronto per essere integrato nel client, per uno dei linguaggi di programmazione supportati: Java, Python, PHP, Ruby, Node.js, Objective-­‐C per iOS, Arduino Yún16. È anche possibile ottenere il comando da invocare utilizzando cURL. L’architettura del programma risultante è quella mostrata in Fig. 2.4. 15
http://www.temboo.com 16
http://arduino.cc/en/Main/ArduinoBoardYun 19 Cap.2 – Lo stato dell’arte Programma client Temboo Choreo Faceboo
k API Twitter API Fig. 2.4 – Architettura di un programma client che utilizza Temboo per comunicare con le API di Facebook e Twitter I Choreo offerti non sono una semplice libreria di programmazione, in quanto parte dell’elaborazione avviene sui server di Temboo, che dunque è a sua volta un servizio utilizzabile tramite l’apposita API. Il vantaggio principale è la semplicità con la quale è possibile invocare un gran numero di API. Normalmente, infatti, il programmatore dovrebbe studiare la documentazione di ognuna di esse, trovare delle librerie per il linguaggio di programmazione che intende utilizzare e testarle, prima di poterle includere nel proprio programma. Con Temboo invece, è sufficiente inserire i parametri necessari e generare il codice per il linguaggio desiderato, inoltre è possibile testare l’invocazione di ogni singolo Choreo, e analizzare le risposte ricevute, all’interno dell’interfaccia web di Temboo. Lo svantaggio è che la versione gratuita permette di effettuare al massimo mille chiamate al mese. Di seguito è riportato il codice del Choreo per PHP che, dopo essersi autenticati con Temboo, permette di postare un messaggio su Facebook. Il token da inserire come parametro è quello ottenuto dopo aver effettuato l’autenticazione con Facebook tramite il protocollo oAUth, cosa che è possibile fare tramite l’apposito Choreo. 20 Cap.2 – Lo stato dell’arte // Instantiate the Choreo, using a previously instantiated Temboo_Session object,: $session = new Temboo_Session('APP_NAME', 'APP_KEY_NAME', 'APP_KEY_VALUE'); $post = new Facebook_Publishing_Post($session); // Get an input object for the Choreo $postInputs = $post-­‐>newInputs(); // Set inputs $postInputs-­‐>setAccessToken("ACCESS_TOKEN")-­‐>setMessage("MESSAGE"); // Execute Choreo and get results $postResults = $post-­‐>execute($postInputs)-­‐>getResults(); Come accennato, Temboo consente di ottenere il codice anche per Arduino Yún, una versione di Arduino con schede WiFi ed ethernet, composta da due processori che possono comunicare tra loro tramite un’apposita libreria: uno che controlla gli input e gli output, l’altro che esegue una distribuzione di Linux apposita. Yún integra le librerie necessarie per utilizzare i Choreo di Temboo, ed è quindi possibile integrare tutti i servizi offerti da essi all’interno del codice di controllo per Arduino scritto in Wiring, permettendo quindi di creare facilmente prodotti sociali a chi abbia una certa dimestichezza con la programmazione. 2.2.2 reaDIYmate reaDIYmate17, prodotto dall’azienda 23 de Enero di Parigi (Francia), permette di costruire oggetti di carta che si connettono alla rete tramite wi-­‐fi e modificano il proprio stato in base a quello che avviene su internet. Ad esempio emettere un suono e cambiare colore quando viene ricevuto un messaggio su Gmail. È anche possibile controllarli tramite un’applicazione per iPhone che sfrutta l’accelerometro. 17
http://www.readiymate.com 21 Cap.2 – Lo stato dell’arte L’utente può assemblare la carta ed i vari componenti elettronici per creare il proprio prodotto, utilizzando un’interfaccia web per configurare le azioni da compiere. La logica di controllo, così come la connessione ad internet, è gestita da una piattaforma hardware Arduino-­‐compatibile; è quindi possibile configurare comportamenti più complessi rispetto a quelli ottenibili tramite l’interfaccia, utilizzando l’IDE di Arduino ed il linguaggio Wiring. La maggior parte dei comportamenti configurabili con reaDIYmate riguardano attuatori, come LED, servo-­‐motori e speaker, i quali si attivano quando qualcosa accade su uno dei servizi internet supportati. Viene anche consentita la pubblicazione di contenuti in seguito alla pressione di un pulsante. 2.2.3 Sense.me Sense.me è un framework basato sul web che consente di creare prototipi che interagiscono con Facebook. È stato sviluppato da Alessandro Acerbis nel 2013, presso la TU Delft (Paesi Bassi) come lavoro di tesi di Laurea Magistrale in Ingegneria Informatica dell’Università degli Studi di Brescia [3]. 2.2.3.1 Un approccio basato sull’End-­‐User Development Sense.me è stato concepito sin dall’inizio come uno strumento che potesse aiutare gli studenti di Industrial Design a creare, e testare, prototipi che avessero comportamenti sociali, utilizzando Arduino, in modo semplice e intuitivo. Il designer infatti, desidera concentrarsi sul processo creativo e sullo studio dell’interazione utente-­‐prodotto, piuttosto che sulla scrittura del codice per Arduino, cosa che, per prototipi dal comportamento non banale, come sono quelli che devono interagire con i social network, risulta molto difficile, essendo necessaria una certa competenza con la programmazione. 22 Cap.2 – Lo stato dell’arte Gli strumenti sopra descritti non soddisfano queste esigenze: Temboo offre il codice per interagire con le API, semplificando questo aspetto, ma richiede comunque la scrittura di codice per gestire i comportamenti del prototipo; reaDIYmate consente di creare prototipi tramite un’interfaccia, in modo tuttavia piuttosto limitato, specialmente per quanto riguarda la pubblicazione di contenuti in seguito all’attivazione di sensori. Per queste ragioni è stato deciso di concepire Sense.me come uno strumento di End-­‐
User Development (EUD). L’EUD consente, mediante appositi strumenti, agli utenti finali di un prodotto software, che quindi non sono sviluppatori professionisti, di creare da zero, o modificare il comportamento, del software stesso. Questo approccio può portare alla riduzione dei tempi necessari alla creazione di un applicativo, infatti gli utenti finali sono i maggiori esperti del dominio nel quale operano, conoscendone i problemi e le necessità. Inoltre il prodotto finale dovrebbe essere più semplice da usare, essendo realizzato dall’utilizzatore stesso. Esistono varie tipologie di strumenti per l’End-­‐User Development, alcuni di esse sono: •
Fogli di calcolo: la tipologia più diffusa. Permettono di inserire e manipolare dati numerici, visualizzando immediatamente l’output, oppure di registrare o creare macro da zero. •
Programmazione visuale: la programmazione avviene mediante la manipolazione di oggetti grafici. Max/MSP, descritto precedentemente, ne è un esempio. •
Programmazione per esempi: l’utente inizialmente inserisce alcuni esempi di dati in ingresso e risultati desiderati, successivamente vengono inseriti dati differenti nel programma generato, correggendo eventuali output errati e raffinando così il programma. All’interno del dominio della creazione di prototipi fisici, il designer è l’utente finale, essendo il prototipo, per definizione, qualcosa che deve essere testato, e quindi utilizzato, dal progettista. 23 Cap.2 – Lo stato dell’arte Sense.me si pone come obiettivo quello di fornire un ambiente dove il designer possa, tramite un’interfaccia grafica intuitiva: 1. Creare un prototipo che all’attivazione di un sensore interagisca con Facebook. 2. Scaricare il codice per Arduino generato automaticamente. 3. Testare il corretto funzionamento del prototipo fisico creato. 2.2.3.2 Caratteristiche del sistema Il framework Sense.me si compone di tre parti, accessibili dopo che l’utente ha effettuato l’autenticazione con il sistema: 1. Creazione e configurazione del prototipo virtuale 2. Generazione del codice per Arduino 3. Uso del prototipo fisico Creazione e configurazione del prototipo virtuale L’utente può creare un prototipo virtuale, la controparte di quello fisico realizzato con Arduino, identificato da un nome univoco. Per ogni prototipo possono essere creati degli eventi, ognuno dei quali appresenta un’azione che l’utente può compiere con l’oggetto. Quando si verifica un evento, il prototipo può interagire con Facebook tramite uno o più dei seguenti comportamenti sociali: “Publish post”, “Show posts”, “Show photos”. L’utente dunque, associa, tramite drag-­‐and-­‐drop, uno o più di questi comportamenti all’evento, e li configura. La configurazione varia per ognuno di essi: nel caso della pubblicazione sarà necessario inserire il testo da pubblicare, nel caso si vogliano mostrare dei post occorrerà fornire le parole chiave per cercarli. In Fig. 2.5 viene mostrata la schermata dove è possibile creare gli eventi ed associare ad essi i comportamenti sociali. In questo caso il progettista ha già creato due eventi che rappresentano lo scuotimento (“shaking”) e lo schiacciamento (“squeezing”) del 24 Cap.2 – Lo stato dell’arte prototipo, Per effettuare l’associazione evento-­‐comportamento sociale è sufficiente trascinare il comportamento desiderato, prendendolo dall’elenco sulla destra, sotto il nome dell’evento. In questo caso, all’evento “shaking” è stato associato il comportamento “publish post”, mentre all’evento “squeezing” sono stati associati “show posts” e “publish post”. Fig. 2.5 -­‐ La configurazione degli eventi in Sense.me Generazione del codice per Arduino Dopo aver creato e configurato gli eventi, è necessario indicare quando attivarli. Per fare questo, ognuno di essi viene associato ad un sensore. L’utente ha a disposizione un elenco di sensori, suddivisi in analogici e digitali. I primi comprendono: fotoresistenza, sensore di pressione, sensore di temperatura, potenziometro lineare, potenziometro a giro. I secondi sono: tilt, bottone e sensore di tocco. A seconda della tipologia di sensore si inseriscono i parametri per attivare quello selezionato: nel caso sia analogico, la soglia di attivazione, compresa tra 0 e 1023, e se il valore rilevato deve essere maggiore o minore di questa soglia; nel caso sia 25 Cap.2 – Lo stato dell’arte digitale se esso debba essere attivato quando in ingresso riceve il valore LOW oppure HIGH. In entrambi i casi deve essere anche indicato il numero del pin di ingresso al quale il sensore è collegato. Dopo aver associato un sensore ad ogni evento, è possibile generare e scaricare il codice per Arduino. Il file scaricato è in formato .ino, quindi l’utente può aprirlo con l’IDE di Arduino e caricarlo sulla scheda premendo l’apposito pulsante. Il codice è già pronto, quindi non richiede interventi da parte dell’utente, tuttavia un esperto può usarlo come punto di partenza e modificarlo, essendo ben commentato. Uso del prototipo fisico In questa fase l’utente ha già caricato il codice su Arduino, e si presume abbia collegato correttamente i sensori al microcontrollore. Per testare il corretto funzionamento del prototipo, il designer può accedere all’apposita area di Sense.me, all’interno della quale deve autenticarsi con Facebook e scaricare l’applicazione Java che permette ad Arduino di connettersi a Internet. L’autenticazione avviene tramite il protocollo oAuth, durante il quale l’utente autorizza l’applicazione Sense.me, registrata su Facebook, a pubblicare sul proprio profilo con il proprio nome. L’utilizzo di questo protocollo evita di dover fornire le proprie credenziali a Sense.me, e a questa di doverle gestire. L’applicazione Java da scaricare ed eseguire sul computer al quale è collegato Arduino, rende possibile realizzare il prototipo con qualsiasi versione del microprocessore, non solo con quelle che integrano la scheda ethernet o wi-­‐fi, che non sarebbero comunque utilizzabili all’interno del TU Delft, in quanto non in grado di gestire l’autenticazione 802.1X18 richiesta per la connessione alla rete. Arduino, quando rileva un evento, scrive una stringa, con un certo formato, sulla porta seriale, indicando il nome del prototipo e dell’evento che si è verificato. 18
IEEE 802.1X-­‐2010, http://standards.ieee.org/findstds/standard/802.1X-­‐2010.html 26 Cap.2 – Lo stato dell’arte L’applicazione legge la porta seriale, e quando rileva una stringa corrispondente al formato atteso, sfruttando la connessione ad Internet del pc, comunica ad un server l’evento che si è verificato, ed il prototipo corrispondente. Il server si interfaccia con le API di Facebook, per eseguire le azioni corrispondenti all’evento che si è verificato, inoltre comunica alla pagina di test, alla quale è collegato l’utente, l’avvento dell’evento e le operazioni che sta svolgendo con Facebook, in modo che questo possa capire se il prototipo sta funzionando correttamente. L’architettura complessiva del sistema è indicata in figura 2.6 [3]. 27 Cap.2 – Lo stato dell’arte Fig. 2.6 -­‐ Architettura di Sense.me 28 Cap.3 – Analisi e specifica dei requisiti Capitolo 3: Analisi e specifica dei requisiti In questo capitolo viene descritta l’analisi compiuta sulla prima versione di Sense.me, e di come questa abbia portato alla specifica dei requisiti per la seconda versione del framework. 3.1 A nalisi d i S ense.me L’obiettivo del lavoro di tesi è stato quello di proseguire lo sviluppo di Sense.me, descritto nel paragrafo 2.2.3. A tal fine, per prima cosa è stato studiato con attenzione il framework. Inizialmente il sistema è stato utilizzato simulando l’attività di un designer: sono stati creati prototipi con Arduino e le corrispondenti controparti virtuali, verificando che il codice generato funzionasse correttamente. L’obiettivo di questa fase era quello di diventare utenti esperti del software. Una volta acquisita una certa dimestichezza, in fase di utilizzo dell’applicazione è stata effettuata anche un’attività di debug, verificando il corretto comportamento degli elementi dell’interfaccia e la reazione del sistema ad input imprevisti. Successivamente si è passati all’analisi del codice sorgente, comprendendone l’organizzazione, ed analizzando passo-­‐passo, all’interno del codice, le attività principali che l’utente può compiere con il sistema. Durante questa fase, per la quale ci si è anche avvalsi della documentazione fornita in [3], è stata compresa più a fondo l’architettura di Sense.me. 3.1.1 Analisi dei test con gli utenti 29 Cap.3 – Analisi e specifica dei requisiti Dopo essere diventati esperti del framework, si è iniziato a lavorare alla progettazione della seconda versione di Sense.me. Per prima cosa sono stati analizzati i test con gli utenti svolti dopo l’implementazione della prima versione, in modo da comprendere come questa fosse stata accolta dagli studenti di Industrial Design, e quali fossero i loro commenti e aspettative. L’obiettivo della valutazione era, non solo analizzare l’usabilità dell’applicazione, ma anche capire come questa si integrasse nel normale processo di design. Per questo motivo il test era stato presentato come un “ideation workshop”. In pratica, dopo aver diviso i partecipanti in gruppi di due o tre persone, era stato chiesto loro di svolgere le seguenti attività: 1. Insieme agli altri membri del gruppo, creare un prototipo fisico che interagisse con Facebook, basandosi su uno scenario proposto. 2. Individualmente, realizzare il prototipo virtuale tramite Sense.me e testarne il corretto funzionamento. 3. Compilare un questionario di valutazione. Le caratteristiche degli utenti volontari che hanno partecipato all’esperimento, tutti studenti di Industrial Design a Delft, sono le seguenti: •
Sesso: 5 femmine e 3 maschi. •
Fascia di età: 23-­‐30. •
Corso di laurea: 4 DFI, 3 SPD, 1 IPD. •
Esperienza nella programmazione di Arduino: 4 sì, 4 no. Durante la prima attività, nella quale i membri del gruppo, lavorando insieme, dovevano progettare un prototipo che interagisse con Facebook, partendo da uno scenario fornito, lo sperimentatore è sempre stato presente per rispondere ad eventuali domande ed evitare che venisse realizzato un prototipo fisico non implementabile con Sense.me. In questo modo è stato possibile raccogliere osservazioni su come il framework si integrasse con l’attività di design. 30 Cap.3 – Analisi e specifica dei requisiti Durante la seconda attività, nella quale gli utenti dovevano utilizzare autonomamente il sistema, è stato utilizzato il protocollo think aloud [4], chiedendo ai partecipanti di commentare ad alta voce le azioni svolte. I commenti, insieme alla schermata del pc sul quale è stato svolto l’esperimento, sono stati registrati. In questa fase è stato possibile individuare alcuni problemi di usabilità del sistema. Il questionario finale investigava se Sense.me facilitasse la creazione di prototipi sociali, come si integrasse con il processo creativo dei designer, i benefici ed i limiti percepiti e quali comportamenti sociali fossero ritenuti utili da aggiungere in futuro. I risultati raccolti sono stati suddivisi in due categorie: 1. Problemi di usabilità 2. Integrazione del framework nell’attività di design I problemi di usabilità più gravi sono stati risolti nei giorni successivi al test, venendo quindi inclusi nella prima versione. Per motivi di tempo non è stato possibile risolvere anche quelli minori. Per quanto riguarda l’integrazione del sistema all’interno dell’attività di design, gli utenti hanno riscontrato le seguenti limitazioni: •
L’interazione è vincolata ai comportamenti sociali messi a disposizione. •
L’interazione è vincolata ai sensori messi a disposizione. •
L’interazione è vincolata al tipo di configurazione dei sensori: è infatti possibile utilizzarli solamente come semplici trigger, che si attivano se i valori sono superiori o inferiori a una certa soglia (per quelli analogici) o corrispondenti ai valori LOW/HIGH (per quelli digitali). •
Ogni evento può essere attivato da un solo sensore; questo non permette di scatenare eventi in corrispondenza di una loro combinazione (ad esempio più sensori in AND), o di configurare comportamenti particolari, come ad esempio temporizzare gli eventi. •
È possibile pubblicare solo del testo predefinito. 31 Cap.3 – Analisi e specifica dei requisiti Nonostante le limitazioni riscontrate, tutte imputabili alla natura prototipale della prima versione di Sense.me, gli studenti hanno in larga parte apprezzato il framework, ritenendolo uno strumento potente e di grande aiuto, soprattutto se ampliato con ulteriori funzionalità. 3.2 S pecifica d ei r equisiti L’analisi descritta nella sezione precedente ha portato alla stesura di un elenco di proposte di modifica per Sense.me. Esse sono: 1. Aggiunta di nuovi social network e nuovi comportamenti sociali. 2. Attivazione di un evento utilizzando più sensori in AND e OR logici tra loro, tramite un’interfaccia adeguata. 3. Modifica della configurazione dei singoli sensori: possibilità di stabilire quante volte il singolo sensore debba rispettare la sua condizione (maggiore o minore di una certa soglia se analogico, uguale a LOW o HIGH se digitale) per essere attivato. 4. Aggiunta di nuovi sensori al sistema. 5. Utilizzo dei dati raccolti dai sensori per la pubblicazione di contenuti. 6. Semplificazione dell’architettura per quanto riguarda la fase di testing del prototipo. 7. Risoluzione dei problemi di usabilità ancora presenti. Queste modifiche sono state analizzate e discusse con il relatore ed il correlatore della tesi, decidendo di ordinarle in base alla loro priorità, in modo da effettuare le modifiche più importanti senza rischiare di essere limitati da vincoli temporali, secondo il classico modello di sviluppo a spirale [5]. Si è dunque deciso di implementare immediatamente i punti 1, 2, 3, 7. I punti 4 e 6 sono stati realizzati successivamente, mentre il 5 è stato accantonato, dato che realizzando il punto 2, un evento può essere attivato da più sensori, e 32 Cap.3 – Analisi e specifica dei requisiti quindi decidere quali dati utilizzare nella pubblicazione, e come eventualmente combinarli tra loro, sarebbe troppo complesso e andrebbe in conflitto con la volontà di mantenere il framework il più semplice ed intuitivo possibile. Inoltre i sensori rilevano un valore numerico tra 0 e 1023, che per un essere umano ha un significato solo se convertito in una misura significativa per il dominio in questione, ad esempio in gradi centigradi nel caso di un sensore di temperatura. Non conoscendo a priori le caratteristiche del sensore usato dal designer, sarebbe impossibile effettuare una conversione automatica senza chiedere informazioni dettagliate all’utente, visto che, anche per la stessa tipologia di sensore, lo stesso valore di input può portare informazioni diverse (ad esempio le temperature massima e minima misurabili da un sensore di temperatura possono variare da sensore a sensore). Durante la fase di riprogettazione del sistema, le modifiche architetturali apportate all’area di test, hanno portato alla possibilità di realizzare il prototipo anche con schede Arduino in grado di connettersi ad internet autonomamente, evitando di utilizzare l’applicazione Java. Per questo motivo è stata introdotta la possibilità per l’utente di indicare quale tipo di Arduino si intende utilizzare, anche se questo non era previsto nelle modifiche proposte inizialmente. 3.2.1 Requisiti funzionali Per comprendere come le modifiche sopra descritte si integrano in Sense.me, vengono ora descritti i requisiti della seconda versione del framework. Il designer, dopo essersi registrato al sistema, fornendo un nome, un indirizzo email e la password, effettua il login. Una volta autenticato può modificare i propri dati personali e gestire i propri prototipi. È anche possibile ricevere tramite posta elettronica una nuova password, nel caso si sia dimenticata la propria. 33 Cap.3 – Analisi e specifica dei requisiti Un prototipo virtuale, che rappresenta la controparte di quello fisico creato con Arduino, viene creato indicandone il nome e la tipologia di microprocessore utilizzata, scegliendo tra: •
Arduino senza connessione a Internet; •
Arduino con ethernet shield: in questo caso viene richiesto il MAC della scheda ethernet; •
Arduino con WiFi shield: in questo viene richiesto il nome della rete wi-­‐fi al quale il prototipo si connetterà, la tipologia di protezione (nessuna, WEP, WPA, WPA2), e la chiave di rete nel caso sia necessaria; •
Arduino Yún: non sono necessari dati di configurazione, dato che in questo tipo di scheda, introdotta nel paragrafo 2.2.1, la connessione a internet è gestita dal processore con sistema operativo Linux. La tipologia di microprocessore utilizzato influirà solo sul codice generato e sulla fase test. Per ogni prototipo è possibile effettuare le seguenti operazioni: •
Aggiungere eventi al prototipo. •
Aggiungere e configurare i comportamenti sociali da eseguire quando si verifica l’evento. •
Aggiungere e configurare i sensori che scatenano l’evento. •
Scaricare il codice per il prototipo fisico realizzato con Arduino. •
Testare il funzionamento del prototipo fisico. •
Modificare la tipologia di Arduino utilizzato per il prototipo fisico. •
Eliminare il prototipo. L’aggiunta di un evento avviene semplicemente indicandone il nome. I comportamenti sociali che possono essere aggiunti ad un evento sono mostrati in una lista, raggruppati per social network di appartenenza. L’utente può associarli all’evento tramite drag-­‐and-­‐drop. Dopo l’associazione è necessario configurare il comportamento sociale. Le informazioni richieste variano in base alla sua tipologia, 34 Cap.3 – Analisi e specifica dei requisiti in generale sono i parametri necessari per invocare la corrispondente API, con l’eccezione dei dati per l’autenticazione, che vengono raccolti durante la fase di test. I sensori disponibili sono elencati anch’essi in una lista, suddivisi tra analogici e digitali. Per ognuno di essi è possibile visualizzarne una breve descrizione. L’associazione ad un evento avviene tramite drag-­‐and-­‐drop. Ogni evento può essere attivato da più sensori, che sono in AND/OR logico tra di loro. La relazione logica tra i vari sensori viene creata tramite un’interfaccia opportuna. Ogni sensore deve poi essere configurato. Le informazioni richieste per i sensori analogici sono: •
Il pin analogico di input su Arduino. •
Il valore di soglia, compreso tra 0 e 1023. •
Se il valore rilevato dal sensore deve essere maggiore o minore del valore di soglia. •
Il numero di volte che il valore rilevato deve essere minore o maggiore della soglia, per attivare il sensore. Le informazioni richieste per i sensori digitali: •
Il pin digitale di input su Arduino. •
Se il valore rilevato dal sensore deve essere LOW o HIGH. •
Il numero di volte che il valore rilevato deve essere uguale a LOW o HIGH, per attivare il sensore. Dopo aver configurato tutti i comportamenti sociali ed i sensori aggiunti agli aventi, è possibile scaricare il file generato da Sense.me contenente il codice per Arduino. Esso è nel formato leggibile dall’IDE ufficiale, quindi il designer può aprirlo e caricarlo sulla scheda utilizzando quest’ultimo. Per testare il corretto funzionamento del prototipo si accede ad una pagina apposita del framework. Se la tipologia di Arduino utilizzata è quella senza connessione Internet, è necessario collegare il microcontrollore al pc, tramite USB, ed utilizzare l’applicazione Java che legge i messaggi scritti dalla scheda sulla porta USB e li invia 35 Cap.3 – Analisi e specifica dei requisiti al server che si occupa di interfacciarsi con le API, sfruttando la connessione del computer. Per questo viene proposto all’utente di scaricare l’applicazione Java. Il funzionamento è dunque del tutto analogo a quello della prima versione di Sense.me descritto nel paragrafo 2.2.3. Se si utilizzano le altre tipologie di Arduino, questa fase non è necessaria, in quanto la scheda è in grado di contattare il server autonomamente. In tutti i casi l’utente deve autenticarsi con i social network utilizzati dal prototipo, in modo da ottenere il token di autenticazione che sarà utilizzato per comunicare con l’API. La pagina mostra anche il log del prototipo, nel quale il designer può visualizzare quando si attiva un evento sul prototipo, le azioni che ne conseguono ed i loro risultati. Durante la fase di registrazione al sistema, è possibile iscriversi utilizzando un’email della TU Delft. In questo caso viene inviato un messaggio di posta elettronica di conferma, con un link per attivare l’account. Una volta effettuato questo passaggio, l’utente viene riconosciuto dal sistema come un designer della TU Delft. Questa tipologia di utente oltre a poter compiere tutte le azioni descritte, ha la possibilità di aggiungere sensori al sistema, che quindi saranno visualizzati da tutti gli utenti. Per ogni sensore è necessario fornire: •
Nome •
Breve descrizione •
Tipologia: analogico o digitale 3.2.1.1 Diagramma dei casi d’uso La fig. 3.1 mostra il diagramma dei casi d’uso relativo ai requisiti appena descritti. 36 Cap.3 – Analisi e specifica dei requisiti Fig. 2.1 -­‐ Diagramma dei casi d'uso di Sense.me 2.0 37 Cap.4 – Riprogettazione del sistema Capitolo 4: Riprogettazione del sistema In questo capitolo viene descritto come sono state riprogettate l’architettura e la base di dati di Sense.me, in modo da poter soddisfare i nuovi requisiti. 4.1 R iprogettazione d ell’architettura I requisiti descritti nel capitolo precedente hanno portato a riconsiderare l’architettura di Sense.me. In una visione ad alto livello, come quella mostrata in fig. 4.1, essa non cambia da quella della prima versione, ad eccezione del fatto che il prototipo fisico, se realizzato con un Arduino con connessione a internet, può interagire direttamente con il server durante la fase di test, senza intermediazione dell’applicazione Java. Il framework è composto da tre aree: •
Creazione del prototipo: consente all’utente di creare il prototipo virtuale e associarvi gli eventi, configurandone i relativi comportamenti sociali e sensori. •
Generazione del codice: permette al designer di scaricare il file contenente il codice per Arduino relativo al prototipo configurato. •
Test del prototipo: gestisce l’autenticazione con i social network, riceve messaggi dal prototipo fisico quando accadono degli eventi su di esso, si interfaccia con le API per compiere le azioni previste e tiene informato l’utente su cosa sta accadendo. Il funzionamento di queste tre aree, descritto nei prossimi paragrafi, ha subito modifiche, anche significative, rispetto alla prima versione. Tutte e tre hanno accesso alla stessa base di dati, che contiene le informazioni inserite dall’utente. 38 Cap.4 – Riprogettazione del sistema Prototipo fisico File Arduino HTTP Applicazione JAVA HTTP Creazione prototipo Generazione codice Test prototipo Database Fig.4.1 -­‐ L'architettura complessiva del sistema 4.1.1 Creazione del prototipo Durante la fase di creazione del prototipo, il designer, dopo essersi autenticato al sistema, configura completamente la controparte virtuale del prodotto che sta progettando. Rispetto alla prima versione, per creare un nuovo prototipo non è più sufficiente indicarne il nome, ma è anche necessario selezionare la tipologia di Arduino impiegata, scegliendo tra “Arduino senza internet”, “Arduino con ethernet shield”, “Arduino con WiFi shield” e “Arduino Yún”, inserendo le relative informazioni di configurazione dove necessario. La tipologia di microcontrollore influirà le fasi di generazione del codice e di test. 39 Cap.4 – Riprogettazione del sistema Per ogni prototipo è possibile aggiungere degli eventi, che rappresentano qualcosa che accade su di esso. Ognuno è creato indicandone un nome. In questa fase è anche possibile aggiungere ad ogni evento i comportamenti sociali che esso deve scatenare. Per fare questo, per prima cosa l’utente seleziona il social network desiderato, ottenendo la lista dei relativi comportamenti sociali, che può poi selezionare e aggiungere all’evento desiderato tramite drag-­‐and-­‐drop. Dopo l’aggiunta, i comportamenti devono essere configurati, indicando le informazioni necessarie, che variano in base alla loro natura (ad es. il testo nel caso della creazione di un post, le parole chiave se si desidera ottenere dei tweet). L’interazione appena descritta è illustrata in fig. 4.2. 40 Cap.4 – Riprogettazione del sistema Fig. 4.2 – Aggiunta degli eventi al prototipo, associazione e configurazione dei comportamenti sociali. Successivamente è necessario configurare i sensori che attivano ogni evento. Rispetto alla prima versione, è possibile utilizzare più sensori in AND e OR logico tra di loro. L’utente, tramite drag-­‐and-­‐drop, associa il sensore desiderato all’evento. L’interfaccia, come sarà illustrato nel prossimo capitolo, consente di creare la configurazione logica a seconda della posizione in cui viene rilasciato il sensore. Ogni sensore deve essere configurato. Le informazioni richieste variano a seconda che esso sia analogico o digitale, come descritto nel paragrafo 3.2.1. Rispetto alla 41 Cap.4 – Riprogettazione del sistema prima versione è possibile indicare quante volte esso debba raggiungere la propria condizione per essere attivato. Se l’utente configura due sensori con lo stesso pin di input, significa che questi rappresentano lo stesso sensore fisico. Per questo motivo il sistema, prima di inserire una nuova configurazione nel database, effettua un controllo di compatibilità tra i sensori di tutti gli eventi: •
Se due sensori hanno lo stesso pin di input, ma sono due tipologie di sensore diverse, è un errore. •
Se due sensori hanno lo stesso pin di input, sono la stessa tipologia di sensore e sono in AND logico tra loro, è un errore. Il diagramma di sequenza per l’aggiunta e la configurazione dei sensori, è mostrato in fig. 4.3. 42 Cap.4 – Riprogettazione del sistema Fig. 4.3 – Aggiunta e configurazione dei sensori agli eventi Come descritto nel paragrafo 3.2.1, esistono due tipologie di utenti: il designer e il designer della TU Delft, che si è registrato al sistema utilizzando, e verificando, un indirizzo email dell’università. Questa tipologia di utente, oltre a poter effettuare le operazioni descritte, ha la possibilità di aggiungere sensori a Sense.me. Per farlo, esso accede ad un’interfaccia dedicata, dove viene richiesto di inserire il nome del sensore, la sua tipologia ed una breve descrizione. Dopo di che, tale tipologia di sensore verrà resa disponibile, in Sense.me, a tutti i designer. 43 Cap.4 – Riprogettazione del sistema 4.1.2 Generazione del codice Dopo aver configurato il prototipo, il designer può ottenere il codice per Arduino pronto per essere caricato sulla controparte fisica. Per prima cosa il sistema controlla se sono rispettate le seguenti condizioni: •
Esiste almeno un evento •
Per ogni evento esiste almeno un comportamento sociale •
Ogni comportamento sociale è configurato •
Per ogni evento esiste almeno un sensore •
Ogni sensore è configurato Successivamente si entra nella fase di generazione del codice, che è creato basandosi sulle informazioni contenute nella base di dati, come sarà illustrato in dettaglio nel prossimo capitolo. L’output di questa fase è il file, in formato leggibile dall’IDE di Arduino, che viene scaricato sul pc del designer, il quale potrà caricarlo sul prototipo fisico, in modo da poterlo testare. Il diagramma di sequenza relativo a questa fase, è mostrato in fig. 4.4. 44 Cap.4 – Riprogettazione del sistema Fig. 4.4 – Generazione del codice per Arduino 4.1.3 Test del prototipo La fase di test è quella che ha subito il maggior numero di modifiche. Nella prima versione, la cui architettura è mostrata in fig. 4.5 ed il diagramma di sequenza in fig. 4.6, l’utente accede, tramite browser, alla pagina di test, dove effettua l’autenticazione oAuth con Facebook, oltre che connettersi al server Node.js tramite protocollo web socket, aprendo così un canale bidirezionale per ricevere aggiornamenti sullo stato del prototipo. 45 Cap.4 – Riprogettazione del sistema Arduino, quando rileva un evento, lo scrive sulla porta seriale, letta dall’applicazione Java, che si occupa di comunicarlo, tramite HTTP, ad Updater, script PHP risiedente su un server Apache. Updater legge dal database i comportamenti che l’evento deve generare, e si interfaccia con le API di Facebook per compiere le azioni richieste. Quando Updater riceve notizia che si è verificato l’evento, inizia la comunicazione con ogni API, e riceve risposta da essa, notificando il tutto, tramite protocollo Web Socket, ad un server Node.js che si occupa di inviare la notifica, sempre tramite Web Socket, al browser, in modo che l’utente possa restare aggiornato su cosa stia accadendo. Prototipo fisico USB Applicazione Java HTTP HTTP Database WebSocket Server Apache (Updater + Test) Web socket Server Node.js Applicazione Sense.me (client) HTTP Fig. 4.5 – L’architettura della fase di test nella prima versione di Sense.me 46 Cap.4 – Riprogettazione del sistema Fig. 4.6 – Diagramma di sequenza della fase di test nella prima versione di Sense.me Si può notare come l’architettura della prima versione sia complessa e poco scalabile: entrano in gioco due server e l’interazione avviene in modo specifico solo con le API di Facebook. Per questo motivo si è studiato come semplificarla. Inizialmente è stato considerato l’interfacciamento con le API. Dato che si sarebbero aggiunti altri social network al sistema, è stata considerata l’ipotesi di utilizzare una libreria specifica per ognuno di essi. Questa soluzione tuttavia è poco scalabile e porterebbe ad avere un codice difficile da manutenere, visto che si utilizzerebbero librerie diverse, con logiche di funzionamento diverse tra loro, ognuna da testare in 47 Cap.4 – Riprogettazione del sistema maniera differente. Inoltre renderebbe più difficile l’aggiunta futura di comportamenti sociali. Per queste ragioni è stato deciso di utilizzare Temboo, descritto nel paragrafo 2.2.1, il quale offre una libreria, ed un’API, attraverso le quali è possibile comunicare con un gran numero di social network, utilizzando un’interfaccia simile. Tra i linguaggi supportati da Temboo, compare Arduino Yún. È stata dunque analizzata la possibilità di far scegliere al designer, in fase di creazione del prototipo, se utilizzare Yún oppure un altro tipo di Arduino. Nel secondo caso l’architettura sarebbe rimasta identica alla prima versione, a parte il fatto che Updater si sarebbe interfacciato con Temboo invece che con Facebook; nel primo caso invece, sarebbe stato possibile per il microprocessore comunicare direttamente con le API, evitando così di coinvolgere il server Apache ed il database, utilizzando il server Node.js solo come notificatore. Il token per l’autenticazione sarebbe stato ottenuto in fase di configurazione dei comportamenti sociali, e sarebbe stato integrato nel codice generato. L’architettura risultante per Arduino Yún, ed il relativo diagramma di sequenza, sono mostrate in fig. 4.7 e 4.8. Web socket HTTP HTTP Server Node.js Applicazione Sense.me (client) Fig. 4.7 -­‐ L’architettura proposta per la fase di test usando Arduino Yún 48 Cap.4 – Riprogettazione del sistema Fig. 4.8 – Il diagramma di sequenza dell’architettura proposta per la fase di test usando Arduino Yún Nonostante la semplificazione apportata all’architettura, quando si utilizza Arduino Yún, questa soluzione presenta alcuni problemi: •
Staticità: una volta generato il codice, non è possibile aggiungere o modificare comportamenti sociali al prototipo, dato che tutte le informazioni sono contenute all’interno del file scaricato. Nella soluzione precedente invece, le informazioni sulle azioni da compiere sono estratte dal database nel momento in cui avviene l’evento, cosa che permette di modificarle anche dopo la generazione. •
Sicurezza: gli access token per autenticarsi con i social network sono visibili all’interno del codice. Nonostante l’utilizzatore finale sia il designer, che è anche colui che si autentica, avere questi dati scritti in chiaro su un file invece che all’interno della base di dati comporta una sicurezza minore. Per queste ragioni, si è deciso di utilizzare come soluzione finale l’architettura mostrata in fig. 4.9. Sfruttando il fatto che Temboo ne supporta il linguaggio, si è mantenuto solo il server Node.js, che non agisce più come semplice notificatore, ma 49 Cap.4 – Riprogettazione del sistema si occupa anche di interfacciarsi con le API e con il database, prendendo il posto del server Apache. Il fatto che si occupi di tutto il server, che si attiva quando riceve notifica che un evento è accaduto, fa sì che sia indifferente quale tipologia di Arduino si utilizzi per realizzare il prototipo. Per questo motivo si è deciso di dare all’utente la possibilità di scegliere la scheda utilizzata, così come descritto nel paragrafo 3.2.1. Se si utilizza un microcontrollore in grado di connettersi a internet, esso può comunicare direttamente col server, in caso contrario sarà ancora necessario utilizzare l’applicazione Java. Applicazione Sense.me (client) Fig. 4.9 -­‐ L'architettura finale della fase di test in Sense.me 2.0 (l’applicazione Java è utilizzata solo nel caso di Arduino senza connessione ad internet) Il funzionamento è mostrato nel diagramma di sequenza in fig. 4.10. Quando l’utente accede alla pagina di test, essa instaura una connessione tramite web socket con il server, in modo da poter essere aggiornata sugli eventi che accadono al prototipo, ed effettua l’autenticazione con tutti i social network coinvolti tramite il protocollo oAuth, utilizzando Temboo. Gli access token ottenuti sono memorizzati all’interno del database. 50 Cap.4 – Riprogettazione del sistema Quando un evento accade su Arduino, questo lo comunica al server tramite un messaggio HTTP, eventualmente tramite la mediazione dell’applicazione Java, in caso di schede non in grado di connettersi a internet. Il server notifica alla pagina di test l’avvento dell’evento, ed estrae dal database le informazioni sulle azioni da compiere ed i relativi token per l’autenticazione. Una volta ottenute, invoca le API necessarie, utilizzando Temboo, notificando il fatto all’utente, al quale sono anche mostrate le risposte ottenute, dopo un opportuno filtraggio. I vantaggi di questa architettura sono: •
Possibilità di usare tutte le tipologie di Arduino. •
Possibilità di testare il prototipo senza dover utilizzare un pc di supporto, nel caso si utilizzi un Arduino con connessione ad internet. •
Possibilità di aggiungere e modificare i comportamenti sociali eseguiti quando si verifica un evento, anche dopo aver caricato il codice sul prototipo. •
Possibilità di utilizzare un gran numero di API, grazie a Temboo. •
Possibilità di aggiungere facilmente nuovi social network e nuovi comportamenti sociali al sistema, dato che si ha a disposizione un’interfaccia uniforme per invocare le API. 51 Cap.4 – Riprogettazione del sistema Fig. 4.10 -­‐ Il diagramma di sequenza finale per la fase di test di Sense.me 2.0 4.2 R iprogettazione d ello s chema d ei d ati In seguito alle modifiche architetturali discusse nel paragrafo precedente, è stato necessario riprogettare il database. Il diagramma E-­‐R [6] risultante è mostrato in fig. 4.11 e fig. 4.12. Le due immagini si collegano tramite l’entità Event. 52 Cap.4 – Riprogettazione del sistema Fig. 4.11 – Diagramma E-­‐R della base di dati, parte 1 Fig. 4.12 – Diagramma E-­‐R della base di dati, parte 1 53 Cap.4 – Riprogettazione del sistema Rispetto alla prima versione, l’entità Prototype è una generalizzazione parziale di PrototypeEthernet e PrototypeWifi, che hanno come attributi i parametri richiesti dalle corrispettive tipologie di Arduino. I prototipi realizzati con una scheda senza connessione ad internet o con Yún, sono rappresentati all’interno dell’entità padre. Designer può specializzarsi in DesignerTU, la quale ha come attributo randomNumber, utilizzato per la fase di attivazione dell’account. SensorSetting, che contiene tutti i sensori aggiunti agli eventi, costituisce una generalizzazione totale esclusiva di Analog e Digital, e si collega, tramite la relazione specifies, a Sensor, che memorizza l’elenco dei sensori disponibili in Sense.me. Dato che sono presenti svariati social network, ognuno con un proprio elenco di comportamenti sociali, è stata aggiunta l’entità SocialNetwork, collegandola a Behaviour tramite la relazione belongs. Le entità figlie di Setting, che raccolgono le impostazioni dei comportamenti sociali associati agli eventi, sono state riprogettate, in modo da includere tutte le tipologie necessarie. In particolare: •
SettingEmail: rappresenta le impostazioni per i comportamenti sociali che permettono di inviare un messaggio di posta elettronica. •
SettingEvent: rappresenta le impostazioni per i comportamenti sociali riguardanti gli eventi, come quelli che interagiscono con Google Calendar o Facebook eventi. •
SettingIdElement: contiene tutti i settaggi per i comportamenti che si riferiscono ad un id, come ad esempio il checkin in qualche località su Foursquare o Facebook. •
SettingShow: contiene le impostazioni per i comportamenti che consentono di mostrare post o immagini. Nel caso siano coinvolte parole chiave, è collegata all’entità Keywords, tramite la relazione match. La generalizzazione è parziale, dato che le impostazioni per alcune tipologie di comportamenti, come ad esempio quelli per la pubblicazione di un post, sono incluse nell’entità padre. 54 Cap.5 – Implementazione del sistema Capitolo 5: Implementazione del sistema In questo capitolo viene descritto come sono state implementate le modifiche principali apportate al sistema. 5.1 I nterfaccia p er l ’associazione d ei s ensori Come descritto nei capitoli precedenti, una delle modifiche principali introdotte nella seconda versione di Sense.me è la possibilità di attivare un evento utilizzando più sensori in AND e OR logico tra loro. Il problema affrontato è stato quello di creare un’interfaccia che permettesse di combinare tra loro i sensori, mantenendo la semplicità e l’immediatezza tipica del framework. La soluzione adottata è un compromesso tra semplicità e completezza. Per associare i sensori agli eventi si utilizza il drag-­‐and-­‐drop: si trascina quello desiderato, prendendolo da una lista posta sulla destra, e lo si rilascia in un’apposita area sotto il nome dell’evento, in modo simile a quanto accadeva, nella prima versione, per i comportamenti sociali. I sensori associati a un evento vengono ora rappresentati da blocchi rettangolari, eventualmente posti in linee consecutive. I blocchi sulla stessa linea sono in AND logico tra loro, mentre ogni linea è in OR logico con le altre. L’utente dunque, rilascia il sensore sulla linea desiderata, in base alla configurazione che vuole creare. I sensori associati all’evento vengono identificati dal loro nome e da un numero. Quest’ultimo serve ad aiutare il loro riconoscimento: se due sensori con la stessa tipologia sono collegati allo stesso pin di input, significa che rappresentano lo stesso sensore fisico, avranno quindi lo stesso nome e numero; se invece due sensori con lo stesso nome rappresentano due sensori fisici diversi, avranno due numeri differenti (ad esempio, in fig. 5.1, sotto l’evento isMorning sono presenti due Button-­‐1, che 55 Cap.5 – Implementazione del sistema quindi rappresentano lo stesso bottone fisico, mentre Force-­‐1 e Force-­‐2 rappresentano due sensori di forza diversi). Per aiutare il designer a comprendere la configurazione, viene anche mostrata la formula logica corrispondente, aggiornata ogni volta che si aggiunge un nuovo sensore. In fig. 5.1 è mostrato uno screenshot dell’interfaccia appena descritta, in cui si possono vedere i blocchi che rappresentano i sensori, con la relativa formula logica, e la lista dei sensori disponibili, suddivisa in analogici e digitali. Fig. 5.1 – Interfaccia per l’associazione dei sensori Questa soluzione, sebbene non consenta di ottenere formule logiche complesse, permette ai designer, che solitamente hanno poche conoscenze di logica, di attivare un evento, utilizzando più sensori, in maniera semplice. Inoltre, come confermato durante dialoghi informali con studenti della TU Delft e un assistente ad un corso nel quale viene insegnato ad utilizzare Arduino, nella maggior parte dei prototipi vengono utilizzati pochi sensori, con una configurazione abbastanza semplice (ad esempio due o tre sensori in AND tra loro). Per realizzare questa interfaccia sono state utilizzate le librerie per JavaScript, JQuery19 e Livequery20. 19
http://jquery.com 20
http://plugins.jquery.com/livequery 56 Cap.5 – Implementazione del sistema Il codice riportato nel listato 5.1, mostra un estratto della funzione che gestisce l’associazione dei sensori all’evento. Livequery, utilizzata per gestire il drag-­‐and-­‐drop, viene applicata all’elemento HTML di classe sensorCollector, lo spazio dove si rilasciano i sensori. Viene inoltre dichiarato che all’interno di quest’area vengono accettati gli elementi HTML di classe sensor-­‐draggable, che sono i sensori presenti nella lista. Quando un sensore viene rilasciato, vengono estratti da appositi attributi all’interno dei tag HTML che lo compongono, informazioni quali l’id del sensore e della riga sulla quale è stato rilasciato. Queste sono passate come parametri allo script PHP 21 , invocato tramite AJAX [7], che si occupa di inserire la configurazione del sensore all’interno del database. Lo script ritorna l’id della tupla appena inserita, informazione che viene memorizzata in un attributo all’interno della struttura HTML rappresentante il sensore. Dopo l’inserimento, il sensore deve essere configurato, fornendo le informazioni descritte nei requisiti. Cliccando sull’apposito ingranaggio accanto al nome del sensore (come si può visualizzare in fig. 5.1), viene effettuata una chiamata AJAX per verificare se esso è già stato configurato. In caso affermativo, nella finestra che compare, vengono mostrate le informazioni inserite precedentemente, che possono essere modificate, altrimenti compaiono gli appositi spazi vuoti, come mostrato in fig. 5.2. 21
http://www.php.net 57 Cap.5 – Implementazione del sistema Fig. 5.2 – Configurazione del singolo sensore Quando l’utente clicca sul tasto di conferma, inizialmente viene controllato il formato dei valori inseriti, se corretto, viene invocato tramite AJAX, lo script PHP controlSensorSettings, il cui codice è parzialmente mostrato nel listato 5.2, che verifica se il pin di input scelto sia compatibile con quello utilizzato dagli altri sensori, secondo le regole già descritte nel paragrafo 4.1.1. In caso positivo, la configurazione del sensore all’interno del database viene aggiornata, altrimenti viene segnalato l’errore. Se l’input scelto è uguale a quello di un sensore già inserito, e i due componenti possono rappresentare lo stesso sensore fisico, il numero di quello appena modificato viene cambiato, in modo da essere lo stesso di quello già inserito. Cliccando sull’icona corrispondente, il designer può rimuovere il sensore. 58 Cap.5 – Implementazione del sistema //viene applicata Livequery all’elemento HTML di classe sensorCollector $(".sensorCollector").livequery(function() { //funzione che gestisce la fase di drop del drag-­‐and-­‐drop $(this).droppable( { //vengono accettati gli elementi HTML di classe sensor-­‐draggable rilasciati //all’interno di quello di classe sensorCollector accept: ".sensor-­‐draggable", //quando il sensore (elemento di classe sensor-­‐draggable) viene rilasciato drop: function(event,ui) { //container rappresenta lo spazio dove viene rilasciato il sensore var container = $(this); //clone è una copia della struttura HTML del sensore preso dalla //lista e rilasciato nell’apposito spazio var clone = $(ui.draggable).clone(); //vengono estratte informazioni che servono per inserire il //sensore all’interno del database var eventId = $("#eventId").attr("data-­‐eventid"); var sensorId = clone.attr("data-­‐idsensor"); var idRow = container.attr('data-­‐idrow'); //viene invocato lo script PHP che inserisce il sensore nel DB $.ajax( { type: 'POST', url : 'phpUtility/ajax/addSensorSettings.php', data : 'sensorId='+sensorId+'&eventId='+eventId+'&idRow='+idRow, //quando lo script PHP ritorna complete: function(text) { //l’id del sensore nel database var id = text.responseText; //viene inserito l’id come attributo HTML clone.attr("id",id); //la struttura HTML che rappresenta il sensore //è appesa a quella che rappresenta lo spazio //che contiene i sensori associati all’evento container.append(clone); } }); } }); }); Listato 5.1 – Funzione che gestisce il drag-­‐and-­‐drop dei sensori 59 Cap.5 – Implementazione del sistema //Nota: Le variabili usate all’interno delle query sono quelle passate in input, dopo essere //state filtrate. Non sono riportate per motivi di spazio $db = new Database(); //la variabile passata come ritorno allo script che ha invocato tramite AJAX quello corrente $reply = "ok"; $queryEvent = $db-­‐>query('SELECT id,name FROM event WHERE id_prototype="'.$protId.'"'); //per ogni evento del prototipo while($event = $db-­‐>estrai($queryEvent)) { $query = $db-­‐>query('SELECT idSensorSettings, idRow FROM sense WHERE idEvent="'.$event-­‐>id.'"'); //per ogni sensore nell'evento corrente while($sense = $db-­‐>estrai($query)) { $sensorSettings = $db-­‐>estrai($db-­‐>query('SELECT id,sensor,inputPin FROM sensorSettings WHERE id="'.$sense-­‐>idSensorSettings.'"')); //se il pin di input del sensore corrente è lo stesso di quello //del sensore appena configurato if($sensorSettings-­‐>inputPin == $pinNumber) { //se i 2 sensori appartengono allo stesso evento if($event-­‐>id == $eventId) { //se sono sulla stessa linea (in A ND tra loro), è errore if($sense-­‐>idRow == $rowId) $reply = "error"; //se sono su 2 linee diverse, ma sono 2 tipologie di sensori //diverse,è errore else if ($sensorSettings-­‐>sensor != $sensorType) $reply = "error"; //se sono su 2 linee diverse e sono la stessa tipologia di //sensore, è corretto else //viene indicato nella risposta l'id del sensore già //associato, in m odo da poter modificare il numero // di quello appena configurato $reply = "same-­‐".$sensorSettings-­‐>id; } //se i 2 sensori appartengono a 2 eventi diversi else { //se sono 2 tipologie di sensori diverse, è errore if($sensorSettings-­‐>sensor != $sensorType) $reply = "errorEvents-­‐".$event-­‐>name; } } } } Listato 5.2 – script PHP che controlla la compatibilità del pin di input inserito dall’utente 60 Cap.5 – Implementazione del sistema 5.2 C onfigurazione d ei c omportamenti s ociali L’associazione dei comportamenti sociali agli eventi, avviene con le stesse modalità della prima versione, utilizzando quindi il drag-­‐and-­‐drop, ad eccezione del fatto che l’utente visualizza la lista dei comportamenti disponibili per ogni social network, dopo aver cliccato sul relativo logo. In fig. 5.3 è mostrato uno screenshot relativo a questa interfaccia. Fig. 5.3 – Interfaccia per l’associazione dei comportamenti sociali Per configurare un comportamento già associato, è necessario cliccare l’apposita icona. Questo causa l’invocazione, tramite AJAX, di uno script PHP che si occupa di smistare i behaviour, indirizzando il browser sulla pagina di configurazione corretta. Queste sono le più generali possibile: invece di esserci una pagina diversa per ogni comportamento, quelli che richiedono informazioni simili sono settati nella stessa, che sarà opportunamente parametrizzata per gestire le differenze tra essi. 61 Cap.5 – Implementazione del sistema Quando l’utente conferma le informazioni inserite, tutte le pagine, dopo opportuni controlli sulla correttezza dei dati, invocano, tramite AJAX, lo script PHP che memorizza le informazioni all’interno della base di dati. 5.3 G enerazione d el c odice p er A rduino Quando l’utente clicca sul pulsante per generare e scaricare il codice per Arduino, situato nella pagina dove si configurano i sensori, inizialmente viene invocato uno script PHP che controlla, all’interno del database, che tutti gli eventi ed i sensori del prototipo siano stati configurati. In caso affermativo, viene chiamato, tramite AJAX, lo script PHP generateCode, che si occupa di generare il codice, passandogli in input un oggetto JSON22, mostrato nel listato 5.3, che rappresenta il prototipo. Oltre all’attributo name, è presente l’attributo events, costituito da un array di eventi. Ogni elemento dell’array è un oggetto che rappresenta il singolo evento, identificato da nome e id. { "name" : nome del prototipo, "events" : [ {"name" : nome evento, "id": id evento}, {"name" : nome evento, "id": id evento}, ... ] } Listato 5.3 – Oggetto JSON che rappresenta il prototipo generateCode, tramite le informazioni contenute nell’oggetto JSON, estrae dal database tutte le informazioni necessarie alla generazione del codice. Lo scheletro di un tipico sketch Arduino è mostrato nel listato 5.4. 22
http://www.json.org 62 Cap.5 – Implementazione del sistema //dichiarazione variabili void setup() { //funzione eseguita una sola volta all’avvio di Arduino, contiene le operazioni iniziali } void loop() { //funzione eseguita ciclicamente quando Arduino è attivo, contiene la logica applicativa } Listato 5.4 – Scheletro di uno sketch Arduino Esso può essere suddiviso in tre parti: •
Dichiarazione delle variabili •
Funzione di setup •
Funzione di loop Per generare il codice, lo script utilizza tre variabili, corrispondenti alla suddivisione dello sketch. 5.3.1 Dichiarazione delle variabili La fase iniziale dipende dalla tipologia di Arduino impiegata per realizzare il prototipo: è necessario importare le librerie che verranno utilizzate per connettersi a internet e inizializzare le variabili contenenti le impostazioni relative alla connessione. Nel listato 5.5, a titolo di esempio, è riportato il codice di questa fase relativo ad Arduino con ethernet shield e Arduino Yún. Arduino con WiFi schield necessiterà di altre librerie e variabili, mentre nel caso si utilizzi una scheda senza connessione ad internet, questa parte non è necessaria. Si noti che vengono generati anche i commenti. 63 Cap.5 – Implementazione del sistema if($prototype-­‐>type == 'ethernet') { $macV = explode("-­‐", $prototype-­‐>mac); $declarationStatements .= "//NOTE: the ethernet shield must be attached to pins 10, 11, 12, 13\n"; $declarationStatements .= "#include <SPI.h>\n"; $declarationStatements .= "#include <Ethernet.h>\n\n"; $declarationStatements .= "//The MAC address of the ethernet shield\n"; $declarationStatements .= "byte m ac[] = { ".$macV[0].", ".$macV[1].", ".$macV[2].", ". $macV[3].", ".$macV[4].", ".$macV[5]." };\n"; $declarationStatements .= "//The Node.js server for the prototype in action\n"; $declarationStatements .= "char server[] = 'http://".$nodeServer."';\n\n"; $declarationStatements .= "//Initialize the Ethernet client library\n"; $declarationStatements .= "EthernetClient client;\n\n"; } elseif($prototype-­‐>type == 'yun') { $declarationStatements .= "#include <Bridge.h>\n"; $declarationStatements .= "#include <Process.h>\n"; } Listato 5.5 – Fase iniziale della generazione del codice Successivamente vengono inserite le variabili relative ai sensori. Per rappresentare ognuno di essi, ne sono necessarie quattro: •
Il pin di input al quale è connesso. •
Il numero di volte che il sensore deve soddisfare la propria condizione per essere attivato. •
Il numero di volte che il sensore ha già soddisfatto la propria condizione. Viene inizializzata a zero. •
Una variabile booleana inizializzata a FALSE. Diventa TRUE quando il sensore soddisfa la propria condizione, FALSE quando non la soddisfa. In questo modo il sensore la può soddisfare più volte solo se tra una volta e l’altra non la soddisfa (ad es. un sensore di temperatura soddisfa due volte la condizione di essere maggiore di 200, se misura un valore maggiore di 200, ne misura uno minore e poi un altro maggiore). La generazione delle quattro variabili è mostrata nel listato 5.6. Questo frammento di codice è all’interno di un ciclo, e viene ripetuto per ogni sensore associato a qualche evento del prototipo. 64 Cap.5 – Implementazione del sistema $declarationStatements .= "//the input pin to which the sensor is connected\n"; $declarationStatements .= "const int ".$name."_Pin = ".$pin.";\n"; $declarationStatements .= "//the number of times that the sensor must reach its condition, $declarationStatements .= “//to activate it\n"; $declarationStatements .= "const int ".$name."_Times = ".$sensor-­‐>times.";\n"; $declarationStatements .= "//counts how many times the sensor reached its condition\n"; $declarationStatements .= "int ".$name."_TimesReached = 0;\n"; $declarationStatements .= "//This variable makes sure that the sensor, when it reached its $declarationStatements .= “//condition, must exit from it before than can reach it again.\n"; $declarationStatements .= "//e.g. if you hold a button, it's counted only 1 time how pressed. $declarationStatements .= “// It's counted how pressed 2 times, if you release it, and then $declarationStatements .= “//you press it again\n"; $declarationStatements .= "boolean ".$name."_ReachedOneTime = false;\n\n"; Listato 5.6 – Generazione delle quattro variabili riferite ad un sensore 5.3.2 Funzione di setup La funzione setup() contiene le operazioni da effettuare all’avvio di Arduino. Inizialmente viene inizializzata la comunicazione con la porta seriale, successivamente tutti i sensori digitali vengono dichiarati come di input. Infatti, mentre le porte analogiche del microcontrollore sono solo di input, quelle digitali possono essere utilizzate sia per collegarvi sensori digitali che attuatori. Per questo motivo è necessario specificarne la tipologia, tramite il codice riportato nel listato 5.7. if($sensor-­‐>type == 'digitalSwitch') $setupStatements .= "pinMode(".$name."_Pin, INPUT);\n\t"; Listato 5.7 – dichiarazione del sensore digitale come input Nel caso di Arduino con Ethernet Shield e WiFi Shield, occorre effettuare la connessione ad internet utilizzando le apposite librerie. Gli eventuali errori vengono stampati sul monitor seriale. Se si utilizza Yún, viene inizializzato l’oggetto Bridge, 65 Cap.5 – Implementazione del sistema che consente la comunicazione tra il microcontrollore e il microprocessore con sistema operativo Linux. Il relativo codice è mostrato nel listato 5.8. if($prototype-­‐>type == 'ethernet') { $setupStatements .= "//starts the Ethernet connection\n\t"; $setupStatements .= "if(Ethernet.begin(mac) == 0)\n\t\t"; $setupStatements .= "Serial.println(\"Failed to configure Ethernet using DHCP\");\n\n\t"; } elseif($prototype-­‐>type == 'wifi') { $setupStatements .= "//attempt to connect to Wifi network\n\t"; $setupStatements .= "while(status != WL_CONNECTED) {\n\t\t"; $setupStatements .= "Serial.print(\"Attempting to connect to SSID: \");\n\t\t"; $setupStatements .= "Serial.println(ssid);\n\n\t\t"; if(is_null($prototype-­‐>protection)) $setupStatements .= "status = WiFi.begin(ssid);\n\t\t"; elseif($prototype-­‐>protection == 'WEP') $setupStatements .= "status = WiFi.begin(ssid, keyIndex, key);\n\t\t"; elseif($prototype-­‐>protection == 'WPA/WPA2') $setupStatements .= "status = WiFi.begin(ssid, pass);\n\t\t"; } elseif($prototype-­‐>type == 'yun') $setupStatements .= "Bridge.begin();\n\t"; Listato 5.8 – Generazione del codice per la connessione ad internet di Arduino 5.3.3 Funzione di loop La funzione loop() costituisce il cuore del codice di controllo. Ad ogni iterazione, per ogni evento vengono effettuate le seguenti operazioni: 1. Lettura dei sensori associati all’evento, ed aggiornamento delle variabili ad essi associate. 2. Verifica della condizione di attivazione dell’evento. Per quanto riguarda il punto 1, all’interno del listato 5.9, viene riportato un estratto proveniente da un esempio di codice generato, relativo ad un sensore di temperatura, che ha come condizione l’essere maggiore di 400. Se la condizione è rispettata, la variabile che conta il numero di volte che questo accade (Temperature1_TimesReached) è incrementata soltanto se quella booleana 66 Cap.5 – Implementazione del sistema (Temperature1_ReachedOneTime), già discussa prima, è falsa. In questo caso la booleana è posta a TRUE. Se invece la condizione non è rispettata, la variabile booleana è posta a FALSE. //Nota: questa è una porzione del codice per A rduino generato dallo script. //condizione rispettata if(analogRead(Temperature1_Pin) > 400) { if(Temperature1_ReachedOneTime == false){ Temperature1_TimesReached++; Temperature1_ReachedOneTime = true; } } //condizione non rispettata else Temperature1_ReachedOneTime = false; Listato 5.9 – Controllo sul singolo sensore all’interno del codice generato Per quanto riguarda il punto 2, viene verificato se tutti i sensori richiesti dalla configurazione logica, associati all’evento, hanno raggiunto la propria condizione il numero di volte necessario per attivarli. Se ad esempio l’evento è costituito da due sensori in OR, sarà sufficiente l’attivazione di uno dei due. Se l’evento è attivato, la porzione di codice successiva dipende dalla tipologia di Arduino. Nel caso di una scheda senza connessione ad internet, il nome del prototipo e dell’evento vengono scritti sulla porta seriale, in modo che l’applicazione Java possa leggerli e comunicarli al server. Nelle altre tre tipologie, il microcontrollore invia una richiesta HTTP al server, contenente nome del prototipo e dell’evento, utilizzando le apposite librerie. L’esempio riportato nel listato 5.10, mostra un evento, denominato isMorning ed appartenente al prototipo socialCup, scatenato da due sensori in AND: quello di temperatura dell’esempio precedente, ed un sensore di tocco. Se l’evento è attivato, le variabili che contano quante volte i sensori hanno soddisfatto la propria condizione vengono azzerate. Sono inoltre mostrati i quattro modi diversi di comunicare l’avvento dell’evento. 67 Cap.5 – Implementazione del sistema //Nota: questa è una porzione del codice per A rduino generato dallo script. if(Temperature1_TimesReached >= Temperature1_Times && Touchsensor1_TimesReached >= Touchsensor1_Times) { Temperature1_TimesReached = 0; Touchsensor1_TimesReached = 0; //per Arduino senza connessione ad internet Serial.println("?protName=socialCup&eventName=isMorning"); //per Arduino con ethernet e WiFi shield if(client.connect(server, 80)) { client.println('GET /?protName=socialCup& eventName=isMorning HTTP/1.1'); client.println('Host: _SERVER_'); client.println('Connection: close'); } //per Arduino Yun Process p; p.runShellCommand("curl -­‐X GET '_SERVER_?protName=socialCup& eventName=isMorning'"); while(p.running()); } Listato 5.10 – Controllo sull’evento all’interno del codice generato L’ultima operazione compiuta dallo script generateCode è quella di scrivere le tre variabili, contenenti il codice generato, all’interno di un file chiamato con lo stesso nome del prototipo, di estensione .ino. In questo modo, quando il controllo viene restituito allo script chiamante, è possibile avviare in automatico il download dello sketch. 5.4 A utenticazione c on i s ocial n etwork L’autenticazione con i social network coinvolti nel prototipo, è una delle operazioni che vengono effettuate nella pagina di test. Nel paragrafo 2.2.1 è stato introdotto Temboo, la soluzione scelta per interfacciarsi con le API relative ai comportamenti sociali. Tra i vari Choreo disponibili, ci sono anche quelli per eseguire il protocollo oAuth, necessario per autenticarsi con i vari social network. 68 Cap.5 – Implementazione del sistema Per questo ambito è stato utilizzato Temboo per PHP, e non per Node.js, come invece avviene quando accade un evento, come sarà illustrato nel prossimo paragrafo. Lo script JavaScript presente nella pagina di test, inizialmente, tramite una chiamata AJAX, ottiene l’elenco dei social network coinvolti nel prototipo. Per ognuno di essi crea una struttura HTML, ed invoca la funzione necessaria ad avviare il protocollo oAuth. Nel listato 5.11 viene riportata, a titolo di esempio, la struttura per Facebook. <div class="authenticationFB"> <span class="authMessage">Facebook login</span> <a href=””></a> <span class="popupClosed" data-­‐closed="0"></span> <span class="listenerId" data-­‐listenerid=""></span> </div> Listato 5.11 – Struttura HTML per l’autenticazione con Facebook Il primo span mostra un messaggio al designer. Dopo l’autenticazione riporterà il nome dell’utente connesso. Il tag a, inizialmente vuoto, conterrà il pulsante di logout dopo l’autenticazione, e quello di login dopo la disconnessione. Il secondo span contiene l’attributo data-­‐closed, che serve a capire se l’utente ha chiuso il popup di autenticazione senza completarla, come sarà chiarito successivamente. Il terzo span possiede l’attributo data-­‐listenerid, che conterrà l’id, all’interno del database, della tupla relativa all’utente connesso a quel social network. La funzione che avvia il protocollo, per prima cosa controlla, tramite AJAX, se nel database è già presente un token di autenticazione, non scaduto, per l’utente. In caso affermativo non è necessario avviare l’autenticazione, altrimenti viene aperta una finestra popup, all’interno della quale è eseguito lo script PHP che, utilizzando l’apposito Choreo di Temboo, esegue le seguenti operazioni: 69 Cap.5 – Implementazione del sistema L’applicazione Sense.me, precedentemente registrata presso il social network, si autentica ad esso utilizzando le proprie chiavi. In caso di successo, l’utente viene reindirizzato su una pagina della rete sociale che lo informa circa i permessi richiesti e gli chiede di fornire l’autorizzazione all’applicazione. Se questo accade, il popup è reindirizzato allo script PHP precedente, che tra i parametri di GET riceve l’access token, che può così essere memorizzato nel database. Se l’autenticazione ha avuto successo il popup si chiude, e viene modificata la struttura HTML relativa: nel primo span viene mostrato l’username dell’utente connesso; nell’a, il pulsante per avviare il logout; nel secondo span l’attributo data-­‐
closed viene posto uguale ad 1; nel terzo span viene inserito, all’interno dell’attributo data-­‐listenerid, l’id della tupla, all’interno del database, che contiene l’access token e le altre informazioni sull’utente. In fig. 5.4 si può visualizzare come l’autenticazione con Twitter sia in corso: sono presenti il popup del protocollo OAuth e la scritta “Twitter login”. Quella con Facebook invece è stata completata, come si evince dal messaggio “You are in Facebook as…” e dal pulsante “Logout”, che si trovano all’interno della struttura HTML descritta precedentemente. Fig. 5.4 – Autenticazione oAuth con Twitter 70 Cap.5 – Implementazione del sistema La funzione JavaScript che ha aperto il popup, quando questo si chiude, controlla il valore dell’attributo data-­‐closed all’interno della struttura HTML. Se è uguale a 0, significa che l’utente ha chiuso la finestra prima che l’autenticazione fosse completata, quindi lo avvisa, e fa comparire all’interno del tag a, il pulsante di login. 5.5 G estione d ell’interazione c on i l p rototipo f isico Come descritto nel paragrafo 4.1.3, il server Node.js è l’attore principale della fase di test. Le funzioni da esso svolte sono: •
Notificare alla pagina di test, visualizzata dal designer, cosa sta accadendo al prototipo e le azioni intraprese in seguito al verificarsi di un evento. •
Quando riceve da Arduino, o dall’applicazione Java, comunicazione del fatto che è accaduto un evento, estrarre dal database le informazioni sulle azioni da compiere e gli access token degli utenti coinvolti, ed utilizzarle per interfacciarsi con le API dei social network. Nonostante le funzioni non siano indipendenti, dato che le notifiche vengono inviate durante le azioni intraprese nel secondo punto, per comodità vengono descritte separatamente. 5.5.1 Notifica all’utente Il server deve inviare, alla pagina di test, notifiche in tempo reale su quello che sta accadendo. La tecnologia scelta per implementare queste comunicazioni è quella dei Web Socket [8], che permettono di aprire un canale bidirezionale tra client e server utilizzando la porta 80. In questo modo, per ricevere aggiornamenti, il browser non deve ricaricare la pagina, o inviare continue richieste AJAX. 71 Cap.5 – Implementazione del sistema Dato che Node.js non supporta nativamente Web Socket, è stato necessario utilizzare una libreria. La scelta è ricaduta su Socket.io23, composta da una parte lato client e una lato server. La sua presenza su entrambi i nodi, consente ad essa di utilizzare questa tecnologia anche con browser che non la dovessero supportare, dato che la libreria è in grado di simularla utilizzando AJAX. Un altro vantaggio è quello di poter scambiare diverse tipologie di messaggi, invece dell’unica prevista da Web Socket. In fig. 5.5 sono mostrati quelli scambiati tra il client ed il server durante la fase di test. Pagina di test Server listener(protName) event(data) wait(data, type) updatepage (data, type) disconnect Fig. 5.5 – Messaggi WebSocket tra il browser ed il server Il messaggio listener è inviato dal client nel momento in cui viene aperta la pagina di test, e comunica al server la volontà di voler ricevere aggiornamenti per il prototipo indicato nel parametro. 23
http://socket.io 72 Cap.5 – Implementazione del sistema Quando lo riceve, il server inserisce l’id del socket all’interno dell’oggetto connections, mostrato nel listato 5.12, che ha come attributi i nomi dei prototipi per i quali esiste, o è esistita, almeno una connessione, ognuno dei quali è costituito dall’array degli id dei socket che devono ricevere le notifiche. { prototypeName1 : [ socketId1, socketId2, … ] prototypeName2 : [ socketId3, … ] ... } Listato 5.12 – Oggetto contenente le connessioni WebSocket in ascolto per i prototipi Il messaggio disconnect è inviato in automatico dal browser quando l’utente chiude la pagina di test. Il server, quando lo riceve, rimuove l’id del socket dall’array. Il codice Node.js che gestisce i due messaggi appena descritti è mostrato nel listato 5.13. 73 Cap.5 – Implementazione del sistema //Il messaggio listener socket.on('listener', function(proto) { //se all’interno dell’oggetto connections, esiste già il prototipo passato come //parametro, l’id del socket viene aggiunto all’array if(connections[proto] != undefined) connections[proto].push(socket.id); //altrimenti viene aggiunto all’oggetto l’attributo relativo al prototipo, e // l’id del socket viene aggiunto all’array else connections[proto] = new Array(socket.id); }); //Il messaggio disconnect socket.on('disconnect', function() { //si cerca, tra tutti i prototipi all’interno dell’oggetto, e tra tutti gli elementi //dell’array di ogni prototipo, l’id del socket da rimuovere for(var prot in connections) { for(var list in connections[prot]) { //il socket viene rimosso if(connections[prot][list] == socket.id) connections[prot].splice(list,1); } } }); Listato 5.13 – Funzioni che gestiscono il messaggio listener e disconnect I messaggi inviati dal server al client sono: •
event(data): quando si è verificato un evento sul prototipo. Il browser scrive sulla pagina il contenuto del parametro, che contiene il nome dell’evento. •
wait(data, type): inviato prima di iniziare la comunicazione con un’API. Il browser, alla ricezione, mostra un’immagine di attesa, e una stringa, contenuta nel parametro data, che informa l’utente sul fatto che il comportamento sociale sta avvenendo. type è un id, che serve successivamente a rimuovere l’immagine di attesa quando l’interazione con l’API è stata completata. •
updatepage(data, type): inviata dopo la risposta dell’API, contiene, all’interno di data, la risposta ottenuta, che può essere una conferma dell’avvenuta pubblicazione, un messaggio di errore o le informazioni ricevute. Il browser mostra questa risposta, e utilizzando type, rimuove l’immagine di attesa relativa a quel comportamento sociale. 74 Cap.5 – Implementazione del sistema Il codice riportato nel listato 5.14 mostra un esempio di invio del messaggio updatepage, dopo la comunicazione con l’API per il comportamento “Publish post”, e la sua gestione da parte del client. //invio del messaggio da parte del server a tutti gli utenti connessi tramite web socket for(var user in connections.users) { connections.wsObject.sockets.socket(connections.users[user]). emit('updatepage', "Status published on Facebook: "+ settingParam.text, "PublishpostFB"); } //ricezione del m essaggio da parte del client socket.on('updatepage', function(data, type) { //viene rimossa l'immagine di attesa $("#"+type).remove(); //viene pubblicato il contenuto di data $(".text").append(data); }); Listato 5.14 – invio e ricezione del messaggio updatepage 5.5.2 Gestione dell’evento La comunicazione del fatto che è accaduto un evento avviene tramite un messaggio HTTP inviato dal prototipo al server Node.js. Questo scatena una serie di operazioni che coinvolgono i tre moduli dai quali è costituito il server: •
protInActionServer: riceve i messaggi Web Socket di tipo listener descritti precedentemente, ed i messaggi HTTP dai prototipi. •
eventHandler: estrae dal database le informazioni necessarie a gestire l’evento: quali azioni compiere, con i relativi dati, e gli access token degli utenti dei social network necessari. •
apiCaller: si interfaccia, tramite Temboo, con le API corrispondenti ai comportamenti sociali coinvolti. Questi moduli vengono ora descritti in maniera dettagliata, al fine di comprendere come viene gestito un evento. 75 Cap.5 – Implementazione del sistema 5.5.2.1 protInActionServer Questo modulo è il server vero e proprio, infatti resta in attesa dei messaggi Web Socket di tipo listener e delle richieste HTTP. Nel primo caso effettua le operazioni descritte precedentemente, nel secondo ne analizza la correttezza. Un prototipo, quando si verifica un evento, invia al server una richiesta HTTP di tipo GET, con una sintassi di questo tipo: GET /?protName=NOME_PROTOTIPO&eventName=NOME_EVENTO Per prima cosa quindi, viene controllato se la query contiene i campi protName e eventName. In caso negativo viene inviata al client una risposta di tipo 400, in caso affermativo viene invocata la funzione principale del modulo eventHandler, passandogli come parametri la query ed un oggetto che consente al modulo di continuare a gestire le connessioni Web Socket. Questo infatti contiene l’oggetto del modulo Socket.io e l’array di id dei socket in ascolto per quel prototipo. Infine viene inviata al client una risposta di tipo 200, comunicandogli che le azioni necessarie per reagire all’evento sono in corso. Nel codice riportato all’interno del listato 5.15, si può visualizzare la gestione delle richieste HTTP. Si noti che Node.js è un linguaggio event-­‐driven basato sulle funzioni di callback, quindi la riposta HTTP di tipo 200 viene generata subito dopo l’invocazione di eventHandle, che, nonostante avvii tutte le operazioni per gestire l’evento, non costituisce una chiamata bloccante. 76 Cap.5 – Implementazione del sistema function handlerHTTP(req, res) { //viene estratta la query dalla richiesta GET var urlQuery = url.parse(req.url, true).query; //la query è corretta se contiene i campi "protName" e "eventName" if(urlQuery.protName != undefined && urlQuery.eventName != undefined) { //viene invocata la funzione del modulo "eventHandler" eventHandle(urlQuery, {wsObject : io, users: connections[urlQuery.protName]}); //la risposta HTTP res.writeHead(200, {"Content-­‐Type": "text/plain"}); res.write("The actions necessary to react at the event are in progress"); res.end(); } //se la query non è corretta else { //la risposta HTTP res.writeHead(400, {"Content-­‐Type": "text/plain"}); res.write("Bad request received"); res.end(); } } Listato 5.15 – Gestione delle richieste HTTP da parte del server 5.5.2.2 eventHandler La funzione eventHandle di questo modulo, riceve in input la query della richiesta GET, dalla quale può ricavare il nome del prototipo e dell’evento che si è verificato, e gli elementi necessari per inviare i messaggi Web Socket. Per prima cosa notifica a tutti gli utenti in ascolto per quel prototipo, il fatto che si è verificato l’evento. Successivamente vengono estratti dal database gli access token degli utenti dei social network con i quali sarà necessario interagire. Si ricorda che queste informazioni sono memorizzate quando il designer, all’interno della pagina di test, esegue l’autenticazione oAuth con le reti sociali incluse nel prototipo. I dati estratti sono inseriti in un oggetto, mostrato nel listato 5.16, che ha come attributi gli id dei social network. Ognuno di essi è un array, ed ogni elemento dell’array è un oggetto, di nome listeners, che ha come attributi l’id dell’utente della rete sociale, i suoi access token e access token secret. 77 Cap.5 – Implementazione del sistema { idSocialNetwork1 : [ { uid : ID_UTENTE_1, accessToken : ACCESS_TOKEN_1, accessTokenSecret : ACCESS_TOKEN_SECRET_1 }, { uid : ID_UTENTE_2, accessToken : ACCESS_TOKEN_2, accessTokenSecret : ACCESS_TOKEN_SECRET_2 }, … ], idSocialNetwork2 : [ { uid : ID_UTENTE_3, accessToken : ACCESS_TOKEN_3, accessTokenSecret : ACCESS_TOKEN_SECRET_3 }, … ], ... } Listato 5.16 – Oggetto contenente gli access token per i social network In seguito è necessario recuperare le configurazioni dei comportamenti sociali da eseguire. Questa operazione viene compiuta da funzioni diverse, ognuna delle quali estrae dal database le informazioni relative ad una certa classe di comportamenti. Ad esempio retrievePublishSetting estrarrà le informazioni per “Publish post” di Facebook e “Publish tweet” di Twitter. Una volta recuperati i dati, il controllo viene passato al modulo apiCaller. Questo presenta all’esterno una funzione per ogni social network, quindi deve essere invocata quella relativa al comportamento sociale per il quale sono state estratte le informazioni. Per farlo, viene mantenuto un oggetto, di nome socialDispatcher, che ha come attributi gli id dei social network, i quali hanno come valore la funzione corrispondente all’interno del modulo apiCaller. La funzione che estrae le impostazioni dei comportamenti sociali, come ultimo atto, invoca la funzione a cui passare il controllo, utilizzando la sintassi: 78 Cap.5 – Implementazione del sistema socialDispatcher[idSocialNetwork](parametri) Per comprendere meglio quanto appena descritto, si consideri l’esempio riportato nel listato 5.17, nel quale è mostrata una parte dell’oggetto socialDispatcher, e la funzione che estrae le impostazioni per i comportamenti sociali di pubblicazione. var socialDispatcher = { 3 : apiCaller.facebook, 4 : apiCaller.twitter, ... }; function retrievePublishSettings(connections, dbConnection, idSetting, settingType, sn, listeners) { var queryPublish = 'SELECT text FROM setting WHERE id='+idSetting; dbConnection.query(queryPublish, function(err, rows) { if (err) throw err; var settingParam = {text: rows[0].text}; socialDispatcher[sn] (settingType, settingParam, listeners[sn], connections); }); } Listato 5.17 – Porzione dell’oggetto socialDispatcher e funzione retrievePublishSettings In questo caso il parametro sn passato a retrievePublishSettings, può valere 3 o 4. Nel primo caso la funzione, dopo aver eseguito la query, invocherà: socialDispatcher[3] (parametri) corrispondente all’invocazione di: facebook (parametri) all’interno del modulo apiCaller. I parametri passati in input alla funzione sono: il nome del comportamento sociale, i dati estratti dal database, gli access token per quel social network e gli elementi per mandare i messaggi Web Socket. 79 Cap.5 – Implementazione del sistema 5.5.2.3 apiCaller Come già accennato, questo modulo esporta al suo esterno una funzione per ogni social network presente, che può essere invocata all’interno del modulo eventHandler. Ognuna di queste, per prima cosa, invia a tutti gli utenti in ascolto il messaggio Web Socket wait, utilizzando le informazioni ricevute in input e informando su quale comportamento sociale si sta eseguendo. Successivamente, invoca la funzione che compie le operazioni necessarie ad interfacciarsi con l’API per quel particolare comportamento. Nel listato 5.18, viene riportato, a titolo di esempio, la funzione per Google Calendar. Il messaggio wait è composto da due parametri: il primo è il messaggio da mostrare all’utente, il secondo un id che identifica il comportamento, che è ottenuto concatenando il suo nome, senza spazi, con una sigla indicante il social network. function googleCal(settingType, settingParam, listeners, connections) { //toglie gli spazi dal nome del comportamento var type = settingType.replace(/\s+/g, ''); //invia il messaggio wait a tutti gli utenti in ascolto for(var user in connections.users) { connections.wsObject.sockets.socket(connections.users[user]).emit('wait', "Performing the behaviour \""+settingType+"\" for Google Cal", type+"GC"); } //ogni comportamento è gestito da un’apposita funzione, che viene qui invocata switch(settingType) { case 'New event' : gCalNewEvent(session, settingParam, listeners, connections); break; case 'Search events' : gCalSearchEvents(session, settingParam, listeners, connections); break; } } Listato 5.18 – funzione per Google Calendar Il codice delle funzioni che si interfacciano con le API è basato sull’apposito Choreo di Temboo per Node.js. La struttura è simile per tutte: dopo aver inizializzato la connessione con Temboo, per ogni utente del social network viene invocata la API, con gli appositi parametri; 80 Cap.5 – Implementazione del sistema quando questa risponde, viene inviato agli utenti connessi tramite Web Socket, il messaggio updatepage, con parametro data diverso a seconda se la risposta è di esito positivo o di errore. Nel caso di API in cui si ricevono informazioni, che solitamente sono in formato JSON, queste vengono elaborate in modo da costruire il messaggio che potrà essere mostrato all’utente. Viene riportato il codice della funzione che pubblica un tweet su Twitter. 81 Cap.5 – Implementazione del sistema function twitterPublishTweet(session, consumer, settingParam, listeners, connections) { //viene inizializzata la connessione con il Choreo Temboo var Twitter = require("temboo/Library/Twitter/Tweets"); var statusesUpdateChoreo = new Twitter.StatusesUpdate(session); var statusesUpdateInputs = statusesUpdateChoreo.newInputSet(); //per ogni utente del social network for(var list in listeners) { //vengono settati gli input della API. Sono le informazioni //estratte dal database e le credenziali dell'applicazione //Sense.me registrata su Twitter statusesUpdateInputs.set_AccessToken(listeners[list].accessToken); statusesUpdateInputs.set_AccessTokenSecret(listeners[list]. accessTokenSecret); statusesUpdateInputs.set_ConsumerSecret(consumer.secret); statusesUpdateInputs.set_ConsumerKey(consumer.key); statusesUpdateInputs.set_StatusUpdate(settingParam.text); //viene eseguito il choreo statusesUpdateChoreo.execute( statusesUpdateInputs, //se l'API è stata invocata con esito positivo function(results) { //viene inviato il messaggio Web Socket, updatepage for(var user in connections.users) { connections.wsObject.sockets.socket(connections.users[user]). emit('updatepage', "Tweet published on Twitter: "+ settingParam.text, "PublishtweetTW"); } }, //se l'API ha generato errore function(error) { //viene inviato il messaggio Web Socket, updatepage, //segnalando l'errore for(var user in connections.users) { connections.wsObject.sockets.socket(connections.users[user]). emit('updatepage', "An error has occurred in the publishing of the tweet on Twitter. Details: "+ error.message, "PublishtweetTW"); } } ); } } Listato 5.19 – Funzione twitterPublishTweet 82 Cap.6 – Valutazione di Sense.me 2.0 Capitolo 6: Valutazione di Sense.me 2.0 Questo capitolo descrive la valutazione svolta su Sense.me dopo aver implementato le modifiche discusse nei capitoli precedenti, e le varie fasi che l’hanno costituita. 6.1 F ase p reliminare Dopo aver completato lo sviluppo della seconda versione di Sense.me, è stato organizzato un test con gli utenti. L’obiettivo non era solo quello di analizzarne l’usabilità, ma anche capire come il framework si integrasse nell’attività di progettazione di un prodotto. Per questo motivo il test è stato nominato “ideation workshop” ed è stato presentato come un laboratorio in cui fosse possibile, utilizzando l’applicazione Sense.me, realizzare un prototipo che interagisse con i social network, in modo semplice e senza la necessità di saper programmare. La struttura dell’esperimento è stata la seguente: 1. In gruppi di tre o quattro persone, progettazione e realizzazione di un prototipo che acquisisse informazioni tramite sensori e interagisse con i social network, basandosi su uno scenario proposto. 2. Singolarmente, utilizzo di Sense.me per creare la controparte virtuale del prototipo, scaricare il codice per Arduino e testarlo. Il tutto commentando le azioni ad alta voce. 3. Intervista ad ogni utente per comprendere le sue impressioni sul framework e la sua integrazione nella fase di design. Per pianificare il test nella maniera più precisa possibile, si sono formulate le risposte a una serie di domande, secondo quanto suggerito in [9]: 83 Cap.6 – Valutazione di Sense.me 2.0 1. Quando e dove si terrà il test? Il test si terrà all’interno dell’ambiente denominato Studio Do, un’area all’interno degli ID Studio Labs fornita di un tavolo e di una grande varietà di oggetti (ad es. polistirolo, compensato, pezzi di Lego, carta) che possono essere utilizzati per realizzare un prototipo. L’ambiente dovrebbe già essere familiare agli utenti, dato che viene utilizzato quando essi lavorano ai progetti assegnati durante i corsi. Le date verranno decise di comune accordo con gli studenti, in modo da poter formare gruppi di almeno tre persone. 2. Quanto tempo durerà ogni sessione? Ogni sessione durerà al massimo un’ora e mezza. La prima fase, di gruppo, avrà durata massima di un’ora, la seconda di circa 20 minuti e la terza di circa 10. 3. Quali tipi di supporto saranno necessari per condurre il test? Oltre ai moduli forniti, descritti successivamente, per la prima fase saranno presenti: una scheda Arduino Uno, dotata di ThinkerKit!; sensori; matite e pennarelli; materiali per la prototipazione, già presenti nello Studio Do. Per la seconda fase sarà utilizzato il pc dello sperimentatore, sul quale è già installato l’IDE di Arduino. Il browser utilizzato sarà Chrome. Sarà inoltre attivo un software di registrazione dello schermo e dell’audio, in modo che lo sperimentatore non rischi di perdere informazioni importanti. Le interviste saranno registrate. 4. In che stato dovrà trovarsi il sistema per iniziare il test? Per la prima fase, i moduli ed il materiale dovranno essere a disposizione ordinatamente. Per la seconda, il browser dovrà essere aperto sull’home page di Sense.me ed il software di registrazione attivo. 5. Quali dovranno essere i tempi di risposta e i tempi della rete? L’esperimento si svolgerà all’interno del TU Delft, il che dovrebbe garantire 84 Cap.6 – Valutazione di Sense.me 2.0 una connessione stabile e veloce. Possibili ritardi saranno dovuti al server che ospita il database. Se si verificassero, sarà possibile testare se il sistema li gestisce correttamente. 6. Chi saranno gli utenti del test, come li troviamo e quanti dovranno essere? Gli utenti saranno studenti magistrali della facoltà di Industrial Design Engineering, dato che il framework è stato sviluppato per loro. Il reclutamento avverrà tramite passa-­‐parola e la pubblicazione di un annuncio sulla bacheca online di un corso frequentato da studenti di tutte e tre le tipologie di corsi magistrali descritti nell’introduzione di questa tesi. Visto il periodo denso di scadenze per gli studenti, si cercherà di formare almeno due gruppi, e quindi di avere almeno sei utenti. 7. Quali compiti faremo svolgere? I compiti sono quelli descritti nella struttura dell’esperimento. 8. Quali aiuti daremo agli utenti? Durante la prima fase lo sperimentatore sarà sempre presente per avvisare gli utenti se il prototipo che hanno in mente non è realizzabile con Sense.me (ad es. nel caso in cui ne vogliano realizzare uno che utilizzi degli attuatori), e per rispondere ad eventuali dubbi e domande. Durante la seconda fase non verranno dati suggerimenti. L’unico aiuto potrà essere quello per il caricamento del codice su Arduino, dato che si tratta di un’attività esterna al framework. 9. Quali dati si vorranno raccogliere e come saranno analizzati? Le informazioni raccolte saranno di natura qualitativa. Durante la seconda fase sarà utilizzato il protocollo “think aloud” [4], che permette di raccogliere i commenti dell’utente in fase di utilizzo del sistema. Le interviste permetteranno di indagare in maniera approfondita le impressioni dell’utente sull’applicazione e sulla sua integrazione con il 85 Cap.6 – Valutazione di Sense.me 2.0 processo di design. 10. Quali saranno gli incentivi per gli utenti a partecipare? La presentazione dell’esperimento come “ideation workshop” ed il fatto di utilizzare un prodotto che permette di realizzare prototipi sociali senza programmare dovrebbe solleticare l’interesse di alcuni studenti. Durante l’esperimento, per far sentire gli utenti a loro agio, saranno fornite bevande e snack. 6.2 S celta d el c ampione d i u tenti La scelta del campione di utenti è fondamentale per effettuare un esperimento di usabilità che sia valido ed affidabile [9]. Per ottenere la validità è necessario che venga misurato qualcosa di effettivamente rilevante rispetto allo scopo dell’esperimento. È dunque necessario avere un campione di utenti rappresentativo della popolazione alla quale è destinato il software. Per l’affidabilità occorre avere una variabilità degli utenti minore possibile. All’esperimento hanno partecipato sette utenti, con le seguenti caratteristiche: •
Sesso: 5 donne, 2 uomini. •
Corso di laurea: 6 DFI, 1 IPD. •
Età: 1 di 22 anni, 1 di 24, 1 di 25, 2 di 26, 1 di 30, 1 di 34. Quasi tutti gli utenti sono studenti del corso Design For Interaction, per i quali è nato Sense.me. 6.3 D efinizione d ella s truttura p er l a v alutazione 86 Cap.6 – Valutazione di Sense.me 2.0 Come già introdotto, l’esperimento prevede tre fasi, ognuna delle quali ha necessitato la produzione di opportuni documenti, in modo da poter svolgere il test e la valutazione in maniera corretta. Vengono ora descritti, suddivisi per fase di appartenenza. 6.3.1 Creazione del prototipo Ai membri del gruppo è stato consegnato il modulo utente, riportato in fig. 10.1. Esso, nella parte iniziale, ringrazia l’utente per la partecipazione, descrive brevemente gli obiettivi di Sense.me e dell’ideation workshop, e chiede l’autorizzazione ad usare materiale fotografico e audiovisivo raccolto per scopi di ricerca. Nella seconda parte sono richieste alcune informazioni sull’utente, come il sesso, l’età ed il corso di laurea. La terza parte è composta dal design brief, ovvero lo scenario a cui gli studenti si devono ispirare nel creare il prototipo, in questo caso un qualcosa che motivi le persone ad usare i mezzi pubblici invece dell’auto. Viene fornito anche l’elenco dei comportamenti sociali disponibili, suddivisi per social network. 87 Cap.6 – Valutazione di Sense.me 2.0 Sense.me ideation workshop
Date: ___ / ____ / ________ ! !
Time required:!
!
!
!
!
!
Group n. ____
1h 30ʼ
Thank you for your time!
Iʼm working on a software, named Sense.me, that allows designers to create prototypes
that receive data from the environment with sensors and interact with social networks.
These prototypes are realized with Arduino, but, with Sense.me, the designer can create
them without programming a single line of code!
With this ideation workshop I would like to understand if the work done is going in the right
direction.
Remember that Iʼm testing the software, not your capabilities, so if you have difficulties
donʼt worry, it will allow me to understand whatʼs wrong with the system.
Below, you can see a design brief from which you can take inspiration for designing a
small social product.
After a briefing with your group in which you decide how to design the interaction using the
material available, you will be asked to use Sense.me to design the virtual counterpart of
your prototype.
Try to make it as interactive as possible with social networks.
In the first design part, discussion among the members of the group is encouraged.
During the use of Sense.me please comment aloud each step you are performing by
expressing your positive and negative impressions.
Before starting, please read the following additional information, and fill in a small form
Additional information
During this workshop a video will be recorded and some pictures may be taken. All the
materials produced will be used only for academic and research purposes.
If you agree, please check the box below and sign the space provided.
I authorize the use of the data that will be collected in this workshop for academic and
research purposes.
Signature:________________________________________
Fig. 6.1 – Modulo utente 88 Cap.6 – Valutazione di Sense.me 2.0 General information about the user:
Gender:!
Male
Female !
!
Age:________
Course:
________________________________________________________________________
Design Brief
In a lot of cities around the world, many people choose to go out by car, instead of using
public transportation.
They do it because they feel themselves more comfortable inside their car rather than
inside a bus, tram, subway...
This fact causes many problems, like pollution and traffic jams.
Design a product that motivates people to use public transportation. It could be something
on the bus, or something possessed by the user...
Details
• An A3 template for each participant is provided in order to help you to deliver sketches
and describe your ideas. Please use them!
• All the material inside the Studio is available with the purpose of creating your physical
prototype.
• In addition, you can use the sensors described in the sensors list document
• The social behaviours available are:
• Facebook
• Publish a post
• Create an event
• Checkin
• Leave a comment
• Reply to an event invitation
• Follow the activity with Sense.me of another Facebook user
• Show posts searching by keywords
• Like something
• Twitter
• Publish a tweet
• Start to follow a user
• Send a direct message
• Show tweets from a user or searching by hashtags/keywords
• Show the favorite tweets of the user
• Google Calendar
• Create a new event
Fig. 6.1 (continua) – Modulo utente 89 Cap.6 – Valutazione di Sense.me 2.0 • Search events
• Gmail
• Send an email
• Yahoo! Weather
• Get the weather for a location
• Foursquare
• Checkin
• Instagram
• Get popular media
• Get media of a user
Fig. 6.1 (continua) – Modulo utente Insieme al modulo utente, è stata fornita la lista di sensori, mostrata in fig. 6.2, disponibili, ognuno accompagnato da una breve descrizione. 90 Cap.6 – Valutazione di Sense.me 2.0 List of sensors
Photoresistor
LDR (or Photoresistor) is a variable resistor. The resistance varies according to the
light which invests the sensor. Output: This sensor returns values that ​​should be
between 0 (dark) and 1023 (high light).
Force
The force sensor is a resistor whose resistance varies significantly depending on
the force applied on itself. Output: The signal returned by this sensor should
approach 1023 if the applied force increases. If the force decreases approaches 0.
Temperature
The temperature sensor is a resistor whose resistance varies significantly (more
than for the resistors standard) depending on the temperature.
Output: The signal returned by this sensor should approach 1023 if the temperature
increases. If the temperature decreases approaches 0.
(Note: any change in values ​​will be very slow; this sensor is very difficult to use
because it is difficult to predict the output values)
Linear Potentiometer
A Linear Potentiometer is a commonly used variable resistor. It is often used to
control the volume of the radio and TV.
Output: This sensor should return 0 to 1023 depending on the position of the slider
(0 to an extreme, the other extreme 1023).
Touch sensor
The Touch Sensor is sensitive to the touch.
Output: This sensor returns normally 0 (LOW) but if touched, returns 1 (HIGH).
Infrared Distance
The infrared distance sensor is able to detect the presence of nearby objects, and
the distance from them, without any physical contact. The signal returned is
between 0 (the minimum distance) and 1023 (the maximum distance, or nominal
range)
Air pressure
An air pressure sensor usually acts as a transducer; it generates a signal as a
function of the pressure imposed.
Output: The signal returned by this sensor should approach 1023 if the pressure
increases. If the pressure decreases approaches 0.
Fig. 6.2 – Lista dei sensori 91 Cap.6 – Valutazione di Sense.me 2.0 Motion
The motion sensor detects changes in infrared radiation that occur when there is
movement of something which is different in temperature from the surroundings
Vibration
The vibration sensor buffers a piezoelectric transducer. As the transducer is
displaced from the mechanical neutral axis, bending creates strain within the
piezoelectric element and generates voltages.
Output: between 0 an 1023
Fig. 6.2 (continua) – Lista dei sensori Per aiutare il gruppo ad esplicitare le proprie idee, è stato messo a disposizione un modello di progettazione, costituito da un foglio A3, suddiviso in tre parti, come mostrato in fig. 6.3. Questo modello è comunemente utilizzato dai designer in fase di progettazione. In alto a sinistra è possibile disegnare una mappa mentale delle idee, a destra è possibile disegnare il prototipo che si vuole realizzare, mentre in basso a sinistra è richiesta una descrizione testuale. Fig. 6.3 – Modello di progettazione 92 Cap.6 – Valutazione di Sense.me 2.0 6.3.2 Utilizzo di Sense.me Durante questa fase è stata valutata l’usabilità dell’applicazione. Per questo motivo essa è stata suddivisa in sette parti da analizzare separatamente: 1. Registrazione e login. 2. Creazione del prototipo. 3. Creazione degli eventi. 4. Associazione dei comportamenti sociali. 5. Configurazione dei comportamenti sociali. 6. Associazione dei sensori. 7. Test del prototipo. Ad ogni utente è stato chiesto di commentare ad alta voce la sua interazione con Sense.me, mentre lo sperimentatore appuntava osservazioni e commenti, utilizzando il documento di cui ne viene mostrata una parte poco sotto. La stessa tabella era presente per ognuna delle sette parti. Lo schermo del pc sul quale si è svolto l’esperimento, così come l’audio, è stato registrato, in modo da evitare di perdere informazioni. 93 Cap.6 – Valutazione di Sense.me 2.0 Date: __________
Start time: __________!
Finish time: __________
Registration and login
User comments
Exprimenter comments
Bugs
Fig. 6.4 – Documento sperimentatore per la seconda fase 6.3.3 Intervista Lo scopo di questa fase è stato quello di capire l’opinione degli utenti su Sense.me, ed in particolare sulla sua integrazione con il processo creativo che porta i designer, prima ad immaginare, e poi a prototipare un oggetto. Per ottenere questo obiettivo si è deciso di effettuare un’intervista semi-­‐strutturata, piuttosto che utilizzare un questionario, in modo da poter indagare in maniera più approfondita le impressioni dell’utente sull’applicazione. Un’intervista semi-­‐strutturata è quella in cui l’intervistatore, partendo da un insieme di domande predefinite, può riadattarle in base alle risposte ottenute. Rispetto ad una non strutturata, è una tipologia più adatta ad un intervistatore non esperto. In questo caso, data la scarsa conoscenza dell’intervistatore sul processo di creazione di un prototipo, ci si è avvalsi dell’aiuto di una tesista di Industrial Design. 94 Cap.6 – Valutazione di Sense.me 2.0 Le domande sono riportate in fig. 6.5. Le prime tre sono relative, rispettivamente, alla fase di progettazione, alla fase di progettazione ed implementazione ed alla fase di test. Sono riportati, ad uso degli intervistatori, gli obiettivi che si vogliono raggiungere con esse, in modo da poter approfondire correttamente le risposte degli utenti. Le ultime tre sono domande di carattere generale che indagano le impressioni dei designer sull’applicazione. Final interview
1 - Do you think that sense.me has facilitated your creative fluency? Can you
explain how it did or not?
This question is related to the Design phase.
-Goal: Understand if, during the phase in which the prototype is imagined and designed
on paper, the designer, knowing that he has to realize it with Sense.me, has an advantage
or a limitation.
The advantage could be the possibility of adding, to the prototype, behaviours that he/she
could never imagine. The limitation could be the fact that he/she knows that he canʼt be
free to create whatever he wants.
2 - Do you think that sense.me has allowed you to prototype your ideas faster? Can
you explain why it did or not?
This question is related to the Design and Implementation phases.
-Goal: Understand if the creation process of a virtual prototype using Sense.me is fast
(from the creation of the prototype to the generation of the code).
If it is fast, is also simple and clear? If itʼs slow, is it because the process is not simple and
clear?
The designer perceives a relation between his mental model of creation and the
organization of Sense.me?
3 - Do you think that Sense.me has allowed you to verify easily if the object behavior
corresponds to what is expected? Can you explain why it did or not?
This question is related to the Test phase.
-Goal: Understand if, when the virtual prototype is generated and the code is uploaded on
Arduino, testing the prototype is simple and clear.
If all goes weel at the first try, the designer understands it immediately?
If something wrong happened, the designer understands why it happened and how to
correct the problems inside Sense.me?
4 - Think about your experience of using Sense.me. What are the perceived
benefits?
5 - Think about your experience of using Sense.me. What are the perceived limits?
6 - Do you have additional comments?
Fig. 6.5 – Documento per le interviste 95 Cap.6 – Valutazione di Sense.me 2.0 6.4 R isultati Vengono ora riportati i risultati dei test svolti con gli utenti, suddivisi nelle tre fasi. 6.4.1 Osservazioni raccolte durante la creazione dei prototipi Gruppo 1 L’idea iniziale del primo gruppo è stata quella di uno strumento che consentisse di visualizzare quali persone, o quali amici, fossero sul mezzo pubblico che l’utente aveva intenzione di prendere. L’ipotesi è stata scartata in quanto in Sense.me non sono presenti comportamenti sociali adatti allo scopo. Successivamente il gruppo si è concentrato sulla realizzazione di un prototipo che fosse presente su ogni mezzo pubblico. L’autobus, il tram, ecc. avrebbe dovuto pubblicare informazioni sul suo stato, come la posizione, la temperatura interna, il numero di persone presenti, in modo che un passeggero potesse avere un’idea della situazione a bordo, ed eventualmente scegliere di prendere il mezzo successivo, o un’altra tipologia di trasporto (es. Il tram invece dell’autobus). L’idea è stata scartata dato che presentava varie incompatibilità con Sense.me: •
Non è possibile acquisire informazioni GPS •
Non è possibile includere i valori misurati dai sensori nella pubblicazione di post sui social network. In seguito il gruppo si è concentrato sul numero di passeggeri a bordo. L’idea era quella di contare i passeggeri entrati nell’autobus e quelli usciti, per conoscere il numero di persone a bordo e comunicarlo su un profilo Facebook del mezzo. Dato che una porta può essere utilizzata sia per salire che per scendere, era stato pensato di utilizzare due sensori ad infrarossi che misurassero la distanza per ogni porta. Se un passeggero fosse entrato nel mezzo si sarebbe attivato prima un sensore e poi l’altro, se fosse uscito l’inverso. 96 Cap.6 – Valutazione di Sense.me 2.0 Anche questa idea è stata scartata in quanto incompatibile con Sense.me: Non è possibile contare quante volte viene attivato un sensore, ma solo attivarlo dopo un numero prefissato di volte (es. si può settare un sensore ad infrarossi per attivarsi dopo che rileva per 5 volte una distanza minore di 300, ma non contare quante volte questo accada) •
Non è possibile raccogliere dati da sensori diversi ed elaborarli insieme, come avrebbe richiesto contare la differenza tra persone entrate e uscite. Si è deciso infine di semplificare l’idea precedente assumendo che i passeggeri potessero entrare da una porta e uscire dall’altra, ma non viceversa. Il prototipo finale prevede che ogni mezzo pubblico sia dotato di un profilo Twitter, sul quale viene pubblicato un messaggio quando entrano o escono un determinato numero di persone (es. “sono entrate 5 persone”, “sono uscite 10 persone”). Gruppo 2 Il secondo gruppo ha deciso di focalizzarsi, come mezzo pubblico, sul treno. L’idea iniziale è stata di rendere interattivi i poster pubblicitari presenti sui vagoni, in modo che i passeggeri interagendo con essi potessero ottenere dei benefici, come degli sconti sul prodotto in questione. Si è successivamente stabilito che questi dispositivi fossero presenti in stazione, e ci si è concentrati su uno che pubblicizzasse un particolare bar all’interno di essa. L’utente, dopo aver effettuato l’autenticazione, può interagire col pannello pubblicitario in due modi: facendo due volte il segno di saluto, o tirando una leva. Nel primo caso viene pubblicato sul profilo Twitter dell’utente un particolare hashtag, e viene effettuato il checkin con Foursquare all’interno del bar. Questo consente di ottenere lo sconto su una bibita. Ne secondo caso viene pubblicato un secondo hashtag e viene effettuato il checkin su Foursquare, cosa che consente di ottenere uno sconto sul caffè. Per riconoscere il primo evento, quello del saluto, è stato deciso di utilizzare un sensore ad infrarossi che misurasse la distanza: quando esso rileva per 2 volte un qualcosa situato ad una distanza molto piccola, vengono attivati i comportamenti sociali. 97 Cap.6 – Valutazione di Sense.me 2.0 Per realizzare il secondo evento si è scelto un potenziometro lineare. 6.4.2 Osservazioni raccolte durante l’utilizzo di Sense.me Vengono riportati i commenti esplicitati dagli utenti, e le osservazioni effettuate dallo sperimentatore, durante l’utilizzo di Sense.me, suddivisi nelle sette parti stabilite per la valutazione dell’applicazione. Registrazione e login Commenti Nessun problema riscontrato Creazione del prototipo Commenti Molti utenti, dopo aver effettuato il login, non capiscono subito dove sia possibile creare un nuovo prototipo. Tutti gli utenti che scelgono per il prototipo un nome composto da più parole, lo scrivono con gli spazi, ottenendo errore. Dopo il messaggio di errore tutti capiscono che non è possibile utilizzare gli spazi. Un utente utilizza il trattino per separare le parole che compongono il nome. Questo genera un errore quando si cerca di aprire il file generato da Sense.me con il software di Arduino. Avendo a disposizione solo un Arduino senza connessione ad internet, non è stato possibile testare le opzioni “Arduino con ethernet shield” e “Arduino con WiFi shield” in fase di creazione del prototipo. Creazione degli eventi Commenti 98 Cap.6 – Valutazione di Sense.me 2.0 Alcuni utenti creano solo un evento invece che tutti quelli previsti dal prototipo. Uno si aspetta di dover prima configurare interamente un evento, e solo successivamente anche altri, un altro lo fa volontariamente perchè vuole testare un evento alla volta. Un utente per prima cosa clicca sul tasto “Sensor association”, e solo dopo aver visualizzato il messaggio di errore entra nella pagina di creazione degli eventi. Un utente crea l’evento dandogli il nome del sensore. Associazione dei comportamenti sociali Commenti Alcuni utenti cercano di trascinare l’icona del social network all’interno dello spazio dove inserire i comportamenti sociali, invece che cliccare su essa per mostrare i comportamenti disponibili. Alcuni utenti non capiscono dove trovare i comportamenti sociali. Un utente clicca sull’icona di un social network, ma non si accorge del fatto che compare la lista dei comportamenti associati, e cerca di trascinare l’icona stessa. Alcuni utenti cliccano sul tasto “Sensors association” senza aver prima configurato i singoli comportamenti sociali, ottenendo errore. Un utente cerca di trascinare il tasto “Sensors association” nello spazio dove vengono trascinati i comportamenti sociali. Un utente non capisce cosa significhi “behaviours” all’interno della scritta “Drag here to add behaviours”. Configurazione dei comportamenti sociali Commenti Gli utenti che hanno il checkin Foursquare all’interno del proprio prototipo, non si aspettano di dover inserire anche un messaggio oltre all’ID del luogo. Dato che l’applicazione non consente di lasciare vuoto il campo, scrivono qualcosa inventato al momento. 99 Cap.6 – Valutazione di Sense.me 2.0 Associazione dei sensori Commenti Un utente trascina i sensori sotto gli eventi e clicca su “Get Arduino code” senza configurare i singoli sensori, ottenendo errore. Molti utenti non capiscono cosa significhino: “Threshold”, “Comparison operator” e “Number of times to activate”; faticano dunque a configurare correttamente il singolo sensore. Alcuni utenti, dopo aver inserito i dati per configurare i singoli sensori, cliccano all’esterno del “fumetto”, facendo si che questo si chiuda senza che le impostazioni vengano salvate. Lamentano che l’icona per confermare le impostazioni sia poco visibile. Un utente ritiene che non dovrebbe essere necessario cliccare sull’icona di conferma per salvarle. Un utente chiede se è importante l’ordine con cui vengono inseriti i sensori: “significa che prima si attiva uno e poi l’altro?” Test del prototipo Commenti Molti utenti faticano a capire dove si debba andare per aprire la pagina di test. Sembra che si aspettino che compaia un collegamento ad essa dopo aver scaricato il codice per Arduino. Un utente non riesce a trovarla, prova a consultare l’help ma non capisce ugualmente come fare. Molti utenti rimangono spaesati dai popup per l’autenticazione con i social network che compaiono quando si apre la pagina di test. Alcuni utenti non capiscono perchè sia necessario scaricare l’applicazione. Alcuni utenti attivano due volte lo stesso evento sul prototipo: dato che Twitter e Facebook non consentono di pubblicare consecutivamente lo stesso messaggio, compare errore, fatto che lascia spaesato gli utenti, non capendo a cosa sia dovuto. 100 Cap.6 – Valutazione di Sense.me 2.0 6.4.3 Risultati delle interviste Vengono ora riportate le risposte ottenute durante le interviste, tradotte in italiano. 1 -­‐ Do you think that sense.me has facilitated your creative fluency? Can you explain how it did or not? Sense.me ha costituito una limitazione perché è necessario inserire la propria idea all’interno di quello che si ha a disposizione, ed il processo di creazione si focalizza sui sensori piuttosto che verso l’obiettivo principale che si vuole raggiungere. Allo stesso tempo avere una lista di sensori disponibili, può portare ad avere idee diverse. In un normale processo di design non si inizia sapendo che strumento utilizzare e le limitazioni di esso. Tuttavia, una volta noto che si utilizzerà Arduino, l’applicazione è molto utile, in particolare per chi è digiuno di elettronica. Senza l’applicazione, un designer che non ha conoscenze di programmazione, non potrebbe proprio realizzare il prototipo, quindi in generale Sense.me è più un aiuto che una limitazione. Esisteva una limitazione dal momento che il gruppo aveva un’idea e lo sperimentatore la bocciava in quanto non realizzabile con Sense.me. Tuttavia, esistendo la possibilità di modificare il codice generato, questa limitazione è in parte compensata. Avendo la lista dei comportamenti sociali e dei sensori disponibili, mi sono sentita ispirata, perché mi permetteva di pensare a come connettere oggetti presenti nella vita di tutti i giorni con i social network. Non so se avrei pensato alle stesse cose senza avere la lista. 101 Cap.6 – Valutazione di Sense.me 2.0 Ha facilitato il flusso creativo perché guardando la lista dei sensori disponibili ho una base dalla quale partire, anche se in quel momento sono a corto di idee, ma allo stesso tempo ha costituito una limitazione perché si è dipendenti da quelli. Può essere un aiuto perché quando si iniziano ad avere “idee pazze”, sapere cosa è possibile fare e cosa no, consente di arrivare ad un punto. 2 -­‐ Do you think that sense.me has allowed you to prototype your ideas faster? Can you explain why it did or not? Assolutamente si, non avendo molte conoscenze su Arduino, senza Sense.me non avrei potuto creare la stessa cosa. L’applicazione è chiara e usabile, per il fatto che è possibile configurare le cose tramite drag-­‐and-­‐drop. Si, ha aiutato molto per quanto riguarda il tempo, perché fare la stessa cosa scrivendo il codice mi avrebbe messo in difficoltà, dato che non ho molta esperienza. 3 -­‐ Do you think that Sense.me has allowed you to verify easily if the object behavior corresponds to what is expected? Can you explain why it did or not? I popup per l’autenticazione mi hanno un po’ confuso. Forse sarebbe meglio che non si aprissero in automatico ma che l’utente debba connettersi cliccando da qualche parte. Sarebbe più chiaro se fosse possibile vedere i risultati dell’interazione all’interno del social network. Ad esempio che si aprisse Twitter dopo che il tweet è stato pubblicato. 102 Cap.6 – Valutazione di Sense.me 2.0 È stato difficile capire dove fosse possibile testare il prototipo, perché quando ho cliccato sul pulsante per scaricare il codice sono rimasto in quella pagina e non sapevo dove andare. Il pulsante per accedere alla pagina di test dovrebbe essere “Test” e non “Web page”. Ho potuto capire che il prototipo stava funzionando. Ho attivato involontariamente due volte l’evento, ed è stato mostrato un errore che mi ha un po’ confuso. 4 -­‐ Think about your experience of using Sense.me. What are the perceived benefits? Mi è piaciuto il fatto che ho potuto creare il prototipo senza dover scrivere codice. Un utente esperto ha nel codice generato un’ottima base, e un utente non esperto, a digiuno di programmazione, o addirittura spaventato dall’elettronica, può creare un prototipo facilmente. Se si vuole creare qualcosa che abbia interazioni di base (es. se schiaccio un bottone pubblica su Facebook) Sense.me è molto utile, perché permette di farlo in modo semplice, e forse avere interazioni di base è sufficiente per molti prototipi. L’interfaccia sembra organizzata e semplice. Sense.me offre una gamma di opzioni limitate rispetto alle potenzialità di Arduino, ma per me che non sono esperto è meglio perché posso vedere cosa posso fare. 5 -­‐ Think about your experience of using Sense.me. What are the perceived limits? 103 Cap.6 – Valutazione di Sense.me 2.0 Sense.me in certi casi costituisce una limitazione, ma comunque consente di avere una base per comunicare con i social network, sulla quale un esperto può lavorare modificando il codice generato. Potrebbe essere migliore se si aggiungessero altre opzioni. Per gli utenti più esperti potrebbe essere una limitazione rispetto alle potenzialità di Arduino. La lista di sensori è un po’ limitata. La distinzione tra sensori analogici e digitali dovrebbe essere più chiara, magari utilizzando colori diversi. Quando ho creato l’evento, non sapevo se avrei dovuto inserire prima i comportamenti sociali o i sensori. Ho visto che per prima cosa chiedeva di inserire i comportamenti sociali, quindi ho fatto quello, ma mi aspetterei di dover inserire prima i sensori perché è più logico. Non era ben chiaro l’ordine in cui fare le cose: quando si programma prima si impostano i sensori, e dopo “cosa fare”, mentre in Sense.me è il contrario. Non sapevo se collegare i sensori ad Arduino prima di utilizzare Sense.me, oppure dopo aver configurato tutto con l’applicazione. 6 -­‐ Do you have additional comments? Mi piacerebbe utilizzare Sense.me in futuro. Sarebbe bello avere altri comportamenti a disposizione, oltre a quelli basati su internet. 104 Cap.6 – Valutazione di Sense.me 2.0 6.5 C onclusioni Vengono ora riassunte le conclusioni ottenute dai test con gli utenti, suddivise tra il punto di vista dell’usabilità e l’integrazione di Sense.me nell’attività di design. Le soluzioni apportate per risolvere i problemi riscontrati saranno trattate nel prossimo capitolo. 6.5.1 Punto di vista dell’usabilità L’analisi effettuata ha portato ad ottenere informazioni qualitative. Il sistema, sebbene supporti un compito strutturato, è pensato per essere di tipo walk-­‐up-­‐and-­‐use. Per questo motivo il suo utilizzo non è stato preceduto da una sessione di apprendimento. Le difficoltà principali rilevate dagli utenti durante lo svolgimento del test riguardano: •
Visualizzazione delle informazioni: in alcuni casi non è immediato trovare le informazioni desiderate. Dopo aver effettuato il login si rimane nella home page. Per accedere alla sezione dove si possono creare e gestire i prototipi, bisogna cliccare sull’apposita voce del menu, che tuttavia è risultata poco visibile. Nella pagina dove si associano agli eventi i comportamenti sociali, questi ultimi sono poco visibili. È mostrato infatti solo l’elenco dei social network disponibili, e può risultare non chiaro il fatto che è necessario cliccare su quello desiderato. Nella finestra che permette di configurare il singolo sensore, l’icona per confermare le impostazioni è poco visibile ed ha poca affordance. Quando l’utente apre la pagina di test, i popup per l’autenticazione con i social network si aprono automaticamente, senza che egli venga informato 105 Cap.6 – Valutazione di Sense.me 2.0 sul loro significato. Dopo che l’utente clicca sul bottone per scaricare il codice, il download è avviato, ma il browser rimane su quella pagina. Risulta dunque difficile capire dove sia l’area di test. •
Discrepanza tra il linguaggio dell’utente ed il linguaggio del progettista: è stata rilevata una discrepanza tra il linguaggio del progettista e quella dell’utente. Le informazioni richieste per configurare il sensore sono risultate poco chiare ad alcuni utenti. La pagina dove è possibile testare il prototipo è chiamata “web page”, rendendo difficile agli utenti capire che si tratta di quella di test. Risulta poco chiaro il motivo per cui sia necessario scaricare l’applicazione Java, dato che le spiegazioni fornite non sono molto chiare. •
Discrepanza tra il modello mentale dell’utente e il modello concettuale del progettista: il problema principale di questa categoria è la configurazione di un evento. Sense.me infatti permette, nella stessa pagina, di creare tutti gli eventi desiderati, ed associarvi i comportamenti sociali, mentre in un’altra pagina è possibile associare i sensori a tutti gli eventi. Molti utenti sono rimasti spaesati da questo approccio, dato che si aspettavano di dover configurare completamente un evento alla volta. Inoltre alcuni di loro pensavano di dover prima associare i sensori all’evento, e poi i comportamenti sociali, sia per una questione di ordine logico (i sensori attivano l’evento, i comportamenti sociali sono effettuati in seguito alla sua attivazione), sia per similitudine con la programmazione di Arduino. 106 Cap.6 – Valutazione di Sense.me 2.0 6.5.2 Punto di vista dell’integrazione nell’attività di design Uno degli obiettivi principali del test era quello di capire se Sense.me potesse essere effettivamente utile ai designer, integrandosi nella fase di progettazione senza sconvolgerla, cosa che scoraggerebbe il suo utilizzo. Il framework è nato con uno scopo preciso: creare prototipi che interagiscono con i social network, quindi deve essere considerato solo in questa casistica. Dalle interviste con gli utenti è emerso che, durante la fase di progettazione di un prototipo, l’applicazione è una limitazione, poiché i designer devono inquadrare le loro idee all’interno delle possibilità che essa offre. Tuttavia in una situazione normale, al di fuori dei vincoli dati dal test, si può ipotizzare che un progettista sviluppi liberamente le proprie idee, e in seguito si avvalga di Sense.me se queste sono compatibili. Alcuni studenti hanno ammesso che questa limitazione in certi casi può essere un vantaggio, dato che sapere cosa si ha a disposizione, può portare ad avere idee nuove. Tutti sono stati concordi nel dire che, senza Sense.me, non sarebbero stati in grado di realizzare lo stesso prodotto, e quindi i vantaggi offerti sono superiori alle limitazioni. È stato anche apprezzato il fatto che si potesse modificare il codice generato, cosa che è stata vista come la possibilità, per un esperto di Arduino, di avere un’ottima base di partenza per sviluppare idee più complesse. Per quanto riguarda le funzionalità offerte dal framework, alcuni utenti hanno dichiarato che sarebbero necessari più sensori. Questa cosa, almeno per quanto riguarda quelli standard per Arduino, può essere risolta facilmente da un utente registrato con un’email della TU Delft, come già visto nella specifica dei requisiti. È stato suggerito anche di fornire altri comportamenti, oltre a quelli dei social network. Nonostante il suggerimento fosse di carattere generale, si può ipotizzare che ci si riferisse alla possibilità di utilizzare anche attuatori. 107 Cap.7 – Modifiche apportate dopo la valutazione Capitolo 7: Modifiche apportate dopo la valutazione Questo capitolo descrive le attività svolte per correggere i problemi riscontrati durante la valutazione del sistema. Dopo aver analizzato i risultati ottenuti dal test con gli utenti, si è proceduto a correggere i problemi di usabilità riscontrati. Vengono quindi descritte le modifiche apportate al sistema. 7.1 C onfigurazione d egli e venti Nel paragrafo 6.5.1 è stato illustrato come molti utenti si aspettassero di configurare completamente un evento alla volta, associandovi prima i sensori, ed in seguito i comportamenti sociali da attivare. È stato quindi deciso di riorganizzare la relativa interfaccia. Nell’interfaccia originaria, l’utente, dopo il login, accede alla pagina dove viene mostrato l’elenco dei suoi prototipi. Ognuno di essi si presenta come mostrato in fig. 7.1. Fig. 7.1 – Gestione di un prototipo prima della valutazione Sono presenti quattro pulsanti: •
Add events: per aggiungere nuovi eventi ed associarvi i comportamenti sociali. •
Delete: per eliminare il prototipo. 108 Cap.7 – Modifiche apportate dopo la valutazione •
Sensors: per associare i sensori agli eventi, e scaricare il codice per Arduino. •
Web Page: la pagina di test. Nell’ottica di configurare un evento alla volta, nella nuova interfaccia ogni prototipo dell’elenco si presenta come in fig. 7.2. Fig. 7.2 – Gestione di un prototipo dopo la valutazione I pulsanti diventano tre: •
Events: per accedere ad una pagina, descritta poco sotto, dove viene mostrato l’elenco degli eventi per il prototipo, ed è possibile aggiungerne di nuovi. •
Test page: per entrare nella pagina di test. Il pulsante è stato rinominato per maggiore chiarezza. •
Delete: per eliminare il prototipo. Nell’interfaccia precedente alle modifiche, cliccando sul tasto “Add events”, si accede alla pagina mostrata in fig. 7.3, dove era possibile creare nuovi eventi, visualizzare quelli già presenti, ed associarvi i comportamenti sociali, trascinandoli sotto il nome. 109 Cap.7 – Modifiche apportate dopo la valutazione Fig. 7.3 -­‐ Pagina degli eventi prima della valutazione Nella nuova interfaccia, cliccando sul pulsante “Events”, si accede alla pagina mostrata in fig. 7.4, dove viene mostrato l’elenco degli eventi per il prototipo in questione. Per ognuno sono presenti due pulsanti: •
Configure: per accedere alla pagina del singolo evento, dove sarà possibile associarvi i sensori ed i comportamenti sociali. •
Delete: per eliminare l’evento. È anche possibile aggiungere nuovi eventi, ed è presente il pulsante “Get Arduino Code” per generare e scaricare il codice. Fig. 7.4 -­‐ Pagina degli eventi dopo la valutazione 110 Cap.7 – Modifiche apportate dopo la valutazione Con la vecchia interfaccia, dopo aver creato gli eventi ed avervi associato i comportamenti sociali (fig. 7.3), era possibile accedere alla pagina dei sensori, mostrata in fig. 7.5, dove era presente l’elenco di tutti gli eventi, sotto ognuno dei quali era possibile trascinare i sensori da associarvi, e scaricare il codice per Arduino mediante l’apposito pulsante. Fig. 7.5 -­‐ Pagina dei sensori prima della valutazione Con l’approccio della nuova interfaccia invece, si ha una pagina per ogni evento, come mostrato in fig. 7.6, alla quale si accede cliccando sul tasto “Configure” (vedi fig. 7.4), oppure in automatico quando l’evento viene creato. Essa è suddivisa in due parti, contrassegnate dalle etichette “IF” e “THEN”. Nella prima è possibile associare i sensori che attivano l’evento, nella seconda i comportamenti sociali da eseguire quando questo si verifica. Questa organizzazione è simile a quella che si utilizza quando si scrive il codice per Arduino, inoltre permette all’utente di capire meglio il funzionamento di un singolo evento. Sotto l’elenco dei social network, è stata inserita una scritta che invita l’utente a cliccare su quello desiderato per mostrare i relativi comportamenti sociali. 111 Cap.7 – Modifiche apportate dopo la valutazione Fig. 7.6 -­‐ Pagina per la configurazione di un evento, dopo la valutazione 7.2 A ssociazione d ei s ensori Anche l’associazione dei sensori all’evento ha subito alcune modifiche. Con l’interfaccia precedente alla valutazione, per utilizzare lo stesso sensore fisico più volte, in linee di AND diverse, era necessario configurare sensori diversi, aventi la stessa tipologia, assegnando a tutti lo stesso pin di input. Nella nuova interfaccia è stato reso possibile trascinare sensori già inseriti, in altre linee di AND. In questo modo si crea una copia del sensore desiderato, già configurata con le stesse impostazioni di quello originale. In questo modo è possibile utilizzare più volte lo stesso sensore in maniera più intuitiva. Dato che l’icona per confermare le impostazioni del singolo sensore risultava poco visibile, è stata sostituita con un pulsante, simile a quelli già utilizzati in altri punti dell’applicazione. In fig. 7.7 si può visualizzare la vecchia interfaccia, in fig. 7.8 quella nuova. 112 Cap.7 – Modifiche apportate dopo la valutazione Fig. 7.7 -­‐ Configurazione sensore, vecchia interfaccia Fig. 7.8 -­‐ Configurazione del sensore, nuova interfaccia Anche la formula visualizzata sotto i sensori associati all’evento ha subito delle modifiche. Nell’interfaccia precedente alla valutazione, essa mostrava solo i nomi dei sensori, e la loro configurazione logica, come mostrato in fig. 7.9. Nella nuova interfaccia, fig. 7.10, per ogni sensore è mostrato il pin al quale è collegato, la sua condizione, ed il numero di volte che questa deve essere raggiunta. In questo modo l’utente può rendersi conto della configurazione attuale in maniera più semplice. Fig. 7.9 -­‐ Formula dei sensori, vecchia interfaccia 113 Cap.7 – Modifiche apportate dopo la valutazione Fig. 7.10 -­‐ Formula dei sensori, nuova interfaccia 7.3 P agina d i t est La pagina per testare il prototipo è stata modificata per risolvere i problemi riscontrati, e per renderla più chiara all’utente. Innanzitutto, come già mostrato in fig. 7.2, essa è stata rinominata “Test page”, anziché “Web page”. Nella vecchia interfaccia, la pagina si mostra come in fig. 7.11. Nel riquadro azzurro sono presenti i pulsanti per scaricare l’applicazione Java per i vari sistemi operativi. Sotto di esso, sulla destra, si può visualizzare la parte relativa all’autenticazione con i social network, che è avviata in automatico quando viene aperta la pagina. In basso è mostrata una scritta che dichiara di stare aspettando che qualche evento accada sul prototipo. In quest’area sono mostrati i messaggi Web Socket ricevuti dal server. Fig. 7.11 -­‐ Pagina di test, vecchia interfaccia 114 Cap.7 – Modifiche apportate dopo la valutazione La nuova interfaccia è mostrata in fig. 7.12. Come si può vedere, è stata suddivisa in tre parti orizzontali. Nella prima, mostrata solo nel caso in cui il prototipo sia realizzato con Arduino senza internet, è presente il riquadro azzurro per scaricare l’applicazione Java. La scritta è stata modificata per rendere più chiaro all’utente il motivo per cui è necessario svolgere questa operazione. Nella seconda parte è possibile gestire l’autenticazione con i social network. Essa non è più automatica, ma dev’essere avviata dall’utente cliccando sul pulsante “Login” accanto al nome di ognuno di essi. Per questo motivo è presente una breve spiegazione. La terza è stata denominata “Prototype Log”, ed è quella in cui vengono mostrati i messaggi Web Socket ricevuti. Quando questo accade, la pagina viene fatta scorrere automaticamente verso il fondo, in modo che essi siano maggiormente visibili. Fig. 7.12 -­‐ Pagina di test, nuova interfaccia 115 Cap.7 – Modifiche apportate dopo la valutazione 7.4 A ltre m odifiche In questa sezione vengono riportate alcune modifiche minori. 7.4.1 Menu La pagina dove viene mostrato l’elenco dei prototipi di un utente, è stata rinominata “Your Prototypes”. Questo si riflette sul menu, la cui vecchia versione è mostrata in fig. 7.13, mentre la nuova è in fig. 7.14. Fig. 7.13 -­‐ Menu, vecchia interfaccia Fig. 7.14 -­‐ Menu, nuova interfaccia È da sottolineare che con la nuova interfaccia, l’utente, dopo aver effettuato il login, viene reindirizzato automaticamente alla pagina “Your Prototypes”, dato che i test avevano evidenziato la difficoltà a raggiungerla da parte degli utenti. 7.4.2 Barra di navigazione La barra di navigazione del sito è stata modificata in modo da rispecchiare i cambiamenti dell’interfaccia. 116 Cap.7 – Modifiche apportate dopo la valutazione Quella vecchia, mostrata in fig. 7.15 e riferita alla pagina per associare i sensori, mostra un link alla pagina dei prototipi, chiamata “Sense.me Framework” e indicazioni sul prototipo a cui si stava lavorando. Fig. 7.15 -­‐ Barra di navigazione, vecchia interfaccia Quella nuova, mostrata in fig. 7.16 e riferita alla pagina di un evento, mostra gerarchicamente le voci: pagina dei prototipi; prototipo; evento; comportamento sociale. Ogni voce, tranne l’ultima della gerarchia, che indica dove ci si trova, è un link alla pagina corrispondente. Fig. 7.16 -­‐ Barra di navigazione, nuova interfaccia 7.4.3 Accesso alla pagina di test Un problema riscontrato durante la valutazione è il fatto che, dopo aver scaricato il codice, si rimanga in quella pagina, e risulti quindi non immediato accedere all’area di test. Per risolvere questo problema, con la nuova interfaccia, quando si clicca il pulsante “Get Arduino code”, oltre ad avviarsi il download del file, compare sotto di esso il pulsante per accedere alla pagina di test, come mostrato in fig. 7.17. Fig. 7.17 -­‐ Pulsante per accedere all'area di test 117 Cap.8 – Conclusioni e sviluppi futuri Capitolo 8: Conclusioni e sviluppi futuri Questo capitolo riassume il lavoro svolto e propone alcuni sviluppi futuri per Sense.me. 8.1 R isultati o ttenuti L’obiettivo della tesi è stato quello di proseguire lo sviluppo di Sense.me, espandendone le funzionalità, in modo che potesse diventare uno strumento semplice ed intuitivo, nell’ottica dell’End-­‐user Development, per la creazione di prototipi, anche complessi, che interagiscono con i social network. In una prima fase è stata analizzata la prima versione del framework, ed i test con gli utenti effettuati su di essa. Basandosi su questi, sono state proposte delle modifiche da apportare al sistema, che sono confluite nella specifica dei requisiti per Sense.me 2.0. Dai requisiti si è passati allo studio dell’architettura del framework, analizzando come questa potesse essere modificata per includere le nuove funzionalità, ma anche per rendere semplici le eventuali espansioni future. La modifica architetturale più corposa è stata quella di sostituire i due server utilizzati durante la fase di test, con un unico server, chiamato server Node.js, che è stato scritto da zero. Esso prende in carico tutte le operazioni da svolgere quando accade un evento sul prototipo. Per aumentare il numero di comportamenti sociali disponibili su Sense.me, e poterne aggiungere facilmente di nuovi, si è deciso di interfacciare il sistema con Temboo, servizio composto da librerie per i principali linguaggi di programmazione ed API, che consente di invocare una grande quantità di API di svariati siti web, tra cui i principali social network. 118 Cap.8 – Conclusioni e sviluppi futuri La base di dati è stata riprogettata per integrare queste modifiche. In seguito alla riprogettazione, si è passati all’implementazione delle modifiche. Oltre al nuovo server Node.js, particolare attenzione ha richiesto l’interfaccia per associare, e configurare, i sensori agli eventi, dato che, a differenza della prima versione, è possibile usarne più di uno. È stato riscritto completamente anche il modulo che genera il codice per Arduino, essendo necessario includere la presenza di più sensori e la possibilità di usare svariate tipologie di microcontrollore. Dato che nella nuova versione del framework sono presenti più social network, è stata ripensata l’autenticazione dell’utente con essi, che avviene all’interno della pagina di test e si avvale di Temboo. Conclusa la fase implementativa, è stato organizzato un test con gli utenti, in cui si è studiata l’usabilità del sistema e la sua integrazione nell’attività di design. Questo ha confermato l’utilità dell’applicazione, dato che, per ammissione degli studenti, consente loro di creare prototipi che altrimenti non avrebbero potuto vedere la luce. Sono emersi alcuni problemi di usabilità, che sono stati successivamente corretti. In particolare è stata ripensata l’organizzazione dell’interfaccia per quando riguarda la gestione degli eventi. Si è deciso di utilizzare una pagina per ogni evento, all’interno della quale il designer può associare ad esso i sensori che lo attivano, e configurare i comportamenti sociali da eseguire quando esso si verifica. Alla luce di quanto descritto, gli obiettivi posti possono dirsi raggiunti. 8.2 P ossibili s viluppi f uturi Vengono ora elencate alcune proposte da cui partire per eventuali sviluppi del framework. 119 Cap.8 – Conclusioni e sviluppi futuri 8.2.1 Valutazione della nuova interfaccia La nuova interfaccia, sviluppata dopo i test con gli utenti, è stata mostrata in maniera informale ad alcuni utenti, che l’hanno apprezzata, tuttavia, per motivi di tempo, non è stato possibile organizzare una valutazione. Questa attività, che permetterebbe di capire se essa incontra il favore dei designer, oltre a individuare possibili problemi di usabilità, potrebbe essere un punto di partenza per la prosecuzione dello sviluppo di Sense.me. 8.2.2 Aggiunta di ulteriori comportamenti e social network Utilizzando Temboo, è semplice aggiungere nuovi social network e nuovi comportamenti sociali al sistema. Questa attività potrebbe essere necessaria per aumentare le funzionalità offerte. 8.2.3 Attivazione attuatori in base ad eventi sui social network Attualmente Sense.me permette di creare prototipi che acquisiscono informazioni dai sensori, e si interfacciano con i social network quando rilevano degli eventi. Uno sviluppo interessante sarebbe quello di poter utilizzare anche gli attuatori, che potrebbero essere attivati, sia quando si verificano determinate condizioni sui sensori, sia quando accade qualcosa sui social network. Considerando l’interfaccia per la configurazione di un evento, mostrata in fig. 7.6, nella parte “IF” si potrebbero utilizzare sia sensori che avvenimenti sui social network, nella parte “THEN” sia attuatori che comportamenti sociali. Ad esempio: quando l’utente @PincoPallino riceve una citazione su Twitter, e il sensore di luminosità rileva un valore maggiore di 300, accende un LED e pubblica un post su Facebook. Si chiuderebbe così il ciclo, come mostrato in fig. 8.1. 120 Cap.8 – Conclusioni e sviluppi futuri Social Network Eventi sui sensori Eventi sui social network Arduino Sensori Attuatori Fig. 8.1 – Proposta di architettura per un prototipo realizzato con Sense.me 8.2.4 Pubblicazione contenuti dal file system Nella scelta dei comportamenti sociali da rendere disponibili in Sense.me, sono stati esclusi volutamente quelli che richiedono accesso al file system, come ad esempio la pubblicazione di foto. Questo per mantenere la compatibilità con tutte le tipologie di microcontrollore, e per non aumentare troppo la complessità. Dato che alcune tipologie di Arduino, come Yún, hanno un sistema operativo ed un file system, si potrebbe studiare la possibilità di aggiungere questa tipologia di comportamento, ove supportata. Questo potrebbe portare a nuovi scenari che espanderebbero le funzionalità del framework, come ad esempio la pubblicazione di fotografie scattate dal prototipo tramite una webcam. 121 Appendice Appendice A. T ecnologie u tilizzate PHP PHP, acronimo ricorsivo di “PHP: Hypertext Preprocessor”, è un linguaggio di programmazione utilizzato principalmente per la creazione di applicazioni web lato server. Creato dal danese Rasmus Lerdorf nel 1994, negli anni successivi ha goduto di una popolarità sempre crescente per la creazione di pagine web dinamiche. Si tratta di un linguaggio interpretato, il cui interprete è open source, di alto livello, debolmente tipizzato, con una sintassi che ricorda quella del C. Dalla versione 5 (quella attuale è la 5.5) è supportato il paradigma di programmazione ad oggetti. Il linguaggio è provvisto di numerose API per interfacciarsi con innumerevoli DBMS e server web. Insieme a MySQL e Apache per Linux, forma la diffusa architettura LAMP per lo sviluppo di applicazioni web. All’interno di Sense.me è utilizzato, tra le altre cose, per la generazione delle pagine HTML costituenti l’interfaccia, per la generazione del codice Arduino e per l’esecuzione del protocollo OAuth che permette di autenticarsi con i social network. MySQL MySQL è un Relational database managment system (RDBMS), di proprietà di Oracle, composto da un client a riga di comando e da un server. 122 Appendice La sua disponibilità per numerose piattaforme, la semplicità, ed il fatto che sia gratuito, ne fanno una delle soluzioni più utilizzate per applicazioni web che non richiedano particolari prestazioni per quanto riguarda la base di dati. Il database utilizzato da Sense.me, a cui hanno accesso sia gli script PHP in fase di configurazione del prototipo, sia il server Node.js in fase di test, è gestito tramite MySQL. Apache Apache24 è un server web open source, multi piattaforma, sviluppato dall’Apache Software Foundation a partire dal 1995. È composto da un’architettura modulare. Tra i vari moduli è presente quello che permette di utilizzare PHP: quando il client richiede una pagina di estensione .php, Apache esegue gli script contenuti in essa e restituisce la pagina risultante. Si tratta del server web più diffuso a livello mondiale, ed è utilizzato anche per Sense.me. JavaScript JavaScript è un linguaggio di scripting, originariamente sviluppato da Brendan Eich all’interno della Netscape Communications, e standardizzato dalla ECMA. È un linguaggio interpretato, debolmente tipizzato, di alto livello, debolmente orientato agli oggetti, con una sintassi simile a quella del C. 24
http://httpd.apache.org 123 Appendice Il suo utilizzo principale è quello per lo sviluppo di pagine web dinamiche lato client. L’interprete è contenuto nel browser, il quale, quando all’interno di una pagina incontra uno script JavaScript lo esegue. In Sense.me, JavaScript è stato utilizzato lato client, tramite la libreria JQuery, e lato server all’interno di Node.js. JQuery JQuery, creata da John Resig nel 2005, è una libreria di funzioni JavaScript, cross-­‐
browser, per la creazione di applicazioni web lato client. Permette di effettuare svariate operazioni in maniera più semplice rispetto a JavaScript, come ad esempio manipolazione del DOM e dello stile CSS, invocazioni AJAX e gestione degli eventi. AJAX AJAX, acronimo di “Asynchronous JavaScript And XML”, è una tecnica di sviluppo per la realizzazione di applicazioni web interattive. Si basa su uno scambio di dati in background tra il server ed il browser, che consente l’aggiornamento dinamico della pagina web senza che questa debba essere ricaricata. È asincrono nel senso che i dati sono richiesti al server e caricati in background, senza interferire con il comportamento della pagina esistente. Solitamente le chiamate AJAX, e la gestione delle risposte, vengono effettuate tramite JavaScript. Nonostante il nome, l’utilizzo di questo linguaggio, e del formato XML per lo scambio dei dati, non è obbligatorio. Molto spesso per quest’ultimo scopo, si utilizza il formato JSON, per motivi di semplicità. 124 Appendice All’interno di Sense.me questa tecnologia è ampiamente utilizzata, tramite JQuery. Quasi tutte le interazioni dell’utente con l’interfaccia comportano una chiamata AJAX ad uno script PHP sul web server, che interroga il database e restituisce una risposta. Node.js Node.js, creato da Ryan Dahl nel 2009, è una piattaforma che consente di sviluppare applicazioni lato server utilizzando JavaScript. È implementato sul motore JavaScript V8 di Google, nato per il browser Chrome, che può anche essere eseguito in modalità stand alone. La sua caratteristica più significativa è Il modello di esecuzione: asincrono e guidato dagli eventi. I linguaggi più comuni (come Java, C++, PHP) sono sincroni: quando eseguono un’istruzione, prima di proseguire con quelle successive, aspettano che questa si concluda. Nel caso di istruzioni che richiedono un certo tempo di esecuzione, dette bloccanti (ad esempio effettuare una query complessa ad un database), il thread rimane in attesa. Il programma principale solitamente è composto da più thread e processi. Node.js invece è composto da un unico processo. Quando incontra un’istruzione bloccante, la esegue, ma invece di aspettare che si concluda, prosegue con l’esecuzione di quelle successive. Quando quella bloccante si conclude genera un evento, che viene gestito da un’apposta funzione di callback. Per comprendere meglio questo concetto, vengono riportati due esempi: il primo è in PHP, il secondo è in Node.js. Entrambi fanno le stesse cose: interrogano un database, stampano il risultato e la stringa “hello world”. Il codice PHP è il seguente: 125 Appendice $risultato = database.query(“SELECT * FROM tabella”);
echo $risultato;
echo “hello world”;
Viene eseguita la query, quando questa si conclude viene stampato il risultato, e successivamente la stringa “hello world”. Il codice Node.js è il seguente: database.query(“SELECT * FROM tabella”, function(risultato){
console.log(risultato);
});
console.log(“hello world”);
In questo caso verrà stampata prima la stringa “hello world”, e solo successivamente il risultato della query. Infatti, dopo aver effettuato la chiamata alla funzione database.query, viene eseguita l’istruzione immediatamente successiva (la stampa di “hello world”). Quando la query termina, viene generato un evento che viene gestito dalla funzione anonima di callback, presente come secondo parametro della funzione database.query, che effettua la stampa del risultato. In Sense.me Node.js è stato utilizzato per realizzare il server che effettua tutte le operazioni necessarie quando accade un evento sul prototipo fisico, e notifica il tutto all’utente. WebSocket Il termine WebSocket si riferisce a due standard: il protocollo WebSocket, un protocollo di comunicazione basato su HTTP e standardizzato dall’IEFT; le WebSocket API, ovvero le API JavaScript per gestire l’implementazione del protocollo all’interno del browser, standardizzate dall’W3C. 126 Appendice Questi due standard permettono ad una pagina web di instaurare una comunicazione a due vie con un host remoto, superando il classico modello richiesta-­‐risposta tipico del web. Nel seguito vengono descritti i due standard appena intodotti. Il protocollo WebSocket Il protocollo WebSocket prevede due nuovi URI scheme (ws:, per connessioni in chiaro, e wss:, per connessioni criptate) per differenziarsi dall’HTTP classico. La peculiarità di questo nuovo protocollo è quella di essere stato progettato per lavorare bene con l’infrastruttura web già esistente; infatti, per mantenere la completa compatibilità con il protocollo HTTP classico, la connessione WebSocket inizia la propria vita come una connessione HTTP tradizionale. Il primo messaggio per effettuare l’handshaking è a tutti gli effetti una richiesta HTTP GET al server verso il quale si desidera aprire una connessione WebSocket. Questo messaggio iniziale contiene una richiesta di upgrade al protocollo WebSocket, nella forma: GET /resource HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: server.example.com:8080
Origin: http://examplesource.com
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Per essere totalmente retrocompatibili, la prima riga specifica una richiesta "HTTP/1.1 GET", mentre le successive due sono l’offerta di upgrade di cui si è parlato precedentemente. Seguono l’host e la porta alla quale si richiede la connessione e un campo di origine che indica il dominio che richiede la risorsa; in questo modo il server è informato dell’indirizzo dello script che ha generato la richiesta di connessione e può verificare se i messaggi provengono da una fonte autorizzata dai suoi protocolli di sicurezza. Infine, il server deve dimostrare al client di aver ricevuto il messaggio WebSocket, in modo che il server non accetti connessioni che non sono connessioni WebSocket. 127 Appendice Ciò impedisce ad un attaccante di ingannare un server WebSocket inviando pacchetti utilizzando XMLHttpRequest o form web. Per fare questo si utilizza la riga “Sec-­‐
WebSocket-­‐Key” che contiene una chiave generata in modo casuale codificata come stringa base64 di 16 byte. Il server decide di consentire l’upgrade di protocollo inviando il seguente header: HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
La prima riga indica l’http status, che vale 101 nel caso di handshaking avvenuto correttamente; qualsiasi altro codice ritornato in tale fase indica che il passaggio al protocollo WebSocket non è stato effettuato e quindi la connessione rimane su HTTP. Le successive due righe indicano che si sta eseguendo l’handshaking per l’upgrade verso il protocollo ws, mentre l’ultima riga contiene l’hash SHA-­‐1 calcolato sulla codifica base-­‐64 della concatenazione della “Sec-­‐WebSocket-­‐Key” del messaggio precedente con un identificatore chiamato Globally Unique Identifier. Grazie a questo campo il client potrà verificare se il server corrisponde a quello a cui è stata inoltrata la richiesta. Per evitare di appesantire la trattazione, per i dettagli tecnici viene consigliata la lettura della RFC64551225. Dopo che la fase di handshaking ha avuto esito positivo sia lato client che lato server, la connessione è stabilita e può partire la fase di trasferimento dati. Si è creato un canale di comunicazione full-­‐duplex nel quale il client e il server in maniera indipendente possono inviare informazioni. Per lo scambio di dati l’header HTTP non viene più utilizzato, in favore di un più agile header di soli 2 byte. Le informazioni sono inviate in unità chiamate messaggi. Ciascun messaggio è composto da uno o più frame. 25
http://tools.ietf.org/html/rfc6455 128 Appendice Senza entrare nel dettaglio della composizione dei differenti frame, si fa notare che ognuno è caratterizzato da un tipo specifico e ogni messaggio è costituito da frame tutti dello stesso tipo. I tipi di frame si possono racchiudere in tre categorie principali: frame testuali (in codifica UTF8), frame binari e frame di controllo. La connessione verrà chiusa semplicemente inviando, sia da parte del client che del server, un messaggio con un apposito frame di controllo indicante il termine della connessione. WebSocket API Le WebSocket API sono API JavaScript direttamente standardizzate dal W3C per accedere e gestire l’implementazione delle WebSocket del browser. Per utilizzare le WebSocket API è sufficiente istanziare, nel codice JavaScript della pagina web, l’oggetto WebSocket. Esso è relativamente semplice: possiede un costruttore, i due metodi principali per inviare messaggi e chiudere la connessione, un attributo che rappresenta lo stato della connessione e quattro handler che vengono invocati allo scatenarsi del rispettivo evento.Nel seguito si analizzeranno brevemente le componenti appena nominate senza scendere troppo nei dettagli, per cui si rimanda la lettura dell’apposita documentazione sul sito del W3C13 Per la connessione al server è sufficiente istanzare l’oggetto JavaScript apposito utilizzando il comando: var websocket = new WebSocket("ws://example.com:8080");
Una volta creata la variabile ed aperta la connessione è possibile inviare messaggi tramite il comando: websocket.send(data); e chiudere la connessione con: websocket.close(); L’oggetto “websocket” precedentemente creato, può essere associato ad alcuni identificatori di eventi speciali, come precedentemente accennato. Essi sono gli eventi “onopen”, “onerror”, “onmessage” e “onclose” 129 Appendice Il primo evento (“onopen”) si verifica nel momento in cui la connessione viene aperta. Il secondo (“onerror”) viene attivato in caso di errore durante la comunicazione, il terzo (“onmessage”) riguarda la ricezione di messaggi nel client, mentre l'ultimo (“onclose”) viene scatenato alla chiusura della connessione. Ad ogni gestore degli eventi dovrà essere associata una funzione contenente il codice da eseguire quando avviene l’evento corrispondente. Nell’esempio che segue, alla ricezione di un messaggio, viene mostrata una finestra di dialogo all’utente contenente il messaggio ricevuto dal server: //handler invocato alla ricezione di un messaggio
connection.onmessage = function (mex)
{
alert('Messaggio ricevuto: ' + mex.data) ;
};
Protocollo OAuth Il protocollo OAuth26 è utilizzato, all’interno di Sense.me, per l’autenticazione con i social network da parte dell’utente. Si tratta di un protocollo aperto, sviluppato da Blaine Cook e Chris Messina a partire dal 2006, che permette all’utente di dare l’accesso alle proprie informazioni presenti su un service provider, ad un consumer, senza però condividere le proprie credenziali con quest’ultimo. Ad esempio, Sense.me è il consumer, che riceve l’autorizzazione ad accedere a certe informazioni dell’utente presenti su Facebook (il service provider), senza che l’utente debba fornirgli il proprio indirizzo email e password. In figura è mostrato il funzionamento del protocollo. 26
http://oauth.net 130 Appendice Prima di eseguire il protocollo, il consumer deve essersi registrato presso il service provider, ottenendo due chiavi: consumer key e consumer secret. Il funzionamento, con riferimento ai numeri mostrati in figura, è il seguente: 1. Il consumer effettua la richiesta per l’access token, autenticandosi tramite consumer key e consumer secret. 2. Il service provider, verificata l’identità del consumer, emette il Request Token. 3. Il consumer reindirizza l’utente ad una pagina apposita del service provider, passandogli in inpu il Request Token. 4. L’utente si autentica con il service provider utilizzando le proprie credenziali, ed autorizza il consumer ad effettuare certe operazioni con le proprie informazioni. 131 Appendice 5. L’utente viene reindirizzato al consumer, al quale viene passato una stringa di verifica (Verifier). 6. Il consumer effettua la richiesta per l’Acess Token, utilizzando il Request Token e il Verifier. 7. Il service provider genera l’Access Token e lo invia al consumer. 8. Il consumer, utilizzando l’Access Token, potrà ottenere informazioni sull’utente, o effettuare azioni a suo nome, a seconda dei permessi concessi dall’utente al punto 4. B. G uida p er i l p rogrammatore Questa sezione vuole essere un punto di partenza per chi dovesse proseguire lo sviluppo di Sense.me. Hosting utilizzati L’architettura complessiva del framework è suddivisa tra tre server, ospitati su piattaforme di hosting diverse, che vengono ora descritte. Web Server L’applicazione web è raggiungibile, temporaneamente, all’indirizzo: http://www.fabiofilisetti.eu/sense.me Server Node.js Il server sviluppato in Node.js è ospitato sulla piattaforma Nodejitsu27. È raggiungibile all’indirizzo: http://senseme3-­‐sensemewebsocket3.nodejitsu.com 27
https://www.nodejitsu.com 132 Appendice Aprendo tale indirizzo con il browser, utilizzando i parametri di GET corretti, è possibile simulare l’accadimento di un evento sul prototipo, testando così il funzionamento del server e della pagina di test. La spesa mensile richiesta dall’hosting è a carico della TU Delft. Database Il database è ospitato sulla piattaforma db4free28, che offre gratuitamente MySQL e la sua gestione tramite interfaccia grafica mediante PHPMyAdmin. L’utilizzo di questa piattaforma è necessario per il fatto che il database è utilizzato dal web server e dal server Node.js, e l’hosting utilizzato per il primo offre un database, senza tuttavia la possibilità di accesso dall’esterno. Le limitazioni di db4free sono relative alle prestazioni, ed al fatto che si tratta di un server sperimentale, senza garanzie sulla continuità del servizio, come esplicitato chiaramente. Esse sono accettabili durante la fase di sviluppo, ma si consiglia di cambiare piattaforma per il prodotto finito. 28
http://www.db4free.net 133 Appendice Diagramma delle pagine Viene riportato il diagramma delle pagine, che consente di capire la relazione, in fase di runtime, tra i vari file costituenti l’applicazione web. Legenda: • Pagina di interfaccia con l’utente o Script PHP incluso nella pagina o Script JavaScript incluso nella pagina  Script PHP chiamato tamite AJAX dal file JavaScript  Pagina di interfaccia con l’utente, aperta dal file js (dentro un popup o come redirect) Nota: Per semplicità, gli script di carattere generale inclusi in molte pagine, e le librerie, sono stati omessi nel diagramma. Essi sono: • phpUtility/htmlComponents.php • phpUtility/ownerControl.php • phpUtility/database.php • phpUtility/tembooAuthentication/temboo/temboo.php • phpUtility/tembooAuthentication/credentials.php • CSS/* • js/jquery/* Diagramma delle pagine: • index.php o js/confirmLoginSignUp.js  phpUtility/ajax/login.php  phpUtility/ajax/signUp.php • prototypesList.php o phpUtility/prototypesListUtility.php o js/prototypesList.js  phpUtility/ajax/deletePrototype.php • phpUtility/deleteService.php  phpUtility/ajax/checkSettings.php • prototypeSettings.php o phpUtility/prototypeSettingsUtility.php o js/prototypeSettings.js  phpUtility/ajax/checkAllConfigured.php • phpUtility/prototypeClasses.php  phpUtility/ajax/generateCode.php  phpUtility/ajax/newEvent.php  phpUtility/ajax/deleteEvent.php 134 Appendice 
• phpUtility/deleteService.php phpUtility/sendFile.php • eventSettings.php o phpUtility/eventSettingsUtility.php o js/sensorsAssociation.js  phpUtility/ajax/sensorsAssociation/cloneSensorSettings.php  phpUtility/ajax/sensorsAssociation/addSensorSettings.php  phpUtility/ajax/sensorsAssociation/getSensorSettings.php  phpUtility/ajax/sensorsAssociation/controlSensorSettings.php  phpUtility/ajax/sensorsAssociation/editSensorSettings.php  phpUtility/ajax/sensorsAss…/editNumSensorSettings.php  phpUtility/ajax/sensorsAssociation/deleteSensorSettings.php o js/socialBehavioursAssociation.js  phpUtility/ajax/addBehaviour.php  phpUtility/ajax/getBehaviours.php  phpUtility/ajax/deleteBehaviour.php • phpUtility/deleteService.php  phpUtility/settingBehaviourDispatcher.php • newPrototype.php o js/confirmNewPrototype.js  phpUtility/ajax/addNewPrototype.php • profile.php o js/profileJS.js  phpUtility/ajax/updateProfile.php • testPage.php o js/testPage.js o js/socialNetworkConnection.js  phpUtility/ajax/getSocialNetworks.php  phpUtility/ajax/checkIfAuthenticated.php  phpUtility/tembooAuthentication/deleteSessionAuth.php  phpUtility/tembooAuthentication/logout.php  phpUtility/tembooAuth…/facebookAuthentication.php  phpUtility/tembooAuth…/twitterAuthentication.php  phpUtility/tembooAuth…/googlePlusAuthentication.php  phpUtility/tembooAuth…/googleCalAuthentication.php  phpUtility/tembooAuth…/foursquareAuthentication.php  phpUtility/tembooAuth…/instagramAuthentication.php • eventSettings/actionWithIdSettings.php o js/eventSettings/actionWithIdSettings.js  phpUtility/ajax/newSetting.php • eventSettings/calendarSettings.php 135 Appendice o phpUtility/publishFunct.php o js/eventSettings/calendarSettings.js  phpUtility/ajax/newSetting.php  phpUtility/getGoogleCalendars.php • eventSettings/publishSettings.php o phpUtility/publishFunct.php o js/eventSettings/publishSettings.js  phpUtility/ajax/newSetting.php • eventSettings/showSettings.php o phpUtility/showFunct.php o js/eventSettings/showSettings.js  phpUtility/ajax/newSetting.php  phpUtility/ajax/newKeywords.php • eventSettings/showTweetsSettings.php o phpUtility/showFunct.php o js/eventSettings/showTweetsSettings.js  phpUtility/ajax/newSetting.php  phpUtility/ajax/newKeywords.php • eventSettings/noSettings.php o js/eventSettings/noSettings.js  phpUtility/ajax/newSetting.php • passwordRecovery.html o js/forgotPassConfirm.js  phpUtility/ajax/checkMail.php  phpUtility/ajax/resendPassword.php 136 Riferimenti bibliografici [1] RFC6749 – “The OAuth 2.0 Authorization Framework.” Dick Hardt. October 2012. Retrieved 10 October 2012. http://tools.ietf.org/html/rfc6749 [2] Lieberman, H., Paternò, F. and Wulf, V. (2006). “End User Development”. Springer, Dordrecht. [3] Acerbis, A. “Interfacce utente espressive per il social networking: sviluppo di un’applicazione web a supporto della prototipazione fisica”. Tesi di laurea magistrale in Ingegneria Informatica, Università degli Studi di Brescia, 2013. [4] Lewis, C. H. (1982). “Using the ‘Thinking Aloud’ Method In Cognitive Interface Design (Technical report)”. IBM. RC-­‐9265. [5] Boehm, B. (1986), "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-­‐24. [6] Chen, P. P. (1976), “The Entity-­‐Relationship Model: Toward a Unified View of Data”, ACM Transactions on Database Systems. [7] Garrett, J. J. (2005). "Ajax: A New Approach to Web Applications". AdaptivePath.com. Archived from the original on 2 July 2008. Retrieved 19 June 2008. [8] RFC6455 – “The WebSocket Protocol”. I. Fette, A. Melnikov. December 2011. http://tools.ietf.org/html/rfc6455 [9] Nielsen, J., “Usability Engineering”, Academic Press, 1993. 137