Come è nato April Zero: parte 2

Come è nato April Zero

Parte 2

Il mio processo di design è diverso ogni volta.

Per theory11 mi sono messo nella testa giusta facendo giochi di magia agli sconosciuti per le strade di Los Angeles. Lo styleguide di Quizlet mi è venuto in mente mentre mi lanciavo con il paracadute sopra le Hawaii, guardando in caduta libera l’acqua blu, la sabbia beige e le onde bianche. La combinazione di colori del mio sito precedente l’ho presa in prestito da una Ducati rossa.

E la nascita di questo sito è stata una strada ancora più tortuosa, fatta di avventure in giro per il mondo, gadget nuovi ed esperimenti su me stesso. Tutto per ricerca & sviluppo, ovviamente.

Dopo aver provato per qualche mese un mucchio di app e di dispositivi, avevo scelto lo stack definitivo, quello con il rilevamento più automatico possibile e il minimo impegno di tempo.

• App Moves per iPhone: per i dati sulla posizione
• App Cardiio per iPhone: per il battito cardiaco
• Instagram: per le mie foto
• App Runkeeper per iPhone: per registrare le mie corse
• Bilancia wireless Withings: per il peso di ogni giorno
• Misuratore di pressione Withings: battito e pressione
• Ecografo Bodymetrix: per la percentuale di grasso corporeo
• Esami del sangue mensili: per trigliceridi e livelli di nutrienti

Maggio 2014: Thailandia

Stavo viaggiando per l’Asia con Dustin Curtis, buttando giù idee per la versione mobile del sito. Cercavo qualcosa che sfruttasse il contesto del telefono, qualcosa che mi tornasse utile ogni giorno mentre ero in giro.

Volevo evitare di creare una cosa da guardare una volta e poi dimenticare. Volevo che cambiasse di continuo e si aggiornasse in tempo reale, mettendo in evidenza la cosa più importante in quel momento: un posto nuovo, un avviso sul battito cardiaco alto, o semplicemente una visione generale dei livelli di salute.

Volevo progettare per quel futuro vicinissimo in cui tutti questi dati saranno disponibili di continuo, ignorando qualche limite del presente. Oggi questi numeri non si aggiornano in continuazione: il peso una volta al giorno circa, i valori del sangue solo una volta al mese, e il battito solo quando lo misuro, qualche volta al giorno.

Prevedo che entro pochi anni, se non prima, arriveranno dispositivi capaci di rendere questi dati molto più automatici e continui. Se non ci arriva Apple o qualche altro grande nel giro di un anno, ci arriverà qualcuno su Kickstarter.

Un’esperienza mobile che mi entusiasmava era una sovrapposizione in realtà aumentata con tutti i miei parametri vitali. L’immagine della fotocamera poteva essere sfocata per creare l’illusione che il telefono fosse trasparente, con le informazioni su livelli diversi sopra. Alla fine nel browser non si poteva fare, ma un giorno potrei riprendere l’idea sotto forma di app.

Mi entusiasmava poter vedere tutte le informazioni al volo dal telefono, e continuavo a provare a far stare tutto in un’unica dashboard intuitiva.

Scuola di immersione

Sono finito a Koh Tao, una piccola isola sulla costa orientale della Thailandia. Era famosa per le immersioni, quindi ho deciso di prendere il brevetto.

Di giorno andavo a scuola di immersione, di notte facevo nuovi mockup per il mobile. Collegavo Photoshop sul Macbook a Skala Preview sull’iPhone per vedere ogni disegno nel suo contesto. Prendevo il telefono e camminavo in giro con ogni pagina aperta, per capire che effetto facesse.

Mi ha aiutato a risolvere tanti dettagli di design, come la scala e la leggibilità. “Quanto posso rimpicciolire il testo?” “Quanto contrasto mi serve per leggere all’aperto?” “Quante informazioni posso far stare in una schermata?”

Gli anelli che ruotavano appena in alto richiamavano la versione desktop e davano un po’ di carattere. All’inizio erano troppo forti, quindi ho continuato ad abbassare opacità e colori finché non si notavano quasi più.

Andavo in giro con gli screenshot sul telefono e li facevo vedere alle persone intorno a me.

“Secondo te cosa ti sta dicendo questa pagina?” “Dove toccheresti?”

