La fabrication d’April Zero : partie 2

La fabrication d’April Zero

Partie 2

Mon processus de design est différent à chaque fois.

Pour theory11, je me suis mis dans le bon état d’esprit en faisant des tours de magie à des inconnus dans les rues de Los Angeles. J’ai trouvé le styleguide de Quizlet en saut en parachute au-dessus d’Hawaï, en voyant l’eau bleue, le sable ocre et les vagues blanches pendant la chute libre. La palette de mon site précédent était empruntée à une Ducati rouge.

Et la création de ce site-ci a été un chemin encore plus détourné : des aventures aux quatre coins du monde, de nouveaux gadgets et des expériences sur moi-même. Le tout pour la recherche & développement, bien sûr.

Après avoir testé un tas d’apps et de matériel pendant quelques mois, j’avais arrêté la panoplie finale, celle qui offrait la mesure la plus automatique pour le moins de temps passé.

• L’app iPhone Moves : pour la position
• L’app iPhone Cardiio : pour ma fréquence cardiaque
• Instagram : pour mes photos
• L’app iPhone Runkeeper ‐ pour suivre mes courses
• La balance sans fil Withings : pour le poids quotidien
• Le tensiomètre Withings : fréquence cardiaque et tension
• L’échographe Bodymetrix : pour le taux de masse grasse
• Des analyses de sang mensuelles : pour les triglycérides et les nutriments

Mai 2014 : Thaïlande

Je voyageais en Asie avec Dustin Curtis et j’esquissais des idées pour la version mobile du site. J’essayais d’imaginer quelque chose qui tire parti du contexte mobile, quelque chose que je trouverais utile chaque jour en déplacement.

Je voulais éviter de créer un truc qu’on explore une fois puis qu’on oublie. Je voulais qu’il soit en changement constant, mis à jour en temps réel, et qu’il mette en avant ce qui compte le plus à l’instant : un nouveau lieu, une alerte de fréquence cardiaque élevée, ou simplement une vue d’ensemble de l’état de santé.

Je voulais concevoir pour l’avenir tout proche où ces données seront disponibles en permanence, en ignorant certaines limites du présent. Aujourd’hui, ces chiffres ne se mettent pas à jour en continu : le poids une fois par jour environ, les analyses de sang une fois par mois seulement, et la fréquence cardiaque uniquement quand je la mesure, quelques fois par jour.

Je parie que d’ici quelques années, sinon plus tôt, du matériel existera pour rendre ces données bien plus automatiques et continues. Si Apple ou un autre grand acteur ne trouve pas la solution dans l’année, quelqu’un le fera sur Kickstarter.

Une expérience mobile qui m’enthousiasmait était une surimpression en réalité augmentée avec toutes mes constantes. L’image de la caméra pouvait être floutée pour donner l’illusion d’un téléphone transparent, et les informations flotteraient à différents niveaux au-dessus. C’était impossible à faire dans le navigateur, mais je reviendrai peut-être un jour à cette idée sous forme d’app.

L’idée de voir toutes les informations d’un coup d’œil depuis mon téléphone m’excitait, et j’ai continué à essayer de tout faire tenir dans un seul tableau de bord intuitif.

École de plongée

J’ai atterri à Koh Tao, une petite île de la côte est de la Thaïlande. Elle est réputée pour la plongée, alors j’ai décidé de passer mon niveau.

La journée, j’allais à l’école de plongée, et le soir je faisais de nouvelles maquettes mobiles. Je reliais Photoshop sur mon Macbook à Skala Preview sur mon iPhone pour voir chaque design en contexte. Je prenais mon téléphone et je marchais avec chaque page ouverte, pour sentir ce que ça donnait.

Cela m’a aidé à régler beaucoup de détails de design, comme l’échelle et la lisibilité. « Jusqu’où puis-je réduire le texte ? » « Quel contraste me faut-il pour lire en extérieur ? » « Combien d’informations puis-je faire tenir dans un écran ? »

Les anneaux qui tournaient discrètement en haut rappelaient la version bureau et donnaient du caractère. Au début ils étaient trop marqués, alors j’ai baissé l’opacité et les couleurs jusqu’à ce qu’on les remarque à peine.

