Desktop Revolution: Stage 1: Notifications Bar

I have a lot of ideas about how the Linux desktop can be improved, perhaps revolutionized, and these ideas all come from running up against walls repeatedly. I’m going to write the best ones down, the ones I will eventually turn into an open-source project (years down the road, mind you) if no one else does.

The Linux tech world has come up with numerous solutions for notifications, and I use as many as possible to satisfy my needs. Chrome has TweetDeck, Linux has libnotify, or notify-osd if you’re using Ubuntu, and all operating systems have an icon “tray.” They all serve similar purposes: they want to give you information about what’s going on right now, and that’s incredibly useful.

However, I dislike the icon tray. It’s messy, hard to notice, and hard to click on.

I dislike the pop-up notifications. They get in the way of something every time and disappear if I don’t give them the attention they crave right at that particular moment.

TweetDeck doesn’t have any of these problems, but it runs as its own app that wants lots of screen space, and is so super-specific that it really can only be used for so many things.

My idea is to take the best of all these worlds and put them together into this new application I’ll call “notifications bar”.

It will sit as a docked panel, on the right side or left side of the screen. Every time there is an event that might be worth the user’s attention, it enters the notifications bar at the top. These notifications should be styled according to source (O/S or human?) and importance (reply soon or just an f.y.i.?). There could be an auto-hiding feature too, but I personally dislike that idea, as it usually means I’ll be accidentally triggering it, or I won’t notice it when I should.

These notifications could be triggered by literally anything. Did the system detect an unusual error that might be worth my attention, such as a failed cron job or authentication attempt?  How about upcoming calendar events? What about when a new song starts playing? Perhaps it could track my last.fm friends and let me know what they’re up to. Or perhaps an application will have a notification, say if it’s out-of-date. Let’s not forget all our social networks, either.

Notifications should indicate a life-span. Some notifications (“you’re computer is full!”) need resolution right away and should exist until acknowledged. Others (“John commented: lol”) aren’t worth keeping in view. Still others (“Meeting with VIP”) need to exist for a period of time, say, 15 minutes before plus 5 minutes after the start of the event. Notifications that indicate a life-span will be called “living”, and the ones that don’t are called “temporal”. Living notifications will have a timer icon on the right side. Let’s just use a pie-chart circle indicator as an example for our imaginations. The circle starts filled, but it slowly empties in circular fashion until its life-span is exhausted.

These living notifications are the ones that stick around. As more notifications fill the bar, the ones that have a life-span “stick” at the bottom and refuse to be pushed off until “killed” or “exhausted”. The temporal ones simply fall behind either the living notifications or the bottom of the screen, whichever comes first.

Of course, a history can be kept. This can also be used for when there are more living notifications than there is screen-space. This could use some more thought.

Clicking a notification is notification-dependent, and running this whole notifications bar via plugins means each notification will provide some quick and meaningful functionality when clicked. A hover icon should appear on the left-most edge of the notification that indicates whether an entirely new application will pop open or just a dialog, similar to TweetDeck for Chrome’s little reply box, will appear. Plugins should be as easy to write as /usr/bin/notify-send is to use, perhaps even providing some UI templates for quick-‘n-simple scripts written by power users, while also allowing for full-fledged custom UI’s written by developers.

This is my dream. Either I’m going to write it or someone else will, and I don’t care which, as long as it happens.

What do you think?

Advertisements
Post a comment or leave a trackback: Trackback URL.

