Hoe April Zero is gemaakt
Deel 2

Mijn ontwerpproces verloopt elke keer anders.
Voor theory11 kwam ik in de juiste stemming door goochelkunstjes te doen voor vreemden op straat in LA. De styleguide voor Quizlet bedacht ik tijdens het parachutespringen boven Hawaï, toen ik in vrije val het blauwe water, het beige zand en de witte golven zag. Het kleurenschema van mijn vorige site heb ik geleend van een rode Ducati.
En deze site kwam via een nog veel grilliger route tot stand, met avonturen over de hele wereld, nieuwe apparaten en experimenten op mezelf. Allemaal voor onderzoek & ontwikkeling, uiteraard.
Nadat ik een paar maanden allerlei apps en hardware had getest, koos ik de definitieve set die het meest automatisch meet en de minste tijd kost.
- Moves iPhone-app, voor locatiedata
- Cardiio iPhone-app, voor mijn hartslag
- Instagram, voor mijn foto's
- Runkeeper iPhone-app ‐ om mijn runs bij te houden
- Withings draadloze weegschaal, voor mijn dagelijkse gewicht
- Withings bloeddrukmeter, hartslag en bloeddruk
- Bodymetrix-echo, voor mijn vetpercentage
- Maandelijkse bloedtesten, voor triglyceriden en voedingsstoffen
Mei 2014: Thailand
Ik reisde door Azië met Dustin Curtis en schetste ideeën voor de mobiele versie van de site. Ik probeerde iets te bedenken dat de mobiele context zou benutten, iets waar ik onderweg elke dag wat aan zou hebben.
Ik wilde niet iets maken dat je één keer bekijkt en daarna vergeet. Ik wilde dat het voortdurend zou veranderen en in realtime zou bijwerken, met steeds het belangrijkste van dat moment op de voorgrond: een nieuwe locatie, een waarschuwing over een verhoogde hartslag, of gewoon een algemeen beeld van hoe het met mijn gezondheid stond.

Ik wilde ontwerpen voor de nabije toekomst waarin al die data continu beschikbaar is, en de beperkingen van het heden een beetje negeren. Op dit moment werken die getallen niet continu bij: het gewicht ongeveer één keer per dag, de bloedwaarden maar één keer per maand, en de hartslag alleen als ik hem meet, een paar keer per dag.
Ik voorspel dat er binnen een paar jaar, en misschien eerder, nieuwe hardware komt die deze data veel automatischer en doorlopender maakt. Als Apple of een andere grote speler het niet binnen een jaar voor elkaar krijgt, doet iemand op Kickstarter het wel.
Eén mobiel idee waar ik enthousiast over was, was een augmented reality-laag met al mijn waarden. Het camerabeeld kon vervaagd worden zodat de telefoon doorzichtig leek, met de informatie op verschillende niveaus daarboven. Het bleek niet mogelijk in de browser, maar misschien pak ik het idee ooit nog op als app.
Ik vond het geweldig om alle informatie in één oogopslag op mijn telefoon te zien, en bleef proberen om alles in één begrijpelijk dashboard te passen.
Duikschool
Ik belandde op Koh Tao, een klein eiland aan de oostkust van Thailand. Het staat bekend om het duiken, dus ik besloot mijn brevet te halen.
Overdag ging ik naar de duikschool, 's avonds maakte ik nieuwe mobiele ontwerpen. Ik verbond Photoshop op mijn Macbook met Skala Preview op mijn iPhone om elk ontwerp in context te zien. Dan pakte ik mijn telefoon en liep ik rond met elke pagina open, om te voelen hoe goed het werkte.
Zo kwam ik achter een hoop ontwerpdetails, zoals schaal en leesbaarheid. “Hoe klein kan ik de tekst maken?” “Hoeveel contrast heb ik nodig om buiten te kunnen lezen?” “Hoeveel informatie past er in één scherm?”

De subtiel draaiende ringen bovenaan verwezen naar de desktopversie en gaven het karakter. In het begin waren ze te sterk, dus ik bleef de doorzichtigheid en de kleuren temperen tot ze nauwelijks opvielen.
Ik liep rond met screenshots op mijn telefoon en liet ze aan de mensen om me heen zien.
“Wat denk je dat deze pagina je wil vertellen?” “Waar zou je op tikken?”
In het begin konden mensen moeilijk wijs worden uit alles wat op de pagina gepropt zat. Dan wist niet naar welke kolom hij als eerste moest kijken. Dustin klaagde dat alles te klein was. De rest op de boot vroeg zich waarschijnlijk af waarom ik mijn laptop had meegenomen.
Ik besefte dat alles op de pagina proppen niet ging werken, dus ik begon terug te snoeien tot alleen de meest relevante cijfers.

