L’appuntamento era gratuito ed i biglietti sono spariti in pochissimo tempo: basti pensare che le iscrizioni sono state aperte solo un paio di settimane prima della data e anche con 200 posti a disposizione la waitlist era decisamente affollata.

Valeva la pena esserci? Decisamente sì.

Non ho intenzione di fare un resoconto di tutti i talk, anche perché erano divisi su due sale e non ho ancora il dono dell’ubiquità, ma è stata una giornata ricca di spunti di riflessione su un tema — quello delle metologie agili — che da più di due anni mi interessa particolarmente.

I temi

Sono emersi alcuni temi ricorrenti durante i vari talk, ed è su questi che mi voglio soffermare.

Il ruolo del Product Owner

Fin dal keynote di apertura di Luca Mascaro il ruolo del PO è stato oggetto di numerose riflessioni. È effettivamente un punto di contatto indispensabile tra il ciclo di sviluppo che procede per iterazioni ed i feedback che arrivano dal mondo esterno. Ma se parliamo di user experience e indicazioni che arrivano dagli utenti dove si posizionano gli UX designer?

Questo punto apre la strada ad un secondo tema emerso durante la giornata.

UX designer: dov’è la visione a lungo termine?

Lavorando per brevi iterazioni (es. sprint di due settimane, come succede nel team scrum dove lavoro attualmente) c’è un forte rischio di perdere di vista la direzione del progetto. Seguendo un insieme eterogeneo di sviluppi nell’arco di varie iterazioni, difficilmente dopo qualche mese ci sarà coerenza se non si è seguita una linea guida. Questo dal punto di vista del designer è un grosso pericolo, ma rinunciare alle iterazioni dal mio punto di vista non è accettabile.

Durante il barcamp c’era chi parlava di designer all’interno dei team di sviluppo e chi invece li posizionava ad un livello superiore quasi a fianco del PO, soprattutto per il lavoro di analisi.

Ritengo il lavoro in un team crossfunzionale l’unica soluzione possibile: non ha senso dividere lo sviluppo verticalmente facendo un considerevole passo indietro.

C’è però un obbligo: avere una visione (che può cambiare in corsa, e quasi sicuramente lo farà) e usarla come guida durante le iterazioni. È un concetto chiave, che anche Aral Balkan aveva espresso alla Kerning Conference e a From the front 2012:

Dati, dati e ancora dati

Non mi stancherò mai di dirlo e finalmente è un concetto che viene ripetuto sempre più spesso durante conferenze ed eventi. Lavorare sulla base di dati e non di supposizioni è l’unico modo per raggiungere dei risultati.

Non è un discorso limitato esclusivamente a chi si occupa di UX: la raccolta di dati nelle fasi iniziali di un progetto e durante ogni iterazione dello sviluppo è fondamentale per lavorare nella giusta direzione.

I comportamenti degli utenti ed i loro desideri sono l’unica cosa che conta.

La cronaca di #auxc13

Per chi vuole rileggere il racconto della giornata ho creato una board con tutti i post dei vari social network relativi all’evento. La trovate su un servizio che ho scoperto proprio il giorno prima della conferenza: http://tagboard.com/auxc13

Conclusioni

Al termine di questi eventi resta spesso una bella sensazione. Non succede sempre, ma se accade significa che la giornata è stata spesa bene.

È stato sicuramente merito dei presenti e delle tante persone che sono riuscito ad incontrare: volti con cui fa sempre bene confrontarsi e che aiutano a non fossilizzarsi sulle proprie convinzioni.

Grazie a tutti.

Esistono la quotidianità e le abitudini del lavoro di tutti i giorni, ma per crescere è necessario anche guardarsi intorno.

Non capita tutti i giorni di trovare in Italia una conferenza internazionale su un argomento di nicchia come la tipografia. Dopo l’esperienza fantastica di From the Front questo nuovo appuntamento italiano aveva degli ottimi presupposti, e le mie aspettative non sono state deluse.

Fin dalla lista degli speaker era lecito aspettarsi qualcosa di unico: il filo conduttore degli interventi era la tipografia, ed ognuno è stato in grado di interpretarlo al meglio. Sapevo cosa aspettarmi da Aral Balkan che si è dimostrato ancora una volta un grande uomo da palcoscenico, ma ci sono state anche delle gradite sorprese come il talk di Yves Peters sull’uso del Trajan nei poster dei film. Probabilmente uno degli interventi più apprezzati.

Ma andiamo nel dettaglio dei talk, perché ognuno degli 8 speaker presenti merita una citazione.

Gli interventi sul palco

Luc(as) De Groot — Keynote

Lucas ha avuto l’onore di aprire la conferenza, e visto il suo curriculum non c’era da dubitare del suo talento. Per chi non lo conoscesse, è l’autore della famiglia di font Thesis, e per Microsoft ha realizzato Consolas e Calibri. Il suo talk è iniziato dalla storia della tipografia per poi entrare nei dettagli del lavoro del font designer: una professione sicuramente sottovalutata, caratterizzata da notti insonni davanti al monitor a correggere kerning e hinting.

Vedere l’animazione in 80 step di come veniva corretta una “&” è stato qualcosa di incredibile, che mi ha fatto pensare “non farò mai il suo lavoro”.

Nina Stössinger — The Hitchhiker’s Guide to Typography

