Cómo se hizo April Zero: parte 2

Cómo se hizo April Zero

Parte 2

Mi proceso de diseño es distinto cada vez.

Para theory11 entré en clima haciendo magia para desconocidos en las calles de LA. La guía de estilo de Quizlet se me ocurrió tirándome en paracaídas sobre Hawái, viendo el agua azul, la arena tostada y las olas blancas durante la caída libre. La paleta de mi sitio anterior salió de una Ducati roja.

Y la creación de este sitio fue un camino todavía más enredado: aventuras por el mundo, aparatos nuevos y experimentos conmigo mismo. Todo por investigación y desarrollo, claro.

Después de probar un montón de apps y de hardware durante unos meses, ya tenía definido el equipo final para lograr la medición más automática posible con el mínimo tiempo dedicado.

• App de iPhone Moves ‐ para los datos de ubicación
• App de iPhone Cardiio ‐ para mi ritmo cardíaco
• Instagram ‐ para mis fotos
• App de iPhone Runkeeper ‐ para registrar mis carreras
• Balanza inalámbrica Withings ‐ para el peso diario
• Tensiómetro Withings ‐ ritmo cardíaco y presión
• Ultrasonido Bodymetrix ‐ para el porcentaje de grasa corporal
• Análisis de sangre mensuales ‐ para triglicéridos y niveles de nutrientes

Mayo de 2014: Tailandia

Estaba viajando por Asia con Dustin Curtis, bocetando ideas para la versión móvil del sitio. Buscaba algo que aprovechara el contexto móvil, algo que me resultara útil todos los días mientras andaba por ahí.

Quería evitar hacer algo que se mirara una vez y después se olvidara. Quería que estuviera cambiando y actualizándose todo el tiempo, en tiempo real, destacando lo más importante de cada momento: un lugar nuevo, un aviso de ritmo cardíaco elevado o simplemente una visualización general de mi estado de salud.

Quería diseñar para el futuro cercano en el que todos estos datos estén disponibles todo el tiempo, ignorando algunas limitaciones del presente. Hoy estos números no se actualizan constantemente: el peso se actualiza más o menos una vez al día, los niveles en sangre solo una vez al mes y el ritmo cardíaco solo cuando lo mido, unas pocas veces al día.

Creo que en unos años, o antes, va a existir hardware nuevo que haga que estos datos sean mucho más automáticos y continuos. Si Apple u otro grande no lo resuelve en el próximo año, alguien en Kickstarter lo hará.

Una experiencia móvil que me entusiasmaba era una capa de realidad aumentada con todas mis constantes. La imagen de la cámara se podía desenfocar para crear la ilusión de un teléfono transparente, con la información flotando en distintos niveles por encima. Resultó que no se podía hacer en el navegador, pero quizá algún día retome la idea como app.

Me entusiasmaba poder ver toda la información de un vistazo desde el teléfono, y seguía intentando meter todo en un panel intuitivo.

Escuela de buceo

Terminé en Koh Tao, una isla chica en la costa este de Tailandia. Es famosa por el buceo, así que decidí sacarme el certificado.

De día iba a la escuela de buceo y de noche armaba maquetas nuevas para móvil. Conecté Photoshop en mi Macbook con Skala Preview en mi iPhone para ver cada diseño en contexto. Agarraba el teléfono y caminaba con cada pantalla abierta, tratando de sentir qué tan bien funcionaba.

Eso me ayudó a resolver muchos detalles de diseño, como la escala y la legibilidad. “¿Qué tan chica puedo hacer la letra?” “¿Cuánto contraste necesito para leerla al aire libre?” “¿Cuánta información entra en una pantalla?”

Los anillos que giran suavemente arriba hacían un guiño a la versión de escritorio y le daban carácter. Al principio eran demasiado fuertes, así que fui bajando la opacidad y los colores hasta que casi no se notaban.

Andaba con las capturas en el teléfono y se las mostraba a la gente que tenía cerca.

