Wie April Zero entstand: Teil 2

Wie April Zero entstand

Teil 2

Mein Designprozess ist jedes Mal anders.

Für theory11 kam ich in die richtige Stimmung, indem ich Fremden auf den Straßen von LA Zaubertricks zeigte. Den Styleguide für Quizlet hatte ich beim Fallschirmsprung über Hawaii, im freien Fall, mit dem blauen Wasser, dem hellen Sand und den weißen Wellen vor Augen. Das Farbschema meiner vorherigen Seite habe ich von einer roten Ducati geborgt.

Und diese Seite entstand auf einem noch verschlungeneren Weg, mit Abenteuern rund um die Welt, neuen Geräten und Experimenten an mir selbst. Alles natürlich nur für Forschung & Entwicklung.

Nachdem ich ein paar Monate lang etliche Apps und Geräte getestet hatte, stand mein finaler Stack für möglichst automatisches Messen bei minimalem Zeitaufwand fest.

• Moves iPhone-App, für Standortdaten
• Cardiio iPhone-App, für meinen Puls
• Instagram, für meine Fotos
• Runkeeper iPhone-App ‐ zum Tracken meiner Läufe
• Withings WLAN-Waage, für das tägliche Gewicht
• Withings Blutdruckmessgerät, Puls und Blutdruck
• Bodymetrix-Ultraschall, für den Körperfettanteil
• Monatliche Bluttests, für Triglycerid- und Nährstoffwerte

Mai 2014: Thailand

Ich reiste mit Dustin Curtis durch Asien und skizzierte Ideen für die mobile Version der Seite. Ich wollte etwas finden, das den mobilen Kontext nutzt, etwas, das ich unterwegs jeden Tag brauchen würde.

Ich wollte vermeiden, etwas zu bauen, das man einmal anschaut und dann vergisst. Ich wollte, dass es sich ständig verändert und in Echtzeit aktualisiert, und dass es immer das Wichtigste des Moments zeigt: einen neuen Ort, eine Warnung wegen erhöhtem Puls oder einfach eine allgemeine Darstellung des Gesundheitszustands.

Ich wollte für die schnell näher rückende Zukunft gestalten, in der all diese Daten ständig verfügbar sind, und ein paar Grenzen der Gegenwart ignorieren. Momentan aktualisieren sich diese Zahlen nicht laufend: das Gewicht etwa einmal am Tag, die Blutwerte nur einmal im Monat, und der Puls nur, wenn ich ihn messe, ein paar Mal am Tag.

Ich sage voraus, dass es in ein paar Jahren, wenn nicht früher, neue Geräte geben wird, die diese Daten viel automatischer und durchgehender liefern. Wenn Apple oder ein anderer großer Player es im nächsten Jahr nicht hinbekommt, macht es jemand auf Kickstarter.

Eine mobile Idee, die mich begeisterte, war eine Augmented-Reality-Ebene mit all meinen Vitalwerten. Das Kamerabild ließe sich weichzeichnen, um die Illusion zu erzeugen, das Handy sei durchsichtig, und die Informationen lägen auf verschiedenen Ebenen darüber. Im Browser war das dann nicht möglich, aber vielleicht nehme ich die Idee eines Tages als App wieder auf.

Mich begeisterte, alle Informationen auf einen Blick auf dem Handy zu haben, und ich versuchte immer wieder, alles in ein einziges eingängiges Dashboard zu bekommen.

Tauchschule

Ich landete auf Koh Tao, einer kleinen Insel an der Ostküste Thailands. Sie ist fürs Tauchen berühmt, also machte ich dort meinen Schein.

Tagsüber ging ich zur Tauchschule, nachts baute ich neue Mockups fürs Handy. Ich verband Photoshop auf meinem Macbook mit Skala Preview auf meinem iPhone, um jedes Design im echten Kontext zu sehen. Ich nahm das Handy, lief mit der jeweiligen Seite herum und versuchte herauszufinden, wie gut sie sich anfühlt.

So klärten sich viele Designfragen wie Größe und Lesbarkeit. „Wie klein darf der Text sein?“ „Wie viel Kontrast brauche ich, um draußen lesen zu können?“ „Wie viel Information passt auf einen Screen?“

Die dezent kreisenden Ringe oben spielten auf die Desktop-Version an und gaben der Seite Charakter. Anfangs waren sie zu stark, also nahm ich Deckkraft und Farbe immer weiter zurück, bis sie kaum noch auffielen.

Ich lief mit Screenshots auf dem Handy herum und zeigte sie Leuten um mich herum.

„Was, glaubst du, will dir diese Seite sagen?“ „Worauf würdest du tippen?“

