Published in

Gyroscope

25 min readSep 10, 2015

The new Gyroscope App is now available in the App Store.

The Making of April Zero

Part 2

This is the journey of designing & coding the April Zero site, continued from part 1. I will share how I went from the early mockups to the final site, with the many iterations and challenges encountered along the way.

My design process is different every time.

For theory11 I got into the right mindset by doing magic for strangers on the streets of LA. I came up with the Quizlet styleguide while skydiving over Hawaii and seeing the blue water, tan sand and white waves during free fall. The color scheme for my previous site was borrowed from a red Ducati.

And the creation of this site was an even more roundabout process — involving adventures around the world, new gadgets, and experiments on myself. All for research & development, of course.

After testing a bunch of apps and hardware for a few months, I had decided on the final stack for the most automatic sensing and minimal time commitment.

Moves iPhone app — for location data
Cardiio iPhone app — for my heart rate
Instagram — for my photos
Runkeeper iPhone app ‐ for tracking my runs
Withings wireless scale — for daily bodyweight
Withings blood pressure monitor — heart rate and BP
Bodymetrix ultrasound — for bodyfat percentage
Monthly blood tests — for triglyceride and nutrient levels

May 2014: Thailand

I was traveling through Asia with Dustin Curtis, sketching ideas for the mobile version of the site. I was trying to come up with something to take advantage of the mobile context, something I would find useful every day while on the go.

I wanted to avoid creating something that would be explored once and then forgotten. I wanted it to be constantly changing and updating in realtime, highlighting the most important thing at the time — a new location, an alert about elevated heart rate, or just a general visualization of health levels.

I wanted to design for the rapidly approaching future where all this data will be constantly available, ignoring some of the limitations of the present. Currently, these numbers aren’t constantly updating — the weight gets updated about once a day, the blood levels only once a month, and heart rate only whenever I measure it, a few times a day.

I predict that within a few years, if not sooner, new hardware will exist to make this data much more automatic and continuous. If Apple or some other big player doesn’t figure it out within the next year, someone on Kickstarter will.

One mobile experience that I was excited about was an augmented-reality overlay with all my vitals. The camera input could be blurred to create the illusion of the phone being transparent, and the information would be at different levels above. It turned out to not be possible to do in the browser, but I might revisit the idea one day as an app.

I was excited by being able to see all the information at a glance from my phone, and kept trying to fit everything into one intuitive dashboard.

Dive School

I ended up in Koh Tao, a small island on the eastern coast of Thailand. It was famous for its scuba diving, so I decided to get certified.

During the day I would go to dive school, and at night I would make new mobile mockups. I connected Photoshop on my Macbook to Skala Preview on my iPhone to see each design in context. I would pick up my phone and walk around with each page open, trying to figure out how good it felt.

This helped me figure out many design details like scale and legibility. “How small can I make the text?” “How much contrast do I need to be able to read outdoors?” “How much info can I fit into one screen?”

The subtle spinning rings at the top alluded to the desktop version and gave it some character. In the beginning they were too strong, so I kept toning down the opacity and colors until they were hardly noticable.

I would walk around with screenshots on my phone and show them to people around me.

“What do you think this page is trying to tell you?” “What would you tap on?”

In the beginning, people had a hard time making sense of all the things crammed on the page. Dan didn’t know which column to look at first. Dustin complained everything was too small. Everyone else on the boat probably wondered why I brought my laptop.

I realized the idea of somehow fitting everything on the page wouldn’t work, and so I started to reduce it to only the most relevant stats.

When we were in Bangkok, we went to a few hospitals to try to get a cheap full-body MRI but they turned out to be too expensive, more than a few thousand dollars. But in the meantime, I got really attached to the idea of having a full medical view of myself, and decided to add it to the page to convey a more clinical and scientific feel. I used a stock image of an average-looking person to start, planning to replace it with a real one of myself later.