“¿Qué crees que te está diciendo esta pantalla?” “¿Dónde tocarías?”

Al principio a la gente le costaba entender todo lo que había amontonado en la página. Dan no sabía qué columna mirar primero. Dustin se quejaba de que todo era muy chico. El resto de la gente del barco seguro se preguntaba por qué había llevado mi laptop.

Me di cuenta de que la idea de meter todo en una página no iba a funcionar, así que empecé a reducirla solo a los datos más relevantes.

Cuando estuvimos en Bangkok fuimos a varios hospitales a ver si conseguíamos una resonancia de cuerpo entero barata, pero resultaron carísimas, más de unos cuantos miles de dólares. Mientras tanto me quedé enganchado con la idea de tener una vista médica completa de mí mismo, y decidí agregarla a la página para darle un aire más clínico y científico. Empecé con una imagen de stock de una persona común, con la idea de reemplazarla más adelante por una real mía.

Me gustaba mucho la sensación del corte transversal humano, sobre todo frente a algo más genérico como el mapa. Con solo mirar la página te dabas una idea de qué estaba pasando, y los datos estaban ahí si te acercabas a las barras y los números. Con buenas animaciones sería todavía mejor. Quería dejar claro que esto era un enlace en tiempo real con una persona viva, y no un conjunto de gráficas médicas aburridas. Tenía que evitar la trampa de las decenas de gráficas de torta y de dona genéricas en la que caen tantas apps.

Estaba tratando de contar una historia, no de mostrar un montón de medidas médicas.

A esta altura el diseño ya me empezaba a entusiasmar. El ritmo cardíaco iba a quedar buenísimo cuando cargara datos en tiempo real. No sabía si la animación de la resonancia era posible, pero este fue el primer diseño móvil que por fin se sintió a la altura de la experiencia de escritorio.

Estaba listo para programarse. Mientras bajábamos hacia Malasia, pasé los días siguientes intentando construir las animaciones.

Después de unos días de experimentar, descubrí cómo simular el escaneo y el brillo de la resonancia en CSS. Agregué un punto de quiebre alrededor de los 600px y empecé a trabajar la maqueta móvil directo en el navegador. Cuando estuvo cerca, la cargué en el teléfono desde la IP de mi computadora para probar y optimizar directamente en el hardware del iPhone.

Con el móvil por fin resuelto, era hora de volver a terminar la experiencia de escritorio de Explorer.

La versión anterior era preciosa, pero saturaba de información. Tenía que encontrar la forma de mostrar mi actividad diaria de manera más compacta y entendible. Sospechaba que la solución era más niveles de navegación, reduciendo cada línea de tiempo a una versión más simple hasta que pidieras más detalles de ese día.

Me cuesta pensar con el estómago vacío, así que decidí llenarme de sushi primero y resolver después el diseño final.

Junio de 2014: Japón

Desayuno en Tsukiji

Aterricé en Tokio a la mañana siguiente y me fui al mercado de pescado de Tsukiji, la casa del pescado más fresco del mundo.

Después de un mes viajando en barcos con oleaje y trenes lentos, moverme por el sistema de metro japonés, puntual y eficiente, se sentía fantástico. Quería que mi sitio diera esa misma sensación: que pudieras hacer clic, llegar a lugares nuevos y confiar en que nada iba a salir mal. Rápido y limpio. Con los tiempos perfectos al milisegundo.

Una hora después estaba inspirado, ya sin hambre y listo para terminar de diseñar el sitio.

Armé un escritorio chico en el hotel y me puse a trabajar. Decidí resolver primero el móvil y después escalar hacia arriba, para no inventar algo delirante que nunca funcionara en tamaños chicos.

Había pasado el último mes debatiendo en qué dirección debía correr el tiempo en móvil. ¿La actividad más reciente tenía que entrar por arriba? Así funcionaban casi todos los feeds, como los de Facebook o Twitter. ¿O tenía que ir en orden cronológico, como un calendario, empezando por el primer día?

