Thomas Otter

Warning I’m definitely not an expert in open source operating systems. (George is)

Readers of this blog will have noted that I have an interest in design thinking. A good portion of my Christmas wish list is made up of books on design, and I will continue to inflict more of my design inspired ramblings on you via this blog once I return in the new year.

It strikes me that what Mark Shuttleworth and his team are doing with the notification feature is a good example of design thinking in action. His post and the discussions that follow in the comments are rich and often very thoughtful.

This sort of information provides fantastic input for the developer.  It suggests to me that more solution/product managers should be using blogs and other social software tools to collect input into the solution design. Some vendors use blogs, but too often it is merely to announce things that are already built, or to solicit high level requests. It should be a conversation not a broadcast.

Mark is keenly aware of the trade off between constraint-driven simplicity and functionality.

The most controversial part of the proposal is the idea that notifications should not have actions associated with them. In other words, no buttons, sliders, links, or even a dismissal [x]. When a notification pops up, you won’t be able to click on it, you won’t be able to make it go away, you won’t be able to follow it to another window, or to a web page. Are you loving this freedom? Hmmm? Madness, on the face of it, but there is method in this madness.

Our hypothesis is that the existence of ANY action creates a weighty obligation to act, or to THINK ABOUT ACTING. That make notifications turn from play into work. That makes them heavy responsibilities. That makes them an interruption, not a notification. And interruptions are a bag of hurt when you have things to do.

So, we have a three-prong line of attack.

1. We want to make notifications truly ephemeral. They are there, and then they are gone, and that’s life. If you are at your desktop when a notification comes by, you will sense it, and if you want you can LOOK at it, and it will be beautiful and clear and easy to parse. If you want to ignore it, you can safely do that and it will always go away without you having to dismiss it. If you miss it, that’s OK. Notifications are only for things which you can safely ignore or miss out on. If you went out for coffee and a notification flew by, you are no worse off. They don’t pile up like email, there is no journal of the ones you missed, you can’t scroll back and see them again, and therefor you are under no obligation to do so – they can’t become work while you are already busy with something else. They are gone like a mystery girl on the bus you didn’t get on, and they enrich your life in exactly the same way!
2. We think there should be persistent panel indicators for things which you really need to know about, even if you missed the notification because you urgently wanted that coffee. So we are making a list of those things, and plan to implement them.
3. Everything else should be dealt with by having a window call for attention, while staying in the background, unless it’s critical in which case that window could come to the foreground.

Since this is clearly the work of several releases, we may have glitches and inconsistencies along the way at interim checkpoints. I hope not, but it’s not unlikely, especially in the first iteration. Also, these ideas may turn out to be poor, and we should be ready to adjust our course based on feedback once we have an implementation in the wild

Deciding what functionality to leave off is hard, yet so often it is given little attention.

I’m also impressed with Mark’s sense of responsibility for the user experience.

The Ubuntu desktop is something I take very personally; I feel personally responsible for the productivity and happiness of every Ubuntu user, so when we bring new ideas and code to the desktop I believe we should do everything we can to make sure of success first time round. We should not inflict bad ideas on our users just because we’re curious or arrogant or stubborn or proud. Despite being occasionally curious, arrogant, stubborn and proud

This is good advice for other software companies too.

5 Comments »

Category: UI software industry usability     Tags: Canonical, Design, Ubuntu

Share