More on the ring that stopped the show

I thought it was merely a funny story, albeit mortifying for the poor fellow at its heart: during a quiet passage of a symphony, a front-row patron's phone went off, echoing throughout the hall and causing the conductor to halt the performance until the offending phone was silenced.

The details are key:

• The phone was an iPhone.
• The owner, who is anonymous in the New York Times account everyone has read, said he had been issued the phone only the day before by his employer.
• The owner had hit the "Silent" button before the concert started, and believed this would keep the phone, well, silent.

It turns out that, first of all, I have to 'fess up to totally bogus technical advice:

... he seems to have been laboring under the understandable misconception that merely locking the screen turns the iPhone "off". (For future reference, the easiest way to silence your iPhone is to use the "vibrate" button and to keep it out of contact with resonant surfaces like hard tabletops.)

In fact, current iPhones have a Ring/Silent button, so I was completely off base suggesting he had merely locked the screen. I still use an original iPhone, so I am unacquainted with more recent models' hardware and software (the original iPhone cannot run iOS 4 or later). I therefore should never have piped up with my unsolicited and smug advice. I thought about deleting that part of the paragraph as unduly smug, in fact, but finally let it stand. Ah me: hindsight is always 20/20.

Anyway, it seems that the iPhone's behavior is more subtle than I thought. The Ring/Silent button, according to Apple's developer guidelines, is meant to suppress sounds the user didn't "expect or explicitly request, such as ringtones or new message sounds". The reason the phone started ringing was because the fellow had (apparently by accident) set an alarm earlier in the day. An alarm is deemed to be an intentional action that is not subject to the Ring/Silent button's "silent" setting.

Daring Fireball's John Gruber argued that Apple's design decision, to allow explicit user actions to override the "silent" setting, was correct. His rationale heavily favors those who use the iPhone as an alarm clock:

... 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.

It seems to me this is the kind of mistake you make only once, assuming you figure out the root cause. Still, there's one vote for the status quo.

Andy Ihnatko has a lengthy counterargument. His argument is to follow the principle of least surprise.

The key question to ask is “When the user slides the switch to ‘Mute’, what does he or she think is going to happen?” They’re most likely to think that their iPhone will be completely silent until they flip that switch back.

Ihnatko concedes that Gruber's unsuspecting sleeper will be disagreeably surprised when she wakes up late the next morning, but says that this bad outcome is better than what happened to the fellow at the concert.

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.” Every time I screw up and take responsibility for my own stupidity, it’s another Pavlovian stimulus that encourages smarter future behavior. If I forgot to unmute my phone after a movie, I’m a dumbass. But if my iPhone makes noise during the movie despite the fact that I’d deliberately chosen to silence it, I can only conclude that the dumbasses in this equation reside about 3,000 miles west of here.

Marco Arment, in turn, agrees with Gruber. He boils down the situation to its essence (emphases in the original):

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.

...

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.

Arment is the one who cited and quoted the Apple developer guidelines I mentioned above. They're a fine explanation, but not entirely appropriate to what is essentially a user-experience question. The fact that the developer guidelines explain Apple's rationale means exactly squat to the vast majority of iPhone users, who, after all, aren't developers.

It turns out, though, that Apple's manual for the current iPhone running iOS 5 sets forth the behavior (though without giving a rationale for it) on page 146:

When set to silent, iPhone doesn’t play any ring, alert, or effects sounds. It does, however, play Clock alarms.

Not that the humiliated patron of the arts who started this back-and-forth would likely have seen this: as noted, he had only been issued the phone the day before. He would have to have been an idle (or obsessive) fellow indeed to have made it through the hundreds of pages of the user guide to find this sentence in only a day, or even the similar one on page 49. And if he had been the kind of person to have read the entire user manual that quickly, he also would have realized he had set a bogus alarm, and would have cancelled it prior to the concert.

Ihnatko's position makes more sense to me than Apple's because it's so easily stated: "Silent" means silent, period. It also emphasizes the primacy of a hardware control over software ones, which is intuitively sensible to me. There's nothing subtle, nor should there be, about a physical button: it should be a big, inarguable override to whatever you might have done in software. The reason is, you're likely to use the hardware control when a situation requires enforcing swift and sure behavior on your phone. When you enter the symphony hall, you're concentrating on the concert ahead, not on the weekly reminder to take out the trash that you set months ago which will, it turns out, go off during the concert. Can you imagine instead having to unlock your phone and search it for all the potential noise-making triggers you might have set? Madness.

I'm sure there is or will be a bug filed about this incident with Apple. I only wish I could see the discussion among the engineering staff.