Why Apple can’t design Time?

Hi, there.

Today's letter took quite a bit of trust in our relationship here. The topic is a bit nerdy and quite wonky but I promise there is a good return at the end. At least, I hope so. I am trying something here and I hope we can all enjoy the ride.

‍

‍

Why Apple can’t design Time?

More specifically, Apple can’t design a UI for Time Input. But that is not as catchy, and well, have a look for yourselves.

‍

To set the time, you have to laboriously spin the software dials to get to the specific digit of the time you want to set. Whenever I go to set multiple alarms, it feels like a chore. On the other hand, a numpad is more physical and more cognitive effort and introduces the delay of launching a keyboard for simply entering time. We can do better! Now designing a Time Input UI is not complicated in my opinion (or, is it?), and someone has actually already solved this puzzle that requires merely a couple taps. But let’s not get ahead of ourselves. Let’s put our First-Principles Thinking Hat on and try to design a Clock UI for Time Input, to establish a platonic ideal, once and for all. For this, I want you to forget for a moment, that there is any such thing as a Clock in our world here! Trust me on this!

Now, to design a Time Input UI, we basically have to solve for two things: Representation of and Interaction with Time. I can’t think of dividing the problem in any more parts and I can’t think of a more fundamental notion. So, Representation and Interaction it is and for our purposes it shall suffice.

We measure time in our lives in seconds, minutes and hours, 24 hours makes a day and these are split into two halves of 12 hours each, for day and night.

Now as with any measurement, it would be logical for an individual to represent Time on a linear scale. A Line divided into 24 parts, and so on. Now, interestingly, this is what an awesome app called Timely, does. Basically, they place the scale on the left edge of your mobile screen. And you can simply tap (presumably, closer to the time you want to set), and then drag up or down to make finer adjustments. This usually takes you to within 15-minute window of the time and that is enough for my alarms, meetings and most other scenarios. If you want more precision, you can tap above or below the slider-bar to change time in steps of 5 minutes.

This is incredibly quick [perhaps, 10x than Apple’s] and as intuitive as a volume slider. And I immediately loved it, and wasn’t surprised when I discovered Google actually ended up acquiring the app. The UI they have for other elements like Timer and Stopwatch are really well-designed too, and I recommend you checking out the app.

You must note here that Apple’s UI is skuemorphic of the dials found on Watches and misses the insight that we almost never need to set time more precise than ±5 minutes. In the very rare case you do, Timely provides a way to tap on the slider and launch a numpad to enter the exact time.

Now the problem with Timely’s design is that it is not robust across devices. While it is okay for the scale to take up the full left-edge of my phone, in a screen completely dedicated to setting the time, the UI doesn’t work when there needs to be more elements on a screen or on a pop-up. The bigger problem, however, is that the scale length must be big enough for 24 hours to be comfortably spaced out for your thumbs and your eyes. This is why I wasn’t surprised either that Google didn’t implement the Scale UI across any other part of their eco-system.

The Scale UI for Time Input is not robust across screens, systems and eco-systems.

Moving on…

For our time-input UI to be robust, it has to be independent of the device it is on. The Scale UI was dependent on the edge and the height of your mobile phone. That’s no good. Instead, we want it to be in a “self-contained frame”. (If there are any Figma designers here, you are used to working with the idea of frames.) The scale - the line - can be contained in a rectangular frame like the volume slider, but then the demanded length for 24 hours constrains it to be weirdly long/tall for most screens.

How about we instead close the line in a loop - a Circle. The Circle can likewise be any polygon, but it doesn’t matter as the user sub-consciously remembers the position of numbers relatively around a center. So it might as well be a Circle! [Remember: there is no such thing as a Clock in our world here, yet.]

​

24 Positional Markings can still be a lot to remember around a circle, but here we can switch to 12 hours and simply give a AM/PM toggle. Now I don’t know specifically about you, but imagining time in 24-hour periods always felt less natural than the 12-hour. A friend once told me there are cultures that count day and night as two units; essentially two “days”. In any case, nobody seems to have a problem with 12-hour clock.

‍

For interaction:

One can set the time in exactly the same way as physically turning the hour and minute hands, but two hands will come in the way of each other. Like our Scale UI, people would rather directly tap and then drag the hand if needed. Here, once you lift your finger after setting the hour, the whole Circle UI can immediately switch to minutes, and so on.

A simple Tap, Drag, Set on a circular "scale" - A Clock - is the ideal UI for Time Input. You can now bet that it will be the future for representing and interacting with Time.

This is the implementation that Google has today across it’s entire software suite, something that Apple almost comically missed. This design will work on phones, desktop, tablets, and smartwatches. With touch input, SmartWatches itself can indeed move on from the dials. As it turns out, the ideal UI for entering time is really just a Clock!

‍

*Ending on an unexpected note…

Most design solutions are inspired from observations and this scares the shit out of me.

Here, we could’ve immediately thought of the circular Clock Representation without thinking about the Line first. But the whole point of this exercise was to be rigorous in accordance to a logical theory.

Interaction Design is a funny discipline. Unlike something like software development, where you are working within a well-defined technological system where solving most problems has to do with understanding the system better, Interaction (Product) Design exists in the messy reality of the human realm. Most design solutions are inspired from observations and this scares the shit out of me.

I don’t want my design ideas to be a function of lucky observations. Rather, I want to try work out a theory which will probabilistically render me the better ideas. And so, whenever I come across an anecdote of a design team, I invest less attention in what inspired them to produce a design, and think more about how I can iterate upon the ongoing theory of mine that can help me arrive at such design ideas in future.

Way back when, I used to practice a preliminary version of this where I would try to collate all the reviews from YouTube and Blogs into a single unified analysis for a particular Product. Today, I have moved on to deeper, at the level of Philosophy, Marshall McLuhan, Information Theory, and so on.

Coming up with the Clock UI for Time Input could be the result of common sense springing out of an observation; of people changing time on physical clocks by literally moving the hands, but coming up with Design ideas from observations is a function of luck. You have to be lucky enough to experience the observation. Here, an ability to invent product ideas from first principles reasoning based on useful theories and models is the essence I aiming for with discourses like today’s. For all we know this is how the Clock Design was originally conceived and now, you can bet that it will be the future for representing and interacting with time.

Put simply,

When observing product design teams, instead of obsessing over how a particular team came up with the design, ask how you could come up with the design idea based on an ongoing theory of yours.

Imagine if you could wipe out your life into a blank slate, your mind reset to point zero, and then you start adding objects one-by-one mindfully. You will have just created a lifestyle from first principles. In a new media landscape, such a rebuilding is imperative. This is the mindset Productize Philosophy aims for. You can check out the ongoing theory here…!

The Theory of Productize Philosophy

‍

‍

📚 Curations for Today

👉 Today's discourse was an exercise in information permutations and combinations across Space and Time. If you want to try another such exercise, check out this essay: Timelines Are Not Always Lines: An Evaluation of Different Timeline Shapes.

​

👉 You can also check out my essay on Notification Systems. Apple's WWDC 2021 featured a notification system as moderated by an algorithm. Now, if you're familiar with HEY E-Mail, you must know that there's almost no need for an AI to manage E-Mails like it is on G-Mail. Just like HEY Email showed GMAIL that you don’t need an algorithm to manage emails with better design, in the above essay, I show how Apple doesn’t need an algorithm to manage notifications.

‍

‍

🎉Yeah!!!

I hope the above discourse made sense to you and do let me know if you would look more of it.

I have around 60 subscribers to this newsletter, and I am looking to expand my circle. Do you know one person you think can benefit from these newsletters, please let me know and I will personally message them along with the best ideas of Productize Philosophy. I promise to make you look good.... unless for some wonky reason 🤣 you don't want me to mention you.

Please consider giving me a shoutout on Social Media. You can share any specific letter from the button below!

​Share this NewsLetter on Twitter | LinkedIn | Facebook | Pinterest | Mail to Someone​

And, ofcourse, if you are new here, first of all, thank you and here's the archives for you to binge. Cheers! 🍻 Let me know how it goes:

Productize Philosophy Archives

​And as always, do reply with any thoughts, criticisms and feedback, is most valued.

​
Until Next Week,
Abhishek Agarwal
​Blog | Twitter

‍