Relazione del progetto "in Bicocca"

1

inBicocca Relazione di proge/o Gruppo 4 Gregorio Marchi – Giulia Marzagalli – Salvatore Sisca

Il Proge.o

2

Abbiamo sviluppato un sito dedicato a tu1 gli user del quar@ere Bicocca (a/uali e potenziali), con un’a/enzione par@colare per gli uten@ “in movimento”, ovvero coloro che si trovano nello spazio fisico del quar@ere con la possibilità, grazie a device quali tablet e smartphone, di conne/ersi.

Il sito perme/e di cercare e trovare ciò che si desidera o ciò di cui si ha bisogno tramite l’interazione con una sorta di tavola periodica sovrapposta alla mappa del quar8ere, in cui gli elemen@ non sono altro che piccole porzioni del territorio, all’interno delle quali si trovano servizi e luoghi di interesse.

Cronologia della proge.azione

3

Fase 1_Brainstorming, le domande

Ci siamo sedu@ a/orno ad un tavolo e ci siamo chies@:

Chi cerca informazioni sul quar@ere Bicocca? Perché? Quali sono le sue esigenze? In quali circostanze potrebbe fare queste ricerche? A/raverso quali mezzi?

Alcune indicazioni ci sono arrivate dalle risposte ai ques@onari, altre da esigenze personali come nuovi uten@ del quar@ere (nessuno di noi tre vive o ha frequentato la triennale in Bicocca), altre ancora da ispirazioni derivate da un’aRvità di web-‐scou4ng. Abbiamo quindi definito i qua/ro possibili profili utente.


4

Fase 1_Brainstorming, generico profilo RESIDENTE

Persona che vive nel quar@ere e che ne ha, quindi, una conoscenza mediamente buona.

Usa abitualmente servizi come i mezzi di trasporto o i negozi in cui fare acquis@, di cui conosce già una serie di de/agli, come gli orari e la localizzazione. È comunque interessato ad approfondire questa conoscenza, curiosando alla ricerca di “cose nuove”, alla scoperta di realtà che gli sono sfuggite muovendosi nello spazio fisico.


5

Fase 1_Brainstorming, generico profilo UNIVERSITARIO

Persona che gravita nel mondo dell'università: studente, ricercatore, docente e personale universitario.

È interessato in par@colare a tuR gli spazi che l’Università Bicocca ha disseminato nel quar@ere, ma anche ai mezzi di trasporto e ai luoghi dove mangiare durante il pranzo (sopra/u/o a buon prezzo).

Gli studen@ cercano inoltre luoghi in cui intra/enersi durante le pause tra le lezioni (palestre, parchi...) o a fine giornata (locali, pub...).


6

Fase 1_Brainstorming, generico profilo LAVORATORE

Impiegato in una delle società che hanno sede nel quar@ere o adde/o ai servizi.

È interessato in par@colare ai mezzi di trasporto e ai parcheggi, come anche a tuR i luoghi dove passare la pausa pranzo (centri fitness, ristoran@, pizzerie...).


7

Fase 1_Brainstorming, generico profilo VISITATORE

Si reca nel quar@ere Bicocca per un determinato evento (spe/acolo teatrale, mostra, concerto...). Non ha alcuna conoscenza del quar@ere e dei suoi spazi, o minima se ci è stato altre volte.

È interessato a conoscere i servizi nelle immediate vicinanze del luogo in cui si deve recare. Inoltre, se la sua visita lo richiede, potrebbe aver bisogno di conoscere hotel e alberghi presen@ sul territorio.


8

Fase 1_Brainstorming, le risposte

TuR gli user ipo@zza@ vogliono uno strumento semplice e immediato, che gli perme/a di agire il quar@ere, conoscendone orari, spazi e servizi presen@. Con un livello di approfondimento che non dica più del necessario, per evitare un “fasidioso sovraccarico informa@vo”.


9


Ovviamente uten8 diversi hanno esigenze specifiche diverse, che per noi non sono altro che le diverse strategie di ricerca rese possibili dall’interfaccia del sito.

Abbiamo delineato n possibili @pi di ricerca:

•  l’utente ha un bisogno specifico (mangiare, spostarsi...) e vuole avere informazioni de/agliate (dove si trova, orari, sito…); •  l’utente cerca “qualcosa” vicino a dove si trova o a un punto specifico del quar@ere; •  l’utente può essere interessato ai servizi aper@ nel momento in cui usufruisce del sito o comunque filtrarli a seconda dell’orario; •  l'utente vuole avere una overview di tu/o ciò che il quar@ere offre.


10


Per quanto riguarda i servizi, inizialmente abbiamo provato a categorizzarli per 8po, sulla falsa riga della pagine gialle (cfr word allegato “elenchi.odt”). Non riuscendo a trovare un equilibrio tra numero, specificità e confini delle categorie abbiamo cambiato paradigma di categorizzazione.


11


Secondo noi gli uten@ cercano risposte ai loro bisogni. Perciò, per “saltare un gradino” tra scopo e azione, abbiamo deciso di categorizzare i servizi basandoci sui bisogni “primari” dell’utente piu/osto che sul @po di servizio. Abbiamo così delineato 6 bisogni in cui i servizi del quar@ere potevano essere suddivisi:

•  Mangiare •  Perno/are •  Comprare •  Diver@rsi •  Spostarsi •  Studiare


12

Fase 2_ Primi schizzi

Abbiamo deciso di stru/urare l’interfaccia come un tavola periodica sovrapposta ad una mappa del quar@ere, con la possibilità di filtrare gli elemen@ tramite una consolle a tre categorie: tribù urbana, @po di servizio e orario.

All’inizio l’idea era di far corrispondere ad un tassello della tabella un servizio, ma ci siamo accor@ di due problemi: alcuni servizi sono le/eralmente sovrappos@ (es. piazza della Trivulziana con molteplici locali/negozi...) o comunque talmente fiR che avremmo dovuto fare dei tasselli microscopici, impossibili da ges@re con un’interfaccia touch.


13

Fase 2_ Primi schizzi

Abbiamo quindi deciso che se ci fossero sta@ più servizi in un tassello l’interazione con quest’ul@mo avrebbe aperto un’altra pagina con una lista (secondo livello), con ulteriori rimandi a pagine specifiche di approfondimento per ogni servizio (terzo livello).

Ci siamo resi conto però che una stru/urazione simile avrebbe potenzialmente fa/o “perdere la bussola” all’utente, perciò abbiamo pensato a un merge del secondo e terzo livello, tramite un overlay.

Sempre per facilitare la navigazione abbiamo eliminato il filtro orario. Abbiamo ipo@zzato l’u@lizzo di un qualche metodo per evidenziare nel primo livello i servizi aper@ al momento dell’accesso dell’utente, ma sarebbe stato complesso da inserire in maniera intui@vamente comprensibile.


14


15

Soluzione conce.uale

16

Perché la metafora della tavola periodica:

Volendo schema@zzare i servizi presen@ nel quar@ere all’inizio abbiamo pensato alla metafora della tavola periodica, con ogni servizio rappresentato da una tesserina/elemento chimico. Ciò avrebbe permesso una più organizzata disposizione dei servizi nella presentazione all’utente, e di associare un’informazione numerica -‐ così come presente negli elemen@ chimici -‐ nel nostro caso rela@va all’orario di fruizione ideale di un servizio.

In seguito ci siamo accor@ che la densità e la sovrapposizione di servizi non perme/eva questa soluzione, ma la tavola periodica è rimasta il nostro modello di riferimento, perché capace di comunicare immediatamente un senso di ordine e pulizia.


17

Fase 3_ Divisione di compi8 e responsabilità

Decisa la stru/urazione di massima del proge/o ci siamo divisi le aree proge/uali a seconda di competenze e interessi personali. Abbiamo inoltre creato uno spazio condiviso sul Dropbox per condividere i materiali, lavorare in contemporanea sugli stessi file, ed essere tuR aggiorna@ in tempo reale sul progress del proge/o.


18

Fase 4_ Prime proto8pazioni

