È da circa un anno e mezzo che e-xtrategy mi ha messo di fronte a progetti impostati secondo metodologie agili. Per tutto questo tempo ho cercato di ricostruire i motivi per cui mi si chiedeva di lavorare così. Ho visto i vantaggi e mi sono scontrata con diversi problemi. Al CSMA sono finalmente partita da zero: teoria, metodi, scrittura delle storie, planning e planning game, iteration e release planning, suddivisione in task… E finalmente ho potuto riempire il vuoto “culturale” che avevo. Siamo partiti da un finto progetto, sulla base della traccia suggerita da Stefano Ottaviani: un sito di e-commerce per la vendita di ebook online, che per motivi di tempo abbiamo ridotto a una semplicissima applicazione collegata con Twitter. Atomizzando il finto progetto deciso al CSMA, ho potuto fare le mie domande e tirare le fila.

Prima lezione: una nuova visione sulle user stories.

Da quando cerco di lavorare con questo metodo, la scrittura delle user stories mi è sembrata la prima grande novità metodologica. Mi sono sembrate molto utili per definire un progetto nel dettaglio, discuterlo e condividerlo, oltre che metterlo in ordine di priorità. Tutto questo mi ha messo di fronte all’evidenza di dover definire meglio il mio ruolo come designer delle interfacce e all’esigenza di trovare un terreno di dialogo comune con gli sviluppatori.
Da quando scriviamo un progetto con le user stories, mi sono sentita come se fossimo un gruppo di persone dentro un appartamento vuoto da riempire. Ogni storia era come un mobile che ognuno portava e lasciava lì dentro, in ordine sparso. A me veniva richiesto di mettere in ordine le stanze e trovare un posto per ogni cosa, oltre che trovare i mobili mancanti. In questa situazione, avevo difficoltà a inquadrare il progetto nel suo insieme, mi occorreva tempo per fare ordine e quindi anche per discutere i punti critici. Questo creava problemi perché è importante che tutto il team abbia chiaro il progetto nel più breve tempo possibile. Al CSMA credo di aver trovato la chiave giusta: posso inserirmi nella scrittura delle storie facendo ordine fin dall’inizio. Ho capito che gli sviluppatori hanno bisogno di spezzettare un progetto in piccole parti, mentre noi designer abbiamo bisogno della visione d’insieme. Il metodo che potrei usare è proprio quello di guidare il processo di scrittura individuando gli scenari (e sottoscenari) in cui l’utente si trova (o, forse, dovrei dire “che proponiamo all’utente”). Tra l’altro, ho scoperto che questi scenari corrispondono all’incirca a un tipo di user story che in gergo viene chiamata “epic” (storie molto grandi che quindi andranno spezzettate).
Curioso perché credo che davvero che sia un uovo di Colombo. Non vedo l’ora di mettere in pratica questo sistema.

Due interventi su tutti.

Se avessi scritto questo post subito dopo la conferenza, probabilmente mi sarei sforzata di tirare fuori gli aspetti interessanti e positivi di questa applicazione (o dovrei dire “piattaforma”). Ma ho preferito lasciar passare qualche giorno per assorbire l’entusiasmo e rifarmi un’idea meno condizionata.

Contestualmente all’evento e agli aspetti generali di Foursquare, segnalo due interventi su tutti: quello di Gianluca Diegoli e quello di Stefano Mizzella. In poche parole: i contro e i pro. È su quello che ho letto in queste slide che vedo i difetti e le opportunità di FourSquare. Non saprei aggiungere altro, ve ne consiglio la lettura.

Cosa ne penso io.

Uso Foursquare da qualche settimana. Dopo la prima sensazione di divertimento e novità, ci sono due cose in particolare che hanno iniziato a non piacermi:

• il check-in è fastidioso come un dito in un occhio. E ovviamente non è una cosa da poco. Il check-in è la conditio-sine-qua-non… ed è una condizione che mi sta antipatica. Trovo che vada bene per chi abbia voglia di giocare e questo non è il genere di giochi che mi piacciono. Nel mio caso, ho notato che fare il check-in mi aliena dalla compagnia con cui sto, provocando (una giusta) irritazione negli altri e un senso di idiozia da parte mia. Sono d’accordo con Michele che conoscere i posti frequentati dal mio network contribuisce a consolidare la fiducia che ho nelle persone, ma questo per me vale quando si parla di lavoro. Nella vita privata, ho molti altri servizi che posso usare in alternativa, meno invadenti di questo.
• vorrei che il servizio venisse da me. Dato che non ho voglia di giocherellare al check-in, vorrei che il servizio funzionasse in qualche modo anche senza dover premere il dannato bottone. Quando il satellite mi trova, posso comunque ricevere informazioni geolocalizzate… ma di certo per questo ci sono già innumerevoli applicazioni. E ci sarebbe un altro tipo di problema di privacy, immagino. Probabilmente questo è un limite per me, che passo molte ore davanti al Mac o allo smartphone per lavoro… e quindi non ho certo voglia di rimettermici anche quando vado a mangiarmi una pizza con gli amici.