Toen we in Bangkok waren, gingen we naar een paar ziekenhuizen om een goedkope MRI van mijn hele lichaam te laten maken, maar die bleken te duur, meer dan een paar duizend dollar. Ondertussen raakte ik erg gehecht aan het idee van een volledig medisch beeld van mezelf, en besloot ik dat aan de pagina toe te voegen om het klinischer en wetenschappelijker te laten aanvoelen. Ik begon met een stockafbeelding van een doorsneepersoon, met het plan om die later door een echte van mezelf te vervangen.
Ik vond die dwarsdoorsnede van een mens erg mooi, zeker vergeleken met iets algemeners als de kaart. Eén blik op de pagina gaf al een goed gevoel voor wat er speelde, en de data was zo bij de hand als je beter naar de balken en getallen keek. Met mooie animaties zou het nog beter worden. Ik wilde duidelijk maken dat dit een live verbinding met een levend persoon was, en niet zomaar een setje saaie medische grafieken. Ik moest de val vermijden waar veel apps in trappen, met tientallen algemene taart- en donutdiagrammen.
Ik probeerde een verhaal te vertellen in plaats van alleen een stapel medische metingen te laten zien.

Op dat moment begon ik enthousiast te worden over het ontwerp. Vooral hartslag zou gaaf worden zodra de data in realtime binnenkwam. Ik wist niet zeker of de animatie voor de MRI mogelijk was, maar dit was het eerste mobiele ontwerp dat eindelijk goed genoeg voelde naast de desktopversie.
Het was klaar om gebouwd te worden. Terwijl we zuidwaarts naar Maleisië gingen, werkte ik de volgende dagen aan de animaties.
Na een paar dagen experimenteren wist ik hoe ik het scannen en oplichten van de MRI in CSS kon nabootsen. Ik zette een breekpunt rond 600px en begon in de browser aan de mobiele indeling. Toen het in de buurt kwam, laadde ik hem op mijn telefoon via het IP-adres van mijn computer, om rechtstreeks op de iPhone te testen en te optimaliseren.

Nu mobiel eindelijk stond, was het tijd om terug te gaan naar de desktopversie van Explorer.

De vorige versie was mooi, maar veel te veel informatie in één keer. Ik moest een manier vinden om mijn dagelijkse activiteit compacter en begrijpelijker te tonen. Ik vermoedde dat de oplossing in meer navigatielagen zat, waarbij elke tijdlijn werd teruggebracht tot een eenvoudiger versie tot je meer details van die dag opvroeg.
Ik kan slecht nadenken op een lege maag, dus ik besloot me eerst vol te eten met sushi en daarna het definitieve ontwerp te bedenken.
Juni 2014: Japan
Ontbijt op Tsukiji
De volgende ochtend landde ik in Tokio en ging ik naar de vismarkt van Tsukiji, de plek met de verste vis ter wereld.
Na een maand reizen op hobbelende boten en trage treinen voelde het rondkomen met het punctuele en efficiënte Japanse metrosysteem fantastisch. Ik wilde dat mijn site datzelfde gevoel zou geven, dat je kon rondklikken en op nieuwe plekken uitkwam met het vertrouwen dat er niets mis zou gaan. Snel en helder. Alle timings tot op de milliseconde kloppend.

Een uur later was ik geïnspireerd, niet langer hongerig en klaar om het ontwerp van de site af te maken.

Ik richtte een klein bureau in in mijn hotel en ging aan de slag. Ik besloot eerst mobiel op te lossen en dan op te schalen, om te voorkomen dat ik iets krankzinnigs zou bedenken dat op kleine schermen nooit zou werken.

