A Better iPhone Mute Switch

Justin French, January 2012

Two weeks back, many of my favorite tech bloggers were covering the story of a switched-off iPhone’s alarm stopping a performance at the New York Philharmonic.

It should be smart!

John Gruber argued that this is an edge case — while Apple’s design is more complicated than simple “Off” and “Mute” switches, it’s far more likely to do what the user expects in most cases:

I think the current behavior of the iPhone mute switch is correct. […] if the mute switch silenced everything, there’d be thousands of people oversleeping every single day because they went to bed the night before unaware that the phone was still in silent mode.

I mostly agree with this sentiment.

It should be dumb!

Andy Ihnatko argues that Apple’s design made it hard for the user to prevent the interruption:


My phone is almost always switched into silent mode (usually deliberately), and I rely on the alarm to wake me every day. The interesting thing here is that I learned that this is how the iPhone works, and have now become accustomed to it. If I interrupted this performance, I’d argue that the fault was completely on me — I could have ensured that there were no active alarms, or left the phone at home.

In the case of the Philharmonic, this was a brand new iPhone, and the owner learned the hard way how it works. It’s hard not to fault Apple here, despite Apple’s overall design being much better most of the time.


Here’s the requirements I’m hearing so far:

  1. It would suck to miss an important alarm, no matter who is at fault
  2. It would suck to be that guy, no matter who was at fault

As Marco Arment succinctly points out:


What about a preference?

Dan Benjamin also argued for a dumb switch, but in a later update, raised the idea of a preference:

Know what would be really cool? Let users decide for themselves what the switch does. They could call it a “side switch” like they do on the iPad, and give us choices about what it controls.

A preference or user configuration is a pretty obvious and valid design crutch when faced with requirements that contradict each other so drastically, but in this case, I think it raises more questions:

  1. What would the default preference be? If it defaulted to Apple’s existing behavior, the conductor was still going to get interrupted, and if it was the other way around, I would have missed quite a few important alarms by now.
  2. As they choose their preference, would users understand the design trade-offs and spend as much time thinking about this as Apple, John, Andy, Dan, you or I have?
  3. Would this preference still result in people being surprised and disappointed?

What else could we do?

I think Apple has solved most of the problems already with a great design – the alarm does the right thing in the majority of use cases. At this point, with millions of iPhone customers now relying on how this stuff already works, it would be a shame to either go back to something dumb or offer a preference between smart and dumb without first answering a simple question:

Given this new information, could we improve the experience by making the smart stuff smarter, instead of dumber or configrable?

I think the answer is yes! Let’s take a look at those two opposing requirements again:


What about this: When the iPhone is in “silent” mode, all alarms start off with vibration only. After a minute or so, the audio gradually fades in, increasing to full volume over the course of another two minutes.

Most mornings, I think the vibration of my iPhone alone would be enough to wake me. If not, I’d much prefer I wake up a few minutes later than completely miss the alarm because of a dumb switch (or a dumb user!). I think this satisfies this first requirement just fine.

For the second requirement, that guy would have had 60 seconds of silent vibration in his pocket to realise something’s going on, and another 60–120 seconds before the alarm was at full volume. Not as perfect as a dumb switch, but a significant improvement.

Maybe I’ve missed something, maybe it’s already been mentioned elsewhere, maybe it’s already built and tested by Apple, but this sure is an interesting design problem I enjoyed thinking though over the weekend!