El problema era que no había una única respuesta correcta. Esto era a la vez un feed en tiempo real de mi actividad y un calendario de lo que había hecho. Cada cosa pedía el diseño contrario, y yo solo podía elegir uno.

Después de maquetar un montón de datos reales de las dos formas, me di cuenta de que casi siempre esperaba el orden cronológico y que si no, entendía mal la página.

Al final decidí que cada página de mes empezara a la medianoche del primer día. Lo más reciente abajo, lo más viejo arriba.

Venía usando Google Maps para moverme y su diseño móvil me inspiraba. Su línea de tiempo de rutas siempre es limpia y confiable.

Lograr una sensación parecida implicaba sacar muchos de los datos que estaba tratando de meter en los márgenes. Para la experiencia móvil, la usabilidad y la simplicidad importaban más que tener toda la información en una sola vista.

Había estado buscando maneras ingeniosas de mostrar el amanecer y el atardecer, las fotos del día, etc. Eran buenos datos, pero agregaban demasiada complejidad. La versión nueva era mucho más simple: solo una lista de los lugares que visité.

Actualicé el contenido con la actividad del día y borré casi todo lo demás. No tenía buena parte de la información, pero empezaba a sentirse mucho más limpio. Por fin era algo que podía usar cómodo en el teléfono o compartir con otros.

Ese mismo día, Apple anunció HealthKit en la WWDC. No fue tan grandioso como yo esperaba, no vino con ningún hardware revolucionario, pero el reloj ya había empezado a correr oficialmente.

El aire clínico y médico de su diseño también me hizo ver lo vital que era Explorer, más de lo que había imaginado. Los datos de ubicación y de viajes iban a darle contexto y sentido a lo que si no sería un conjunto de datos sueltos, pura trivia.

Me quedaban unos pocos días en Japón antes de tener que volver a casa a construir y lanzar esto. Al fin y al cabo, los artistas de verdad lanzan.

Ceremonia del té

A la mañana siguiente salí a correr largo por el parque. Quería despejarme y dejar que llegara la inspiración. Después de leer sobre HealthKit tenía la cabeza llena de ideas locas para convertir el ejercicio en un juego o prevenir infartos con algoritmos.

Después decidí ir a una ceremonia del té japonesa tradicional. Fue en un jardín precioso, rodeado de un estanque de carpas y mucho verde. Una mujer en kimono jugaba con los peces ahí cerca.

El primer paso fue un dulce chico, servido sobre un posavasos hexagonal de madera. Me recordó a un concepto que había bocetado antes. Prácticamente había abandonado los hexágonos, porque no se pueden anidar unos dentro de otros como los rectángulos.

Llevaba tiempo buscando en vano un encabezado icónico para la parte de arriba de cada página de mes. Los círculos de la versión anterior eran limpios, pero no muy memorables ni interesantes. La experiencia del té me hizo pensar que quizá era momento de volver a los hexágonos.

Me entusiasmaba cómo creaba un elemento visualmente interesante que además podía transmitir mucha información. Como la idea dependía tanto del contenido, era mejor empezar a construirla con los datos reales que intentar armar una maqueta precisa con cientos de iconos dinámicos.

Esta fue la primera versión programada. No era especialmente bonita, pero traía el contenido en vivo y armaba la estructura básica de los elementos con los que iba a jugar.

Convertir cada elemento en hexágono fue una simple máscara de imagen en CSS. Todo el conjunto de lugares está apenas manipulado en el espacio 3D para dar una perspectiva más interesante. Una sombra suave en los bordes mantiene el foco en el centro.

Las categorías de lugares de Foursquare hicieron gran parte del trabajo pesado aquí: crearon una taxonomía de categorías y aportaron iconos muy buenos para representarlas.

