Como o April Zero foi feito: parte 2

Como o April Zero foi feito

Parte 2

O meu processo de design é diferente a cada vez.

Para a theory11, entrei no clima certo fazendo mágica para estranhos nas ruas de LA. Cheguei ao guia de estilo do Quizlet saltando de paraquedas sobre o Havaí e vendo a água azul, a areia clara e as ondas brancas durante a queda livre. A paleta de cores do meu site anterior foi emprestada de uma Ducati vermelha.

E a criação deste site foi um processo ainda mais tortuoso, envolvendo aventuras pelo mundo, aparelhos novos e experimentos em mim mesmo. Tudo em nome da pesquisa & desenvolvimento, claro.

Depois de testar um monte de apps e equipamentos por alguns meses, eu tinha definido a combinação final para o máximo de captura automática com o mínimo de tempo investido.

• App Moves para iPhone, para os dados de localização
• App Cardiio para iPhone, para a minha frequência cardíaca
• Instagram, para as minhas fotos
• App Runkeeper para iPhone ‐ para registrar as minhas corridas
• Balança sem fio Withings, para o peso diário
• Medidor de pressão Withings, frequência cardíaca e pressão
• Ultrassom Bodymetrix, para o percentual de gordura
• Exames de sangue mensais, para triglicérides e níveis de nutrientes

Maio de 2014: Tailândia

Eu estava viajando pela Ásia com o Dustin Curtis, rascunhando ideias para a versão mobile do site. Tentava criar algo que aproveitasse o contexto do celular, algo que eu achasse útil todo dia enquanto estivesse na rua.

Eu queria evitar criar uma coisa que fosse explorada uma vez e depois esquecida. Queria que ela estivesse mudando e se atualizando o tempo todo, em tempo real, destacando o que fosse mais importante naquele momento: um lugar novo, um alerta de frequência cardíaca alta ou só uma visualização geral dos níveis de saúde.

Eu queria desenhar para o futuro que se aproximava rápido, em que todos esses dados estariam disponíveis o tempo todo, ignorando algumas das limitações do presente. Hoje, esses números não se atualizam continuamente: o peso é atualizado umas uma vez por dia, os níveis no sangue só uma vez por mês, e a frequência cardíaca só quando eu meço, algumas vezes ao dia.

Aposto que, em poucos anos, ou até antes, vai existir hardware novo para deixar esses dados muito mais automáticos e contínuos. Se a Apple ou outro gigante não resolver isso no próximo ano, alguém no Kickstarter resolve.

Uma experiência mobile que me animava era uma sobreposição em realidade aumentada com todos os meus sinais vitais. A imagem da câmera poderia ser desfocada para criar a ilusão de um celular transparente, e as informações ficariam em camadas por cima. No fim não deu para fazer isso no navegador, mas talvez eu volte à ideia um dia, como app.

Eu ficava animado com a possibilidade de ver todas as informações de relance no celular, e ficava tentando encaixar tudo em um painel intuitivo só.

Escola de mergulho

Acabei em Koh Tao, uma ilha pequena na costa leste da Tailândia. Ela é famosa pelo mergulho, então resolvi tirar o certificado.

De dia eu ia para a escola de mergulho, e de noite fazia mockups novos para o celular. Conectei o Photoshop do meu Macbook ao Skala Preview no meu iPhone para ver cada design no contexto. Eu pegava o celular e andava por aí com cada página aberta, tentando sentir se aquilo era bom.

Isso me ajudou a resolver vários detalhes de design, como escala e legibilidade. “Quão pequeno posso deixar o texto?” “De quanto contraste eu preciso para ler ao ar livre?” “Quanta informação cabe em uma tela?”

Os anéis girando discretamente lá em cima faziam referência à versão de desktop e davam personalidade. No começo eles estavam fortes demais, então fui baixando a opacidade e as cores até quase não dar para notar.

Eu andava por aí com capturas de tela no celular e mostrava para as pessoas ao meu redor.

“O que você acha que esta página está tentando te dizer?” “Onde você tocaria?”

No começo, as pessoas tinham dificuldade de entender tudo o que estava espremido na página. O Dan não sabia qual coluna olhar primeiro. O Dustin reclamava que tudo estava pequeno demais. O resto do pessoal do barco devia estar se perguntando por que eu tinha levado o laptop.

Percebi que a ideia de encaixar tudo na página não ia funcionar, então comecei a reduzir aquilo só aos números mais relevantes.

Quando estávamos em Bangkok, fomos a alguns hospitais tentar fazer uma ressonância de corpo inteiro barata, mas saía caro demais, mais de alguns milhares de dólares. Nesse meio-tempo, fiquei muito apegado à ideia de ter uma visão médica completa de mim mesmo, e decidi colocar aquilo na página para passar uma sensação mais clínica e científica. Usei uma imagem de banco de uma pessoa comum para começar, com o plano de trocar por uma minha de verdade depois.

Gostei muito da sensação do corte transversal do corpo humano, principalmente em contraste com algo mais genérico, como o mapa. Só de bater o olho na página já dava para sentir o que estava acontecendo, e os dados ficavam à mão bastando olhar mais de perto as barras e os números. Com boas animações, ficaria ainda melhor. Eu queria deixar claro que aquilo era um link em tempo real com uma pessoa viva, e não só um conjunto de gráficos médicos chatos.Precisava evitar a armadilha de ter dezenas de gráficos de pizza & rosca genéricos em que muitos apps caem.

Eu estava tentando contar uma história, não só mostrar um monte de medidas médicas.

Nesse ponto, eu já estava animado com o design. A frequência cardíaca ficaria especialmente legal quando carregasse dados em tempo real. Eu não sabia se a animação da ressonância era possível, mas aquele era o primeiro design mobile que finalmente parecia bom o bastante para acompanhar a experiência de desktop.

Estava pronto para virar código. Enquanto seguíamos para o sul, rumo à Malásia, passei os dias seguintes tentando construir as animações.

Depois de alguns dias de experimentação, descobri como simular a varredura e o brilho da ressonância em CSS. Adicionei um breakpoint por volta de 600px e comecei a trabalhar no layout mobile direto no navegador. Quando ficou perto, abri no celular pelo IP do meu computador para testar e otimizar direto no hardware do iPhone.

Com o mobile finalmente resolvido, era hora de voltar e terminar a experiência de desktop do Explorer.

A versão anterior era bonita, mas tinha informação demais. Eu precisava descobrir como mostrar a minha atividade diária de um jeito mais compacto e compreensível. Desconfiava que a solução fosse mais camadas de navegação, reduzindo cada linha do tempo a uma versão mais simples até alguém pedir mais detalhes daquele dia.

Eu penso mal de barriga vazia, então decidi primeiro me encher de sushi e depois resolver o design final.

Junho de 2014: Japão

Café da manhã em Tsukiji

Cheguei em Tóquio na manhã seguinte e fui direto ao mercado de peixes de Tsukiji, a casa do peixe mais fresco do mundo.

Depois de um mês viajando em barcos sacolejantes e trens lentos, andar no metrô japonês, pontual e eficiente, foi uma sensação fantástica. Eu queria que o meu site tivesse essa mesma sensação, em que você clica por aí, chega em lugares novos e confia que nada vai dar errado. Seria rápido e limpo. Todos os tempos seriam perfeitos, no milissegundo.

Uma hora depois, eu estava inspirado, sem fome e pronto para terminar o design do site.

Montei uma mesinha no hotel e comecei a trabalhar. Decidi resolver o mobile primeiro e depois crescer, para não inventar nenhuma loucura que jamais funcionaria em tamanhos menores.

Eu tinha passado o último mês debatendo em que direção o tempo deveria correr no celular. A atividade mais recente devia entrar por cima? Era assim que funcionava a maioria dos feeds, como Facebook ou Twitter. Ou tudo devia ficar em ordem cronológica, como um calendário, começando pelo primeiro dia?

O problema é que não havia uma resposta certa. Aquilo era ao mesmo tempo um feed em tempo real da minha atividade e um calendário do que eu tinha feito. Cada um pedia um design oposto, e eu só podia escolher um.

Depois de montar muitos protótipos com dados reais dos dois jeitos, percebi que na maioria das vezes eu esperava a ordem cronológica, e sem ela costumava entender a página errado.

Enfim decidi que a página de cada mês começaria à meia-noite do primeiro dia. O conteúdo mais recente ficaria embaixo, o mais antigo em cima.

Eu vinha usando o Google Maps para me virar por lá, e me inspirei no design mobile deles. A linha do tempo de rotas é sempre limpa e confiável.

Chegar a algo parecido significava jogar fora boa parte dos dados que eu tentava espremer nas margens. Usabilidade e simplicidade eram mais importantes na experiência mobile do que ter toda a informação em uma única tela.

Eu vinha tentando bolar formas espertas de mostrar nascer e pôr do sol, fotos do dia e por aí vai. Eram bons dados, mas traziam complexidade demais. A versão nova ficou muito mais simples, só uma lista dos lugares por onde eu passei.

Atualizei o conteúdo com a atividade do dia e apaguei quase todo o resto. Faltava muita informação, mas estava ficando bem mais limpo. Enfim era algo que eu podia usar sem esforço no celular ou compartilhar com outras pessoas.

Mais tarde naquele dia, a Apple anunciou o HealthKit na WWDC. Não foi tão incrível quanto eu esperava, nenhum hardware revolucionário veio junto, mas o relógio agora estava oficialmente correndo.

O caráter clínico e médico do design deles também me fez perceber como o Explorer era vital, mais do que eu tinha imaginado. Os dados de localização e viagem dariam contexto e sentido ao que, sem isso, seria só um amontoado de dados desconexos, mera curiosidade.

Eu tinha só mais alguns dias no Japão antes de voltar para casa para construir e lançar essa coisa. Afinal, artista de verdade entrega.

Cerimônia do chá

Na manhã seguinte fui correr um bom tempo pelo parque. Queria clarear a cabeça e deixar a inspiração aparecer. Depois de ler sobre o HealthKit, a minha cabeça estava cheia de ideias malucas para gamificar a saúde ou prever infartos por algoritmo.

Depois, decidi conhecer uma cerimônia do chá tradicional japonesa. Ela acontecia em um jardim lindo, cercado por um lago de carpas e muito verde. Uma mulher de quimono brincava com os peixes ali perto.

O primeiro prato era um docinho, servido em um porta-copos de madeira hexagonal. Aquilo me lembrou de um conceito que eu tinha rascunhado antes. Eu já tinha praticamente desistido dos hexágonos, porque eles não se encaixam uns nos outros como os retângulos.

Eu vinha procurando em vão um cabeçalho marcante para o topo da página de cada mês. Os círculos da versão anterior eram limpos, mas não muito memoráveis nem empolgantes. A experiência do chá me fez pensar que talvez fosse hora de voltar ao conceito dos hexágonos.

Fiquei animado com o jeito como aquilo criava um elemento visualmente interessante e ao mesmo tempo podia carregar muita informação. Como a ideia dependia tanto de conteúdo, seria melhor começar a construir direto com os dados reais do que tentar criar um mockup fiel com centenas de ícones dinâmicos.

Esta foi a primeira versão em código. Não era lá muito bonita, mas trouxe o conteúdo ao vivo e montou o layout básico dos elementos com que eu ia brincar.

Transformar cada item em hexágono foi só uma máscara de imagem em CSS. O conjunto todo de lugares foi levemente manipulado no espaço 3D para dar uma perspectiva mais interessante. Uma sombra sutil nas bordas mantém o foco no centro.