Je me promenais avec des captures d’écran sur mon téléphone et je les montrais aux gens autour de moi.

« À ton avis, qu’est-ce que cette page essaie de te dire ? » « Sur quoi appuierais-tu ? »

Au début, les gens avaient du mal à comprendre tout ce qui était entassé sur la page. Dan ne savait pas quelle colonne regarder en premier. Dustin se plaignait que tout était trop petit. Les autres, sur le bateau, se demandaient sans doute pourquoi j’avais emporté mon ordinateur.

J’ai compris que l’idée de tout faire tenir sur la page ne marcherait pas, et j’ai commencé à ne garder que les statistiques les plus pertinentes.

À Bangkok, nous sommes allés dans plusieurs hôpitaux pour essayer d’obtenir une IRM corps entier pas chère, mais c’était trop cher, plus de quelques milliers de dollars. En attendant, je m’étais vraiment attaché à l’idée d’avoir une vue médicale complète de moi-même, et j’ai décidé de l’ajouter à la page pour donner une impression plus clinique et scientifique. J’ai utilisé une image d’archive d’une personne quelconque pour commencer, en prévoyant de la remplacer plus tard par une vraie image de moi.

J’aimais beaucoup le rendu de cette coupe du corps humain, surtout comparé à quelque chose de plus banal comme la carte. Un simple coup d’œil sur la page donnait une bonne idée de la situation, et les données restaient accessibles en regardant de plus près les barres et les chiffres. Avec de bonnes animations, ce serait encore mieux. Je voulais qu’il soit clair que c’était un lien en temps réel avec une personne vivante, et pas juste une série de graphiques médicaux ennuyeux.Il fallait éviter le piège des dizaines de camemberts & d’anneaux génériques dans lequel tombent beaucoup d’apps.

J’essayais de raconter une histoire, pas seulement de montrer une série de mesures médicales.

À ce stade, le design commençait à m’enthousiasmer. La fréquence cardiaque serait particulièrement chouette une fois les données en temps réel chargées. Je ne savais pas si l’animation de l’IRM était possible, mais c’était le premier design mobile qui me semblait enfin à la hauteur de l’expérience sur ordinateur.

Il était prêt à être codé. Alors que nous descendions vers la Malaisie, j’ai passé les jours suivants à essayer de construire les animations.

Après quelques jours d’expérimentation, j’ai trouvé comment simuler le scan et la lueur de l’IRM en CSS. J’ai ajouté un point de rupture autour de 600 px et j’ai commencé à travailler la mise en page mobile dans le navigateur. Quand je m’en suis approché, je l’ai chargée sur mon téléphone depuis l’adresse IP de mon ordinateur pour tester et optimiser directement sur le matériel de l’iPhone.

Le mobile enfin réglé, il était temps de revenir finir l’expérience Explorer sur ordinateur.

La version précédente était belle, mais représentait une surcharge d’informations. Je devais trouver comment afficher mon activité quotidienne de façon plus compacte et plus compréhensible. Je soupçonnais que la solution passerait par plus de niveaux de navigation, en réduisant chaque chronologie à une version plus simple jusqu’à ce qu’on demande plus de détails pour la journée.

J’ai du mal à réfléchir le ventre vide, alors j’ai décidé de me remplir d’abord de sushis et de trouver ensuite le design final.

Juin 2014 : Japon

Petit déjeuner à Tsukiji

J’ai atterri à Tokyo le lendemain matin et je suis allé au marché aux poissons de Tsukiji, le poisson le plus frais du monde.

Après un mois de voyage en bateaux cahotants et en trains lents, circuler dans le métro japonais, ponctuel et efficace, m’a paru fantastique. Je voulais que mon site donne la même impression : on clique partout, on arrive dans de nouveaux endroits et on est sûr que rien ne va se casser. Ce serait rapide et net. Tous les timings seraient parfaits à la milliseconde près.

Une heure plus tard, j’étais inspiré, je n’avais plus faim et j’étais prêt à finir le design du site.

J’ai installé un petit bureau à mon hôtel et je m’y suis mis. J’ai décidé de régler le mobile d’abord puis d’agrandir, pour être sûr de ne pas inventer un truc fou qui ne marcherait jamais en petit.