De afgelopen maand had ik lopen dubben over welke kant de tijd op moest lopen op mobiel. Moest de laatste activiteit van boven binnenkomen? Zo werkten de meeste feeds als Facebook en Twitter. Of moest het chronologisch, als een kalender, beginnend bij de eerste dag?
Het probleem was dat er geen enkel juist antwoord was. Dit was zowel een realtime feed van mijn activiteit als een kalender van wat ik in het verleden had gedaan. Elk vroeg om het tegenovergestelde ontwerp, maar ik kon er maar één kiezen.
Nadat ik een hoop echte data in beide vormen had gezet, merkte ik dat ik vaker chronologische volgorde verwachtte en de pagina anders vaak verkeerd begreep.
Uiteindelijk besloot ik dat elke maandpagina zou beginnen om middernacht op de eerste dag. Het nieuwste zou onderaan staan, het oudste bovenaan.

Ik gebruikte Google Maps om me te oriënteren en werd geïnspireerd door hun mobiele ontwerp. Hun tijdlijn van routes is altijd helder en betrouwbaar.
Om iets vergelijkbaars te bereiken moest ik een hoop data schrappen die ik in de marges probeerde te proppen. Bruikbaarheid en eenvoud waren belangrijker voor de mobiele ervaring dan alle informatie in één beeld hebben.
Ik had geprobeerd slimme manieren te bedenken om zonsopgang en zonsondergang, foto's van die dag enzovoort te tonen. Prima data, maar het maakte alles te ingewikkeld. De nieuwe versie was veel eenvoudiger, gewoon een lijst van de plekken waar ik was geweest.

Ik werkte de inhoud bij met de activiteit van die dag en schrapte bijna al het andere. Er stond weinig informatie in, maar het begon een stuk rustiger te worden. Het was eindelijk iets wat ik makkelijk op mijn telefoon kon gebruiken of met anderen kon delen.

Later die dag kondigde Apple HealthKit aan op WWDC. Het was niet zo groots als ik had verwacht, er kwam geen revolutionaire hardware bij, maar de klok tikte nu officieel.
Door het klinische, medische karakter van hun ontwerp besefte ik ook hoe cruciaal Explorer was, meer nog dan ik oorspronkelijk had gedacht. De locatie- en reisdata zouden context en betekenis geven aan wat anders alleen een verzameling losse datapunten zou zijn, niet meer dan weetjes.
Ik had nog maar een paar dagen in Japan voordat ik naar huis moest om dit ding te bouwen en te lanceren. Echte kunstenaars leveren tenslotte.
Theeceremonie
De volgende ochtend ging ik lang hardlopen door het park. Ik wilde mijn hoofd leegmaken en de inspiratie de ruimte geven. Na het lezen over HealthKit zat mijn hoofd vol wilde ideeën over fitness als spel of het algoritmisch voorkomen van hartaanvallen.

Daarna besloot ik een traditionele Japanse theeceremonie te bezoeken. Die vond plaats in een prachtige tuin, met een koivijver en veel groen eromheen. Vlakbij speelde een vrouw in kimono met de vissen.

De eerste gang was een klein zoetigheidje, geserveerd op een zeshoekige houten onderzetter. Het deed me denken aan een idee dat ik eerder had geschetst. Ik had zeshoeken zo goed als opgegeven, omdat je ze niet in elkaar kunt nestelen zoals rechthoeken.

Ik had tevergeefs gezocht naar een herkenbare kop voor bovenaan elke maandpagina. De cirkels in de vorige versie waren netjes, maar niet erg gedenkwaardig of spannend. Door de thee dacht ik dat het misschien tijd was om de zeshoeken er weer bij te pakken.

Ik was enthousiast dat het een visueel interessant element werd dat toch veel rijke informatie kon overbrengen. Omdat het idee zo op inhoud leunde, was het beter om meteen met de echte data te gaan bouwen dan een nauwkeurig ontwerp met honderden dynamische iconen te maken.

Dit was de eerste gebouwde versie. Bijzonder mooi was hij niet, maar de levende inhoud zat erin en de basisindeling voor de elementen waar ik mee zou spelen stond.

Van elk item een zeshoek maken was gewoon een simpel CSS-beeldmasker. De hele reeks locaties is licht bewerkt in 3D voor een interessanter perspectief. Een lichte schaduw langs de randen houdt de aandacht in het midden.

De locatiecategorieën van Foursquare deden hier het meeste werk, met een indeling in categorieën en mooie iconen om ze weer te geven.

