iOS notifications: a better implementation proposal [Update #3] - Post WWDC 2011 Keynote

[Scroll to bottom for the updated info following the WWDC 2011 keynote.]

In a previous blog post (iOS notifications: what are the problems?), I exposed the real issues that lies under the current implementation of iOS notifications. Those who think Apple is interested to buy the maker of Boxcar are misunderstanding the issues. The iOS notification backend is not the root of the problem. Nor is the way push notifications works. The problem is the user experience of handling push notifications. Boxcar is an application that helps you define triggers on Twitter or an RSS feed to get notified under certain conditions. This is not where Apple needs to invest its resources. What needs to be fixed is very simple:

• how do we present notifications to the user in a way that is less obstructive
• how the user can peek and manage the notification stack

Less obstructive notifications
In order to implement less obstructive notifications to the users, one must understand the stages of notifications:

• visual cue for new notifications
• invocation method to get access to the notification stack
• management of the notification stack

Visual cue
The first part of my proposal is to focus on the visual enhancement targeted at the status bar. The status bar could see the addition of a small icon just on the right. This icon would be present when the device just got a notification in the last hour (could be user-defined setting). For lightly used device, the icon shouldn't be there too often. For heavily connected users, it could be always there because of frequent notifications. In that case, the notification icon could disappear once the users visit the notification stack (more on that later). In general, the proposed behaviour is pretty much the same as the one we experience with the location services pointing arrow.

The next visual cue enhancement proposal is the way notification gets displayed while occurring. Instead of standard alert with buttons, the proposal is to use the same kind of visual feedback a user see while adjusting the device volume. An implementation example is shown in the following movie (you can download the original one here).

This proposal is very subtle and produce much less disruption to the user. In fact, beside looking at the notification which shows briefly, the user can continue to do whatever he was doing before the notification. Some interesting details: the display duration would be proportional to the size of the content: the more text, the more time the notification get displayed. The device would vibrate briefly while the notification occurs. Finally, the user could tap the notification to bring the application responsible for this notification. 

Not all notifications would get this treatment. Critical alerts like the following would still behave in the same way as today:

• Low battery warning
• Location services usage permission request
• All other notification requiring immediate user acknowledgement

Invocation method

Now that we get less obstructive notifications, how to we get access to them as they pile up in the notification stack? Many scenarios are possible:

• swipe gesture on the status bar
• introduction of a notification space in the task switcher
• notifications app with a red badge

Swipe gesture on status bar
A swipe gesture could be a vertical gesture: from the status bar to the bottom. Then, a special view would take over the home screen (a little bit like the search view) to display the notification stack. There is a small problem with this scenario: the status bar is already responsive to a single tap in order to scroll the current view to the top of the displayed data. So this could be problematic.

The second possibility involves the addition of a notification area in the task switcher invoked by the user with a double click of the home button. This possibility is not really good because of the lack of space in this area and because this would not be a real task switching space anymore. Also possible is scrolling to the left shows the iPod controls, another scroll to the left if for the volume control. Adding another scroll to the left is not a solution. This proposal is not retained.

Another possibility could be the use of a dedicated notification application with a standard red badge number. In my view, this provide the most consistent and extensible solution. The notification application icon could also be made permanent in the task switching space (first from the left).

Notification.app

Notification management

The use of a dedicated notification application could be the closest thing to the Boxcar proposal. This may be the reason for the rumours in the last few days. So the application becomes the invocation method to see the actual notification stack. Next, it provides a way to centralize notifications and see previous one very easily. The notification history problem is then fixed.

Notifications sorted by time

Notifications sorted by applications

Looking at the previous picture, a table of application icons on the left with the application name as the main tag line. The detailed text portion could be the actual notification message. Very simple implementation as you can see. On each cell, the user can tap to see the detail view. The following is what a user could be presented after tapping the Phone.app notification. This view is divided in two parts: the notification content on the first half, the user action part at the bottom half.

Standard visual organization for notification's detailed view

Notification's detailed view example

At the bottom, the user would have an action that is contextual of the type of notification. In the previous example, the user can call back. For a SMS notification, the user could be offered the choice to reply. Hitting the action button, the user would be switching to the application responsible for the notification.

To get a more complete proposal, we have to define what kind of notifications do we expect to put there:

• calendar notifications
• missed calls
• sms message
• location-based notifications (introduced in iOS 4)
• app store updates available (why not!)
• long lasting task completion from backgrounded apps
• clock notifications
• Game Center notifications
• event-based notifications (checkins)

Final implementation details
Apple should provide the following settings in Notification section of the Settings.app:

• to let the user see immediately a notification (this is the current obstructive way)
• quiet periods: start, end, weekdays, holidays, all day, repeat
• how long to display notification visual cue
• how long to keep notifications in the stack: days, weeks, months
• sort notifications by date or by application
• notification flag in the status bar: always, for notifications in the last N hours, M days

Developers point of view

First, I don't think this proposal requires a lot modifications to the iOS's APIs if at all. Second, I think Apple can implement this proposal as all the notification content is already there in internal data structures. I don't see a lot of stuff to put inside iOS to achieve this goal. Maybe we'll see that in iOS 5 this summer. Who knows.

As you can see, iOS notifications can be improved in many ways. This blog post is about proposals of a few user experience implementation regarding iOS notifications. Now, it is your turn: write your own comment or suggest improvements too in the post's comment section. Lastly, why no share this article to your peer! That would be awesome.

PS: MacStories.net has another interesting point of view on iOS notifications. Good read.

[Update 1] Something very nice is MobileNotifyer: This is iOS notifications done right (video). Very cool.
[Update 2] Another take on this famous problem: http://talkingpengwin.com/re-design-of-the-ios-notification-system. I think my proposal is better though.
[Update 3 - After the WWDC 2011 Keynote] I just finished looking at the Apple video presenting the Notification Center. I'm happy to see that they essentially did what I wanted. In fact, instead of a dedicated application for managing notifications, they managed to put all this into a scrolled-down view. Access is also more direct as you can swipe on the lock screen a notification to directly get to the right app that handle the notification. The user of the rotating block at the top is also in line with the status bar while a call is in progress while switching to another app. This make the visual user experience more coherent. Stay tuned for a more complete analysis.

Comments

[Ray]

I believe a good way to notify a user in apps like games would be the drop down banner like the achievements or connect confirmation that Game Center has. When you start a game and it connects to Fame Center it drops that banner, gives you a short notification that you are connected and then goes away. If you could set a delay on the for texts , emails, twitter DMs, and so on it would be great. It's small, unobtrusive, and doesn't stop you from what you're doing. It wouldn't work everywhere but that notification is about the best tats in iOS right now and it could work very well in 90% of the cases that a really frustrating popup does now. I really like that notification system as far as Game Center alerts goes.