Armé un código de colores para diferenciar los lugares de un vistazo, y eso reveló patrones en cada mes. La naturaleza y los parques son verdes, los aeropuertos y las estaciones turquesa, los restaurantes y las cafeterías casi siempre naranja, y las casas y los hoteles un gris discreto.

Los meses en los que buceé mucho tienen mucho verde. Cuando estuve en Nueva York hay mucho rojo de los restaurantes italianos. El viaje a Japón tiene mucho rosa de sushi.

Con la parte de arriba de la página diseñada y programada, tenía que resolver cómo llenar las líneas de tiempo de abajo. Los datos estaban todos, solo faltaba presentarlos bien.

Perdido en Roppongi

Volvía tarde de la casa de té. Había perdido la noción del tiempo tratando de practicar mi japonés con la mujer del kimono. Tenía que dejar el Park Hyatt Tokyo en menos de una hora y estaba del otro lado de la ciudad. Según Google Maps eran 43 minutos en metro.

Tomé el tren hacia la estación Azabujuban y salí. “Va a estar bien”, me dije. “Normalmente empaco en menos de 5 minutos.”

Ya en el tren me distraje tratando de pensar un pie de foto ingenioso para mi Instagram, y cuando levanté la vista mi parada estaba pasando por la ventana. Ups. Me bajé en la siguiente: Roppongi.

Me quedé mirando el mapa para decidir si volver o seguir, enojado porque el sistema de metro que tanto quería me había fallado justo cuando más lo necesitaba. Tardé un rato en darme cuenta de qué estaba mirando en realidad.

Ahí había un montón de lugares, sobre una línea fina y con mucho texto. Todas las etiquetas estaban apenas inclinadas. Círculos enormes y de colores vivos diferenciaban las zonas. ¡Era justo lo que venía buscando!

Esta forma de mostrar información en una línea de tiempo fue la última inspiración que necesitaba para terminar de diseñar Explorer 2.0. Las etiquetas inclinadas resolvían mi problema de apilamiento, y los círculos grandes y contundentes se iban a entender fácil en poco espacio.

Quería reservar la mitad de la página para graficar otros detalles del día, usando los lugares de arriba como contexto de cuándo y dónde habían pasado. Jugué con la idea de que un mapa llenara el espacio restante.

Había muchas cosas que quería graficar para cada día: sueño, comida, transporte, ánimo, glucosa, etc. Por ahora iba a usar los datos que tenía a mano y que más variaban de un día a otro: transporte, commits de GitHub y ritmo cardíaco.

Ponerle color a los nombres de los lugares me dejó separarlos mejor sin perder la conexión visual con los iconos de colores.

Jugué con la idea de poner un mapa de fondo. Visualmente me gustaba mucho la textura que aportaba. Pero se volvía confuso cuando encima había datos que no tenían que ver con él.

En vez del mapa probé un fondo desenfocado de fotos de Instagram. Eso le daba a cada día un telón único e interesante para sus datos. El historial de commits y despliegues de Github llenaría los huecos de los muchos días en los que no hacía nada más.

Después de días de avance lento y de pruebas, buscando literalmente la respuesta por todo el mundo, de golpe todo encajó. Supe, en el momento en que agregué la última capa, que era esta.

La etapa de diseño por fin había terminado. Era hora de construir.

Julio de 2014: San Francisco

Hasta ese momento había pateado para adelante la decisión de cómo construir esto y qué stack usar. Quería pasar todo mi tiempo en el diseño y el frontend sin distraerme con infraestructura ni código. Quedarme con Jekyll, súper simple, para prototipar fue clave para ir rápido y poder probar muchas ideas. Tener todo estático me dejaba guardar versiones interesantes para consultarlas después.

Mi vecino defendía Node. Un montón de gente me sugería Rails. En el pasado había usado Django y me había gustado. Sabía que el lenguaje no importaba tanto: solo tenía que elegir uno y empezar a escribir.