I really liked the feel of the human cross-section, especially opposed to something more generic like the map. Just glancing at the page gave a good feeling for what was going on, and the data was easily available by just looking closer at the bars and numbers. With some good animations, it would be even better. I wanted to make it clear that this was a realtime link to a live person, rather than just some set of boring medical graphs.I needed to avoid the trap of having dozens of generic pie & donut graphs that many apps fall into.

I was trying to tell a story rather than just show a bunch of medical measurements.

At this point, I was starting to get excited about the design. Heart rate would be especially cool once it was loading realtime data. I wasn’t sure if the animation for the MRI was possible, but this was the first mobile design that finally felt good enough to accompany the desktop experience.

It was ready to be coded. As we headed south to Malaysia, I spent the next few days trying to build the animations.

After a few days of experimentation, I figured out how to simulate the scanning and glowing of the MRI in CSS. I added a breakpoint at around 600px, and started working on the mobile layout in the browser. When it got close, I loaded it on my phone from my computer’s IP address to test and optimize directly for the iPhone hardware.

With mobile finally figured out, it was time to go back to finish the desktop experience of Explorer.

The previous version was beautiful, but too much of an information overload. I needed to figure out how to display my daily activity in a more compact, understandable manner. I suspected the solution would be more levels of navigation, reducing each timeline to a simpler version until more details are requested for that day.

I have a hard time thinking on an empty stomach, so I decided I would first fill up on sushi and then figure out the final design.

June 2014: Japan

Breakfast at Tsukiji

I landed in Tokyo the next morning and headed to the Tsukiji fish market, home of the freshest fish in the world.

After a month of traveling on bumpy boats and slow trains, getting around on the punctual and efficient Japanese subway system felt fantastic. I wanted my site to have the same feel, where you could click around and end up in new places and be confident that nothing would go wrong. It would be fast and clean. All the timings would be perfect to the millisecond.

An hour later, I was inspired, no longer hungry and ready to finish designing the site.

I set up a small desk at my hotel and started working. I decided to figure out mobile first and then scale up, to ensure I didn’t invent something crazy that would never work at smaller sizes.

I had spent the past month debating about which direction time should flow on mobile. Should the latest activity come in from the top? This was the way most feeds like Facebook or Twitter worked. Or should it be arranged chronologically, like a calendar, starting from the first day?

The problem was there was no one right answer. This was both a realtime feed of my activity, and a calendar of what I did in the past. Each required an opposite design, but I could only pick one.

After mocking up a lot of real data in both ways, I realized I was more frequently expecting chronological order and often misunderstood the page otherwise.

I finally decided each month page would start from midnight on the first day. The latest content would be at the bottom, earliest at top.

I had been using Google Maps to get around, and was inspired by their mobile design. Their timeline of routes is always clean and reliable.

To achieve a similar feel meant getting rid of a lot of the data I was trying to cram into the margins. Usability and simplicity were more important for the mobile experience than having all the information available in one view.

I had been trying to figure out clever ways to show sunrise/sunset, photos from the day, etc. It was great data but added too much complexity. The new version was much simpler, just a list of the places I visited.

I updated the content with the day’s activity and deleted almost everything else. It didn’t have a lot of the information, but was starting to feel a lot cleaner. It was finally something I could easily use on my phone or share with others.

Later that day, Apple announced HealthKit at WWDC. It wasn’t quite as great as I was expecting — no revolutionary hardware accompanied it — but the clock was now officially ticking.

The clinical and medical nature of their design also made me realize how vital Explorer was — more than I had originally imagined. The location and travel data would give context and meaning to what would otherwise be just an assortment of disconnected data points, merely trivia.

I only had a few more days in Japan before I had to head home to build and launch this thing. After all, real artists ship.

Tea Ceremony

The next morning I went for a long run through the park. I wanted to clear my head and allow inspiration to strike. After reading about HealthKit, my mind was filled with wild ideas for gamifying fitness or algorithmically preventing heart attacks.

Afterwards, I decided to check out a traditional Japanese tea ceremony. It took place in a beautiful garden, surrounded by a koi pond and lots of greenery. A woman in a kimono played with the fish nearby.