Comments

  • Tom Jollans  On August 26, 2011 at 12:46 pm

    Have you used KDE4 and Gnome3-shell?

    KDE4’s notification system does “pop up”, over your windows, but the notifications are attached to the panel, and when they are hidden after a short amount of time, they don’t necessarily disappear: some notifications stay available in the plasmoid, until you close them. The number of notifications is listed in the panel.

    Gnome 3’s shell has a notification system that is, in a way, similar. Notifications appear at the bottom of the screen, and remain accessible there, until they’re no longer relevant or closed by the user. Empathy’s chat notifications are fully-fledged chat windows, and Rhythmbox’s “current song” notifications allow pausing and skipping tracks.

    Both seam pretty close to what you propose.

    • Jacob Godserv  On August 26, 2011 at 12:51 pm

      All the notifications you mention, however, exist as a sort of dialog box that covers your workspace, and simply vanish if they’re not touched. KDE4 does save the notifications, but in the icon tray. That’s not very helpful.

      GNOME3 notifications are simply the pop-ups I described that get in the way.

      The reason these all fall very close to what I want is because my idea is close to these systems. The difference is the system I propose is both out of the way and visible.

  • Bart Broek  On August 27, 2011 at 7:43 pm

    Excellent idea, however there should be a mechanism that classifies different messages say from a disk monitor deamon to the seriousness of the notification. I think of a drawer-like inbox with tab’s that should easy made possible with KDE plasmoids

  • Tom Jollans  On August 28, 2011 at 3:20 am

    It doesn’t sound like you’re actually familiar with the way Gnome 3’s shell does things, Jacob. Not Ubuntu with its Notify-OSD, not Gnome 3 fallback mode – Gnome-shell. Like in KDE, when a notification first appears, it pops up, above other windows, at the bottom of the screen. However, only the title is shown for larger notifications – it barely gets in the way. After some time, it disappears, and is kept in the message tray, which is not normally visible, but can be accessed by moving the pointer to the bottom left, or in overlay mode.

    Of course, this is not what you propose, but if you hacked gnome-shell to permanently display the message tray, it might be pretty close.

    Honestly, I’m not even sure what you’re proposing: are you proposing a panel that is wide enough to hold the notification text? That would certainly get in the way even more than the classic notification-daemon notifications. Are you proposing a set of app icons representing notifications (similar to gnome-shell’s message tray)? Do you envision them as being larger than icon tray icons, thus easier to notice? A news ticker perhaps?

    • Jacob Godserv  On August 28, 2011 at 4:53 pm

      I see I poorly defined “getting in the way”. I was describing a piece of UI that overlaps another.

      I am proposing a panel wide enough to hold text. It would not “get in the way” because it would declare itself as a docked panel, so any decent Linux window manager should be able to keep maximized windows from covering it.

      It is, I suppose, a sort of vertical news ticker, except it only scrolls when it must.

      Indeed, there are many implementations that come somewhat close, mostly because they all display a notification. 😉 But I’ve always been a firm believer in the small details, and this is one area of the Linux desktop that disgusts me because it simply follows what everyone else does. I came up with ideas for a way to fix that, and, according to differences between what I propose and what’s out there, nothing comes close to what I propose.

  • Fitzcarraldo  On August 28, 2011 at 5:39 am

    I do agree with you that the mechanisms for notifying the user are not ideal, but I wouldn’t want a new ‘notifications bar’/’docked panel’ occupying more ‘real estate’ on my Desktop. Also, how would each message be displayed or held in the new ‘notifications bar’ you propose? Either it would have to be wide in order to display some meaningful part of the message, or it would be narrow and display nothing meaningful and one would need to hover the mouse pointer over it — or click on it — in order to display the full message. You might find the practical problems more apparent if you were to produce some sketches or a mock-up.

    • Jacob Godserv  On August 28, 2011 at 4:57 pm

      This is a subjective choice of how you want your desktop set up. I don’t expect everyone to agree that notifications are worth desktop space. In fact, there’s people out there that probably prefer as little as possible on their screen. That’s what software like http://www.hogbaysoftware.com/products/writeroom is for.

      It would save me time and frustration to group all notifications for everything I use into one permanent place.

      A mock-up would be a good idea. As I said in my post, I would write the software eventually if no one else takes it up first.

  • qpid  On August 28, 2011 at 6:14 am

    Something like this?

    https://bbs.archlinux.org/viewtopic.php?id=124647

    • Jacob Godserv  On August 28, 2011 at 4:54 pm

      No. What I propose is something (for starters) that keeps notifications visible as long as possible, and in a way that does not cover existing UI.

  • Bart Broek  On August 28, 2011 at 4:08 pm

    But this is where the problem “Pops Up” different desktops use different ways for notifications. A more universal input method that can handle applications, dbus and user scripts to output to a “notification” deamon is needed. For instance, Colibri accepts html markup tags send by libnotify but the KDE standard deamon does not. A common language that can solve the problem how things an when they are displayed and if necessary buttons to be presented for subsequent action would be welcomed.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: