The Making of April Zero
Part 1
This is the first chapter of how I designed the original April Zero website. I will share some sketches, deleted concepts and old prototypes explaining how it evolved along the way.
If you’re interested in using it yourself, you can now sign up for Gyroscope.
March 2014 — Inspiration
Get your move on
I was about to go to Paris with my roommate. He is an avid photographer and usually when we go somewhere he builds a minisite about our trip, full of nice fullscreen photos and videos. The previous one was about our Japan adventure.
It was always fun to go back a few months later and see the detailed chronicle of what we did, with beautiful photos and videos of every step along the way.
For this trip, we decided to use the Moves app to keep a log of everywhere we went. I installed it while in security line at SFO, not realizing this was the beginning of what would soon become an obsession.
Some people may have tried Moves or similar apps and in the past and had issues with battery life. For a long time, any sort of GPS or movement based apps (Nike, Find My Friends, Highlight, etc.) were terrible because they would drain your battery instantly. Then the iPhone 5S came out. But with the rumor mill buzzing about their upcoming iWatch, Apple’s groundbreaking release of the M7 processor went unnoticed by almost everyone — myself included.
All of a sudden, it was possible to do so many things with minimal impact on battery life. All of a sudden, so much rich content was available in realtime. All of a sudden, an entire generation of fitness devices became obsolete. Hardware problems became simple software problems. Moves was one of the few to actually take advantage of it.
Heartbeats
At around the same time, someone told me about an app called Cardiio, which could read your heart rate with the iPhone camera. I downloaded it mostly because I didn’t believe it would work. I really couldn’t have cared less how often my heart was beating.
But after playing with it for a few days I was obsessed. The great thing about it was that it only took about 15 seconds to get a measurement — maybe 30 if you count the time it takes to get your phone out of your pocket, unlock it, and open the app.
The thing that got me really hooked was learning that well trained athletes typically have lower resting heart rates. Lower was better. This was a very easy way to get an objective measurement of my current status. And it was fun.
One week I noticed my heart rate was abnormally high — near 80 or 90 when it was usually closer to 60. Was I stressed out about something? I went for a long run and then checked it again the next day. Back to 60. Fascinating…
It was like I had installed New Relic in my body. I was used to watching graphs and fixing things. Except instead of a server, this time it was my body.
Run for your life
My previous hobby was indoor rock climbing. I was a few blocks from Mission Cliffs, and going bouldering there became my nightly routine. But it is a pretty strenuous sport and I soon suffered from a variety of shoulder injuries.
I started running instead. I was just getting over a big breakup and it was a great way to cope. I had used the Nike running app occasionally in the past, going a mile here and there but never getting any serious mileage. The GPS powered app used to kill my battery so it was not very fun to use.
But now, with M7 my knees would give out long before my phone. Things like the fancy Garmin running watches or Fitbits I was thinking about getting were no longer necessary. It’s easy to make excuses about missing some important tool, but everything I needed was already in my pocket.
Posting the photos of my runs on Instagram kept me motivated and running regularly once I started. They had an easy system to overlay the map, distance and Nike logo to a picture. Instagramming it with the #nikeplus hashtag would make sure you got a lot of likes from other runners all over the world.
It combined three of my passions: running, photography, and getting attention. It was brilliant. It was a great time to be a runner — between Runkeeper, Strava, Nike, etc. there many great tools and communities out there.
Seeing all my stats for each run gave me something to try to optimize and get better at. I could now give myself challenges and goals.
But almost nothing else had a similar ecosystem. I wanted this sort of info and motivation for every aspect of my life, not just running. This was just analytics. I’ve built analytics before. It was time to start sketching.
Blood Levels
I was overdue for my yearly physical. I got all the standard tests, and also requested to be emailed a copy of my blood tests for my own records.
The next week, I received a PDF that was very comprehensive. It had not only my current stats but an explanation of the ideal ranges for each value and an analysis of my situation. I was surprised to see my Vitamin D so low, and some other things were within ranges not ideal. This was really amazing data, but stuck in a text PDF attachment in my inbox. It deserved to be much more.
I’ve been getting monthly blood tests ever since, and keeping a close eye on the changes. Putting them in a dashboard would give a constant reminder of what I need to try to improve. I was counting on my theory that just by tracking things I could improve them. Or if that didn’t work, at least I would know and could try harder.
Bodyfat
In The 4 Hour Body, Tim Ferriss talks about various gadgets and tests he used to track himself. One of them was a portable USB ultrasound machine to accurately measure body fat percentages. I had already been weighing myself, but knowing bodyfat percentage would give me even better understanding of what was changing.
The ultrasound process is a bit inconvenient — it takes a few minutes and you need to use a special gel — but I found the data it produced was really accurate and fascinating to see every day. You could actually visually see inside your own body, down to how many millimeters of fat, muscle and underlying bone you had.
I would see the bodyfat spike up on weekends after epic cheat days, and then go even lower the next week. The data I was getting was great, but the app interface and presentation were not.
I wanted to see how this related to everything else I was doing.
I also believed the idea that just by tracking something you will start improving. Knowing the current status and rate of change allows you to make better decisions, iterate quickly and understand what actually works and doesn’t. Without instrumenting all the things you care about, you are essentially just flying blind.
I realized I needed to find the right balance of easy, frequent measurements like heart rate and weight and more annoying but insightful data points like my bodyfat and blood levels. Together they would form a really good dashboard and tell a complete story. I’m also betting on the fact that technology will improve quickly, especially once this becomes more popular and demand increases. If the microchip implant version comes out on Kickstarter, or Apple starts monitoring it with the Apple Watch, I would just have to change a few lines of code.
April 2014 — First Drafts
A Grid of Datapoints
I liked the idea and simplicity of this pod-based design, with a nice grid and modular elements that could be upgraded later. Most of them could be 100% automated from API’s, and the manual ones like my latest climbing would just take a few minutes.
Even if I got lazy or really busy, the site still wouldn’t get stale. I would still be running or listening to music or posting new photos on Instagram!
The Importance of Sketching
I spend most of the early stages of a project just sketching and thinking. Whether creating designs or writing code, I find sketching things out first allows me to think more clearly.
Working with sketches on paper is powerful because it allows you to go fast. It is probably the only medium where you can record ideas as fast as they happen. It allows you to present yourself with visual options instead of just things in your head, and then to make better informed design decisions. Often putting two options on paper, even in the most rough form, will make it obvious which one is better.
Wacom Tablet
After paper, I quickly sketched this idea out in Photoshop to make sure it still made sense in a digital context. A lot of designs seem good on paper as a tiny thumbnail but don’t actually work when digitized. Something about the style of sketches can make even a bad idea seem classy and refined. When working on whiteboard or paper, it is very easy to fudge the scale and make text fit where it won’t, or for elements to take up much more space than they actually fill.
Sometimes I like maintaining a sketched style for the early mockups. It allows you to keep thinking as if you were on paper, and work on one variable at a time. Since the layout and content was just figured out, now I could add color and verify the contrast and scale still made sense. Texture, typography, background images and other time-consuming details would be figured out later if this was greenlit.
This iteration seemed pretty decent so I sent it to some friends. They were pretty excited about it so I kept working in Photoshop to create more realistic mockups. This had potential.
I spent a few more days cleaning up the details and experimenting with variations. I was very excited about the content and the information architecture — always most important things — but the style and layout didn’t take my breath away every time I looked at it.
It was a solid and usable design — but not the best in the world.
The April Zero Styleguide
This was the future. The potential to magically analyze and share everything about yourself is just about as fantastic as human flight or electricity. I wanted it to feel as futuristic as it actually was.
When building a brand, I usually put together a moodboard to quickly prototype various styles and figure out the elements needed to convey the mood. The pieces can be anything — clips from movies, photos, billboards, screenshots from other apps, etc. I often draw a lot of inspiration from motion design and advertising, which have great budgets and amazing artists behind them. There is also a lot of great stuff to be found on Dribbble and Behance.
There are many examples of great holographic interfaces and things that felt futuristic — but I needed to narrow it down to a more specific subset. As with most decisions in my life, I asked myself: What would Tony Stark do?
Some recurring elements I noticed were: holographic overlays, concentric circles, isometric perspective & thin lines. Incorporating these into a product without sacrificing usability would be hard, but it was a great starting point.
Now that I had narrowed down both the content and style, it was time to go back to the drawing board…
Version 2
I wanted to keep the modularity and architecture of earlier, but without such a boring layout. I decided to split everything into “mini-apps” to present the data around specific themes. The first two could be called “Sport” and “Explorer.”
Narrowing each section down to a single context would allow for a cohesive story to form instead of just throwing a bunch of stats and numbers at the visitor.
And in the future I could roll out new sections without needing to rebuild the existing ones. A few examples of other things I was excited about were:
“Aviation” — logging every flight as I worked on my pilots license
“Underwater” — logging dives as I worked on getting scuba certified
“Digital” — what I did when I was on my computer (design, code, screencasting, etc.)
“Finance” — spending habits, progress bar on becoming a billionaire
“Love” — quantifying my dating life, etc.
Maybe some stuff would need to be password protected…
Designing for Sport
The Sport section would have everything fitness and medical related, showing current blood levels and performance improvements over time.
The first iteration was a feed view of different types of activity. I really liked the display of the blood levels, but felt like the feed was too hard to quickly parse. I could only see the last few events, which didn’t give a good overview.
I wanted to be able see a year of data at a glance. To do this, I needed to have more aggregate data as well as make everything more compact.
This was a better layout but it didn’t feel very advanced. That was a problem that could be solved while building, by adding some subtle animations and adding subtle details.
This was the coded static version. The darker side columns give it a bit more contrast and tie it to the homepage by sliding the content column over.
I wanted to have everything be explorable and interactive. Hovering something would tell you more details about it — there was a lot of data behind the hood that could potentially be revealed.
The Spinner
One pattern I had noticed when looking at the analytics of previous sites is that most people will hit a page or two and then bounce. Even if there is a whole world of great content, most visitors will never reach it. Clicking on something is quite a commitment, and thoroughly exploring every section is just not done.
I wanted to create a new type of interface, where you didn’t have to commit to clicking on anything at first but could just move your mouse around and explore, with lightweight micro-interactions that were easy and fun.
And so this spinner was born. I wanted to create something as fun to use and revolutionary as the original iPod.
It would also allow a departure from the boring, rectangular layouts. The moodboard featured a bunch of circular, moving elements and this would allow for those details to naturally exist in the interface.
After I had a mockup I was sufficiently excited about, it was time to start coding! I already had a basic Jekyll foundation from a previous blog experiment. I checked out a new branch and started coding the spinner.
Early Code Prototypes
This is a good example of a situation where it is very useful to be both design & code a problem. Having the page look good visually was important, but how it felt & moved was an equally important thing to figure out. To do so, I put together a basic prototype with some lightweight Javascript, running inside the Jekyll container I was originally going to use for my blog.
The first version didn’t look very impressive. Version 1 (above) was very basic. Getting everything to spin and line up properly was a bit tricky, so I used brightly colored circles while building and debugging it.
Version 3 (below) added the ring elements and javascript for more interactions, like spinning the circle when you hovered on the text.
Version 5 added an intro animation, which was more challenging than I expected since I was trying to run transitions on elements that were also animating.
Version 8 introduced an exit animation with different settings than the intro so that clicking on something felt more rewarding.
Each iteration fixed a specific problem or added a new feature to make it slightly better. I was pleasantly surprised by how fun it was becoming to use. It confirmed my idea that there was something here worth spending time on. With some more improvements and design details, this could be a great experience.
And so I kept working on it, spending hours a day refreshing the page and trying to make the animations smoother, more interesting, better timed.
I was enjoying it, but I needed more validation to make sure there were no design problems. I was working out of various coffee shops at the time, so I recruited some strangers to play with the site.
I didn’t give them any instructions besides “try using this” and handed them my laptop, watching closely what they did. I noticed a few issues, mostly involving clicking on parts of the interface that weren’t actually links. I quickly expanded the link areas to include the commonly misclicked areas, and some hover effects to reinforce their clickability. Soon my testing volunteers were having no issues navigating or understanding the site.
It turned out to be as intuitive as I’d hoped. More importantly, they seemed to really be enjoying hovering around and clicking on sections, a little surprised and excited by all the animations they were triggering.
Satisfied with the core design of the homepage, it was time to tackle the part of the site I was most afraid of.
Explorer
A lot of technology problems were about to enter the picture. The previous sections were pretty easy to sketch and mock up in Photoshop with basic data, but for this one I would need real content. I set up an API key and started to import my data from Moves.
After spending a few weeks in San Francisco, I realized I needed a more diverse set of data to work with. So I grabbed my Macbook and passport and headed to New York for some research. I needed to really get in the mindset of exploration and adventuring if I was to get that feeling across in this section.
Now I had to figure out how to display flights, changes in time zones, runs in Central Park, and a count of how much pizza I consumed. It turned out to be a great thing that I went, because I quickly encountered a lot of issues with how Moves handled time zones that I needed to account for. Had I just stayed in San Francisco and counted on the old Paris stuff for international testing, everything would’ve imploded the next time I traveled across time zones.
On the flight back home, I started processing all the data from Moves and laying it out in a basic timeline. It was a bit of an unreadable mess, but it was working with the real data from my trip!
One of the biggest design decisions was to have the timelines be horizontal, and the days stacked on top of each other.
Almost all the other similar designs had arranged them vertically, conveniently avoiding the text overlap problem I was having. However, I believed the ability to see all the days compared to each other was essential. I wanted to have each day be an axis that could contain a lot of rich data later. The problem of showing the labels would have to be figured out some other way.
I started playing around with an algorithm to nicely stagger the labels across 4 levels. It would analyze the time difference between places and make sure there was always enough space for the text to show.
Version 9 was on a light background but for Version 10 I switched to a dark background to make the locations pop more and match the style of the rest of the site.
I decided to only show significant places initially, and that hovering would show more details about the day and reveal the smaller text. I also nerfed the display of recurring places like home or hotels, as they weren’t as interesting as other places even though they had much more time spent.
Then one day I decided to work outdoors at the park. The section was called Explorer after all.
And… I couldn’t read anything.
The original version with the white background worked fine, but the new one with an improved dark color scheme was totally unusable in sunlight.
This is why using your product in context is extremely important. The more removed you are, even in ways that may seem insignificant, the higher the likelihood of being blindsided or having design flaws. This is why I like to work on planes, in coffee shops, upside down, and in other ways that may get strange looks. It opens your mind to different perspectives and reveals issues that might otherwise go unnoticed.
Now I had to make the decision: did I keep it dark because that is what looked better indoors for 95% of people, or does it make sense to redo the whole thing to be light. If it happened to me, it could happen to someone else, or more importantly, it could happen to me again.
Sometimes when you get stuck or hit a speed bump, you need to just keep going and power through, throwing hours at the problem until it gets solved. In other cases, it is better to switch gears and approach from a different angle. I made a dark version (11) and a light version (12) for the archives and decided to move on to other problems.
Representing Travel
The first version had the travel and locations in the same line. I wanted to try making it seem more intuitive, instead representing travel from point to point as hops.
Aggregate Stats
I wanted to keep the map of the world at the top showing my current location, but also add overall statistics to the page, giving a quick summary of the page without having to look through 30 timelines. I decided to add another level of structure and split everything into months. Each month would have its own statistics and they could be compared to each other.
It was fascinating to see how my habits changed from month to month — certain months were spent traveling and in airports, other times I went climbing a lot or spent most of my day in coffee shops. Italian restaurants quickly dropped once I returned from New York, replaced by burritos.
Going Responsive
When I started to work on the responsive version, things started to go downhill. The horizontal timeline that worked great on desktop didn’t fit on a small screen. It needed to be vertical, but I didn’t want to sacrifice the functionality of the whole site just for the mobile implementation. I started refactoring the code to be able to run both orientations, and switch smoothly when the screen was resized.
The code to have a separate mobile version without messing up desktop was working. Now I could start designing for mobile from scratch, instead of trying to cram the bigger version into a small space.
I was getting tired of playing with the same old data. The design was coming along but it was still missing something. I needed a change of scenery and a new perspective.
I was working at a coffee shop (Coffee Bar on May 6) when my friend messaged me.
Perfect timing.
Ready to start tracking your life?
Sign up for Gyroscope to see the complete story of your life. Our iPhone app is now available for free in the App Store.
