UNIVERSITÀ DEGLI STUDI DI TRENTO DIPARTIMENTO DI INGEGNERIA E SCIENZA DELL’INFORMAZIONE CORSO DI LAUREA IN INFORMATICA TESI FINALE “iFame”: una social app per una migliore esperienza della mensa Relatore: prof.ssa Antonella De Angeli Correlatore: dott.ssa Silvia Bordin Candidato: Francesco Bonadiman Anno Accademico 2012-2013

Per cominciare, vorrei ringraziare il team di Smart Campus per avermi offerto l’opportunità di partecipare a questa incredibile esperienza e, soprattutto, per avermi fornito l’aiuto e il sostegno necessari in ogni occasione, creando un ambiente coinvolgente e stimolante e permettendomi di trascorrere un periodo di tirocinio davvero sereno. In particolare vorrei ringraziare Silvia che, soprattutto durante la scrittura della tesi, mi ha dato un aiuto enorme per riuscire a portare a termine il lavoro in tempo, e Antonella, a cui devo praticamente ogni soddisfazione personale ottenuta nell’ultimo anno. Vorrei quindi ringraziare tutte le persone che hanno partecipato alle varie fasi della valutazione di iFame: non sempre troviamo 20 minuti del nostro prezioso tempo da dedicare a qualcun altro, ma voi l’avete fatto e giustamente vi ringrazio anche qui. Devo assolutamente ringraziare i miei “boys” di iFame e tutti i miei compagni di università: svegliarsi all’alba (anche dopo feste spaziali) non è mai stato un peso se poi passavamo le giornate assieme, e questi 3 anni rimarranno uno dei ricordi più ricchi e importanti della mia vita. Vorrei ringraziare anche tutti i miei amici sparsi qua e là: mi piacerebbe citarvi tutti da quanto vi voglio bene, ma credo che finirei per emozionarmi ripensando ad ogni singolo momento trascorso. In particolare devo ringraziare i miei due fratelli “Poio” e Chris, che mi sono rimasti vicini durante tutte le avventure di questi lunghi anni, e su cui so che potrò sempre contare. Devo ringraziare Francy, senza la quale questa impresa chiamata “laurea a Luglio” sarebbe rimasta soltanto un sogno intentato, e che durante tutti questi mesi frenetici mi ha sempre fatto forza, dandomi tutto l’affetto che potessi desiderare. Un grazie speciale va al mio “fan club” personale, in particolare ai miei nonni e alle mie zie, che si sono sempre interessati alla mia vita e mi hanno fatto sentire il loro appoggio (alimentare e non). Devo poi ringraziare assolutamente la mia fantastica sorella Angela, che mi ha fatto compagnia in ogni situazione e che posso senza dubbio considerare la mia migliore amica. Infine ringrazio i miei genitori: anche se sono spesso più in giro che a casa, non c’è giorno in cui mi avete fatto mancare un gesto, una parola, un po’ del vostro tempo, e questo è il dono più grande che avete potuto farmi. Un grazie quindi a mia mamma, per avermi cresciuto con la fiducia nei miei mezzi che poi “andrà sicuramente bene!”, e a mio papà, che mi ha insegnato il valore delle cose.

Indice 1. Introduzione 1 2. Stato dell’arte 3 2.1. Motivazione 3 2.2. Analisi della letteratura 4 3. Requisiti 6 3.1. Prototipo iniziale 6 3.2. Valutazione del primo prototipo 7 3.3. Il forum e il Participatory Design Contest 8 3.4. Indagine dell’Opera Universitaria 8 3.5. Sondaggio “Eating in the UniTn canteen!” 9 4. Design 13 4.1. Nuovo prototipo e differenze 14 4.2. Alcuni dettagli implementativi 26 5. Valutazione 28 5.1. Valutazione del secondo prototipo 28 5.2. Analisi dei risultati 30 5.3. Studio “sul campo” dell’applicazione 30 6. Conclusioni e sviluppi futuri 32 Bibliografia 35 Appendice 37

- 1 - Capitolo 1 Introduzione La seguente tesi descrive il design, la prototipazione e la valutazione di un’applicazione per smartphone chiamata “iFame” e destinata ad offrire agli studenti dell’Ateneo di Trento un servizio di ristorazione più efficace e vicino alle loro necessità. Si è infatti notato come uno degli aspetti della vita universitaria meno sviluppato dal punto di vista tecnologico sia proprio quello relativo alla mensa: questa lacuna causa spesso allo studente numerosi disguidi, che si traducono poi in perdite di tempo inaspettate e disagi nel regolare svolgimento dell’attività di studio. Ad esempio, lo studente arriva alla cassa con l’intento di pagare il suo pasto, ma si ritrova con un credito insufficiente nella tessera mensa ed è costretto a ricorrere a prestiti dagli amici per poter effettivamente consumare il pranzo. Ancor più diffusa è la situazione in cui lo studente decide di andare a mangiare, scoprendo però, solo una volta giunto in mensa, di trovarsi davanti una lunga coda di persone in attesa; probabilmente, se avesse aspettato dieci minuti, avrebbe evitato la fila. Inoltre, come emerso poi dagli studi effettuati per la presente tesi, un numero ragguardevole di studenti pur frequentando l’Università già da parecchio tempo, non ha ancora chiare le composizioni delle varie tipologie di menù, né i criteri in base ai quali queste si differenziano. Il “menù del giorno” è sconosciuto a gran parte degli studenti e in molti, magari pentiti di aver preso un certo piatto, vorrebbero poter contare su di una community affidabile. L’applicazione iFame vuole proporre una soluzione a questi scenari: essa è nata inizialmente come proposta di applicazione per il coursework di Human-Computer Interaction, è passata attraverso un contest di idee e infine è stata sviluppata tramite il progetto Smart Campus di Trento RISE. iFame è stata progettata fin dalle sue prime fasi seguendo un approccio di progettazione centrato sull’utente: verranno rivisitate perciò le analisi e le valutazioni effettuate sul primo prototipo, che verrà poi contestualizzato tramite uno studio della letteratura relativa ad applicazioni riguardanti il cibo; si vedrà poi come i giudizi provenienti dalla valutazione con gli utenti sono stati integrati in una seconda iterazione del design dell’applicazione, e come tale design sia culminato nella stesura di un nuovo prototipo e nella sua successiva implementazione. Infine, verrà presentata la valutazione di tale prototipo condotta con un gruppo di utenti, assegnando loro dei compiti e verificando quali difficoltà essi abbiano trovato nell’eseguirli. La tesi si conclude con l’analisi di tale valutazione e l’introduzione ai prossimi sviluppi di iFame, derivati da uno studio “sul campo” informale effettuato con la prima versione stabile dell’applicazione.

- 2 - Creare iFame è stato un compito estremamente ampio e diversificato, in quanto costituito dallo sviluppo di un’idea a partire dal suo concepimento fino alla realizzazione della sua parte grafica e funzionale. Questa esperienza mi ha fornito un insegnamento capillare su molteplici ambiti, quali ad esempio i metodi per focalizzare l’attenzione dell’utente verso determinate funzionalità e come rendere queste il più semplice ed efficiente possibili; infine, mi ha permesso di apprendere concretamente quale sia l’effettivo procedimento che porta alla realizzazione di un prodotto rivolto al pubblico.

- 3 - Capitolo 2 Stato dell’arte La sezione relativa allo stato dell’arte è divisa in due parti: la prima, in cui viene presentata la motivazione che ha portato allo sviluppo di iFame, descrive le origini e l’evoluzione dell’applicazione, mentre la seconda si concentra sulla letteratura esistente riguardo all’analisi di applicazioni mobile correlate al cibo, sia dal punto di vista sociale che dell’interazione uomo- macchina. 2.1. Motivazione Questo capitolo presenta l’evoluzione di iFame, culminata in un’esperienza di tirocinio e nella presente tesi. L’applicazione nasce nei primi giorni di dicembre 2012. Durante il corso di Human-Computer Interaction, sono stati assegnati diversi lavori di gruppo relativi alla valutazione di un set di applicazioni sviluppato da Smart Campus [1], un progetto di Trento RISE [2]. Per la consegna finale, il mio gruppo (composto da me, Stefano Bozzi, Desmond Agyeman, Francesco Maturi e Nicola Parrello) ha scelto di proporre una nuova app, da integrare nell’ecosistema Smart Campus, con la convinzione che essa dovesse risultare utile per la vita degli studenti dell’Ateneo di Trento. L’app avrebbe riguardato il servizio mensa, uno degli ambiti finora meno curati dal punto di vista tecnologico tra i diversi aspetti del “vivere l’Università”. La proposta di applicazione, chiamata scherzosamente “iFame”, è stata illustrata tramite dei prototipi realizzati con Balsamiq Mockups [3], un software per la prototipazione rapida e low-fidelity di interfacce utenti; oltre ai prototipi, sono stati presentati i requisiti funzionali e non; infine, i contesti di utilizzo previsti sono stati esemplificati tramite storyboard realizzate con Pixton [4] e Go!Animate [5]. Il team di Smart Campus, nei mesi successivi, ha valutato le varie proposte emerse dai diversi lavori di gruppo e, il 14 marzo 2013, ha organizzato un “Partecipatory Design Contest”, dove le quattro migliori proposte di apps sono state presentate di fronte ad una giuria: la proposta vincitrice avrebbe avuto la possibilità di venir implementata ed entrare così a far parte del set di applicazioni di Smart Campus. “iFame” è stata selezionata per partecipare al concorso ed è stata insignita del primo premio; nei giorni seguenti il mio gruppo (ad esclusione di Nicola Parrello) è diventato parte del team di Smart Campus nell’ambito di un tirocinio. I compiti sono stati suddivisi tra i quattro membri del gruppo; in particolare, io mi sono dedicato alla parte di design e implementazione dell’interfaccia

- 4 - grafica. Si è lavorato perciò allo sviluppo verticale di “iFame”, partendo dal prototipo iniziale ed arrivando ad un’implementazione stabile ed integrata nell’ecosistema Smart Campus. L’obiettivo del progetto Smart Campus è infatti quello di creare una community locale tramite lo sviluppo di piattaforme IT e servizi innovativi, che facilitino i cittadini e le istituzioni nelle proprie attività quotidiane; la realizzazione di uno “smart territory” passa per la definizione ed implementazione di servizi che, proprio per risultare aderenti alle necessità degli utenti finali, vengono progettati e valutati tramite un approccio partecipativo. Ad esempio, i requisiti per le app che ora compongono Smart Campus sono stati raccolti coinvolgendo gruppi di studenti, mentre i prototipi al momento disponibili sono in fase di valutazione “sul campo” tramite l’utilizzo nella vita quotidiana da parte di allievi dell’Ateneo. 2.2. Analisi della letteratura All’evoluzione di iFame hanno contribuito, oltre ai designers e agli sviluppatori del team di Smart Campus, concetti e principi provenienti da letteratura specifica, riferita a due ambiti principali: il materiale su Interfacce e Mobile Design da una parte, quello riguardante il rapporto tra HCI e alimentazione dall’altra. Per quanto concerne il primo settore, fondamenti di Human-Computer Interaction sono presentati nel libro [6], che permette di apprendere i primi elementi base come “usability”, “user experience” e “user-centred design” e di radicare le conoscenze apprese durante i corsi universitari. Importanti nozioni di visualizzazione riferite in particolare al settore mobile sono riportate da [7], che offre un’idea chiara di principi chiave in settori quali consistenza, layout e visibilità. Infine, soprattutto nella scelta di icone, immagini e colori, si è fatto riferimento a [8]. Riguardo invece il legame tra interazione uomo-macchina e applicazioni inerenti il cibo è stata effettuata una fase di ricerca attraverso svariati articoli sul tema pubblicati, ad esempio, per il SIGCHI [9], la principale associazione internazionale per i professionisti che operano in ambito HCI, nonché uno dei più significativi “gruppi di interesse” di ACM [10]. Negli ultimi anni, gran parte degli sforzi si sono concentrati sul rapporto tra “human-food interaction” e “healthy eating”, ossia sull’analisi del comportamento degli utenti in relazione al cibo, al fine di indurli ad uno stile di vita sano ed equilibrato. Tali aspetti interessano anche iFame, che vuole offrire agli utenti non solo un servizio efficiente e veloce, ma che al tempo stesso permetta di mantenere un riferimento costante all’apporto calorico dei pasti, consentendo così all’utente di pianificare la propria dieta lungo tutta la settimana pur mangiando in mensa.

- 5 - A differenza della maggioranza delle ricerche effettuate in passato poi, dove il cibo veniva percepito con un’accezione negativa, nel paper [11] ne viene esaltata la sua funzione nella società odierna: esso è una parte fondamentale delle nostre vite, ma non soltanto a livello di sostentamento, bensì (e ancor più) a livello sociale. Esso permette infatti alle persone di riunirsi ed interagire, riflette il modo di essere e il carattere di ognuno, offre agli utenti piacere e soddisfazione: da qui deriva il termine “Celebratory Technology”, poichè si concentra sugli aspetti positivi del cibo, quali creatività, piacere, coesione familiare, rilassatezza. Un’altra importante linea-guida per il design e lo sviluppo di iFame è descritta in [12], secondo cui la tecnologia, se affiancata a design e interfacce appropriati e persuasivi, può influire sull’adozione di uno stile di vita sano e regolare, influenzando così il comportamento e le abitudini dell’utente. Nel paper è descritto lo studio effettuato per realizzare una tecnologia chiamata HealthyEdge, sviluppata tramite un processo di user-centred design al fine di monitorare lo stato fisiologico di una persona, tenendo conto delle componenti esterne e delle specifiche necessità dietetiche che possono ostacolare il mantenimento di uno stile di vita equilibrato. In questa direzione va anche [13] dove, oltre a trattare la problematica del rapporto conflittuale con il cibo, percepito troppo spesso come aspetto da tenere sotto controllo anzichè come fonte di sostentamento e convivialità, viene evidenziato l’enorme potere che può avere la tecnologia nel contagiare le scelte degli utenti. Viene perciò fatto riferimento a due progetti: SocialReceipt, basato su un social-network di liste della spesa, che ha però ottenuto scarso successo; e Plate and Rate, in cui è stato chiesto agli utenti di fotografare i propri pasti e quindi di valutarli in base a quanto sono considerati sani. Questa applicazione, che ha ottenuto discreti risultati in termini di coinvolgimento e incidenza, può essere ricondotta ad iFame, poiché permette agli utenti di esprimere una propria opinione libera e autonoma rispetto al piatto consumato; a differenza di iFame però, dove l’utente valuta il gusto e la qualità del piatto, in Plate and Rate l’utente si basa unicamente sull’aspetto visivo del cibo. Tutto il materiale precedentemente elencato ha fornito una base teorica, stabile e affidabile, da cui partire per analizzare i dati derivanti dalla raccolta dei requisiti, che verrà ora esaminata.

- 6 - Capitolo 3 Requisiti La seguente sezione descrive la fase di raccolta dei requisiti, ossia la definizione delle specifiche dell’app e la valutazione del primo prototipo in Balsamiq Mockups realizzato come consegna finale del coursework di Human-Computer Interaction. Vengono presi in esame anche un’indagine effettuata dall’Opera Universitaria ed un sondaggio, entrambi indirizzati agli utenti della mensa, al fine di identificare i problemi effettivamente riscontrati dagli stessi fruitori del servizio, e verificare se altri servizi possano venire inclusi nell’applicazione. 3.1. Prototipo iniziale Il mockup realizzato per il coursework [AP1] è la sintesi delle scelte in termini di design e funzionalità effettuate all’interno del gruppo. L'applicazione risulta così divisa in 4 features principali: 1) iFretta si basa sulla considerazione del fatto che l’entità delle code in mensa varia notevolmente a seconda della fascia oraria, e risulta perciò alquanto altalenante; pertanto, recarsi alla mensa in determinati orari può risultare più vantaggioso che in altri. La soluzione è fornire agli utenti uno streaming sempre accessibile delle webcams nelle varie mense, in modo che essi possano scegliere quando è il momento più appropriato per andare a mangiare. 2) iDeciso si propone come soluzione alle difficoltà incontrate dall’utente riguardo la sua alimentazione in mensa. Attualmente l’utente è infatti all’oscuro di quale sia l’offerta della mensa per un determinato giorno e per i giorni successivi, ed anzi ha molteplici dubbi su cosa sia possibile acquistare e quale sia il corrispondente prezzo. iDeciso si occupa perciò di fornire informazioni riguardo le varie tipologie di menù disponibili, l’offerta del menù del giorno ma anche quella dei giorni successivi: in questo modo, l’utente ha più informazioni a disposizione che gli consentano di mantenere un’alimentazione equilibrata e di gestire l’apporto calorico in base alle proprie esigenze (oltre senz’altro al controllo sul fattore economico, che può essere oggetto di interesse in particolar modo per una categoria con limitate risorse come quella degli studenti). 3) iGradito punta a risolvere uno dei noti punti critici del servizio mensa in generale: poiché questo opera dei prezzi notevolmente inferiori rispetto alle normali attività commerciali gestite da privati, il

- 7 - risultato in termini di gradimento del cibo proposto non è sempre ottimale. iGradito cerca dunque di costituire una community di utenti che usufruiscono della mensa, fornendo loro la possibilità di scrivere e leggere commenti relativi ai vari piatti, valutandoli anche in scala 1-10. L’utente “inesperto” può dunque avere un riferimento rapido ed affidabile su quali siano i cibi più buoni e quali i più scadenti, in modo tale da non incappare in spiacevoli imprevisti. 4) iSoldi risponde infine alla problematica, molto comune tra gli utenti (come descritto nelle sezioni 3.3. e 3.4.), di non conoscere il credito presente nella tessera mensa, non potendo così consumare un pasto e rendendo quindi necessario un prelievo bancario. Quest’app informa così l’utente del credito disponibile prima che questi arrivi alla cassa della mensa, evitando quindi che egli scopra solo allora di non avere credito a sufficienza. Inoltre in iSoldi è possibile visualizzare lo storico dei pasti consumati dall’utente, per ottenere delle statistiche sui tipi di pasto mangiati, gli apporti calorici e il quantitativo di denaro speso in un dato periodo di tempo. 3.2. Valutazione del primo prototipo Sul prototipo appena descritto sono stati effettuati degli user-studies al fine di evidenziare eventuali problemi di usabilità; il prototipo è stato sottoposto ad un campione di 25 persone di età compresa tra i 18 ed i 60 anni. Gli utenti possiedono background, abilità e grado di istruzione alquanto diversificati: la maggior parte di loro sono studenti, ma vi sono anche diversi insegnanti, impiegati ed un pensionato. Infatti, sebbene iFame sia destinata principalmente agli studenti dell’Ateneo, un campione così variegato ha permesso da un lato di validare elementi quali la visibilità e il Look & Feel, mentre dall’altro ha simulato l’utilizzo dell’app in ulteriori contesti: in questo modo è stato considerato un possibile futuro utilizzo da parte di utenti come professori, operai e dipendenti dell’Università. Ad ogni utente è stato così proposto il mockup interattivo dell’applicazione (su telefono o pc) e gli sono stati assegnati determinati compiti: ad esempio, gli è stato richiesto di scorrere il menù del mese, di verificare il proprio credito residuo, oppure di inserire una recensione per un dato piatto, o ancora di visualizzare la coda in una data mensa [AP2]. L’utente è stato osservato durante lo svolgimento di questi incarichi e, in presenza di difficoltà, aiutato nell’affrontarle; gli è stato inoltre richiesto di spiegare ad alta voce cosa stesse facendo e per quali motivi avesse operato determinate scelte, seguendo il protocollo “Think Aloud”. Questo metodo è solitamente utilizzato in fase di usability testing per ottenere informazioni più ricche sul modello mentale che l’utente si costruisce del prototipo che sta utilizzando: all’utente viene infatti domandato di spiegare ad alta voce qualunque cosa stia guardando, pensando e facendo man mano che svolge il compito; tali commenti vengono eventualmente registrati, ma comunque raccolti dallo sperimentatore.