The first course was a small sweet, served on a hexagonal wooden coaster. It reminded me of a concept I was sketching earlier. I had pretty much given up on hexagons, since they couldn’t be nested into each other like rectangles.

I had been searching in vain for an iconic header to go at the top of each month page. The circles in the previous version were clean but not very memorable or exciting. The tea experience made me think it might be time to revisit the hexagons concept.

This was the first mockup, arranging a grid of hexagons to represent each location.

I was excited about how it made a visually interesting element while still potentially conveying a lot of rich information. Since the idea was so content-heavy, it would be better to just start building with the real data than try to create an accurate mockup with hundreds of dynamic icons.

This was the first coded version. It wasn’t especially pretty, but added the live content and set up the basic layout for the elements I would be playing with.

Making each item into hexagons was just a simple CSS image mask. The whole set of locations was slightly manipulated in 3D space for a more interesting perspective. A slight shadowing around the edges keeps the focus in the center.

Foursquare’s location categories did a lot of the heavy lifting here, creating a taxonomy of categories and providing great icons to represent them.

I set up some color coding to easily differentiate places, which revealed patterns in each month. Nature and parks are green, airports or train stations are teal, restaurants and coffee shops are mostly orange and residences or hotels a subtle grey.

Months where I went diving a lot had a lot of green. When I was in New York there is a lot of red for Italian restaurants. The Japan trip had a lot of pink for sushi.

With the top of the page designed and coded, I needed to figure out how to fill in the timelines below. The data was all there, it just needed to be presented properly.

Lost in Roppongi

I was running late coming back from the tea place. I had lost track of time trying to practice my Japanese with the woman in the kimono. I was supposed to check out of the Park Hyatt Tokyo in less than an hour, but I was all the way across town. According to Google Maps, it would take 43 minutes by subway.

I caught the train towards Azabujuban station and was on my way. “It would be fine,” I told myself. “I can usually pack in less than 5 minutes.”

Once I was on the train, I got distracted trying to come up with a witty caption for my Instagram photo, and by the time I looked up my stop was just passing by. Oops. I got off at the next one: Roppongi.

I was staring at the map trying to figure out whether to go back or forward, angry that the subway system I loved so much had failed me when I most needed it. It took me a while to realize what I was actually looking at.

Here were a bunch of locations, on a small line with a lot of text. All the labels were slightly tilted. Huge brightly-colored circles differentiated the areas. This was what I had been searching for!

This style of displaying information on a timeline was the final inspiration I needed to finish designing Explorer 2.0. The tilted labels solved my stacking problem, and the big bold circles would be easy to understand in a compact form.

I wanted to reserve half the page to plot other related details about the day, using the locations above to create a context of when and where they occurred. I played with the idea of having a map fill the remaining space.

There were many things I wanted to plot for each day: sleep, food, transportation, mood, blood sugar, etc. For now, I would use the data I had easy access to and varied the most day-to-day: transport, GitHub commits and heart rates.

Coloring the location names let me space them out better while maintaining a strong visual connection to the colored icons.

I played with the idea of having a map in the background. Visually, I really liked the rich background effect that it added. However, it felt too confusing once unrelated data was positioned above it.

Instead of the map, I tried a blurred background of Instagram photos. That gave each day a unique, interesting backdrop for its data. Github commit and deployment history would fill the gaps for the many days when I didn’t do anything else.

After days of slow progress and experimentation — literally searching around the world for the answer — all of a sudden everything came together. I knew from the moment I added the last layer, that this was the one.

The design phase was finally over. It was time to start building.

July 2014: San Francisco

Until now, I had put off figuring out how to actually build this & choosing the tech stack. I wanted to spend all of my time on the design and frontend without being distracted by infrastructure or code . Sticking with super-simple Jekyll for the prototyping was essential to moving fast and being able to try many ideas. Having everything static let me easily stash interesting versions for reference later.