Il talk di Nina è stata la prima di svariate occasioni durante la giornata in cui è stato possibile capire il vero senso della tipografia. Non si tratta di rendere un contenuto semplicemente bello: la scelta di font, dei giusti caratteri, della corretta indentazione e spaziatura sono dettagli che possono fare davvero la differenza, anche se la maggior parte delle persone non se ne accorgerà. Non è quello l’obiettivo, perché anche se la maggior parte dei lettori di una pagina non sarà in grado di distinguere la differenza tra due font diverse, il solo fatto di offrire — inconsciamente — un’esperienza più piacevole è un motivo valido per spendere del tempo in questo lavoro.

Richard Rutter — Inspiring Web Typography you can do now

Richard ha un curriculum di tutto rispetto, essendo la mente dietro a Clearleft e FontDeck. Il suo intervento è stato il primo con un approccio più tecnico, orientato alla web typography.

I consigli pratici su come realizzare un sito responsive sono materiale prezioso che vi consiglio di leggere nelle slide messe a disposizione. Gestione delle media-query, lunghezza dei paragrafi proporzionale alla dimensione della pagina, e strumenti utili per il lavoro quotidiano come modular scale sono stati spiegati in dettaglio.

La citazione?

Good typography induces a good mood. Like beer, or sex.

Slide: http://webtypography.net/talks/kerning2013/

Marko Dugonjić — Responsive Web Typography

Anche Marko Dugonjić ha tenuto un talk sulla buona tipografia dei siti responsive. È stato effettivamente un punto debole del programma, con due interventi simili uno dopo l’altro, ma gli speaker sono comunque stati bravi ad evitare ripetizioni.

Marko ha criticato senza pietà siti come UxMas, che per quanto ben fatti e ricchi di contenuti interessanti non hanno curato con altrettanta attenzione la tipografia. Il sito in questione è responsive, ma i testi rimangono inalterati, con la stessa line-height e nessuna variazione anche sul display di un cellulare, rendendo i contenuti difficilmente leggibili.

Yves Peters — Two decades of Trajan in movie posters

Il talk di Yves Peters è stato probabilmente uno dei più apprezzati. Parlando di un argomento apparentemente scontato come i poster cinematografici ha presentato un’analisi dettagliata e allo stesso tempo divertente per spiegare come le logiche in questo ambito siano totalmente diverse da quelle di altri ambiti.

L’originalità viene messa da parte in favore della riconoscibilità, permettendo a chiunque di capire a colpo d’occhio dalla locandina di un film quale sia l’argomento. Film d’azione, drammatici, commedie, tutti con locandine identiche per essere riconoscibili, e questo si è riflettuto anche nella scelta della tipografia con il fenomeno Trajan, che viene definito “the movie font”.

Aral Balkan — Content out typography

Avevo già applaudito Aral durante From the front 2012, ed il suo intervento alla Kerning Conference è stato altrettanto emozionante. Il ruolo del designer deve essere focalizzato nell’offrire la migliore esperienza possibile, puntando all’eccellenza, senza fermarsi alla mediocrità.

Aiutato dalla sua notevole abilità sul palco, Aral è stato capace di tenere i presenti per almeno 10 minuti a guardare una pagina HTML mentre scriveva codice: non da tutti. In questo caso il messaggio era chiaro: prima i contenuti.

Ha offerto anche notevoli spunti di riflessione parlando di framework e griglie: come designer abbiamo una paura tremenda, quella della tela bianca su cui non sappiamo cosa scrivere o disegnare. Le griglie ed i framework come Bootstrap ci aiutano a superare questa difficoltà, ma il risultato sarà per forza di cose limitato dai confini che ci siamo autoimposti. Perché non andare oltre? Se vogliamo raggiungere l’eccellenza, l’unico modo è eliminare tutto ciò che è preconfezionato, partendo dai contenuti.

Bas Jacobs — Tea is the new coffee. The book is the new LP. Hinting is the new kerning. Doing is the new thinking.

Bas ha tentato l’impossibile, con il primo esperimento di kerning dal vivo, coinvolgendo tutti i presenti in una simulazione all’interno del teatro. Sorvolando le risate rivolte a chi non capiva cosa fare, ha confermato quello che altri prima di lui avevano già detto: quello del font designer è un mestiere spesso incompreso, e almeno tra i professionisti dovrebbe essere d’obbligo almeno sapere come utilizzare le feature OpenType di un font.

Chris Murphy — These go to eleven

Chris degli Standardistas ha chiuso la conferenza basando il suo intervento su un concetto chiave: la tipografia è un vestito per i contenuti, che deve essere adeguato al contesto per comunicare al meglio quello che vogliamo.

Anche in questo caso è tornato l’immancabile tema dei contenuti: mai come in questa giornata l’attenzione è stata rivolta al messaggio. Soprattutto in ambito web, questo spesso viene dimenticato quando invece dovrebbe essere alla base di tutto.

Conclusioni e ringraziamenti

Anche in questo caso, un grazie va agli organizzatori.

Sono riusciti in un compito non facile, creando dal nulla un evento e riuscendo a riscuotere un ottimo successo. Se vi siete persi la conferenza e questo resoconto non vi ha soddisfatto, tornate prossimamente quando saranno messi online i video degli interventi. Da non perdere.

Il workshop era intitolato “CSS e HTML5: organizzare il caos”. Speaker di turno Matteo Papadopoulos, che in poco più di un’ora ha affrontato una serie di temi relativi allo sviluppo di pagine web facili da mantenere grazie alla logica modulare.

L’argomento non era facile da affrontare soprattutto addentrandosi in dettagli tecnici, ma proprio questo ho trovato diversi spunti interessanti.

La logica modulare