Questi sono i miei due cents ed è per questo che forse Foursquare non fa per me. Per ora continuerò a usarlo in situazioni lavorative, ma credo proprio che rinuncerò a tutti gli altri aspetti che riguardano la vita privata.

Ho ascoltato le sessioni mattutine, mentre quelle pomeridiane si sono rivelate troppo tecniche, per me. Così ne ho approfittato per scrivere questo post.

Mi è sembrato che il seminario fosse rivolto perlopiù agli sviluppatori ma, anche questa volta, ho notato che le questioni di usabilità, interfaccia utente, architettura dell’informazione, feedback e test sono considerate parte dello sviluppo, al pari del resto del lavoro.

Devo confessare che non conoscevo diversi termini usati durante le presentazioni (al di là degli interventi tecnici)… a partire proprio dal titolo del workshop: da oggi, spero di ricordarmi i termini SOA e deploy. Magari non il loro significato preciso (roba da ingegneri…) ma almeno la loro esistenza.

Vorrei dare un consiglio a tutto il gruppo DotNetMarche e anche ai relatori: per favore, condividete le vostre slide (magari su SlideShare)! Durante il workshop ho dato per scontato che le avrei trovate online e ora non solo non trovo i titoli, ma non posso neanche inserirle in questo post. O forse sono io che non vi trovo.. quindi rendetevi più “trovabili”.

Le sessioni introduttive di Ricci e Servienti.

La prima sessione della giornata è stata di Gian Maria Ricci, che ha spiegato i motivi per cui il metodo waterfall non è più adatto a risolvere i problemi di sviluppo e ha introdotto il concetto di agile, spiegando motivi e metodi.

Mauro Servienti ha proseguito inquadrando alcune delle questioni centrali relative all’impostazione di una nuova applicazione, basandosi su problemi riscontrabili nel mondo reale: trovare il giusto interlocutore, fare le giuste domande, ricordarsi in tutte le fasi dello sviluppo che il focus è sull’utente, il dialogo all’interno del gruppo di lavoro e con il cliente (evitando i tecnicismi). Anche nel suo intervento, ho notato che il metodo agile viene dato per scontato, al punto che è ovvio che il gruppo di lavoro scriva, discuta e condivida le storie. Infine, anche per Mauro, le storie dovrebbero essere indipendenti tra loro e comportarsi quasi come se fossero microapplicazioni, perfettamente funzionanti al momento del rilascio.

Prototipi con Sketchflow di Scardova.

Alessandro Scardova ha presentato una sessione molto pratica. Inizialmente, ha spiegato l’importanza dei prototipi e la necessità di avere un feedback dagli utenti. Poi ha mostrato come usare Expression SketchFlow per avere degli “schizzi” interattivi online, utilizzabili dagli utenti che possono anche lasciare un commento. In questo modo, il gruppo di lavoro avrebbe un prototipo funzionante e pieno di appunti lasciati dagli utenti.

Il suo intervento è quello che mi ha aperto più domande, ma purtroppo non c’è stato il tempo di fargliele in diretta. Gli segnalerò questo post, sperando che abbia voglia e tempo per venire a rispondere qui.

Alla ricerca della parola giusta (cioè dello strumento e del metodo giusti).

In diversi (ormai tantini) anni di lavoro, ho sentito molte parole legate al concetto di schizzo / prototipo, ma ogni settore (dalla carta al web) sembra usarle senza una vera soluzione di continuità: perciò posso dire bozza, draft, menabò (o menabau), timone, mockup, wireframe… ogni volta avendo il sospetto che dev’esserci un modo “definitivo” di usare questi termini.

A naso, mi viene da dire che bozza e draft sono la stessa cosa. Una bozza mostra una proposta grafica che verrà usata come guida durante lo sviluppo. In un’ottica di sviluppo agile, la bozza potrà avere diversi dettagli variabili e dovrà mostrare il look&feel del sito. Fino a qualche tempo fa, la grafica mostrava tutte le funzionalità del progetto. Negli ultimi anni, però, i progetti sono diventati sempre più complessi e abbiamo visto che questo non è più possibile. Perciò in grafica si prevedono diversi ingombri che verranno approfonditi meglio in fase di sviluppo (o forse di prototipo, il giorno che capirò meglio come farne uno).

Il prototipo è una specie di schizzo (sketch.. altra parola da aggiungere all’elenco) interattivo che verrà usato come strumento per discutere con l’utente delle funzionalità e delle criticità legate al progetto. Individua le principali questioni d’uso e funzionalità, ma non le approfondisce. Anche qui, gli approfondimenti verranno fatti in fase di sviluppo.
Alessandro, all’inizio delle sue slide, ha detto anche che il prototipo è utile in fase di quotazione, perché mostra a grandi linee il funzionamento e le criticità del progetto.