All’inizio le persone facevano fatica a raccapezzarsi tra tutte le cose stipate nella pagina. Dan non sapeva quale colonna guardare per prima. Dustin si lamentava che fosse tutto troppo piccolo. Tutti gli altri sulla barca probabilmente si chiedevano perché mi fossi portato il portatile.

Ho capito che l’idea di far stare tutto nella pagina non poteva funzionare, e ho iniziato a ridurla ai soli dati più importanti.

Quando eravamo a Bangkok siamo andati in qualche ospedale per provare a farci una risonanza magnetica total body a poco prezzo, ma erano troppo care, più di qualche migliaio di dollari. Nel frattempo, però, mi ero affezionato all’idea di avere una vista medica completa di me stesso, e ho deciso di metterla nella pagina per dare un tono più clinico e scientifico. Per iniziare ho usato una foto stock di una persona qualunque, con l’idea di sostituirla più avanti con una mia vera.

Mi piaceva molto l’effetto della sezione del corpo umano, soprattutto rispetto a qualcosa di più banale come la mappa. Bastava un’occhiata alla pagina per farsi un’idea di cosa stesse succedendo, e i dati erano lì, disponibili guardando meglio le barre e i numeri. Con delle belle animazioni sarebbe stato ancora meglio. Volevo che fosse chiaro che quello era un collegamento in tempo reale con una persona viva, non solo l’ennesima serie di grafici medici noiosi. Dovevo evitare la trappola delle decine di grafici a torta & a ciambella generici in cui cadono tante app.

Volevo raccontare una storia, non solo mostrare un mucchio di misure mediche.

A quel punto il design iniziava a entusiasmarmi. Il battito cardiaco sarebbe stato bellissimo una volta caricati i dati in tempo reale. Non ero sicuro che l’animazione della risonanza fosse possibile, ma questo era il primo design mobile che finalmente mi sembrava all’altezza dell’esperienza desktop.

Era pronto per essere scritto in codice. Mentre scendevamo verso sud in Malesia, ho passato i giorni successivi a costruire le animazioni.

Dopo qualche giorno di prove ho capito come simulare la scansione e il bagliore della risonanza in CSS. Ho aggiunto un breakpoint intorno ai 600px e ho iniziato a lavorare al layout mobile direttamente nel browser. Quando ci siamo avvicinati al risultato, l’ho caricato sul telefono dall’indirizzo IP del computer per testare e ottimizzare direttamente sull’hardware dell’iPhone.

Con il mobile finalmente risolto, era ora di tornare a finire l’esperienza desktop di Explorer.

La versione precedente era bellissima, ma era un sovraccarico di informazioni. Dovevo capire come mostrare la mia attività quotidiana in modo più compatto e comprensibile. Sospettavo che la soluzione stesse in più livelli di navigazione, riducendo ogni timeline a una versione più semplice fino a quando non si chiedono i dettagli di quel giorno.

Faccio fatica a ragionare a stomaco vuoto, quindi ho deciso che prima mi sarei riempito di sushi e poi avrei trovato il design definitivo.

Giugno 2014: Giappone

Colazione a Tsukiji

Sono atterrato a Tokyo la mattina dopo e sono andato dritto al mercato del pesce di Tsukiji, la casa del pesce più fresco del mondo.

Dopo un mese di viaggi su barche che sballottavano e treni lentissimi, muoversi con la metropolitana giapponese, puntuale ed efficiente, è stato fantastico. Volevo che il mio sito desse la stessa sensazione: clicchi in giro, arrivi in posti nuovi e sei sicuro che non andrà storto niente. Sarebbe stato veloce e pulito. Tutti i tempi perfetti al millisecondo.

Un’ora dopo ero ispirato, non più affamato e pronto a finire il design del sito.

Ho sistemato una piccola scrivania in hotel e mi sono messo al lavoro. Ho deciso di partire dal mobile e poi salire di dimensione, per essere sicuro di non inventare qualcosa di assurdo che non avrebbe mai funzionato in piccolo.

Avevo passato tutto il mese precedente a discutere con me stesso su che direzione dovesse avere il tempo sul mobile. L’attività più recente doveva entrare dall’alto? Era così che funzionavano quasi tutti i feed, tipo Facebook o Twitter. Oppure doveva essere in ordine cronologico, come un calendario, a partire dal primo giorno?

