The Genesis of “The Most Beautiful Clock App in History”

By Feng Qiu
July 19, 2024
Clock AppUser ExperienceProduct Design
🔔
Article image

Instead of diving into heady, professional topics like "interaction languages" or "design philosophies," I find that most users are actually more interested in the story behind each app and its features.

The Smartisan OS "Clock" app was once called "the most beautiful time-keeping app in history," and today, I want to share a few of those stories with you.

The Day-and-Night World Clock

The clock face of the World Clock would change dynamically based on the local time of the city it represented. If the city was in daylight, the clock face was white; if it was nighttime, the clock face turned black.

This small detail was first mentioned on stage at the Smartisan OS launch event back on March 27, 2013.

Article image

"Black face for night, white face for day" is the simple summary of the feature, and for the most part, it's accurate. But this glosses over a detail that's easy to ignore, yet perfectly reveals the level of thoughtfulness required: Where, exactly, is the dividing line between day and night?

In our early versions, we took the naive approach: we hard-coded "day" as the period between 6 AM and 6 PM, and "night" as everything else. This worked passably during the spring and autumn, but the flaws became obvious in winter and summer. In temperate and colder regions, the sky is already getting light at 5 AM in the summer, yet the clock face would still be black. In the winter, you still need streetlights to walk at 7 AM, yet our clock face would be white.

My first thought was to define three sets of times: one for spring/autumn, one for summer, and one for winter. But after a moment's consideration, it's clear this is still a form of what you might call "mid-latitude-centrism." When we think through problems, we are all—often unconsciously—limited by our own environment. In this case, I've always lived in a mid-latitude region, so my entire mental model of day and night was based on that experience, typically ignoring the unique conditions in low or high-latitude areas. Besides, even within the same latitude, when the sun has already risen in Beijing, it is still dawn in Ürümqi. It was clear that any method of manually defining the transition point was a dead end.

At this point, we needed a more precise approach. Using the actual local sunrise and sunset times was the obvious answer. After some research, our engineers found that such algorithms did exist. As long as you have a location's date, time zone, and latitudinal/longitudinal coordinates, you can calculate its sunrise and sunset times for any given day. The date is easy to get from the phone's system; the challenge is getting the correct time zone and coordinates for every city.

A Quick Detour into Time Zones

Here, it's important to clarify what "time zone" means. The "GMT+8" or "GMT-5" zones we're familiar with are theoretical time zones. In the real world, governments may not adopt their theoretical time zone and can even change it. For example, in March 2014, Crimea moved its clocks forward by two hours to adopt Moscow Time.

Furthermore, the time zone database used in software (the tz database) is not organized by these theoretical offsets. For example, Paris (2°21′ E) and London (0°7′ W) are, by longitude, both located in what should be the UTC time zone. In reality, France uses Central European Time, which is one hour ahead of the UK. In the tz database, this is reflected not by a simple offset, but by unique location identifiers: Europe/Paris and Europe/London.

[object Object]
Theoretical Time Zones(from wikipedia)
[object Object]
Time Zones in the Computer Time Zone Database(from wikipedia)

For the next week, an engineer and I went down a data-entry rabbit hole. We manually looked up and cross-referenced the names (in Simplified Chinese, Traditional Chinese, and English), countries (in all three languages), time zones, and specific latitudinal/longitudinal coordinates for 622 cities. All the while, the engineer was repeatedly validating the algorithm.

And so, in the release notes for Smartisan OS v0.8.8 α on December 4, 2013, a new line item appeared: "The World Clock face color now changes between black and white according to local sunrise and sunset times."

When Engineers Become Designers

In fact, because of our relentless emphasis on user experience and visual perfection, many of our engineers developed an incredibly sensitive intuition for design.

A specific example: the official Smartisan Weibo account once shared a video filmed by a user. The video showed that after each tick, the Clock app's second hand had a slight rebound, just like a real quartz clock. This animation was something an engineer had added on his own initiative.