Pasé un día jugando con Ruby on Rails. Mucha gente me lo había recomendado. Parecía una opción sólida para sumar otros desarrolladores más adelante. Después de una hora para poner el ejemplo de Hello World andando y en vivo, me di cuenta de que iba demasiado lento. Necesitaba pasar todo mi tiempo construyendo y no aprendiendo las mañas de un framework nuevo.

Decidí ir con Python y Django, que ya había usado hace mucho para armar una startup de analítica. Heroku hacía que desplegar y administrar los servidores fuera mucho más fácil de lo que yo estaba acostumbrado con AWS. En minutos el sitio estaba en vivo. En horas tenía todas las URLs conectadas con plantillas vacías. En unos días la mayoría de los modelos andaban e importaban datos de varias APIs. Ahí sí que estábamos cocinando.

Casi todos los servicios que quería integrar tenían APIs OAuth 2.0 lindas y bien documentadas, así que sincronizar las cuentas y traer los datos fue sorprendentemente fácil. Programé una tarea en el scheduler de Heroku para buscar datos frescos cada 10 minutos e importarlos si aparecía algo nuevo.

El frontend

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

El sitio carga un archivo CSS global y un archivo JavaScript global. Esos archivos se arman concatenando un montón de archivos SASS y Coffee más chicos, para mantener todo ordenado y modular mientras desarrollo.

En desarrollo uso la app de Mac LiveReload para recargar el sitio al instante cada vez que cambio CSS o JavaScript. Ahorra unos segundos cada vez que toco algo, lo que ayuda muchísimo cuando iteras miles de veces.

El backend

• Python
• Django
• Postgres
• Memcached
• Heroku

Heroku tiene tutoriales muy útiles para montar su stack. Desplegar es realmente simple: un “git push heroku master” y los cambios ya están en vivo. Yo hago push a GitHub seguido y a Heroku cada vez que quiero desplegar.

Estuve preocupado un tiempo por el rendimiento en las páginas con consultas pesadas, pero Memcached me salvó. Como el sitio era tan estático y solo cambiaba cuando entraban datos nuevos, pude cachear casi todas las plantillas y servirlas al instante.

La recta final

Al proceso de diseño le vienen bien los cambios de perspectiva y las interrupciones frecuentes. A veces resuelvo cosas en medio de una conversación, o después de ver algo en la calle.

Pero cuando programo me gusta tener días enteros sin interrupciones para concentrarme y mantener miles de líneas de código cacheadas en la cabeza. Mis dos compañeros de piso estaban fuera de la ciudad una semana, así que tuve paz y silencio.

Con los diseños resueltos y los datos entrando, solo me quedaba una lista larga de errores y problemas de rendimiento por arreglar antes de lanzar. Decidí encerrarme en mi cuarto hasta que esto estuviera en vivo.

Iba y venía entre construir el frontend y el backend, sumando más datos en vivo a la página y después limpiándola.

Cuando construyo algo en CSS, primero trabajo la maquetación con estilos súper simples. El objetivo es que todo quede en su lugar, no que se vea bonito. El primer paso es asegurarme de que el backend esté devolviendo todo lo que necesito. Quiero sacarme eso de encima y después poder pasar todo mi tiempo en el mismo archivo CSS. Todo se lleva un background: red o un background: blue solo para verificar que los selectores funcionan bien. Después trabajo la maquetación y el posicionamiento, pensando en cosas como el diseño adaptable y los casos límite. Cuando eso está resuelto del todo, suelo crear una hoja de estilos nueva para completar todos los detalles de diseño y dejarlo bonito.

Usar los mismos colores e iconos que los hexágonos de arriba hacía muy fácil captar los tipos de lugares de un día. Casa se repetía todo el tiempo y no era muy interesante, así que la hice más discreta para que los otros lugares resaltaran: círculos blancos en vez de azules.

Ahora todas las etiquetas estaban ocultas, lo que dejaba cada línea de tiempo más simple y liviana. Al hacer clic en un día se abría y mostraba más información.