Il problema è che non c’era una risposta giusta. Era insieme un flusso in tempo reale della mia attività e un calendario di quello che avevo fatto. Ognuno dei due chiedeva il design opposto, ma potevo sceglierne uno solo.

Dopo aver simulato un sacco di dati veri in tutti e due i modi, ho capito che più spesso mi aspettavo l’ordine cronologico e che altrimenti fraintendevo la pagina.

Alla fine ho deciso che ogni pagina del mese sarebbe partita dalla mezzanotte del primo giorno. I contenuti più recenti in fondo, i primi in alto.

Stavo usando Google Maps per muovermi ed ero ispirato dal loro design mobile. La loro timeline dei percorsi è sempre pulita e affidabile.

Per ottenere una sensazione simile dovevo eliminare buona parte dei dati che cercavo di stipare nei margini. Per l’esperienza mobile contavano più la semplicità e la facilità d’uso che avere tutte le informazioni in una sola vista.

Avevo cercato di inventarmi modi ingegnosi per mostrare alba e tramonto, le foto della giornata e così via. Erano bei dati, ma aggiungevano troppa complessità. La nuova versione era molto più semplice: solo l’elenco dei posti che avevo visitato.

Ho aggiornato i contenuti con l’attività della giornata e ho cancellato quasi tutto il resto. Non conteneva molte informazioni, ma iniziava a sembrare molto più pulita. Finalmente era una cosa che potevo usare con comodità sul telefono o condividere con altri.

Più tardi, quello stesso giorno, Apple ha annunciato HealthKit al WWDC. Non era all’altezza di quello che mi aspettavo, non c’era nessun dispositivo rivoluzionario ad accompagnarlo, ma da quel momento l’orologio aveva ufficialmente iniziato a correre.

Il tono clinico e medico del loro design mi ha anche fatto capire quanto fosse importante Explorer, più di quanto avessi immaginato all’inizio. I dati sui luoghi e sui viaggi avrebbero dato contesto e significato a quella che altrimenti sarebbe stata solo una raccolta di dati scollegati, pura curiosità.

Mi restavano pochi giorni in Giappone prima di tornare a casa a costruire e lanciare questa cosa. In fondo, i veri artisti spediscono.

La cerimonia del tè

La mattina dopo sono andato a fare una lunga corsa nel parco. Volevo schiarirmi le idee e lasciare spazio all’ispirazione. Dopo aver letto di HealthKit, avevo la testa piena di idee folli su come trasformare il fitness in un gioco o prevenire gli infarti con un algoritmo.

Poi ho deciso di andare a vedere una cerimonia del tè tradizionale giapponese. Si teneva in un giardino bellissimo, circondato da uno stagno di carpe koi e da tantissimo verde. Lì vicino una donna in kimono giocava con i pesci.

La prima portata era un piccolo dolce, servito su un sottobicchiere di legno esagonale. Mi ha ricordato un concept che avevo abbozzato tempo prima. Avevo praticamente rinunciato agli esagoni, perché non si potevano incastrare l’uno nell’altro come i rettangoli.

Cercavo invano un’intestazione riconoscibile da mettere in cima a ogni pagina del mese. I cerchi della versione precedente erano puliti ma poco memorabili e poco entusiasmanti. L’esperienza del tè mi ha fatto pensare che fosse il momento di riprendere in mano l’idea degli esagoni.

Mi entusiasmava il fatto che creasse un elemento visivamente interessante potendo comunque trasmettere tante informazioni. Visto che l’idea era così legata ai contenuti, era meglio iniziare a costruirla direttamente con i dati veri piuttosto che provare a fare un mockup preciso con centinaia di icone dinamiche.

Questa è stata la prima versione scritta in codice. Non era particolarmente bella, ma portava dentro i contenuti veri e definiva il layout di base degli elementi con cui avrei giocato.

Trasformare ogni elemento in un esagono è stata solo una semplice maschera CSS sull’immagine. Tutto l’insieme dei luoghi è stato manipolato appena nello spazio 3D per avere una prospettiva più interessante. Una leggera ombreggiatura sui bordi tiene il fuoco al centro.

Le categorie dei luoghi di Foursquare hanno fatto gran parte del lavoro pesante, creando una tassonomia di categorie e fornendo ottime icone per rappresentarle.