Am Anfang taten sich die Leute schwer, aus all den Sachen schlau zu werden, die auf die Seite gequetscht waren. Dan wusste nicht, welche Spalte er zuerst ansehen soll. Dustin fand alles zu klein. Alle anderen auf dem Boot fragten sich vermutlich, warum ich meinen Laptop mitgebracht hatte.

Mir wurde klar, dass die Idee, irgendwie alles auf die Seite zu bekommen, nicht funktionieren würde, also reduzierte ich auf die wirklich relevanten Werte.

In Bangkok sind wir in ein paar Krankenhäuser gegangen, um ein günstiges Ganzkörper-MRT zu bekommen, aber das war zu teuer, mehrere tausend Dollar. In der Zwischenzeit hatte ich mich richtig in die Idee verliebt, ein vollständiges medizinisches Bild von mir zu haben, und beschloss, es auf die Seite zu nehmen, für ein klinischeres, wissenschaftlicheres Gefühl. Ich nahm zuerst ein Stockbild einer durchschnittlich aussehenden Person und wollte es später durch ein echtes von mir ersetzen.

Das Gefühl des menschlichen Querschnitts gefiel mir sehr, gerade im Gegensatz zu etwas Generischem wie der Karte. Ein Blick auf die Seite genügte, um zu spüren, was los war, und die Daten waren griffbereit, wenn man genauer auf die Balken und Zahlen schaute. Mit guten Animationen wäre es noch besser. Ich wollte deutlich machen, dass das eine Echtzeitverbindung zu einem lebenden Menschen war, und nicht bloß ein Haufen langweiliger medizinischer Graphen. Ich musste der Falle entgehen, in die viele Apps tappen, mit Dutzenden generischer Torten- & Donut-Diagramme.

Ich wollte eine Geschichte erzählen, nicht einfach ein paar medizinische Messwerte zeigen.

An diesem Punkt fing das Design an, mich zu begeistern. Der Puls würde besonders cool sein, sobald er Echtzeitdaten lädt. Ob die Animation für das MRT möglich ist, wusste ich nicht, aber das war das erste mobile Design, das sich endlich gut genug anfühlte, um neben dem Desktop-Erlebnis zu bestehen.

Es war bereit für Code. Auf dem Weg nach Süden Richtung Malaysia verbrachte ich die nächsten Tage damit, die Animationen zu bauen.

Nach ein paar Tagen Experimentieren hatte ich heraus, wie sich das Scannen und Leuchten des MRT in CSS simulieren lässt. Ich setzte einen Breakpoint bei etwa 600px und arbeitete am mobilen Layout direkt im Browser. Als es fast fertig war, lud ich es über die IP-Adresse meines Rechners aufs Handy, um direkt auf der iPhone-Hardware zu testen und zu optimieren.

Nachdem Mobile endlich geklärt war, ging es zurück an das Desktop-Erlebnis von Explorer.

Die vorherige Version war schön, aber viel zu viel Information auf einmal. Ich musste herausfinden, wie ich meinen Tagesablauf kompakter und verständlicher zeige. Ich vermutete, die Lösung liege in mehr Navigationsebenen, die jede Timeline auf eine einfachere Fassung eindampfen, bis man mehr Details zu diesem Tag anfordert.

Auf leeren Magen kann ich schlecht denken, also beschloss ich, mich erst mit Sushi vollzuladen und dann das endgültige Design zu klären.

Juni 2014: Japan

Frühstück in Tsukiji

Am nächsten Morgen landete ich in Tokio und fuhr direkt zum Fischmarkt Tsukiji, der Heimat des frischesten Fischs der Welt.

Nach einem Monat auf holprigen Booten und langsamen Zügen war es fantastisch, sich mit dem pünktlichen und effizienten japanischen U-Bahn-System zu bewegen. Ich wollte, dass sich meine Seite genauso anfühlt: Man klickt herum, landet an neuen Orten und ist sicher, dass nichts schiefgeht. Schnell und sauber. Alle Abläufe auf die Millisekunde genau.

Eine Stunde später war ich inspiriert, nicht mehr hungrig und bereit, das Design fertig zu machen.

Ich richtete mir im Hotel einen kleinen Schreibtisch ein und legte los. Ich entschied mich, zuerst Mobile zu klären und dann nach oben zu skalieren, damit ich nichts Verrücktes erfinde, das in kleinen Größen nie funktionieren würde.

Den ganzen letzten Monat hatte ich darüber gegrübelt, in welche Richtung die Zeit auf dem Handy fließen soll. Sollte das Neueste von oben hereinkommen? So machen es die meisten Feeds wie Facebook oder Twitter. Oder sollte alles chronologisch angeordnet sein, wie ein Kalender, beginnend mit dem ersten Tag?