Imparare a scrivere codice CSS è tutto sommato semplice, ma quando si tratta di farlo in maniera ordinata e ben strutturata iniziano a emergere le prime difficoltà. Per questo motivo la soluzione migliore è capire fin da subito come suddividere la pagina in moduli, sfruttandoli per non ripetersi nella scrittura del codice.

Ho trovato molto intelligente il riferimento alla creazione di wireframe e prototipi su carta nelle fasi iniziali di un progetto: iniziare subito a scrivere codice non è mai una buona idea, perché creare un prototipo permette di individuare facilmente i blocchi che compongono le singole pagine. Da lì a strutturare il codice HTML e CSS in maniera modulare il passo è breve.

Anche l’HTML5 aiuta in questo, perché i tag semantici (section, article, aside, header, footer) aiutano a ordinare il lavoro, senza esagerare con ID e classi.

Un chiaro sintomo di un approccio sbagliato alla scrittura del codice è l’uso degli !important nel CSS. Ogni volta che viene usato significa che c’è qualcosa che non va. Cosa fare per evitare questi problemi? Andare a ritroso, trovare il problema, capire quale parte di codice è alla radice del caos e imparare dai propri errori.

Se poi il sito deve essere responsive, partire dalle risoluzioni più basse è sempre la scelta migliore. Questo tipo di approccio mobile first permette di costruire il CSS in maniera ordinata, aggiungendo nuovi elementi al CSS senza essere costretti a continue sovrascritture delle regole esistenti.

SASS e i preprocessori CSS

Parlando di CSS e moduli, viene naturale il collegamento con i CSS preprocessor come LESS e SASS. Nel workshop di Matteo oggetto della discussione era proprio SASS, che è stato utilizzato per costruire una pagina di esempio in pochi passi.

Cos’è un preprocessore? Uno strumento che permette di utilizzare all’interno dei fogli di stile variabili, funzioni, controlli condizionali e tutta una serie di comodità altrimenti proibite. Proprio per questo motivo, unito alla mantenibilità, è consigliato usare uno strumento come SASS in ogni situazione, anche per i siti di poche pagine che prima o poi richiedono sempre modifiche e nuove aggiunte.

Abbiamo visto anche utility di supporto come Compass, un framework che grazie a SASS permette di utilizzare i CSS3 e la tipografia in maniera comodissima, senza dover tra l’altro scrivere per ogni regola gli odiati prefissi -webkit, -moz, ecc…

Una citazione la merita anche Oily_png, un’estensione di Ruby che permette di creare immagini sprite automaticamente. Mettendo le icone in una cartella e compilando il codice viene creato lo sprite: nel CSS viene usato come background, e le singole icone vengono sostituite dalle coordinate dello sprite.

Cosa volere di più? È tutto automatico!

Se vi interessano i prossimi workshop di Develer tenete d’occhio il sito dedicato. Potreste trovare l’argomento che fa per voi.

[Construction block - immagine di Shutterstock]

Ammettetelo: se avete fatto attenzione all’accessibilità dei vostri siti, fino a qualche tempo fa vi siete sicuramente preoccupati di inserire sui link poco comprensibili un attributo title. Lo scopo era chiaro: spiegare meglio la destinazione del collegamento.

Un esempio su tutti è quello dei classici “read more” o “continua…”, dove un attributo title poteva dare qualche informazione in più:

<a title="Titolo della pagina di destinazione">continua...</a>

Leggendo un post di David Ball ho fatto la scoperta: il title non serve perchè non viene letto dagli screen reader, e utilizzarlo crea solo confusione. Incredibile fino a qualche anno fa: se cercate in rete articoli che parlano di accessibilità, erano in molti a raccomandare l’uso di questo attributo.

Come si comportano gli screen reader

La prova è stata eseguita sia con JAWS (software a pagamento) che con la sua alternativa gratis più diffusa: NVDA. In particolare JAWS ha un’opzione per attivare la lettura degli attributi title, ma è disabilitata di default.

Un utente non vedente non saprà mai che avete speso del tempo ad inserire un title su un link. Anche nel caso il link sia su un’immagine viene letto l’attributo alt, e non il title.

L’unico caso in cui viene letto il title è quando non è presente l’attributo href: situazione veramente rara.

Se volete le prove, questa è una dimostrazione video di cosa accade:

Ha senso usare ancora l’attributo title sui link?

Dovendo dare una risposta chiara, a questo punto direi semplicemente no, non serve.

Il title ha senso su altri elementi come abbr o acronym, ma per i collegamenti ipertestuali è bene trovare altre strade. Se un link ha bisogno di una spiegazione, molto probabilmente significa che deve essere scritto meglio.

Della stessa opinione sono anche Bruce Lawson e Jeffrey Zeldman, ai quali lo stesso David ha fatto la domanda tramite Twitter. Il responso è stato chiaro: niente title sui link!

E sui link “continua…”?

Se proprio non potete fare a meno di questi link, il W3C suggerisce di aggiungere del testo descrittivo, e nasconderlo successivamente tramite CSS. Laborioso, ma funzionale. La soluzione migliore in questo caso è sostituire il testo generico direttamente con qualcosa di più mirato: se funziona per gli utenti non vedenti, perché non usarlo per tutti?

[HTML code - immagine di Shutterstock] 

Ho voluto aspettare a scrivere un articolo a riguardo perché volevo provare direttamente sul campo gli insegnamenti necessari: non avrebbe avuto senso riproporre testi scritti altrove senza approfondire di persona.

La mia esperienza