J’avais passé le mois précédent à me demander dans quel sens le temps devait s’écouler sur mobile. L’activité la plus récente devait-elle arriver par le haut ? C’est ainsi que fonctionnent la plupart des fils, comme Facebook ou Twitter. Ou fallait-il un ordre chronologique, comme un calendrier, à partir du premier jour ?

Le problème, c’est qu’il n’y avait pas une seule bonne réponse. C’était à la fois un flux en temps réel de mon activité et un calendrier de ce que j’avais fait. Chacun appelait un design opposé, et je ne pouvais en choisir qu’un.

Après avoir maquetté beaucoup de vraies données dans les deux sens, j’ai compris que j’attendais plus souvent l’ordre chronologique et que, sinon, je me trompais souvent en lisant la page.

J’ai fini par décider que chaque page de mois commencerait à minuit le premier jour. Le contenu le plus récent en bas, le plus ancien en haut.

J’utilisais Google Maps pour me déplacer et leur design mobile m’inspirait. Leur chronologie d’itinéraires est toujours nette et fiable.

Obtenir la même impression voulait dire supprimer beaucoup des données que j’essayais d’entasser dans les marges. L’utilisabilité et la simplicité comptaient plus pour l’expérience mobile que d’avoir toutes les informations dans une seule vue.

J’avais cherché des façons astucieuses de montrer le lever et le coucher du soleil, les photos de la journée, etc. C’étaient de belles données, mais elles ajoutaient trop de complexité. La nouvelle version était bien plus simple : juste la liste des lieux visités.

J’ai mis à jour le contenu avec l’activité du jour et supprimé presque tout le reste. Il manquait beaucoup d’informations, mais l’ensemble devenait bien plus net. C’était enfin quelque chose que je pouvais utiliser facilement sur mon téléphone ou partager.

Plus tard ce jour-là, Apple a annoncé HealthKit à la WWDC. Ce n’était pas tout à fait aussi formidable que je l’espérais, aucun matériel révolutionnaire ne l’accompagnait, mais le compte à rebours était officiellement lancé.

Le caractère clinique et médical de leur design m’a aussi fait comprendre à quel point Explorer était vital, bien plus que je ne l’avais imaginé au départ. Les données de lieu et de voyage allaient donner du contexte et du sens à ce qui, autrement, ne serait qu’un assortiment de points de données déconnectés, de simples anecdotes.

Il me restait quelques jours au Japon avant de rentrer construire et lancer ce truc. Après tout, les vrais artistes livrent.

Cérémonie du thé

Le lendemain matin, je suis parti courir longuement dans le parc. Je voulais me vider la tête et laisser venir l’inspiration. Après avoir lu sur HealthKit, j’avais l’esprit plein d’idées folles pour transformer la forme physique en jeu ou prévenir les crises cardiaques par algorithme.

Ensuite, j’ai décidé d’assister à une cérémonie du thé japonaise traditionnelle. Elle se déroulait dans un magnifique jardin, autour d’un bassin à carpes koï et beaucoup de verdure. Une femme en kimono jouait avec les poissons à côté.

Le premier service était une petite douceur, posée sur un dessous de verre hexagonal en bois. Cela m’a rappelé un concept que j’esquissais un peu plus tôt. J’avais à peu près renoncé aux hexagones, puisqu’ils ne s’emboîtent pas les uns dans les autres comme les rectangles.

Je cherchais en vain un en-tête marquant à placer en haut de chaque page de mois. Les cercles de la version précédente étaient nets, mais ni très mémorables ni très excitants. La cérémonie du thé m’a fait penser qu’il était peut-être temps de revenir aux hexagones.

J’aimais l’idée d’un élément visuellement intéressant capable de porter énormément d’information. Comme le concept reposait autant sur le contenu, il valait mieux commencer à construire directement avec les vraies données que d’essayer de faire une maquette fidèle avec des centaines d’icônes dynamiques.

Voici la première version codée. Elle n’était pas très jolie, mais elle apportait le contenu réel et posait la structure des éléments avec lesquels j’allais jouer.

Transformer chaque élément en hexagone n’était qu’un simple masque d’image en CSS. L’ensemble des lieux était légèrement manipulé dans l’espace 3D pour une perspective plus intéressante. Un léger ombrage sur les bords garde l’attention au centre.