As categorias de lugares do Foursquare fizeram boa parte do trabalho pesado aqui, criando uma taxonomia de categorias e trazendo ótimos ícones para representar cada uma.

Criei um código de cores para diferenciar os lugares facilmente, o que revelou padrões em cada mês. Natureza e parques são verdes, aeroportos e estações são azul-esverdeados, restaurantes e cafés são quase sempre laranja, e residências ou hotéis, um cinza discreto.

Os meses em que mergulhei bastante têm muito verde. Quando eu estava em Nova York, tem muito vermelho de restaurante italiano. A viagem ao Japão teve muito rosa de sushi.

Com o topo da página desenhado e codado, eu precisava descobrir como preencher as linhas do tempo lá embaixo. Os dados estavam todos ali, só faltava apresentar aquilo direito.

Perdido em Roppongi

Eu estava atrasado voltando da casa de chá. Tinha perdido a hora tentando praticar o meu japonês com a mulher de quimono. Deveria fazer o check-out do Park Hyatt Tokyo em menos de uma hora, mas estava do outro lado da cidade. Segundo o Google Maps, seriam 43 minutos de metrô.

Peguei o trem no sentido da estação Azabujuban e lá fui eu. “Vai dar tudo certo”, eu dizia para mim mesmo. “Geralmente faço as malas em menos de 5 minutos.”

Já no trem, me distraí tentando bolar uma legenda esperta para a minha foto do Instagram, e, quando levantei os olhos, a minha estação estava passando. Ops. Desci na seguinte: Roppongi.

Fiquei encarando o mapa tentando decidir se voltava ou seguia em frente, com raiva de o metrô que eu tanto amava ter me falhado bem na hora que eu mais precisava. Levei um tempo para perceber o que eu estava olhando de verdade.

Ali estavam vários lugares, sobre uma linha fina com muito texto. Todos os rótulos ligeiramente inclinados. Círculos enormes e coloridos diferenciavam as áreas. Era exatamente aquilo que eu estava procurando!

Esse jeito de mostrar informação em uma linha do tempo foi a última inspiração de que eu precisava para terminar o design do Explorer 2.0. Os rótulos inclinados resolviam o meu problema de empilhamento, e os círculos grandes e fortes seriam fáceis de entender em um formato compacto.

Eu queria reservar metade da página para plotar outros detalhes do dia, usando os lugares de cima para criar o contexto de quando e onde aquilo aconteceu. Brinquei com a ideia de um mapa preenchendo o espaço restante.

Havia muita coisa que eu queria plotar para cada dia: sono, comida, deslocamento, humor, glicose e por aí vai. Por ora, usaria os dados a que eu tinha acesso fácil e que mais variavam de um dia para o outro: deslocamento, commits no GitHub e frequência cardíaca.

Colorir os nomes dos lugares me deixou espaçar melhor tudo aquilo mantendo uma ligação visual forte com os ícones coloridos.

Brinquei com a ideia de um mapa ao fundo. Visualmente, gostei muito do efeito rico que ele dava. Só que ficava confuso demais quando dados sem relação apareciam por cima.

No lugar do mapa, testei um fundo desfocado com fotos do Instagram. Isso dava a cada dia um pano de fundo único e interessante para os dados. O histórico de commits e deploys do Github preencheria os buracos dos muitos dias em que eu não fiz mais nada.

Depois de dias de progresso lento e experimentação, literalmente procurando a resposta pelo mundo, de repente tudo se encaixou. Soube na hora em que coloquei a última camada que era aquilo.

A fase de design tinha acabado. Era hora de construir.

Julho de 2014: San Francisco

Até então, eu tinha adiado a decisão de como construir isso & qual pilha de tecnologia escolher. Queria passar todo o meu tempo no design e no frontend, sem me distrair com infraestrutura ou código . Ficar com o Jekyll, bem simples, na fase de protótipo foi essencial para andar rápido e conseguir testar muitas ideias. Com tudo estático, eu podia guardar versões interessantes para consultar depois.