Non posso andare troppo nello specifico sull’argomento del test: l’esperimento è stato infatti condotto nell’azienda in cui lavoro per testare delle pagine non ancora online. Posso però affermare senza ombra di dubbio che questo esperimento è stato utilissimo per rendersi conto degli errori commessi durante lo sviluppo: la parte migliore è stato potersi accorgere come sia possibile ottenere netti miglioramenti correggendo pochi dettagli. Se si considera poi il tempo necessario per eseguire i test (6 sessioni eseguite nell’arco di 2 giorni, compresa l’elaborazione dei risultati), il risultato è stato eccellente ed ha risparmiato ore ed ore di riunioni:

Il materiale necessario per iniziare

Cosa serve per iniziare? Intanto vi tranquillizzo subito: non avrete bisogno di un enorme lavoro di preparazione. È necessario organizzarsi e servono un po’ di documenti, ma sono tutti testi che potete preparare in qualche ora.

Noi eravamo in due ad eseguire i test: una persona seguiva l’utente, e l’altro prendeva nota di tutto quello che succedeva sullo schermo. Per essere sicuri di non perdere nessun dettaglio abbiamo anche invitato ad ogni sessione un terzo osservatore che seguiva quello che succedeva sedendo in seconda fila, senza disturbare.

In particolare avrete bisogno di:

• un copione da seguire non necessariamente scritto in maniera dettagliata, ma approfondito quanto basta per ricordarvi cosa dire al vostro ospite. I concetti fondamentali da ricordare sono pochi: dire all’utente che non è lui ad essere oggetto del test, che per quanto possibile è bene che pensi ad alta voce descrivendo cosa sta facendo, e che gli organizzatori non potranno rispondere alle domande dell’utente o intervenire se non per motivi tecnici.
• istruzioni per gli osservatori esterni eventualmente presenti, ricordandovi di non invitare troppe persone. Per questo motivo vi consiglio di non far assistere più di una persona per volta oltre a quelle necessarie per eseguire il test. Potete anche non invitare nessuno e semplicemente condividere i risultati, ma a noi è stato utile questo tipo di approccio per far capire meglio all’interno dell’azienda l’utilità di quello che stavamo facendo. Le istruzioni da dare sono semplici: non disturbare, eventualmente prendere appunti (un altro punto di vista non fa male), e segnarsi eventuali domande da fare alla fine.
• scenari con compiti ben precisi da far eseguire all’utente: una componente fondamentale del test, che merita un approfondimento (vedi sotto).
• un questionario finale da far compilare ai partecipanti. Noi essendo in due ci siamo organizzati in maniera più informale: una persona faceva le domande e l’altro si segnava le risposte. Le domande dovrebbero comunque essere abbastanza generiche per non guidare troppo l’utente: arrivati alla fine quello che vi interesserà sarà raccogliere sensazioni e suggerimenti, tenendo però presente che hanno molto più valore le indicazioni raccolte guardando il comportamento dell’utente durante il test.

Avremmo potuto usare anche un software di screen recording (la nostra scelta sarebbe stata Silverback), ma per questo primo esperimento abbiamo deciso di non farlo per non complicarci troppo la vita. La scelta è stata corretta, perché gli appunti sono stati più che sufficienti.

Gli scenari

La scrittura degli scenari è sicuramente la parte più complicata di tutta la preparazione. Dovete infatti dare all’utente degli obiettivi precisi da seguire, e la scelta di questi obiettivi è determinante per capire i problemi del vostro sito/applicazione. Lasciare troppa libertà all’utente può essere controproducente, ma essere troppo specifici potrebbe d’altra parte guidarlo fin troppo attraverso i percorsi che volete, falsando l’esito del test.

Qualche esempio potrebbe essere:

• cerca un prodotto specifico e acquistalo
• registrati al sito e accedi alla tua area personale
• scrivi un contenuto e pubblicalo
• ritrova il contenuto pubblicato e modificalo

Cercate di immedesimarvi nel vostro target ed immaginate degli obiettivi realistici. Una volta trovati, scriveteli in maniera schematica e stampateli: solo così potrete avere delle indicazioni precise durante il test.

La ricerca degli utenti giusti

Quali persone far partecipare al test? Quante ne servono? La ricerca di utenti è un compito più semplice di quanto si possa immaginare, principalmente perché qualsiasi utente sarà capace di far emergere i problemi più gravi del vostro sito, anche se non rientra esattamente nel vostro target di riferimento.

Per questa prima sessione di test noi abbiamo sfidato le comuni raccomandazioni, prendendo persone interne all’azienda che però non avessero a che fare con le attività di sviluppo e non conoscessero il progetto: amministrazione, ufficio acquisti, ecc.
Non è la soluzione ottimale perché in questo modo gli utenti potrebbero comunque conoscere già qualcosa, ma devo ammettere che nel nostro caso l’esperimento è andato davvero bene. Se siete alle prime armi e volete organizzare una prima sessione di test di usabilità, potete provate anche invitando le persone che avete intorno, assicurandovi però che non conoscano il progetto. Parenti e amici sono una soluzione altrettanto valida.

Il numero di utenti necessari è limitato, ed è uno dei motivi per cui sono sufficienti 1-2 giorni per avere dei risultati. Già dopo le prime 3-4 sessioni sarete in grado di evidenziare i problemi più gravi di usabilità, ed eventuali sessioni successive serviranno solo a confermare quanto già trovato e ad aggiungere alla lista problemi secondari. A noi sono bastate 6 sessioni, e già dopo le prime 2-3 avevamo raccolto molte indicazioni utili.

Elaborazione dei risultati

Eseguite le sessioni di test, vi troverete con diverso materiale da elaborare:

• appunti oggettivi raccolti osservando il comportamento dell’utente durante il test
• commenti finali e risposte al vostro questionario
• appunti raccolti dagli eventuali osservatori esterni invitati a partecipare

La cosa migliore da fare a questo punto è ritagliarsi un paio d’ore per organizzare il materiale raccolto. È fondamentale non far passare troppo tempo, perché in questo frangente quello che avete visto è molto più importante di qualsiasi appunto scritto.

Un consiglio che ho sentito dare dallo stesso Steve Krug è quello di organizzare le sessioni di test nell’arco di una mattinata e pranzare subito dopo con tutte le persone coinvolte nel progetto. Questo permette di discutere immediatamente dei risultati. Ovviamente è bene che partecipino tutti, dagli sviluppatori ai grafici.

Azioni da intraprendere

La parte più importante di tutta la sessione di test di usabilità è questa: non lasciate i report da una parte senza intraprendere alcun provvedimento, altrimenti sarà stato tutto inutile. Se avete individuato dei problemi, correggeteli subito e non lasciate passare troppo tempo!

Questo è uno dei motivi per cui è bene organizzare pochi test veloci ed eventualmente ripeterli spesso: se impiegherete settimane a scrivere un report, magari aspettando di elaborare eventuali video registrati, al 99% tutto resterà come prima.

Conclusioni

I test di usabilità sono uno strumento indispensabile per raccogliere feedback concreti su un progetto, ed è importante eseguirli spesso. Una volta al mese può essere sufficiente se riuscite a non dilungarvi troppo. Vedere un utente non riuscire ad utilizzare un’interfaccia che ritenevate immediata non ha prezzo: ore ed ore di riunioni saranno smentite in poco tempo, perché quello che conta realmente è sempre il comportamento delle persone reali.

Se non sapete come iniziare e non avete l’appoggio di nessuno, provate a partire in piccolo organizzando un primo esperimento. Invitate qualcuno a osservare quello che succede, e ben presto il passaparola farà capire alle persone che avete intorno l’importanza di questa pratica.

Aspettavo l’appuntamento con From the Front da maggio scorso, momento in cui all’Agile UX Barcamp ho scoperto che ci sarebbe stata un’edizione 2012 della conferenza. Ebbene, non sono rimasto deluso. Ho passato una giornata intera in quel di Bologna, dalle 8 di mattina alle 19 di sera, in compagnia di sviluppatori, designer e professionisti del settore affamati di conoscenza, nella cornice del teatro Duse.

Se eravate presenti non ho bisogno di aggiungere altro, sapete di cosa sto parlando. Per chi non c’era: vi siete persi uno dei migliori eventi degli ultimi anni in Italia, e mi dispiace davvero che non siate riusciti a partecipare. È stato un appuntamento memorabile, con ospiti internazionali e riflessioni più o meno tecniche sul futuro del web, sulla creatività e sul design.

Non capiterà molto spesso di trovare nello stesso evento Steve Krug che parla di usabilità, Jonathan Snook che spiega come scrivere i CSS in modo produttivo e altri personaggi del calibro di Blaine Cook (sì, una delle menti dietro al primo Twitter), Remy Sharp e Aral Balkan.

Ma andiamo per gradi, perché voglio riservare uno spazio a tutti.

I talk di From the Front 2012

Steve Krug – You are not doing usability testing? Are you… nuts?

Il keynote di Steve Krug è stata la degna apertura dell’evento. L’autore di Don’t make me think (praticamente tutti i presenti conoscevano il libro) ha parlato di test di usabilità e della loro importanza. Non è importante che siate una realtà grande o piccola: è assurdo progettare per il web e non verificare quello che si è sviluppato con degli utenti reali.

Un test di usabilità non necessita di grandi fondi a disposizione: più imponente sarà l’organizzazione del test ed il report generato, meno probabilità ci saranno di vedere messe in pratica delle correzioni. È tristemente comune: le società che commissionano test di usabilità molto spesso non modificano niente anche dopo aver appreso i propri errori.

Cosa fare quindi? Alleggerire la procedura e svolgere test veloci con poche persone senza preoccuparsi del target del proprio prodotto: se ci sono problemi di usabilità, emergeranno comunque. Svolgere un test una volta al mese, una mattina, e discutere a pranzo i risultati con tutti gli sviluppatori coinvolti. Niente report di centinaia di pagine!

È stato illuminante vedere una dimostrazione di un test di usabilità sul palco, con l’applicazione Clear per iPhone: è un’app decisamente ben fatta, ma nonostante questo sono emerse delle difficoltà di utilizzo.

Peter-Paul Koch – A pixel is not a pixel

L’intervento di Peter-Paul Koch è stato tecnico, inerente ad un argomento ben noto a molti: la resa dei pixel sui dispositivi mobili, soprattutto dopo l’arrivo dei retina display. Chi è @ppk? La mente dietro a Quirksmode: se sviluppate sul web non potete non conoscere il blog.

Ha spiegato perfettamente le ragioni dietro all’utilizzo del meta tag viewport con il valore width=device-width. Se volete che il vostro layout sia responsive, dovete partire da qui.

Trovate le slide della sua presentazione qui: A pixel is not a pixel (download pdf).

Denys Mishunov – Science of design

Denys ha tenuto un talk in bilico tra visual design e arte, spiegando le ragioni di una serie di convenzioni ormai più che diffuse. Sezione aurea, regola dei terzi, gestalt e regole presenti nelle varie arti, dalla pittura alla musica passando per l’architettura. Ascoltarlo è stato un piacere, anche se mettere in pratica le sue raccomandazioni non è sempre così immediato… c’è spazio per imparare e sperimentare.