Forse è solo una questione di parole, ma non ne sono molto sicura… Certo è che mi piacerebbe usare le parole giuste per le cose che faccio.

Le mie domande.

• dove collochiamo il wireframe? Per me ora il wireframe è utilissimo per decidere i pesi grafici e i principali contenuti del progetto. Spesso ci è servito per scrivere le storie, altre volte sono partita dalle storie e ogni elemento del wireframe ne soddisfa una. Mi piacerebbe creare un wireframe interattivo… Ma dovrei forse separare le due cose? cioè usare il wireframe più per un discorso grafico e il prototipo per un discorso di funzioni e usabilità?
• se il wireframe, il prototipo e la grafica non mostrano mai un prodotto definito, quand’è che lo vede il cliente? In teoria, durante i rilasci frequenti che verranno poi corretti in base ai feedback… Eppure, si è detto più volte che questo sarebbe un rischio per gli sviluppatori.
• il prototipo mostra necessariamente dei bottoni e dei contenuti impaginati, anche se a livello molto grezzo. Quanto cambiano queste impaginazioni dal prototipo alla grafica? se l’utente si è abituato a trovare nel prototipo un menù a sinistra e una scheda organizzata in un certo modo, quanto posso allontanarmi da questa impaginazione al momento di studiare la grafica?
• e infatti, quand’è che è giusto studiare la grafica? prima, durante o dopo il prototipo?
• il prototipo serve per la quotazione e questo è un sogno per gli sviluppatori. Loro possono quantificare un progetto su una base piuttosto chiara, ma se poi il progetto non passa? chi ci rimette è quello che ha investito il tempo a creare il prototipo e testarlo… Come si fa in questi casi? Finché il “prototipista” lavora in azienda, è comunque l’azienda che perde l’investimento; ma se il prototipista è un freelance (ehm… tipo me) alla fine è solo lui (o lei ) che ci rimette… Forse andrebbe fatto sempre un accordo a monte tra prototipista e sviluppatori, per dividere onori e oneri?

Concludendo.

Una delle questioni che vorrei tentare di risolvere rimane sempre il ruolo della grafica, intesa anche come comunicazione. Continuo ad avere l’impressione che certi metodi funzionino su progetti molto tecnici o destinati a un uso riservato. Ma per quelle interfacce in cui la comunicazione gioca un ruolo fondamentale, mi sembra improbabile che il cliente (e in fondo anche l’utente quando testa) capisca un box grigio al centro della grafica e un prototipo in Comic Sans. Il proposito di creare un progetto davvero utile per l’utente è ineccepibile, ma spesso i progetti non sono fatti solo di funzionalità. È su questo confine labile tra uso e comunicazione che sto cercando l’equilibrio giusto per inserirmi nel flusso delle iterazioni, senza perdere di vista l’aspetto comunicativo ed emozionale che un’applicazione potrebbe contenere.

17 luglio 2010.

Prima conferenza dei sindaci di Foursquare
L’hanno organizzata i Mimuli Roberto e Francesca, insieme a Tommaso e Lisa. Me ne ha parlato Adriano e ci ho messo poco a capire che avrei dovuto esserci anch’io. Nel suo post, Adriano dice tutto: non è tanto il network in sé che interessa quanto il fenomeno della geolocalizzazione e lo spostamento dell’uso di internet dai media tradizionali ai nuovi dispositivi. Che forse è quello che potremmo chiamare anche “internet delle cose”. Vediamo che argomenti salteranno fuori.

2-3-4 settembre.

Campo Scuola sulle Metodologie Agili
Grazie al gruppo XPug Marche, che ho conosciuto su invito di Lorenzo, a settembre saremo a Fabriano per una full immersion agile di due giorni e mezzo. Saremo in 12 e cercheremo di affrontare un progetto dall’inizio alla fine, seguendo i metodi che ci suggerirà Jacopo Romei, il nostro “agile coach”. Non vedo l’ora di partecipare. Da quando e-xtrategy ha introdotto questo metodo di lavoro, ci sono molti punti interrogativi riguardo alle questioni di ux, interfaccia e grafica, quindi voglio cogliere l’occasione per  provare a svoltare. Credo che la chiave stia nel cambiamento di approccio ai progetti e all’organizzazione delle scadenze. Ma, anche qui, vedremo.
Intanto sono contenta di aver progettato il logo del Gruppo.

Prima metà di novembre.

UX Camp Firenze
Ho perso l’edizione 2009 e non vorrei mancare anche quest’anno. Il programma e l’evento sono ancora tutti da definire, ma su Twitter se ne sta già parlando. Io e Ale faremo di tutto per esserci.

Aspettando lo stop…