O meu vizinho defendia o Node. Um monte de gente sugeria Rails. No passado eu tinha usado Django e gostado. Eu sabia que a linguagem não importava tanto assim, só precisava escolher uma e começar a escrever.

Passei um dia brincando com Ruby on Rails. Muita gente tinha recomendado. Parecia uma escolha sólida para envolver outros desenvolvedores depois. Depois de passar uma hora para colocar o exemplo Hello World no ar & funcionando, percebi que as coisas estavam indo devagar demais. Eu precisava gastar todo o meu tempo construindo, não aprendendo as manhas de um framework novo.

Decidi ir de Python e Django, que eu já tinha usado para construir uma startup de analytics muito tempo atrás. O Heroku deixou o deploy e a gestão dos servidores bem mais fáceis do que eu estava acostumado com a AWS. Em minutos, o site estava no ar. Em horas, todas as URLs das páginas estavam ligadas a templates vazios. Em poucos dias, a maioria dos modelos rodava e importava dados de várias APIs. Agora a coisa engrenou.

A maior parte dos serviços com que eu queria integrar tinha boas APIs OAuth 2.0 com documentação decente, então foi surpreendentemente fácil conectar as contas e puxar os dados de que eu precisava. Criei um job no scheduler do Heroku para checar dados novos a cada 10 minutos e importar se aparecesse algo.

O frontend

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

O site carrega um arquivo CSS global e um arquivo JavaScript global. Esses arquivos são concatenados a partir de vários arquivos menores de SASS e Coffee, para manter tudo organizado e modular durante o desenvolvimento.

No desenvolvimento, uso o app de Mac LiveReload para recarregar o site na hora sempre que mudo CSS ou JavaScript. Isso economiza alguns segundos toda vez que mudo alguma coisa, o que ajuda muitíssimo quando você itera milhares de vezes.

O backend

• Python
• Django
• Postgres
• Memcached
• Heroku

O Heroku tem tutoriais úteis para montar a pilha deles. O deploy é bem simples: um “git push heroku master” e as mudanças estão no ar. Eu envio para o GitHub com frequência e para o Heroku sempre que quero publicar.

Fiquei um tempo preocupado com o desempenho nas páginas com consultas pesadas, mas o Memcached salvou a pátria. Como o site era muito estático & só mudava quando dados novos eram importados, consegui colocar quase todo template em cache & servir tudo na hora.

Reta final

O processo de design se beneficia de trocas frequentes de perspectiva e de interrupções. Às vezes eu resolvo as coisas no meio de uma conversa ou depois de reparar em algo na rua.

Já no desenvolvimento, gosto de ter dias sem interrupção para focar e manter milhares de linhas de código na cabeça. Os meus dois colegas de casa estavam viajando por uma semana, então tive paz e silêncio.

Com os designs definidos e os dados entrando, sobrava só uma lista comprida de bugs e problemas de desempenho para resolver antes de lançar. Decidi que ia me trancar no quarto até aquilo estar no ar.

Eu ia e voltava entre construir o frontend e o backend, colocando mais dados ao vivo na página e depois arrumando tudo.

Sempre que construo alguma coisa em CSS, primeiro trabalho o layout com estilos extremamente simples. O objetivo é colocar tudo no lugar certo, não deixar bonito. O primeiro passo é garantir que o backend está entregando tudo o que eu preciso. Quero tirar isso do caminho e depois passar todo o meu tempo no mesmo arquivo CSS. Tudo ganha um background: red ou background: blue só para eu conferir se os seletores estão funcionando. Depois trabalho o layout e o posicionamento, pensando em coisas como responsividade e casos extremos. Quando isso está resolvido, geralmente crio uma folha de estilo nova para preencher todos os detalhes de design e deixar tudo bonito.

Usar as mesmas cores e ícones dos hexágonos de cima deixou muito fácil sentir os tipos de lugar de um dia. Casa se repetia o tempo todo e não era nada empolgante, então deixei aquilo mais discreto para os outros lugares se destacarem: círculos brancos em vez de azuis.