- 8 - Lo user testing ha evidenziato alcuni problemi di usabilità, raccolti in forma tabellare [AP3] e ordinati secondo i “severity ratings” di Nielsen [14]. In particolare, dalla tabella in questione emergono problemi legati al nome di iDeciso, alla sezione dedicata alle alternative al menù del giorno e all’interfaccia grafica di iGradito. Gli utenti stessi, inoltre, hanno fornito importanti suggerimenti su come migliorare e rendere maggiormente immediato l'uso dell'applicazione. 3.3. Il forum e il Participatory Design Contest Successivamente, la proposta di applicazione è stata presentata agli utenti di Smart Campus direttamente sul forum della community [15], suscitando un discreto interesse da parte di una decina di studenti: sebbene uno di questi abbia fatto notare come il nome possa richiamare un prodotto Apple, la quasi totalità degli intervistati (anche durante la fase di valutazione) l’ha trovato divertente ed evocativo. Federico e Michele, studenti al terzo anno di Informatica, pur denotando l’utilità che avrebbe tale applicazione, si dichiarano dubbiosi sulle possibilità di accesso ai dati necessari; sono inoltre favorevoli all’inclusione in iFame di tutte le funzionalità riguardanti i valori nutrizionali. Andrea, anch’egli studente di Informatica del terzo anno, ritiene invece che avrebbe senso mantenerle separate in un’ulteriore feature, in modo da non fornire all’utente informazioni superflue. Altri utenti hanno invece voluto condividere le proprie impressioni dopo aver assistito al Participatory Design Contest. Riccardo, ricercatore presso il Dipartimento di Ingegneria e Scienza dell’Informazione dell’Ateneo, ha voluto evidenziare l’efficacia del design partecipativo di iFame e delle altre app in gara: “Oggi sono stato al concorso di idee e l'ho trovato davvero interessante, le presentazioni sono state veramente valide. Collaborare, condividere idee e lottare per un obiettivo sono tutti fattori che contribuiscono a strutturare un percorso evolutivo, sia in materia di istruzione che di comunicazione tra gli studenti.” Anche Liza, studentessa di Scienze Cognitive, concorda e sottolinea quanto sia importante il ruolo dell’utente nel processo interattivo: “E’ stato interessante vedere interaction design all'interno di interaction design. Non solo l'app di Smart Campus è uno straordinario esempio di interaction design concreto, ma ora pure gli utenti stessi stanno iniziando a progettare in modo interattivo! E’ come fosse HCI^2!” 3.4. Indagine dell’Opera Universitaria Dopo aver verificato l’opinione degli utenti rispetto all’applicazione, si è passati ad esaminare cos’altro potesse servire ad un possibile fruitore della mensa, cioè se ulteriori servizi potessero essere inclusi nell’applicazione.

- 9 - Per fare ciò, innanzitutto, si è considerata l’indagine [16], effettuata nel mese di marzo 2012 da parte dell’Opera Universitaria [17] e a cui hanno risposto 5221 persone. Tale indagine era volta a conoscere la soddisfazione degli utenti riguardo al servizio (sono state valutate ad esempio qualità e quantità dei cibi, cottura e condimenti dei piatti, cortesia ed efficienza del personale, igiene e organizzazione dei locali), ma ha permesso anche agli stessi di fornire consigli sul come migliorarlo. L’analisi si è perciò indirizzata principalmente a quest’ultimo tipo di informazioni, per cercare di offrire un servizio più completo possibile agli utenti dell’applicazione. Alcuni suggerimenti emersi sono stati, ad esempio, l’invito a mostrare in maniera più chiara le tipologie di menù, ad indicare all’ingresso della mensa il menù del giorno ed a mostrare i nomi e gli ingredienti delle pietanze. 3.5. Sondaggio “Eating in the UniTn canteen!” In contemporanea è stato creato un sondaggio on-line [18], indipendente da quello dell’Opera Universitaria, che è stato poi diffuso attraverso il social-network Facebook e pubblicato in diversi gruppi legati all’Università di Trento: a questo hanno risposto 575 persone, rappresentanti di tutti i dipartimenti dell’Ateneo. Il sondaggio comprende domande appartenenti a tutte le tipologie: risposta aperta e chiusa, scelte multiple, giudizi su scala di valori. Figura 1: Frequentazione della mensa Una parte iniziale raccoglie informazioni sull’utente per cercare di delinearne il profilo (età, sesso, nazionalità, occupazione, dipartimento); vengono poi rilevate le abitudini dell’utente, come il grado di frequentazione del servizio o l’orario e la mensa in cui solitamente mangia; gli viene quindi chiesto quali difficoltà incontri durante il pagamento, come valuti la lunghezza della coda e quali siano, a suo parere, le principali cause di formazione della stessa.

- 10 - Figura 2: Principali cause della coda Figura 3: Principali problemi durante il pagamento Vengono in seguito analizzate le necessità alimentari (allergie, intolleranze, diete...) e le abitudini dell’utente (pianificazione pasti, criteri di scelta dei cibi, utilizzo del sito dell’Opera). Figura 4: Influenza delle opinioni altrui nelle scelte

- 11 - Figura 5: Criteri di scelta del pasto Gli viene quindi chiesto se sia a conoscenza delle alternative al menù del giorno, se trovi le tipologie di menù ben definite e quali ritenga siano i principali problemi riguardanti il servizio mensa. Figura 6: Conoscenza delle alternative al menù del giorno

- 12 - Figura 7: Chiarezza delle tipologie di menù Infine, viene esaminato il background tecnologico e informatico dell’utente e gli viene data la possibilità di aggiungere un commento libero. Il sondaggio ha consentito di raccogliere una grande quantità di dati [AP4] che, uniti a quelli provenienti dall’indagine effettuata dall’Opera Universitaria, sono stati poi tradotti sotto forma di specifiche tecniche [AP5] e nuove funzionalità da includere nel redesign dell’applicazione [AP6].

- 13 - Capitolo 4 Design Una volta conclusa la raccolta dei requisiti descritta nella sezione precedente, si è passati alla loro integrazione nell’app tramite una seconda iterazione del processo di design, proseguita fino al raggiungimento di un mockup consolidato [AP7] che è poi stato impiegato come guida per la fase di implementazione. Man mano che il design veniva tradotto in codice, sono emerse alcune situazioni in cui le difficoltà tecniche hanno reso necessaria un’ulteriore modifica al design stesso; quindi, sebbene il prototipo sia stato ripreso in mano e modificato più volte in base alle esigenze e necessità, risulta comunque meno completo e dettagliato rispetto all’applicazione. Il design conclusivo dell’applicazione è il risultato della combinazione di diversi elementi: prima di tutto sono stati raffinati i punti meno intuitivi ed usabili, accogliendo consigli e critiche da parte degli utenti che avevano testato il primo prototipo; sono stati quindi tenuti in considerazione gli standard propri di Smart Campus, dalla scelta dei colori all’utilizzo di determinati strumenti offerti da Android, al fine di mantenere una certa consistenza tra le diverse apps; infine il tutto è stato integrato con una buona dose di esperienza ed “occhio clinico” fornita dai designers di Smart Campus. E’ stata inoltre svolta una fase di benchmarking, in cui sono state analizzate 15 diverse applicazioni disponibili sul PlayStore che avessero a che fare con mense o servizi di ristorazione; la quasi totalità di esse sono sviluppate per le mense scolastiche in Germania, ma hanno fornito comunque spunti interessanti, almeno per quanto riguarda quali ulteriori funzionalità includere in iFame e quali scelte di design (non) adottare.

- 14 - 4.1. Nuovo prototipo e differenze La Home di iFame perciò, seguendo il Look & Feel minimale e pulito di Smart Campus, è stata ridisegnata utilizzando un solo colore tematico, il rosso. Il nome di iDeciso, poco chiaro e fraintendibile come risultato dagli user studies, è stato sostituito proprio con iFame, a sottolineare una volta di più come questa sia la sotto-app principale. Per lo stesso motivo, la relativa icona è stata spostata in alto a sinistra, posizione in cui essa ottiene il massimo risalto e che offre una migliore organizzazione logica dell’interfaccia: infatti, dopo aver controllato il menù del giorno, l’utente può visualizzare la coda in mensa con iFretta (in alto a destra), verificare il credito residuo nella tessera con iSoldi (in basso a sinistra) e per finire, a pasto consumato, votare e recensire i piatti con iGradito (in basso a destra). Sono stati infine rimossi tutti i menù e le informazioni relative all’utente, poiché queste si troveranno già all’interno del profilo utente di Smart Campus. Figura 8: Evoluzione della Home di iFame: primo prototipo, secondo prototipo, implementazione

- 15 - Cliccando su iFame quindi, che è ora raffigurata per mezzo di un’icona con un vassoio contenente piatto e bicchiere (trovata dagli utenti più evocativa rispetto al carrello) si accede ad una schermata dove sono mostrati 4 sottomenù disposti in una lista, anzichè in 4 bottoni come da design iniziale, che rappresentano le funzionalità cardine della sottoapplicazione. Figura 9: Evoluzione di iFame (precedentemente iDeciso): primo prototipo, secondo prototipo, implementazione

- 16 - Entrando in Menù del giorno la user interface risulta totalmente rinnovata: nel mockup iniziale, infatti, il menù del giorno era introdotto da un’etichetta con la data odierna ed un pulsante “In più” per raggiungere le cosiddette alternative al menù del giorno, ossia quei piatti che sono sempre garantiti per assicurare una scelta più vasta. Come è però emerso dagli user-studies, la visibilità e l’immediatezza di questo pulsante sono risultate estremamente ridotte, impedendo così all’utente di avere un’idea efficace delle offerte relative al giorno in questione. Sono state perciò prese in considerazione altre scelte di design, quali l’utilizzo del menù nella barra del titolo, la sua ripetizione per ogni singola portata o l’utilizzo di una lista a sezioni espandibili anzichè di una fissa. Dopo una lunga discussione all’interno del team di Smart Campus la scelta è ricaduta sull’utilizzo di due tabs, una per il menù del giorno e una per le Alternative: ciò ha permesso di fornire ampia visibilità a queste ultime senza causare ridondanze nè eccessive dilatazioni della lista. L’utente può così, con estrema facilità, passare da una tab all’altra; il titolo presente nella barra, invece, mostrerà sempre la data odierna, fornendo un riferimento immediato al giorno in questione. Figura 10: Evoluzione di Menù del giorno: primo prototipo, secondo prototipo, implementazione

- 17 - Pure la parte grafica di Tipologie di menù è stata radicalmente rivisitata: l’interfaccia iniziale è infatti risultata troppo elementare, rappresentando unicamente le tre tipologie tramite le locandine offerte dall’Opera Universitaria. Anche qui sono state introdotte allora tre tabs, una per tipologia di menù. Cliccando ad esempio sulla tab “Ridotto” viene mostrata l’immagine del menù corrispondente, in modo da garantire all’utente un riferimento visivo rapido ed immediato, il relativo prezzo e le diverse possibilità di composizione comprese nella tipologia. In grassetto sono indicati i piatti principali che determinano l’inserimento del menù nella tipologia in questione, seguiti dagli ulteriori cibi acquistabili compresi nel prezzo. Si è cercato così di mostrare nel modo più chiaro possibile le varie composizioni, in quanto queste rappresentano uno dei punti di maggior incertezza per gli utenti. Figura 11: Evoluzione di Tipologie di menù: primo prototipo, secondo prototipo, implementazione

