28 Nov 2016

We Need Ambient Notifications

The other day, I was cooking something on my induction stove. I had set a timer, after which I had more preparation to make. While it was cooking, I worked on my computer, with an ear to the stove. The stove has a fan, which is audible, but not loud or distracting. After a while, I noticed that I could no longer hear the fan, so I concluded that the stove must have finished cooking, and I went to check, and it indeed had, so I proceeded with the next step of cooking.

In fact, the stove also makes a gentle beep it makes when it's done. It's loud enough to be audible, but not loud enough to yank your attention away from what you're doing.

The stove does an excellent job of informing without overpowering. It lets me know that it's done cooking, but gently, without interrupting what I'm doing, whether working on my computer or carrying on a conversation.

The stove is much better behaved than many of our digital devices which make loud and jarring notification sounds that demand that you stop doing whatever you're doing and tend to them. I've been woken up to be informed that an Android update is available. I've had meetings interrupted, conversations at home and with friends interrupted, and even had phone calls interrupted with notifications. Every app developer arrogantly assumes that their app is the most important thing in the world.

What can our digital devices learn from the stove? How can they provide ambient notifications that inform without overpowering? If we did, we'd derive two benefits. First is less interruption and annoyance and stress, and more time spent in fulfilling ways.

Second is a richer interface. Most of our interactions with our devices are currently visual. Sound isn't used as often as it could be. If we could use it, but in a sensitive, understated way, rather than in a loud, jarring way, it would add a second dimension to our interactions, making them richer. Just as talking to someone in person is a richer form of communication than speaking to them over the phone — you can observe their expressions and body language to see how they're taking your points, in addition to what they say verbally.

In order to derive these two benefits, our OSs should support a new type of notifications, which I'll call ambient notifications. These are in addition to traditional notifications, not instead of. Traditional notifications are still the right answer if something is urgent, like turn-by-turn navigation or an incoming VoIP call. But most things aren't, and ambient notifications work better in such cases.

Ambient notifications are just at the threshold of attention, so as not to disturb you if you're doing something more important. It's better for the notification to be missed than to interrupt a user who's doing something more important. How would we achieve this balance?

First, ambient notifications would always play at a low volume, even if the device volume is set to high. OSs have multiple volume controls, and even if all of them are set to maximum, ambient notifications would play at a low volume.

Second, ambient notifications would be very short, perhaps via a limit enforced by the OS. Maybe 100ms? 50ms? Sound designers will be able to tell us if there's a reasonable limit beyond which users may be interrupted or annoyed by the notification. Ambient notifications would be shorter than this limit, even at the risk of being sometimes missed.

Third, some sounds inherently are jarring or otherwise demand our attention. Developers, with the aid of sound designers, should carefully choose notifications that recede into the background and are easy to ignore.

Fourth, sounds should also be distinctive, to be unmistakably associated with a particular app. It shouldn't be a generic chime, say, that can mean anything. This requires a professional sound designer, not an engineer [2] doing something over the weekend. Just as an app icon should ideally be designed by a visual designer, and not a random person who installs Illustrator.

Fifth, ambient notifications wouldn't cause the phone to vibrate, since that immediately draws your attention away from something that could be more important. If your phone is in your hand or pocket, and it vibrates, you immediately pay attention to it. Or if it's on a table, it rattles, which is annoying. So, no vibration.

Sixth, ambient notifications would either cause the LED to flash, or play a sound, not both. Doing both is redundant and excessive, given that the goal is not to seize your attention at any cost. If the LED flashes, it would flash only once, and only dimly, depending on the ambient light, so as not to blind you in a dark room, or wake you up by shining a bright light in your face, which happened to me. The brightness of the LED would also increase gradually, say over 20 seconds, rather than abruptly, since abrupt changes in our environment immediately grab our attention, an evolutionary leftover from our days when that could mean a tiger in the bush. After the LED reaches peak brightness, it again fades away gradually, as gradually as it came on.

Seventh, any app should be able to delay ambient notifications globally if the user is performing a task in that app that notifications would conflict with. Remember, ambient notifications always yield to other things. In that sense, they're respectful citizens. Examples of such tasks are an active phone call, VoIP or video call, turn-by-turn navigation, music and video playback, and games. In those cases, ambient notifications would be delayed by the OS till the task ends. In fact, audio or video playback in any app would delay ambient notifications, even if the app didn't specifically take care to turn them off.

Eighth, apps should be able to turn off ambient notifications at a particular time, even if the user isn't actively performing a task in that app at that time. An example of that is a calendar app, which automatically turns ambient notifications off for the duration of a meeting. You may not have opened the calendar app on your phone, and scheduled an event on your PC, but when it syncs down to your phone, the calendar app on your phone would tell the OS not to bother you at that time. Another example is a sleep tracker app that detects that you've fallen asleep. Or a fitness tracker that detects you're running or cycling or otherwise exercising. Or driving, at which point a notification could be dangerous.

Ninth is the time of day. The OS would automatically turn off ambient notifications at sunset, and turn them on again only at sunrise. This discourages use of screens after dark, when it affects sleep. In addition, ambient notifications would be turned off when people may be asleep, which is till 9 in the morning, and from 1-5 in the afternoon [1]. Better to delay an unimportant notification than risk waking up sleeping people for trivia. Besides, four hours in the morning and an hour in the evening is plenty of time to notify you for things that aren't urgent, which is the entire use case of ambient notifications. Urgent situations, like an incoming phone call, would use normal notifications, anyway.

Tenth is throttling. The OS would permit no more than one ambient notification in 20 minutes say, so as not to overwhelm the user [3]. The OS would also disallow apps from showing ambient notifications if, say, you haven't used the app in a month, and you ignored the last few notifications the app sent you.

On iOS, ambient notifications wouldn't need approval from the user, since they don't disturb them. This also provides an incentive for apps to use them in preference to normal notifications, thereby aligning incentives. And if an app decides to use normal notifications, iOS still shows a prompt as usual, but in addition to Yes or No, there'll be a third choice, Allow without disturbing me. If you choose that, normal notifications from that app will be converted to ambient notifications.

Ambient notifications, implemented this way, will let us take control back from notifications that interrupt and annoy and add to stress. And adding notifications via gentle sounds will make our UIs richer to interact with than mostly visual, allowing a higher bandwidth of communication between the user and the device.

[1] An OS may allow users to change these, but the defaults should be conservative. Better to delay an unimportant notification than wake up a sleeping person for trivia. A UI for customisation may be like:

I'm up by [9 AM].

I may also sleep in the afternoon from [1:00] to [5:00].

If your sleep time varies from day to day, overestimate rather than underestimate your sleep hours, so that you're not disturbed.

[2] Unless the engineer is also experienced at sound design. The important thing is the skill, not the job title.

[3] Perhaps with a burst of up to 2 ambient notifications within a 20-minute window, perhaps using the token bucket algorithm.

No comments:

Post a Comment