Okay, so there’s a new discussion floating around the Internet. It started with a story of a mortified man who accidentally interrupted a symphony with his iPhone’s alarm. This is always embarrassing, every time it happens. This case in particular was exceptionally well poorly timed, which made the faux pas that much worse.
Some have taken to using this story to ignite a design conversation, specifically whether the iPhone’s mute feature behaves properly. For those who may not know, the iPhone mute switch silences almost all sounds the iPhone might make, with a few notable exceptions. Specifically, its designers felt that the feature should silence sounds that the user did not specifically request. That includes phone calls, email and text message alerts, i.e. things that the user can’t stop from happening. This excludes sounds that the user has specifically requested, e.g. audio that accompanies user-controlled video. The user’s alarms fall into the second category. Because alarms are strictly user-defined, they are not silenced by the mute switch. After the incident with the New York Philharmonic, some people have begun to question whether alarms have been categorized properly. If they haven’t, how should the mute switch affect alarms?
One proposed solution is for the mute switch to silence alarms. Defendants are quick to point out that this would lead many users to miss their alarms. Alarms are historically used to get our attention because time is of the essence. Nobody has ever said “thank God I missed my alarm”. Plaintiffs have since returned with a suggestion that the iPhone should indeed silence alarms when the mute switch is on, but when it is turned on, the iPhone should inform the user of the future alarms he or she will not hear.
Wait. What’s that? Look! Up in the sky! Is it a bird? A plane? No! It’s Edge-Case Man!
That’s right good people of the Internet, I’m here to help you solve this dilemma. Using my superpower, edge-case vision, I can help you see the light. There are a few problems with this proposed behavior.
- First of all, exactly how many of the future alarms did you want to be warned about missing? The next 24 hours worth? More? Less? There is no way of knowing how long the iPhone will remain muted. When do you stop listing alarms?
- The mute switch can be actuated by accident. I have done this countless times, even while my iPhone remains safely in my pocket. Just brushing up against the seam in my pocket can flip the switch one way or the other. What if I don’t know that my iPhone was muted? Now I’m going to miss an alarm that I specifically set? No, that’s unacceptable.
- What if we could eliminate Problem #1’s unknown of how long the phone will be muted? What if mute was controlled in software instead of hardware? The user could tell his/her iPhone: “be quiet for 5 hours”. That would allow the software to clearly warn the user of any alarms scheduled to go off before the end of “quiet time”, and would prevent accidental muting.
The only problem now is that the task of silencing the phone has become significantly more complex than it was. The user must go through several manual steps (increasing the definitive length of the task) but must also declare an endpoint for the silence (adding a new cognitive load). While not ideal, this almost seems reasonable. Except that in real life, this creates the same commonplace frustration that users had to deal with before the iPhone simplified mobile phone ownership. Just imagine explaining to your parents that in order to silence their phones, they must first calculate when they want their phones to be allowed to make noise again. I know that would be the point my parents couldn’t get past: that would be the moment they would decide to quit and go back to a dumber phone. But never-mind the parents… how much will you resent having a prolonged discussion with your iPhone about the muting? I imagine it would be quite like trying to put a 4 year old to bed.
It’s time to go to bed now.
Why?
Because you need to sleep
Why?
Because you need to rest so you can do things tomorrow.
But I’m not tired.
That doesn’t matter. You have to go to sleep. Now.
Why?
Because I said so, dammit! Now shut up and SLEEP!
Clearly, we have lost the tenuous grip we had on elegance. Trying to perfect this tiny feature has just muddied up a much more common activity. Let’s go back and start again.
The embarrassed owner of the iPhone that interrupted a symphony explained that his iPhone was new to him, and that he didn’t know that the mute switch would not silence alarms. In fact, he is quoted as saying:
“I didn’t even know phones came with alarms”
This is unfortunate. Everybody has been a newbie at some point, and nobody likes to feel like an idiot. But his deduction isn’t technically correct: phones don’t come with alarms. Alarms on iPhones don’t exist until they are set by a user. That’s the original premise that led to the decision to exclude them from silencing. He or somebody who had access to his iPhone set that alarm. He certainly didn’t mean for it go off during a concert, and may indeed have assumed that the mute switch would have prevented the interruption.
On the bright side, he probably won’t make this mistake again. This is cold comfort, but mistakes make for some of the most memorable lessons. We can learn things by repetition, by memorization, by deduction, by experiment, but nothing is learned more quickly or permanently than lessons learned by making a mistake. Perhaps this is not such a horrible thing.
As a UI designer, one spends so much energy trying to prevent users from making mistakes that it can be easy to forget that mistakes have their good sides. Certainly, some mistakes are so destructive that the education they provide isn’t worth the trouble. Yes, please tell your child not to touch the stove before he finds out first-hand. But repairable mistakes can be used for good. We should keep in mind that there are different kinds of mistakes.
It may sound like I’m being harsh, but there are times when we have to stop and realize that we cannot (and should not) eradicate all the world’s problems. It’s wonderful to have a phone that is so easy to use that it doesn’t require a manual or a course to use it. But to say that a user doesn’t need to learn to use an iPhone is patently false. Users do learn to use iPhones, but they learn on the job; they learn to use it by using it. This is still a superior experience to learning to use an iPhone (or any phone) by first reading a manual or taking a class. That would not only be boring as hell, it would be harder than hell.
At some point, UI designers need to recognize when they are trying too hard to protect the user from making mistakes. More specifically, we need to be careful that in preventing mistakes, we aren’t preventing the user from learning. A future in which we are surrounded by “yes-men” interfaces would be awful. A life without mistakes is a life without dissent, without argument. If our opinions, our beliefs are never challenged, then there are no facts, no truth. To make that world work, we would interact only with machines and not with each other (à la The Matrix). Our brains would atrophy to the point that we are nothing more than Eloi. Every book you ever read about a utopia was warning you about this.
I first considered this at the 2009 UX Week conference. We were discussing how to prepare mobile phones for their second lives as hand-me-downs in the 3rd world. There was a strong emphasis on iconography, because most of the users surveyed (poor, uneducated housewives) were illiterate. The ethnographic research was fascinating, but I had to ask if we were not doing these people a disservice by directing energy toward making Snake a usable game on a Nokia candy bar phone instead of directing energy toward promoting literacy. There’s a quote by Johann Wolfgang von Goethe that I think sums this up nicely:
If we treat people as they are, we make them worse. If we treat people as they ought to be, we help them become what they are capable of becoming.
So, let’s keep in mind that some mistakes are not fatal. There are some things that users are better off from having learned.