Con la pausa d’agosto davanti e il clima di ferie che si inizia a respirare, sto cercando la calma e la lucidità per fare un’analisi delle cose fatte da marzo a oggi, tra lavori ed eventi che ho seguito. Intanto, voglio cogliere l’occasione per ringraziare gli organizzatori dell’IA Summit e dell’Experience Camp di Lugano, per la qualità degli interventi e l’apertura al confronto. Devo ringraziare anche la “Mimula” Francesca, per questa intervista.

E grazie anche al solito Alfredo, che mi ha dato l’opportunità di disegnare la launcher icon per la sua applicazione androidiana “SMS for free”.

Una piccola nota personale.

Per luglio e agosto ho messo in programma la visita a due splendide mostre fotografiche (che consiglio a tutti), quelle di Steve McCurry e Francesca Tilio. E naturalmente tanto mare.

Lo semplifichiamo?

Ero arrivata convinta di aver fatto tutto il possibile per asciugare l’interfaccia e le informazioni, finché Massimo non mi ha buttato lì questa frase: Mi piacerebbe che i grafici si chiedessero anche “Lo semplifichiamo?” e non solo “Lo complichiamo?”. Gli ho risposto che non avrei saputo come farlo più asciutto di così: avevo ridotto le funzioni al minimo, tolto tutto il superfluo (forse pure troppo, mi ha fatto notare mia sorella…), cosa potevo togliere ancora? A rispondermi, è arrivato Cristiano. Le funzionalità proposte nella tabBar potevano essere ridotte a due: calendario e settings. Chissà, forse Andrea Picchi, che ha parlato anche di “credenze”, direbbe che la mia convinzione di aver fatto tutto il possibile era appunto una credenza E infatti è vero: le tre funzioni “calendario passato”, “calendario futuro” e “aggiungi una data”, possono essere indubbiamente raccolte in un’unica funzione “calendario”, che è un pattern acquisito su smartphone. Nelle date future vedrò le ipotesi, in quelle passate le date certe… e ovviamente posso aggiungere una data dove mi pare. Più semplice di così!

Un errore semantico.

Sempre Cristiano mi ha fatto notare un errore semantico nella scelta di un componente: lo slider “Yes/No” nella pagina in cui posso aggiungere una data di inizio ciclo o una nota non è un componente adatto alla funzione che dovrebbe svolgere in quella pagina. Quel tipo di slider, mi ha riassunto in due parole mio cognato, significa “Acceso/Spento” e in effetti, la libreria prevede che venga usato come On/Off. Io pensavo di poter cambiare questa funzione (infatti On/Off è diventato Yes/No), ma ora ho capito che ogni oggetto ha il suo significato semantico, per questo va usato nella giusta accezione. Un ciclo mestruale non è acceso o spento: ce l’hai o non ce l’hai. Ecco perché il componente da usare in quella pagina è il classico checkbox.
Rientrando a Chiavari, ho scambiato qualche impressione con Edoardo e mi affatto vedere che, sul suo HTC Android, il componente slider di iPhone non esiste: quella funzione viene svolta dal checkbox. La prossima volta, dovrò tenere conto di queste differenze componentistiche (e dei loro significati semantici) tra i vari OS.

Un errore di comunicazione (di uxd)?

In questo tweet, Emanuele ha criticato l’alert che compare se l’utente inserisce user o password sbagliati. Per ora ho scritto: wrong username and password (bottoni “retry” e “cancel”). Secondo Emanuele, questi tipi di alert che segnalano errori da parte dell’utente sono violenti come uno schiaffo. È vero, ma è anche vero che sono molto chiari. Su iPhone ne vedo molti, ma sappiamo che una pratica diffusa non è sinonimo di buona progettazione. Per Emanuele ci sono molte applicazioni che usano disattivare il tasto submit in caso di errata compilazione e mi suggerisce di proporre questo tipo di soluzione. A me però non convince: un tasto disattivato non è un feedback, secondo me è solo un’opzione non disponibile che non sembra verificare alcun dato. Però potrei proporre di ricaricare la pagina segnalando l’errore nella schermata e non su layer con alert.
Una risposta più sicura potrei averla solo verificandolo con le utenti.

Funzioni che dovrei aggiungere.

Mia sorella mi ha fatto notare che manca la segnalazione del periodo di ovulazione, che molte utenti usano abitualmente. Mi ha suggerito di aggiungere nei settings l’opzione di attivarla o disattivarla. Cosa che ovviamente prevederò nella versione 1.1.

Miglioramenti visivi = miglioramenti usabili.

Alla fine della giornata, Cristiano mi ha indicato altri possibili miglioramenti all’interfaccia: nel calendario, più evidenza all’icona bianca checked (relativa alla data di inizio ciclo) e meno evidenza all’icona checked verde (relativa a una nota)… Mi ha anche suggerito qualche ritocco ai colori, per dare più o meno visibilità ai bottoni; e un’ottimizzazione dello spazio nella schermata d’inizio rivalutando l’uso delle label nei bottoni (questa osservazione l’ho ricevuta anche da Paolo alla fine del mio intervento). Il risparmio di spazio riservato ai bottoni mi tornerà utile per dare rilievo alle notifiche e all’eventuale riga in più relativa all’ovulazione, che ha chiesto mia sorella.