Lo primero que agregué fueron los datos de desplazamiento, conectando los lugares entre sí caminando, corriendo, en auto, etc. Todo estaba posicionado en absoluto, así que podía ubicar cada elemento según su hora de inicio y de fin.

Las fotos desenfocadas de Instagram le daban a los días fondos más interesantes y variados para mostrar los datos. Después sumé datos reales de ritmo cardíaco de cada día.

Un poco de estilo empieza a darle forma a la página. Entre cada lugar se dibujan arcos que muestran el tipo y la duración del trayecto. Las cosas aburridas, como caminar, quedan chiquitas, pero una carrera larga o un vuelo van en colores vivos para que se noten enseguida.

Se reserva algo de espacio a la derecha para mostrar la ciudad y la navegación al día anterior y al siguiente.

Algunos días tenían mucho espacio vacío: parecía que me había quedado en casa o durmiendo todo el día. Los commits de Github llenan los huecos que quedan en la historia y muestran cuándo estaba trabajando y en qué.

Las páginas de mes

Ahora que cada día y cada mes tenían su página, me puse con la lista de meses y con las animaciones para navegar entre todas las páginas.

Al principio los meses iban en una lista vertical, con detalles de las ciudades y los tipos de lugares visitados. Las mejores fotos del mes también ayudan a dar un panorama de lo que pasó.

Pensada al principio como la versión móvil adaptable, me di cuenta de que convertir cada mes en una cápsula sería más atractivo que una lista. Cada mes invitaría más al clic y parecería un objeto interactivo.

Mapbox

Quería un fondo discreto con relieve y calles para darle contexto a mis carreras. Google Maps es increíble, pero yo quería algo un poco más personalizable, así que decidí probar Mapbox. El servicio parecía un poco caro, pero la configuración es muy fácil y calculé que valdría la pena el costo por tener una página de inicio más linda con buenos mapas.

Runkeeper entrega una serie de coordenadas GPS cada 5 segundos durante la carrera. Usé la librería de javascript de Mapbox para crear una línea SVG con esos puntos. Al principio temía tener que escribir código complicado para animar la línea creciendo de principio a fin, pero resultó ser una simple transición CSS con las propiedades stroke-dash. En este ejemplo, bajar el offset a 0 va revelando la línea de a poco.

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

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

La hora de la crítica

Cada noche Stammy volvía del trabajo y repasábamos las funciones y los cambios nuevos. También les mandaba enlaces o capturas a Yuri, a Dustin y a otros amigos cuando me trababa o necesitaba una segunda opinión. Ayuda muchísimo tener la mirada de otros y que ojos frescos vean el proyecto con frecuencia. Muchas de las ideas salieron de conversaciones o como respuesta a comentarios de que algo no terminaba de sentirse bien.

Pedir opiniones es más que hacer todo lo que te dicen o sacar lo que a la gente no le gusta. Los comentarios te dicen si lo que hiciste se entiende o funciona bien, pero no qué hacer ni cuál debería ser la visión. La visión no se puede tercerizar a la multitud. Un proyecto lleno de parches y remiendos para cada queja termina siendo difícil de iterar y de mantener.

Una reacción fuerte suele ser buena señal, incluso si es negativa: significa que la persona se involucró lo suficiente como para que le importara. Eso en realidad es raro. Si los comentarios de todos son tibios o nadie tiene nada que decir, suele ser mala señal, la de un diseño que no inspira. Si a todo el mundo le parece horrible, puede ser pésimo o brillante: a veces cuesta saberlo.

Es importante buscar opiniones todo el tiempo, pero no soltar todo ni tirar la idea entera apenas llega algo negativo. Yo suelo juntarlos para la siguiente revisión, salvo que haya un problema catastrófico que obligue a volver al tablero.