- 18 - Componi il tuo menù, invece, ha mantenuto il design progettato nel primo prototipo: una lista di checkbox dove sono indicati tutti i possibili piatti. L’algoritmo che ne regola la composizione, inoltre, non permette all’utente di creare offerte di menù in realtà inapplicabili. In aggiunta, scegliendo una certa portata compare un bottone la cui pressione espande la lista in modo dinamico, mostrando i piatti dell’offerta del giorno e permettendo la creazione di un menù vero e proprio. Premendo il bottone “Calcola” si viene reindirizzati alla tipologia di menù che corrisponde alle scelte dell’utente, dove vengono mostrate in verde eventuali pietanze che è possibile aggiungere senza sforare nella categoria di prezzo superiore, il prezzo corrispondente e, in caso di credito insufficiente, un’indicazione dell’impossibilità di acquistare tale tipologia. Figura 12: Evoluzione di Componi il tuo menù: primo prototipo, secondo prototipo e implementazione di Menù risultante

- 19 - Menù del mese ha invece subìto un redesign totale: se inizialmente era concepito come un semplice rimando al PDF presente sul sito dell’Opera Universitaria, ora consente di selezionare una certa settimana del mese corrente e di visualizzare la lista dei menù del giorno relativi ad essa, permettendo così all’utente di pianificare i suoi pasti durante l’arco del mese. Figura 13: Evoluzione di Menù del mese: primo prototipo, secondo prototipo, implementazione

- 20 - In iFretta si trova, come da design iniziale, l’elenco delle mense fornite di webcam; queste però non sono più mostrate tramite bottoni, ma con una lista, sia per una questione di coerenza interna nell’app, sia per permettere una più facile e veloce aggiunta di ulteriori videocamere da parte dell’Opera. Figura 14: Evoluzione di iFretta: primo prototipo, secondo prototipo, implementazione

- 21 - Cliccando su Mesiano1 l’utente può così visualizzare, come da prototipo iniziale, lo snapshot che mostra la coda in quel dato momento; il bottone Refresh è stato rimosso, dato che l’aggiornamento dell’immagine è definito dal server dell’Opera. Tramite menù l’utente può inoltre visualizzare la posizione della mensa sulla mappa di ViviTrento (una delle altre applicazioni sviluppate da Smart Campus) ed ottenere così ulteriori informazioni quali orari, calendario e giudizi esterni; può infine impostare la mensa stessa come preferita, evidenziandola all’interno della lista mense. Figura 15: Evoluzione di iFretta per una specifica mensa (in questo caso Mesiano1): primo prototipo, secondo prototipo, implementazione (ancora da concludere lo switch tra le diverse tabs)

- 22 - La terza sottoapplicazione è iSoldi che, come il nome stesso lascia intuire, si concentra sulla situazione economica dell’utente. L’icona, da semplice simbolo dell’Euro, è stata ridisegnata come una mazzetta di banconote. Toccandola, l’utente accede ad una schermata in cui è mostrato il credito disponibile nella sua tessera, colorato in base a quante tipologie di menù può acquistare. Il design è stato arricchito con l’aggiunta della lista di tipologie acquistabili, raggiungibili direttamente alla pressione dell’indicatore del credito, e da una sezione “statistiche”, che offre all’utente un riepilogo dei suoi acquisti, delle sue ricariche, delle transazioni e dei piatti acquistati. Figura 16: Evoluzione di iSoldi: primo e secondo prototipo. L'implementazione è stata praticamente completata, ma l'Opera Universitaria non ha ancora fornito i dati relativi a ricariche e transazioni.

