Alberto Mucignat

Qualche settimana fa ho iniziato a collaborare con gli amici di Ideato a un progetto intranet.



Jacopo ha dettagliatamente descritto i primi due giorni di lavoro con il team e gli utenti.

In particolare, per favorire la scoperta delle User Stories, abbiamo adottato un approccio che prevede, assieme agli utenti/stakeholders:
- la scoperta dello scenario tipo di lavoro
- la definizione dei vari "step" dello scenario
- la generazione delle user stories a partire da ogni step dello scenario

Questo approccio ha favorito la comunicazione tra team di sviluppo e utenti, garantendo la copertura di tutti gli aspetti del sistema.

“La perfezione non si ottiene quando non c'è più nulla da aggiungere, bensì quando non c'è più nulla da togliere" -Antoine de Saint Exupery

"Sbarazzati della metà delle parole di ogni pagina, e poi sbarazzati della metà di quello che resta" -Steve Krug, Terza legge di Krug sull'usabilità

"Less is more" -Unknown

Togliere è un'attività fondamentale in ogni processo creativo.

La dimostrazione empirica è che da quando faccio test sugli utenti, mi accorgo che spesso non vogliono molte delle cose che ci vengono in mente.

Quindi, sintetizzando.

"Lavorare con gli utenti serve soprattutto a capire cosa togliere" -Alberto Mucignat

Flow Interactive ha scritto un post su come raccogliere le priorità di un progetto web con le Scorecards.

Il post è molto interessante e, tra le altre cose, utilizzano la matrice di priorità che ho descritto in un precedente post.

Getting Real è una bella lettura estiva. Il libro è uscito da un sacco di tempo, ma vale la pena rileggerlo perchè è sintetico, essenziale, zen.

E poi aiuta a mantenere i piedi per terra. Leggetelo anche a pezzi, ma leggetelo.

Nella sua semplicità, un capitolo fondamentale è Interface Design, dove si spiegano pochi chiari concetti che dovrebbero essere alla base della progettazione di ogni servizio web.

A mo' di mantra riporto i punti più importanti:

- Epicentric Design: iniziare (e focalizzare) il design a partire dal core della pagina. Ne parlo da diversi anni anche in termini di page paradigm.

- Context over Consistency: in ogni pagina ci vanno le informazioni giuste, sulla base di quello che l'utente può decidere di voler fare. Un esempio classico sono i menù: non è detto che uno stesso menù debba apparire in ogni pagina del sito, ma questa è invece una convenzione comune nel costruire siti web.

- Three state solution: disegnare le pagine web pensandole nei 3 stati: regular, error, blank. In particolare lo stato blank viene spesso tralasciato (anche dal sottoscritto, sigh). Si tratta di pensare la pagina a come appare la prima volta che un utente la visita. La prima impressione di un'applicazione web è spesso la cosa più importante (remember: "you never get a second chance").

- Get defensive: migliorare l'esperienza dell'utente in caso di errore o altri problemi. Questa regoletta è stata poi ampliata per bene dagli autori nel libro Defensive Design.

- Copywriting is Interface Design: per finire in bellezza, se non fai copywriting, non stai facendo design. Fondamentale.

In queste regole manca forse qualche accento in più sull'utente, sugli scenari di utilizzo e sui task, che sono fondamentali per stabilire quali cose siano centrali e funzionali a una data pagina. Ma per il resto, lo trovo formidabile.

Quoto in pieno Leeander:

Credo sia assurdo che questi idioti del marketing delle telco continuino a parlarci di quantità di traffico misurate in Megabyte. CHE CAZZO NE SO quanto pesa la pagina di Repubblica (che non leggo, per carità) o che cosa ha messo in home il mio blogger preferito? Il Megabyte è una dimensione per MACCHINE. Trovatene una per UOMINI. Se non siete in grado di farlo, siete anche voi dei Mr. Waterloo.

Per essere chiari:
- a me il telefono serve per telefonare e mandare sms
- vorrei tariffe flat serie
- se scelgo un iphone è anche (e soprattutto) per poter navigare in mobilità

Ora, io credo che vedremo delle serie tariffe internet in mobilità in Italia solo quando in tutto il resto del mondo ci sarà il teletrasporto.

Quindi al momento non ho nessuno stimolo a comprare un iPhone. E sconsiglio tutti dal farlo, perchè mi pare una vera ciulata.

ps: non vorrei disturbarli, ma quelli dell'AGCom pensano di fare qualcosa nei confronti di questo vergognoso cartello delle telco? Che peraltro a questo livello esiste solo in Italia...

pps: per quanto mi riguarda, visto che il mio cell sta tirando le cuoia, credo che mi prenderò un nokia nuovo da 50 euro. E buonanotte.

In questi giorni, mentre esce IE8, c'è chi sta abbandonando il supporto per IE6, che peraltro è usato ancora molto rispetto a IE7. È il caso di 37 signals:

[...] IE 6 can't provide the same web experience that modern browsers can. Continued support of IE 6 means that we can't optimize our interfaces or provide an enhanced customer experience in our apps.Supporting IE 6 means slower progress, less progress, and, in some places, no progress.

