What is the problem?
Notifications are treated equally by default, but not all notifications are created equal. The OS assumes that each app takes responsibility in determining when we should divert our attention to it, but that’s right in a conflict of interest with the OS’s goal to ensure a wholesome and zen-like user experience. A flashlight app developer thinks you need to drop your conversation with a friend and look at a new promotional in-app purchase that allows you to adjust flashlight brightness. The same notification alert and style also reminds you that an important crash has happened on your host server.
They are simply not the same. Not every app on your phone is worthy of your attention. And even for those apps that are important, not every event within the app deserves it.
The current paradigm of information organization centers around the medium via which they are transferred. Everything goes in and out of apps. Want to share a web page with your best friend? Pick a messaging app first in the sharing dialog. You really care about this one friend and her snaps, but don’t really want to see all other Snapchat notifications? Too bad.
The flaw in this organization framework is that new information is not organized by where they come from or how useful they are, but rather who delivered them. If my mom sends me a message asking me when I will come home for Thanksgiving, I don’t care if it comes through iMessage, Messenger, WeChat, Line, or Email, I want to hear an alert sound and respond to it. But if Verizon sends me a new promotional blurb, whether via text, email, or call, I don’t want to be distracted by it.
Unfortunately, that’s not how our operating systems work today.
Rethink the organization of new information stream
What if we can build an information architecture from scratch. What would be a better way that’s more suited to our natural way of interacting with the world? I experimented with some thoughts and sketched out a crazy idea — demote apps, promote people and services.
Let’s introduce two new conceptual sources around which we organize all of our incoming streams of information: Person and Service.
- A Person represents someone you interact with in the real world or online.
- A Service is a single-purpose utilitarian source that takes some input from you and gives you something else more valuable in return, similar to chat bots.
So now you have two sources, how do we organize the new information coming out of them? Let’s create three tiers of importance: FYI, Query, and Alert. Most notifications fall into one of these three categories:
- FYI: time-insensitive, optional, not important to the user
- Query: time-sensitive, requires some response action
- Alert: mission critical, do something now or else something will go wrong
How will apps and mobile OSes implement this information architecture? Let’s look at an example story.
First, all apps have to register their sources with the OS. Messenger, for example, will register a user’s list of friends as People in the OS, and all the chat bots as Services. News just needs to register each journalism publication as individual Services. Comico might choose to register each comic series as a Service. Uber can just register itself as one Service.
Next, each notification must be assigned a tier from one of these three: FYI, Query, or Alert. But where do these assignments come from? For most Services, they should be FYI or Query. The submission and approval process for each app should require permission requests from developers to apply for one or more of these tiers, just like how they have to apply for location services permission. This will prevent, for instance, shopping apps from abusing Alert tier privileges. Once these default assignments are approved on App Store or Play Store, users can also choose to fine-tweak them in the settings if they choose to.
But the most interesting part is when People interact with other People. Do we ask users each time when they are sending a message to a friend, whether it’s a FYI or Query or Alert? That’d be ridiculous.
Tier Inference by Context
The interesting case of People-People interaction can be solved by using tier inference. For instance, if I’m sharing an article from News app to a friend with no custom message attached, i.e. just a link, this should be categorized as FYI. I’m just sharing something, I’m not asking for their response. But if this message contains a custom message, I am then sending a Query type message. Ideally, these two bits of information from me should show up under different sections on my friend’s phone with two different styles of notifications — one stays quiet and non-intrusive and one grabs their attention.
When Jasper shares with me an interesting cat video, I won’t hear an alert sound, my phone won’t buzz, but when I go into Notification Center, I should see his video. But if he sends me a TED talk video with some thoughts and insights along with it, I hear a sound, my phone vibrates, and I know I should pay attention to this one.
Currently, when an app asks for permission to send notifications, it’s actually quite vague. I don’t know
- Exactly what kind of notifications it will send
- How frequent it will send them
- Which tier(s) the notifications will be in
The best solution to this problem right now is called “permission priming,” where an app explains why it needs to send notifications before asking for the permission to. The problem with this solution is that not every app does it. In fact, most don’t.
I propose a new permission granting flow where apps demonstrate their notification frequency and tier along with an example to ask for approval. I understand that a lot of developers rely on notifications to increase user engagement and maybe even profit from promos, but not every user is fond of every promo equally. I may want promo notifications from Muji, but don’t care at all about a Black Friday clothing sale from Amazon.
We should give developers a chance to demonstrate its notifications’ usefulness and let the users decide whether or not to receive them.
Only a Thought Experiment
From end-to-end, we start with how we share and end with how we receive them. Information is organized around who makes them, whether that’s people or services. Developers get to demonstrate the type of information they offer and the OS protects users’ time and attention by allowing the users to choose the ones they want.
Although, I’m not sure if introducing this layer of “people” and “services” complexity on top of your already busy home screen is a good trade-off. Now we have not only apps, but another abstraction layer on top of apps. That feels wrong to me and is definitely not the most elegant solution.
But this is just some of my thought experiments. What do you think?
This article was originally published on Fwd: Thoughts, a publication Jasper and I run on Medium. Follow us there if you'd like to read our thoughts on tech, design, and business.