La sua presentazione è visibile su Speaker Deck.

Remy Sharp – Mobile debugging

Il titolo dice tutto: Remy Sharp ha tenuto uno speech tecnico su come effettuare debugging sui dispositivi mobili. Spesso questa pratica è un incubo, ma esistono degli strumenti incredibili che mi hanno lasciato a bocca aperta. Tool come weinre o JS Bin possono essere utilissimi: se volete sviluppare su mobile avete due scelte: impazzire, oppure collegare il vostro telefono al computer su cui lavorate e vedere il vostro lavoro aggiornarsi in tempo reale sullo smartphone. Se volete sapere come fare seguite la presentazione qua sotto.

In attesa dei video di From the front, ho trovato infatti il talk su Vimeo. Potete leggere anche le slide su Speaker Deck.

Blaine Cook – Inventing the new world

Blaine è stato lead developer di Twitter, adesso lavora come freelancer. Ammetto di essere rimasto sorpreso dal suo talk, che ha avuto un’introduzione decisamente spiazzante quanto astratta. L’obiettivo era aprire la mente dei presenti, cercando di capire in che direzione stia andando il web. È fondamentale individuare la rotta da seguire e non lasciarsi tentare da quello che è stato già fatto per ripercorrere strade comode ma banali.

Durante il suo intervento la timeline di twitter ha visto calare in maniera drastica gli interventi con l’hashtag #ftf12: eravamo rapiti dal talk.

Linda Sandvik – Making things better

Linda ha avuto il merito di riuscire a far aprire gli occhi a tutti coloro che erano all’interno del teatro Duse. Perché limitarsi e arrendersi davanti ai propri limiti? Perché non osare e porsi sempre nuove sfide?

La dimostrazione più lampante l’ha data lei: non aveva mai tenuto un talk in una conferenza prima d’ora, e se l’è cavata alla grande nonostante l’evidente timidezza. Quando l’abbiamo scoperto, 20 minuti dopo l’inizio del suo intervento, gli applausi sono stati spontanei. Immaginate poi la reazione del pubblico quando ha dichiarato di avere partecipato alla corsa di cavalli più lunga del mondo, lo scorso agosto, senza avere mai fatto prima alcuna attività sportiva.

Jake Archibald – Application cache: douchebag

Jake ha dimostrato un’abilità senza pari, parlando di un tema tecnico senza annoiare.

Appcache permette di far scaricare al browser intere parti di un sito web, conservandole in locale per quando la connessione non è disponibile e migliorando le prestazioni. Tutto questo però non è esente da pericoli, perché giocare con la cache può causare brutti scherzi arrivando anche a rendere impossibile l’aggiornamento di un sito.

Se volete saperne di più, Jake ha pubblicato su A list apart un articolo con lo stesso titolo della presentazione di From the Front.

Anche in questo caso ho trovato un video su Vimeo, sentirsi spiegare certe cose a voce è molto più efficace:

Jonathan Snook – State-based design

Jonathan Snook non ha bisogno di presentazioni: con Steve Krug per me era l’ospite più atteso. Certe figure sono diventate delle vere e proprie star grazie alla loro bravura, e non ha prezzo ricevere conferme sul proprio metodo di lavoro da professionisti del genere.

Ha spiegato come scrivere il codice CSS in maniera efficace e manutenibile, facendo capire chiaramente che usare i fogli di stile è semplice, ma farlo in maniera corretta, elegante e strutturata richiede molta più attenzione.

La frase più rappresentativa del suo talk è sicuramente questa:

Don’t code CSS for a page. Code it for a system.

Denise Jacobs – Responsive storytelling

L’intervento di Denise Jacobs è stato quello più atipico: ha raccontato la storia di un cervello, intrattenendo i presenti con una favola per spiegare quello che succede nella nostra testa, la differenza tra emisfero destro ed emisfero sinistro, e come stimolare la creatività.

Il paradosso è quello ormai noto: il cervello non è una macchina e non gli possiamo chiedere l’impossibile. Per essere produttivi è fondamentale distrarsi, giocare, ridere ed allontanarsi dall’idea di un mondo sempre più grigio.

Aral Balkan – A happy grain of sand: designing for humans

Ammetto la mia ignoranza: non conoscevo Aral Balkan prima di venerdì scorso. È stata una lacuna che ho colmato molto volentieri, visto che il suo intervento ha incantato tutti i presenti. Aral è un designer con una reale passione per quello che fa, e tra l’altro ha dimostrato di essere un uomo da palcoscenico, cosa che non a caso lo porterà al TED Global 2013.

Il suo entra di diritto tra i migliori talk mai ascoltati ad una conferenza, e se volete avere un’idea di cosa sto parlando potete andare direttamente al video qua sotto.

Ha parlato della responsabilità di noi designer, del ruolo che abbiamo e degli obiettivi che dobbiamo porci.

Ha saputo inserire nel suo intervento numerosi momenti comici, mostrando errori di progettazione assurdi ma realmente esistenti: l’era delle feature è finita, quello che conta davvero è l’esperienza utente. Proprio per questo il minimalismo deve essere la regola, perché la chiave del successo non è aggiungere funzionalità, ma eliminarne finché è possibile.

Ci sono due citazioni che mi sono segnato e che ho voluto condividere anche su Twitter:

An experience is only as strong as its weakest link.

e

Great design is about to say “No” way more than saying “Yes”.