Di recente ragionavamo sul fatto che mentre per Firefox e Safari i costi della compatibilità tra versione 2 e 3 possono considerarsi relativamente bassi, pensare di mantenere la compatibilità su 3 browser di casa Redmond equivale a un bagno di sangue (un 9a in termini arrampicatori).

A proposito negli ultimi giorni anche Yahoo ha aggiornato il proprio modello di supporto ai vari browser.

In Google Calendar io trovo molto utili i reminder. In pratica, esiste la possibilità di farsi inviare una mail, un sms (!) e di aprire un popup a una certa distanza dall'evento.

Il menù di selezione consente di scegliere a quale distanza temporale ricevere il reminder, con una vasta scelta di numerilli:



Backpack invece per i reminder utilizza il linguaggio naturale che è molto più semplice da comprendere:



"Later today" non è una cifra precisa, ma è quello che ci diciamo solitamente parlando tra di noi: "me lo ricordi più tardi?".

A piccoli passetti il linguaggio naturale sta prendendo piede sul web, perchè il web dev'essere più vicino alle persone, io credo.

Probabilmente, il linguaggio naturale aumenta la comprensione delle applicazioni web da parte delle persone, migliorando l'usabilità nel suo complesso.

Qualcun'altro ha altri esempi da consigliarmi? Mi interessa molto.

Segnalo che sono aperte le iscrizioni ai workshop del dconstruct (ci sono ancora pochi posti: sbrigatevi!).

Le iscrizioni della conferenza apriranno invece il 24 Giugno, quindi save the date e occhio che i ticket vanno a ruba in poche ore. Io mi sono iscritto ai workshop, quindi se lo fate, sentiamoci che poi ci becchiamo.

Sono aperte anche le iscrizioni a EuroIA, che quest'anno si terrà ad Amsterdam.

YouRank è una toolbar per firefox che memorizza la navigazione web nel proprio pc e consente di ritrovare facilmente i siti visitati, oltre a scoprire i trend derivati dall'attività propria e/o degli altri utenti (sempre se ho capito bene, il software è molto complesso e non ho i dettagli).

Inoltre c'è la possibilità di inviare i dati della propria navigazione a un server centrale, per contribuire a costruire il rank dei vari siti: c'è sicuramente un problema di privacy, che però mi pare sia stato affrontato con buona chiarezza.

Il valore risiede appunto nelle "correlazioni sociali" dei risultati, ovvero dal rank che emergerà dai dati di navigazione degli utenti.

Ne so troppo poco per capire se funzionerà veramente. E al momento un grosso scoglio è dato dal dover passare i miei preziosi dati di navigazione ad altri.

Di sicuro da tempo la community internazionale si chiede se Google funziona bene oppure no, se si può migliorare e come. In ogni caso, progetti come questo avranno il merito perlomeno di provare a dare una risposta.

Disclaimer: Luca mi ha invitato alla beta, chiedendomi di spargere un po' la voce e lo faccio volentieri, ma non sono coinvolto in questo progetto.

Negli ultimi giorni sto lavorando a un progetto con Jacopo e stiamo applicando un processo di sviluppo totalmente agile. Abbiamo discusso parecchio su come pianificare le priorità delle cose da fare e abbiamo sostanzialmente evidenziato due modelli che voglio condividere.



In questo modello, vengono fatte per prime le funzionalità ad alto valore e basso effort. Successivamente le funzionalità ad alto valore ed alto effort e per ultime le funzionalità a basso valore e basso effort.

E' utile quando si vogliono rilasciare velocemente delle nuove funzionalità, ma ha il rischio che funzionalità particolarmente complicate (ad alto effort, quindi anche a maggior rischio) comportino problemi quando è troppo tardi per porvi rimedio.

In realtà è più sicuro avere il seguente approccio.



Facendo prima le funzionalità ad alto valore ed alto effort, si scoprono subito i problemi e si lasciano le funzionalità a basso effort per tutta la seconda parte della realizzazione. Come dire: le rogne prima le affronti, meglio è.

Da notare che in entrambi i casi le funzionalità a basso valore e alto effort non dovrebbero essere fatte: non sono essenziali e costano tanto. Un buon motivo che aiuta il cliente a scegliere cosa non fare.

Può sembrare un modello semplice, ma spesso è complicato stabilire le priorità di un progetto e fare una valutazione dell'effort per ogni singola funzionalità.

La mancanza di tempo è la scusa più comune, una giustificazione più che altro verso se stessi. Con le metodologie agili esiste una facile pratica chiamata planning game che aiuta molto.

In alternativa, si rischia di considerare che tutto sia importante e tutto sia facile, mentre non è mai così.

Comunque questo è solo il primo macro-livello del modello di pianificazione che stiamo costruendo, ma fornisce le basi per una discussione iniziale.

Tu cosa ne pensi? Hai mai pianificato il lavoro sulla base del valore e del costo delle feature? Che problemi/benefit hai avuto?