Das Problem war: Es gab keine einzig richtige Antwort. Das war beides, ein Echtzeit-Feed meiner Aktivität und ein Kalender dessen, was ich getan hatte. Jedes verlangte das gegenteilige Design, aber ich konnte nur eins wählen.

Nachdem ich viele echte Daten in beiden Varianten aufgebaut hatte, merkte ich, dass ich häufiger eine chronologische Reihenfolge erwartete und die Seite sonst oft falsch verstand.

Schließlich entschied ich, dass jede Monatsseite um Mitternacht des ersten Tages beginnt. Das Neueste steht unten, das Früheste oben.

Ich hatte mich mit Google Maps orientiert und fand deren mobiles Design inspirierend. Ihre Routen-Timeline ist immer sauber und verlässlich.

Ein ähnliches Gefühl zu erreichen hieß, viele Daten loszuwerden, die ich in die Ränder quetschen wollte. Bedienbarkeit und Einfachheit waren für das mobile Erlebnis wichtiger als alle Informationen in einer Ansicht zu haben.

Ich hatte versucht, clevere Wege zu finden, Sonnenauf- und -untergang, Fotos des Tages und so weiter zu zeigen. Schöne Daten, aber zu viel Komplexität. Die neue Version war viel einfacher, nur eine Liste der Orte, an denen ich war.

Ich füllte die Inhalte mit dem Tagesablauf und löschte fast alles andere. Es zeigte nicht mehr viele Informationen, wirkte aber deutlich aufgeräumter. Endlich war es etwas, das ich bequem auf dem Handy nutzen und mit anderen teilen konnte.

Später am selben Tag kündigte Apple HealthKit an, auf der WWDC. Es war nicht ganz so großartig, wie ich erwartet hatte, keine revolutionäre Hardware dazu, aber die Uhr tickte jetzt offiziell.

Der klinische, medizinische Charakter ihres Designs machte mir auch klar, wie wichtig Explorer war, wichtiger, als ich ursprünglich gedacht hatte. Standort- und Reisedaten würden dem Kontext und Bedeutung geben, was sonst nur eine Ansammlung zusammenhangloser Datenpunkte wäre, bloße Trivia.

Ich hatte nur noch ein paar Tage in Japan, bevor ich nach Hause musste, um das Ding zu bauen und zu starten. Echte Künstler liefern schließlich.

Teezeremonie

Am nächsten Morgen ging ich für einen langen Lauf in den Park. Ich wollte den Kopf frei bekommen und der Inspiration eine Chance geben. Nach dem, was ich über HealthKit gelesen hatte, schwirrten mir wilde Ideen durch den Kopf, Fitness zu einem Spiel zu machen oder Herzinfarkte algorithmisch zu verhindern.

Danach schaute ich mir eine traditionelle japanische Teezeremonie an. Sie fand in einem schönen Garten statt, mit einem Koi-Teich und viel Grün ringsum. Eine Frau im Kimono spielte in der Nähe mit den Fischen.

Der erste Gang war eine kleine Süßigkeit, serviert auf einem sechseckigen Holzuntersetzer. Er erinnerte mich an ein Konzept, das ich vorher skizziert hatte. Ich hatte Sechsecke eigentlich schon aufgegeben, weil sie sich nicht wie Rechtecke ineinander schachteln lassen.

Ich hatte vergeblich nach einem markanten Kopfbereich für jede Monatsseite gesucht. Die Kreise in der vorherigen Version waren sauber, aber nicht besonders einprägsam oder aufregend. Der Tee brachte mich auf den Gedanken, dass es Zeit sein könnte, die Sechsecke noch einmal anzusehen.

Mich begeisterte, dass daraus ein visuell interessantes Element wurde, das trotzdem viel Information tragen kann. Weil die Idee so inhaltslastig war, wäre es besser, gleich mit echten Daten zu bauen, als ein exaktes Mockup mit Hunderten dynamischer Icons zu basteln.

Das war die erste programmierte Version. Besonders hübsch war sie nicht, aber sie brachte die echten Inhalte und das Grundlayout für die Elemente, mit denen ich spielen wollte.

Aus jedem Element ein Sechseck zu machen war nur eine einfache CSS-Bildmaske. Die ganze Menge der Orte ist im 3D-Raum leicht gekippt, für eine interessantere Perspektive. Ein sanfter Schatten an den Rändern hält den Fokus in der Mitte.

Die Ortskategorien von Foursquare haben hier viel Arbeit abgenommen, mit einer fertigen Taxonomie und guten Icons dafür.