Ik zette een kleurcodering op om plekken makkelijk te onderscheiden, waardoor er patronen per maand zichtbaar werden. Natuur en parken zijn groen, vliegvelden en stations turquoise, restaurants en koffiezaken meestal oranje, en woningen of hotels een subtiel grijs.
Maanden waarin ik veel dook hadden veel groen. Toen ik in New York was, zit er veel rood in van Italiaanse restaurants. De reis naar Japan had veel roze van de sushi.

Nu de bovenkant van de pagina ontworpen en gebouwd was, moest ik bedenken hoe ik de tijdlijnen daaronder zou vullen. De data was er allemaal, hij moest alleen goed gepresenteerd worden.
Verdwaald in Roppongi
Ik was laat op de terugweg van de theeceremonie. Ik was de tijd vergeten omdat ik mijn Japans probeerde te oefenen met de vrouw in de kimono. Ik moest binnen een uur uitchecken bij het Park Hyatt Tokyo, maar ik zat aan de andere kant van de stad. Volgens Google Maps zou het 43 minuten duren met de metro.

Ik stapte in de trein richting station Azabujuban en was onderweg. “Het komt wel goed,” zei ik tegen mezelf. “Ik kan meestal in minder dan 5 minuten inpakken.”
Eenmaal in de trein raakte ik afgeleid door een geestig bijschrift voor mijn Instagram-foto te verzinnen, en tegen de tijd dat ik opkeek gleed mijn halte net voorbij. Oeps. Ik stapte uit bij de volgende: Roppongi.
Ik stond naar de kaart te staren om te bedenken of ik terug of verder moest, boos dat het metrosysteem waar ik zo van hield me in de steek liet op het moment dat ik het het hardst nodig had. Het duurde even voor ik doorhad waar ik eigenlijk naar keek.

Hier stond een reeks locaties op een dunne lijn met veel tekst. Alle labels stonden licht schuin. Grote, felgekleurde cirkels onderscheidden de gebieden. Dit was waar ik naar op zoek was!
Deze manier om informatie op een tijdlijn te tonen was de laatste inspiratie die ik nodig had om het ontwerp van Explorer 2.0 af te maken. De schuine labels losten mijn stapelprobleem op, en de grote, stevige cirkels zouden ook in een compacte vorm goed te begrijpen zijn.

Ik wilde de halve pagina reserveren om andere details over de dag uit te zetten, met de locaties erboven als context voor wanneer en waar die plaatsvonden. Ik speelde met het idee om een kaart de rest van de ruimte te laten vullen.
Er waren veel dingen die ik per dag wilde uitzetten: slaap, eten, vervoer, stemming, bloedsuiker enzovoort. Voorlopig gebruikte ik de data waar ik makkelijk bij kon en die van dag tot dag het meest varieerde: vervoer, GitHub-commits en hartslagen.

Door de locatienamen te kleuren kon ik ze beter uit elkaar zetten en toch een sterke visuele band met de gekleurde iconen houden.
Ik speelde met het idee van een kaart op de achtergrond. Visueel vond ik het rijke effect dat het gaf erg mooi. Maar het werd te verwarrend zodra er data bovenop kwam te staan die er niets mee te maken had.
In plaats van de kaart probeerde ik een vervaagde achtergrond van Instagram-foto's. Dat gaf elke dag een eigen, interessante achtergrond voor zijn data. De geschiedenis van Github-commits en deploys vulde de gaten op de vele dagen dat ik verder niets deed.