Ho impostato dei codici colore per distinguere i posti a colpo d’occhio, e sono venuti fuori gli schemi di ogni mese. La natura e i parchi sono verdi, gli aeroporti e le stazioni verde acqua, i ristoranti e i bar quasi tutti arancioni, le case e gli hotel di un grigio discreto.

I mesi in cui ho fatto molte immersioni sono pieni di verde. Quando ero a New York c’è un sacco di rosso per i ristoranti italiani. Il viaggio in Giappone ha tantissimo rosa per il sushi.

Con la parte alta della pagina disegnata e scritta in codice, dovevo capire come riempire le timeline sotto. I dati c’erano tutti, andavano solo presentati come si deve.

Perso a Roppongi

Stavo tornando in ritardo dalla casa del tè. Avevo perso la cognizione del tempo mentre provavo a esercitarmi con il giapponese con la donna in kimono. Dovevo fare il check-out dal Park Hyatt Tokyo entro meno di un’ora, ma ero dall’altra parte della città. Secondo Google Maps ci volevano 43 minuti di metropolitana.

Ho preso il treno verso la stazione di Azabujuban ed ero in viaggio. “Andrà tutto bene”, mi dicevo. “Di solito faccio la valigia in meno di 5 minuti.”

Una volta sul treno mi sono distratto cercando una didascalia spiritosa per la mia foto su Instagram, e quando ho alzato gli occhi la mia fermata stava passando in quel momento. Ops. Sono sceso alla successiva: Roppongi.

Fissavo la mappa cercando di capire se tornare indietro o andare avanti, arrabbiato con la metropolitana che amavo tanto e che mi aveva tradito proprio quando ne avevo più bisogno. Ci ho messo un po’ a capire cosa stessi guardando davvero.

C’era una serie di luoghi, su una linea sottile con tantissimo testo. Tutte le etichette erano leggermente inclinate. Cerchi enormi e coloratissimi distinguevano le zone. Era esattamente quello che stavo cercando!

Questo modo di mostrare le informazioni su una linea del tempo è stata l’ultima ispirazione che mi serviva per finire il design di Explorer 2.0. Le etichette inclinate risolvevano il mio problema di sovrapposizione, e i cerchi grandi e decisi si sarebbero capiti anche in forma compatta.

Volevo tenere metà pagina per riportare altri dettagli della giornata, usando i luoghi qui sopra come contesto per capire quando e dove fossero successi. Ho giocato con l’idea di far riempire lo spazio rimasto da una mappa.

C’erano tante cose che volevo riportare per ogni giornata: sonno, cibo, spostamenti, umore, glicemia e altro. Per il momento avrei usato i dati a cui avevo accesso facilmente e che variavano di più da un giorno all’altro: spostamenti, commit su GitHub e battito cardiaco.

Colorare i nomi dei luoghi mi ha permesso di distanziarli meglio mantenendo un legame visivo forte con le icone colorate.

Ho giocato con l’idea di mettere una mappa sullo sfondo. Visivamente mi piaceva molto la ricchezza che aggiungeva. Diventava però troppo confusa quando ci mettevo sopra dati che non c’entravano.

Al posto della mappa ho provato uno sfondo sfocato di foto di Instagram. Dava a ogni giornata uno sfondo unico e interessante per i suoi dati. La cronologia dei commit e dei deploy su Github avrebbe riempito i buchi nei tanti giorni in cui non facevo altro.

Dopo giorni di progressi lenti e di prove, letteralmente cercando la risposta in giro per il mondo, all’improvviso tutto si è incastrato. Ho capito che era quella giusta nel momento esatto in cui ho aggiunto l’ultimo livello.

La fase di design era finalmente finita. Era ora di iniziare a costruire.

Luglio 2014: San Francisco

Fino a quel momento avevo rimandato il problema di come costruire davvero questa cosa & di che stack tecnologico scegliere. Volevo passare tutto il tempo sul design e sul frontend senza farmi distrarre dall’infrastruttura o dal codice. Restare sul semplicissimo Jekyll per il prototipo è stato essenziale per andare veloce e provare tante idee. Avere tutto statico mi permetteva di mettere da parte facilmente le versioni interessanti per riguardarle dopo.