Les catégories de lieux de Foursquare ont fait le gros du travail ici, en fournissant une taxonomie et de belles icônes pour les représenter.

J’ai mis en place un code couleur pour distinguer facilement les lieux, ce qui a révélé des motifs propres à chaque mois. La nature et les parcs sont verts, les aéroports et les gares turquoise, les restaurants et les cafés surtout orange, et les logements ou hôtels d’un gris discret.

Les mois où j’ai beaucoup plongé sont très verts. Quand j’étais à New York, il y a beaucoup de rouge pour les restaurants italiens. Le voyage au Japon est plein de rose pour les sushis.

Le haut de la page étant conçu et codé, il fallait maintenant remplir les chronologies en dessous. Les données étaient toutes là, il ne restait qu’à bien les présenter.

Perdu à Roppongi

J’étais en retard en revenant de la maison de thé. J’avais perdu la notion du temps en essayant de pratiquer mon japonais avec la femme en kimono. Je devais libérer ma chambre au Park Hyatt Tokyo dans moins d’une heure, et j’étais à l’autre bout de la ville. D’après Google Maps, il fallait 43 minutes en métro.

J’ai pris la ligne vers la station Azabujuban et j’étais en route. « Ça va aller », me suis-je dit. « D’habitude, je fais mes valises en moins de 5 minutes. »

Une fois dans le train, je me suis laissé distraire à chercher une légende spirituelle pour ma photo Instagram, et quand j’ai relevé la tête, mon arrêt défilait déjà. Zut. Je suis descendu au suivant : Roppongi.

Je fixais le plan en essayant de décider s’il fallait revenir en arrière ou continuer, furieux que ce métro que j’aimais tant m’ait lâché au pire moment. Il m’a fallu un moment pour comprendre ce que je regardais vraiment.

Il y avait là une série de lieux, sur une petite ligne avec beaucoup de texte. Toutes les étiquettes étaient légèrement inclinées. D’énormes cercles aux couleurs vives distinguaient les zones. C’était exactement ce que je cherchais !

Cette façon d’afficher l’information sur une ligne de temps a été la dernière inspiration qu’il me fallait pour finir le design d’Explorer 2.0. Les étiquettes inclinées réglaient mon problème d’empilement, et les gros cercles bien nets seraient faciles à comprendre dans un format compact.

Je voulais réserver la moitié de la page à d’autres détails de la journée, en me servant des lieux du haut pour donner le contexte de quand et où ils s’étaient produits. J’ai joué avec l’idée de remplir l’espace restant par une carte.

Il y avait beaucoup de choses que je voulais tracer chaque jour : le sommeil, la nourriture, les transports, l’humeur, la glycémie, etc. Pour l’instant, j’allais utiliser les données auxquelles j’avais facilement accès et qui variaient le plus d’un jour à l’autre : les transports, les commits GitHub et la fréquence cardiaque.

Colorer les noms de lieux m’a permis de mieux les espacer tout en gardant un lien visuel fort avec les icônes colorées.

J’ai testé l’idée d’une carte en fond. Visuellement, j’aimais beaucoup la richesse que cela apportait. Mais c’était trop confus dès que des données sans rapport se plaçaient par-dessus.

À la place de la carte, j’ai essayé un fond flouté de photos Instagram. Cela donnait à chaque jour une toile de fond unique et intéressante pour ses données. L’historique des commits et des déploiements Github comblerait les vides pour les nombreux jours où je n’avais rien fait d’autre.

Après des jours de progrès lents et d’essais, à chercher littéralement la réponse aux quatre coins du monde, tout s’est assemblé d’un coup. Dès l’instant où j’ai ajouté la dernière couche, j’ai su que c’était la bonne.

La phase de design était enfin terminée. Il était temps de construire.

Juillet 2014 : San Francisco

Jusque-là, j’avais repoussé la question de la construction & du choix de la pile technique. Je voulais consacrer tout mon temps au design et au frontend sans me laisser distraire par l’infrastructure ou le code . Rester sur Jekyll, ultra simple, pour le prototypage a été essentiel pour aller vite et tester beaucoup d’idées. Avec un site entièrement statique, je pouvais facilement mettre de côté les versions intéressantes pour y revenir plus tard.

