Why we prototype - Building Dawn
Why we prototype.
Did you know that in Winter, the sun rises at the same time in Amsterdam as it does all the way across the Atlantic in Chile? In Summer, people in Amsterdam and Madagascar see the sun coming up at the same time. I find this fascinating.
This is how I came up with the idea for Dawn, a watch face for smart watches that allows you to see at any time of day, where in the world the sun is rising. While telling time, it makes you dream of places far away. If you’re a maker, you know what happened next: I could not let this idea rest, until I played with it.
Much like illustrators start out with a rough sketch to get a feel for an idea, digital designers often start with wireframes. They help to get a feel for all of the components that you want to appear on the screen, and map out how tapping one button will make the system show another. But it doesn’t feel real enough. In digital design we need to create a prototype. To paraphrase an old saying: “A prototype is worth a thousand wireframes”.
It’s a dangerous word: ‘prototype’. In the years I’ve been working as a designer I’ve had discussions with many different colleagues. Are we building a prototype, simulation, demo or proof of concept? All of these terms seem to mean different things to different people. In the end they all come down to the same thing; how can I test if my idea is worth it, without actually having to go through the trouble of producing the final thing? To get an answer to this question, you first need to ask yourself, what is this prototype for? Is it to prove that it can be done? Is it to test the performance of a functionality? Do you want to test interaction with end users? Or is it just plain curiosity. In this case, I wanted to know what it would be like to have a watch face that is more about serendipity than telling time.
Waiting for the sunrise
The first step in creating a prototype is to understand the problem space that you are working in; in this case this meant studying the Nautical Almanacs references for navigation. Let me introduce you to the problem space:
For a fixed position on earth, the sunrise and sunset times change daily. This is caused by our the planet’s rotation and place in our solar system. How much these times change depends on the time of year. During the June and December solstice (the longest and shortest day, depending on which hemisphere you’re at) the sunrise time changes the least. During the March and September equinox, the sunrise time in Amsterdam shifts more than 2 minutes per day.
During the Solstices the places in which the sun comes up at the same moment, follows a curve. During summer, the sun comes up much more earlier in the North than in the South. In winter this is the opposite. Look at the image below to see the shape of the sunrise line in Summer.
Making it real
So, how can we enable the serendipity of finding new places on the globe? Simple: I randomly pick a coordinate on the sunrise line. When I have this coordinate, I check the OpenStreetMap API for a location name. Of course not all locations on earth have an actual address. Since making many API requests that resemble a game of Battleship will slow down the application, we made a simplified map of earth, in the form of a giant lookup table.
The Matrix anyone?
The lookup table is essentially a 2D map of earth, that we store in memory locally to speed up our random location finding process. When I have a location name I use it to look up a photo of the sunrise for this particular location using the Flickr API. Combining all of this information allows us to draw the main interface for Dawn.
We found the titanic!
To test the prototype I made it run as a ‘Daydream’ app on my android device, which is essentially a screensaver. I kept on improving it, while running it at all times on my desk. At one moment at around 10:30 in the morning the app showed something funny: “RMS Titanic (1912)”. Dawn had found the titanic! After verifying the information on google I saw that at that very moment, the sun was rising in the location where the titanic sank. This made me think, can I add extra information? Since people will be introduced to places they have never heard of, why not provide them a simple way of finding out more?
Discovering new things like that make prototyping worth the cost. Being able to play with a piece of code and seeing it run in its intended context is what makes the difference. It levels the playing ground so everyone, designer or not, can participate in coming up with new ideas and features.
You can try our prototype here:
The obvious next step is to get this running on a smart watch. The first prototype taught us that the idea was good, and that it has potential. Next round will be all about using it in its intended context. Will it still work once I wear it on my wrist? Will the code still run? What places will I discover? Let’s see.