Il mio vicino di casa sponsorizzava Node. Un mucchio di gente mi diceva di usare Rails. In passato avevo usato Django e mi ero trovato bene. Sapevo che il linguaggio in fondo non contava molto: dovevo solo sceglierne uno e iniziare a scrivere.

Ho passato un giorno a giocare con Ruby on Rails. In tanti me lo avevano consigliato. Sembrava una scelta solida per coinvolgere altri sviluppatori più avanti. Dopo un’ora passata a far girare & pubblicare l’esempio Hello World, ho capito che stavo andando troppo piano. Dovevo passare tutto il tempo a costruire cose, non a imparare le sottigliezze di un nuovo framework.

Ho scelto Python e Django, che avevo già usato tanto tempo prima per costruire una startup di analytics. Heroku rendeva il deploy e la gestione dei server molto più semplici di quanto fossi abituato con AWS. Nel giro di pochi minuti il sito era online. Nel giro di poche ore avevo tutti gli URL delle pagine collegati a template vuoti. Nel giro di pochi giorni quasi tutti i modelli giravano e importavano dati da varie API. Ora sì che si ragionava.

Quasi tutti i servizi con cui volevo integrarmi avevano belle API OAuth 2.0 con una buona documentazione, quindi è stato sorprendentemente facile collegare gli account e tirare fuori i dati che mi servivano. Ho impostato un job nello scheduler di Heroku che controllasse ogni 10 minuti se c’erano dati nuovi e in quel caso li importasse.

Il frontend

• SASS
• Compass
• CoffeeScript
• LiveReload
• jQuery
• PJAX
• jQuery Throttle
• D3

Il sito carica un file CSS globale e un file JavaScript globale. Questi file vengono messi insieme da tanti file SASS e Coffee più piccoli, per tenere tutto ordinato e modulare durante lo sviluppo.

In sviluppo uso l’app per Mac LiveReload per ricaricare il sito all’istante ogni volta che cambio il CSS o il JavaScript. Fa risparmiare qualche secondo a ogni modifica, cosa utilissima quando si itera migliaia di volte.

Il backend

• Python
• Django
• Postgres
• Memcached
• Heroku

Heroku ha delle guide utili per configurare il loro stack. Il deploy è davvero semplice: basta un “git push heroku master” e le modifiche sono online. Faccio push su GitHub spesso, e su Heroku quando voglio pubblicare.

Per un po’ mi preoccupavano le prestazioni sulle pagine con query pesanti, ma Memcached mi ha salvato. Visto che il sito era così statico & cambiava solo quando venivano importati nuovi dati, sono riuscito a mettere in cache quasi ogni template & a servirlo all’istante.

Rush finale

Il processo di design guadagna dai cambi di prospettiva e dalle interruzioni frequenti. A volte le cose mi si chiariscono nel mezzo di una conversazione, o dopo aver notato qualcosa per strada.

Quando sviluppo, però, ogni tanto mi piace avere giornate senza interruzioni per concentrarmi e tenere migliaia di righe di codice in testa. Tutti e due i miei coinquilini erano via per una settimana, quindi avevo pace e silenzio.

Con i design definiti e i dati che arrivavano, mi restava solo una lunga lista di bug e di problemi di prestazioni da risolvere prima del lancio. Ho deciso che mi sarei chiuso in camera finché questa cosa non fosse stata online.

Rimbalzavo avanti e indietro tra il frontend e il backend, aggiungendo altri dati veri alla pagina e poi ripulendola.

Quando costruisco qualcosa in CSS, lavoro prima al layout con stili semplicissimi. L’obiettivo è mettere ogni cosa al posto giusto, non farla venire bella. Il primo passo è assicurarsi che il backend sputi fuori tutto quello che mi serve. Voglio togliermelo di mezzo e poi poter passare tutto il tempo nello stesso file CSS. Tutto prende un background: red o un background: blue giusto per verificare che i selettori funzionino. Poi lavoro al layout e al posizionamento, pensando a cose come la responsività e i casi limite. Quando quelli sono a posto, di solito creo un nuovo foglio di stile per riempire tutti i dettagli di design e far venire le cose belle.

Usare gli stessi colori e le stesse icone degli esagoni qui sopra rendeva facilissimo farsi un’idea dei tipi di luogo di una giornata. Casa si ripeteva di continuo ma non era particolarmente interessante, quindi l’ho resa più discreta per far risaltare gli altri posti: cerchi bianchi invece che blu.

