Josh On Design

In the first two (1, 2 ) installments of this essay I covered overall system design, the window manager, and applications. I talked about how the user will communicate with the system, but I haven’t discussed much about how the system communicates back to the user. This brings us to the next big problem of today’s operating systems: notifications and concentration.

Jef Raskin famously said: "User data is sacred". We can say the same about the user’s time and attention.

The computer must never waste the user’s time. The computer must never break the user’s attention. While these rules are impossible to keep absolutely, they are excellent guidelines. If the computer must interrupt your current task, it better have a damn good reason to do so. And that brings us to notifications.

Notifications: The Big Bugaboo

Notifications have become the bane of my existence. I get notifications for everything: new emails, VIP emails, tweets, likes, +1s, stack overflows. Everything sends me a notification. Every app I install on my phone wants to notify me of their newest stuff.

None of these notifications is really spam. Each source is providing me with genuine information. The problem is timing. Notifications are too frequent. They appear at times when I need to concentrate. They are too aggressive in their interruptions.

They are also not sorted. While I eventually want to receive all notifications at certain times; I want only the "important" ones now. To solve this we really need to solve two problems: creating a way to notify me of information in less disruptive ways, and how to define important.

Let’s look at other solutions.

iOS 7/8

Apple’s solution in iOS7/8 is an improvement from iOS6, but not great. You get this giant list of apps. For each app, on a separate screen, can you configure whether you want notifications at all, and where they should be displayed. On the lock screen? With sounds? All of this may be configured for each application. This is too much work so most people just accept the defaults. A system no one uses is less that worthless. I usually love Apple’s design, but iOS notifications are abysmal. I don’t know how it got past design review.

One possible solution is to position the apps relative to colored lines. Everything below the red line may not notify you in any way beyond it’s app icon. Everything above the line can notify you with a dropdown notification that quickly fades away. Above the red line is a green line. Anything above the green can notify you even when do not disturb is turned on. These are only for the very important things. To adjust an app you simply drag it up and down. The list becomes a hierarchy of which apps do more urgent things. The position indicates it’s setting. This is far easier to manage than a per app settings screen.

The problem with this plan is that an "app" is too granular. My email client receives both urgent and non-urgent messages yet it is treated as one "app". We need a more fine grained approach.

One idea is for the app generating a notification to set the priority level, but this complicates the app config screen. Would you have one entry for 'email: low priority' and a second one for 'email: high priority? This will quickly become confusing. There has to be a better way.

Content based Prioritization

Manually managing notifications in a preferences app simply won’t scale. I can manage these individually but it’s death by a thousand cuts. We need to solve this problem as a whole, just like we did with memory management and security. We need content based analysis to determine the priority.

Content based notifications are a complex and under-researched area, but it should be possible. Ten years ago we were drowning in spam but Bayesian filters. One key will be keeping calculations as local as possible. The farther away your data gets the easier it is to steal.

Real Customization

Now on to a new topic. What if our computers could really be customized. I mean really customized, not just changing the theme or setting keybindings (though having system wide editable keybindings would be wonderful. If there from the beginning all apps would use it. But on to real customization.)

Customization isn’t just tweaking defaults. It’s about reconfiguring the computer to your needs for the particular task you are doing. With something like a RaspberryPI, the cost is so low I might have several of these running clones of each other. I should be able to do the following with just a few lines of code, or ideally a single visual diagram without anything we could today call ‘coding’.

All of the above cases are really just snapping a few components together, yet today this would be extremely challenging for most people to build. Even for a professional engineer like myself I’d spend a lot of time dealing with interoperability issues like data formats and app permissions. It shouldn’t be this hard. Computers were supposed to be a general purpose tool. Why aren’t they accessible to everyone?

Everyone should code

This flows into my belief that everyone should learn to code. I’m not saying we all need to be programmers, or that we all need to even learn to use a programming language, but everyone should be comfortable with computational thinking. Everyone should understand what an algorithm is and how to make a device do something for you through instruction with loops and conditionals.

It does sound a bit crazy to say that everyone should learn to think computationally, but it was crazy to say everyone should learn how to read or do arithmetic just a few hundred years ago. This really is a topic for it’s own full essay. (one day…) For today let’s just say that you should be able to reconfigure your computer with simple tools.

A few notes on implementation

This essay series isn’t really about implementations. The user experience is what matters, not how it’s built; but tools and formats do matter, especially if you want a long term computing platform. So, a few things must be said.

Theming

Look and feel theming. When people say the look and feel they usually mean the look, even though the feel is far more important. The feel must be carefully designed, and then carefully customized for the user in very specific and limited ways. Applications should have no control over this. The user (and their agent, the OS, not apps) are the final arbiters.

On the look side we really do mean theming. I guess it’s okay, but i’d prefer not to support theming, at least not with a public API. In theory it’s great, but in practice I have never seen a 3rd party theme as good as the default from the OS vendor. Perhaps it’s a market failure. Perhaps good designers have better things to do with their time than build free themes. Perhaps it’s hard to judge the quality of a theme from a screenshot. Perhaps end users interested in theming have no taste. I don’t know. But it’s definitely a low priority.

Device Drivers:

In short, I hate them. They break all the time, and in the computers most vunerable spots. The kernel. Ideally access to the hardware would be completely virtualized. OS provided hooks connect the real hardware to the ‘device drivers’, where are isolated user-level modules that understand the details of that particular hardware. If a driver crashes it crashes, and the service it was providing to the user will stop, but the whole OS won’t come down.

We’ve invented amazing hardware virtualization technology for the server room. Let’s bring that back to our desktops. With modern GPUs even the screen should be virtualizable without a significant speed hit.

Message bus format

In general the ideal OS would be based on a simple messaging system. And I do mean simple. Simple. Simple! Text or a text equivalent like JSON. It must have multiple implementations. It must be language agnostic. Just messages, not remote objects. We aren’t rebuilding CORBA here. Something more like REST. It doesn’t have to be high perf. This is for system components to communicate at slightly faster than human speeds. When they need to do bulk data transfers they can use other existing systems like files and shared memory.

In Memoriam

Throughout this essay series I’ve highlighted the way our desktop operating systems, which are destined to be used by at least 10% of us, are horrible. While amazing technically, they fail us at every step. We still don’t have useful features that were designed in the 1970s, and we still have technical underpinnings that were designed in the 1970s. Seriously. We can do better.

I really hope in 300 years, when we are all computing on the Starship Enterprise, we won’t still struggle to combine applications and deal with segfaults. Let’s fix it in this century.