Por ejemplo, en la revisión actual me llegaron muchos comentarios de que los arcos de los trayectos no se entienden. No tenía sentido retrasar el lanzamiento para arreglarlos, pero la próxima versión que publiquemos va a tener otro enfoque.

También vale la pena escuchar a gente distinta, sobre todo a la menos técnica o a la que no está acostumbrada a interfaces parecidas. Puede ser frustrante, pero también te abre los ojos ver lo distinto que piensa e interactúa alguna gente. Por eso me gusta tanto probar en cafeterías o con desconocidos: sacas conclusiones fascinantes y descubres cosas que parecían obvias pero que a otros no les cierran.

Hasta el diseño más pulido y mejor pensado va a tener bordes ásperos y le va a servir una prueba a fondo.

Chat heads

Los formularios de contacto son muy de 2006. Quería una forma divertida de interactuar con la gente que visitaba el sitio. Mi teoría era que mucha gente tiene algo que decir, pero a la mayoría le intimida un formulario de contacto de aspecto oficial. A mí me pasa.

Quería que fuera divertido, amable y humano, aunque el estilo visual del resto del sitio fuera bastante futurista y automatizado. Quería que el sitio fuera atractivo, pero no tanto como para intimidar.

Yo usaba los chat heads de Facebook para hablar con gente todos los días. Era un diseño y una forma de comunicarse muy naturales. Quería una interacción parecida aquí, algo a lo que casi todos ya estuvieran acostumbrados. En el futuro incluso podría hablar con la gente en tiempo real por Messenger, usando el sitio como cliente de chat.

La página de información

Este proyecto dependía de mucho software y hardware de otros. Quería una buena forma de darle crédito a todos y de compartir las herramientas que uso. Decidí armar una secuencia simple de logos de todos los aliados, tipo “powered by”, con su nombre y su aporte visibles al pasar el mouse.

Agregué algunos datos sobre burritos para que se sintiera más divertido y personal, no solo un panel médico. Porque, ¿a quién no le gustan los burritos?

Impulsado por azúcar

Sobre el final estaba tomando cantidades enormes de azúcar para mantener la concentración y trabajar toda la noche. Era terrible para mi cuerpo, pero me dejaba pensar con claridad unas horas y resolver casi cualquier problema. Cuanto más difícil el problema, más azúcar necesito para resolverlo.

11 de julio de 2014

Día del lanzamiento

Era viernes. El sitio estaba casi listo, así que decidí ir a casa de Alex para los últimos retoques. Siempre viene bien un segundo par de ojos para estas cosas, y tener cerca a uno de los mayores expertos del mundo en Javascript tampoco molesta.

Mi lista de pendientes era un montón de cosas chicas: conectar los chat heads para que mandaran mensajes de verdad, agregar botones de twitter, arreglar las meta descripciones, escribir el primer artículo, actualizar los archivos del CDN, pensar el tuit del lanzamiento, etc.

En las pocas horas que estuvimos ahí trabajando, él hizo una extensión de Chrome para tener nuestro contador de edad como pantalla de inicio.

Discutimos un rato si el viernes por la noche era demasiado tarde para lanzar, o si convenía esperar al lunes, cuando todos volvieran a sus computadoras. Seguramente lo sensato era esperar unos días más, pero a esa altura yo estaba agotado después de una semana de programar sin parar a pura adrenalina y sentía que era ahora o nunca.

Cambié algunos ajustes de DNS, publiqué un tuit, ¡y estábamos en vivo!

Como era viernes por la noche, casi todas las visitas iniciales llegaban desde el móvil. Yo había pasado la mayor parte del tiempo usando la versión de escritorio, pero la mayoría de la gente estaba viendo la versión móvil, la básica.

Por suerte le había dedicado mucho tiempo al diseño adaptable sobre el final. A todos parecía gustarles y la compartían solo desde el teléfono. Si lo volviera a hacer, le dedicaría más tiempo a la experiencia móvil, entendiendo que es la primera y muchas veces la única forma en que la gente la vive.