Il design non è democratico: cedere alla tentazione di aggiungere inutili dettagli senza motivo, magari richiesti da persone diverse, è sbagliato e porta a risultati mediocri. L’obiettivo devono essere i bisogni degli utenti, perché ogni esperienza durante la nostra vita è come un granello di sabbia che passa in una clessidra.

L’obiettivo?

Fare in modo che le esperienze positive siano più di quelle frustranti, rendendo migliori le nostre vite.

Una parola per gli organizzatori

Grazie.

Dico sul serio, grazie per l’evento che avete saputo organizzare. Ci sono stati problemi, lunghe attese, e qualcosa poteva inevitabilmente andare meglio, ma tutto passa in secondo piano quando torni a casa contento per avere investito bene il tuo tempo. Quando ci sono eventi del genere, la cosa più importante è sentirsi arricchiti e felici, con la voglia di condividere almeno una piccola parte di quello che si è ascoltato. È quello che ho provato io, ed è la ragione che mi ha portato a scrivere questo post.

Non penso di esagerare dicendo che From the Front 2012 sia stata una delle migliori conferenze degli ultimi anni in Italia.

Continuate così.

[photo by magrolino, laurakalbag]

<label for"nome">Nome:</label>
<input type="text" name="nome" placeholder="Inserisci il tuo nome">

Il risultato sarà simile a questo:

C’è però un dettaglio non indifferente da ricordare: l’attributo placeholder non può sostituire la label di testo. Questo semplicemente perché iniziando a compilare il campo il placeholder scompare, e non si hanno più indicazioni su quale contenuto inserire. In alcuni browser sparisce addirittura al focus.

Leggendo la documentazione del W3C, le indicazioni sono chiare:

The placeholder attribute should not be used as an alternative to a label.

In sintesi: il placeholder è comodo, spesso semplifica la vita e può essere utilizzato facilmente per visualizzare dei suggerimenti, ma per indicare il contenuto di un campo la label resta di primaria importanza. Dovrebbe infatti essere utilizzato per contenuti testuali opzionali, come il title.

Se proprio non è possibile visualizzare la label, questa dovrebbe almeno essere presente nel codice HTML e nascosta tramite CSS in modo che almeno gli screen reader la possano leggere. Ci sono poi delle eccezioni come i campi di ricerca, dove basta una semplice icona per far capire lo scopo del form.

Per dare un aspetto grafico differente all’attributo placeholder potete seguire questa guida di David Walsh, ma non vi consiglio di spingervi troppo oltre con le personalizzazioni, anche perché non tutti i browser offrono questa possibilità.

Ma a cosa è dovuto il suo successo?

I fattori sono diversi: il primo è sicuramente da ricercare nella comunicazione e nei testi utilizzati sul sito. Potrebbe sembrare una cosa banale, ma dietro ogni annuncio c’è un preciso studio su come attirare il cliente utilizzando testi informali e diretti. Non troverete mai offerte banali: molto spesso è l’ironia l’aspetto che emerge nelle descrizioni dei prodotti. Attenzione però a non confondere le varie fasi dell’esperienza utente: se sul sito lo stile è informale, non lo è altrettanto nelle comunicazioni ufficiali, nelle mail di servizio e in tutti gli aspetti che riguardano pagamenti e processo di acquisto.

Oltre ai contenuti, ci sono anche diversi fattori psicologici da tenere presenti: il primo è il concetto di variable rewards (premi variabili), come vengono definiti anche su Designing for emotion, il libro che ho recensito pochi giorni fa. Trovare ogni giorno un’offerta diversa sul sito, o riceverne una via mail, è una sorta di slot-machine quotidiana che invoglia a tornare spesso sperando di trovare qualcosa di interessante. Questa è una logica ovviamente comune a tutti gli altri siti del genere, come Groupalia.

Ad aumentare il coinvolgimento contribuiscono altri due elementi, sempre presenti su questi siti:

• l’urgenza dell’acquisto, indicata da un periodo molto breve a disposizione per comprare il prodotto, con tanto di conto alla rovescia
• l’indicazione di quante altre persone hanno già aderito all’offerta, per rassicurare. Questo elemento aveva un significato diverso in passato, quando ogni deal consentiva un numero limitato di acquisti: in quella circostanza era ancora l’urgenza il fattore predominante.

Il problema dei gruppi d’acquisto

Groupon, Groupalia, ed i vari competitor nati in questi anni sulla scia del loro successo devono però vedersela con un problema: la fiducia dei clienti. Va tutto bene finché non emergono problemi con gli acquisti, ma cercando in rete sono tanti i casi negativi. Il problema è sempre il solito: i commercianti scaricano le responsabilità sul sito web, mentre l’assistenza telefonica incolpa i negozianti. Il cliente si trova quindi a combattere su due fronti che non vogliono assumersi responsabilità, e i rimborsi spesso richiedono mesi.

Io stesso sto avendo un’esperienza negativa con un coupon comprato a fine 2011 che deve essere ancora rimborsato: il customer care ad ogni telefonata rassicura sull’imminente restituzione del credito, ma alla scadenza della data promessa non succede niente.

Possibili miglioramenti

I siti di social shopping stanno indirizzandosi verso una strada sempre più globale: aumentano i prodotti venduti esclusivamente online, e salvo rare eccezioni sono poche le offerte geolocalizzate. Siamo sicuri che sia questa la via giusta? Per una crescita che non potrà continuare all’infinito, una svolta potrebbe essere data puntando più sugli annunci locali.

Anche sul lato tecnico i siti presi ad esempio potrebbero decisamente migliorare.