Ich habe eine Farbcodierung eingerichtet, um Orte leicht zu unterscheiden, und damit wurden Muster in jedem Monat sichtbar. Natur und Parks sind grün, Flughäfen und Bahnhöfe türkis, Restaurants und Cafés meist orange, Wohnungen und Hotels ein dezentes Grau.

Monate, in denen ich viel getaucht bin, sind sehr grün. Als ich in New York war, gibt es viel Rot für italienische Restaurants. Die Japanreise hatte viel Pink für Sushi.

Der Kopf der Seite war gestaltet und programmiert, jetzt musste ich klären, wie die Timelines darunter gefüllt werden. Die Daten waren alle da, sie mussten nur ordentlich präsentiert werden.

Verirrt in Roppongi

Ich war auf dem Rückweg vom Teehaus zu spät dran. Ich hatte die Zeit vergessen, weil ich mit der Frau im Kimono mein Japanisch üben wollte. Ich musste in weniger als einer Stunde aus dem Park Hyatt Tokyo auschecken, war aber quer durch die Stadt entfernt. Laut Google Maps würde es mit der U-Bahn 43 Minuten dauern.

Ich stieg in die Bahn Richtung Azabujuban und war unterwegs. „Das wird schon“, sagte ich mir. „Normalerweise packe ich in weniger als 5 Minuten.“

In der Bahn ließ ich mich davon ablenken, eine witzige Bildunterschrift für mein Instagram-Foto zu finden, und als ich aufsah, fuhr meine Haltestelle gerade vorbei. Ups. Ich stieg an der nächsten aus: Roppongi.

Ich starrte auf den Plan und überlegte, ob ich zurück oder weiter soll, ärgerlich, dass mich das U-Bahn-System, das ich so liebte, ausgerechnet jetzt im Stich ließ. Es dauerte einen Moment, bis mir klar wurde, was ich da eigentlich ansah.

Da war eine Menge Orte, auf einer schmalen Linie, mit viel Text. Alle Beschriftungen leicht gekippt. Große, kräftig gefärbte Kreise unterschieden die Bereiche. Genau danach hatte ich gesucht!

Diese Art, Informationen auf einer Zeitleiste zu zeigen, war die letzte Inspiration, die ich brauchte, um Explorer 2.0 fertig zu gestalten. Die gekippten Beschriftungen lösten mein Stapelproblem, und die großen kräftigen Kreise wären auch in kompakter Form leicht zu verstehen.

Ich wollte die halbe Seite freihalten, um weitere Details des Tages einzuzeichnen, mit den Orten darüber als Kontext, wann und wo etwas passiert ist. Ich spielte mit dem Gedanken, den restlichen Platz mit einer Karte zu füllen.

Es gab viele Dinge, die ich pro Tag zeigen wollte: Schlaf, Essen, Fortbewegung, Stimmung, Blutzucker und so weiter. Fürs Erste nahm ich die Daten, an die ich leicht kam und die sich von Tag zu Tag am stärksten unterschieden: Fortbewegung, GitHub-Commits und Puls.

Die Ortsnamen einzufärben ließ mich sie luftiger verteilen und trotzdem klar mit den farbigen Icons verbinden.

Ich spielte mit einer Karte im Hintergrund. Optisch mochte ich den satten Hintergrundeffekt sehr. Sobald aber andere Daten darüber lagen, wirkte es zu verwirrend.

Statt der Karte probierte ich einen weichgezeichneten Hintergrund aus Instagram-Fotos. Damit bekam jeder Tag einen eigenen, interessanten Untergrund für seine Daten. Die Github-Commits und Deployments füllten die Lücken an den vielen Tagen, an denen ich sonst nichts gemacht habe.

Nach Tagen mühsamen Fortschritts und vieler Experimente, buchstäblich einer Suche rund um die Welt nach der Antwort, fügte sich plötzlich alles zusammen. In dem Moment, als ich die letzte Ebene ergänzte, wusste ich: Das ist es.

Die Designphase war endlich vorbei. Zeit, zu bauen.

Juli 2014: San Francisco

Bis dahin hatte ich vor mir hergeschoben, wie ich das Ganze tatsächlich baue & welchen Tech-Stack ich wähle. Ich wollte meine ganze Zeit ins Design und Frontend stecken, ohne mich von Infrastruktur oder Code ablenken zu lassen. Für das Prototyping beim superschlichten Jekyll zu bleiben war entscheidend, um schnell zu sein und viele Ideen ausprobieren zu können. Weil alles statisch war, konnte ich interessante Versionen leicht wegsichern und später wieder ansehen.