Na dagen van traag geploeter en experimenteren, waarbij ik letterlijk de hele wereld afzocht naar het antwoord, viel opeens alles op zijn plek. Vanaf het moment dat ik de laatste laag toevoegde, wist ik dat dit hem was.
De ontwerpfase was eindelijk voorbij. Tijd om te gaan bouwen.
Juli 2014: San Francisco
Tot dan toe had ik uitgesteld om te bedenken hoe ik dit ging bouwen & welke techniek ik zou kiezen. Ik wilde al mijn tijd aan het ontwerp en de frontend besteden zonder me te laten afleiden door infrastructuur of code . Bij het prototypen vasthouden aan het supersimpele Jekyll was cruciaal om snel te blijven en veel ideeën te kunnen proberen. Doordat alles statisch was, kon ik interessante versies makkelijk bewaren om later terug te kijken.
Mijn buurman was groot voorstander van Node. Een hoop mensen raadden Rails aan. Vroeger had ik Django gebruikt en dat beviel me. Ik wist dat de taal eigenlijk niet zoveel uitmaakte, ik moest er gewoon een kiezen en beginnen met schrijven.
Ik speelde een dag met Ruby on Rails. Veel mensen hadden het aangeraden. Het leek een degelijke keuze om later andere ontwikkelaars te betrekken. Nadat ik een uur bezig was geweest om het Hello World-voorbeeld draaiend & live te krijgen, besefte ik dat het te traag ging. Ik moest al mijn tijd aan bouwen besteden en niet aan het doorgronden van een nieuw framework.
Ik koos voor Python en Django, waarmee ik lang geleden al een analytics-startup had gebouwd. Met Heroku waren deployen en servers beheren veel makkelijker dan ik van AWS gewend was. Binnen enkele minuten stond de site live. Binnen een paar uur had ik alle pagina-URL's aangesloten op lege templates. Binnen een paar dagen draaiden de meeste modellen en haalden ze data uit allerlei API's. Nu kwam er vaart in.
De meeste diensten waarmee ik wilde koppelen hadden nette OAuth 2.0-API's met goede documentatie, dus het was verrassend eenvoudig om de accounts te verbinden en de data op te halen die ik nodig had. Ik zette een taak in de Heroku scheduler om elke 10 minuten op verse data te controleren en die te importeren als er iets nieuws was.
De frontend
- SASS
- Compass
- CoffeeScript
- LiveReload
- jQuery
- PJAX
- jQuery Throttle
- D3
De site laadt één globaal CSS-bestand en één globaal JavaScript-bestand. Die bestanden worden samengevoegd uit een reeks kleinere SASS- en Coffee-bestanden, zodat alles tijdens het ontwikkelen overzichtelijk en modulair blijft.
Tijdens het ontwikkelen gebruik ik de Mac-app LiveReload om de site meteen te herladen zodra ik CSS of JavaScript aanpas. Dat scheelt elke keer een paar seconden, wat enorm helpt als je duizenden keren itereert.
De backend
- Python
- Django
- Postgres
- Memcached
- Heroku
Heroku heeft handige handleidingen om hun stack op te zetten. Deployen is heel simpel: gewoon een “git push heroku master” en de wijzigingen staan live. Ik push vaak naar GitHub en naar Heroku wanneer ik wil deployen.
Ik maakte me een tijd zorgen over de snelheid van pagina's met zware queries, maar Memcached was mijn redding. Omdat de site zo statisch was & alleen veranderde als er nieuwe data binnenkwam, kon ik zo goed als elk template cachen & direct uitserveren.
De laatste loodjes
Het ontwerpproces heeft baat bij wisselende perspectieven en onderbrekingen. Soms valt het kwartje midden in een gesprek, of nadat ik iets op straat zie.
Maar bij het bouwen wil ik soms dagen ononderbroken tijd hebben om me te concentreren en duizenden regels code in mijn hoofd te houden. Mijn beide huisgenoten waren een week weg, dus ik had rust.
Met de ontwerpen op orde en de data die binnenstroomde, had ik alleen nog een lange lijst met bugs en snelheidsproblemen om op te lossen voor de lancering. Ik besloot mezelf in mijn kamer op te sluiten tot dit ding live was.

Ik sprong heen en weer tussen frontend en backend, voegde meer levende data aan de pagina toe en ruimde het daarna weer op.
Als ik iets in CSS bouw, werk ik eerst aan de indeling met extreem simpele stijlen. Het doel is om alles op de juiste plek te krijgen, niet om het mooi te maken. De eerste stap is zorgen dat de backend alles uitspuugt wat ik nodig heb. Dat wil ik van tafel hebben zodat ik daarna al mijn tijd in hetzelfde CSS-bestand kan doorbrengen. Alles krijgt background: red of background: blue om te controleren of de selectors goed werken. Daarna werk ik aan de indeling en positionering, met dingen als responsiviteit en randgevallen in mijn hoofd. Als dat helemaal staat, maak ik meestal een nieuw stylesheet om alle ontwerpdetails in te vullen en het mooi te maken.

Doordat ik dezelfde kleuren en iconen als bij de zeshoeken hierboven gebruikte, kreeg je meteen gevoel voor de soorten plekken op een dag. Thuis kwam constant terug en was niet bijzonder spannend, dus dat maakte ik subtieler zodat de andere plekken meer opvielen: witte cirkels in plaats van blauwe.