My neighbor had been advocating Node. A bunch of people were suggesting I use Rails. In the past I had used Django and enjoyed it. I knew the language didn’t really matter that much, I just needed to pick one and start writing.

I spent a day playing with Ruby on Rails. Many people had recommended it. It seemed like a solid choice for getting other developers involved later. After spending an hour getting the Hello World example running & live, I realized things were going too slowly. I needed to spend all my time building things and not learning the intricacies of a new framework.

I decided go to with Python and Django, which I had already used to build an analytics startup long ago. Heroku made deploying and managing the servers much easier than I was used to with AWS. Within minutes, the site was live. Within hours, I had all the page URLs hooked up with empty templates. Within a few days, most of the models were running and importing data from various APIs. Now we were cooking with fire.

Most of the services I wanted to integrate with had nice OAuth 2.0 API’s with good documentation, so it was surprisingly easy to sync up the accounts and pull the data I needed. I set up a job in Heroku scheduler to check for fresh data every 10 minutes and import it if anything new was found.

The Frontend

SASS
Compass
CoffeeScript
LiveReload
jQuery
PJAX
jQuery Throttle
D3

The site loads one global CSS file and one global JavaScript file. Those files are concatenated from a bunch of smaller SASS and Coffee files to keep everything organized and modular while developing.

In development, I use the Mac app LiveReload to instantly reload the site whenever I change CSS or JavaScript. It speeds up development by a few seconds every time I change something, extremely helpful when iterating thousands of times.

The Backend

Python
Django
Postgres
Memcached
Heroku

Heroku has some helpful tutorials on setting up their stack. Deploying is really simple: just a simple “git push heroku master” and the changes are live. I push to GitHub frequently and to Heroku whenever I want to deploy.

I was worried about performance on pages with heavy queries for a while, but Memcached was a lifesaver. Since the site was so static & only changed when new data was imported, I was able to cache almost every template & serve it instantly.

Home Stretch

The design process can benefit from frequent perspective changes and interruptions. Sometimes I will figure things out in the middle of a conversation, or after noticing something on the street.

However, when developing I like to sometimes have days of uninterrupted timeto focus and keep thousands of lines of code cached in my head. Both my roommates were out of town for a week, so I had some peace and quiet.

With the designs figured out and the data flowing in, I just had a long list of bugs and performance problems to fix before launching. I decided I would lock myself in my room until this thing was live.

I was bouncing back and forth between building the frontend and backend, adding more live data to the page and then cleaning it up.

Whenever I build something in CSS, I first work on the layout with extremely simple styles. The goal is to get everything in the right place, not to make it look good. The first step is making sure the backend is outputting everything I need. I want to get that out of the way and then be able to spend all my time in the same CSS file. Everything gets a background: red or background: blue just to verify that the selectors are working properly. Then I work on the layout and positioning, thinking about things like responsiveness and edge cases. Once those are fully figured out, I usually make a new stylesheet to fill in all the design details and make things look nice.

Using the same colors and icons as the hexagons above made it really easy to get a feel for the types of locations in a day. Home was constantly repeated but not particularly exciting, so I made it more subtle to allow the other places to stand out more — white circles instead of blue.

All the labels were now hidden, making each timeline more simple and lightweight. Clicking on a day would open it to reveal more information.

The first thing I added was travel data, connecting the locations to each other by walking, running, driving, etc. Everything was absolutely positioned, so I could plot each item by start and end times.

Blurred Instagram photos gave the days more interesting and diverse backgrounds to show the data. I then added real heart rate data for each day.

A little styling starts to bring the page together. Arcs are created between each place to show the type and duration of travel. Boring things like walking are really small, but a big run or flight is brightly colored to be easily noticed.

Some space is reserved on the right side to show the city and navigation to the previous and next days.

Some days had a lot of empty space — it looked like I was just sitting at home or sleeping all day. Github commits fill in the remaining gaps in the story, revealing when I was working and what I was working on.

Month Pages

Now that each day & month had a page, I started to work on the list of months and the animations for navigating through all the pages.