Mon voisin défendait Node. Pas mal de gens me conseillaient Rails. Par le passé, j’avais utilisé Django et j’avais aimé. Je savais que le langage n’avait pas vraiment d’importance, il fallait juste en choisir un et commencer à écrire.

J’ai passé une journée à jouer avec Ruby on Rails. Beaucoup de gens me l’avaient recommandé. Cela semblait un choix solide pour impliquer d’autres développeurs plus tard. Après une heure passée à faire tourner & publier l’exemple Hello World, j’ai compris que ça avançait trop lentement. Je devais passer tout mon temps à construire, pas à apprendre les subtilités d’un nouveau framework.

J’ai choisi Python et Django, que j’avais déjà utilisés pour monter une startup d’analytics il y a longtemps. Heroku rendait le déploiement et la gestion des serveurs bien plus faciles que ce que j’avais connu avec AWS. En quelques minutes, le site était en ligne. En quelques heures, toutes les URL des pages étaient branchées sur des templates vides. En quelques jours, la plupart des modèles tournaient et importaient des données depuis diverses API. Là, ça commençait à chauffer.

La plupart des services que je voulais intégrer avaient de bonnes API OAuth 2.0 bien documentées, donc connecter les comptes et récupérer les données a été étonnamment simple. J’ai programmé une tâche dans le scheduler Heroku pour vérifier toutes les 10 minutes s’il y avait du nouveau et l’importer le cas échéant.

Le frontend

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

Le site charge un fichier CSS global et un fichier JavaScript global. Ils sont concaténés à partir d’une série de fichiers SASS et Coffee plus petits, pour rester organisé et modulaire pendant le développement.

En développement, j’utilise l’app Mac LiveReload pour recharger le site instantanément dès que je modifie du CSS ou du JavaScript. Cela fait gagner quelques secondes à chaque changement, ce qui est extrêmement utile quand on itère des milliers de fois.

Le backend

• Python
• Django
• Postgres
• Memcached
• Heroku

Heroku propose de bons tutoriels pour mettre en place leur pile. Le déploiement est très simple : un « git push heroku master » et les changements sont en ligne. Je pousse souvent sur GitHub, et sur Heroku dès que je veux déployer.

Les performances des pages aux requêtes lourdes m’ont inquiété un moment, mais Memcached m’a sauvé. Comme le site était très statique & ne changeait qu’à l’import de nouvelles données, j’ai pu mettre presque tous les templates en cache & les servir instantanément.

Dernière ligne droite

Le travail de design gagne à changer souvent de point de vue et à être interrompu. Il m’arrive de trouver une solution au milieu d’une conversation, ou après avoir remarqué quelque chose dans la rue.

En revanche, pour développer, j’aime parfois avoir des journées ininterrompues pour me concentrer et garder des milliers de lignes de code en tête. Mes deux colocataires étaient partis pour une semaine, donc j’avais la paix.

Les designs étant réglés et les données affluant, il ne restait qu’une longue liste de bugs et de problèmes de performance à corriger avant le lancement. J’ai décidé de m’enfermer dans ma chambre jusqu’à ce que le truc soit en ligne.

Je faisais des allers-retours entre le frontend et le backend, en ajoutant des données réelles à la page puis en la nettoyant.

Quand je construis quelque chose en CSS, je travaille d’abord la mise en page avec des styles extrêmement simples. Le but est de mettre chaque chose au bon endroit, pas de faire joli. La première étape est de vérifier que le backend sort bien tout ce dont j’ai besoin. Je veux régler ça une fois pour toutes et pouvoir ensuite passer tout mon temps dans le même fichier CSS. Tout reçoit un background: red ou background: blue simplement pour vérifier que les sélecteurs fonctionnent. Je m’occupe ensuite de la mise en page et du positionnement, en pensant au responsive et aux cas limites. Une fois cela réglé, je crée en général une nouvelle feuille de style pour tous les détails de design et rendre le tout joli.

Reprendre les mêmes couleurs et les mêmes icônes que les hexagones du haut permettait de saisir très vite les types de lieux d’une journée. « Maison » revenait sans arrêt mais n’avait rien de passionnant, alors je l’ai rendu plus discret pour laisser ressortir les autres lieux : des cercles blancs plutôt que bleus.