Durante la fase di sviluppo sono sta@ crea@ diversi proto8pi, alcuni per lo studio del filtro, altri per lo studio dell’interazione coi livelli. Il primo script per il filtro faceva sparire le/eralmente gli elemen@ non interessan@. Dato che ciò poteva disorientare gli uten@ abbiamo scelto di fare il contrario, ovvero di evidenziare gli elemen@ filtra@ tramite l’assegnazione di un colore e di un simbolo.


19


Prima prova di posizionamento delle macro-‐aree


20


Prima prova di funzionamento del filtro


21


Seconda prova del filtro


22


Prima implementazione delle stru/ure grafiche

Il sito finale

23 Schermata del sito in un esempio d’uso.

Il sito finale

24 Livello 2: visuale con liste chiuse

Il sito finale

25 Livello 3: informazioni de/agliate di un servizio

Archite.ura informa8va

26

Selezione dei principali pun@ di interesse del quar@ere Bicocca e loro iden@ficazione con la @pologia del servizio (univoca) e tribù di riferimento (una o più tribù per ciascun posto).

Per ogni punto di interesse è pensata una scheda di approfondimento contente una serie di informazioni de/agliate che rispondono a tu/e le potenziali esigenze dell’utente: orari, contaR, indirizzo fisico, mappa*, descrizione...