Risposte?

Luca Mascaro mi ha dato qualche risposta al terzo dubbio: per iPhone si progetta a 96 dpi (ma sul sito Apple si parla di 163), sugli altri device a 72, mentre per iPad si va a 132. Eravamo un po’ di fretta e quindi non sono riuscita a chiedere altri chiarimenti, ma intanto proverò ancora a capire perché queste risposte non mi quadrano mai.
Luca mi ha anche lanciato uno spunto riguardo ai problemi di rendering dei vari formati: png e jpg presentano delle peculiarità di resa visuale di cui dobbiamo tenere conto. Non mi riferisco all’interpretazione della trasparenza che alcuni browser non supportano: dando per scontato che tutti i device supportino i file png, c’è proprio un problema di rendering, passando da un supporto a un altro.
Mi resta anche il dubbio sulla profondità in bit… Continuerò a cercare risposte esaustive a riguardo.

Una volta di più: l’importanza del lavoro di gruppo.

Per Monthly.Info versione mobile ho fatto tutto da sola, cosa che nel lavoro quotidiano (per fortuna) non accade mai. Il dibattito che è venuto fuori alla fine è la tipica discussione che affronto al lavoro quando mi confronto con il team: ognuno porta la sua competenza, ci correggiamo a vicenda, spieghiamo le nostre intenzioni e le nostre esigenze… e alla fine il progetto si modifica sempre in meglio. È quello che è successo alla fine del mio intervento: in pochi minuti, ho imparato cose nuove e ricevuto spunti di riflessione davvero molto molto utili.

Non finisce qui.

Andrò avanti con l’esercizio che ho cominciato su Monthly.Info: la mia intenzione è quella di migliorare l’interfaccia dell’applicazione e integrare le slide con tutti i consigli e le risposte ricevute. Non so quando né dove, ma spero di aver modo di ripresentare questa prossima versione 1.1.

(Le altre.)

Alla fine del mio intervento, avevo accennato al fatto che non avevo guardato com’erano fatte le applicazioni simili a questa attualmente disponibili nell’App Store. Eccone alcune:

• http://www.imensies.com/index.php?page=about_logging
• http://www.winkpass.com/iperiod.html
• http://www.periodplus.com/
• http://www.fertilityfriend.com/iphone/calendar.php
• http://triplecreeks.com/womancalendariphone.aspx
• http://femcal.jonathanwatmough.com/
• http://delworks.com/monthly-cycles/overview

Mi sono fatta un’opinione e.. sono contenta di continuare questo esercizio. Chissà, magari riuscirò a trovare un volontario che abbia voglia di svilupparla.

Il metodo… e perdere il controllo.

Nel tempo rimasto, con mia grande sorpresa, è saltato fuori un bel dibattito, da cui ho raccolto molti suggerimenti… ci tornerò su al prossimo post.
Alla fine, una persona del pubblico ha obiettato che a suo parere, nel lavoro del designer, manca il metodo… per lui, tutto risulta essere molto emotivo, poco misurabile. La mia risposta è stata che tutta la mia presentazione voleva essere una spiegazione utile a far capire il metodo di lavoro e la motivazione delle scelte che facciamo. Alla mia risposta è seguita quella di Cristiano, davvero eccellente: l’utente non lo controlli, al massimo puoi controllare i processi. Per quanto ci si sforzi di proporre una buona interfaccia, l’utente può sempre spiazzarti, perché potrà avere comportamenti inaspettati… è inutile chiedere al designer di dare risposte certe e misurabili al 100%, perché di là ci sono persone, individui. Non simulazioni. Il nostro compito è quello di tentare, studiare per proporre la soluzione che possa essere il miglior compromesso possibile. Cristiano aveva già espresso questo concetto all’Italian Agile Day 2009, ma dopo il mio intervento e i consigli ricevuti (che sono quasi diventati una specie di primo test), le sue affermazioni hanno acquistato ulteriore spessore. Almeno per me.

Grazie al Whymca.

Ringrazio ancora una volta chi mi è venuto a sentire, chi ha commentato, chi mi ha dato suggerimenti e anche criticato… E ringrazio di cuore gli organizzatori del Whymca, con un pensiero particolare ad Alfredo (mr. In Gambissima, ed è proprio vero!). Per me, è stata la prima vera occasione di mettermi in gioco e parlare davanti a un bel gruppo di professionisti. Mi spiace di non essere riuscita a seguire gli altri interventi e a dare spazio a qualcuno che aveva ancora qualche domanda. Se leggerete questo post, fatevi avanti: vi risponderò da qui.

