I’m : a programmer, writer, podcaster, geek, and coffee enthusiast.

Designing “Mute”

An iPhone alarm disrupted a Philharmonic performance:

Actually, [the iPhone owner] said he had no idea he was the culprit. He said his company replaced his BlackBerry with an iPhone the day before the concert. He said he made sure to turn it off before the concert, not realizing that the alarm clock had accidentally been set and would sound even if the phone was in silent mode.

And a lot of people started condemning the iPhone mute-switch behavior, which doesn’t mute all sounds all the time.

John Gruber defended Apple’s implementation. Andy Ihnatko strongly disagreed and argues for a hard-line “‘Mute’ mutes everything” implementation.

The iPhone makes very few exceptions to the Mute switch.1 For the most part, exceptions to the Mute switch are:

Apple’s guidelines for developers clearly illustrate their rationale:

For example, in a theater users switch their devices to silent to avoid bothering other people in the theater. In this situation, users still want to be able to use apps on their devices, but they don’t want to be surprised by sounds they don’t expect or explicitly request, such as ringtones or new message sounds.

The Ring/Silent (or Silent) switch does not silence sounds that result from user actions that are solely and explicitly intended to produce sound.

In other words, the Mute switch silences sounds that the user didn’t ask for, but not those that the user explicitly requested. Users are fully in control, in that sense. My iPhone has never made a sound while muted that I didn’t ask it to make.

Ihnatko frames this as Apple’s arrogant design:

My philosophy is “It’s much better to be upset with yourself for having done something stupid than to be upset with a device that made the wrong decision on its own initiative.” …

Apple’s most notable successes and failures usually spring from the same basic company mindset: “We know what the customer wants better than the customer does. …”

Apple certainly shows that attitude a lot (and is often right), but that’s not a fair characterization here.

The user told the iPhone to make noise by either scheduling an alarm or initiating an obviously noise-playing feature in an app.

The user also told the iPhone to be silent with the switch on the side.

The user has issued conflicting commands, and the iPhone can’t obey both.

It’s a typical design problem: it can’t be heavy and light and big and small. Neither decision will satisfy everyone all the time or cover every edge case: if Apple implemented Mute in Ihnatko’s preferred way, millions of people would be just as irritated when their scheduled alarms didn’t wake them up.

When implementing the Mute switch, Apple had to decide which of a user’s conflicting commands to obey, and they chose the behavior that they believed would make sense to the most people in the most situations.

That’s good design.

  1. Ihnatko’s “Case ‘B’” wouldn’t really happen: when muted, alerts from iCal and Reminders only vibrate. ↩︎

  2. Siri is great for setting timers. After putting the quarter in the parking meter, as I’m walking away, I can put the phone up to my face and tell Siri, “Set a timer for 37 minutes.” ↩︎

  3. If only built-in apps were allowed to bypass Mute, we would complain that developers couldn’t make useful alarm apps and Apple was being evil. (Update: Oops.) ↩︎