Groupon oltre ad avere un’interfaccia poco innovativa fa un esagerato uso di JavaScript anche dove non necessario. Il codice è tutto tranne che pulito ed ordinato, ma l’aspetto più incredibile è il peso delle pagine. Nel momento in cui scrivo la homepage pesa 2.5Mb (con la compressione dei file attivata, altrimenti sarebbero quasi 4Mb). Considerando il numero di visite giornaliere, quanto potrebbero migliorare le prestazioni del sito ed il risparmio di banda se il peso fosse anche solo dimezzato? Impensabile fare analisi di accessibilità in un contesto simile.

Con Groupalia non va molto meglio: c’è una maggiore cura dei dettagli dell’interfaccia ed il codice è più ordinato, ma anche qui abbondano i JavaScript (43 file diversi richiamati solo in homepage). Anche il peso delle pagine è sempre elevato con 1.6Mb (3.6Mb non compressi).

Siamo sicuri che non si possa fare di meglio? Certe realtà dovrebbero seriamente iniziare a preoccuparsi anche dell’ottimizzazione lato tecnico. I risultati non potrebbero che migliorare, mirando ad ottimizzare l’esperienza dell’utente e con una conseguente maggiore manutenibilità del codice.

Non capita spesso di leggere libri veramente utili. Per me è successo con Designing for emotion, il quinto libro pubblicato da A Book Apart che da tempo mi promettevo di leggere. Dopo averlo acquistato, non gli ho mai dedicato la giusta attenzione, fino a quando l’ho visto citare durante una presentazione all’Agile UX Camp. Questo mi ha convinto a trovare il tempo per leggerlo, ed ora sono decisamente contento di averlo fatto.

Se un testo come Responsive Web Design mi aveva lasciato molto soddisfatto dal punto di vista tecnico, Designing for emotion ha un approccio totalmente diverso: non si parla di HTML e CSS, perché l’oggetto della discussione è molto più teorico. Se volete capire come catturare l’attenzione dei vostri utenti, offrire loro qualcosa di unico e non riciclare le solite esperienze di navigazione viste altrove, qui troverete molti spunti interessanti. Ci sono riferimenti alla psicologia e non mancano casi studio degni di nota: lo stesso autore, Aarron Walter, è l’UX designer di MailChimp e nel testo riporta vari casi studio relativi al proprio progetto.

Una delle parti che ho apprezzato particolarmente è all’interno degli ultimi capitoli: una guida pratica per convincere il proprio capo / cliente ad adottare la filosofia illustrata nel testo. Se vi è mai capitato di leggere un libro tecnico pensando che non sarebbe mai stato possibile applicarlo nella vostra realtà quotidiana, in questo caso vi vengono messi a disposizione una serie di suggerimenti per risolvere il problema. Non è un’approccio comune, e mi è piaciuto vedere una tale attenzione ai dettagli: quelle contenute nel testo non sono indicazioni fini a se stesse.

Se volete avere un’idea parziale degli argomenti trattati all’interno di Designing for emotion, trovate un estratto del capitolo 3 su A List Apart: Personality in Design. All’interno di questo stesso capitolo c’è un documento molto interessante che guida alla realizzazione di Design Personas per i vostri progetti: potrebbe valere la pena spendere un po’ di tempo per capire la personalità del vostro sito, e sfruttarla per dare coerenza alle interazioni con gli utenti.

I contenuti di Designing for emotion

1. Emotional Design
2. Designing for Humans
3. Personality (estratto in inglese – estratto in italiano)
4. Emotional Engagement
5. Overcoming Obstacles
6. Forgiveness
7. Risk and Reward

I difetti di questo libro? Devo ammetterlo, faccio fatica a trovarne. Probabilmente l’unico è che essendo un testo uscito un anno fa ha un paio di esempi già vecchi (ad esempio i riferimenti al nuovo Twitter), ma questo è inevitabile quando si parla di web. Le indicazioni presenti sono comunque valide.

Qualcuno forse potrebbe trovarlo troppo teorico, ma quello trattato non è un argomento da tutorial tecnici di cui fare copia-incolla. Se siete interessati a comunicare qualcosa tramite un sito web, è una lettura che vi consiglio senza esitazione.

Gumroad è una startup che in pochi passi si propone di risolvere il problema:

• Ti registri su gumroad.com
• Inserisci il nome del prodotto che vuoi vendere ed un link
• Fissi il prezzo
• Diffondi il link di acquisto

Se tutto va come previsto, ogni mese Gumroad pagherà via Paypal, trattenendo una commissione (pari al 5% + 0.30$ per ogni acquisto).

La procedura di acquisto

Gumroad sembra una buona soluzione per vendere prodotti senza doversi preoccupare dell’esperienza di acquisto dell’utente. La procedura infatti è semplicissima:

1. pagina di acquisto

2. inserimento dati della carta di credito

E i difetti?

Il problema principale è uno: Gumroad non offre nessuna protezione o garanzia sul link di acquisto del prodotto. Niente vieta ad un utente di comprare e poi condividere il link con amici e parenti.

Parlando di beni digitali, in ogni caso il problema resterebbe anche se il link fosse dinamico. Nessuno potrebbe impedire ad un acquirente di condividere tramite altri mezzi il bene appena acquistato.

Io valuterò seriamente l’uso di questo servizio: vendere foto, temi WordPress, script o elementi grafici non è mai stato così facile, e la commissione è decisamente inferiore a quella di altri servizi come ThemeForest. Certo, qui non esiste un network all’interno del quale farsi conoscere, ma sono due servizi differenti per esigenze diverse. Avere una nuova possibilità a disposizione è sempre positivo, considerando che è la creazione di un 19enne: Sahil Lavingia.