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.

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!

e-xtrategy incontra xpug Marche.

Le slide dell’incontro potete trovarle qui: http://www.slideshare.net/extrategy/extrategy-incontra-xpug-marche. Ho iniziato a mettere nella mia lista dei desideri anobiiana un paio di libri e dovrò fare un bello sforzo per imparare anch’io a usare questo metodo fin dall’inizio di un nuovo progetto. Da quando e-xtrategy lavora così, uno dei punti critici è rapportarsi con professionisti esterni che non possono muoversi negli stessi modi. Se voglio migliorare la qualità del mio rapporto con loro e in generale con chi sviluppa software, è indispensabile che provi a fare anch’io questo salto. A me sembra che un approccio agile costituisca un cambiamento radicale per l’azienda e il cliente. In questi primi mesi, nel mio piccolo ho potuto toccare con mano alcuni dei molti aspetti positivi di questa metodologia (le slide di e-xtrategy sono molto esaurienti in questo senso). Per ora trovo che l’ostacolo più difficile sia quello culturale, perché la fiducia tra cliente e fornitore diventa fondamentale per portare avanti un progetto, in modo proficuo per entrambi.
Intanto, ho trovato diverse slide in cui si parla di agile design e user experience:
http://www.slideshare.net/Cennydd/getting-real-about-agile-design-arial
http://www.slideshare.net/pieterj/agile-design-the-fabrique-way
http://www.slideshare.net/alicetoth/ixdaagileforweb

Agile Day 2009.

Quella di quest’anno è la sesta edizione dell’Agile Day. Ho approfittato di una giornata di ferie per salire in macchina con Lorenzo e Giorgio e fare la mia prima presenza all’evento. Ho seguito le sessioni più teoriche, perché nelle altre i programmatori e gli sviluppatori parlavano una lingua segreta, per me

Ho ascoltato Peter Stevens, Antonio Brandolini, Jacopo Romei, Francesco Fullone e Cristiano Rastelli. Ho avuto qualche perplessità sul discorso iniziale di Stevens, dovrei leggermi bene il manifesto agile per capire a fondo le esperienze di Jacopo e non ho le capacità di capire la profonda conoscenza di php di Fullone. Perciò ammetto che ho trovato più adatte a me le presentazioni di Brandolini e di Rastelli, che mi hanno regalato qualche perla di saggezza, valida anche fuori da questi contesti.

(visto quello che scriverò tra un po’ in merito al discorso di Rastelli, l’espressione di Lorenzo in questa foto mi sembra particolarmente adatta )

Il problema della qualità è tornato più volte durante la giornata e Antonio Brandolini ha tentato di analizzarlo insieme al pubblico, durante la sua presentazione “Possiamo fare di meglio” (che personalmente mi ha molto divertito). Antonio ha portato diversi esempi pratici in cui noi per primi non abbiamo fiducia e non diamo il meglio. Mi hanno colpito due punti della sua presentazione:

• la semplicità è una risorsa: “Le persone fuggono la complessità come la peste. Provate a entrare nel dettaglio di una discussione e, tempo 30 secondi, avrete perso il vostro pubblico”.
• la qualità non è contrattabile: quando si sa scrivere del buon codice, non si può pensare di abbassarne la qualità per stare dentro a un preventivo. … e questo posso dire che vale un po’ per tutte le professioni.

Brandolini cede la parola al pubblico.

Ho notato che spesso il discorso sulla qualità si è intrecciato con quello dell’usabilità del software. In una pausa tra i vari talk, ne abbiamo discusso un attimo con Lorenzo e Francesco Trucchia (che ho avuto il piacere di conoscere personalmente).

Nella sua mezz’ora di presentazione, Cristiano Rastelli ha detto diverse cose che sento molto vicine:

• nonostante il gran numero di metodi e strumenti utili, il lavoro del grafico ha bisogno di un momento di respiro perché l’idea giusta può venire anche sotto la doccia. Paper prototying, wireframing, tecnica del pomodoro e… l’ultimo che ho sentito ieri dal blog di Jacopo Romei è il Pair Design. Io credo che tutti questi strumenti possano andare bene, ma c’è un momento in cui il designer deve raccogliere i pensieri e immaginarsi lo stile, il gusto, i colori, l’appeal grafico dell’interfaccia. E in quel momento non ci sono pomodori che tengano: un’idea può venire in 5 minuti come dopo due giorni di pausa. Per me, questi momenti “sacri” sono la fase di ricerca e la prima bozza di homepage (e se qualcuno mi interrompe proprio lì…). Dopo che ho avuto il mio tempo, posso discutere con tutti, sistemare, rivedere, aggiustare. Si può anche ritoccare la grafica, avendo il rispetto e la fiducia per l’occhio neutrale che ha una seconda persona. Lo abbiamo fatto in questi giorni con Ale, davanti alla pagina coming soon per Dolcevita. Man mano che lavoravo alla grafica, Ale mi anticipava vari suggerimenti, risparmiandomi tempo e correzioni.
• più che le persone, si possono controllare i processi che seguono. Con questa perla, Cristiano mi ha riportato davanti agli occhi queste slide che avevo visto durante un breve e interessantissimo talk all’IA Summit 2009 di Forlì. È qui che vedo il futuro (meglio, il presente) in cui ci stiamo muovendo e la logica con cui si possono pensare le nuove interfacce, grazie ai nuovi device e alle nuove tecnologie.

Cosa mi resta.

Il mondo degli sviluppatori mi atterisce – lo confesso. Quando i discorsi tornano a essere “umani” e non “informatichesi”, mi rimane la sensazione di uno sforzo incredibile da parte loro, e cioè tradurre in un linguaggio comprensibile, usabile e utile una cosa che è del tutto misteriosa, come il codice, il design di un sistema, un software. A una figura come la mia, gli sviluppatori chiedono di trasformare i loro software in sistemi piacevoli e facili da usare, per non mandare in fumo gli sforzi fatti. Ho visto che esistono molti, moltissimi tools e metodi già pronti, devo solo scegliere quali usare e come. Il viaggio che ho iniziato mi sembra quello giusto. Il mio unico timore è quello di infilarmi troppo profondamente in un discorso tecnico, strozzandomi con le procedure e perdendo di vista la creatività, che è e resta il cuore del mio lavoro. Se voglio stare al passo, la soluzione resta sempre quella: un pezzetto alla volta, provare gli strumenti e poi selezionarli, prendere confidenza con quelli più adatti a me, e… ascoltare, lavorare, spiegare, studiare.