At first the months were in a vertical list, with details about the cities and types of places visited. The top photos for the month also help give an overview of what happened.

Originally designed as the responsive mobile version, I realized making each month into a pod would be more exciting than a list view. Each month would be more clickable and seem like an interactive object.

Mapbox

I wanted to have a subtle background with terrain and streets to give context to my runs. Google Maps are amazing, but I wanted something a bit more customizable so I decided to try out Mapbox. The service seemed a bit expensive, but the setup process is really easy and I figured it would be well worth the cost to have a nicer homepage with good maps.

Runkeeper provides an array of GPS coordinates every 5 seconds during the run. I used Mapbox’s javascript library to create an SVG line from those points. At first I was worried I would have to do some complicated code to animate the line growing from start to finish, but it turned out to be a simple CSS transition using stroke-dash CSS properties. In this example, reducing the offset to 0 gradually reveals the line.

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

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

Critique Hour

Every night, Stammy would come home from work and we would go over the new features and changes. I would also send links or screenshots to Yuri, Dustin and other friends when I got stuck or needed a second opinion. It really helps to have other people’s perspectives and regularly get fresh eyes on a project. A lot of the ideas originally came from discussions or as responses to feedback that something that didn’t feel quite right.

Getting feedback from people is more than just doing everything they say, or removing things that people don’t like. Feedback will tell you whether what you did made sense or works well, but not what to do or what the vision should be. Vision can’t be crowdsourced. Having a project with a bunch of patches and hacks for every complaint usually ends up being hard to iterate on and maintain.

Strong feedback is usually a good sign, even if it is negative it means they were engaged enough to become emotionally invested. It is actually rare. If everyone’s feedback is nondescript or they have nothing to say, that is usually a bad sign of an uninspiring design. If everyone hates it, it may be terrible or brilliant — sometimes it is hard to tell.

It is important to constantly get feedback, but not drop everything or scrap the whole idea the moment something negative comes in. I usually batch things for the next revision, unless there is some catastrophic problem that requires going back to the drawing board.

For example, in the current revision I’ve received a lot of feedback that the arcs for travel don’t make sense. It didn’t make sense to delay the launch to fix them, but the next version we release will have a different approach.

It is also worth getting feedback from different types of people, especially ones who are more non-technical or aren’t used to similar interfaces. It can be frustrating but also eye-opening to see how differently some people think and interact. That is why I really like testing in coffee shops or with total strangers — you can get some fascinating insights and discover things that seemed obvious but don’t make sense to others.

Even the most polished and well thought-out design will have some rough edges and benefit from thorough testing.

Chat Heads

Contact forms are so 2006. I wanted to have a fun way to interact with visitors. My theory was that many people have something to say, but most are intimidated by an official looking contact form. I know I usually am.

I wanted it to be fun and friendly and human, even though the visual style of the rest of the site was pretty futuristic and automated. I wanted the site to be cool, but not so much that it was intimidating to people.

I used to use Facebook chat heads to talk to people every day. It was a very natural design & way to communicate. I wanted to have a similar interaction here, one that most people would already be used to. In the future I could even have people talk to me in realtime through Messenger, using the site as a chat client.

About Page

This project relied on a lot of other software and hardware. I wanted to have a good way to give everyone credit and share all the tools I’m using. I decided I would make a simple “powered by” sequence of logos of all the partners, with their name and contribution visible on hover.

I added some stats about burritos to make it feel more fun and personal, not just like a medical dashboard. Because who doesn’t like burritos?

Powered by Sugar

Towards the end, I was consuming vast quantities of sugar to keep focused and stay up all night working. It was terrible for my body, but allowed me to think clearly for a few hours and solve almost any problem. The harder the problem, the more sugar I need to figure it out.

July 11, 2014

Launch Day

It was Friday. The site was almost ready, so I decided to go over to Alex’s place for the final finishing touches. It’s always good to have a second pair of eyes for this kind of thing, and having one of the world’s experts on Javascript around doesn’t hurt either.