Mein Nachbar warb für Node. Etliche Leute rieten mir zu Rails. Früher hatte ich Django benutzt und mochte es. Ich wusste, dass die Sprache nicht so wichtig ist, ich musste mich nur entscheiden und anfangen zu schreiben.

Ich verbrachte einen Tag mit Ruby on Rails. Viele hatten es empfohlen. Es wirkte wie eine solide Wahl, um später andere Entwickler dazuzuholen. Nachdem ich eine Stunde gebraucht hatte, das Hello-World-Beispiel zum Laufen & live zu bringen, merkte ich, dass es zu langsam vorangeht. Ich musste meine ganze Zeit ins Bauen stecken und nicht in die Feinheiten eines neuen Frameworks.

Ich entschied mich für Python und Django, womit ich vor langer Zeit schon ein Analytics-Startup gebaut hatte. Heroku machte das Deployen und Verwalten der Server viel einfacher, als ich es von AWS kannte. Nach Minuten war die Seite live. Nach Stunden hatte ich alle Seiten-URLs mit leeren Templates verdrahtet. Nach ein paar Tagen liefen die meisten Models und importierten Daten aus verschiedenen APIs. Jetzt lief es rund.

Die meisten Dienste, die ich anbinden wollte, hatten schöne OAuth-2.0-APIs mit guter Dokumentation, es war also überraschend einfach, die Accounts zu verbinden und die Daten zu ziehen, die ich brauchte. Ich richtete im Heroku Scheduler einen Job ein, der alle 10 Minuten nach frischen Daten sucht und alles Neue importiert.

Das Frontend

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

Die Seite lädt eine globale CSS-Datei und eine globale JavaScript-Datei. Diese Dateien werden aus vielen kleineren SASS- und Coffee-Dateien zusammengesetzt, damit beim Entwickeln alles ordentlich und modular bleibt.

In der Entwicklung nutze ich die Mac-App LiveReload, die die Seite sofort neu lädt, wenn ich CSS oder JavaScript ändere. Das spart jedes Mal ein paar Sekunden, extrem hilfreich, wenn man tausende Male iteriert.

Das Backend

• Python
• Django
• Postgres
• Memcached
• Heroku

Heroku hat hilfreiche Tutorials zum Aufsetzen ihres Stacks. Das Deployen ist wirklich simpel: ein „git push heroku master“ und die Änderungen sind live. Ich pushe häufig zu GitHub und zu Heroku, wann immer ich deployen will.

Eine Weile machte ich mir Sorgen um die Performance bei Seiten mit schweren Queries, aber Memcached war die Rettung. Weil die Seite so statisch war & sich nur änderte, wenn neue Daten importiert wurden, konnte ich fast jedes Template cachen & sofort ausliefern.

Endspurt

Dem Designprozess tun häufige Perspektivwechsel und Unterbrechungen gut. Manchmal fällt mir mitten in einem Gespräch etwas ein oder wenn ich auf der Straße etwas sehe.

Beim Entwickeln mag ich dagegen manchmal Tage ohne Unterbrechung, um konzentriert zu bleiben und tausende Zeilen Code im Kopf zu behalten. Meine beiden Mitbewohner waren eine Woche verreist, ich hatte also meine Ruhe.

Die Designs standen und die Daten flossen, es blieb nur eine lange Liste von Fehlern und Performanceproblemen vor dem Launch. Ich beschloss, mich in meinem Zimmer einzuschließen, bis das Ding live ist.

Ich sprang zwischen Frontend und Backend hin und her, brachte mehr echte Daten auf die Seite und räumte sie dann auf.

Wenn ich etwas in CSS baue, arbeite ich zuerst mit extrem simplen Styles am Layout. Ziel ist, dass alles an der richtigen Stelle sitzt, nicht dass es gut aussieht. Der erste Schritt ist sicherzustellen, dass das Backend alles ausgibt, was ich brauche. Das will ich vom Tisch haben, um danach meine ganze Zeit in derselben CSS-Datei zu verbringen. Alles bekommt ein background: red oder background: blue, nur um zu prüfen, ob die Selektoren greifen. Dann kümmere ich mich um Layout und Positionierung und denke an Dinge wie Responsiveness und Sonderfälle. Wenn das steht, mache ich meist ein neues Stylesheet, um alle Designdetails zu ergänzen und es schön zu machen.

Dieselben Farben und Icons wie bei den Sechsecken oben zu nehmen machte es sehr leicht, ein Gefühl für die Arten von Orten eines Tages zu bekommen. Zuhause tauchte ständig auf, war aber nicht besonders spannend, also habe ich es dezenter gemacht, damit die anderen Orte hervortreten: weiße Kreise statt blauer.