Tra qualche giorno pubblicherò l’elenco di consigli e risposte ricevute: la mia base di lavoro per passare a Mobile Monthly.Info versione 1.1.

L’icona mi invita a leggere le istruzioni per l’uso a pagina… 348! O_o
Leggo tutto ed è molto ben spiegato. Non ho alcuna difficoltà a installare l’applicazione per smartphone o a capire come dovrò estrapolare gli articoli “aumentati”. E quindi inizio proprio dall’editoriale: avvio i-Nigma (applicazione gratuita) inquadro l’icona in fondo all’articolo e l’applicazione mi apre automaticamente il browser alla versione online dell’articolo (presumo sia il blog del Direttore). Così posso leggere i commenti e aggiungere il mio.

Alcuni articoli non rimandano a un blog ma a un contenuto video, per esempio un’intervista utile ad approfondire il tema trattato.

La realtà aumentata è presente perlopiù nelle pubblicità: andando sul sito indicato dai vari inserzionisti e inquadrando il target con la webcam, compaiono contenuti aumentati, come video o giochini interattivi.

Le mie prime impressioni sono buone per quanto riguarda il quick response (QR), cioè i contenuti extra disponibili via smartphones (quelli che riconosco usando appunto i-Nigma con il mio iPhone). Possono essere utili approfondimenti o possono farmi interagire con un articolo, cosa finora impossibile su carta.

Rimango invece del tutto delusa (una volta di più) dalla realtà aumentata: usata così, a mio parere, non serve assolutamente a nulla. Chi può voler spendere il suo tempo per vedere una pubblicità in più? Che cosa mi offre di preciso? Niente se non altra pubblicità. Credo che ci siano già da ora spazi molto più utili per la AR… è giusto tentare, anche con le pubblicità, ma non è qui (di certo non con questo tipo di pubblicità) che la AR troverà sbocchi davvero utili.

La domanda più importante è: chi utilizzerà questi contenuti extra? Da un lato, trovo sicuramente interessante e opportuno fare tentativi in questa direzione; ma al di là dell’aspetto divertente e tecnologico, la mia perplessità sta nel fatto che a oggi la lettura/scrittura su smartphone rimane piuttosto ostica. Forse saranno proprio dispositivi come iPad e Tablet a sdoganare definitivamente i limiti della carta stampata. Tornando all’osservazione iniziale (come mai queste novità tecnologiche non siano state segnalate con maggiore rilievo), mi viene da pensare che questi approcci con smartphone e webcam non siano altro che una palestra, in modo da arrivare molto preparati non appena i vari tablet saranno maggiormente diffusi. Oggi, il giro che devo fare per accedere a un contenuto extra mi spinge a dire che questo contenuto dovrà essere davvero molto, ma molto interessante al punto che “sopporto” di leggerlo su uno schermo piccolo. Ma attenzione, può bastare un solo extra deludente per tradire sul nascere le aspettative del lettore e perderlo da sempre, fin da subito.

Ad ogni modo, si conferma ancora un volta la tendenza e la necessità di aprire i contenuti alla conversazione, soprattutto quelli di tipo informativo e giornalistico. La tecnologia QR utilizzata da Panorama mi sembra, in questo senso, sicuramente apprezzabile e (oserei dire) pioniera, almeno per quanto riguarda il giornalismo mainstream.

In questo caso volevo segnalare un buon servizio fornito dall’azienda: Viaggia Treno. Si tratta di un’applicazione online che tiene traccia dei treni in tempo reale. Dal computer, l’interfaccia è chiara: c’è una mappa che permette di effettuare uno zoom sulla zona interessata (a sinistra) e abbiamo un pannellino di ricerca da cui posso cercare il mio treno per numero, stazione o dati di viaggio (a destra). Il sito fornisce davvero le risposte sui treni ed è curioso doverlo specificare: spesso si fa tanta fatica per costruire un mostro di sistema e poi alla fine c’è qualcosa che non lo fa mai funzionare a dovere. Qui, a prima vista, tutto sembra essere a posto….

E quindi, cosa c’è che non va?

(grazie a Nick Fink per queste ottime slide che spiegano il concetto di “Design Contestuale”)

Flash.

Tutto questo sistema è stato costruito in flash. Ora: ultimamente, anche sparare a zero su Flash sembra diventato un po’ troppo facile, quindi invito a leggere questo post di Antonio D’Alessio, che condivido.

In questo caso, però, la scelta di Flash mi sembra un errore clamoroso.

