Much has been written around modern operating systems’ notifications and the negative effects they have on users today. The WSJ published a piece on this just this week.

In modern OSes, notifications are defined and triggered by apps. Often, by third-party apps. This code is not under the user’s control, but under the third-party vendor’s control. And yet notifications are the thing that take up most of the screen real estate on the default / lock screen, and they are the only way that our personal computing devices initiate new interactions with us (rather than, as is the case most of the time, us initiating new interactions with them).

OS vendors have made steps towards making notifications more manageable and less distracting. But fundamentally, the way notifications work in modern OSes is backwards: someone else decides when (and how often) my device wakes up to interrupt what I’m doing.

And yet, notifications stand to be one of the most important things in our personal computing domain. Consider a notification center that contains only what your want to know: it might contain deliveries arriving today, replies to important emails, any weather or air quality alerts for your area, new physical mail received today, changes to upcoming events or travel itineraries, maybe even a new album released by a favorite artist, and so forth. The notification center can become a singular space that keeps us up-to-date with what’s going on in our lives. If done right, the notification center might become the most trusted and impressive space within a person’s personal computing domain.

This concept reminds me in some ways of Google Now, a short-lived but insightful product that would show all of the above, in addition to, if you scrolled far enough, scores from your favorite sports teams and other items you’ve shown an interest in knowing about.

Notifications stand to be an incredible, concise way for our personal computers to show us everything we care about right now. But today, this sacred space fails to achieve that ideal because it is home to others’ priorities over our own, often filled with prompts from social networks to look at new posts, deals emailed to us from online stores we’ve made a purchase from once before, and so forth. Notifications are fundamentally backwards when they are issued by someone else, and our control over them only exists in filtering or delaying them. This is especially egregious when they exist on our device’s home or lock screen!

It wasn’t clear to me at first, but over time I’ve realized that the itemized OS has the opportunity to get notifications fundamentally right.

As discussed in LN 018, rather than apps, our OS of the future has services that provide items to our operating system. Podcast episodes, emails, calendar events and more — they all come into our system via services.

But notifications don’t.

Instead, our services simply supply our system with items. And we, the users, tell our system what kinds of new items we want to be notified about. There is no way for a service to tell the system to notify us about something; instead, they only supply the system with their available items.

As users, we set sensible notification preferences, such as:

• I want to be notified about calendar events coming up soon
• I want to be notified about replies to emails I’ve sent
• I want to be notified about deliveries that have arrived
• I want to be notified about local weather alerts
• …and so forth

These notifications are posted to our system according to rules we have set up, not unlike the rules described in LN 018 to trigger automations. In this way, notifications are simply automations themselves: if an item meets conditions X, Y, and Z, then notify me about it.

Usually this pertains to new items, but sometimes it’s with items that already existed, such as a reminder attached to an email we sent off a week ago that we’d like to follow up on.

We can set up simple or complex rules, and we can define if we want the notification to interrupt. All notifications may go into a notifications list, which we can check when we have the time to do so. But only interrupting notifications would also pop up on our screens automatically. This way, we can set up notifications for items like upcoming deliveries to land in our notifications list, but not interrupt. Then when the time is right, we can check our notifications list and catch up with a running log of everything going on that we care about (without those things interrupting us all day).

Common notification rules would likely be presented to the user or enabled by default, so that users get the functionality they expect with little or no effort, and the ability to fully adjust their notifications whenever they wish.

So, most often, notifications look like this: A service brings a new item into our system (as discussed in LN 018). Let’s say it’s an email from a spouse. Our system checks our rules for new items, which include things like automations as well as notifications. Following a rule we set up requesting immediate notification about any kind of new message item from our spouse, it posts the notification.

And we covered this before in LN 005, but just for fun: notifications can bring up helpful connections with other items whenever a notification about an item posts. This has some really cool potential uses, such as giving us the original email thread about a meeting when the notification for the upcoming event appears:

For more, see LN 005: Associated items.