Jon McCann ran the Shell design session as a BOF discussion. He began with a straight forward introduction to where the Shell stands today comparing it to the usability hackfest exactly one year ago where GNOME Shell was born. An amazing amount of progress has been made but some major things still remain. (More on that later.) Fortunately, Red Hat decided to fund work on the Shell full-time so a lot of progress is being made, quickly.

Jon focused on the Shell UI as it stands today: the top bar is redesigned. The right-hand side is session-oriented actions: things that apply to the entire session. For example, your presence, log-in-and-out, and messaging. The notification tray is staying but a new messaging API is coming (more on that later.) In the center is the clock and date widget: it's needed and always changing. They wanted to balance the weight of the things in the bar to provide an even amount of content across the bar. Moving from right-to-left, the current application with focus is shown. In the future, a new API will be added to allow application level actions: Quit, Preferences, New Window, etc. Finally, the "Activities" menu is in the upper left (and is a hotspot) which activates the overview mode.

The overview mode grants a workspace layout view similar to Exposé. An important point is that workspaces are not forced on the users but they are immediately accessible should they choose to use them: the default workspace count is one. Jon gave the example of usability studies where users hit the "Show Desktop" button or the Workspace Switcher button, all their windows vanish, and then they panic. That can't happen in this design: when they return to the overview, everything is there.

The left-hand pane in the overview displays a search box, your list of favorite and all applications, recent documents and bookmarked places (from Nautilus/GIO).

Colin Walters jumped in to add that a central theme is that the new UI is application-based. The application title in the top bar is part of this but it runs deeper: the UI can request a new window from any application by calling the binary again. Applications that don't use some variant of libunique may launch a second instance. A short-term solution to that would to have applications that support a libunique-style application management approach to indicate that is so in their .desktop file. This difference also extends in to the new Alt-Tab interface which reflects applications in the top level view and, optionally, if more windows are present, an extended view of the individual windows grouped underneath the application icon. Mouse navigation is also possible in the Alt-Tab UI, now. Mouse wheel gives users who prefer a window-based approach, can now flip through windows rather than applications. A lot of insider tips are up at; enabling expert-keyboard navigation is a major objective.

The floor was opened to discussion on design ideas. An issue was raised about showing the user the application window on the workspace they're on when clicking its icon in the shell—this will be fixed. Another issue was raised about allowing users that love to have tons of application launchers. The application well (the area where favorite and running apps. icons live) will accommodate a number of favorites and is still a little in flux but this use-case will be handled.

A large discussion centered around the Session menu (where your name is). There hasn't been a lot of attention paid to this menu yet but a central theme is that this menu should contain everything related to your session (like logging in and out; suspending), those things that are user-specific (like Preferences) and your presence (here, away, do not disturb, etc.). A tangential issue is making it clear that this is even a menu, in the first place. Owen threw out one proposed solution: a help bubble on first login that says "Click here to set your name."

Search is something of an open question at this point. Right now the list of items searched is menus, recent docs. and places. There's a desire to integrate with Tracker but it's still an open-ended issue. Storing other meta-data there would be a win: click frequency, for instance.

(a short break was taken)

A major objective that is just beginning is messaging: everyone is tired of getting their focus stolen by chat, SELinux, etc. Canonical deserves credit for trying to solve this in GNOME 2. Borrowing from that, the new design is inspired by this earlier work.

In the lower right hand-corner, a message queue will be displayed with things waiting for your attention: chat applications, mail notification, system warnings and music players. A critical difference will be that acknowledging receipt of a message is not the only way to get rid of it: a "message" can be suppressed temporarily without discarding it. To obtain the list of pending messages needing your attention, you can move your mouse to the lower right corner to have the message queue slide in. Newly arrive notifications will display for a short moment by sliding up from the bottom to display their message in a single line of text, remain for three seconds, and then slide out.

Chat apps. will be able to provide a simple notification of the message with a simple reply window for the rapid-style interruption allowing a user to immediately return to their primary focus. More involved chat will continue to be done in the IM client itself, for now.

Robert McQueen, who works on Telepathy, jumped in to say that most of the plumbing from the IM side is ready and is mostly in GNOME 2.28. Jon said that he'd like the ability to access the chat history in telepathy to get context.

A discussion about how to go about making this happen ensued. For example, should applications draw the tray item or respond to an API call when clicked? It's not clear at this point but there will be a libnotify compatibility layer for support of legacy applications. Unfortunately there really can't be a way to prevent people from abusing this message queue: applications that do would need to be encouraged to behave better.

Jon stated that he doesn't see that this message area would ever act as the primary interaction UI for an application: it's just a place for a quick reply or dismissal: not intended to be a primary UI.

There was a discussion about how the Empathy "Buddy List" fits in to this world if there is no notification icon, only messages in the message try. A "People Panel" is one proposed idea: integration of all applications with a concept of Contacts that allows you to initiate any communication via any method supported by that contact: chat, phone, email, etc. This is a very rough idea at this point, though. The inspiration for this approach comes from Moblin.

We ran out of time but there are two more GNOME Shell sessions scheduled.

Sponsored by GNOME Foundation