On January 10, 2012, an iPhone sounded the famous “Marimba” alarm. You know the one. Unfortunately, this iPhone belonged to a man seated in the front row of the New York Philharmonic, and the orchestra was in the middle of Mahler’s Ninth Symphony. The conductor, exasperated, let his arms fall to his side, silencing the music. For an uncomfortable period thereafter, the only sound in the concert hall was Marimba. Pure poetry. If you missed it, you can read Daniel Wakin’s report in the New York Times or, through the magic of the interneteratti, enjoy a simulation.

Considerable debate among technology bloggers I follow has erupted over this incident because of one fact. The concertgoer’s iPhone was “silenced” with the “mute switch.” Naturally, this poses a question. Should alarms sound even when a phone is set to mute? Marimbagate (yes, I said it) surely points out the downside to alarms sounding when the phone is muted, and your initial reaction might be, like that of Andy Ihnatko, mute means mute. When the switch is set to silence, the phone should make no noise under any circumstances.

This problem is more general than phones or even technology. It’s inherent in the design of complex systems with many, heterogeneous users, whether they be legal systems, computer networks, or ubiquitous, mass-market devices. What to do when any choice of system behavior will at times deliver unexpected results but where meeting expectations is the goal? This particular controversy illustrates how a device in the head is different from a device in the hand and how a seductively clear and simple rule may turn out, in the hand, to be the less desirable one.

In the abstract, Dan Benjamin’s argument is compelling: “Physical settings should always trump and override software settings. If you’ve flipped a switch, you’ve told the iPhone something very important, just like when you flip a switch in the real world.” Further, he argues, the behavior should mirror that of real switches, like light switches, in that the switch should completely disable the system you’re trying to turn off. Mute means mute, as he titles his post. “When I ask the iPhone to be quiet, I’d really like for it to be quiet and stay quiet until I ask it to make noise again, and I think most people expect the mute switch to mute everything.”

As Ihnatko puts it:

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.

… .

[T]the right answer seems clear. The iPhone must never let a user down the way it let down that man at the philharmonic.

But the iPhone, and many similar devices, are designed to let such a user down in order not to let other users down. As Ihnatko acknowledges, the simplest solution will inevitably result in users’ not waking up on time, missing flights, and otherwise having their expectations foiled in situations where they really didn’t want mute to mean mute. As Marco Arment summarizes, the iPhone mute switch mutes all sounds except: (1) Sounds in the Movies or Music apps when you play a movie or song. (2) Third party apps that explicitly choose to ignore the switch but only if the app is in the foreground, the one you’re currently running. You can hit the sleep switch and the sound will play, but if you exit the app by hitting the Home button, the sound will not play. (3) Alarms and Timers set in the Clock app. (But not Calendar items.)

In each of these three cases, you, the user, are explicitly telling the device to make noise. The design problem is to figure out whether that instruction or the instruction to remain mute should be ignored. The simplest answer, and the most conceptually appealing, is to respect the switch, turning all sound off. In any system, a simple answer that delivers desirable results is preferable to a more complex answer. But sometimes conceptually simple solutions have unintended consequences. And the solution that is more complex conceptually (in the head) is simpler and better in practice (in the hand).

So here’s the downside to mute meaning mute. Suppose you use your iPhone as an alarm clock, as I do. Suppose you also either generally mute your phone, as I do, or at least do so at night to prevent notifications from sounding at 2 a.m. Your alarm would not sound if the mute switch were on. To silence my phone but allow the alarm to sound would require me to unmute the phone and put it in airplane mode — so that no other notifications would come in. The simpler solution is, for me, more complex.

In the head, the device should obey the conceptually simple rule. In the hand, most users expect the device to follow a more complex rule: mute everything except the things I expect to make noise. The iPhone, in my view, obeys the more complex rule that makes for the simplest user interaction. I want my phone to wake me up in the morning and vibrate instead of ringing for phone calls, texts, emails, and the like. The design choice is the simplest rule that matches general user expectation, even if that expectation is not the simplest conceptually.

Let’s think about what has to happen to create a Marimbagate. First, you must have an iPhone, go to the Clocks app, and set an alarm. Second, you must be somewhere where you do not want the alarm to sound at the time you set it to sound. Third, you must be unaware that alarms will sound despite mute and also not have turned the phone off. Fourth, you must, despite having set the alarm, not know how to silence it. Marimbagate only happened because the user had an iPhone he didn’t know how to use that had been given to him with alarms set (for odd hours) by someone else.

How often will that happen compared to the frequency with which people want to use their phone as an alarm clock but still otherwise be silent? I’d lay a large sum that the latter is far, far more frequent. This is John Gruber’s conclusion as well:

You can’t design around every single edge case, and a new iPhone user who makes the reasonable but mistaken assumption that the mute switch silences everything, with an alarm set that he wasn’t aware of, and who is sitting in the front row of the New York Philharmonic when the accidental alarm goes off, is a pretty good example of an edge case.

Whereas 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’d go further than Gruber. I bet that most new iPhone users if asked what the mute rule was would respond with “mute means mute.” They would be responding to a question about the right conceptual model. But if you measure their expectations from the way they actually use the device, then you’d see they expect the device to behave pretty much the way it does. The simplest rule, so clear and easy in the head, doesn’t take account of how most people would live with it.

This distinction, between thinking abstractly about rules and considering their consequences, is apparent in the law as well. In the abstract, many people prefer simple solutions like border fences to keep out all illegal immigrants and stiff penalties and deportation for those who get through, but faced with an actual person caught up in such a system, people’s views tend to change. Sentencing a real person to prison or death is far, far different from determining what the right punishment would be for an abstract criminal. Hard-core libertarians are famous for conceptually simple solutions that fail to take account of how life is really lived. In the head, law is easy, but in the hand, we naturally, and more simply, latch on to a more complex calculus for what the rules should be.

Back to the iPhone, well how about settings? Let users, when they set an alarm, further specify whether that alarm should sound when the phone is set to mute. Yes, settings, the solution to every problem on which users might differ, right? More choice is better! Not necessarily, yet again the conceptually simple solution to heterogeneity — choice — fails to take account of what is practically simple. Yes, the introduction of this one setting might not be a big deal. But the mode of thinking that sees every heterogeneity in use as a mandate to introduce a choice, well, there would be no end to it. That way lies disaster, like this and this. An interface littered with choice is one dripped in sadness.

Ihnatko believes that if there are such settings, the default should be that the mute switch silences explicitly set alarms. It seems to me that settings, regardless of default (and I think Ihnatko’s choice of default would exacerbate this), would lead to am/pm and “separate knob” mistakes. You start with the simple, conceptual model, and then to accommodate how people actually use the device, you add settings and choices. But now you have a device that matches no one’s conceptual or practical model but is instead something to be configured. In the immortal words of Jean-Paul, “Why separate knob!? Why separate knob!?” In an instant, Seinfeld gets to the heart of it.