Notifications as the app itself

I gave a fast quick talk (ten minutes to write, ten minutes to give) at InboxAwesome yesterday in DUMBO.

The conference was all about different ways we are designing and looking at our inboxes.

A lot of the conversation took to how our inboxes and message queues mostly have started resembling to-do lists, whether we want them to or not. And even if that phrasing wasn’t used, the interfaces certainly make them seem that way.

I was tasked with speaking about notifications: that now, in a mobile world, notifications are the inbox.

We used to get app alerts and newsletters and weather alerts in our email inbox. Now, those things live on in lighter form in our mobile notification trays.

Towards the end, I got asked a question that asked me to compare visibility of email alerts versus notifications. I had to think about it for a while, but I think it’s obviously why (at least for now) notifications are stronger. The strengths here over email:

• only applications can author notifs, unlike in email where some are authored by a single person, others by apps, still others by groups or people you don’t know and with whom you have a more informal relationship;
• you don’t get “spam” notifications in the same way – that is, you don’t get notifications from apps you don’t even have as you would with email where anyone who knows your address can send you something. additionally, if an app misbehaves, you can block notifs or delete it altogether. try that in email sometime: “unsubscribe” is more of a soft contract;
• it’s easier to triage and easier to control settings and make sure only certain notifications show up (and in what position and in what style). The best email has so far is Gmail’s “Important/Social/Promotions”. Filters solve some of this, but they don’t allow you to do things like play-alert versus show-subject versus show-in-full, &c.

All that led me to getting around to this idea that very soon, if we’re not already there, Notifications are becoming the app itself.

A couple of great pieces have been written on this in the last couple of weeks – first on the idea of “invisible apps” wherein you needn’t even open an app to get value out of it. The other, the idea exploring notifications as an interface by @mat. I don’t mean to repeat their points. But while talking about all this yesterday, I realized something more.

When you combine the idea of iOS 8 improving on notifications with actions like ‘reply’, and notifications turning more into apps, and perhaps when you put that together with a new easier-to-get-going programming language in Swift, a really amazing thing happens.

For very little work (even less than was needed before), one, especially one who’s not even a full-on developer, can create incredible apps and experiences using fewer pieces of infrastructure and code.

For instance, I can put together a Swift app that serves as a shell to get the user to allow me Facebook or Twitter permission and notification permission and background location permission. Then, after the first time to ask for permission, the user never has to launch the app. I can program everything else on my backend stack, made easier with things like Heroku and something like Parse’s ability to easily set up push notifications.

Essentially then the only reason you’re putting together an app is this: to get placement in the app store and to get the user’s FB/Twitter, location and notifications permission. It allows you to leave all logic on the server – thereby allowing you to easily deliver the same message on iOS, Android, email, web, &c.

Beyond that, for some types of products, the app disappears. The notification becomes the app itself.