A New Metro / Notifications
This is the second of series of six posts on how Metro could improve the Start experience. You can read the first entry on Bing here.
There is no question that the number of notifications we receive is growing-not only growing, but growing at ever speedier rates. Nowadays we receive notifications for emails, score updates, check-ins, etc. But in a not-too-distant tomorrow, we'll receive notifications for our coffee orders at Starbucks, for lack of certain nutrients in our body, or for an empty taxi's imminent arrival. We are already overwhelmed by notifications and we are sure to be buried by notifications if we don't more intelligently manage notifications.
As I started to pay attention to Metro's design inspirations in my daily commutes, I began to notice something: in a world that is overloaded with information, real-world signages use colors, shapes and other characteristics to help us prioritize all the information around us and help us respond appropriately to unique circumstances.
Mobile computing has created a very personal world of information. Hubs in Metro act like maps to this world, giving us high-level views of what's happening in various corners of the world. Notifications in Metro, in my opinion, could become signages that help us navigate this world more easily and quickly.
What do we need to prioritize notifications? It's easy. As we go about our lives, we're constantly evaluating and prioritizing the who, what, when, where, why and how. We need to have app developers send notifications that pass along these contexts. The hard question is how can we prioritize notifications. There is no way an app could make a fair comparison between a notification it sends out to one that is sent by a different app. That is why the prioritization of notifications need to take place at the OS level.
I'm not a data scientist or a genius on artificial intelligence, but based on how much Facebook and Google have come to know about me, I don't think it's impossible for something this personal, a mobile OS in this case, to learn our priorities over time. I'm not going to discuss the science behind such a system but the following assumes an OS-level system that prioritizes notifications that have the who, what, when, where, why and how relative to the user passed along by app developers.
My reasoning behind the presentation of prioritized notifications finds its inspiration in the colors of real world signages. A ‘hot' color is used to convey the most urgent, critical piece of information. A ‘warm' color is used to convey the less important piece of information while a ‘cold' color is used to convey the least important piece of information.
As Metro is big on people-centric, I also designed the notification screen to be people centric. I call it the Notification Thread. Notifications are grouped by the who but the groups are sorted according to notification priority. The icons next to each notification indicate which app sent the notification and would be launched after a single tap on a particular notification.
This particular aspect came as an after thought to Notification Thread, but it ended up being the most significant. This makes extensive use of the Contracts concept first introduced in Windows 8 that is very well received. Notification Thread enhanced with Contracts makes "true multitasking" unnecessary-or at the very least, it greatly reduces the need for it. Users will be able to truly get-in-and-get-out when they only need to perform simple tasks.
Interaction with the Notification Thread relies on the long-press gesture that brings up a contextual menu for each notification. Developers of each app is to include up to three or four* hooks for communication between the Notification Thread and their app. One of the three or four hooks is default, an ‘Ignore' option for the user to delete the notification with (users can swipe away each notification to the side to perform the same function). Each notification is dismissed once acted on or ignored. The developers are advised to include an option to respond, an option to share, as well as an optional link option. The behavior for the respond and share options are programmed into the app while the link option provides an URL scheme mechanism.
Note: an email could contain a <meta> tag to plug into the link option. In the case of this email below from Washington Huskies, tapping on Buy Tickets takes the user to either the Ticketmaster.com ticketing page or the Ticketmaster app.
Having a structure between the OS and the most important functions of apps provides a foundation for third-party access to alternative input methods like voice. Imagine Siri saying, "Message from Washington Huskies, Huskies 9, Trojan 3, 3:21 in first quarter. Reply or Share?" Imagine Siri saying, "Paul Miller called you on Skype. Call or Message?"
What are your thoughts on these? I'd love to hear from you. Your input on my last entry already had a positive influence on this one. I'll certainly appreciate it if you could share your thoughts on this one as well. Thank you. Again, please excuse my horrible, foreign writing.