If you are lucky enough to be with us in tropical Las Palmas and attended Owen’s keynote today you saw a preview of some of the new ideas we’ve been toying with for the GNOME Shell. One of these concepts, that we think should be pretty fun, is what we’ve been calling the Message Tray.
Jeremy helped me put together a nice animated mockup of what it may look like. Check it out! Or you don’t have the magic for that format, you can check out the stills.
This concept builds on an idea that we discussed at the GNOME UX Hackfest last fall and is informed by a variety of prior art and the research of Eric Horvitz and others.
Basically, the HCI literature is full of studies that have found that messaging (in the broadest sense) accounts for a significant percentage of user task interruptions. But at the same time, messaging (especially instant messaging) is one of the most important applications for personal computing devices today. One of the most fun too. As we connect to an increasing number of information sources and friends, managing disruptions has become a real challenge. The primary goal of the Message Tray is to provide the user with enough information to quickly assess an event but limit the severity and duration of the preemption. Another important goal is to allow but not compel the user to respond to the event – again quickly and with limited disruption. Another side effect of information overload and frequent disruption is that it far too easy to forget what we are doing and what we want to do. So, the tray also provides an important reminding function for messages that the user has deferred addressing.
More specific goals include:
- permit the user to stay focused on the primary task
- provide awareness of new notifications
- remind for unseen messages
- direct attention to high priority messages and alerts
- use an unobtrusive display
- provide a uniform interface for messages, notifications, and alerts
- allow the user to control the information display
As you can see from the mockup, the design of the Message Tray supports four modes of operation:
- Hidden mode – tray is normally hidden off the bottom of the screen and remains hidden if the user is marked as “busy”
- Notification mode – shows a one line summary of the notification or message along with an icon
- Summary mode – a peripheral awareness (or low detail) mode showing an icon for each Message Source
- Detail mode – an interactive mode showing more detail about each Message Source
One of the major advantages this system will have over any other that I’m aware of is the ability to quickly respond to messages from friends and coworkers without breaking my primary focus or switching away from my current application. In fact, it becomes much easier to talk about your primary task. We will be able to integrate chat deeply into the core GNOME experience. At least for me, and pretty much everyone I know, that will be pretty damn cool.
You can read more about this and the rest of the GNOME Shell design concepts in a document I’ve put together to try to explain it to myself and others. I should emphasize that this is a living document that we’ll try to keep up-to-date as things evolve. Check it out and let me know what you think.
If you want to help or become involved in this evolution we’d love to talk to you anytime this week and especially at the GNOME Shell design BoF on Thursday. Please see Marina’s blog post for some details of that. Or drop by #gnome-shell on IRC or jump on the mailing list.
Are you a designer? A messaging and chat expert? A hacker extraordinaire? We need you!
Please stay tuned for more previews and design discussions in forthcoming posts.
is this just another notification system?
but graphically promising =)
have you eared of notify-osd?
I really love this! But it should be more clear, that there is clickable icons in the corner – they seem to appear out of the blue.
But the panel! Damn, it’s simple and beautiful 🙂
Page 23: “Perhaps we can even show a hint to use alt-tab when we detect that the user is going in and out of the shell to switch windows in rapid succession?”
I think it would be good to exploit the non-invasive messaging area to display tips on desktop usage to new users. This could be disabled from the preferences. There could be a small program like “gnome-advice” which monitor what the user is doing and shows tips on a not-too-often and contextual manner.
Distrubutions like Ubuntu and other may like this approach since it’s also easy to extend/modify/disable/enable.
Just my 2¢.
The Message Tray concept seems similar (or same) to what Ubuntu are doing with notifications. Same concept?
Pingback: “Message tray” e GNOME Shell PDF « pollycoke :)
THANK YOU LORD
I bow before you. This is exactly how it should always have been.
Palm’s WebOS has a similar design, and it has been really well regarded.
Am I correct in hoping that this will not use the system tray spec for notification icons, but something more rigidly defined and more under the control of gnome-shell itself? (And that notification bubbles would become / be attached to their notification icons within the same simple library, permitting consistency in that end of the interface?)
If so, I deem this project not just fantastically amazing, but Amazingly Fantastic Stuff!
Now, quickly, get to the freedesktop mailing lists and shout about this before they redesign the libnotify spec and break all hope of interoperability.
Nice design document. I agree about having an active application menu, as that finally permits us a logical place to put application-level menu items like Help and Preferences, which is something I have always been jealous of MacOS about.
Oh, answering one open question: “Should there be a special system modal type of message? http://mail.gnome.org/
In my opinion, I think there indeed should be, but this could be nicely done by touching up something from the level of the GUI toolkit. I think we need a widget in GTK+ for a non-blocking but interactive (and semi-permanent) popup window like that notification bar. This same kind of bar could be used nicely within an application’s own window (eg: gedit uses these, as does Jokosher and some others) just the same as it could work globally. It’s a great replacement to floating dialog windows pretty much anywhere. (Floating, non-modal dialogs are flawed because they intend not to block interaction, but draw on top of the window anyway so might as well be modal).
The link to Marina’s blog is broken, it should be http://blogs.gnome.org/marina/2009/07/05/gcds-and-the-gnome-shell-sneak-peak/
GNOME Shell is certainly progressing nicely. I have done a test build recently and really like the concept.
However there is one thing that really destroys a lot of usability for me: the bad, manual workspace handling.
Let me explain:
After starting GNOME(Shell) I need a basic set of applications: Browser, IRC, IM, Email. Browser and Mail get a workspace for themselves, IM and IRC can share one (this is only an example). Now, I need to write a text and start OOo Writer on a new workspace. While doing this I also start something different on yet another workspace. I finish the text doc and close Writer. Now I have an empty workspace and no way to get rid of it, other than manually move over the window(s) from the last workspace to this one and remove the last one.
It would rock if the Shell would do the cleanup work for me, e.g. remove a workspace after the last window is closed.
Looks awesome 🙂
I know this has probably been discussed to death and completely redesigned since GUADEC etc, but I wanted to say two things:
1) One thing confused me in the mockup: there’s no clear transition when a message in “notification mode” is moved to “summary mode”. So it looks like you get a message, which disappears, and then some other unrelated icons pop up for some reason.
I think it would help to animate the message shrinking into its icon, as the icon moves rightward into the “summary” part of the tray. That should help build a stronger connection between the notifications and their summary icons.
2) Other than that, I completely love this design and want it *right now*.