Alle labels waren nu verborgen, waardoor elke tijdlijn eenvoudiger en luchtiger werd. Als je op een dag klikte, klapte die open met meer informatie.

Het eerste wat ik toevoegde was reisdata, die de locaties met elkaar verbindt via lopen, hardlopen, rijden enzovoort. Alles was absoluut gepositioneerd, dus ik kon elk item uitzetten op begin- en eindtijd.
Vervaagde Instagram-foto's gaven de dagen interessantere en gevarieerdere achtergronden voor de data. Daarna zette ik er echte hartslagdata per dag bij.

Een beetje styling brengt de pagina langzaam samen. Tussen de plekken lopen bogen die het type en de duur van de verplaatsing tonen. Saaie dingen als lopen zijn heel klein, maar een flinke run of vlucht heeft een felle kleur zodat je hem meteen ziet.

Rechts is wat ruimte gereserveerd voor de stad en de navigatie naar de vorige en volgende dag.

Sommige dagen hadden veel lege ruimte, alsof ik de hele dag thuis had gezeten of geslapen. Github-commits vullen de resterende gaten in het verhaal, en laten zien wanneer ik werkte en waaraan.

Maandpagina's
Nu elke dag & maand een pagina had, begon ik aan de lijst met maanden en aan de animaties om door alle pagina's te navigeren.

In het begin stonden de maanden in een verticale lijst, met details over de steden en de soorten plekken die ik had bezocht. De beste foto's van de maand geven ook een indruk van wat er gebeurd is.

Oorspronkelijk was dit de responsieve mobiele versie, maar ik besefte dat elke maand als een eigen blokje spannender zou zijn dan een lijst. Elke maand werd zo uitnodigender om aan te klikken en leek meer op een interactief object.

Mapbox
Ik wilde een subtiele achtergrond met terrein en straten om mijn runs context te geven. Google Maps is fantastisch, maar ik wilde iets wat ik meer kon aanpassen, dus ik probeerde Mapbox. De dienst leek wat prijzig, maar het opzetten gaat heel makkelijk en ik vond een mooiere homepage met goede kaarten het geld wel waard.

Runkeeper levert elke 5 seconden tijdens de run een reeks GPS-coördinaten. Ik gebruikte de javascript-bibliotheek van Mapbox om van die punten een SVG-lijn te maken. Eerst was ik bang dat ik ingewikkelde code moest schrijven om de lijn van begin tot eind te laten groeien, maar het bleek een simpele CSS-overgang met de stroke-dash-eigenschappen. In dit voorbeeld komt de lijn geleidelijk tevoorschijn doordat de offset naar 0 gaat.
path.line {
/* Assuming a stroke length of 100px */
stroke-dasharray: 100px;
stroke-dashoffset: 100px;
transition: all 500ms ease;
}
path.line.loaded {
stroke-dashoffset: 0;
}Kritiekuur
Elke avond kwam Stammy thuis van zijn werk en namen we de nieuwe functies en veranderingen door. Ook stuurde ik links of screenshots naar Yuri, Dustin en andere vrienden als ik vastliep of een tweede mening nodig had. Het helpt enorm om andermans blik te hebben en er regelmatig frisse ogen bij te halen. Veel van de ideeën kwamen oorspronkelijk uit gesprekken, of als antwoord op feedback dat iets niet lekker voelde.
Feedback vragen is meer dan alles doen wat mensen zeggen, of weghalen wat ze niet mooi vinden. Feedback vertelt je of wat je gedaan hebt logisch is of goed werkt, maar niet wat je moet doen of wat de visie moet zijn. Een visie kun je niet crowdsourcen. Een project vol pleisters en trucjes voor elke klacht wordt meestal lastig om verder te ontwikkelen en te onderhouden.
Felle feedback is meestal een goed teken, zelfs als hij negatief is betekent het dat iemand betrokken genoeg was om er emotie in te steken. Dat is eigenlijk zeldzaam. Als iedereens feedback vaag is of ze hebben niets te zeggen, is dat meestal een slecht teken en is het ontwerp weinig inspirerend. Als iedereen het haat, kan het verschrikkelijk of briljant zijn, dat is soms lastig te zeggen.
Het is belangrijk om steeds feedback te vragen, maar niet om alles te laten vallen of het hele idee overboord te gooien zodra er iets negatiefs binnenkomt. Ik verzamel het meestal voor de volgende ronde, tenzij er een ramp aan het licht komt waardoor je terug naar de tekentafel moet.

