A Better iPhone Mute Switch

Justin French, January 2012

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!

No. I should slide the switch to “Mute,” and then the phone goes SILENT. If I miss an appointment because I did that, it’s completely on me. If my phone disrupts a performance despite the fact that I took clear and deliberate action to prevent that from happening…that’s the result of sloppy design. Or arrogant design, which is harder to forgive.

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.

What about 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:

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.

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?

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:

It would suck to miss an important alarm, no matter who is at fault

It would suck to be that guy, no matter who was at fault

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!

This is the online home of Justin French. A designer, developer and product nerd from Melbourne, Australia. You can follow me on Twitter and Github or subscribe to my RSS feed.