Todos os rótulos agora ficavam escondidos, deixando cada linha do tempo mais simples e leve. Clicar em um dia abria aquilo e revelava mais informação.

A primeira coisa que coloquei foram os dados de deslocamento, ligando os lugares uns aos outros por caminhada, corrida, carro e assim por diante. Tudo tinha posição absoluta, então eu podia plotar cada item pelo horário de início e de fim.

As fotos desfocadas do Instagram deram aos dias fundos mais interessantes e variados para mostrar os dados. Depois coloquei a frequência cardíaca real de cada dia.

Um pouco de estilo começa a dar unidade à página. Arcos são criados entre cada lugar para mostrar o tipo e a duração do deslocamento. Coisas sem graça, como caminhar, ficam bem pequenas, mas uma corrida longa ou um voo ganham cores vivas para chamar atenção.

Um espaço fica reservado do lado direito para mostrar a cidade e a navegação para o dia anterior e o seguinte.

Alguns dias tinham muito espaço vazio, parecia que eu tinha ficado em casa ou dormindo o dia todo. Os commits do Github preenchem os buracos que sobram na história, mostrando quando eu estava trabalhando e no que estava trabalhando.

Páginas de mês

Agora que cada dia & cada mês tinha uma página, comecei a trabalhar na lista de meses e nas animações de navegação entre as páginas.

No começo os meses ficavam em uma lista vertical, com detalhes sobre as cidades e os tipos de lugar visitados. As melhores fotos do mês também ajudam a dar uma visão do que aconteceu.

Desenhada originalmente como a versão mobile responsiva, percebi que transformar cada mês em uma cápsula seria mais empolgante que uma lista. Cada mês ficaria mais clicável e pareceria um objeto interativo.

Mapbox

Eu queria um fundo discreto com relevo e ruas para dar contexto às minhas corridas. O Google Maps é incrível, mas eu queria algo um pouco mais personalizável, então resolvi testar o Mapbox. O serviço parecia meio caro, mas a configuração é muito fácil e imaginei que valeria bem o custo ter uma página inicial mais bonita com bons mapas.

O Runkeeper fornece um conjunto de coordenadas de GPS a cada 5 segundos durante a corrida. Usei a biblioteca javascript do Mapbox para criar uma linha SVG a partir desses pontos. No começo temi que precisasse de um código complicado para animar a linha crescendo do início ao fim, mas no fim era uma transição CSS simples, usando as propriedades stroke-dash. Neste exemplo, reduzir o offset para 0 revela a linha aos poucos.

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

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

Hora da crítica

Toda noite, o Stammy chegava do trabalho e a gente revia os recursos e as mudanças novas. Eu também mandava links ou capturas de tela para o Yuri, o Dustin e outros amigos quando travava ou precisava de uma segunda opinião. Ajuda muito ter a perspectiva de outras pessoas e olhos novos no projeto com frequência. Muitas ideias surgiram de conversas ou como resposta a um feedback de que alguma coisa não estava boa.

Receber feedback é mais do que fazer tudo o que as pessoas dizem ou tirar o que elas não gostam. O feedback diz se o que você fez faz sentido ou funciona bem, mas não o que fazer nem qual deve ser a visão. Visão não se terceiriza para a multidão. Um projeto cheio de remendos e gambiarras para cada reclamação costuma acabar difícil de manter e de evoluir.

Um feedback forte geralmente é bom sinal, mesmo negativo, porque significa que a pessoa se envolveu o bastante para se importar. Isso é raro, na verdade. Se o feedback de todo mundo é vago ou ninguém tem nada a dizer, geralmente é o mau sinal de um design sem graça. Se todo mundo odeia, pode ser terrível ou genial, às vezes é difícil saber.

É importante receber feedback o tempo todo, mas não largar tudo nem jogar a ideia inteira fora assim que aparece algo negativo. Normalmente eu junto as coisas para a próxima revisão, a menos que exista um problema catastrófico que exija voltar à prancheta.