Alle Beschriftungen waren jetzt versteckt, jede Timeline damit einfacher und leichter. Ein Klick auf einen Tag öffnete ihn und zeigte mehr.

Als Erstes kamen die Reisedaten dazu, die die Orte miteinander verbinden, zu Fuß, laufend, mit dem Auto und so weiter. Alles war absolut positioniert, ich konnte also jedes Element nach Start- und Endzeit eintragen.

Weichgezeichnete Instagram-Fotos gaben den Tagen interessantere und abwechslungsreichere Hintergründe für die Daten. Danach kamen die echten Pulsdaten für jeden Tag dazu.

Ein bisschen Gestaltung bringt die Seite langsam zusammen. Zwischen den Orten entstehen Bögen, die Art und Dauer der Fortbewegung zeigen. Langweiliges wie Zufußgehen ist ganz klein, ein langer Lauf oder Flug leuchtet kräftig und fällt sofort auf.

Rechts bleibt etwas Platz für die Stadt und die Navigation zum vorigen und nächsten Tag.

Manche Tage hatten viel leeren Raum, es sah aus, als hätte ich nur zu Hause gesessen oder den ganzen Tag geschlafen. Github-Commits füllen die verbleibenden Lücken in der Geschichte und zeigen, wann ich gearbeitet habe und woran.

Monatsseiten

Jetzt, wo jeder Tag & jeder Monat eine Seite hatte, machte ich mich an die Liste der Monate und die Animationen für die Navigation durch alle Seiten.

Anfangs waren die Monate eine vertikale Liste, mit Details zu den Städten und Arten von Orten. Die besten Fotos des Monats geben zusätzlich einen Überblick, was passiert ist.

Ursprünglich als responsive mobile Version gedacht, merkte ich, dass jeder Monat als eigene Kapsel spannender wäre als eine Listenansicht. Jeder Monat wirkt klickbarer und wie ein interaktives Objekt.

Mapbox

Ich wollte einen dezenten Hintergrund mit Gelände und Straßen, um meinen Läufen Kontext zu geben. Google Maps ist großartig, aber ich wollte etwas Anpassbareres, also probierte ich Mapbox aus. Der Dienst wirkte etwas teuer, aber das Einrichten ist wirklich einfach, und ich fand, eine schönere Startseite mit guten Karten wäre die Kosten wert.

Runkeeper liefert während des Laufs alle 5 Sekunden GPS-Koordinaten. Mit der Javascript-Bibliothek von Mapbox habe ich aus diesen Punkten eine SVG-Linie gemacht. Zuerst befürchtete ich komplizierten Code, um die Linie von Anfang bis Ende wachsen zu lassen, aber es war nur ein einfacher CSS-Übergang mit den stroke-dash-Eigenschaften. In diesem Beispiel legt das schrittweise Verringern des Offsets auf 0 die Linie frei.

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

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

Kritikstunde

Jeden Abend kam Stammy von der Arbeit nach Hause und wir gingen die neuen Features und Änderungen durch. Wenn ich feststeckte oder eine zweite Meinung brauchte, schickte ich auch Links oder Screenshots an Yuri, Dustin und andere Freunde. Es hilft enorm, andere Perspektiven zu haben und regelmäßig frische Augen auf ein Projekt zu bekommen. Viele der Ideen kamen ursprünglich aus Gesprächen oder als Reaktion auf Feedback, dass sich etwas nicht ganz richtig anfühlt.

Feedback einzuholen heißt nicht, einfach alles zu tun, was die Leute sagen, oder alles zu entfernen, was jemandem nicht gefällt. Feedback sagt dir, ob das, was du gebaut hast, verständlich ist oder gut funktioniert, aber nicht, was du tun sollst oder wie die Vision aussieht. Vision lässt sich nicht crowdsourcen. Ein Projekt mit lauter Flicken und Hacks für jede einzelne Beschwerde ist am Ende meist schwer weiterzuentwickeln und zu pflegen.

Starkes Feedback ist meistens ein gutes Zeichen, selbst wenn es negativ ist, denn es heißt, dass jemand so beteiligt war, dass er emotional investiert ist. Das ist ziemlich selten. Wenn alle nur unbestimmt reagieren oder nichts zu sagen haben, ist das meist ein schlechtes Zeichen für ein blasses Design. Wenn es alle hassen, kann es furchtbar oder brillant sein, das ist manchmal schwer zu sagen.

Es ist wichtig, ständig Feedback zu holen, aber nicht, beim ersten negativen Wort alles hinzuwerfen oder die ganze Idee zu verwerfen. Ich sammle das meiste für die nächste Runde, außer es gibt ein katastrophales Problem, bei dem man zurück ans Reißbrett muss.