In de huidige versie heb ik bijvoorbeeld veel feedback gekregen dat de bogen voor verplaatsingen nergens op slaan. Het was onzinnig om de lancering uit te stellen om ze te repareren, maar in de volgende versie pakken we het anders aan.
Het loont ook om feedback te vragen aan verschillende soorten mensen, vooral aan mensen die minder technisch zijn of dit soort interfaces niet gewend zijn. Het kan frustrerend zijn, maar ook een eyeopener, om te zien hoe anders sommige mensen denken en dingen gebruiken. Daarom test ik zo graag in koffiezaken of met volslagen vreemden: je krijgt fascinerende inzichten en ontdekt dingen die vanzelfsprekend leken maar voor anderen nergens op slaan.
Zelfs het meest gepolijste en best doordachte ontwerp heeft ruwe randjes en wordt beter van grondig testen.
Chat heads
Contactformulieren zijn zo 2006. Ik wilde een leuke manier om met bezoekers om te gaan. Mijn idee was dat veel mensen wel iets te zeggen hebben, maar dat de meesten schrikken van een officieel ogend contactformulier. Ik in elk geval wel.

Ik wilde dat het leuk, vriendelijk en menselijk zou zijn, ook al was de rest van de site behoorlijk futuristisch en geautomatiseerd. Ik wilde dat de site gaaf was, maar niet zo gaaf dat mensen zich er niet toe durfden te verhouden.

Vroeger gebruikte ik elke dag de chat heads van Facebook om met mensen te praten. Dat was een heel natuurlijk ontwerp & een natuurlijke manier van communiceren. Ik wilde hier iets vergelijkbaars, iets waar de meeste mensen al aan gewend waren. In de toekomst zouden mensen zelfs via Messenger in realtime met me kunnen praten, met de site als chatprogramma.
Over-pagina

Dit project leunde op een hoop andere software en hardware. Ik wilde iedereen goed kunnen bedanken en alle hulpmiddelen die ik gebruik kunnen delen. Ik besloot een simpele “powered by”-reeks logo's te maken van alle partners, met hun naam en bijdrage zichtbaar als je erover zweeft.

Ik zette er wat cijfers over burrito's bij zodat het leuker en persoonlijker aanvoelde, en niet alleen als een medisch dashboard. Want wie houdt er nou niet van burrito's?
Powered by suiker
Tegen het einde werkte ik enorme hoeveelheden suiker weg om scherp te blijven en de hele nacht door te kunnen werken. Verschrikkelijk voor mijn lichaam, maar ik kon er een paar uur helder van denken en bijna elk probleem oplossen. Hoe lastiger het probleem, hoe meer suiker ik nodig heb om het op te lossen.