Por exemplo, nesta revisão recebi muito feedback de que os arcos de deslocamento não fazem sentido. Não fazia sentido adiar o lançamento para arrumar isso, mas a próxima versão vai ter uma abordagem diferente.

Também vale ouvir tipos diferentes de pessoa, principalmente quem é menos técnico ou não está acostumado com interfaces parecidas. Pode ser frustrante, mas também revelador, ver como algumas pessoas pensam e interagem de outro jeito. Por isso eu gosto muito de testar em cafés ou com estranhos: você tira conclusões fascinantes e descobre coisas que pareciam óbvias mas não fazem sentido para os outros.

Até o design mais polido e bem pensado tem arestas e ganha muito com um teste rigoroso.

Chat heads

Formulário de contato é coisa de 2006. Eu queria um jeito divertido de interagir com quem visita. A minha teoria era que muita gente tem algo a dizer, mas a maioria se intimida com um formulário de contato de cara oficial. Eu costumo me intimidar.

Eu queria algo divertido, simpático e humano, mesmo com o estilo visual do resto do site sendo bem futurista e automatizado. Queria que o site fosse legal, mas não a ponto de intimidar as pessoas.

Eu usava as chat heads do Facebook para falar com gente todo dia. Era um design & uma forma de conversar muito natural. Queria uma interação parecida aqui, com a qual a maioria já estivesse acostumada. No futuro, eu poderia até falar com as pessoas em tempo real pelo Messenger, usando o site como cliente de chat.

Página sobre

Este projeto dependia de muito software e hardware de outras pessoas. Eu queria um bom jeito de dar crédito a todo mundo e mostrar as ferramentas que uso. Decidi fazer uma sequência simples de logos “powered by” com todos os parceiros, com o nome e a contribuição de cada um aparecendo ao passar o mouse.

Coloquei alguns números sobre burritos para deixar tudo mais divertido e pessoal, e não só um painel médico. Porque quem não gosta de burrito?

Movido a açúcar

Perto do fim, eu consumia quantidades enormes de açúcar para manter o foco e virar a noite trabalhando. Era péssimo para o meu corpo, mas me deixava pensar com clareza por algumas horas e resolver quase qualquer problema. Quanto mais difícil o problema, mais açúcar eu preciso para resolver.

11 de julho de 2014

Dia do lançamento

Era sexta-feira. O site estava quase pronto, então resolvi ir até a casa do Alex para os retoques finais. Sempre é bom ter um segundo par de olhos nesse tipo de coisa, e ter por perto um dos maiores especialistas em Javascript do mundo também não atrapalha.

A minha lista de tarefas era só um monte de coisinhas: ligar as chat heads para mandar mensagens de verdade, colocar botões do twitter, arrumar as meta descriptions, escrever o primeiro artigo, atualizar os arquivos do CDN, pensar no tuíte de lançamento e por aí vai.

Nas poucas horas em que ficamos ali trabalhando, ele fez uma extensão do Chrome para colocar o nosso contador de idade na tela inicial.

Discutimos rapidamente se a noite de sexta era tarde demais para lançar, ou se fazia mais sentido esperar até segunda, quando todo mundo voltasse para o computador. Provavelmente teria sido sábio esperar mais alguns dias, mas naquele ponto eu estava exausto depois de uma semana de código sem parar, movido a adrenalina, e senti que era agora ou nunca.

Mudei umas configurações de DNS, publiquei um tuíte e estávamos no ar!

Como era sexta à noite, quase todas as primeiras visitas vieram do celular. Eu tinha passado a maior parte do tempo usando a versão de desktop, mas a maioria das pessoas estava vendo a implementação mobile básica.

Foi uma sorte eu ter passado tanto tempo no design responsivo no fim. Todo mundo parecia estar gostando e compartilhando direto do celular. Se eu fizesse tudo de novo, passaria mais tempo na experiência mobile, sabendo que ela é a primeira e muitas vezes a única forma pela qual as pessoas vão ver aquilo.