In der aktuellen Version habe ich zum Beispiel viel Rückmeldung bekommen, dass die Bögen für Fortbewegung nicht einleuchten. Es war nicht sinnvoll, den Launch dafür zu verschieben, aber die nächste Version wird das anders lösen.

Es lohnt sich auch, Feedback von ganz unterschiedlichen Menschen zu holen, besonders von weniger technischen oder solchen, die ähnliche Oberflächen nicht gewohnt sind. Es kann frustrierend, aber auch augenöffnend sein, wie unterschiedlich manche denken und bedienen. Deshalb teste ich so gern in Cafés oder mit völlig Fremden, dabei kommen faszinierende Einsichten heraus und man entdeckt Dinge, die einem selbstverständlich schienen und für andere keinen Sinn ergeben.

Selbst das ausgefeilteste und durchdachteste Design hat raue Kanten und profitiert von gründlichem Testen.

Chat Heads

Kontaktformulare sind sowas von 2006. Ich wollte eine spaßige Art, mit Besuchern in Kontakt zu kommen. Meine Theorie war, dass viele etwas zu sagen haben, sich aber von einem offiziell wirkenden Kontaktformular abschrecken lassen. Mir geht es meistens so.

Es sollte sich spaßig, freundlich und menschlich anfühlen, obwohl der Rest der Seite ziemlich futuristisch und automatisiert aussieht. Die Seite sollte cool sein, aber nicht so cool, dass sie einschüchtert.

Ich habe früher jeden Tag über Facebook Chat Heads mit Leuten geschrieben. Das war ein sehr natürliches Design & eine natürliche Art zu kommunizieren. So etwas wollte ich hier auch, etwas, das die meisten schon kennen. Später könnten Leute sogar in Echtzeit über Messenger mit mir sprechen, mit der Seite als Chat-Client.

Über-Seite

Dieses Projekt stützte sich auf viel andere Software und Hardware. Ich wollte einen guten Weg, allen die Ehre zu geben und alle Werkzeuge zu zeigen, die ich nutze. Also machte ich eine schlichte „powered by“-Reihe mit den Logos aller Partner, deren Name und Beitrag beim Überfahren erscheinen.

Ich habe ein paar Burrito-Statistiken ergänzt, damit es persönlicher und spaßiger wirkt und nicht nur wie ein medizinisches Dashboard. Denn wer mag keine Burritos?

Powered by Zucker

Gegen Ende habe ich Unmengen Zucker gegessen, um konzentriert zu bleiben und die Nächte durchzuarbeiten. Für meinen Körper war das furchtbar, aber es ließ mich ein paar Stunden lang klar denken und fast jedes Problem lösen. Je härter das Problem, desto mehr Zucker brauche ich dafür.

11. Juli 2014

Launch-Tag

Es war Freitag. Die Seite war fast fertig, also fuhr ich für den letzten Feinschliff zu Alex. Ein zweites Paar Augen ist bei so etwas immer gut, und einen der weltbesten Javascript-Experten dabeizuhaben schadet auch nicht.

Auf meiner Todo-Liste standen nur noch Kleinigkeiten: die Chat Heads anschließen, damit sie wirklich Nachrichten schicken, Twitter-Buttons ergänzen, Meta-Beschreibungen korrigieren, den ersten Artikel schreiben, die CDN-Assets aktualisieren, den Launch-Tweet finden und so weiter.

In den paar Stunden, die wir da saßen und arbeiteten, baute er eine Chrome-Erweiterung, die unseren Alterszähler als Startbildschirm zeigt.

Wir diskutierten kurz, ob Freitagabend zu spät für einen Launch ist oder ob es mehr Sinn ergibt, bis Montag zu warten, wenn alle wieder am Rechner sitzen. Wahrscheinlich wäre es klug gewesen, noch ein paar Tage zu warten, aber ich war nach einer Woche pausenlosem, adrenalingetriebenem Programmieren erschöpft und hatte das Gefühl: jetzt oder nie.

Ich änderte ein paar DNS-Einstellungen, setzte einen Tweet ab, und wir waren live!

Weil Freitagabend war, kamen fast alle ersten Aufrufe vom Handy. Ich hatte die meiste Zeit mit der Desktop-Version verbracht, aber die Mehrheit erlebte die einfache mobile Umsetzung.

Zum Glück hatte ich gegen Ende so viel Zeit ins responsive Design gesteckt. Allen schien es zu gefallen und sie teilten es direkt vom Handy. Würde ich das noch einmal machen, würde ich mehr Zeit ins mobile Erlebnis stecken, weil es für viele der erste und oft einzige Zugang ist.