Dicevo che, a prima vista, tutto sembra funzionare… e questo mi ricorda l’ultimo libro che ho letto di Norman “Il design del futuro”. A un certo punto Norman cita un episodio in cui il suo collega Nielsen descrive la sua esperienza d’uso con una macchina per fare biglietti dell’autobus. Nielsen si trovava in Svezia, verso maggio. La macchina aveva funzionato bene e l’unica domanda che si era fatto era stata: “Chissà perché i bottoni sono così sproporzionatamente grandi rispetto alle vere dimensioni delle dita?”… Poi Nielsen tornò in Svezia d’inverno e riutilizzò la stessa macchinetta, con indosso un paio di guanti: ed ecco svelato il mistero.

Cosa mi ha ricordato questo piccolo episodio?
Che nel progettare un’interfaccia, lo studio del contesto di utilizzo è fondamentale. Senza quello, l’interfaccia (e quindi tutto il sistema, magari funzionante) può risultare inutilizzabile.

Viaggia Treno per me oggi funziona al 50% perché uno dei più naturali contesti di utilizzo di un servizio come questo è proprio durante un viaggio. Se ho una coincidenza a Bologna e sono già sul treno, posso collegarmi con il mio smartphone e interrogare il sistema per sapere se tutto è in orario… Ma se il tutto viene realizzato in Flash, da telefonino diventa inaccessibile o di difficile lettura. Flash è disponibile solo sugli iPhone e gli Android più nuovi (anche se da parte di Apple bisogna vedere come e per quanto, visto le recenti diatribe tra l’azienda di Jobs e Adobe). Il risultato è che potrei disporre di un’informazione davvero utile, ma il modo in cui il sistema è costruito, quando non mi impedisce arrivarci, mi rende tutto molto lento e macchinoso.

Consiglio a Trenitalia di fare un ultimo sforzo e pensare a una versione mobile, molto più light. Hanno costruito un ottimo servizio, ora si tratta solo di renderlo accessibile a tutti e soprattutto a chi potrebbe usarlo di più.

Due note a margine.

• il sito è del 2006, quindi mi auguro che Trenitalia stia lavorando alla nuova versione. Questo può spiegare un po’ perché sia stato realizzato in Flash, anche se già nel 2006 si poteva intuire che avrebbe potuto essere una scelta inopportuna.
• i contenuti sono protetti da copyright… O almeno da copyright per l’anno 2006. Mi è venuta spontanea questa domanda: che senso ha mettere il copyright in un sito del genere, quando qui le informazioni dovrebbero essere di pubblico dominio / utilità? Se un treno è in ritardo e lo scopro grazie a questo servizio, significa che non posso avvisare nessuno perché Trenitalia è proprietaria di questo contenuto? Una distribuzione copyleft sarebbe di gran lunga auspicabile e opportuna, per non dire obbligatoria. Almeno per un servizio come questo.

Post Scriptum.

Ho scritto questo post qualche giorno fa e l’ho tenuto saggiamente in bozza. Proprio ieri ero in viaggio verso Milano con Michele. Guarda caso, il nostro treno era “insolitamente” in ritardo e così gli ho raccontato di questo post. Con mia grande sorpresa, mi ha risposto che la versione mobile del sito viaggiatreno.it esiste e me l’ha mostrato in diretta. Il servizio funzionava e ci ha risposto correttamente in merito al ritardo del nostro treno… Peccato che ci siano questi due problemi:

• se provo a caricare viaggiatreno.it, succede esattamente quello che ho mostrato e sulla pagina non c’è nessun richiamo (manuale o automatico) a una versione mobile molto semplificata del servizio;
• se carico la pagina mobile.trenitalia.com, scopro che esiste una versione molto ridotta del sito Trenitalia, in cui una delle pochissime opzioni disponibili è proprio quella di cercare l’”Andamento dei treni”. Basta conoscere il numero del treno e il sistema risponde correttamente (è appunto quello che ha fatto Michele dal suo Android). Ma anche qui, digitando trenitalia.com da telefonino, non esiste alcun redirect alla versione mobile del sito. Si dà per scontato che i viaggiatori conoscano la url.

In bocca al lupo a Trenitalia, ne ha decisamente bisogno.
Ma soprattutto, ne abbiamo bisogno noi quando prendiamo un treno.

Salone del Mobile 2010 – Fuorisalone (dal 14 al 19 aprile 2010).

Non credo di esagerare se affermo che si tratta del più importante appuntamento internazionale (leggi: mondiale) nel settore del design e dell’arredo.
Quest’anno andrò un giorno intero al Fuorisalone. Sabato mattina parcheggerò in zona Famagosta e punterò dritto su Zona Tortona. Poi in via Durini, in Zona Brera e a zonzo, improvvisando. Salterò impunemente il Salone, per due motivi: il costo (35 euro, se non è aumentato); e per le idee: mentre il Salone è più orientato alle vendite, il Fuorisalone è una fucina di idee che guardano al futuro e che colpiscono da mille punti di vista: dal respiro cosmopolita e giovane alle invenzioni design e di marketing, dalle presentazioni alle installazioni, dalle location agli eventi… insomma, per me il Fuorisalone è un momento davvero emozionante e stimolante.