Parecia tudo tranquilo até eu receber uma DM do Stammy dizendo que eu pesava 1517 libras. Estranho, porque eu me sentia bem mais leve.

Eu não mexia no código da página Sport havia muito tempo, então não fazia sentido ter quebrado do nada. Olhando o código-fonte da página, o valor bruto tinha vírgula em vez de ponto: 151,7 e não 151.7. O Javascript ignorava a vírgula e interpretava aquilo errado. Limpei o cache e a página voltou ao normal. Estranho…

Mais tarde naquela noite, eu estava num bar mostrando o site para um amigo no celular quando notei que um dos títulos das páginas estava em russo. Esquisito. Liguei aquilo na hora ao bug de antes: os dois teriam a mesma causa, algum código de internacionalização fora de controle.

Claro que eu tive que ir para casa investigar.

No fim era só uma configuração do Django, com a internacionalização (normalmente abreviada como i18n) ligada para coisas como números e datas. Combinada com o sistema de cache, algumas partes eram corrompidas depois de serem acessadas de outros países. Desligar aquilo foi uma correção de uma linha e garantiu uma experiência consistente para todo mundo no mundo inteiro.

Esse foi só um dos vários casos em que uma pista pequena e obscura aponta para um bug em algum lugar que precisa ser resolvido.

Naquela noite, dormi exausto mas feliz, depois de uma semana longa de trabalho. O site estava enfim no ar, e alguns milhares de pessoas tinham visto pelo meu tuíte. Eu ia relaxar no fim de semana e depois pensar em como começar a mostrar aquilo para o mundo na semana seguinte. Não foi preciso…

Na manhã seguinte

Em poucas horas, enquanto eu dormia, as pessoas tinham postado aquilo no Reddit, no Hacker News e pela internet inteira. Eu tinha combinado de correr com um amigo às 7h do dia seguinte, então acordei cedo, o que não é do meu feitio. Ainda bem.

O meu celular estava explodindo de notificações. Algumas centenas de tuítes, um monte de e-mails. Tentei abrir o site e estava extremamente lento. Fui ver as analytics e o tráfego tinha disparado nas últimas horas, quase derrubando tudo. Por sorte, escalar no Heroku era bem fácil, e subi de 2 para 8 dynos. Com servidores suficientes para dar conta daquele tráfego absurdo, tudo voltou a carregar na hora.

Em algumas horas, o site passou de cem mil visitantes. À tarde, duzentos mil. Pelo visto, as pessoas gostaram. Os tuítes e as mensagens não paravam de chegar!

Foi uma lição de humildade ver todo tipo de gente comentando e compartilhando, ainda mais porque eu não tinha certeza se alguém ia entender ou gostar. Alguns tuítes fizeram o meu dia, de pessoas que eu admiro muito.

Notei que centenas de pessoas faziam as mesmas perguntas:

• Como você fez as animações?
• Que tecnologias você está usando?
• Como você sabe os seus níveis no sangue?
• Como eu consigo isso para mim?

Depois de responder às 10 ou 20 primeiras, percebi que deveria contar a história inteira, do começo ao fim. O processo era empolgante demais para não dividir com o mundo. Eu tinha centenas de rascunhos, mockups e protótipos antigos que ninguém nunca tinha visto.

E foi assim que este post começou…

Epílogo

Eu tinha desenhado o site basicamente como o meu brinquedo pessoal. Sabia que aquilo era o futuro, mas não tinha certeza se mais alguém acharia que valia o esforço diário de juntar todos esses dados. Mas parece que pelo menos algumas pessoas se interessaram muito. Depois do lançamento, recebi centenas de mensagens de gente perguntando como conseguir o seu próprio.

Alguns meses depois, decidi abrir uma empresa chamada Gyroscope. Ela já está de pé e funcionando, e qualquer pessoa pode se cadastrar e começar a acompanhar a própria vida.