Google's Inbox implements a really smart management paradigm - specifically, users can swipe in one direction to "snooze" a message (designating a time at which the message will reappear in the inbox), or swipe the other way to mark the message "done," essentially archiving it. Steve Albright, in a post to Google+, recently opined that this paradigm might find a good home among all of Android's notifications, rather than being confined to Inbox messages.

At the suggestion of another Google+ user I follow (Derek Traini), I decided to give the idea some thought, and work up at least a preliminary interface sketch for how something like this would work.

Of course, snoozing notifications and having them appear later when you may be more attentive sounds like a great idea on the surface, but it comes with a lot of User Experience baggage. In this post, we'll take a look at the initial concept I came up with, and a couple of the primary UX questions I encountered when thinking about the concept. If it sounds like I'm arguing with myself in this post, it's because I am. This is an idea that at its core would provide utility, but which treads in murky UX waters that are worth an open, even-handed discussion.

Is it a Good Thing to Add Complexity to the Notification Shade?

This is the first and perhaps most important question when considering a change like this. The answer is unclear but the path to find the answer is obvious: just look at Google's UX "jars" principle. As Fast Co wrote last year, Google has a trick for determining whether something is in good UX taste. Simply imagine two jars. One jar represents some positive value of UX imparted by a given change, and the other represents a negative value. The key idea to remember is that one marble in the negative jar can only be overcome by three marbles in the positive jar. If you inconvenience, confuse, worry, mystify, or otherwise hassle the user, you've got at least one negative marble to deal with.

So the question in this case should really be this: is the utility provided by this change to the notification shade so great that it will overcome the confusion it would undoubtedly cause? The answer here is "maybe." There would be some initial confusion - after all, Android's notifications have historically been flexible to swiping. Users can currently swipe in either direction to get rid of a notification. But under this model, only one direction would dismiss, while the other would require further action.

This is an easy lesson to learn, and I've built into the concept an escape hatch for users who do the wrong action - if you snooze the notification by mistake, just hit the undo icon and it will pop back into frame.

There's also the fact that this process takes more time. Ultimately, the fractions of seconds add up, but for many (not all) they'd probably be worth the utility of having a notification come back. If a user wants a clean notification tray but doesn't want to lose their notification reminders to check on things later, this is a good solution. If, like me, the user treats notifications very casually and doesn't really care whether they're dismissed prematurely, the feature still works because the option is there, but may not add a lot to the experience. For this reason I'm tempted to punt the question of whether this feature should exist and "throw it into the settings," with an option to disable notification triage.

Who Decides When a Notification Should Come Back?

This issue is related to the above issue. Notifications right now have a very high level of same-ness. That is, they all look the same, they can be managed the same, and they can all expand or stay contracted based on actions the developer chooses to build in. There's no more room on expanding notifications for timed "snooze" options, so the solution to the problem of adding a "snooze" to notifications begs to maintain a level of same-ness with all notifications system-wide. So the answer to who decides the snooze options becomes apparent - it should be the system.

The hitch in this is, of course, that what makes sense for one user doesn't make sense for all. To attempt to address this in some sort of preliminary fashion, the concept above offers just three options: later today, tomorrow, or "sometime." This is sort of similar to how Inbox does things. In this case "later today" would be at the end of the day, or in the early evening (hence "see you again in a few hours"), while "tomorrow" would snooze until the next morning, and "sometime" would open some sort of dialog or picker (like Inbox does) for more fine-grained controls. The "sometime" option is my least favorite, as it introduces at least one or two more layers of interaction to an already somewhat complex interface, but it is in place for those users who want complexity in exchange for usefulness.

Final Thoughts

So in the end, is a system-wide snooze/done notification triage system a "good" experience? Maybe. The possibilities I've presented above are just scratching the surface. As stated before, this is a useful idea for a feature but it does carry its own drawbacks, perhaps even past the ones we've just discussed.

It doesn't seem evident that Google plans on implementing anything like this right now (it's likely this is an idea that's been discussed before), but I think this has been a worthwhile exploration into what lessons Android at large could take from the Gmail team's Inbox interface, and that this is an area still ripe for exploration.