Todo parecía ir sobre ruedas hasta que me llegó un mensaje de Stammy diciendo que yo pesaba 1517 libras. Rarísimo, porque me sentía mucho más liviano.

Hacía mucho que no tocaba el código de la página de deporte, así que no debería haberse roto de golpe. Al ver el código fuente noté que el valor crudo tenía una coma en vez de un punto: 151,7 y no 151.7. Javascript ignoraba la coma y lo interpretaba mal. Vacié la caché y la página volvió a la normalidad. Qué raro…

Más tarde esa noche estaba en un bar mostrándole el sitio a un amigo en mi teléfono cuando vi que uno de los títulos de página estaba en ruso. Extraño. Enseguida lo conecté con el error anterior: los dos tenían que venir de algún código de internacionalización descontrolado.

Obviamente, tuve que volver a casa a investigar.

Resultó ser por un ajuste simple de Django, con la internacionalización (que suele abreviarse i18n) activada para cosas como números y fechas. Combinado con el sistema de caché, algunas secciones se corrompían después de ser pedidas desde otros países. Desactivar esa función fue un arreglo de una línea y garantizó una experiencia consistente para todo el mundo.

Ese fue apenas uno de tantos casos en los que una pista chica y rara apunta a un error escondido que hay que resolver.

Esa noche me dormí agotado pero contento después de una semana larga de trabajo. El sitio por fin estaba en vivo y unos miles de personas lo habían visto por mi tuit. Iba a descansar el fin de semana y ver la semana siguiente cómo empezar a mostrarlo al mundo. Resultó que no iba a hacer falta…

A la mañana siguiente

En pocas horas, mientras yo dormía, la gente lo había publicado en Reddit, en Hacker News y por todo internet. Había quedado en salir a correr con un amigo a las 7 de la mañana, así que me desperté temprano, algo raro en mí. Por suerte lo hice.

Mi teléfono explotaba de notificaciones. Unos cientos de tuits, un montón de emails. Intenté cargar el sitio y estaba lentísimo. Miré la analítica y el tráfico se había disparado por las nubes en las últimas horas, hasta dejarlo casi sin responder. Por suerte escalar con Heroku era bastante fácil, y lo subí de 2 a 8 dynos. Con suficientes servidores web para aguantar ese tráfico brutal, todo volvió a cargar al instante.

En un par de horas el sitio pasó las cien mil visitas. Para la tarde, doscientas mil. Parece que le gustó a la gente. ¡Los tuits y los mensajes no paraban de llegar!

Fue muy emocionante ver a todo tipo de personas comentándolo y compartiéndolo, sobre todo porque no estaba seguro de que alguien lo fuera a entender o le fuera a gustar. Hubo algunos tuits que me alegraron el día especialmente, de gente que admiro mucho.

Me di cuenta de que cientos de personas hacían las mismas preguntas:

• ¿Cómo hiciste las animaciones?
• ¿Qué tecnologías usas?
• ¿Cómo sabes tus niveles en sangre?
• ¿Cómo consigo esto para mí?

Después de responder a las primeras 10 o 20, me di cuenta de que debía contar toda la historia de principio a fin. El proceso era demasiado interesante como para no compartirlo. Tenía cientos de bocetos, maquetas y prototipos viejos que nadie había visto nunca.

Y así empezó este artículo…

Epílogo

Había diseñado el sitio sobre todo como mi juguete personal. Sabía que era el futuro, pero no estaba seguro de que a alguien más le pareciera que valía la pena el esfuerzo diario de juntar todos estos datos. Pero parece que al menos a unos cuantos les interesó bastante. Después del lanzamiento recibí cientos de mensajes de gente preguntando cómo podía tener el suyo.

Unos meses después decidí fundar una empresa llamada Gyroscope. Ya está en marcha y cualquiera puede registrarse y empezar a registrar su vida.