Toutes les étiquettes étaient maintenant masquées, ce qui rendait chaque chronologie plus simple et plus légère. Cliquer sur une journée l’ouvrait pour révéler plus d’informations.

La première chose ajoutée a été les déplacements, reliant les lieux entre eux à pied, en courant, en voiture, etc. Tout était positionné en absolu, ce qui me permettait de placer chaque élément selon ses heures de début et de fin.

Les photos Instagram floutées donnaient aux journées des fonds plus intéressants et plus variés pour afficher les données. J’ai ensuite ajouté les vraies fréquences cardiaques de chaque jour.

Un peu de style commence à assembler la page. Des arcs relient chaque lieu pour montrer le type et la durée du trajet. Les choses banales comme la marche sont toutes petites, mais une longue course ou un vol s’affichent en couleurs vives pour être vus tout de suite.

Un peu de place est réservée à droite pour afficher la ville et la navigation vers les jours précédent et suivant.

Certaines journées avaient beaucoup de vide : on aurait dit que je restais chez moi ou que je dormais toute la journée. Les commits Github comblent les trous restants du récit et révèlent quand je travaillais et sur quoi.

Les pages de mois

Maintenant que chaque jour & chaque mois avait sa page, je me suis attaqué à la liste des mois et aux animations de navigation entre toutes les pages.

Au début, les mois formaient une liste verticale, avec des détails sur les villes et les types de lieux visités. Les meilleures photos du mois aident aussi à donner une vue d’ensemble de ce qui s’est passé.

Conçue au départ comme la version mobile responsive, j’ai réalisé que faire de chaque mois une capsule serait plus excitant qu’une liste. Chaque mois donnerait davantage envie de cliquer et ressemblerait à un objet interactif.

Mapbox

Je voulais un fond discret avec le relief et les rues pour donner du contexte à mes courses. Google Maps est formidable, mais je voulais quelque chose d’un peu plus personnalisable, alors j’ai essayé Mapbox. Le service semblait un peu cher, mais l’installation est vraiment simple et je me suis dit que cela valait largement le coût pour avoir une plus belle page d’accueil avec de bonnes cartes.

Runkeeper fournit une série de coordonnées GPS toutes les 5 secondes pendant la course. J’ai utilisé la bibliothèque javascript de Mapbox pour créer une ligne SVG à partir de ces points. Au début, je craignais de devoir écrire du code compliqué pour animer la ligne qui se dessine du début à la fin, mais c’est en fait une simple transition CSS avec les propriétés stroke-dash. Dans cet exemple, réduire l’offset à 0 révèle progressivement la ligne.

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’heure de la critique

Chaque soir, Stammy rentrait du travail et nous passions en revue les nouveautés et les changements. J’envoyais aussi des liens ou des captures à Yuri, Dustin et d’autres amis quand je bloquais ou qu’il me fallait un deuxième avis. Cela aide vraiment d’avoir le regard des autres et de faire relire un projet par des yeux neufs. Beaucoup d’idées sont nées de discussions ou en réponse à un retour disant que quelque chose n’allait pas tout à fait.

Recueillir des retours ne consiste pas à faire tout ce que les gens disent, ni à retirer ce qui ne leur plaît pas. Un retour vous dit si ce que vous avez fait est compréhensible et fonctionne bien, pas ce qu’il faut faire ni quelle doit être la vision. La vision ne se crowdsource pas. Un projet bourré de rustines et de bidouilles pour répondre à chaque plainte finit en général par être difficile à faire évoluer et à maintenir.

Un retour tranché est en général bon signe : même négatif, il veut dire que la personne était assez impliquée pour s’attacher émotionnellement. C’est en fait rare. Si les retours de tout le monde sont flous ou que personne n’a rien à dire, c’est plutôt mauvais signe, celui d’un design sans souffle. Si tout le monde déteste, c’est peut-être nul ou génial : parfois, difficile de trancher.

Il est important de recueillir des retours en permanence, mais sans tout laisser tomber ni jeter l’idée entière au premier commentaire négatif. En général, je regroupe ces points pour la révision suivante, sauf en cas de problème catastrophique qui oblige à repartir de zéro.