I remember checking in with this engineer on his development progress one day. After we finished, he said to me: "I think we should add an effect to the second hand. On a real quartz clock, the second hand always has a tiny kickback after it moves. Our app's second hand doesn't have that, so I made a version that does. Take a look."

I was blown away. Normally, engineers dread feature requests from product managers, but here was one of our engineers proactively creating a new visual design requirement for himself. We reviewed the animation and thought it was fantastic—the rhythm and intensity were perfectly tuned. We added it in the very next release.

The Limits of Internal Vision

The two stories I've shared so far are about how we improved the product internally. But my experience is that a product's evolution can't just rely on the team "thinking up" new requirements. The problems that users discover and report back to us are just as critical.

Product managers and designers spend every day thinking about how to improve a product, but there will always be things we can't think of or fail to notice. As the old saying goes, "Even if your body is made of iron, how many nails can you forge from it?" You can't do it all yourself. Sometimes, you need the feedback and push that only your users can provide. Let's stick with the Clock app as an example.

Shipping the "Perfect" App (And What Happened Next)

To date, we've launched four standalone apps: Hammer Clock, Hammer Notes, Smartisan Cloud Sync, and Hammer Calendar. Of those, Hammer Clock was the very first. There were two reasons for this. First, the clock is a self-contained application that doesn't depend on other system functions, making it ideal for a standalone release. Second, it was a great showcase for the high standards of our company's designers.

In July 2013, "Hammer Clock" went live on various Android app stores. Honestly, our thinking at the time was that an app at this level of polish, with these features, was basically perfect. All we had to do was sit back and wait for the universal praise to roll in.

And in fact, after its release, Hammer Clock did receive a flood of positive reviews. But even though we knew our users had unusually high standards for experience and aesthetics, we were still shocked by the suggestions they sent back.

I can give you a few simple examples.

One user discovered that the "Tripoli" in our world clock didn't match the actual time in "Tripoli"—it was off by a few hours. After some digging, we realized that there are two famous cities named Tripoli: one is the capital and largest city of Libya, and the other is a city of the same name in Lebanon. In a subsequent update, we made a small but important change: we added the country name next to the city name in the world clock list to distinguish them.

Article image

Here's another example. Our stopwatch had a lap timer feature. There are two ways to display lap times:

The first is Interval Time. Think of one person running multiple laps around a track. When they complete a lap, you hit the button to log the time. The second time you log a lap, the time displayed is for that second lap only.

The second is Cumulative Split Time. Imagine timing a race with ten people. You hit the button as each person crosses the finish line, and each log records the total elapsed time at that specific moment. This gives you the final score for each of the ten runners.

Neither mode is "right" or "wrong"—they just serve different use cases.

In our first release, the app only showed Interval Time, and we quickly heard from a lot of users who found this confusing. So, in a later version, we added a toggle switch that let users choose which mode they wanted to see.

But the feedback kept coming. Users told us that even with the switch, it was still inconvenient. They often wanted to see both types of results at the same time.

Ultimately, this pushed us to rethink the design. We went back and modified the interface to display both the interval and the cumulative split times simultaneously.

Article image

Then there was the time a user discovered that the minute hands on the World Clock and the Alarm Clock updated at different frequencies.

This might be a little hard to picture, so let me break it down. On a physical clock, as the second hand moves, the minute hand also creeps forward by a tiny, almost imperceptible amount with each tick. For every full space the second hand moves, the minute hand moves 1/60th of that space.

A user noticed that our World Clock simulated this perfectly: the minute hand moved incrementally along with the second hand. But on the Alarm Clock, the minute hand would stay completely frozen while the second hand ticked all the way around. Then, in the final second, it would suddenly jump forward one full minute.

It was such a tiny inconsistency, but our users found it.

During that period, I would wake up every single morning to a dozen or more messages about details just like this. The pressure was immense. But it was precisely this kind of relentless, detailed feedback from our users that pushed the Clock app to improve so dramatically, building upon a foundation we already thought was great.

Share this article