Relazione del gruppo 4 sul progetto "inBicocca", prototipo di un tipo realizzato per l'utenza del quartiere omonimo per il corso in Comunicazione Visiva e Design delle Interfacce.

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

2. Il
Proge.o
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.
2

3. Cronologia
della
proge.azione
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.
3

4. Cronologia
della
proge.azione
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.
4

5. Cronologia
della
proge.azione
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...).
5

6. Cronologia
della
proge.azione
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...).
6

7. Cronologia
della
proge.azione
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.
7

8. Cronologia
della
proge.azione
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”.
8

9. Cronologia
della
proge.azione
Fase
1_Brainstorming,
le
risposte
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.
9

10. Cronologia
della
proge.azione
Fase
1_Brainstorming,
le
risposte
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.
10

11. Cronologia
della
proge.azione
Fase
1_Brainstorming,
le
risposte
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
11

12. Cronologia
della
proge.azione
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.
12

13. Cronologia
della
proge.azione
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.
13

14. Cronologia
della
proge.azione
14

15. Cronologia
della
proge.azione
15

16. Soluzione
conce.uale
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.
16

17. Cronologia
della
proge.azione
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.
17

18. Cronologia
della
proge.azione
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.
18

19. Cronologia
della
proge.azione
Fase
4_
Prime
proto8pazioni
19
Prima
prova
di
posizionamento
delle
macro-­‐aree

20. Cronologia
della
proge.azione
Fase
4_
Prime
proto8pazioni
20
Prima
prova
di
funzionamento
del
filtro

21. Cronologia
della
proge.azione
Fase
4_
Prime
proto8pazioni
21
Seconda
prova
del
filtro

22. Cronologia
della
proge.azione
Fase
4_
Prime
proto8pazioni
22
Prima
implementazione
delle
stru/ure
grafiche

23. Il
sito
finale
Schermata
del
sito
in
un
esempio
d’uso.
23

24. Il
sito
finale
Livello
2:
visuale
con
liste
chiuse
24

25. Il
sito
finale
Livello
3:
informazioni
de/agliate
di
un
servizio
25

26. Archite.ura
informa8va
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.
26

27. Sistemi
di
navigazione
e
di
interazione
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.
27

28. Aspe1
grafico-­‐comunica8vi
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.
28

29. Scelte
croma8che
e
8pografiche
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.
29

30. Usabilità
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.
30

31. Usabilità
in
mobilità
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.
31

32. Usabilità
in
mobilità
Esempi
orientamen@
e
geolocalizzazione
32

33. Cara.eris8che
tecnologiche
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@.
33

34. Conclusioni
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.
34

35. Conclusioni
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.
35

36. Conclusioni
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.
36

37. Il
Team
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.
37