Par exemple, sur la version actuelle, on m’a beaucoup dit que les arcs des déplacements n’étaient pas clairs. Cela n’avait pas de sens de repousser le lancement pour les corriger, mais la prochaine version que nous publierons adoptera une autre approche.

Cela vaut aussi la peine de demander leur avis à des profils très différents, en particulier des gens peu techniques ou peu habitués à ce genre d’interfaces. C’est parfois frustrant, mais aussi révélateur de voir à quel point certains pensent et interagissent autrement. C’est pour cela que j’aime beaucoup tester dans des cafés ou avec de parfaits inconnus : on recueille des observations fascinantes et on découvre des choses qui semblaient évidentes mais n’ont aucun sens pour les autres.

Même le design le plus abouti et le mieux pensé aura des aspérités et gagnera à être testé sérieusement.

Les têtes de chat

Les formulaires de contact, c’est tellement 2006. Je voulais une façon amusante d’échanger avec les visiteurs. Ma théorie était que beaucoup de gens ont quelque chose à dire, mais que la plupart sont intimidés par un formulaire de contact à l’air officiel. Moi le premier, en général.

Je le voulais amusant, chaleureux et humain, même si le style visuel du reste du site était plutôt futuriste et automatisé. Je voulais un site cool, mais pas au point d’intimider les gens.

J’utilisais les têtes de chat de Facebook tous les jours pour parler aux gens. C’était un design & un mode de communication très naturels. Je voulais la même interaction ici, une chose à laquelle la plupart des gens seraient déjà habitués. À l’avenir, je pourrais même discuter en direct avec les visiteurs via Messenger, en utilisant le site comme client de chat.

La page à propos

Ce projet s’appuyait sur beaucoup d’autres logiciels et matériels. Je voulais une bonne façon de créditer tout le monde et de partager les outils que j’utilise. J’ai décidé de faire une simple série de logos « powered by » avec tous les partenaires, leur nom et leur contribution visibles au survol.

J’ai ajouté quelques statistiques sur les burritos pour rendre l’ensemble plus amusant et plus personnel, pas juste un tableau de bord médical. Parce qu’enfin, qui n’aime pas les burritos ?

Propulsé au sucre

Vers la fin, j’avalais des quantités énormes de sucre pour rester concentré et travailler toute la nuit. C’était terrible pour mon corps, mais ça me permettait de penser clairement quelques heures et de résoudre à peu près n’importe quel problème. Plus le problème est dur, plus il me faut de sucre pour en venir à bout.

11 juillet 2014

Le jour du lancement

C’était un vendredi. Le site était presque prêt, alors j’ai décidé d’aller chez Alex pour les dernières finitions. C’est toujours bien d’avoir une deuxième paire d’yeux pour ce genre de chose, et avoir sous la main l’un des meilleurs experts mondiaux de Javascript ne gâche rien.

Ma liste de tâches n’était plus qu’un tas de petites choses : brancher les têtes de chat pour qu’elles envoient vraiment des messages, ajouter les boutons twitter, corriger les meta descriptions, écrire le premier article, mettre à jour les fichiers du CDN, trouver le tweet de lancement, etc.

Pendant les quelques heures où nous sommes restés là à travailler, il a fabriqué une extension Chrome pour afficher notre compteur d’âge en page de démarrage.

Nous avons brièvement débattu de la question : le vendredi soir était-il trop tard pour lancer, ou valait-il mieux attendre lundi, quand tout le monde serait de retour devant son ordinateur ? Il aurait sans doute été sage d’attendre quelques jours de plus, mais j’étais épuisé après une semaine de code non-stop à l’adrénaline et j’avais le sentiment que c’était maintenant ou jamais.

J’ai modifié quelques réglages DNS, publié un tweet, et nous étions en ligne !

Comme c’était vendredi soir, presque toutes les premières visites venaient du mobile. J’avais passé l’essentiel de mon temps sur la version bureau, mais la majorité des gens découvraient l’implémentation mobile, la plus sommaire.