Ora tutte le etichette erano nascoste, e ogni timeline era più semplice e leggera. Cliccando su un giorno si apriva e mostrava altre informazioni.

La prima cosa che ho aggiunto sono stati i dati sugli spostamenti, che collegavano i luoghi tra loro a piedi, di corsa, in auto e così via. Era tutto posizionato in modo assoluto, quindi potevo collocare ogni elemento in base all’ora di inizio e di fine.

Le foto sfocate di Instagram davano alle giornate sfondi più interessanti e vari su cui mostrare i dati. Poi ho aggiunto i dati reali del battito cardiaco per ogni giornata.

Un po’ di stile inizia a tenere insieme la pagina. Tra un posto e l’altro nascono degli archi che mostrano il tipo e la durata dello spostamento. Le cose noiose come camminare sono piccolissime, mentre una bella corsa o un volo hanno colori accesi e si notano subito.

Sulla destra è riservato un po’ di spazio per la città e per la navigazione ai giorni precedente e successivo.

Certe giornate avevano tanto spazio vuoto: sembrava che fossi rimasto a casa o a dormire tutto il giorno. I commit su Github riempiono i buchi rimasti nel racconto e mostrano quando stavo lavorando e a cosa.

Le pagine dei mesi

Ora che ogni giorno & ogni mese aveva la sua pagina, ho iniziato a lavorare all’elenco dei mesi e alle animazioni per spostarsi tra le pagine.

All’inizio i mesi erano in una lista verticale, con i dettagli sulle città e sui tipi di posti visitati. Anche le foto migliori del mese aiutano a farsi un’idea di quello che era successo.

Pensata all’inizio come versione mobile responsive, ho capito che trasformare ogni mese in un modulo sarebbe stato più bello di una vista a lista. Ogni mese sarebbe sembrato più cliccabile, come un oggetto con cui interagire.

Mapbox

Volevo uno sfondo discreto con il terreno e le strade, per dare contesto alle mie corse. Google Maps è straordinario, ma volevo qualcosa di un po’ più personalizzabile, quindi ho deciso di provare Mapbox. Il servizio sembrava un po’ caro, ma la configurazione è davvero semplice e ho pensato che valesse la spesa per avere una homepage più bella con delle belle mappe.

Runkeeper fornisce una serie di coordinate GPS ogni 5 secondi durante la corsa. Ho usato la libreria javascript di Mapbox per creare una linea SVG a partire da quei punti. All’inizio temevo di dover scrivere codice complicato per animare la linea che cresce dall’inizio alla fine, ma è venuta fuori una semplice transizione CSS con le proprietà stroke-dash. In questo esempio, riducendo l’offset a 0 la linea si scopre poco a poco.

path.line {
	/* Assuming a stroke length of 100px */
	stroke-dasharray: 100px;
	stroke-dashoffset: 100px;
	transition: all 500ms ease;
}

path.line.loaded {
	stroke-dashoffset: 0;
}

L’ora della critica

Ogni sera Stammy tornava a casa dal lavoro e passavamo in rassegna le nuove funzioni e le modifiche. Mandavo anche link o screenshot a Yuri, Dustin e ad altri amici quando mi bloccavo o mi serviva un secondo parere. Avere il punto di vista di altre persone e far vedere il progetto a occhi freschi con regolarità aiuta tantissimo. Molte idee sono nate da discussioni o come risposta a un commento su qualcosa che non convinceva del tutto.

Ricevere commenti non vuol dire fare tutto quello che ti dicono, o togliere le cose che non piacciono. Un commento ti dice se quello che hai fatto ha senso o funziona, non cosa fare o quale debba essere la visione. La visione non si può affidare alla folla. Un progetto pieno di toppe e di trucchetti messi lì per ogni lamentela di solito diventa difficile da far crescere e da mantenere.

Un commento forte è di solito un buon segno, anche quando è negativo: vuol dire che la persona era abbastanza coinvolta da appassionarsi. In realtà capita di rado. Se i commenti di tutti sono vaghi o non hanno niente da dire, di solito è un brutto segno e indica un design che non ispira. Se lo odiano tutti, può essere pessimo o geniale: a volte è difficile capirlo.

