This is the journey of designing & coding this site, continuing 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.

Here's where we left off...

Homepage design
Sport design
Explorer prototype

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
  • 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

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.

Chapter 1 – 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 off 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?"

5/25/14 1:13 AM
5/25/14 7:55 AM

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 on the boat wondered why I had 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.

5/25/14 9:09 PM
5/25/14 11:03 PM

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, and not just some set of boring medical graphs.I needed to avoid the boredom of hundreds 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.

5/25/14 11:11 PM
5/26/14 12:29 AM

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.

The final mockup
5/26/14 12:36 AM
The coded prototype
5/31/14 11:02 PM

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.

Chapter 2 – Japan

Breakfast at Tsukiji

I landed in Tokyo the next morning and headed to the Tsukiji fish market, where the freshest fish in the world can be found.

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 feeling, where you could click around and end up in cool 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 finished my sushi and was 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. 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?

This was a realtime feed of my activity, but also a calendar of what I did in the past. Each required an opposite approach, 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 come in from the bottom.

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.

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, even 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 had very limited time to keep changing the design, so I needed to make the best of my few days in Japan before heading home to build and launch this thing.

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 ideas for gamifying fitness and predicting heart attacks.

Morning run
Matcha tea

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 plants. 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 sketch I did a month ago. I had pretty much given up on hexagons, since they couldn't be nested into each other like rectangles.

I had been trying to figure out an iconic header for the top of each month page. The circles in the previous version were clean but not very memorable or exciting. Maybe it was time to revisit the hexagon 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 display the timelines below.

Lost In Roppongi

I was running late. I had lost track of time trying to practice my Japanese with the woman in the kimono. I had to check out of the Park Hyatt Tokyo within an hour, but I was all the way across town. According to Google Maps, it would take 43 minutes.

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

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. I got off at the next one: Roppongi. Oops.

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 occured. 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, 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, 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.

Chapter 3 – San Francisco

Choosing a stack

Until now, I had put off choosing a tech stack. I wanted to spend all of my time on the design and frontend without being distracted by the infrastructure. I think sticking with Jekyll for the prototypes 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 getting a Hello World example and 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 had been 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.

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.

Frontend Stack

  • SASS
  • Compass
  • CoffeeScript
  • LiveReload
  • jQuery
  • PJAX
  • jQuery Throttle
  • D3
  • Aileron.js (Keep reading for more details)

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.

I use the Mac app LiveReload on localhost to instantly reload the site whenever I change CSS or JavaScript. It speeds up development by a few seconds every time I change something, which ends up being extremely helpful for iterating.

Backend Stack

  • GitHub
  • 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. I cache most of the templates and only update them when new data is found.

I also used a bunch of helpful Django packages and Python utilities to speed up the process:

  • python-slugify
  • python-social-auth
  • requests
  • django-user-accounts
  • django-user-agents


  • New Relic
  • Google Analytics
  • Cloudflare

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 time to 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 very basic styles. 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.


Having days that could open up and reveal more info required yet another recode of my page loading system. It had been fairly simple when there were only three pages. Now there were multiple nested levels of pages. It was like Inception and I was about to fall into limbo. Content was being loaded on the fly to fill the gaps. Going in and out of a subpage, like opening a day, would also need special animations.

This was sufficiently complicated and tricky that I just wanted to figure it out once and then never have to worry about it again. I decided to structure it as a simple javascript plugin and spent a lot of time testing edge cases to make sure it was bulletproof.

I plan to release it as an open source project soon.

Month Pages

Armed with the new page transition system, 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.


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. They are really expensive, but the setup process is really easy and it would be worth the cost to improve the homepage.

Raw Lat/Longs
Map of San Francisco

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 others 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. 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 sometimes 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.

Bryan on page content
Ulf on travel visualizations

For example, in the current revision I've received a lot of feedback that the arcs for travel don't make sense, especially the smaller ones. It didn't make sense to delay the launch to fix them, but the next time I do something in that area I will try out different variations or keep thinking about a new design that would work better.

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 robotic and automated. I wanted the site to be cool, but not so much that it was intimidating to people.

Getting their info
Sending messages

I use Facebook chat heads to talk to people every day. It is a very natural 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.

All the Bi-Rites
Another gallon of rocky road
Coding during afternoon tea


Throughout the course of the project, I had playlists for each phase. There was Launch Week, Explorer 2.0, Explorer 1 and many more. Having good music to listen to is an essential part of my design process. I can't really design something until I find the right song to go with it, and then I listen to it thousands of times until I'm finished. Check out my article on music pairings to see how I think design and music fit together.

Launch Day

It was Friday—launch day. 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 things left: 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 the 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 logical 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.

A quick DNS update and we were live!

Since it was friday evening, most of all the initial views were coming from mobile. I had spent most of the time on the desktop version, but the majority of people were only seeing the basic mobile implementation.

It was a good thing that I spent a lot of time on the responsive version towards the end. Everyone seemed to be liking and sharing it just from their phone. 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.

On Diagnosing mysterious bugs

Things usually break at the most inconvenient moment. Strange bugs can severely delay a launch, or at least make it much more stressful. No one plans to spend a week fixing something that was working fine. Often just a single character or line can be slightly wrong, and it is like finding a needle in a haystack of code.

Being able to find and fix things that break without getting stressed out is critical for things to go smoothly. Having great version control with well structured commits and helpful messages makes this a lot easier. Being able to easily revert, or see everything that changed over time, makes debugging more of a reliable process than just blindly searching for an unknown line of code.

Having small things mysteriously break during development can be frustrating, but is often a blessing in disguise. Usually mysterious bugs are a symptom of some systematic flaws in your code, or an assumption that wasn't correct, or perhaps simply a variable somewhere slightly misspelled.

It is a great opportunity to follow the thread until you discover the core issue. For example, at Quizlet there was once a seemingly small javascript bug that led to discovering ads had not been showing for about a year in IE, a bug that potentially cost hundreds of thousands of dollars.

There are many known issues on this site. Many are compromises or things I plan to fix later. But the interesting things that break are the ones that I don't understand—I always try to get a diagnosis when I encounter them.

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. Strange. 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 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 wasn'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 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 kinds of people commenting and sharing it, especially since I hadn't been sure if people would 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.


I had designed this mostly as a 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 are very interested. After launching, I received hundreds of messages from people asking how they could get their own.

I've begun production on a new version called Gyroscope where anyone can sign up and start tracking their life.

You can enter your email address here to subscribe to production updates and get invited once it's ready.