- 23 - Per ultimo, iGradito è stata completamente ridisegnata: gli user studies hanno infatti individuato un elevato numero di casi in cui gli utenti si sono trovati in difficoltà per la sua struttura non ben definita e la presenza di elementi ridondanti disposti in maniera dispersiva. Nel prototipo finale, quindi, la ricerca è stata spostata all’interno della barra del titolo; tramite menù, inoltre, si ha la possibilità di impostare come preferita la mensa in uso. Questa può venire scelta per mezzo di uno spinner, che mostra la lista (ordinata alfabeticamente) di cui si desidera visualizzare le recensioni e/o recensire i piatti, affiancati dal relativo voto medio. Ogni piatto risulta così univoco per ogni mensa, permettendo di avere giudizi diversi in base alla sede in cui si mangia. Questo fattore è di vitale importanza per l’affidabilità dell’applicazione: se un cibo è cucinato bene in una mensa ma in modo pessimo in un’altra, affermare che questo è “mediamente buono” non offre alcuna garanzia all’utente che si appresta a mangiare in una delle due. La scelta della mensa ha sostituito lo spinner destinato a filtrare i piatti per portata poiché, fornendo già l’utente della ricerca e dell’ordine alfabetico, è risultato superfluo e di scarso utilizzo; inoltre è stata tolta la possibilità di inserire nuovi piatti, in quanto la lista dei cibi è fornita direttamente dall’Opera Universitaria. Figura 17: Evoluzione di iGradito: primo prototipo, secondo prototipo, implementazione (dove viene mostrato l'utilizzo della ricerca)

- 24 - Cliccando su un piatto si accede all’area Recensioni: qui l’utente può visualizzare il giudizio medio per quel piatto, il numero di utenti che hanno votato e la lista delle recensioni associate. Può anche mettere “mi piace” o “non mi piace” alle recensioni degli altri. Figura 18: Evoluzione delle Recensioni: primo prototipo, secondo prototipo, implementazione

- 25 - Cliccando sul tasto “+” compare una finestra di dialogo (che riprende la schermata del design iniziale), dove l’utente può inserire la propria recensione, che consiste di una valutazione qualitativa su una scala Pessimo-Ottimo e di un’opzionale commento testuale. Se l’utente in precedenza ha già lasciato un commento ed intende modificarlo, il nuovo commento andrà a sovrascrivere il precedente, con logiche conseguenze positive per il controllo sulle recensioni, sul numero delle stesse e sulla loro veridicità, in modo da offrire agli utenti un riferimento sempre aggiornato. Figura 19: Evoluzione dell'Inserimento di una recensione: primo prototipo, secondo prototipo, implementazione

- 26 - Per finire, tramite il menù la lista delle recensioni può essere ordinata per data di inserimento, dando quindi priorità ai commenti più recenti, o per numero di likes/dislikes. E’ stato deciso infatti di seguire la politica di rating utilizzata da Facebook e Youtube, cioè di dare priorità più alta ai commenti con un maggior numero di “likes+dislikes”; questo significa infatti valorizzare le recensioni che sono state condivise (nel bene e nel male) da un elevato numero di utenti. Seguendo questa filosofia viene perciò limitato il numero di recensioni, per dare invece rilevanza ai “mi piace” sulle stesse. Così facendo non risulta necessario tenere conto del numero di recensioni scritte da ogni utente, dei suoi accessi in mensa e del numero di “mi piace” ai suoi commenti: non solo si tratta di una procedura estremamente complicata da implementare, ma può anche rivelarsi inapplicabile. Infatti in questo modo potrebbero verificarsi casi di commenti ragionevoli che vengono declassati solo perchè un utente frequenta poco la mensa o ha scritto un commento poco condiviso in un'altra occasione. Invece, valutando unicamente i “mi piace” al commento, può capitare che anche chi ha mangiato una sola volta in mensa possa scrivere qualcosa ritenuto affidabile e condivisibile. Se il suo commento sarà ritenuto poco credibile, riceverà come negli altri casi un numero abbondante di “non mi piace”, facendo capire agli utenti che non è per niente condiviso, o semplicemente non verrà preso in considerazione, sparendo sul fondo della lista. D'altra parte, una recensione che ha ottenuto 50 “mi piace” e 49 “non mi piace”, non avrà mai lo stesso peso di una che ha ottenuto un solo “mi piace”: avere a disposizione un campione di 99 utenti votanti, sebbene contrastante, la rende certamente più affidabile di quella espressa dal singolo utente. Quindi considerare la somma di likes e dislikes alle recensioni è sembrato un valido criterio di valutazione dell’affidabilità dei commenti. 4.2. Alcuni dettagli implementativi Prima di cominciare la fase di implementazione è stato effettuato uno studio approfondito sulle applicazioni già presenti nella suite di Smart Campus [AP8], che ha consentito di riconoscere quali pattern di design dovessero essere adottati anche in iFame per garantire la coerenza tra le app. Si è fatto uso poi delle librerie personalizzate di Smart Campus, oltre che di quelle di Android, per implementare funzionalità quali layout, sicurezza e connessione. E’ stato concordato lo sviluppo nativo in Android soprattutto per la vastissima diffusione di dispositivi che lo supportano (come risultato anche dal sondaggio distribuito agli studenti), seguendo così la linea intrapresa da Smart Campus.

- 27 - Figura 20: Sistema operativo posseduto dagli utenti che hanno risposto al sondaggio "Eating in the UniTn canteen!" La principale difficoltà incontrata durante lo sviluppo dell’applicazione è stata la mancanza di informazioni strutturate per le pietanze, le transazioni e gli altri dati necessari ad iFame. Dopo aver testato il prototipo dell’app, però, l’Opera Universitaria si è attivata per fornire dati strutturati per le transazioni delle singole card, i pasti consumati e lo storico delle ricariche. Inizialmente per i menù era disponibile soltanto un file PDF sul sito [17]; in seguito è stato messo a disposizione un file Excel da cui poter ricavare i dati. E’ al momento in lavorazione da parte dell’Opera Universitaria un web service che consenta di esporre i dati in suo possesso in modo più sistematico. Infine, uno degli obiettivi iniziali era quello di offrire all’utente l’elenco dei cibi in diverse lingue, magari corredato da una descrizione e la lista di ingredienti; questi dati non ci sono però stati forniti dall’Opera Universitaria. Per ovviare a tale mancanza è stata introdotta la ricerca online: cliccando su uno specifico piatto compare una finestra di dialogo, che chiede all’utente se desideri cercarne il nome in Google. Alla pressione di “Avvia ricerca” vengono così mostrati nel browser i risultati e le immagini relative al piatto desiderato. Questa feature può rivelarsi utile per gli utenti (soprattutto per gli stranieri) che, una volta giunti in mensa, non conoscono la composizione e gli ingredienti di determinati piatti (ad esempio un vasto numero di sughi e pietanze tipiche). Una volta giunti ad una versione sufficientemente stabile dell’applicazione si è quindi passati all’ultima fase, cioè alla valutazione del prototipo definitivo e allo studio “sul campo” di iFame.

- 28 - Capitolo 5 Valutazione Il prototipo finale è stato infine validato tramite degli user studies: trenta utenti hanno valutato prima il prototipo finale e poi la prima versione stabile dell’applicazione. In questa sezione si descrive lo svolgimento dei due esperimenti, presentando e discutendo poi i risultati qualitativi ottenuti. 5.1. Valutazione del secondo prototipo Il primo passo è stato la valutazione del mockup definitivo, realizzato in Balsamiq, tramite degli user studies che hanno coinvolto un campione di 30 persone. Ad ognuno di questi utenti è stata assegnata una lista di compiti da svolgere interagendo con il prototipo interattivo in formato PDF. Il campione preso in esame è bilanciato e composto da 15 utenti di sesso femminile ed altrettanti di sesso maschile. L’età media si aggira sui 23 anni: la quasi totalità degli intervistati ha infatti tra i 19 e i 23 anni, mentre due ne hanno rispettivamente 48 e 52. Come discusso precedentemente, la scelta di includere nella valutazione anche utenti che non ricalcano il profilo dello studente universitario medio, che dovrebbe invece rappresentare il principale fruitore del servizio, ha permesso di contestualizzare l’app in scenari ipotetici anche se meno comuni, come ad esempio l’utilizzo da parte dei professori o dei dipendenti dell’Università. 4 utenti su 30 non frequentano l’Università: tra di loro si riconoscono un impiegato, una insegnante di scuola dell’infanzia, un contadino ed uno studente delle Superiori. Altri 4 sono studenti non immatricolati presso l’Ateneo di Trento: uno studia Biotecnologie a Parma, uno Lingue Orientali a Venezia, uno Design a Bolzano mentre l’ultimo è iscritto all’ISIT, l’Istituto privato per Interpreti e Traduttori di Trento. Degli intervistati che risultano registrati all’Università di Trento, invece, si trovano rappresentanti di 7 dipartimenti su 11. Ben 14 di loro studiano Scienze e Tecnologie Biomolecolari (9 sono iscritti alla Triennale e 5 alla Magistrale), tre Ingegneria Industriale, mentre per Fisica, Matematica, Informatica, Giurisprudenza e Scienze Cognitive è stato intervistato uno studente per facoltà. Queste informazioni possono rivelarsi utili per tracciare un profilo medio del campione preso in esame: un ambiente universitario come quello di una facoltà scientifica, infatti, contribuisce in modo sicuramente più efficace a delineare il background tecnologico dell’utente. Il luogo dove si è svolta la valutazione può inoltre aver contribuito a confondere l’utente o a provocarne cali di attenzione, inducendolo a commettere errori; 8 studenti, ad esempio, sono stati intervistati durante una cena all’aperto e altri 4 in un momento di svago, situazioni in cui la

- 29 - concentrazione non è certamente massima. 6 utenti sono stati invece esaminati in casa ed altri 12 in facoltà: in questi casi eventuali fattori esterne risultano notevolmente affievoliti. Ad ogni utente è stato chiesto se fosse interessato a partecipare ad un esperimento finalizzato a migliorare l’interazione con il servizio mensa: tutti gli intervistati hanno manifestato grande curiosità a riguardo e si sono mostrati disponibili durante tutto il test, durato in media 10 minuti. Il mockup dell’applicazione, esportato in formato PDF interattivo, è stato sottoposto agli utenti in due modalità: a 15 di loro è stato fatto utilizzare su PC, mentre altrettanti l’hanno testato direttamente su di uno smartphone Samsung Galaxy S2. A ciascun utente è stata assegnata una serie di compiti da svolgere sul prototipo [AP9], ed in particolare gli è stato chiesto di: ● visualizzare il menu del mese ● visualizzare il proprio credito residuo ● aggiungere la propria recensione per il piatto “Anatre” ● visualizzare la tipologia di menu “Ridotto” ● visualizzare le alternative al menu del giorno ● visualizzare l'elenco dei piatti da recensire ● visualizzare le proprie statistiche e transazioni ● visualizzare la coda alla mensa di Mesiano ● comporre un proprio menu ● visualizzare le calorie dei vari piatti ● ordinare le recensioni per data di inserimento ● visualizzare l'elenco delle webcams per la coda ● visualizzare il menu del giorno ● cercare uno specifico piatto da recensire ● tornare indietro alla schermata precedente ● visualizzare le recensioni per il piatto “Anatre”. Per facilitare la trascrizione delle informazioni è stato seguito nuovamente il protocollo “Think Aloud” già utilizzato in precedenza: all’utente è stato richiesto di spiegare ad alta voce qualunque cosa stesse guardando, pensando e facendo durante l’esperimento. E’ stato perciò osservato durante lo svolgimento di questi incarichi, e le difficoltà che ha incontrato sono state raccolte tramite appunti ed annotazioni e riunite quindi in forma tabellare. Questa prima parte del processo di valutazione ha così permesso di evidenziare problemi di usabilità non risolti tramite il redesign del prototipo; questi sono stati quindi riportati in un documento [AP10] e vengono presentati ed analizzati nel paragrafo successivo.

- 30 - 5.2. Analisi dei risultati Gli user studies svolti hanno evidenziato alcuni problemi di usabilità che, seppur meno gravi rispetto a quelli derivanti dallo studio sul primo mockup, necessitano di esser tenuti in considerazione per giungere ad un prodotto il più user-friendly possibile. Un primo dato incoraggiante proviene dal fatto che 12 utenti, corrispondenti cioè al 40% del campione, non hanno incontrato alcuna difficoltà nello svolgere tutti i compiti loro assegnati. 5 utenti hanno invece riscontrato dei problemi al primo contatto con l’app, non essendo estremamente sicuri su quale icona cliccare: due di loro sono così entrati in iFretta, anche spinti dal significato del nome; gli altri hanno tentennato qualche secondo prima di capire come proseguire. È effettivamente normale che, entrando in un’applicazione per la prima volta, si incontrino delle difficoltà causate dalla mancanza di familiarità con la stessa, ma considerare ed analizzare queste complicazioni può rendere l’app ancora più usabile, soprattutto in caso di primo utilizzo. 3 utenti hanno trovato poco immediata la ricerca di un piatto in iGradito: la sua posizione nella barra del titolo, in effetti, può rendere questa funzionalità nascosta ad un primo esame. Per lo stesso motivo un altro utente ha avuto difficoltà ad aggiungere una propria recensione, non trovando il tasto ‘+’ ed aspettandosi invece una scritta “Inserisci”. Due utenti, che non hanno mai frequentato il servizio mensa a Trento, non hanno compreso il termine “Alternative”: una volta spiegato loro il significato, però, le hanno raggiunte agevolmente. Altri due hanno invece frainteso la semantica della parola e, quindi, si sono indirizzati in iFretta, che fino ad allora non era stata ancora esplorata. In questo caso il modo di assegnare i tasks impiegato negli user- studies può essersi rivelato controproducente: infatti, in un reale utilizzo di iFame, l’utente sarà interessato a conoscere il menù del giorno e, solo in caso questo non lo soddisfi, cercherà le alternative che avrà ben visibili nella stessa schermata. Vi sono infine alcuni casi in cui l’utente ha effettivamente sbagliato, entrando in una schermata diversa da quella desiderata: questi errori sono stati dettati principalmente dalla fretta o da equivoci legati alla formulazione dei tasks e ai nomi delle sottoapplicazioni. Un utente, ad esempio, per vedere i piatti da recensire è entrato in iFame (ed effettivamente il suo ragionamento ha senso); un altro, invece, per visualizzare le statistiche ha premuto su iGradito. Conclusa la valutazione del prototipo, si è passati alla valutazione dell’applicazione vera e propria. 5.3. Studio “sul campo” dell’applicazione La seconda parte del processo di valutazione è stata lo studio “sul campo” informale della prima release stabile di iFame. Al termine degli user-studies, infatti, ad ogni utente che non lo avesse utilizzato in precedenza per testare il mockup, è stato consegnato un Samsung Galaxy S2.

- 31 - La scelta di sperimentazione adottata, in questo caso, è stata di dare piena libertà all’utente, lasciando che familiarizzasse con l’applicazione e che, in un certo modo, la facesse sua. Così facendo ha potuto finalmente esplorare appieno ciò che prima era solamente un modello statico e limitato: cliccare su tutte le icone, scorrere ogni lista, visualizzare qualsiasi schermata e scrivere ciò che desiderava. Anzi, molti utenti sono rimasti sorpresi nel poter usare quella che, fino a pochi istanti prima, credevano essere soltanto un’idea in fase di realizzazione. Anche in questo caso il tester è stato osservato lungo tutta la durata dell’esperimento: tramite il “Think Aloud”, ancora una volta, si è potuto cogliere quali fossero le sue intenzioni, le sue attese e le sue opinioni, che sono state raccolte prima, durante e dopo lo studio, ed incluse quindi nel documento [AP10]. Alcuni utenti, addirittura, si sono immedesimati in possibili scenari, simulando l’utilizzo dell’applicazione in diversi contesti: ad esempio, controllando la lunghezza della coda pur essendo a lezione oppure decidendo cosa mangiare, in base alle recensioni dei piatti, una volta giunti in una mensa che non conoscono. Tra le tante opinioni raccolte, infine, un utente ha lasciato un commento decisamente significativo: “Grande idea e molto pratica. Anche se è semplice e diretta ha una varietà di opzioni sorprendenti. Parlandone anche con i miei compagni di corso ho capito subito che serviva un'app così! Eviterà la coda a chi deve fare in fretta, o comunque la diminuirà, evitando tutti i problemi legati a gente che scopre solo al momento di essere senza soldi. E’ molto utile anche per poter condividere opinioni riguardo a cibo e servizi. Sono sicura che avrà molto successo sia tra gli studenti che tra gli adulti!” Tutte le considerazioni e le impressioni degli utenti, quindi, sono state esaminate assieme ai problemi emersi durante la valutazione e, per alcuni di essi, verrà proposta una soluzione da realizzare come sviluppi futuri.

- 32 - Capitolo 6 Conclusioni e sviluppi futuri Questa tesi si è occupata del processo di redesign e della successiva valutazione di iFame, un’applicazione sviluppata per offrire agli studenti dell’Università di Trento un servizio di ristorazione più diretto e coinvolgente. Particolare importanza è stata data al tipo di metodologia applicato, noto come design “partecipativo”: durante la progettazione viene seguito, infatti, un approccio user-centred, in cui l’utente non solo è il destinatario principale di qualunque scelta condivisa dal gruppo di lavoro, ma diventa parte integrante di ogni fase del processo. Sono state così ripercorse le tappe che hanno portato allo sviluppo di iFame, a cominciare dalla sua ideazione e successiva prototipazione, passando per le analisi e gli user-studies effettuati sul primo modello, fino a giungere ad una seconda iterazione del design, che è culminata in un nuovo mockup e nell’implementazione della prima versione stabile dell’applicazione. Questi due prototipi, infine, sono stati valutati tramite dei nuovi user-studies ed uno studio “sul campo” informale: entrambe le valutazioni hanno riportato risultati incoraggianti, sia dal punto di vista dell’interazione utente-interfaccia che da quello dell’interesse mostrato per l’applicazione. L’idea che sta alla base, infatti, viene considerata da tutti semplice e diretta; inoltre, data soprattutto la carenza attuale del servizio mensa dal punto di vista tecnologico, la varietà di funzionalità offerte viene ritenuta davvero ricca, rendendo iFame quasi un’esigenza per l’utente. Come emerso dalla fase di valutazione, poi, gli utenti stessi auspicano di potersi servire dell’applicazione entro breve, al fine di mettere in atto un nuovo modo di vivere ed utilizzare la mensa: verificando quindi il credito prima di mettersi in coda, controllando la fila ben prima del termine della lezione, componendo il proprio menù per evitare di incappare in “brutte sorprese”. Gli user studies hanno inoltre confermato che, dopo una breve fase di esplorazione iniziale, l’utente riesce a muoversi senza difficoltà all’interno dell’applicazione, trovandola anzi immediata ed usabile (anche non possedendo un telefono Android). I risultati di questa valutazione inoltre, uniti a tutti i consigli e le impressioni provenienti dallo studio “sul campo”, hanno permesso di delineare una serie di suggerimenti e ulteriori miglioramenti, che verranno presi in esame e tradotti in realtà come sviluppi futuri, sempre seguendo l’approccio del design partecipativo e portando avanti un’applicazione in continua evoluzione:

- 33 - ● per quanto riguarda l’applicazione in generale, come emerso dagli user-studies, risulterebbe di grandissimo aiuto un mini-tutorial opzionale, da mostrare all’ingresso dell’app, per introdurre all’utente le funzionalità presenti ancor prima che cominci l’esplorazione; ● per una diffusione più capillare si provvederà a sviluppare l’app per altri sistemi operativi; ● come consigliato da un utente, si potrebbe progettare un sistema di segnalazioni in tempo reale, per permettere la diffusione di notizie quali l’esaurimento di un certo cibo o la chiusura di una data mensa. Questa funzionalità potrebbe comportare numerosi vantaggi, ma devono essere valutati in modo preciso i rischi legati all’apertura di un canale comunicativo senza controllo; ● risulta innegabile la necessità di fornire un supporto esteso per le lingue, visto soprattutto l’ambiente multiculturale presente nell’Ateneo di Trento. Questo significa sia tradurre l’app almeno nelle lingue più comuni, sia rendere disponibili i nomi dei cibi in altri idiomi; ● relativamente ad iFame, una descrizione ufficiale del piatto e degli ingredienti contenuti potrebbe offrire diversi benefici agli utenti, in particolare a vegetariani, celiaci o con diete legate a motivi etnici o religiosi. A questo proposito si deve proseguire nell’ottica del cosiddetto “healthy eating” che, seppur discusso nella parte di analisi della letteratura, non ha ancora trovato un effettivo riscontro nell’applicazione. Sempre riguardo il “mangiare sano”, infine, si potrebbe implementare il calcolo delle calorie come nell’app “McDonald’s Italia” [19], fornendo all’utente una funzionalità dal forte impatto visivo; ● come fatto notare da un utente, inoltre, i piatti del menu del giorno potrebbero ospitare un collegamento diretto alle relative recensioni, permettendo all’utente prima di visualizzare le opinioni a riguardo e poi, una volta concluso il pasto, di inserire facilmente la propria; ● per quanto riguarda iFretta, una fase successiva potrebbe concentrarsi sullo studio e la definizione di un algoritmo in grado di analizzare la quantità di persone presenti in coda, in modo da restituire il numero di minuti d’attesa previsti; al momento questa feature è irrealizzabile, data la scarsa qualità dei frame delle webcam e il non perfetto posizionamento delle stesse. Se queste venissero però sistemate e magari potenziate, si potrebbero aiutare anche gli utenti che vanno in una certa mensa senza conoscerla; ● inoltre, come mostrato nel mockup definitivo, le webcam nella lista dovrebbero venire accorpate per “edificio” (ad esempio Mesiano1 e Mesiano2 riunite in “Mesiano”), in modo da consentire all’utente di scegliere in modo più agevole in quale andare a mangiare;

- 34 - ● il collegamento a ViviTrento, ancora da realizzare, presuppone che questa contenga tutti i dati necessari relativi alle mense. Si potrebbe pensare di permettere l’inserimento e l’aggiornamento di questi direttamente dall’Opera Universitaria, garantendo così date ed orari sempre aggiornati ed affidabili; ● in precedenza si è anche pensato di mostrare il credito presente nella tessera direttamente nella Home di iFame: se da una parte questo avrebbe permesso un notevole risparmio di tempo da parte dell’utente, dall’altra avrebbe reso quasi superflua iSoldi. Questa opzione non è comunque da scartare e se, una volta distribuita l’applicazione, venisse fatta notare da più utenti, potrebbe venir presa in considerazione; ● riguardo ad iGradito, si potrebbe permettere all’utente di segnalare eventuali disfunzioni o disagi direttamente alla commissione mensa o all’Opera Universitaria; ● precedentemente, da parte dell’Opera Universitaria sono stati evidenziati i possibili pericoli legati alle recensioni, che appaiono come un “canale comunicativo unidirezionale e non controllato”, ed è stata proposta un’alternativa: feedback nella forma di questionario, sia con domande a risposta multipla, sia con campi testuali liberi (con moderatore) su temi ben identificati, quali ambiente, qualità e servizio della mensa. Tale richiesta è stata però presa solo parzialmente in considerazione, in quanto l’obiettivo primario di iGradito è quello di creare una “Community” per la mensa: se l'utente ha volontà di contribuire, allora ha necessariamente bisogno di libertà di scrittura, altrimenti la recensione diventa vincolata e innaturale. Sarebbe inoltre assurdo chiedere all'utente di valutare il servizio della mensa complessivamente ogni qualvolta decida di recensire un piatto. In futuro, però, la soluzione potrebbe consistere in un popup che periodicamente richiede all'utente di lasciare un commento riguardo al servizio in generale.

- 35 - Bibliografia [1] Progetto Smart Campus. http://www.smartcampuslab.it/. [2] TrentoRISE. http://www.trentorise.eu/. [3] Balsamiq Mockups. http://www.balsamiq.com/products/mockups. [4] Pixton. http://www.pixton.com. [5] Go!Animate. http://goanimate.com/. [6] H. Sharp, Y. Rogers, J. Preece, “Interaction Design: Beyond Human-Computer Interaction”, 2^ edizione, John Wiley & Sons, 2007. [7] T. Schlatter, D. Levinson, “Visual Usability: Principles and Practices for Designing Digital Applications”, 1^ edizione, Morgan Kaufmann, 2013. [8] K. Mullet, D. Sano, “Designing Visual Interfaces: Communication Oriented Techniques”, 1^ edizione, Prentice Hall, 1994. [9] SIGCHI. http://www.sigchi.org/. [10] ACM. http://www.acm.org/. [11] A. Grimes, R. Harper, “Celebratory Technology: New Directions for Food Research in HCI”, in Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, CHI ‘08, pagg. 467-476, New York, NY, USA, 2008. ACM. [12] J. Xu, P. Chen, S. Uglow, A. Scott, E. Montague, “Design Challenges and Guidelines for Persuasive Technologies that Facilitate Healthy Lifestyles”, in International Journal of Computer Technology and Application 3, pagg. 140-147, 2012. [13] C. Linehan, T. Leeman, C. Borrowdale, S. Lawson, “Crowd saucing: social technology for encouraging healthier eating”, in Interactions (volume 20, issue 1, January + February 2013), pagg. 53-57, New York, NY, USA, 2013. ACM.

- 36 - [14] Nielsen’s Severity Ratings for Usability Problems. http://www.nngroup.com/articles/how-to- rate-the-severity-of-usability-problems/. [15] Smart Campus forum. http://www.smartcampuslab.it/forum/viewtopic.php?f=9&t=84. [16] P. Peri, M. Bazzoli, “Indagine sulla soddisfazione degli utenti dei servizi di ristorazione offerti dall’Opera Universitaria di Trento”, Opera Universitaria di Trento, 2012. [17] Opera Universitaria di Trento. http://www.operauni.tn.it. [18] Eating in the UniTn canteen! http://docs.google.com/forms/d/16FVvTDrsL_u2jt24rN- Abg4WifC383puLjHVuUitZsY/viewform?pli=1. [19] Mc Donald’s Italia applicazione Android. http://play.google.com/store/apps/details?id=com.getset.android.mcdonalds&hl=it.

- 37 - Appendice [AP1] Il mockup interattivo in Balsamiq realizzato per il coursework. http://www.dropbox.com/s/g1pr7rjz7zagtot/%5BAP1%5D.pdf. [AP2] La lista dei tasks assegnati all’utente da effettuare sul prototipo iniziale. In seguito oppure al link http://www.dropbox.com/s/93rqqbctym1bx85/%5BAP2%5D.pdf. [AP3] La tabella contenente i problemi di usabilità riscontrati durante gli user-studies. In seguito oppure al link http://www.dropbox.com/s/t4lb7fxv04h45e7/%5BAP3%5D.pdf. [AP4] La tabella contenente i risultati del sondaggio “Eating in the UniTn canteen!”. http://www.dropbox.com/s/9l15ob8nso1k2sz/%5BAP4%5D.xlsx. [AP5] Il documento (in inglese) elencante le specifiche tecniche di iFame. In seguito oppure al link http://www.dropbox.com/s/e8iw8huw8n87whi/%5BAP5%5D.pdf. [AP6] Il documento elencante le funzionalità da includere in iFame. In seguito oppure al link http://www.dropbox.com/s/f2plhv27qy3hn9j/%5BAP6%5D.pdf. [AP7] La versione definitiva del mockup in seguito al redesign. http://www.dropbox.com/s/3qmog7oh0jofu52/%5BAP7%5D.pdf. [AP8] Il documento elencante le somiglianze tra iFame e il set di applicazioni di Smart Campus. In seguito oppure al link http://www.dropbox.com/s/33qrzoqltsfhz49/%5BAP8%5D.pdf. [AP9] La lista dei tasks assegnati all’utente da effettuare sul prototipo definitivo. In seguito oppure al link http://www.dropbox.com/s/i8tvsy43ym5b9kj/%5BAP9%5D.pdf. [AP10] La tabella contenente la valutazione su mockup definitivo e prima release di iFame. http://www.dropbox.com/s/wzvu45sndofw07a/%5BAP10%5D.xlsx.

[AP2] Tasks assegnati agli utenti per verificare l'usabilità del prototipo in Balsamiq di iFame All'utente viene chiesto di: • visualizzare il menu del mese • visualizzare il proprio credito residuo • scrivere la propria recensione per il piatto “Anatre” • visualizzare le info su “iFame” • visualizzare la tipologia di menu “Ridotto” • visualizzare la coda alla mensa di Povo • tornare indietro alla schermata precedente • visualizzare le alternative al menu del giorno • visualizzare l'elenco dei piatti da recensire • visualizzare i propri dati • visualizzare la coda a Mesiano • inserire un piatto da recensire • comporre un proprio menu • visualizzare le calorie dei vari piatti • scegliere la lingua nella Home • visualizzare l'elenco delle webcams • visualizzare il menu del giorno • cercare nella pagina Home • visualizzare le recensioni per il piatto “Anatre” • visualizzare le tipologie di menu

Problema Degree Severity Rating Scale Possibile soluzione 4 4 4 4 All'utente viene chiesto di visualizzare il menu del mese: prima entra in iFretta (giustificandosi con “lo voglio sapere subito perchè ho fretta”). Poi cerca di premere sul titolo “iFame”, quindi entra in iSoldi. Sostiene che non avrebbe mai pensato ad iDeciso perchè rappresenta qualcosa di “già” deciso (il nome trae in inganno) Usability catastrophe: imperative to fix this before product can be released Il nome iDeciso risulta fuorviante. Possibili soluzioni: iScelta, iDubbi, iMenu, iDeciso? (col punto di domanda). Oppure ridenominarla iFame e chiamare l'app con un nome riguardante la mensa. All'utente viene chiesto di visualizzare il menu del mese: inizialmente preme su iFretta, convinto che sia un rapido sistema per ottenere le informazioni di cui necessita. Tornato indietro, seleziona correttamente l'icona di iDeciso Usability catastrophe: imperative to fix this before product can be released Rendere più chiaro che in iDeciso si trova tutta la sezione relativa ai menu (tramite un'icona più chiara e, soprattutto, un nome più indicativo). L'utente ritiene che il carrello non vada bene, mentre sarebbe ideale l'icona stessa di iFame (o anche la nuova, ma senza cannuccia) All'utente viene chiesto di visualizzare il menu del mese: ma iDeciso non dà immediatamente idea che all'interno vi sia elencato il menu. L’utente lo capisce solo dopo aver anche visualizzato tutte le immagini Usability catastrophe: imperative to fix this before product can be released Rendere più chiaro che in iDeciso si trova tutta la sezione relativa ai menu (“meglio il carrello perchè faccio la spesa”, “il carrello è un simbolo troppo significativo”) All'utente viene chiesto di visualizzare il suo credito residuo. Entra immediatamente in iSoldi ma, una volta lì, si chiede il perchè di questo passaggio per visualizzare unicamente il credito. Usability catastrophe: imperative to fix this before product can be released Secondo l'utente sarebbe estremamente vantaggioso se il credito gli venisse mostrato sempre in cima alla Home di iFame, senza dover fare ulteriori passi (come anche per la mensa preferita)

3 3 3 3 2 All'utente viene chiesto di scrivere la propria recensione per “Anatre”: arrivato però all'interno di iGradito, crede di non poter più svolgere questo task, poiché la casella è già riempita con “Giudizio medio” e due bottoni Major usability problem: important to fix, so should be given high priority Redesign completo della parte dedicata alle recensioni per iGradito All'utente viene chiesto di inserire un piatto da recensire: scorre tutta la schermata di “iGradito” alla ricerca di un bottone “Aggiungi”, tenta tutte le possibili soluzioni, finchè non clicca “+” Major usability problem: important to fix, so should be given high priority Problema risolto nel caso in cui l'Opera (o il servizio di ristorazione) fornisca già l'elenco completo dei piatti a disposizione dell'utente All'utente viene chiesto di visualizzare le alternative al menu del giorno: ricerca così nell'applicazione un pulsante corrispondente ma, ovviamente, senza risultato. Si reca perciò in “Tipologie di menu”. La posizione nascosta del bottone, inoltre, rende il compito più difficile anche una volta entrato in Menu del giorno Major usability problem: important to fix, so should be given high priority Redesign della parte dedicata alle alternative al menu del giorno; come renderle più visibili? Un'idea è quella di scrivere “Menu del giorno e alternative”. L'utente si chiede inoltre perchè, essendo iDeciso la funzionalità cardine e più corposa, non si trovi come prima (in alto a sinistra) All'utente viene chiesto di visualizzare le alternative al menu del giorno: non ha però chiaro che cosa realmente siano, quindi la ricerca appare un po' difficoltosa. Clicca prima su “Componi il tuo menu” dato che non l'ha ancora visualizzato, ma poi si dirige al menu del giorno Major usability problem: important to fix, so should be given high priority Redesign della parte dedicata alle alternative al menu del giorno; come renderle più visibili? Una soluzione potrebbe essere chiamare le alternative “Menu fisso”. Oppure, come suggerisce l'utente, spostare la funzionalità in iDeciso All'utente viene chiesto di tornare indietro di una schermata: essendo iOS user, ha premuto più volte in alto a sinistra aspettandosi di ritornare alle schermate precedenti. Una volta ha addirittura premuto il pulsante Home Minor usability problem: fixing this should be given low priority Aggiungere la freccia “Indietro” nella ActionBar delle Activity

2 2 Sostituire “In più” con “Alternative” 2 2 1 0 0 All'utente viene chiesto di creare un proprio menu: egli però non può cliccare su alcune checkbox e vorrebbe capirne il motivo Minor usability problem: fixing this should be given low priority L'apparenza di un Toast esplicativo potrebbe risolvere il problema All'utente viene chiesto di visualizzare le alternative al menu del giorno: egli si reca correttamente in “Menu del giorno”, ma poi non è sicuro se cliccare su “In più” Minor usability problem: fixing this should be given low priority All'utente viene chiesto di visualizzare i propri dati del profilo: ha qualche difficoltà, poiché non immagina l'utilizzo del pulsante menu Minor usability problem: fixing this should be given low priority Rimuovere i dati relativi all'utente rendendoli disponibili direttamente dalla Home di SmartCampus All'utente viene chiesto di visualizzare la coda alla mensa di Povo: clicca su iFretta, ma a quel punto è in dubbio se la mensa sia indicata con “Povo1” o “Povo0” Minor usability problem: fixing this should be given low priority Cambiare i nomi delle mense in “Povo Mensa” e “Povo Mensa Veloce” All'utente viene chiesto di visualizzare le alternative al menu del giorno: la risposta dell’utente non è immediata come nelle altre richieste. Servono due tentativi per trovare la funzionalità richiesta: l’utente consiglia un riposizionamento del bottone Cosmetic problem only: need not be fixed unless extra time is available on project Redesign della parte dedicata alle alternative al menu del giorno; come renderle più visibili? All'utente viene chiesto di visualizzare la coda a Mesiano: una volta arrivato alla webcam desiderata vede lo screenshot, ma non sa come interpretare il dato I don't agree that this is a usability problem at all L'utente suggerisce di aggiungere una funzionalità che stimi quanto tempo dovrà attendere in coda in quel caso All'utente viene chiesto di scrivere la propria recensione per “Anatre”: entra in Menu del giorno cercando “Anatre” per poi cliccarci sopra e votarle I don't agree that this is a usability problem at all L'idea di votare il pasto del giorno premendo direttamente sullo stesso è da tenere in forte considerazione!

[AP5] iFame VAS specification The iFame application aims to become a grouping of all those functionalities required by students to enjoy the canteen experience at most, enhancing the quality of the service with benefits on both sides of itself: this means iFame could be extremely useful not only for the customers, but also for the company which is the provider of the canteen. 1. Functionalities 1.1 iFretta A list of all the canteens in Trento is shown: after selecting the one where the customer wants to eat, the entity of the queue is displayed in terms of a real-time image (provided by the Opera Universitaria). Moreover, the user has the possibility to reach the chosen canteen-entry in ViviTrento, indicating its location and timetable/calendar. 1.2 iDeciso This app provides all the information that need to be known by the client, such as: - the composition of the daily menu, which means all the available dishes for the current day (including the alternatives for people with specific dietary needs); - the different types of menu that can be bought, with their price and the possible combinations allowed; - the monthly menu, which can be read week per week or day per day; - the possibility to compose their own (daily) menu, verify which is the one that corresponds to what the user has selected and choose among the several types (explained in the second feature of the application). 1.3 iGradito iGradito acts like a community for the canteen customers, where they can post reviews about

the quality of the food they eat and, obviously, see others' reviews: this can give a relevant clue about how a specific dish will taste, and whether it deserves to be bought. The review is composed of two parts: the former is a mark expressed on a scale from 1 to 10, while the latter is a written comment where the user is allowed to explain the reason of their good/bad mark. Furthermore, every comment can be voted by other users too, with a “like” or a “dislike”: this feature guarantees the reliability of the comment. 1.4 iSoldi This app is a sort of container for all the information about the canteen customer. The main functionality is to show the money left in the canteen card. In addition, there is the possibility to toggle other info within the page: this information are not well-defined yet, and depend on which data will be available and provided by the Opera Universitaria. However, iSoldi will surely include: - the number of the card associated to the user; - the amount of money inside the card; - the history of the transactions (dates and relative imports both for refills and purchases). 2. Data (minimal) required from external systems 2.1 iFretta - Data stream of the webcams - Up-to-date list of all the canteens and conventioned bars 2.2 iDeciso - Digitalized datas of the monthly menu - Complete list of all the dishes with the corresponding calories - Well-defined list of all the possible combinations of menu - Clear explanation of the alternative dishes (vegetarian / celiac / bio / etnic...) - English names, ingredients and brief descriptions of the dishes

2.3 iGradito - Complete list of all the dishes with the corresponding calories - Clear explanation of the alternative dishes (vegetarian / celiac / bio / etnic...) - English names, ingredients and brief descriptions of the dishes 2.4 iSoldi - Card number (id) - Up-to-date amount of money in the card - History of the transactions (dates and relative imports both for refills and purchases) 3. Platform requirements - Internationalisation - Authentication - Server-side: support for notifications, mapping crud onto Domain Objects, search using semantic engine, search with pagination, authentication - Service wrapping: incremental cache (for user-specific data) 4. Architecture - Online Database for retrieving datas such as the reviews in iGradito. - Database filled with the complete list of dishes, menus, types, etc... - Database with the webcams link - Access (read-only) to the Opera DB in order to retrieve the data associated with the user - Comments: for each dish, assign a list of comments with the related user - Ratings: for each dish, assign a list of ratings with rating value - Likes/dislikes: for each comment, assign a list of likes and/or dislikes - User statistics: number of comments written, number of ratings done, number of canteen accesses, number-imports-dates of refills/purchases

[AP6] Funzionalità da includere in iFame iFame Home Design consono con lo standard Smart Campus, introduzione alle 4 aree principali individuate per l'applicazione. 4 ImageViews clickabili con Intent per il lancio dell'applicazione desiderata. Eventualmente possiamo considerare un menu di opzioni dove recuperare funzionalità come ad esempio verificare la presenza di aggiornamenti, avere a disposizione alcuni dati personali (di login, etc), info sull'app (versione, etc) e poter fare segnalazioni dirette all'Opera (ma ancor più alla Commissione Mensa!). iFretta Una ListView con le mense della città di Trento, ed eventualmente un collegamento laterale dalle stesse all'applicazione ViviTrento per informazioni sulla posizione geografica e gli orari delle mense. Necessità: - Aggiungere Povo FBK Trento Rise, Povo Bar, Mesiano Bar e SanBa Bar alle mense - Fixare posizione telecamere e aggiungere le mancanti Alla selezione della mensa desiderata la schermata mostra un riferimento al nome della stessa e all'ora dell'ultimo snapshot acquisito. Troviamo poi chiaramente il placeholder per l'immagine e un tasto "Refresh" per eventualmente cercare di acquisire immagini più recenti. Per l'implementazione: l'immagine in questione potrà venire acquisita direttamente tramite protocollo ftp dalle webcam o recuperata dal sito dell'Opera, urge verificare eventuali latenze, ed entità di queste, per scegliere l'opzione implementativa più efficiente.

iDeciso Problematiche: - Mancanza di dati strutturati (attualmente disponibile solo un PDF mensile) e verifica della consistenza tra i pasti elencati e i pasti effettivamente serviti giornalmente. - "digitalizzazione" dei dati per fornire il menu giornaliero che deriva da quello mensile. Necessità: - Nome cibi in inglese per gli utenti stranieri. - Breve descrizione del pasto (o perlomeno ingredienti presenti – anche se non segnalati). - menu per DIETE/ALLERGIE/CELIACHIA/RELIGIONE/VEG/BIO/ETNICI Pensavamo di introdurre un pulsante affianco al titolo dell'activity per linkare alle statistiche dell'utente e avere informazioni sui pasti consumati precedentemente. Le funzionalità "cardine" rimangono invece: - "Menu del giorno": necessità di estrarre digitalmente i dati forniti dall'opera per automatizzare la visualizzazione del menu per il giorno in questione (ci è stato detto che l'Opera dovrebbe impegnarsi a fornire i dati in maniera più accessibile per noi) Graficamente, listView che mostra i piatti disponibili a seconda della tipologia (primi,secondi etc.). Rimane da stabilire se mostrare tutti i piatti immediatamente in lista oppure inglobarli nelle varie tipologie. Resta comunque molto forte la dipendenza da come i dati ci verranno forniti, che rimane ancora un mistero. - "Tipologie di menu": riferimento alle varie tipologie attualmente acquistabili (intero,ridotto,snack) e le varie possibile composizioni di queste rendendole il più chiare possibili in quanto sono uno dei punti di maggior incertezza per gli utenti. - "Fai il tuo menu": lista di checkboxes che consentono di selezionare i tipi di piatto che si intende acquistare e restituiscono la tipologia associata, il corrispettivo di prezzo ed eventuali pietanze aggiuntive comprese nella scelta. Sarebbe fantastico riuscire ad ottenere dinamicamente il menu del giorno per poter associare alle checkboxes direttamente i piatti disponibili per quella data anziché la tipologia generica dei piatti (cioè selezionare ad esempio "pasta A.O.P" al posto di "primo piatto", oppure comunque visualizzare "primo piatto" però avere la possibilità di vedere in cosa consiste quella tipologia per il giorno in questione, anche perché alcune non sono chiare agli utenti).

- "Menu del mese": semplice funzionalità descrittiva delle pietanze che sarà possibile acquistare nel mese corrente. Pensavamo di dividere questo in 2 aree: 1. Visualizza menu del mese completo (riferimento rapido e immediato) 2. Visualizza menu di un giorno specifico. iGradito Activity che mostra feedbacks degli utenti riguardo ai piatti specifici. - Database interno dovrà contenere i dati dei piatti e delle recensioni, che pensavamo di mettere in forma valutazione numerica e/o recensione (la prima per un giudizio sintetico scala 1/10 e la seconda per eventuali segnalazioni facoltative). - Fornire il nome dell'utente basandosi sui dati di login - Siccome la mensa non è un servizio a cui tutti accedono con la stessa frequenza, leggere commenti di persone che la frequentano saltuariamente può comportare giudizi generalmente più negativi, quindi associare al nome dell'utente un dato che indichi quanto questa persona utilizzi il servizio (magari in base al numero di recensioni postate, oppure al numero di accessi ad iFame) può migliorare l'activity. Usare un sistema simile ad Ebay potrebbe essere una mossa vincente, dando la possibilità di valutare le recensioni altrui con like/dislike per avere garanzia che la recensione sia condivisa tra più utenti, e permettere all'utente di ordinare le recensioni per vari parametri (data di inserimento, numero di "likes" etc). I dati sono semplici entries del database a cui si associano tutte le info necessarie. - Rispetto al primo mockup che abbiamo proposto è forse da rivedere la possibilità data all'utente di aggiungere piatti nel caso non siano presenti nel DB per non creare inconsistenze nei dati (ad esempio avere nel DB sia "pasta A.O.P" che "pasta aglio olio peperoncino) anche perchè se i dati verranno forniti in maniera strutturata sarà semplice verificare se le pietanze hanno la loro entry associata oppure no. iSoldi - Come in iDeciso inseriamo il bottone delle statistiche per mostrare tutti i dati a disposizione di interesse dell'utente (storico pasti, credito speso, orari di punta della coda etc). - I dati dovrebbero essere disponibili senza troppi intoppi per cui l'activity si proporrà di mostrare il traffico residuo e le tipologie di menu acquistabili in base al credito disponibile (magari con collegamento alla parte "Tipologie di menu" di iDeciso in base al credito residuo.

SOMIGLIANZE di iFame con SMARTCAMPUS: • iFame Home: ricalca in pieno la Home di ViaggiaTrento/LifeLog/INBox, con le diverse icone tutte del medesimo colore. Le scritte potrebbero però essere colorate, dato che sono brevi e rappresentano il titolo della “sotto-app”, non un menu/funzionalità. Inoltre bisogna decidere se mettere il nome sotto o sopra l'icona. • iFretta Home: la lista delle webcams riprende quella di “Invia segnalazioni” di ViaggiaTrento, anche se potrebbe esser realizzata come quella in “Info in tempo reale”. Non sarebbe male nemmeno l'idea di utilizzare le liste di ViviTrento, con l'icona di una videocamera di fianco al nome della mensa. • iFretta Mesiano: può tranquillamente venire realizzata partendo da zero, con una label per il nome della mensa, lo snapshot corrispondente e un bottone per rimandare a ViviTrento.

• iDeciso Home: vale lo stesso discorso di iFretta Home. Si è deciso di utilizzare una lista come quella in “Info in tempo reale”. Alternative possono essere quella di “Invia segnalazioni” o quelle di ViviTrento. • iDeciso Menu del Giorno: una label indica il giorno corrente, affiancata da un bottone che rimanda alle “Alternative” al menù del giorno. Le tre liste (primi, secondi e contorni) possono ricalcare quelle di “Eventi”oppure di “Ritardo autobus” , con uno specifico header colorato per ogni portata. • iDeciso Alternative: identico ad iDeciso Menu del Giorno. • iDeciso Componi Menu: una semplice lista di checkbox dove, una volta premuta la componente del menu desiderata, viene dinamicamente esteso “l'albero” con le portate del menu del giorno.

• iDeciso Menu Risultato: il menu risultante mostrato come immagine fornita dall'Opera Universitaria e seguito da una textbox con le descrizioni del menu. • iDeciso Tipologie di Menu: identico a iDeciso Menu Risultato, mostra le immagini dei menu accompagnate dalla descrizione delle tipologie, che vengono divise tramite “tabs”, come in “Pianifica Viaggio”, “ViviTrento” o “Shared data”. • iDeciso Menu del Mese: una tendina stile “Invio segnalazioni” o “INBox” con le varie settimane del mese seguita da una lista scorrevole, come in “Eventi”, con i menu di tutti i giorni della settimana.

• iGradito Home: come in iDeciso Menu del Mese, una tendina stile “Invio segnalazioni” o “INBox” con le varie categorie di cibi. Quindi, un elenco in ordine alfabetico di tutti i cibi come in “Rubrica”. Il menu opzioni permette all'utente di contattare direttamente la Commissione Mensa. • iGradito Visualizza Recensioni: un titolo per il cibo in questione accompagnato da alcune info. Quindi un bottone “Scrivi recensione” che permette di votare il pasto. Sotto, una lista di tutte le recensioni relative a quel determinato pasto: la lista si carica dinamicamente man mano che si scrolla, come in “INBox”, “ViviTrento” o “Shared Data”. Tramite un click sul pollice in su/in giù si può approvare o disapprovare un commento. Il menu opzioni permette all'utente di ordinare le recensioni per numero di likes o per data.

• iGradito Aggiunta Recensione: un popup come in “Pianifica Viaggio” con una tendina stile “Invio segnalazioni” o “INBox” per votare il pasto, quindi una textbox dove commentare. • iGradito Conferma Aggiunta: identica a iGradito Visualizza Recensioni, solo che mostra un toast di avvenuto inserimento come in “I miei viaggi”. • iSoldi Home: semplici labels e elenchi puntati per esporre la disponibilità della card, quindi un bottone “Le tue statistiche” che espande la sezione come in “Pianifica Viaggio”.

No content

[AP9] Tasks assegnati agli utenti per verificare l'usabilità del nuovo prototipo in Balsamiq di iFame All'utente viene chiesto di: • visualizzare il menu del mese • visualizzare il proprio credito residuo • aggiungere la propria recensione per “Anatre” • visualizzare la tipologia di menu “Ridotto” • visualizzare le alternative al menu del giorno • visualizzare l'elenco dei piatti da recensire • visualizzare le proprie statistiche e transazioni • visualizzare la coda a Mesiano • creare un proprio menu • visualizzare le calorie dei vari piatti • ordinare le recensioni per data • visualizzare l'elenco delle webcams per la coda • visualizzare il menu del giorno • cercare uno specifico piatto da recensire • tornare indietro alla schermata precedente • visualizzare le recensioni per “Anatre”