11 juli 2014
Lanceerdag
Het was vrijdag. De site was bijna klaar, dus ik besloot naar Alex te gaan voor de laatste puntjes op de i. Het is altijd goed om er een tweede paar ogen bij te hebben, en dat een van de beste Javascript-experts ter wereld in de buurt is helpt ook.
Mijn todo-lijst bestond nog uit allemaal kleine dingen: de chat heads echt berichten laten versturen, twitterknoppen toevoegen, metabeschrijvingen repareren, het eerste artikel schrijven, de CDN-bestanden bijwerken, de lanceringstweet bedenken enzovoort.
In de paar uur dat we daar zaten te werken, maakte hij een Chrome-extensie om onze leeftijdsteller als startscherm te gebruiken.
We bespraken kort of vrijdagavond te laat was om te lanceren, of dat het slimmer was om tot maandag te wachten als iedereen weer achter zijn computer zat. Het was waarschijnlijk verstandiger geweest om nog een paar dagen te wachten, maar ik was op dat moment uitgeput na een week non-stop coderen op adrenaline en had het gevoel: nu of nooit.
Ik paste wat DNS-instellingen aan, plaatste een tweet, en we waren live!
Omdat het vrijdagavond was, kwamen bijna alle eerste bezoeken van mobiel. Ik had het grootste deel van mijn tijd in de desktopversie doorgebracht, maar de meeste mensen kregen de eenvoudige mobiele uitvoering te zien.
Het was een geluk dat ik er aan het eind zoveel tijd in had gestoken om het responsief te maken. Iedereen leek het mooi te vinden en deelde het gewoon vanaf zijn telefoon. Als ik dit nog eens deed, zou ik meer tijd aan de mobiele versie besteden, want die is de eerste en vaak de enige manier waarop mensen het zien.
Alles leek soepel te lopen tot ik een DM van Stammy kreeg dat ik 1517 pounds woog. Dat was raar, want ik voelde me een stuk lichter.
Ik had de code van de Sport-pagina al lang niet aangeraakt, dus die kon niet zomaar kapot zijn gegaan. In de broncode zag ik dat de ruwe waarde een komma had in plaats van een punt: 151,7 in plaats van 151.7. Javascript negeerde de komma en las dat verkeerd in. Ik leegde de cache en de pagina was weer normaal. Vreemd…
Later die avond was ik in een bar en liet ik een vriend de site op mijn telefoon zien, toen ik zag dat een van de paginatitels in het Russisch was. Raar. Ik legde meteen de link met de bug van eerder: allebei zouden veroorzaakt zijn door een of andere op hol geslagen internationaliseringscode.
Uiteraard moest ik naar huis om het uit te zoeken.
Het bleek te komen door een simpele instelling in Django, met internationalisering (meestal afgekort tot i18n) aangezet voor dingen als getallen en datums. In combinatie met het cachesysteem raakten bepaalde stukken beschadigd als ze vanuit het buitenland waren opgevraagd. Die functie uitzetten was een oplossing van één regel en zorgde voor dezelfde ervaring voor iedereen ter wereld.
Dat was maar één van de vele voorbeelden waarbij een kleine, obscure aanwijzing wijst op een bug die ergens uitgezocht moet worden.
Die nacht viel ik uitgeput maar tevreden in slaap na een lange week werken. De site was eindelijk live en een paar duizend mensen hadden hem gezien via mijn tweet. Ik zou het weekend uitrusten en de week daarna bedenken hoe ik hem met de wereld ging delen. Dat bleek niet nodig…
De volgende ochtend
Binnen een paar uur, terwijl ik lag te slapen, hadden mensen hem op Reddit, Hacker News en overal op internet gezet. Ik had met een vriend afgesproken om de volgende dag om 7 uur 's ochtends te gaan hardlopen, dus voor mijn doen stond ik vroeg op. Gelukkig maar.
Mijn telefoon ontplofte van de meldingen. Een paar honderd tweets, een berg e-mails. Ik probeerde de site te laden en dat ging extreem traag. Ik keek in de analytics en zag dat het bezoek de afgelopen uren door het dak was gegaan, waardoor hij onder de belasting bijna niet meer reageerde. Gelukkig was opschalen met Heroku vrij makkelijk, en ik ging van 2 naar 8 dyno's. Met genoeg webservers voor die extreme drukte laadde alles weer meteen.
Binnen een paar uur passeerde de site honderdduizend bezoekers. Tegen de middag tweehonderdduizend. Mensen vonden het blijkbaar mooi. De tweets en berichten bleven binnenstromen!
Het maakte me nederig om allerlei soorten mensen erover te zien praten en het te zien delen, zeker omdat ik niet zeker wist of iemand het zou snappen of mooi zou vinden. Er waren een paar tweets die mijn dag helemaal goed maakten, van mensen die ik erg bewonder.
Ik merkte dat honderden mensen dezelfde vragen stelden:
- Hoe heb je de animaties gemaakt?
- Welke technieken gebruik je?
- Hoe weet je je bloedwaarden?
- Hoe krijg ik dit voor mezelf?
Nadat ik de eerste 10 of 20 had beantwoord, besefte ik dat ik het hele verhaal van begin tot eind moest opschrijven. Het proces was te spannend om niet met de wereld te delen. Ik had honderden oude schetsen, ontwerpen en prototypes die niemand ooit had gezien.
En zo begon dit bericht…
Nawoord
Ik had de site vooral ontworpen als mijn eigen speeltje. Ik wist dat dit de toekomst was, maar ik wist niet of iemand anders het de dagelijkse moeite waard zou vinden om al die data te verzamelen. Maar er bleken er in elk geval een paar erg geïnteresseerd. Na de lancering kreeg ik honderden berichten van mensen die vroegen hoe ze er zelf een konden krijgen.

Een paar maanden later besloot ik een bedrijf te beginnen dat Gyroscope heet. Dat draait nu, en iedereen kan zich aanmelden om zijn leven bij te houden.