A Better Way to Track Global Time

As a consultant who travels frequently and keeps clients, friends, and family in all corners of the globe, one of the things I'm constantly juggling is what timezone my meetings are in. This difficulty is compounded by no one else being willing to deal with the time conversions. Asking around, I realized all of my colleagues who travel frequently have similar frustrations. Most of us relied on the native android/iOS clock apps or simply asking google what time it was in a given location. Each approach had it's limitations. The native apps were limited by search: you had to know a major city within the same timezone you were scheduling around. Fine if you are in New York or London, but frustrating if your friend happens to be in Punto d'Ouro, Mozambique or on the Island of Mabul. Asking google for the time always worked, regardless of how remote the location, but it's results were not persistent. I wanted both, an application that returned times for any location on the planet and remembered all the timezones I was interested in.

Choosing the API

I originally targeted timezonedb.com to access the timezone information, but soon realized that it's city search API was much more limited that I wanted. It required that the user select a city, and didn't have nearly the same scoped dataset that google provided. Google seemed like the best solution, and with a little searching I found they have a timezone API. Unfortunately it only accepts results from providing geo-coordinates. But a google Places Autocomplete query provides geo-coordinates for any location which can be easily passed to the timezone API returns everything else I need, the current time in the location, the offset from GMT, and if the location is currently in Daylight savings time. I was ready to start building.

Rapid Prototyping

I already had a good idea of what the product requirements were, so I jumped right into the prototype. I wanted to get a working proof of concept done before I started in on the visual layer. This allowed me to hammer out any problems with the application before I got bogged down pushing pixels.

Responsive Scaling

I wanted a design that would scale fluidly between responsive states, so the clocks always took up as much screen as you gave them. However, the internal layout of each clock required a static layout just to keep readable and looking clean. So I settled on having a fixed layout, and then fluidly scaling the clocks all together with a 3D transform ratio applied via Javascript attached to an event listener that detects changes to layout.

User Testing

A simple, single page application with very little depth to the user flow is a good candidate for a high rate of problem discoverability. This means testing with 5 users should discover the large majority of usability issues. I sat on sessions with a small number of users who were trying the app for the first time and noted where they were getting lost or confused within the app. This insight allowed me to adjust the introductory tutorial, add features, and tweak the visual design to overcome usability issues.