*il plugin di Google Maps (con il punto del servizio e il punto di dove si trova precisamente l'utente) è solo simulato, non avendo avuto tempo di implementare questa feature.

Sistemi di navigazione e di interazione

27

TuR gli elemen@ della tavola periodica sono aRva@ tramite dei filtri, in base alla categoria d’utente (tribù) e al 8po di servizio.

Seleziona@ i filtri si evidenziano gli elemen8 con un contenuto inerente alla selezione. Il colore dell’elemento è associato alla tribù, mentre l’icona al servizio.

Cliccando su uno degli elemen@ evidenzia@ appare in sovraimpressione (overlay) la lista dei servizi. I pallini colora@ indicano le tribù che possono usufruire del servizio.

Per avere informazioni più de/agliate si deve selezionare un elemento della lista, aprendone i contenu@ tramite un accordion.

Aspe1 grafico-‐comunica8vi

28

L’utente, all’accesso al sito, viene a conta/o con una splash page dove trova già una sorta di introduzione al look&feel della pagina principale. Lo sfondo è lo stesso, il logo si trova sopra una mini tabella che introduce al tema della pagina successiva, alla quale si accede selezionando il tasto “entra” nella propria lingua. Al momento portano tuR alla pagina in italiano, ma l’idea del mul*-‐language è pensata in funzione dell’internazionalità dell’utenza del quar@ere.

Nella pagina principale l’utente si trova di fronte alla tavola degli elemen@ del quar@ere.

Scelte croma8che e 8pografiche

29

Visivamente l'interfaccia si presenta con uno s@le sobrio, semplice, pulito, chiaro e il più possibile minimale. Seguendo questo approccio sono sta@ u@lizza@ dei colori base, in gradazione sicura per il web e molto saturi, per una migliore discriminazione e per offrire maggiore “supporto” agli elemen@ chiari contenu@ al loro interno. Queste scelte sono state pensate anche in prospeRva di sviluppo del concept, che prevede “accensione/spegnimento” dei pulsan@ del pannello filtri con soluzioni croma@che che rispecchiano ciò che poi effeRvamente accade nella tavola.

A livello @pografico si è u@lizzato un cara/ere graziato sicuro per il web per le informazioni de/agliate dei luoghi, mentre per tuR gli altri @toli e so/o@toli è stato u@lizzato un cara.ere bastoni integrato al sito grazie al servizio Web Fonts di Google.

Usabilità

30

L'idea principale perseguita nella proge/azione di questa interfaccia è stata quella della facilità d'uso, sopra/u/o per quanto riguarda i parametri di immediatezza di comprensione e fruizione rapida ed efficace dei contenu8. Due sono gli aspeR fondamentali che rendono efficace l'u@lizzo dell'interfaccia: la rappresentazione spaziale degli elemen@ secondo la reale disposizione degli stessi nel quar@ere (e quindi la possibilità di esplorare virtualmente il quar8ere o/enendo solo le informazioni che cerchiamo); la semplicità delle azioni da compiere per accedere alle informazioni che ci interessano (click su pulsan@/aree per visualizzare/nascondere/aprire, e scorrimento per la fruizione dei contenu@), eseguibili con ogni @po di disposi@vo.

Usabilità in mobilità

31

Questa interfaccia è proge/ata sopra/u/o nell'oRca di un u8lizzo su disposi8vi mobili come smartphone e tablet: la loro natura touch e la dotazione di sensori (per geo-‐localizzazione e orientamento) perme/ono un'esperienza ancora più immediata e soddisfacente.

Un possibile u@lizzo è ad esempio quello su un tablet che trasforma la tavola periodica in una vera e propria mappa intera1va fisicamente navigabile con pochi tocchi delle dita, che ci dice dove siamo rispe/o al quar@ere (e a ciò che s@amo cercando), che si riposiziona rispe.o a dove siamo rivol8, e che si adegua all'orientamento dello schermo su cui è visualizzata.

Usabilità in mobilità

32 Esempi orientamen@ e geolocalizzazione

Cara.eris8che tecnologiche

33

Il sito è stato scri/o in XHTML 1.0 transi@onal tramite l’editor Adobe Dreamweaver. Gli elemen@ grafici (sfondi, immagini, pulsan@...) sono sta@ crea@ e/o modifica@ con Adobe Photoshop. Il layout, la grafica e la @pografia sono sta@ defini@ tramite fogli di s@le CSS esterni, tranne qualche a/ributo style=“ ” per mo@vi di interazione con JavaScript. Per comodità sono state usate alcune proprietà incluse da CSS3. I comportamen@ (filtraggio, overlay e accordion) del sito sono sta@ possibili grazie all’implementazione del modulo jQuery TOOLS e script JavaScript dipenden@.

Conclusioni

34

Limitazioni, pecche, pun8 deboli

Uno dei limi@ principali è stato la mancanza di un informa@co puro nel gruppo, per cui lo sviluppo di alcune feature, come la completa compa@bilità cross-‐browser e cross-‐device, non è pienamente realizzata. Ad esempio accedendo al sito tramite un device basato su iOs non è possibile interagire con l’accordion così implementato. Inoltre il filtro non “ricarica” la tabella, costringendo all’uso frequente del tasto reset. Un secondo aspe/o che ci sarebbe piaciuto riuscire a implementare è il filtro del tempo, con gli elemen@ della tabella “opachi/ni@di” a seconda che i servizi interni siano aper@ o meno al momento della fruizione.

Conclusioni

35

Pun8 for8

Un’interfaccia semplificata porta vantaggi nell’uso da parte di uten@ meno esper@ e al primo impa/o con il sito, evitando “traumi” che potrebbero portare all’allontanamento dal sito. Raggruppare i servizi in microzone evita il sovraffollamento di icone, semplificando così il processo di ricerca su mappa.

Conclusioni

36

Possibili sviluppi

Il concept su cui si basa il proge/o può benissimo venire traslato per un prodo/o des@nato al mercato mercato delle applicazioni, sopra/u/o per tu/o quanto riguarda il se/ore mobile. Coinvolgendo aziende locali e uten@ il database di informazioni può essere ampliato. Il modello a tavola può essere riu@lizzato per altre zone della ci/à o per una ci/à intera.

Il Team

37

Gregorio Marchi (744780) Dopo il diploma scien@fico, ha scelto di frequentare il corso in Psicologia Cogni@va Applicata presso la facoltà di Scienze Cogni@ve dell’Università degli Studi di Trento. Nerd fa/o e finito, cerca di capire come funzionano le cose, spesso rompendole nel processo. Responsabilità principale: developer del proge/o.

Giulia Marzagalli (743732) Studia semio@ca, ma preferisce occuparsi di ricerca etnografica sui consumi e gli s@li di vita emergen@. Colleziona designer toy e si nutre di serie tv. Responsabilità principale: content creator del proge/o.

Salvatore Sisca (742449) Geek curioso, si interessa pra@camente di qualsiasi cosa col risultato però di sapere troppo poco di tu/o. Ma ci prova lo stesso. Responsabilità principale: graphic designer del proge/o.

Relazione del progetto "in Bicocca"

Design

Transcript of Relazione del progetto "in Bicocca"