My todo list was just a bunch of small remaining things: hook up the chat heads to actually send messages, add twitter buttons, fix meta descriptions, write the first article, update the CDN assets, figure out the launch tweet, etc.

In the few hours that we were sitting around and working, he made a Chrome extension to have our age counter as the start screen.

We had a quick discussion of whether Friday evening was too late to launch, or whether it made more sense to wait until Monday when everyone was back on their computers. It was probably wise to wait just a few more days, but at that point I was exhausted after a week of nonstop, adrenaline-powered coding and felt like it was now or never.

I changed some DNS settings, posted a tweet — and we were live!

Since it was Friday evening, most of all the initial views were coming from mobile. I had spent most of my time using the desktop version, but the majority of people were experiencing the basic mobile implementation.

It was fortunate that I spent so much time on responsive design towards the end. Everyone seemed to be liking it and sharing from just their phones. If I was doing this again, I would spend more time on the mobile experience, realizing it is the first and often only way many people are experiencing it.

Everything seemed to be going smoothly until I got a DM from Stammy saying I was 1517 pounds. This was quite strange, as I felt much lighter.

I hadn’t touched the Sport page code in a long time, so it shouldn’t have suddenly broken. Viewing the page source showed the raw value had a comma instead of period: 151,7 not 151.7. Javascript was ignoring the comma and parsing that incorrectly. I cleared the cache and the page was back to normal. Strange…

Later that night, I was at a bar showing my friend the site on my phone when I noticed one of the page titles was in Russian. Weird. I instantly connected this to the bug from earlier — both would have been caused by some sort of rogue internationalization code.

Of course, I had to head home and investigate.

It turned out to be a caused by a simple setting in Django, with internationalization (commonly shortened to i18n) enabled for things like numbers and dates. Combined with the caching system, certain sections were being corrupted after being requested from foreign countries. Disabling that feature was a one line fix and ensured a consistent experience for everyone around the world.

That was just one of many examples where a small and obscure hint points to a bug somewhere that needs to be figured out.

That night, I fell asleep exhausted but happy after a long week of work. The site was finally live, and a few thousand people had seen it from my tweet. I would relax for the weekend and then figure out how to start sharing it with the world next week. It turned out that wouldn’t be necessary…

The Next Morning

Within a few hours, as I was sleeping, people had posted it on Reddit, Hacker News and all over the internet. I had made plans to run with a friend at 7am the next day, so I woke up uncharacteristically early. It was fortunate that I did.

My phone was blowing up with notifications. A few hundred tweets, a bunch of emails. I tried to load the site and it was extremely slow. I checked the analytics and it showed the traffic had spiked through the roof in the past few hours, becoming almost nonresponsive from the load. Fortunately, scaling up with Heroku was pretty easy, and I bumped it up from 2 to 8 dynos. With enough web servers to handle the extreme traffic, everything loaded instantly again.

Within a couple hours, the site passed a hundred thousand visitors. By the afternoon, two hundred thousand. Apparently people liked it. The tweets and messages kept flowing in!

It was really humbling to see all types of people commenting and sharing it, especially since I hadn’t been sure if anyone would understand or like it. There were a few tweets that particularly made my day, from people I admire a lot.

I noticed hundreds of people were asking some of the same questions:

How did you make the animations?
What technologies are you using?
How do you know your blood levels?
How can I get this for myself?

After responding to the first 10 or 20, I realized I should post the whole story from start to finish. It was too exciting of a process to not share with the world. I had hundreds of old sketches, mockups and prototypes that no one had ever seen.

And that is how this post was started…

Epilogue

I had designed the site mostly as my personal toy. I knew this was the future, but wasn’t sure if anyone else would think it worth the daily effort to collect all this data. But it seems like at least a few others were very interested. After launching, I received hundreds of messages from people asking how they could get their own.

A few months later, I decided to start a company called Gyroscope. It is now up and running, where anyone can sign up and start tracking their life.

Ready to start tracking your life?