iFame: Design, analisi e valutazione di un'applicazione per la mensa

Tesi di Francesco Maturi

Transcript

1. Università degli Studi di Trento Dipartimento di Ingegneria e Scienza dell’Informazione Laurea in Informatica Elaborato Finale IFAME DESIGN, ANALISI E VALUTAZIONE DI UN’APPLICAZIONE PER LA MENSA Relatore: Laureando: Prof.ssa Antonella de Angeli Francesco Maturi Correlatore: Dott.ssa Silvia Bordin Anno Accademico 2012-2013
2. 1 Vorrei ringraziare tutto il team di Smart Campus per avermi dato l’opportunità e i mezzi per realizzare al meglio, in un ambiente molto sereno, questa nostra idea. In secondo luogo desidero ringraziare Antonella e Silvia che mi hanno seguito durante tutto il percorso, iniziato ormai un anno fa, che si è concluso con la presente tesi. Devo ringraziare tutti i miei amici, coinquilini e compagni di università grazie ai quali mi ricorderò per sempre di questi tre anni fantastici passati assieme. Voglio fare un ringraziamento anche a tutta la famiglia di The Garden per avermi dato l’opportunità di realizzare esperienze bellissime. Un grazie va anche a tutta la famiglia della Civetta per tutti quei momenti passati assieme che resteranno indelebili nei miei ricordi. Un ringraziamento va poi a tutti i miei amici e amiche di Pinzolo e non solo, che conosco da una vita e che mi hanno permesso sempre di divertirmi, passare spensieratamente degli anni stupendi assieme a loro, condividendo esperienze fantastiche e combinandone praticamente di ogni. Voglio ringraziare in particolare i miei fratelli Rizot, Mario e Jeip che mi sono sempre rimasti vicini e su cui so che potrò sempre contare. Ringrazio i miei nonni e i miei zii per avermi supportato in ogni istante e per aver creduto in me. Un grosso grazie lo devo anche a Marianna per avermi sopportato in questo percorso. Un grazie gigante e un abbraccio enorme va ai miei fratelli di sangue Oscar e Lorenzo perchè hanno sempre dimostrato di esserci per me e per i quali ci sarò sempre. Per concludere ringrazio infinitamente i miei genitori per avermi sempre supportato, sopportato e sostenuto in ogni momento della mia vita. Senza loro e i loro insegnamenti certamente non sarei arrivato dove sono ora. Grazie a tutti. Di cuore.
3. 2 Sommario La tesi qui presente si prefigge come obiettivo l’analisi della realizzazio- ne, l’implementazione e la conseguente valutazione dell’applicazione “iFame”. Con questa applicazione vorremmo migliorare l’esperienza in mensa a tut- ti gli utenti che quotidianamente usufruiscono di questo servizio. Verranno esposte inizialmente tutte le diverse metodologie di sviluppo e valutazio- ne utilizzate durante la realizzazione di questo progetto. Si passerà poi ad analizzare il design in relazione anche all’ambiente interno al quale questo nostro progetto ha potuto concretizzarsi, ovvero la piattaforma di servizi per il cittadino Smart Campus. Sarà quindi tattato il processo di sviluppo del- l’applicazione, dal concepimento dell’idea fino alla sua realizzazione: passo passo verranno spiegate le problematiche che si sono incontrate durante tutto il percorso di creazione e come si è deciso di procedere per risolverle. Sa- ranno trattate le fasi di progettazione e sviluppo a partire dai primi mockup e dalle bozze di design fino all’effettiva implementazione della piattaforma su cui è basata “iFame”. Infine verranno riportati i dati ricavati dai primi mesi di sperimentazione effettiva sul campo per vedere così come gli utenti hanno risposto al rilascio dell’applicazione e in che modo hanno contribuito al successo di questo progetto.
4. Indice 1 Introduzione 6 2 Metodologie 8 2.1 Interaction Design . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2 User Centered Design . . . . . . . . . . . . . . . . . . . . . . 9 2.3 Partecipatory Design . . . . . . . . . . . . . . . . . . . . . . . 10 3 Analisi dei requisiti 12 3.1 Ricerca delle funzionalità . . . . . . . . . . . . . . . . . . . . 12 3.2 Requisiti funzionali e non funzionali . . . . . . . . . . . . . . 12 4 Primo prototipo di iFame 14 4.1 iFretta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2 iDeciso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3 iSoldi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4 iGradito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.5 Interviste, user-studies e valutazione . . . . . . . . . . . . . . 17 5 Dall’idea alla realizzazione 20 5.1 Partecipatory design contest . . . . . . . . . . . . . . . . . . . 20 5.2 Indagini Opera Universitaria e Eating in the canteen . . . . . 21 6 Secondo prototipo 23 6.1 Redesign e integrazione in Smart Campus . . . . . . . . . . . 23 6.2 Valutazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7 Prima versione Android 27 7.1 Dal mockup all’applicazione . . . . . . . . . . . . . . . . . . . 27 7.2 Valutazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 8 Seconda versione Android 31 8.1 Gestione delle recensioni . . . . . . . . . . . . . . . . . . . . . 35 8.2 Dati di utilizzo . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3
5. INDICE 4 9 Conclusioni 42 9.1 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6. Elenco delle figure 4.1 Mockup primo prototipo: home di iFame e iFretta . . . . . . . 15 4.2 Mockup primo prototipo: iDeciso . . . . . . . . . . . . . . . . 15 4.3 Mockup primo prototipo: iSoldi . . . . . . . . . . . . . . . . . 16 4.4 Mockup primo prototipo: iGradito . . . . . . . . . . . . . . . . 17 6.1 Mockup secondo prototipo: home e menu di iFame e iFretta . 24 6.2 Mockup secondo prototipo: dettaglio funzionalità di iFame . . 25 6.3 Mockup primo prototipo: home di iFame e iFretta . . . . . . . 26 7.1 Prima versione Android: iFame home e funzionalità . . . . . 28 7.2 Prima versione Android: componi il tuo menù e iFretta . . . 29 7.3 Prima versione Android: iSoldi e iGradito . . . . . . . . . . . 29 8.1 Seconda versione Android: iFame home e dettagli . . . . . . . 33 8.2 Seconda versione Android: iFretta . . . . . . . . . . . . . . . 34 8.3 Seconda versione Android: Integrazione di iGradito nei menù di iFame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.4 Seconda versione Android: Componi il tuo menù . . . . . . . 36 8.5 Percenuali di utilizzo delle diverse funzionalità offerte da iFame 37 8.6 Percentuali di utilizzo delle funzionalità in iGradito . . . . . . 38 8.7 Voti inseriti nelle recensioni . . . . . . . . . . . . . . . . . . . 39 8.8 Distribuzione delle recensioni nelle diverse mense di Trento . 40 5
7. Capitolo 1 Introduzione L’idea di realizzare “iFame” è nata durante il corso di Human Computer In- teraction, durante l’anno accademico 2012-2013, come progetto del gruppo di lavoro composto da Francesco Bonadiman, Desmond Agyeman, Nicola Parrello, Stefano Bozzi e me medesimo. Abbiamo sviluppato questo pro- getto con l’obiettivo di far fronte alla carenza di infrastrutture informatiche presente nei servizi di ristorazione offerti dalle mense universitarie. Siamo partiti valutando quali servizi rivolti agli studenti universitari potessero man- care, essere sviluppati ulteriormente o essere strutturati in modo alternativo. Così, dopo aver analizzando diverse situazioni abbiamo deciso di focalizza- re la nostra attenzione sul servizio riguardante la ristorazione. In questo modo volevamo favorire e agevolare l’utilizzo della mensa da parte di tutti gli utenti rivolgendoci non solo agli studenti universitari ma a tutti coloro che ne usufruiscono quotidianamente. Siamo partiti da un’attenta analisi dei requisiti e uno studio sulle funzionalità necessarie per la realizzazione di questa nostra idea. Abbiamo poi concentrato tutti i nostri sforzi nella realizzazione di questo originale modello di applicazione per smartphone che abbiamo deciso di chiamare ironicamente “iFame” fin dal principio. Grazie a questa nostra idea alternativa abbiamo anche avuto la possibi- lità di partecipare ad un design contest tenuto da Trentorise1, in particolare per il progetto Smart Campus2, volto ad integrare e realizzare proposte inno- vative di servizi informatici, non solo per gli studenti universitari bensì per il cittadino in generale. Il verdetto della giuria si è rivelato a favore di iFame e la nostra idea ne è uscita vincitrice. Un successo per noi in quanto ci è stata offerta la possibilità di realizzare concretamente questa nostra invenzione. Abbiamo permesso così alla nostra idea di compiere il passaggio da progetto ad applicazione reale potendo fornire un servizio effettivo a tutti gli utenti. “iFame” è diventata infatti un’applicazione per smartphone rivolta a tutti coloro che usufruiscono del servizio mensa offerto dall’Opera Universitaria 1Trento Rise, http://www.trentorise.eu/it 2Smart Campus, http://www.smartcampuslab.it/ 6
8. CAPITOLO 1. INTRODUZIONE 7 di Trento3. In questo modo è stata integrata e migliorata l’offerta di ser- vizi già presenti con interessanti novità da cui eventualmente ne può trarre vantaggio anche l’ente fornitore. La seguente tesi conterrà inizialmente un’analisi delle metodologie di pro- gettazione e di design. Saranno trattate quindi la progettazione centrata sull’utente e l’interaction design passando per i principi cardine dell’usabi- lità che uniti alla nostra creatività, fantasia e alle nostre necessità, quali utenti del servizio di ristorazione, ci hanno permesso di realizzare al meglio questo nostro lavoro. In seguito vedremo come “iFame” sia stata progettata seguendo i principi precedentemente elencati e come il processo di progetta- zione iterativo abbia permesso di raffinare sempre più un’idea che alla nascita risultava molto grezza. Verrà anche preso in considerazione l’ambiente al- l’interno del quale l’applicazione è stata realizzata, ovvero il progetto Smart Campus dell’ente Trentorise, ripercorrendo le linee guida di design ormai affermate che sono state accolte nello sviluppo della nostra applicazione. Sa- ranno trattate poi le varie iterazioni di re-design e ottimizzazione partendo dai primi mockup per arrivare al progetto ultimato, passando per tutto lo sviluppo e la crescita del design. Vedremo quindi come prenderà forma il lavoro grazie anche alle continue valutazioni effettuate, realizzate tramite diverse metodologie di interazione con gli utenti come interviste, osservazio- ni e questionari. Infine illustreremo brevemente la piattaforma web su cui si appoggia iFame e concluderemo riportando dati e valutazioni ottenuti in seguito al rilascio dell’applicazione a tutti coloro che sono stati coinvolti nel progetto Smart Campus. Realizzare iFame è stato un lavoro molto ampio, impegnativo e soddisfa- cente: siamo riusciti a realizzare un progetto completo e complesso partendo da un’idea molto semplice creando un prodotto che potrà essere utilizzato da tutti. Grazie alla realizzazione di tutto questo lavoro ho avuto la possibilità di imparare moltissime cose sia nelle fasi di progettazione che in quelle di im- plementazione. Ho potuto toccare con mano molteplici aspetti anche molto diversi tra loro partendo dall’analisi del design di un prodotto, passando per l’implementazione di un software all’interno di una piattaforma ben defini- ta per poi concludere anche con le problematiche legate alle normative che tutelano la privacy. Infine desidero affermare che, il confronto costruttivo, che è avvenuto con tutti i diversi membri sia del nostro gruppo ma anche all’interno del team di Smart Campus, è stata la cosa più importante e valo- rizzante dal punto di vista umano che mi ha dato quest’esperienza senza la quale tutto questo progetto non si sarebbe realizzato con tutta la serenità e la tranquillità con la quale è stato portato al termine. 3Opera Universitaria di Trento, http://www.operauni.tn.it/an
9. Capitolo 2 Metodologie In questa sezione verranno trattate le diverse metodologie di progettazione ed analisi per la realizzazione di sistemi che puntano ad ottimizzare l’usabilità in modo da poter fornire una migliore esperienza di utilizzo all’utente. In se- guito vedremo come questi modelli teorici sono stati concretamente applicati durante lo sviluppo della nostra applicazione iFame. 2.1 Interaction Design Iniziando a realizzare iFame ci siamo subito dovuti confrontare con diversi metodi di progettazione per capire quale fosse la migliore strada da percor- rere che avrebbe permesso il migliore risultato nei nostri intenti. La nostra sfida era quella di rendere possibile e facilitare al massimo l’uso e l’interazio- ne con il nostro sistema, in modo che dall’utilizzo della nostra applicazione ne derivasse un’esperienza piacevole e soddisfacente per l’utente. Durante il percorso di realizzazione di questa nostra idea abbiamo focalizzato il nostro lavoro in questa direzione cercando di elaborare e rifinire al meglio, tutto ciò che riguarda l’Interaction Design[12], ovvero la progettazione dell’intera- zione tra uomo e macchina per rendere il nostro sistema fruibile dall’utente finale in modo semplice e diretto. Ciò è stato reso possibile applicando al nostro lavoro diverse metodologie di progettazione, le quali saranno illustrate dettagliatamente nei capitoli successivi. Abbiamo dovuto affrontare e inte- grare nel nostro progetto i più comuni principi di usabilità come l’efficienza, l’efficacia o la facilità di apprendimento tenendo sempre in considerazione il contesto, l’utenza e l’ambiente nella quale iFame è inserita. Durante il pro- cesso di sviluppo abbiamo praticamente attraversato tutte le attività cardine dell’interaction design. Siamo partiti infatti dall’identificazione dei bisogni per stabilire i requisiti del progetto; abbiamo poi sviluppato proposte diverse di design che potevano rispondere alle specifiche precedentemente analizzate ed infine abbiamo costruito versioni interattive dell’applicazione. In questo modo abbiamo avuto la possibilità che queste potessero venir testate e valu- 8
10. CAPITOLO 2. METODOLOGIE 9 tate direttamente dagli utenti per ottenere così dei feedback importanti da tenere in considerazione anche per raffinare il nostro prototipo nelle successi- ve iterazioni di progettazione. Proprio questa metodologia di progettazione chiamata anche Iterative Design, in italiano progettazione iterativa, ci ha permesso di lavorare in modo ciclico alternando continuamente tutte le varie fasi di ricerca, analisi dei requisiti, design, creazione del prototipo, testing e infine valutazione. Siamo arrivati così ad un prodotto sempre meno grezzo progredendo di volta in volta in nuove sperimentazioni volte a confermare o smentire le proposte e le modifiche applicate ai nuovi prototipi, realizzate basandosi sulle precedenti osservazioni e valutazioni. In questo modo si va a chiudere il cerchio analizzando i feedback forniti dalle ultime sperimentazioni per passare poi al successivo perfezionamento del prototipo. 2.2 User Centered Design Fin dai primi passi del nostro lavoro è parso molto naturale utilizzare un modello di design e progettazione che ricopriva al meglio le nostre esigenze, rispecchiandone anche le necessità e forse, più che di un modello, è meglio parlare di un approccio generale alla progettazione che può essere concretiz- zato in diversi modi in funzione anche della natura dei prodotti da realizzare. Il metodo in questione, attraverso il quale è passato gran parte dello svilup- po di iFame è il cosiddetto User Centered Design ovvero la progettazione centrata sull’utente. Lo User Centered Design è un modo per progettare e costruire applicazioni software tenendo conto del punto di vista e delle esi- genze dell’utente. Lo UCD è un processo composto di più attività. Si basa sull’iterazione di diversi strumenti di analisi od osservazione, progettazio- ne e verifica. In italiano questo processo è noto anche come “Progettazione Centrata sull’Utente”. Questo approccio, come si può facilmente intuire già dal nome, mette l’utilizzatore, con i suoi bisogni, abitudini, comportamenti, punti di vista e esigenze specifiche, direttamente al centro del processo di progettazione. In questo modo, il progettista del sistema diventa, in primo luogo, progettista dell’interazione fra utente e sistema. Il processo di proget- tazione prende perciò spunto direttamente dai diversi casi d’uso specifici a differenza invece del metodo tradizionale, basandosi così non solo su un’ana- lisi diretta delle funzionalità che devono essere offerte dal sistema ma tenendo conto principalmente del punto di vista e delle esigenze specifiche dell’utente al quale il prodotto è rivolto. Questo modo di progettare e costruire prodot- ti è un processo composto di più attività. Si basa sull’interazione di diversi strumenti di analisi ed osservazione, progettazione e verifica. Il processo è stato definito e descritto da molti autori e vi sono diverse norme ISO come in particolare la norma ISO 13407 (Human centred design processes for in- teractive systems) nella quale viene elaborato molto bene questo concetto. Infatti secondo l’ISO 13407 [3]
11. CAPITOLO 2. METODOLOGIE 10 “la progettazione centrata sull’essere umano (human-centred de- sign) è un approccio allo sviluppo dei sistemi interattivi specifica- mente orientato alla creazione di sistemi usabili. È un’attività multi- disciplinare che incorpora la conoscenza e le tecniche dei fattori umani e dell’ergonomia. L’applicazione dei fattori umani e dell’ergonomia alla progettazione dei sistemi interattivi ne potenzia l’efficacia e l’efficienza, migliora le condizioni del lavoro umano e contrasta i possibili effetti av- versi dell’uso sulla salute, sulla sicurezza e sulle prestazioni. Applicare l’ergonomia alla progettazione dei sistemi richiede che si tenga conto delle capacità, delle abilità, delle limitazioni e delle necessità umane. I sistemi human-centred supportano gli utenti e li motivano a imparare. I benefici possono includere una maggiore produttività, una migliore qualità del lavoro, riduzione dei costi di supporto e di addestramento e una migliore soddisfazione dell’utente.” 2.3 Partecipatory Design Un altro approccio che si differenzia leggermente dallo UCD ma che allo stesso modo richiede la collaborazione attiva dell’utente è il Participatory Design ovvero la “progettazione partecipativa”. Mentre lo UCD richiede la partecipazione dell’utente solo nelle fasi di analisi dei requisiti e di valutazio- ne il PD coinvolge direttamente l’utente in tutto il processo di realizzazione. Questa metodologia di progettazione permette così all’utilizzatore, il quale è destinatario del prodotto sviluppato, di essere incluso attivamente in tutto il processo di progettazione, dallo studio dei requisiti passando per lo sviluppo e concludendo con la realizzazione del prodotto, col fine sia di contribuire alla creazione di un bene che incontri le sue necessità e i suoi bisogni ma anche di produrre un prodotto nel quale usabilità, produttività ed efficienza siano altamente ottimizzate. A questo punto però è necessario definire cosa intendiamo per usabilità. Secondo la normativa ISO 9241-11[4] l’usabilità è definita come “l’efficacia, l’efficienza e la soddisfazione con le quali determina- ti utenti raggiungono determinati obiettivi in uno specifico contesto d’uso” L’usabilità può essere definita in altre parole o in maniera più informa- le come una misura di qualità che valuta quanto e come le interfacce siano utilizzabili dall’utente in base a diverse dimensioni definibili come efficacia, efficienza, facilità di apprendimento, facilità di memorizzazione, sicurezza e robustezza all’errore. La maggiore usabilità di un sistema o di un prodotto porta con sé notevoli vantaggi aumentando efficienza, produttività, soddisfa- zione e la sicurezza con i quali un utente interagisce con esso riducendo allo stesso tempo gli errori e il bisogno di supporto. L’usabilità può inoltre essere misurata attraverso valutazioni sia oggettive, come l’analisi di dati derivanti dall’utilizzo del prodotto, che soggettive come questionari o interviste[11].
12. CAPITOLO 2. METODOLOGIE 11 Possiamo perciò definire in un certo senso lo sviluppo e la realizzazione di iFame un caso limite tra partecipatory design e user centered design poiché l’applicazione è stata concepita, sviluppata e realizzata completamente e di- rettamente dagli utenti finali alla quale è rivolta. Infatti noi, in primo luogo essendo studenti, fruiamo del servizio di ristorazione fornito dall’Opera Uni- versitaria. Ci ritroviamo perciò oltre ad applicare precisi e ben definiti stili di progettazione, descritti dettagliatamente anche in diverse ISO, ad essere coinvolti completamente nello sviluppo dell’applicazione poiché è frutto pro- prio delle nostre necessità e dei nostri bisogni in quanto utenti. Ritroviamo così nello sviluppo di iFame oltre all’applicazione di molteplici pattern di de- sign anche una conseguenza naturale creatasi nel nostro caso facendo sì che l’applicazione sia stata progettata appunto centrata sull’utente. Possiamo inoltre affermare che ciò rispecchia e si integra perfettamente con quella che è la filosofia del progetto Smart Campus, all’interno della quale iFame ha potuto concretizzarsi. Infatti alle basi di questo progetto vi è una filosofia di design partecipativo per la quale i servizi erogati sono pensati e realizzati tramite una stretta collaborazione e partecipazione alla realizzazione degli stessi utenti ai quali sono rivolti.
13. Capitolo 3 Analisi dei requisiti 3.1 Ricerca delle funzionalità A partire da questa sezione vedremo come sono state applicate le varie me- todologie trattate finora nello sviluppo di iFame. Partendo dall’analisi dei requisiti saranno attraversate tutte le fasi di progettazione, design e crea- zione del prototipo. Nella fase di analisi dei requisiti abbiamo dapprima analizzato noi stessi il caso, valutando le problematiche da risolvere o quali erano i servizi da migliorare all’interno del nostro progetto per poi elaborare un prototipo contenente tutte le considerazioni da noi effettuate. Questa prima parte del lavoro è stata svolta come coursework durante il corso di Human Computer Interaction per il quale abbiamo dovuto sviluppare ap- punto un prototipo che integrasse quanto appreso durante il corso con delle proposte di servizi innovativi sottoposti da noi. Il primo prototipo che ab- biamo realizzato era un mockup interattivo in formato pdf che racchiudeva tutti i requisiti necessari ottenuti dalle prime analisi del problema effettua- te dal nostro gruppo. I requisiti inizialmente sono stati rilevati abbastanza semplicemente pensando direttamente ai bisogni e ai servizi di cui noi stes- si, come effettivi utenti finali, avevamo bisogno. Abbiamo così sintetizzato, nella seguente successione di punti, i requisiti più importanti. 3.2 Requisiti funzionali e non funzionali 1. L’utente deve essere in grado di conoscere l’attuale affluenza di gente alla mensa 2. L’utente deve poter visualizzare il menù offerto dalla mensa 3. L’utente deve poter conoscere il suo credito presente sulla tessera con cui vengono effettuati i pagamenti in mensa 12
14. CAPITOLO 3. ANALISI DEI REQUISITI 13 4. L’utente deve poter conoscere le statistiche riguardo al suo utilizzo del credito presente nella tessera 5. L’utente deve aver chiarezza sulle varie composizioni di menù offerte dalla mensa 6. L’utente deve poter esprimere un’opinione sul cibo 7. L’utente deve poter valutare le pietanze consumate 8. L’utente deve poter conoscere l’opinione altrui 9. L’utente deve poter valutare l’opinione altrui 10. Sviluppo e mantenimento di una piattaforma per la gestione delle recensioni 11. Integrazione con i sistemi informatici dell’Opera Universitaria 12. Accesso alle webcam presenti e già installate nelle varie mense 13. Creazione di una piattaforma scalabile dove poter aggiungere eventual- mente nuove mense Inizialmente abbiamo tralasciato i requisiti non funzionali poiché in que- sta prima parte del progetto non venivano ad assumere un ruolo importante dato che l’implementazione effettiva del sistema non era ancora prevista nel lavoro. Assumeranno poi un ruolo fondamentale quando sarà il momento di creare l’infrastruttura sulla quale l’applicazione è basata, ma nella fase di design possiamo per ora tralasciarli. Ci siamo concentrati quindi sui requisiti funzionali in modo da progettare, strutturare e sviluppare al meglio tutte le funzionalità di cui aveva bisogno la nostra applicazione.
15. Capitolo 4 Primo prototipo di iFame Il frutto di questo lavoro iniziale è stato un primo mockup realizzato appunto per il corso di HCI ed è la sintesi delle scelte in termini anche di design ef- fettuate all’interno del nostro gruppo. Abbiamo ritenuto opportuno dividere l’applicazione in quattro sezioni differenti raggruppando cosi le diverse fun- zionalità uscite dal lavoro di analisi dei requisiti. Inoltre per mantenere una certa consistenza con il nome dato ad iFame abbiamo scelto in modo altret- tanto scherzoso i nomi delle diverse sezioni cercando sempre di concentrare e massimizzare anche in questi la significatività per permettere una migliore usabilità all’utente finale. 4.1 iFretta Con questa funzionalità cerchiamo di dare all’utente un modo per gestirsi il proprio orario della pausa pranzo vedendo direttamente la situazione al- l’interno della mensa per decidere quando sia il momento ideale per recarsi a pranzo. Questa funzionalità sfrutta il sistema di webcam già presente al- l’interno delle mense universitarie in quasi tutta la città di Trento rendendo così determinante la decisione dell’orario in cui andare in mensa per non trovarsi più, inconsapevolmente, di fronte a code chilometriche potendo in questo modo ottimizzare il proprio tempo. 4.2 iDeciso In questa sezione abbiamo voluto concentrare risposte chiare ed adeguate alle perplessità e alle difficoltà riscontrate durante l’utilizzo della mensa uni- versitaria. IDeciso quindi si occupa di mostrare all’utente le informazioni necessarie per il corretto utilizzo della mensa come possono essere le com- posizioni dei diversi menù offerti e il relativo prezzo. Inoltre in questa parte dell’applicazione abbiamo inserito le informazioni riguardanti il menù giorna- liero e quello mensile senza tralasciare le alternative sempre presenti in menù 14
16. CAPITOLO 4. PRIMO PROTOTIPO DI IFAME 15 Figura 4.1: Mockup primo prototipo: home di iFame e iFretta per coloro che hanno particolari bisogni nutrizionali come i vegetariani o i celiaci. Grazie a questa funzionalità l’utente ha più informazioni a disposi- zione che gli consentono di gestire e mantenere un’alimentazione equilibrata dando inoltre la possibilità di determinare il corretto apporto calorico in base alle proprie esigenze. Figura 4.2: Mockup primo prototipo: iDeciso
17. CAPITOLO 4. PRIMO PROTOTIPO DI IFAME 16 4.3 iSoldi Questa funzionalità risponde ad un problema molto comune che qualsiasi utente si trova ad affrontare quando utilizza carte di credito o ricaricabili e cioè la necessità di sapere sempre quale effettivamente sia la quantità di denaro disponibile su queste carte. Anche negli utilizzatori della mensa uni- versitaria abbiamo riscontrato questa necessità e abbiamo deciso di includere la possibilità di accedere alla propria carta direttamente dall’applicazione. L’utente è così informato del credito presente sulla sua tessera per evitare spiacevoli inconvenienti, sempre all’ordine del giorno quando è il momento di passare per la cassa. Inoltre questa funzionalità presenta molte altre in- formazioni e statistiche che abbiamo ritenuto importante includere per dare dei feedback all’utente in base al suo storico di utilizzo della tessera della mensa. In questo modo ognuno può accedere ai dati forniti come per esem- pio il quantitativo di denaro speso in un mese, la frequenza delle ricariche o l’apporto calorico dei pasti consumati, per poter gestire così in maniera più opportuna le proprie finanze e la propria dieta. Figura 4.3: Mockup primo prototipo: iSoldi 4.4 iGradito La possiamo definire come un servizio di feedback, una community volta a informare l’utente sull’opinione generale riguardo alle pietanze consumate in mensa. In questo modo si cerca di creare una coscienza di gruppo riguar- do ad uno dei punti più critici delle mense in generale poiché non sempre in relazione al prezzo offerto, solitamente molto accessibile, il risultato in termini di gradimento è ottimale. Ciò potrebbe essere incrementato se gli
18. CAPITOLO 4. PRIMO PROTOTIPO DI IFAME 17 utenti potessero condividere le loro esperienze riguardo l’utilizzo del servizio di ristorazione. Questa funzionalità ha come obiettivo quindi quello di diven- tare uno strumento utilizzabile per poter esprimere in modo ragionevole la propria opinione riguardo ai pasti consumati in mensa e confrontarsi così con tutti i membri della community. Ogni utente può così valutare in anticipo ogni scelta evitando spiacevoli imprevisti ed aumentando di conseguenza la positività del servizio usufruito. Le valutazioni raccolte tramite iGradito po- trebbero anche essere utilizzate direttamente dall’ente fornitore del servizio stesso per migliorarne ulteriormente la qualità e l’efficacia. Figura 4.4: Mockup primo prototipo: iGradito Tutta questa prima parte di lavoro, dall’analisi cioè alla progettazione, si è conclusa con la realizzazione del primo mockup interattivo, un prototipo con il quale si può rudimentalmente simulare l’interazione con l’utente della prima versione dell’applicazione. 4.5 Interviste, user-studies e valutazione Grazie al prototipo realizzato è stato possibile effettuare degli user- studies e delle interviste. In questo modo abbiamo potuto trarre una prima valutazio- ne esterna globale del nostro progetto. Il primo prototipo è stato sottoposto ad un gruppo di 25 persone molto differenti tra loro, sia per quanto riguar- da l’età, infatti comprese tra i 18 e i 60 anni, sia per quanto riguarda la formazione, stato sociale e istruzione. Questo campione di utenti, molto di- versificato, rispecchia abbastanza bene l’utenza alla quale iFame è rivolta. Essa infatti non solo è diretta ad un’utenza prevalentemente di studenti bensì sarebbe indirizzata a tutti coloro che utilizzano una mensa come servizio di ristorazione il che comprende professori, operai, dipendenti e anche persone esterne provenienti da altre aziende o persone comuni. Questo test ci ha permesso di valutare quindi il nostro prototipo in situazioni estremamente
19. CAPITOLO 4. PRIMO PROTOTIPO DI IFAME 18 differenti valorizzando così anche la solidità del test effettuato. Agli utenti è stato sottoposto un mockup interattivo in formato pdf con il quale era pos- sibile interagire tramite un computer. E’ stato così chiesto loro di svolgere determinate azioni per poter capire e valutare il grado di usabilità del nostro risultato. Le azioni che sono state sottoposte sono: 1. Visualizzare il menù del mese 2. Visualizzare il proprio credito residuo 3. Scrivere la propria recensione per il piatto “Anatre” 4. Visualizzare le info su “iFame” 5. Visualizzare le diverse tipologie de menù acquistabili 6. Visualizzare la coda alla mensa di Povo 7. Visualizzare le alternative al menù del giorno 8. Visualizzare i propri dati 9. Visualizzare l’elenco dei piatti da recensire 10. Inserire la recensione di un piatto 11. Comporre un proprio menù 12. Visualizzare le calorie dei vari piatti 13. Visualizzare il menù del giorno 14. Visualizzare le recensioni per il piatto “Anatre” 15. Visualizzare l’elenco delle webcams 16. Scegliere la lingua nella Home 17. Fare like/dislike sulla recensione di un altro utente Poiché è fondamentale per lo studio dell’interazione tra uomo e macchina conoscere quali siano i pensieri, le sensazioni e le emozioni sviluppati nell’u- tente durante l’utilizzo di un qualsiasi prodotto, abbiamo seguito durante questa sperimentazione il protocollo di analisi dell’usabilità definito “Think aloud”[6]. Questo metodo è largamente utilizzato per ottenere dati e feed- back durante la progettazione e il design di nuovi prodotti. I partecipanti ai test sono invitati a condividere a voce alta qualsiasi cosa stiano guar- dando, facendo, pensando o provando durante tutto lo svolgimento di un determinato compito. Contemporaneamente i cosiddetti osservatori devono
20. CAPITOLO 4. PRIMO PROTOTIPO DI IFAME 19 prendere nota oggettivamente di ogni cosa detta dall’utente. Il fine di que- sta metodologia di interazione è rendere esplicito cosa uno soggettivamente prova e soprattutto quali difficoltà incontra nel compiere uno specifico task. Abbiamo chiesto quindi agli utenti di esprimersi e raccontare i loro pensieri a voce alta in modo che noi sviluppatori potessimo entrare nei loro pensieri per capire meglio le loro reazioni di fronte ad una nuova proposta quale era la nostra. Tutti i dati raccolti sono stati riportati in un foglio Excel ed ordinati secondo i gradi della scala di valutazione dell’usabilità di Nielsen[9]. Abbiamo potuto così osservare che il problema più comune, fonte di di- versi problemi e fraintendimenti, riguardava il nome della funzionalità “iDe- ciso”. L’utente infatti nella maggior parte dei casi si è trovato molto confuso quando gli è stato chiesto di cercare il menù del giorno o il menù del mese, dovendo andare per esclusione o dovendo chiedere un aiuto perché proprio non in grado di associare il nome della funzionalità con il compito che gli è stato assegnato. Grazie a quest’esperienza e alla valutazione di tutti questi dati e problemi abbiamo potuto osservare meglio e con occhio critico il nostro operato. Inoltre questo test con gli utenti ha fornito importanti suggerimenti sia su come migliorare per rendere più intuitivo l’uso dell’applicazione che sulla aggiunta e rimodulazione di alcune funzionalità che noi stessi non ave- vamo contemplato nell’idea originale. Tutti questi suggerimenti sono stati inseriti nelle nuove versioni del prototipo e saranno analizzati nel dettaglio, in seguito.
21. Capitolo 5 Dall’idea alla realizzazione 5.1 Partecipatory design contest Dopo questa fase di sviluppo del primo prototipo, conclusa con la fine del corso di HCI, abbiamo avuto l’opportunità di presentare la nostra idea ad un Participatory Design Contest, ovvero un concorso di idee indetto da Smart Campus, un progetto dell’ente Trentorise. Smart Campus è un laboratorio di ricerca che mira a fornire soluzioni in campo informatico rivolte non solo ad un target universitario bensì a tutti i cittadini del territorio locale. Il progetto si basa su un approccio partecipativo, il che significa che i servizi sono sviluppati non solo dal laboratorio ma anche dalla gente che prende parte attivamente alla community proponendo nuovi servizi, soluzioni e idee. Il design contest è stato appunto realizzato in quest’ottica dove diverse proposte e idee innovative si sfidavano per poter andare ad arricchire il baglio di servizi già presenti. La nostra idea è stata accolta molto positivamente dalla giuria e ne siamo usciti vincitori. Abbiamo così avuto la possibilità di collaborare per sviluppare e realizzare concretamente questo progetto. La proposta di iFame si sposa benissimo con quest’idea di partecipazione, innovazione e realizzazione di servizi per lo studente e il cittadino. Il nostro lavoro si è rivolto inizialmente all’integrazione delle idee da noi proposte al- l’interno della piattaforma Smart Campus e in seguito all’implementazione effettiva dei diversi servizi. Abbiamo dapprima rivisto il nostro prototipo in funzione delle linee di design semplice e minimale, caratteristiche delle varie applicazioni già presenti nel set offerto da Smart Campus, per poi focaliz- zarci sulla realizzazione del client Android1 e della piattaforma di supporto all’applicazione. Durante lo sviluppo della nuova versione del prototipo sono stati quindi tenuti in considerazione gli standard propri di Smart Campus, dalla definizione dei colori da utilizzare, allo stile e al layout semplice e chiaro dei vari menù al fine di mantenere una certa coerenza con le diverse apps già realizzate dal lab. 1Android, http://www.android.com/ 20
22. CAPITOLO 5. DALL’IDEA ALLA REALIZZAZIONE 21 5.2 Indagini Opera Universitaria e Eating in the canteen Nello stesso periodo in cui abbiamo iniziato a prendere parte al progetto di Smart Campus sono state fatte, indipendentemente, due indagini riguar- danti le mense universitarie. La prima indagine è stata svolta direttamente dall’Opera Universitaria[10]. Tale indagine era volta a conoscere la soddisfa- zione degli utenti riguardo al servizio. Venivano infatti chieste valutazioni riguardo alla qualità e la quantità dei cibi, cottura e condimenti dei piatti, cortesia ed efficienza del personale, igiene e organizzazione dei locali. Vi era poi la possibilità anche per gli utenti di esprimere commenti o dare consigli su come migliorare il servizio offerto. Ci è stato possibile analizzare questi dati raccolti per cercare di offrire un servizio, il più completo possibile, agli utenti dell’applicazione. Abbiamo riscontrato infatti come solo il 5% valuta la qualità del cibo molto buona, il 54% abbastanza buona, il 30% poco buona e ben l’11% non buona. I risultati analizzati sono ancora peggiori nelle mense della collina con percentuali che giungono anche al 56% di persone che considerano non abbastanza buona la qualità del cibo fornito dalla mensa nell’ultimo pasto che hanno effettuato. Inoltre per quello che riguarda la quantità del cibo nella maggior parte delle mense il pasto viene dichiarato adeguato o abbondante da almeno il 50% dei suoi utenti. Nelle mense di Povo 1 e Mesiano il 54% degli interpella- ti dichiara che la quantità del loro ultimo pasto era scarsa. Diverse sono anche le lamentele riguardo alla cottura, in particolare dei primi piatti che non vengono cotti adeguatamente, secondo più del 50%. Problematiche che potrebbero essere risolte , almeno in parte, se un utente potesse leggere le recensioni fornite dagli altri utenti e decidere di conseguenza se prendere un primo piatto piuttosto che un secondo o un’insalatona. Un secondo sondaggio2 è poi stato creato direttamente da noi per valuta- re se le nostre opinioni sul servizio mensa erano più o meno condivise anche dagli altri e abbiamo così preparato una serie di domande generali che riguar- davano diversi aspetti del servizio mensa, dalla chiarezza delle informazioni ai problemi legati alle code nei momenti di maggior afflusso. Dall’analisi dei dati raccolti abbiamo potuto riscontrare che le problematiche da noi solleva- te venivano riscontrate anche dagli altri utilizzatori. Abbiamo infatti potuto notare, per esempio, come le tipologie di menu siano difficilmente comprensi- bili tramite i volantini dell’Opera Universitaria oppure come la maggior parte degli utenti ignorasse la presenza di alternative al menù giornaliero per colo- ro che sono vegetariani oppure celiaci. Abbiamo constatato che la maggior parte dei problemi che sorgono al momento del pagamento riguardano la 2Eating in the UniTn canteen!, Francesco Bonadiman 2013, https://docs.google. com/forms/d/16FVvTDrsL_u2jt24rN-Abg4WifC383puLjHVuUitZsY/viewform?edit_ requested=true
23. CAPITOLO 5. DALL’IDEA ALLA REALIZZAZIONE 22 mancanza di credito nella tessera e la mancata conoscenza delle tipologie di menù.
24. Capitolo 6 Secondo prototipo 6.1 Redesign e integrazione in Smart Campus Il design del nuovo prototipo è stato realizzato seguendo le linee guida del de- sign già consolidato di Smart Campus grazie anche all’aiuto dei loro esperti designer. Abbiamo così ridisegnato tutta l’applicazione utilizzando un solo colore tematico, il rosso, per contraddistinguerla dalle loro altre applicazioni già presenti. Partendo dalla home analizziamo ora le diverse novità intro- dotte. La prima che andiamo a trattare è la sostituzione del nome iDeciso che si è dimostrato di difficile comprensione, che ha spesso tratto in inganno gli utenti, fin dai primi test effettuati. Al posto di iDeciso abbiamo preso in considerazione diversi nomi che potessero sostituirlo cercando allo stesso tempo di massimizzarne l’intuibilità della funzione svolta. Diverse sono sta- te le proposte, dall’utilizzo di espressioni come iMenù, iScelto o iDubbi al riutilizzo del nome iFame. Dopo numerose valutazioni e scambi di opinioni interni al gruppo sulla base anche dei risultati dei primi user-studies abbia- mo deciso di riutilizzare il nome iFame per due ragioni precise: la prima è che tra i nomi proposti nessuno, al contrario di iFame, rendeva intuibile la descrizione della funzionalità e la seconda è che così facendo veniva da- ta maggior visibilità alla funzionalità che racchiude la maggior parte delle funzioni dell’applicazione. In seguito salta subito agli occhi la nuova dispo- sizione del menù con le funzioni ora posizionate in ordine cronologico ovvero nell’ordine in cui un utente andrebbe ad utilizzare il servizio mensa. Prima di tutte infatti troviamo iFame poi iFretta seguita da iSoldi e infine iGradi- to; in questo modo l’utente, dopo aver controllato il menù del giorno, può visualizzare la coda in mensa con iFretta, verificare il credito residuo nella tessera al momento del pagamento con iSoldi e infine una volta concluso il pasto può votare e recensire le pietanze con iGradito. Per concludere la trat- tazione della home, si può notare come le varie icone siano state realizzate in stile minimale e semplice dai designer di Smart Campus, rendendo sempre immediato e intuitivo l’utilizzo dell’applicazione. 23
25. CAPITOLO 6. SECONDO PROTOTIPO 24 Figura 6.1: Mockup secondo prototipo: home e menu di iFame e iFretta Sempre nell’ottica di integrazione e nell’intento di massimizzare l’usa- bilità dell’applicazione sono stati rivisti i vari sotto-menù sia in iFame che in iFretta. Questi infatti sono passati da essere bottoni inizialmente molto grezzi e colorati, a delle liste di opzioni molto chiare, semplici, immediate per ridurre al minimo la possibilità di errori da parte dell’utente. Dall’altra par- te è stata anche aumentata la consistenza e la appartenenza alle linee guida di design proprie di Smart Campus. Nella parte relativa al menù del giorno sono stati rivisti il posizionamento e l’etichetta del bottone che presenta le alternative al menù fisso. Infatti era emerso dai test effettuati sulla prima versione del prototipo come non fosse immediato accedere alle alternative. Sono così state create due tab: una per il menù del giorno e l’altra per le alternative, rendendo più funzionale l’utilizzo. La data, che si trovava prece- dentemente nella parte alta della pagina, è stata spostata nella action bar, separando così in modo chiaro il contenuto dai dettagli, favorendone la leggi- bilità e aumentandone la chiarezza. Il menù del mese è stato profondamente rivisitato, passando dalla versione precedente, dove veniva mostrato sempli- cemente il pdf fornito dall’Opera Universitaria, ad una formulazione comple- ta e più chiara. Il mese è stato scomposto nelle varie settimane, ponendo in alto una barra per navigare correttamente attraverso esse, e mostrando nella parte restante dello schermo il menù suddiviso nei i diversi giorni. Anche la parte dedicata alle informazioni riguardanti le diverse tipologie di menù è stata profondamente cambiata. Infatti le immagini mostrate hanno riscon- trato diversi problemi di usabilità e chiarezza durante i test perciò abbiamo riformulato la sezione dedicata alle tipologie suddividendola in tre diverse
26. CAPITOLO 6. SECONDO PROTOTIPO 25 tabs: oltre a un’ immagine rappresentativa posizionata nella parte alta dello schermo abbiamo aggiunto, nella parte restante, le informazioni riguardanti le diverse composizioni acquistabili dagli utenti, rendendo in questo modo molto più chiaro ed accessibile il menù. Figura 6.2: Mockup secondo prototipo: dettaglio funzionalità di iFame I cambiamenti maggiori sono stati effettuati in iGradito. La ricerca è stata integrata nella action bar aumentando così lo spazio utilizzabile per mostrare i piatti e il voto attribuito ad essi. Nella pagina delle recensioni ab- biamo deciso di valorizzare il voto e il numero di recensioni ponendo in alto queste due informazioni spostando così nella barra il nome del piatto. Sepa- rati da una label leggermente sotto troviamo le recensioni, che mostrano il commento, la data, e i like/dislike, ordinati di default per data ma ordinabili anche per numero di apprezzamenti/dissensi. Infine la schermata presente per aggiungere una recensione è stata rimpiazzata da una finestra di dialo- go che mostra oltre ai campi di inserimento del testo e della selezione della mensa, una barra con cui esprimere il voto rendendo molto più utilizzabile questa funzionalità, in un contesto mobile. 6.2 Valutazione La valutazione del secondo prototipo è stata realizzata tramite degli user- studies che hanno coinvolto un campione di circa 30 persone. Il campione di utenti a cui è stato sottoposto il prototipo era composto da 15 utenti di sesso femminile ed altrettanti di sesso maschile di età media che si aggirava intorno ai 23 anni. E’ stato chiesto loro di svolgere alcuni compiti utiliz- zando la versione interattiva del prototipo. I dati sono stati raccolti anche in questo caso tramite l’utilizzo del protocollo “Think aloud” grazie al quale
27. CAPITOLO 6. SECONDO PROTOTIPO 26 Figura 6.3: Mockup primo prototipo: home di iFame e iFretta abbiamo avuto molte delucidazioni sui diversi comportamenti assunti dagli utenti durante i test che sono stati svolti. L’analisi dei dati raccolti ha mostrato come quasi la metà degli utenti abbia svolto tutti i compiti senza alcuna difficoltà accedendo in modo imme- diato e diretto a tutte le funzionalità senza sbagliare o avere dubbi anche al primo accesso. Un minor numero di utenti (5) ha avuto problemi al primo accesso, trovando comunque subito dopo, una buona confidenza con l’app: sono stati inizialmente portati a cliccare sull’icona di iFretta durante lo svol- gimento dei primi task a causa del bottone col nome leggermente ingannevole. Alcuni utenti hanno poi avuto delle difficoltà per quello che riguarda la ri- cerca di un piatto in iGradito. Un fattore che potrebbe essere determinante nel manifestarsi di questo comportamento può essere la mancata familiarità in generale con i pattern di design specifici1 dell’ambiente Android piuttosto che un problema di usabilità relativo ad iFame. Allo stesso modo hanno avu- to un tentennamento iniziale quando è stato chiesto loro di aggiungere una recensione ad un piatto, proprio perché non si aspettavano il bottone nella Action Bar bensì all’ interno della schermata. Nel complesso i tester non hanno riscontrato difficoltà considerevoli di usabilità dandoci dei feedback molto positivi e una buona base su cui poter proseguire e migliorare il nostro percorso. 1Patterns | Android Developers, https://developer.android.com/design/patterns/ index.html
28. Capitolo 7 Prima versione Android 7.1 Dal mockup all’applicazione Una volta concluse le fasi di progettazione, design, realizzazione e testing del secondo mockup abbiamo iniziato l’implementazione sia client che server di tutta l’applicazione. In questa prima fase di sviluppo mi sono personalmente dedicato maggiormente allo sviluppo della parte server e a tutto quello che riguarda la connessione col server all’interno dell’applicazione. Durante tut- ta questa prima fase di implementazione del client il design non è cambiato e abbiamo cercato di attenerci il più possibile al modello sviluppato, proprio per evitare il sorgere di nuovi problemi di usabilità. Alcuni elementi sono stati adattati allo stile di Android sempre rispettando l’integrazione con le linee guida di design di Smart Campus. Sono stati eseguiti solo leggeri cam- biamenti, dati soprattutto dalla mancanza di informazioni strutturate alla partenza del nostro progetto e hanno fatto sì che, durante la creazione del client Android, andassimo a differire non in maniera importante dal mockup realizzato in precedenza. Non differire dalla versione precedente del prototi- po realizzato era importante per evitare l’insorgere di nuove problematiche relative all’usabilità della nostra aoolicazione e in secondo luogo poiché intro- ducendo un nuovo design in fase di implementazione saremmo andati contro tutti i fondamenti dell’iterative design. Infatti, prima avviene la fase di ana- lisi dei requisiti, poi la progettazione di diverse soluzioni che implementano i requisiti specificati seguita dalla creazione di un prototipo sulla quale infine vengono fatti i vari esperimenti di testing. Successivamente sull’analisi dei risultati si ripercorre un’altra iterazione di questo ciclo di progettazione per garantirsi sempre di rispondere alle necessità degli utenti in modo adeguato, strutturato e funzionale. Alcune funzionalità come la ricerca dei piatti per categorie in iGradito, a causa dell’assenza di dati strutturati, è stata rimossa lasciando spazio solo alla ricerca per nome. Anche l’ordinamento delle recensioni secondo diverse politiche di ranking, come era stato proposto durante la realizzazione dei 27
29. CAPITOLO 7. PRIMA VERSIONE ANDROID 28 Figura 7.1: Prima versione Android: iFame home e funzionalità prototipi non è stata portata al termine. I giudizi sono perciò stati ordinati esclusivamente per data di inserimento, in modo da valorizzare i commenti più recenti. Uno sviluppo futuro come era stato proposto inizialmente po- trebbe appunto essere la realizzazione di un algoritmo che ordini i commenti tenendo conto sia della data che della condivisione da parte degli utenti di quel opinione, ottenuta tramite l’analisi del numero di like o dislike ricevuti dallo specifico commento. Un’altra modifica che è stata apportata sempre in iGradito, a causa di un problema di progettazione del mockup, è stato l’inserimento nella prima schermata di un menù a tendina attraverso il quale si va a settare la scelta della mensa, permettendo così l’accesso alle visua- lizzazioni dei giudizi e alla possibilità di valutare un piatto, relativamente alla mensa settata. Non avevamo infatti preso in considerazione, durante la progettazione del prototipo, il fatto che le opinioni riguardo ad un determi- nato piatto sono specifiche alla mensa frequentata. Un ulteriore dettaglio che è stato rimosso, la maggiore semplicità di implementazione e scalabili- tà dell’applicazione, sono state le tab nella visualizzazione delle webcam in iFretta. Si è preferito trattare ogni mensa come un’entità unica perciò ogni webcam corrisponde ad uno specifico elemento nel menu iniziale di iFretta. A causa di alcune problematiche e soprattutto a causa dei ritardi riguar- danti la reperibilità dei dati provenienti da fonti esterne, come per esempio le composizioni dei menu, i dati relativi alle tessere della mensa e alle varie sta- tistiche che dovevano essere fornite dall’Opera Universitaria, non ci è stato possibile realizzare completamente iSoldi con tutte le funzionalità che ave- vamo previsto. Perciò nella prima versione questa sezione dell’applicazione era semplicemente la visualizzazione statica di quello che avevamo realizza- to nel mockup. Senza alcuna funzione effettiva veniva mostrato un credito casuale per anticipare all’utente quello che in futuro, una volta ottenuti i dati, sarebbe dovuto essere visualizzato. Le restanti funzionalità sono state implementate senza apportare ulteriori cambiamenti.
30. CAPITOLO 7. PRIMA VERSIONE ANDROID 29 Figura 7.2: Prima versione Android: componi il tuo menù e iFretta Figura 7.3: Prima versione Android: iSoldi e iGradito
31. CAPITOLO 7. PRIMA VERSIONE ANDROID 30 7.2 Valutazione La valutazione della prima versione si è sviluppata in due momenti diversi. Per prima cosa l’app è stata sottoposta a 15 utenti e è stato loro chiesto anche in questo caso di svolgere determinati compiti. Per mantenere una certa consistenza con i test effettuati in precedenza, anche in questo caso sono stati raccolti i dati tramite l’applicazione del protocollo “Think Aloud”. E’ stato sottoposto quindi a tutti gli utenti uno smartphone con l’applicazione installata e li abbiamo osservati mentre svolgevano i diversi task richiesti, aiutandoli e cogliendo le loro osservazioni per capire meglio i punti critici o di forza dell’app. Da questa prima fase di test non sono emerse particolari problematiche: tutti gli utenti interpellati hanno saputo compiere tutti i task in modo adeguato. In seguito vi è stata un’altra valutazione o meglio un vero e proprio stu- dio sul campo dell’applicazione. Anche in questo caso come nel precedente è stato consegnato agli utenti uno smartphone ma con degli obiettivi differenti. Prima erano stati sottoposti agli utenti una serie di task ben definiti ora in- vece la nostra intenzione era quella di vedere e di annotare come avvenissero le prime interazioni e quale fosse la reazione di un utente al primo utilizzo di questa applicazione. Durante questo studio sul campo quindi abbiamo appositamente lasciato all’utente la piena libertà di utilizzo dell’applicazio- ne. Ci siamo posti così come osservatori prendendo nota di quali fossero i problemi, le difficoltà o i commenti positivi che gli utilizzatori incontravano durante questi test. La maggioranza degli utenti si è mostrata molto contenta del lavoro da noi svolto fino a questo punto e i feedback ricevuti sono stati molto utili e ci hanno stimolati e motivati a proseguire nel nostro intento. Durante tutta questa fase di test è stata tenuta traccia di tutte le opinioni, dei feedback e delle perplessità espresse dagli utenti. Analizzando i dati raccolti si può subito notare che molti hanno davvero apprezzato l’utilità di un’applicazione che possa raggruppare tutti questi servizi. Abbiamo riscontrato inoltre la presenza abbastanza importante di una cosa comune a molteplici utenti. Essi infatti hanno notato come sarebbe più semplice ancora utilizzare l’app se almeno al primo ingresso vi fosse un tutorial che mostrasse velocemente tutte le funzionalità delle quali si può usufruire utilizzando iFame. Nonostante ciò la quasi totalità degli utenti ha trovato l’applicazione molto semplice e intuitiva a livello globale. Infine, solo alcuni utenti più avanzati, hanno fatto notare come non fossero integrate a loro volta le funzioni all’interno dell’app proponendo idee su come poter integrare per esempio iGradito con il menù del giorno. Le proposte sono state interessanti a tal punto che nella versione successiva dell’applicazione si è subito pensato di realizzarle effettivamente. A questo punto è iniziata la seguente iterazione nel percorso di progettazione di iFame.
32. Capitolo 8 Seconda versione Android Dopo la prima versione dell’app e successivamente sempre in quantità mag- giore, abbiamo iniziato a ricevere feedback proprio sul forum1 di Smart Cam- pus notando così il crescente interesse sviluppato intorno alla nostra idea . A questo punto una nuova iterazione nello sviluppo dell’applicazione è iniziata. Una volta raccolti tutti i feedback degli utenti riguardo alla prima versione dell’applicazione l’attenzione si è concentrata in diversi punti. Abbiamo mes- so assieme e preso in considerazione tutte due le valutazioni effettuate sulla prima versione dell’app per poi analizzarne i risultati e valutarne nuovamente le problematiche riscontrate. Dopo la prima versione dell’app e il successivo rilascio, in modo che venisse utilizzata effettivamente da un discreto numero di utenti della mensa, anche il forum di Smart Campus ha iniziato ad essere uno strumento importante per trasmettere direttamente a noi sviluppatori, feedback importanti. I problemi riportati sia dall’analisi dei test che dai vari feedback ricevuti sul forum li abbiamo concentrati praticamente in tre aspetti principali: 1. necessità di integrare le funzionalità meglio all’interno dell’applicazione 2. realizzare diversamente alcune funzionalità per avere un accesso più diretto specialmente per le azioni più comuni e che si ripetono mag- giormente come l’accesso alle webcam 3. migliorare la chiarezza sia nella composizione dei menu sia per la ricerca dei piatti in iGradito. Dopo aver preso in considerazione tutte le opinioni ricevute abbiamo ana- lizzato dettagliatamente le funzionalità per cercare di integrarle al meglio ove possibile. Abbiamo trovato molto utili i consigli riguardo all’integrazione di iGradito con iFame in modo da poter recensire le pietanze oppure di visualiz- zarne le recensioni direttamente durante la visualizzazione del menu offerto. 1Smart Campus forum, http://www.smartcampuslab.it/forum/ 31
33. CAPITOLO 8. SECONDA VERSIONE ANDROID 32 In secondo luogo l’attenzione è stata posta sulla riduzione delle interazioni ri- chieste all’utente per svolgere determinati compiti. Sono stati pensati diversi modelli per accedere in modo più diretto alle funzionalità utilizzate più fre- quentemente come iFretta o la visualizzazione delle recensioni. Avendo ormai acquisito una certa dimestichezza nello sviluppo nell’ambiente Android, non è stato necessario sviluppare un mockup anche questa volta. E’ stata creata una versione alpha dell’applicazione nella quale siamo andati ad inserire le nuove idee sorte. Come fosse un mockup abbiamo realizzato questa versione a stretto contatto con i designer di Smart Campus i quali ci hanno aiuta- to e indirizzato verso le soluzioni migliori. Finalmente poi abbiamo anche ottenuto accesso ai sistemi dell’Opera Universitaria in modo da poter par- zialmente andare a realizzare le funzionalità che avevamo previsto come per esempio iSoldi. Nella seconda versione di iFame infatti l’utente può visualiz- zare direttamente sul suo smartphone il credito presente sulla tessera della mensa, acquisendo così vitali informazioni riguardo l’utilizzo della mensa e evitando spiacevoli inconvenienti se il credito non fosse sufficiente. Essendo un accesso ancora in fase di sviluppo e non avendo avuto alcun chiarimen- to da parte dei fornitori sul tipo di dati a cui potevamo collegarci è stato deciso di tralasciare inizialmente la parte delle statistiche per concentrarci solo sul credito residuo. La visualizzazione di statistiche o dati più appro- fonditi può essere un valido spunto eventualmente per degli sviluppi futuri. L’implementazione di questa funzionalità si è limitata quindi a mostrare il credito residuo all’utente e le diverse tipologie di menù acquistabili con quel determinato credito fornendo messaggi di avvertimento in caso questo fosse basso o avesse bisogno di una ricarica. Abbiamo lasciato l’integrazione con iFame infatti l’utente può vedere il nome della tipologia del menù corrispon- dente a quello che può acquistare e cliccandovi sopra viene rimandato alla spiegazione dei dettagli nella sezione relativa in iFame. Ritornando allo sviluppo di questa nuova versione ora vediamo come sono stati migliorati i problemi riscontrati. Durante l’analisi di questi cambiamen- ti per rendere tutto possibile abbiamo dovuto aggiungere una funzionalità intrinseca ma di per sé questa si è ritrovata benissimo nell’ottica di migliorare ulteriormente l’esperienza utente. Abbiamo visto infatti come per un utente sia costante l’utilizzo di una mensa specifica, sono infatti pochissimi colo- ro i quali utilizzano abitudinariamente mense diverse. Alla base di questa constatazione e con la volontà di velocizzare e migliorare l’accesso alle varie funzionalità abbiamo definito il bisogno di realizzare una funzionalità che corrisponda al settaggio di una mensa preferita all’interno dell’applicazione. Questa funzionalità è stata integrata perfettamente nella home accessibi- le tramite l’icona a stella, pattern classico nella selezione delle preferenze personali dell’utente. Inoltre per semplificare al massimo l’impiego da par- te dell’utente, al primo utilizzo viene chiesto automaticamente quale sia la mensa preferita.
34. CAPITOLO 8. SECONDA VERSIONE ANDROID 33 Figura 8.1: Seconda versione Android: iFame home e dettagli Questo primo cambiamento porta con sé ulteriori migliorie all’interno di tutta iFame. Partendo da iFretta è stato possibile infatti rendere immediato l’accesso alla visualizzazione della webcam. Infatti grazie all’impostazione predefinita l’utente entrando in iFretta potrà subito visualizzare la webcam corrispondente alla mensa abituale, invece che dover selezionare tutte le volte la mensa preferita. Un miglioramento ulteriore è stato apportato grazie a questo cambiamento poiché ora un utente invece di dover entrare e uscire dalla funzionalità per cambiare la webcam da visualizzare può, direttamente dalla stessa schermata grazie allo spinner posizionato nell’action bar, passare facilmente da una webcam all’altra. Questa scelta di mettere lo spinner nella action bar ripercorre un pattern di navigazione molto comune all’interno della piattaforma Android. Allo stesso tempo però non è un pattern comune nelle applicazioni Smart Campus ma ugualmente si abbina molto bene allo stile minimalista necessario per integrarsi tra le varie applicazioni presenti nell’ecosistema di Smart Campus. Inoltre sono stati risolti due problemi riscontrati, ovvero la leggibilità del testo riportato sull’immagine della webcam nel fuori orario e la pessima visualizzazione in modalità landscape che era uscita dalla prima implementa- zione dell’app. E’ stata infatti aggiunta una dicitura nella parte bassa dello schermo in cui vengono riportati gli orari della apertura delle mense ovvero delle dirette delle webcam. La modalità landscape è stata migliorata intro- ducendo una differenza di composizione del layout in base all’orientamento dello schermo. L’immagine invece di essere nella parte alta dello schermo viene spostata a sinistra prendendo solo una parte di questo mentre alla sua destra è riportata l’informazione riguardante gli orari.
35. CAPITOLO 8. SECONDA VERSIONE ANDROID 34 Figura 8.2: Seconda versione Android: iFretta Gli altri cambiamenti riguardano più l’integrazione tra le diverse funzio- nalità che offre iFame. La prima che andiamo a citare risolve delle proble- matiche riscontrate durante gli ultimi user testing. Infatti era un problema visualizzare le recensioni per un piatto che era presente nel menu del giorno poiché richiedeva numerosi passaggi in cui l’utente si poteva perdere tra una funzionalità e l’altra. La soluzione proposta è stata quella di modificare la schermata di dialogo, già presente al click dell’utente su un qualsiasi piatto, aggiungendo diverse opzioni che permettono ora di visualizzare direttamente le recensioni relative a quel piatto oppure permettono di inserirne una nuova senza, in entrambi i casi dover uscire ed entrare in iGradito ma la funzio- nalità è stata integrata in modo da avere un flusso nelle azioni molto più scorrevole e l’usabilità ne trae un grosso vantaggio generale. La terza modifica sostanziale dalla precedente versione è stata effettuata nella sezione relativa alla visualizzazione e composizione del menu. In questa sezione l’utente può vedere le diverse composizioni di menù disponibili e ca- pire quali piatti corrispondono ad un menu intero piuttosto che snack poiché come abbiamo potuto testare con la nostra esperienza in mensa, le infor- mazioni fornite dall’Opera Universitaria a riguardo sono molto confusionarie e complesse da leggere e necessitano un interpretazione, cosa che abbiamo voluto rendere disponibile a tutti tramite la creazione di questa funzionalità. Infatti è stata pensata fin dalla nascita per essere più chiara ed esplicativa possibile ma nonostante la buona riuscita del primo design abbiamo avuto conferme nei test che si poteva fare meglio. In più con il successivo cambia- mento alla composizione dei menù dell’opera un aggiornamento andava fatto e così è stata colta l’occasione. La lista unica di possibilità da cui scegliere è stata divisa nelle varie tipologie. Abbiamo cosi ridisegnato meglio il layout utilizzando tutto lo schermo, evitando tutti gli spazi vuoti presenti nella vec- chia versione. Inoltre le numerose nuove opzioni sono rappresentate in una
36. CAPITOLO 8. SECONDA VERSIONE ANDROID 35 Figura 8.3: Seconda versione Android: Integrazione di iGradito nei menù di iFame griglia chiara senza lasciare troppo spazio all’interpretazione. Invece il co- mando che regola l’accesso è rimasto nella parte bassa dello schermo poiché chiaro e molto visibile. Anche la parte dove vengono rappresentate le diverse tipologie ha subito un leggero redesign per ottimizzare gli spazi e rendere ancora una volta più chiara la composizione. Sono state introdotte anche per coerenza con il resto dell’applicazione, delle etichette rappresentanti il nome della tipologia di menu, separando così meglio le diverse composizioni e rendendo più leggibile il tutto. L’ultima variazione che è stata realizzata, sia per una maggiore unifor- mità con le linee guida di Android che per la risoluzione di problemi legati all’usabilità, anche le schermate di caricamento sono state completamente riviste togliendo gli ormai sempre meno utilizzati ProgressDialog e sostituiti con il pattern di Android che tutti sono abituati a vedere permettendo così una migliore navigazione. 8.1 Gestione delle recensioni Dare la possibilità agli utenti di esprimere la propria opinione con dei com- menti liberi apre le porte a diverse problematiche legate all’utilizzo che può essere fatto di questa opportunità. E’ stata quindi una necessità pensare ad un sistema che permetta il controllo dei commenti per evitare abusi della libertà di espressione lasciata agli utenti. La moderazione è stata sviluppata all’interno di Smart Campus come un ulteriore modulo all’interno della piat- taforma già ricca di servizi, al quale noi, sviluppatori di iFame, siamo andati ad appoggiarci per gestire proprio la problematica relativa alla moderazione.
37. CAPITOLO 8. SECONDA VERSIONE ANDROID 36 Figura 8.4: Seconda versione Android: Componi il tuo menù Abbiamo infatti sfruttato le API presenti per interagire con il moderatore dal server web che gestisce i commenti e al quale si appoggia l’applicazio- ne. La moderazione avviene in due diversi momenti: vi è un filtro primario che agisce tramite software analizzando il commento e facendo matching con delle keywords presenti nel nostro database per evitare che vi siano parole non gradite. Le keywords sono gestite manualmente da un amministratore incaricato di tenere aggiornato il database con parole sgradite che non si vuole siano presenti nei commenti. In secondo luogo passato questo primo filtraggio il commento viene passato alla console di moderazione dove sempre un amministratore può manualmente filtrare, se ritiene inopportuni, ulterio- ri commenti passati al precedente filtraggio. Queste due funzioni sono state realizzate utilizzando le Mediation API offerte da Smart Campus e integra- te in modo che quando un utente da iFame interagisce con il server, siano chiamate e facciano da filtro e controllo delle recensioni. 8.2 Dati di utilizzo La seconda versione di iFame non ha subito lo stesso percorso di testing che hanno avuto i prototipi e la prima versione. È stata rilasciata infatti a tutti gli utenti iscritti al progetto Smart Campus, dopo aver superato dei test au- tomatizzati effettuati durante le ultime fasi di sviluppo , volti più che altro a scovare eventuali malfunzionamenti e bug dal punto di vista implementativo piuttosto che problematiche o criticità relative all’usabilità dell’applicazione stessa. Abbiamo così potuto analizzare i dati prodotti direttamente dall’u- tilizzo dell’applicazione per valutare le diverse funzionalità e vedere cosa sia preferito o meno dagli utenti. Analizzando i dati raccolti dall’utilizzo del-
38. CAPITOLO 8. SECONDA VERSIONE ANDROID 37 l’applicazione, cioè i vari dati di log dei server e i dati relativi ai commenti delle pietanze, presenti nel database di iFame, effettuati dagli utenti tra fine novembre e fine gennaio, abbiamo potuto fare alcune statistiche sull’utilizzo effettivo. Sono stati presi in considerazione diversi aspetti o meglio abbiamo ricercato le funzionalità più o meno utilizzate, le mense che sono state più coinvolte nelle recensioni anche i voti dati alle diverse recensioni che ci pos- sono indicare approssimativamente un indice di gradimento delle pietanze. Dai dati analizzati è emerso che, come si può notare anche dall’immagine del grafico, le funzionalità più utilizzate, che ricoprono quasi il 75% dell’utilizzo globale dell’applicazione, sono state principalmente quattro: iFretta, iSoldi, iGradito per visualizzare le recensioni e la consultazione del menù del giorno. Figura 8.5: Percenuali di utilizzo delle diverse funzionalità offerte da iFame Un po’ di stupore è seguito all’analisi dei dati relativi all’utilizzo della funzionalità iGradito. Infatti per la maggior parte, cioè quasi l’80%, l’utilizzo si è limitato alla consultazione delle recensioni presenti, mentre solo in parte è stata colta l’opportunità di esprimersi tramite una recensione, il 13,3% oppure tramite il like/dislike di una recensione 7,2%. Per quello che riguarda il numero di recensioni inserite tra fine novembre e fine gennaio ne abbiamo registrate quasi 150 per l’esattezza 146 che sono state inserite da 43 utenti. Perciò nonostante dall’immagine precedente si noti come sia stata preferita la consultazione delle recensioni piuttosto che l’espressione di un giudizio , abbiamo raccolto lo stesso un notevole numero di opinioni. Abbiamo poi valutato i diversi like e dislike e sorprendentemen- te si è notato come fossero presenti solo likes sui 36 like registrati. Sempre
39. CAPITOLO 8. SECONDA VERSIONE ANDROID 38 Figura 8.6: Percentuali di utilizzo delle funzionalità in iGradito analizzando i dati di iGradito abbiamo visto come gli utenti si sono espressi tramite i voti dati alle recensioni delle pietanze. Dalle analisi abbiamo otte- nuto dei dati molto interessanti poiché si è potuto vedere come circa il 70% dei voti sia stato sopra il 6 in una scala che andava da 0 a 10. Nonostante i 6 siano poco sopra il 20% e sia il voto che è stato maggiormente condiviso dagli utenti il secondo voto per condivisione è stato il 10. Infatti il 16,4% degli utenti ha messo delle recensioni con un voto pari a 10 mentre l’ultimo gradi- no del podio se lo aggiudica il 7 con una condivisione pari al 15,8% seguito subito dopo per il 15,1% dal voto 8. I voti negativi o meglio che vanno dal 5 allo 0 compreso, non hanno riscontrato un grande appoggio infatti la somma di tutti questi raggiunge solo il 23,3% il che equivale al 6 da solo e con una presenza importante determinata dai 5 ovvero del 7,5%. Resta comunque un dato abbastanza rilevante che circa il 15% non apprezza proprio le pietanze distribuite nella mensa infatti è questa la percentuale raggiunta dai voti che vanno dallo 0 al 4. Abbiamo potuto poi vedere anche come i giudizi fossero distribuiti tra le diverse mense di tutta Trento. Prima di analizzare questi dati è importante tenere presente il fatto che l’applicazione è stata sottoposta a tutti gli uten- ti di Smart Campus che per la maggioranza sono studenti di informatica e perciò si può facilmente prevedere quale sia la mensa che ha ricevuto il mag- gior numero di recensioni. Come previsto si può notare che più della metà delle recensioni inserite dagli utenti sia riferita alle pietanze distribuite nelle mense a Povo. E’ comunque considerevole la partecipazione degli studenti
40. CAPITOLO 8. SECONDA VERSIONE ANDROID 39 Figura 8.7: Voti inseriti nelle recensioni di Ingegneria che frequentano la mensa di Mesiano infatti quasi il 30% delle recensioni è riferito appunto alla mensa che opera a Mesiano. Un’ altra fetta, seppur molto minore, cioè pari al 12,3% dei giudizi, ha interessato la mensa in via Tommaso Gar mostrando comunque di aver riscosso un certo interesse e partecipazione anche nelle mense non in collina. E’ stata effettuata poi un ‘altra analisi dei commenti che va oltre il sem- plice voto dato al piatto. Infatti agli utenti è stata data la possibilità di esprimersi anche attraverso un commento e ciò ha reso necessario come ab- biamo detto precedentemente, la necessità di una moderazione di questi, per evitare l’utilizzo di una terminologia inappropriata. Una prima anali- si l’abbiamo ottenuta grazie alla presenza di un moderatore software che blocca eventuali contenuti offensivi analizzando la presenza di parolacce o meno all’interno dei commenti. Guardando i commenti bloccati dal mode- ratore abbiamo positivamente potuto riscontrare che solo un utente si era espresso utilizzando termini non adatti al contesto, mentre la quasi totalità degli utenti hanno correttamente espresso la loro opinione. Sicuramente dati positivi e incoraggianti, probabilmente la positività di questa valutazione è anche data dalla presenza di un login con le credenziali universitarie che ha smorzato eventuali utilizzi inappropriati di iGradito. La seconda analisi è stata effettuata andando a leggere direttamente tutti i commenti presenti per poter vedere la positività o negatività che esprimevano in relazione al voto dato. I commenti letti hanno pressoché rispettato le aspettative infatti in com-
41. CAPITOLO 8. SECONDA VERSIONE ANDROID 40 Figura 8.8: Distribuzione delle recensioni nelle diverse mense di Trento binazione ai voti alti avevamo commenti molto positivi mentre per i voti bassi i commenti erano piuttosto negativi. Alcune eccezioni sono state rilevate nei voti presenti nella parte centrale della scala di valutazione. Infatti due va- lutazioni a cui è stato assegnato il voto 5 avevano associato un commento che lasciava trasparire positività definendo la pietanza in un caso addirittura ottima. Leggermente diversa la situazione per le pietanze che hanno ricevuto un voto pari a sei, infatti in questo caso possiamo notare come la positività e la negatività dei commenti si siano divisi in due grandi gruppi. Metà degli utenti che hanno recensito una pietanza con un 6 lasciano trasparire una certa positività dal commento mentre l’altra metà dei giudizi ha si un voto sufficiente ma il commento ha un accezione chiaramente negativa. Sempre analizzando i piatti che sono stati recensiti si è potuto vedere co- me sulle 146 recensioni che sono state inserite, ben 65 riguardavano i secondi (44,5%) seguite da 43 che riguardavano i primi (29,5%) e infine 38 riguar- danti i contorni (26%). Per quel che riguarda l’utilizzo dell’applicazione è stato possibile analizzare e visualizzare in che periodi sono state effettuati maggiormente gli accessi e in che periodi siano stati coinvolti gli utenti nel- l’inserimento e nella valutazione dei piatti. Come si può immaginare l’utilizzo maggiore dell’applicazione è avvenuto in un periodo in cui gli studenti erano ancora impegnati in città per seguire le lezioni poiché durante il periodo degli esami e delle vacanze natalizie gli studenti tornano a stare nelle proprie zone di provenienza. Infatti a confermare questa ipotesi abbiamo avuto una quasi totalità degli accessi durante il periodo tra novembre e dicembre mentre a
42. CAPITOLO 8. SECONDA VERSIONE ANDROID 41 gennaio l’utilizzo dell’applicazione è notevolmente calato. Durante il perio- do delle lezioni sono stati infatti effettuati il 97% degli accessi mentre solo il 3% della cifra complessiva sono stati effettuati durante il mese di gennaio. Anche per quello che riguarda le recensioni abbiamo dati che confermano questo trend. Infatti ben 130 recensioni su 146 sono state effettuate entro la fine del periodo delle lezioni mentre solo le restanti 16 durante il periodo di esami cioè a gennaio dopo le vacanze di Natale.
43. Capitolo 9 Conclusioni Questa tesi ha seguito tutto il processo di design, analisi, implementazione e valutazione dell’applicazione iFame, realizzata per essere di supporto all’u- tente nell’utilizzo dei servizi di ristorazione forniti dall’Opera Universitaria di Trento. Partendo dall’analisi delle metodologie di Iterative Design, User Centered Design e soprattutto Partecipatory Design abbiamo analizzato e visto come siano state applicate ad un caso reale, lo sviluppo di iFame. La realizzazione di questo progetto ha permesso la concretizzazione di un idea nata e rivolta agli studenti stessi mostrando come le proprie conoscenze e le proprie idee possano essere direttamente applicate sul campo per esse- re di supporto alla vita di tutti i giorni. Tra i risultati più particolari che abbiamo ottenuto durante questo percorso è da citare sicuramente la diver- sità dei dati raccolti in questi mesi passati dal rilascio dell’applicazione da quelli raccolti dall’Opera Universitaria nel questionario precedentemente ci- tato. Avendo letto l’indagine[10] effettuata dall’Opera Universitaria, sulla soddisfazione degli utenti del servizio di ristorazione, si era notato come più della metà degli utenti, arrivando al 56% nelle mense in collina, considerava- no non abbastanza buona la qualità del cibo fornito dalla mensa, nell’ultimo pasto che avevano effettuato. Dei risultati diametralmente opposti sono usci- ti dall’analisi dei commenti e dei voti presenti in iGradito. Ovviamente in queste considerazioni dobbiamo tenere presente anche l’ampiezza del cam- pione analizzato. Infatti a differenza delle 4234 persone che hanno risposto al sondaggio, noi abbiamo avuto la possibilità di analizzare solo 150 opinioni. Era normale perciò, avendo analizzato l’indagine sopracitata, aspettarsi dei risultati in linea con questo sondaggio, cosa però che non è accaduta. Infatti dai risultati da noi ottenuti circa il 70% degli utenti ha dato voti superiori alla sufficienza mostrando un netta positività nei confronti della mensa molto criticata nelle precedenti inchieste. In questo modo possiamo affermare che la condivisione di opinioni, sia positive che negative, può aumentare la soddi- sfazione negli utenti riguardo alla fruizione di un servizio quale può essere la mensa. Speriamo che questo progetto diventi così un contributo importante 42
44. CAPITOLO 9. CONCLUSIONI 43 per continuare a migliorare tutti i servizi quotidianamente utilizzati dalla gente. Inoltre che l’anima open source di tutto questo progetto dia vita a nuovi contributi per incrementare e migliorare i servizi offerti. Gli studenti che hanno potuto prendere parte al progetto contribuendo a tutta la fase di test e coloro che sono stati interpellati durante lo sviluppo si sono dimostrati generalmente molto entusiasti di iFame e si augurano un rilascio finale ed ufficiale entro breve periodo. Dai loro feedback abbiamo potuto percepire come fosse mancante un’applicazione del genere e speriamo diventi al più presto condivisa su larga scala per poter dare accesso a chiunque ai servizi offerti migliorando così l’esperienza giornaliera di ogni persona. 9.1 Sviluppi futuri Per eventuali sviluppi futuri sarebbero molte le cose da prendere in con- siderazione. Citandone alcune tra le più importanti possiamo dire che la realizzazione di un supporto per le lingue il più ampio possibile, vista la realtà multietnica presente nella città di Trento, non può che essere un fat- tore positivo e sicuramente apprezzato. Lo sviluppo di un algoritmo per l’ordinamento dei commenti in base a data e condivisione dell’opinione tra gli utenti potrebbe aprire le porte ad un lavoro più ampio che vada anche ad analizzare le politiche di ranking utilizzate dai social network più comuni come Facebook o YouTube. Si potrebbe pensare inoltre ad una funzionalità che faccia da canale diretto per la rilevazione di feedback, la comunicazione di disagi o disfunzioni all’Opera Universitaria la quale ne può trarre beneficio e migliorare costantemente il proprio servizio. Infine sarebbe molto utile e sicuramente un valore aggiunto a tutta l’applicazione la realizzazione della sezione di statistiche mancante in iSoldi e, concludendo così questa tratta- zione, potrebbe essere sviluppata la stessa applicazione per diversi sistemi operativi raggiungendo così la totalità degli utenti di smartphone.
45. Bibliografia [1] Andrea Grimes and Richard Harper. Celebratory technology: new direc- tions for food research in hci. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. ACM, 2008. [2] ISO Iso. Iec 9126-1: Software engineering-product quality-part 1: Quality model. Geneva, Switzerland: International Organization for Standardization, 2001. [3] ISO13407 ISO. 13407: Human-centred design processes for interactive systems. Geneva: ISO, 1999. [4] WD ISO. 9241-11. ergonomic requirements for office work with vi- sual display terminals (vdts). The international organization for standardization, 1998. [5] Timo Jokela. Making user-centred design common sense: striving for an unambiguous and communicative ucd process model. In Proceedings of the second Nordic conference on Human-computer interaction. ACM, 2002. [6] Clayton Lewis. Using the thinking-aloud method in cognitive interface design. IBM TJ Watson Research Center, 1982. [7] Conor Linehan, Tom Leeman, Christopher Borrowdale, and Shaun Law- son. Crowd saucing: social technology for encouraging healthier eating. interactions, 2013. [8] Kevin Mullet and Darrell Sano. Designing visual interfaces: Commu- nication oriented techniques, volume 2550. SunSoft Press Englewood Cliffs NJ, 1995. [9] Jakob Nielsen. Severity ratings for usability problems. Papers and Essays, 1995. [10] M. Bazzoli P. Peri. indagine sulla soddisfazione degli utenti dei ser- vizi di ristorazione offerti dall’opera universitaria di trento. Opera Universitaria di Trento, 2012. 44
46. BIBLIOGRAFIA 45 [11] Tania Schlatter and Deborah Levinson. Visual Usability: Principles and Practices for Designing Digital Applications. Newnes, 2013. [12] Helen Sharp, Yvonne Rogers, and Jenny Preece. Interaction design: beyond human-computer interaction. 2002, 2007. [13] Jie Xu, Ping-yu Chen, Scott Uglow, Alison Scott, and Enid Monta- gue. Design challenges and guidelines for persuasive technologies that facilitate healthy lifestyles. Computer Technology and Application, 2012.