Alles lief glatt, bis mir Stammy eine DM schickte, ich wöge 1517 Pfund. Das war ziemlich seltsam, ich fühlte mich deutlich leichter.

Ich hatte den Code der Sport-Seite lange nicht angefasst, sie hätte also nicht plötzlich kaputtgehen dürfen. Im Quelltext sah ich, dass der Rohwert ein Komma statt eines Punkts hatte: 151,7 statt 151.7. Javascript ignorierte das Komma und las die Zahl falsch. Ich habe den Cache geleert und die Seite war wieder normal. Merkwürdig…

Später am Abend saß ich in einer Bar und zeigte einem Freund die Seite auf meinem Handy, als mir auffiel, dass einer der Seitentitel auf Russisch war. Seltsam. Ich brachte das sofort mit dem Fehler von vorhin zusammen, beides müsste von irgendeinem außer Rand und Band geratenen Internationalisierungscode kommen.

Natürlich musste ich nach Hause und der Sache nachgehen.

Es lag an einer simplen Einstellung in Django, mit aktivierter Internationalisierung (meist als i18n abgekürzt) für Dinge wie Zahlen und Datumsangaben. Zusammen mit dem Caching wurden bestimmte Abschnitte beschädigt, nachdem sie aus dem Ausland abgerufen worden waren. Das Feature abzuschalten war ein Einzeiler und sorgte für ein einheitliches Erlebnis für alle auf der Welt.

Das war nur eines von vielen Beispielen, bei denen ein kleiner, unscheinbarer Hinweis auf einen Fehler zeigt, den man finden muss.

In dieser Nacht schlief ich erschöpft, aber glücklich ein, nach einer langen Arbeitswoche. Die Seite war endlich live, und ein paar tausend Leute hatten sie über meinen Tweet gesehen. Ich wollte am Wochenende ausspannen und mir dann in der nächsten Woche überlegen, wie ich sie mit der Welt teile. Das war dann gar nicht mehr nötig…

Am nächsten Morgen

Innerhalb weniger Stunden, während ich schlief, hatten Leute sie auf Reddit, Hacker News und überall im Internet gepostet. Ich war um 7 Uhr mit einem Freund zum Laufen verabredet, deshalb war ich für meine Verhältnisse ungewöhnlich früh wach. Zum Glück.

Mein Handy explodierte vor Benachrichtigungen. Ein paar hundert Tweets, jede Menge E-Mails. Ich versuchte die Seite zu laden, und sie war extrem langsam. Ich sah in die Analytics und der Traffic war in den letzten Stunden durch die Decke gegangen, unter der Last reagierte fast nichts mehr. Zum Glück war das Hochskalieren mit Heroku ziemlich einfach, und ich ging von 2 auf 8 Dynos. Mit genug Webservern für den extremen Andrang lud wieder alles sofort.

Innerhalb weniger Stunden hatte die Seite hunderttausend Besucher, am Nachmittag zweihunderttausend. Offenbar gefiel sie den Leuten. Die Tweets und Nachrichten hörten nicht auf!

Es war sehr demütigend, wie viele verschiedene Menschen sie kommentierten und teilten, gerade weil ich nicht sicher war, ob sie überhaupt jemand versteht oder mag. Ein paar Tweets haben mir besonders den Tag gerettet, von Leuten, die ich sehr bewundere.

Mir fiel auf, dass hunderte Leute dieselben Fragen stellten:

• Wie hast du die Animationen gemacht?
• Welche Technologien nutzt du?
• Woher kennst du deine Blutwerte?
• Wie bekomme ich das für mich selbst?

Nachdem ich die ersten 10 oder 20 beantwortet hatte, wurde mir klar, dass ich die ganze Geschichte von Anfang bis Ende aufschreiben sollte. Der Prozess war zu spannend, um ihn nicht zu teilen. Ich hatte hunderte alte Skizzen, Mockups und Prototypen, die noch nie jemand gesehen hatte.

Und so hat dieser Beitrag angefangen…

Epilog

Ich hatte die Seite vor allem als mein persönliches Spielzeug gestaltet. Ich wusste, das ist die Zukunft, war mir aber nicht sicher, ob sonst jemand den täglichen Aufwand für all diese Daten für lohnend hält. Aber offenbar fanden es zumindest ein paar andere sehr spannend. Nach dem Launch bekam ich hunderte Nachrichten von Leuten, die fragten, wie sie so etwas selbst bekommen.

Ein paar Monate später beschloss ich, eine Firma zu gründen: Gyroscope. Sie läuft inzwischen, und jeder kann sich anmelden und anfangen, sein Leben zu tracken.