IA Summit 2010 (7-8 maggio 2010).

È la quarta edizione e durante questo evento ho sempre racconto diversi spunti. Partiremo con Ale e posso dire “come sempre”, perché siamo andati insieme a Roma, a Trento e a Forlì… Ultimamente abbiamo notato che avremmo preferito più spazio per casi di studio pratici. È vero che il nostro punto di vista è viziato dalla nostra professione, ma a volte ci siamo trovati persi di fronte a interventi molto accademici e quasi filosofici, rispetto a casi di studio più reali e orientati alle nuove tecnologie. Nell’insieme, si parla di interventi sempre di altissimo livello, con luminari provenienti da ogni parte del mondo… e quindi, anche se a volte qualche speech può risultarci un po’ nebbioso, altri interventi rimangono davvero preziosi.

Whymca 2010 (21 maggio 2010).

Ci sarei andata comunque, perché ho capito che questo settore è in forte espansione e presto conoscerà un vero boom… ed è complementare al web, in diversi modi – almeno per quello che riguarda la mia professione. Mi sono affacciata al settore mobile quasi per caso e ora sto con le orecchie tesissime… Alfredo (credo di non sbagliare se dico che è l’uomo che ha ideato l’evento) mi ha chiesto di proporre uno speech e così ho fatto. Avrò 45 minuti: Aula D ore 15.55. Lo spunto da cui voglio partire è volutamente ironico: con il consenso dell’autrice del sito Monthly.info, vorrei mostrare in modo molto pratico che ragionamenti faccio e che processi grafici seguo per trasformare il sito in applicazione mobile. E in più vorrei aggiungere qualche nota a margine su usabilità, standard e idee varie… Mi diverte il fatto di presentare un tema così smaccatamente femminile a un evento per sviluppatori, settore quasi prevalentemente maschile. Della serie: tiro fuori l’orgoglio femminile, come mi ha insegnato Ani Di Franco! Mia sorella urlerebbe con me: “Girl Power”!
Scherzi a parte, è la prima volta che parlo a un evento… è presto per farmi prendere dall’ansia, ma ce la metterò tutta (sia per farmi prendere dall’ansia che per fare un buon talk).

Experience Camp 2010 (29 maggio 2010).

Ho la fortuna di avere un pezzo di famiglia vicino a Chiasso e l’Experience Camp si svolge proprio a 30 km da lì. Il programma è ancora in fase di definizione, ma intanto mi sono registrata e ho il mio biglietto. Aspetto di vedere l’elenco degli interventi./p>

Cosa manca?

Better Software (5-6 maggio 2010).

Ho rinunciato a Better Software, per tre motivi: per il prezzo, per il fatto che capita durante la settimana e perché è attaccato all’IA Summit, che non ho mai mancato. Il prezzo: lo capisco e non lo critico assolutamente. Ma visto che ci sono altri eventi altrettanto interessanti, con i soldi che risparmio su Better Software posso partecipare più tranquillamente agli altri eventi. E poi sì, durante la settimana è davvero difficile sganciarsi per due/tre giorni, soprattutto in questa fase di startup in cui mi trovo. Ecco perché opto per l’IA Summit, evento che mi è forse più vicino e cade di venerdì e sabato. Mi terrò Better Sotware per l’anno prossimo, magari rinunciando a qualcos’altro… perché a guardare il programma, ci sarebbero davvero tante tante cose da seguire.

A parte Better Software, che perdo a malincuore, se ci sarà qualcuno ci vedremo lì, lì, lì e lì.

Come (immagino) per molti di voi, anche se questo campo ha molti punti in comune con il web, per me è tutto molto nuovo. Così, mentre nel progettare interfacce per il web mi muovo con una certa dimestichezza, sul mobile ho molti interrogativi e dubbi di base. Alcuni li ho affrontati nel progetto Dolcevita, attualmente in fase di sviluppo… e ora aspetto la prossima occasione per ributtarmi.
Ma intanto, vorrei approfittare del Whymca per cercare un confronto tra grafici. Qando sento parlare gli sviluppatori, sembra che mastichino queste materie da anni, mentre i grafici mi sembrano molto titubanti (e io stessa lo sono). Ecco perché mi sono venuti in mente questi possibili argomenti:

• differenza tra sito web, versione mobile e applicazione mobile
• step di base per progettare la grafica di un’interfaccia mobile
• ux design nel settore mobile: inquadrare il contesto.

Magari nessuno di questi argomenti vi sembra interessante, magari ve ne verranno in mente altri… o magari qualcuno di questi vi sembra particolarmente utile. Ho tempo fino al 31 marzo per presentare il titolo del mio speech, sperando che venga accettato… e quindi eccomi qui, vi invito ad aiutarmi a individuare il tema più adatto, io cercherò di ragionandorci sul mio blog e sugli spazi che Laura mi ha aperto. Vi aspetto!