È importante raccogliere commenti di continuo, ma senza mollare tutto o buttare via l’idea intera al primo commento negativo. Di solito metto le cose da parte per la revisione successiva, a meno che non ci sia un problema catastrofico che obbliga a ricominciare da capo.

Per esempio, nella revisione attuale mi è arrivato un sacco di feedback sul fatto che gli archi degli spostamenti non si capiscono. Non aveva senso rimandare il lancio per sistemarli, ma la prossima versione che rilasceremo avrà un approccio diverso.

Vale anche la pena raccogliere commenti da tipi di persone diverse, soprattutto da chi è meno tecnico o non è abituato a interfacce simili. Può essere frustrante, ma anche illuminante, vedere quanto diversamente ragionano e interagiscono certe persone. Per questo mi piace tanto testare nei bar o con perfetti sconosciuti: si scoprono cose affascinanti, e cose che sembravano ovvie ma per gli altri non hanno senso.

Anche il design più rifinito e più ragionato avrà qualche spigolo e trarrà vantaggio da un test approfondito.

Le chat head

I moduli di contatto sono roba da 2006. Volevo un modo divertente per interagire con chi passa di qui. La mia teoria era che molte persone hanno qualcosa da dire, ma quasi tutte si intimidiscono davanti a un modulo di contatto dall’aria ufficiale. Io di solito sì.

Volevo che fosse divertente, amichevole e umano, anche se lo stile visivo del resto del sito era piuttosto futuristico e automatizzato. Volevo un sito bello, ma non al punto da intimidire le persone.

Usavo le chat head di Facebook per parlare con le persone ogni giorno. Erano un design & un modo di comunicare molto naturali. Volevo un’interazione simile qui, una a cui quasi tutti fossero già abituati. In futuro potrei perfino far parlare le persone con me in tempo reale via Messenger, usando il sito come client di chat.

La pagina about

Questo progetto si appoggiava a tanti altri software e dispositivi. Volevo un buon modo per dare a tutti il giusto credito e mostrare gli strumenti che uso. Ho deciso di fare una semplice sequenza “powered by” con i loghi di tutti i partner, con nome e contributo visibili al passaggio del mouse.

Ho aggiunto qualche numero sui burrito per rendere il tutto più divertente e personale, non solo una dashboard medica. Perché a chi non piacciono i burrito?

Alimentato a zucchero

Verso la fine consumavo quantità enormi di zucchero per restare concentrato e lavorare tutta la notte. Faceva malissimo al mio corpo, ma mi permetteva di pensare lucidamente per qualche ora e risolvere quasi ogni problema. Più il problema è difficile, più zucchero mi serve per venirne a capo.

11 luglio 2014

Il giorno del lancio

Era venerdì. Il sito era quasi pronto, quindi ho deciso di andare da Alex per gli ultimi ritocchi. Per queste cose è sempre meglio avere un secondo paio di occhi, e avere lì uno dei massimi esperti mondiali di Javascript non guasta.

La mia lista di cose da fare era ormai fatta di piccole rimanenze: collegare le chat head perché mandassero davvero i messaggi, aggiungere i pulsanti di twitter, sistemare le meta description, scrivere il primo articolo, aggiornare gli asset sul CDN, decidere il tweet di lancio e così via.

Nelle poche ore in cui siamo stati lì a lavorare, lui ha fatto un’estensione per Chrome che metteva il nostro contatore dell’età come schermata iniziale.

Abbiamo discusso brevemente se il venerdì sera fosse troppo tardi per lanciare, o se avesse più senso aspettare il lunedì, quando tutti sarebbero tornati davanti al computer. Sarebbe stato saggio aspettare ancora qualche giorno, ma a quel punto ero esausto dopo una settimana di codice ininterrotto a base di adrenalina e mi sembrava che fosse ora o mai più.

Ho cambiato qualche impostazione DNS, ho pubblicato un tweet, ed eravamo online!

Visto che era venerdì sera, quasi tutte le prime visite arrivavano da telefono. Io avevo passato quasi tutto il tempo a usare la versione desktop, ma la maggior parte delle persone stava vivendo la versione mobile, quella di base.

Per fortuna verso la fine avevo dedicato tanto tempo al design responsive. Sembrava piacere a tutti e la condividevano direttamente dal telefono. Se dovessi rifarlo, dedicherei più tempo all’esperienza mobile, sapendo che è il primo e spesso l’unico modo in cui molte persone la vivono.