Heureusement que j’avais consacré autant de temps au responsive vers la fin. Tout le monde semblait aimer et partager depuis son téléphone. Si c’était à refaire, je passerais plus de temps sur l’expérience mobile, en sachant que c’est la première et souvent la seule façon dont beaucoup de gens la découvrent.

Tout semblait aller pour le mieux jusqu’à ce que je reçoive un message de Stammy m’annonçant que je pesais 1517 livres. C’était plutôt étrange, je me sentais bien plus léger.

Je n’avais pas touché au code de la page Sport depuis longtemps, elle n’aurait pas dû casser d’un coup. En regardant le code source de la page, la valeur brute contenait une virgule au lieu d’un point : 151,7 et non 151.7. Javascript ignorait la virgule et l’interprétait mal. J’ai vidé le cache et la page est redevenue normale. Bizarre…

Plus tard ce soir-là, j’étais dans un bar en train de montrer le site à un ami sur mon téléphone quand j’ai remarqué que l’un des titres de page était en russe. Étrange. J’ai tout de suite fait le lien avec le bug précédent : les deux devaient venir d’un code d’internationalisation devenu fou.

Évidemment, il a fallu rentrer enquêter.

C’était dû à un simple réglage de Django, avec l’internationalisation (souvent abrégée en i18n) activée pour les nombres et les dates. Combinée au système de cache, elle corrompait certaines sections après des requêtes venues de l’étranger. Désactiver cette option a demandé une seule ligne et garanti une expérience identique pour tout le monde, partout dans le monde.

Ce n’était qu’un exemple parmi d’autres où un indice minuscule et obscur signale un bug qu’il faut aller débusquer.

Cette nuit-là, je me suis endormi épuisé mais heureux après une longue semaine de travail. Le site était enfin en ligne, et quelques milliers de personnes l’avaient vu grâce à mon tweet. J’allais me reposer le week-end puis réfléchir la semaine suivante à la façon de le faire connaître. Ce ne serait finalement pas nécessaire…

Le lendemain matin

En quelques heures, pendant que je dormais, des gens l’avaient posté sur Reddit, Hacker News et partout sur internet. J’avais prévu de courir avec un ami à 7 h le lendemain, donc je me suis levé anormalement tôt. Heureusement.

Mon téléphone explosait de notifications. Quelques centaines de tweets, une masse d’emails. J’ai essayé de charger le site : il était extrêmement lent. J’ai regardé les statistiques et le trafic avait explosé ces dernières heures, au point que le site ne répondait presque plus sous la charge. Heureusement, monter en puissance avec Heroku était assez simple, et je suis passé de 2 à 8 dynos. Avec assez de serveurs web pour encaisser ce trafic extrême, tout se chargeait de nouveau instantanément.

En quelques heures, le site a dépassé les cent mille visiteurs. Dans l’après-midi, deux cent mille. Apparemment, ça plaisait. Les tweets et les messages continuaient d’affluer !

C’était très humblant de voir toutes sortes de gens commenter et partager, d’autant que je n’étais pas sûr que quiconque comprenne ou aime. Quelques tweets m’ont particulièrement fait plaisir, venus de personnes que j’admire beaucoup.

J’ai remarqué que des centaines de personnes posaient les mêmes questions :

• Comment as-tu fait les animations ?
• Quelles technologies utilises-tu ?
• Comment connais-tu tes analyses de sang ?
• Comment puis-je avoir la même chose ?

Après avoir répondu aux 10 ou 20 premiers, j’ai compris que je devais raconter toute l’histoire du début à la fin. Le processus était trop passionnant pour ne pas le partager. J’avais des centaines de vieux croquis, de maquettes et de prototypes que personne n’avait jamais vus.

Et c’est ainsi que cet article a commencé…

Épilogue

J’avais surtout conçu le site comme mon jouet personnel. Je savais que c’était l’avenir, mais je n’étais pas sûr que quelqu’un d’autre trouverait l’effort quotidien de collecte de toutes ces données justifié. Il semble pourtant que quelques personnes aient été très intéressées. Après le lancement, j’ai reçu des centaines de messages me demandant comment en avoir un.

Quelques mois plus tard, j’ai décidé de créer une entreprise appelée Gyroscope. Elle est aujourd’hui bien lancée, et chacun peut s’y inscrire pour commencer à suivre sa vie.