Sembrava filare tutto liscio finché non mi è arrivato un DM di Stammy che diceva che pesavo 1517 libbre. Cosa piuttosto strana, visto che mi sentivo molto più leggero.

Non toccavo il codice della pagina Sport da parecchio, quindi non poteva essersi rotta all’improvviso. Guardando il sorgente della pagina, il valore grezzo aveva una virgola al posto del punto: 151,7 invece di 151.7. Javascript ignorava la virgola e lo interpretava male. Ho svuotato la cache e la pagina è tornata normale. Strano…

Più tardi quella sera ero in un bar a far vedere il sito a un amico sul telefono quando ho notato che uno dei titoli delle pagine era in russo. Assurdo. Ho collegato subito la cosa al bug di prima: tutti e due dovevano essere causati da qualche codice di internazionalizzazione impazzito.

Ovviamente sono dovuto tornare a casa a indagare.

È venuto fuori che dipendeva da una semplice impostazione di Django, con l’internazionalizzazione (di solito abbreviata in i18n) attiva per cose come numeri e date. Insieme al sistema di cache, alcune sezioni venivano corrotte dopo essere state richieste dall’estero. Disattivare quella funzione è stata una correzione di una riga e ha garantito un’esperienza uguale per tutti nel mondo.

È solo uno dei tanti casi in cui un indizio piccolo e oscuro segnala un bug da qualche parte che va scovato.

Quella notte mi sono addormentato esausto ma contento, dopo una lunga settimana di lavoro. Il sito era finalmente online e qualche migliaio di persone lo aveva visto dal mio tweet. Mi sarei rilassato per il fine settimana e poi la settimana dopo avrei capito come iniziare a farlo conoscere al mondo. È venuto fuori che non sarebbe servito…

La mattina dopo

Nel giro di poche ore, mentre dormivo, la gente lo aveva pubblicato su Reddit, Hacker News e in giro per tutta internet. Avevo un appuntamento per correre con un amico alle 7 del mattino, quindi mi ero svegliato presto, cosa insolita per me. Per fortuna.

Il telefono esplodeva di notifiche. Qualche centinaio di tweet, un mucchio di email. Ho provato a caricare il sito ed era lentissimo. Ho guardato le statistiche: il traffico era schizzato alle stelle nelle ultime ore e il sito era quasi bloccato dal carico. Per fortuna scalare con Heroku era abbastanza semplice, e sono passato da 2 a 8 dyno. Con abbastanza server per reggere quel traffico assurdo, tutto è tornato a caricarsi all’istante.

Nel giro di un paio d’ore il sito ha superato i centomila visitatori. Nel pomeriggio, duecentomila. A quanto pare piaceva. I tweet e i messaggi continuavano ad arrivare!

Vedere persone di ogni tipo commentarlo e condividerlo mi ha reso davvero umile, soprattutto perché non ero sicuro che qualcuno l’avrebbe capito o gli sarebbe piaciuto. Qualche tweet in particolare mi ha fatto la giornata, da persone che stimo moltissimo.

Ho notato che centinaia di persone facevano più o meno le stesse domande:

• Come hai fatto le animazioni?
• Che tecnologie stai usando?
• Come fai a conoscere i valori del tuo sangue?
• Come posso averlo anche io?

Dopo aver risposto alle prime 10 o 20, ho capito che dovevo raccontare tutta la storia dall’inizio alla fine. Era un percorso troppo bello per non condividerlo con il mondo. Avevo centinaia di vecchi schizzi, mockup e prototipi che nessuno aveva mai visto.

Ed è così che è nato questo post…

Epilogo

Avevo progettato il sito soprattutto come il mio giocattolo personale. Sapevo che era il futuro, ma non ero sicuro che qualcun altro avrebbe trovato che valesse la fatica quotidiana di raccogliere tutti questi dati. Sembra però che almeno qualcuno fosse molto interessato. Dopo il lancio ho ricevuto centinaia di messaggi di persone che chiedevano come averlo anche loro.

Qualche mese dopo ho deciso di fondare un’azienda che si chiama Gyroscope. Ora è in piedi e funziona: chiunque può iscriversi e iniziare a tenere traccia della propria vita.