Transient Applications
Thomas blogged about my nemesis, bug 482354. I've been trying to upstream the fix for unbreaking clicking on links for quite a while now.
In it, Christophe brought up Rhythmbox, which is quite similar to Pidgin in how it acts with the tray icon.
Several years ago I was chatting with Seth about Rhythmbox and he mentioned that he thought it was a fairly special kind of application because it is generally used in a very "transient/background" way. For example, a normal way to use it would be minimized to the tray (not even in tasklist at the bottom); then when you want to switch songs or albums, you click the tray, do a quick search, and then minimize again. This contrasts with "regular" applications like Eclipse, Firefox, Evolution where it's expected that you will often spend a substantial amount of time in them in one go.
The tray icon approach sort of works, but I think we could do better. Following is a potential approach that I'm recording in my blog so I don't forget, and of course to gather comments.
Transient Application
First, for reference here is how Rhythmbox currently looks:

Unmodified Rhythmbox
And here's a mockup of how it could work:

How Rhythmbox could be a "transient" application
The general idea is to treat the application window like a really fancy GtkMenu. Here's a concrete list of user-visible behavioral changes:
- Clicking anywhere outside of the window causes it to minimize back to the tray icon.
- It does not appear in the task list
- There are no minimize/maximize buttons
- The close button does not actually exit the app (i.e. stop your music), but just minimizes
- There is a visible arrow showing you the association with the tray
Overall I think this approach will make the "show Rhythmbox window, choose song/album, start playing, make it go away" task nicer since you'll only have to move your mouse to the tray icon and click once (to open) instead of twice (once to open, once to close). It will make it a lot clearer to the user what's going on (in the current Rhythmbox we have the minimize/maximize animation, but no arrow).
Implementing this would require window manager changes, new GTK+ API for GtkStatusIcon, and updating several applications that fall in this category (Rhythmbox, Pidgin, Banshee, etc.) to use it. Also someone with actual graphics skills would have to draw the arrow. Does that sound like a lot of work just to save you one mouse click? Not when you're applying the forehead mashing method of user experience improvement!
Now to find some time to implement it...
Edit: - I forgot to mention this would also be perfect for the new NetworkManager connection dialog.

(Anonymous)
no min/max?
maximization isn't something you'd want to get rid of, imo, and having it alone would be silly. just make minimize and close do the same thing - iconify the window to the taskbar (bonus points for window managers animating the window to the taskbar location's icon)
(update: not just for Rhythmbox, btw. For everything. Should we keep two minimisation models, or one, and which?)
(also: I want to say thanks for when I'm listening to a radio station and working in another window, and a new song comes on, and a balloon pops up to say what it is. This is awesome.)
Edited at 2008-07-23 07:14 pm (UTC)
Now the "notification area" has really turned into "programmatic applet container". Bryan had a good design a while back for a way for programs to add applets but it was never implemented (and I can't find the link atm).
But yes, the notification area has grown into a makeshift dock for applications; something largely inherited from Windows applications.
One thing I'd love to see is an extension of the Notification area docking to general applets. In the land of Xrandr, it's quite annoying to have layouts change because I rotate 90 degrees to read a paper and back. Generally I use one gnome-panel with 3 areas, a "stack" on the left, a "stack" on the right, and a window list to consume the rest of the area. If there was a smarter panel applet / layout engine for this, I'd be happy.
(Anonymous)
Simpler solution (but in a technical sense)
A simpler solution would be that the taskbar and 'launchers' would merge. Then rhythmbox would be accessible in one place. The single icon of rythmbox.
And not a different place where we have to tell user where that is.
But i guess that's copying apple too much ;)
But really, currently rhythmbox exists two places in the top bar. Since i have a shortcut. After it shows up in three distinct locations. (icon,taskbar,notification)).
You solution fixes the taskbar but makes the notification bar function as a 'special' taskbar. Go all the way and kill both ;)
Re: Simpler solution (but in a technical sense)
This is how many IM clients on Windows behave, and I think it makes sense.
So if we did that you wouldn't need the panel launcher icon.
(Anonymous)
Re: Simpler solution (but NOT in a technical sense)
Ultimately where we want to be is that music (like IM) is part of the desktop; not really a separate "program". One way to implement this is to add a music applet to the default panel configuration.
This applet would launch/control whichever music playback program was installed.
(Anonymous)
working with background apps, a different route
For instance Tomboy, I never really used it as it was too much work to find notes that were's in the list in the recent notes list. However, with Gnome Do I can easily get to any note equally fast.
Apps with a nice dbus interface allow other apps like Gnome Do to provide a consistent window to things running in the background.
(Anonymous)
I am correct
I absolutely get pumped into rage every time Firefox decides that some silly javascript popup from one inactive tab simply can not wait and it pops that tab up. The Firefox has been in 100% of the cases wrong. I could simply not care less. I have some 300 tabs often open and without the noscript extension the experience would be frankly hellish. I could not simply do things to accomplish my real life tasks instead of tending to the constant stream of stuff I really am not interested in.
The only moment when a computer should make such context change (virtual desktop change, pop an application up, blink something annoyingly) is when I ask it to. There are no excuses for fucking that one single rule up.
About transience: Well, that lead into many applications building quite heavy and complex right click context menus on the tray bar. A whole windows popping up has its own problems so they went that way. Then came for instance NetworkManager folks that seemingly recently noticed that those menus are quite limited and after all bad usability. Something like what you suggested actually could help, providing that the application would also gtfo my face effortlessly enough after the 1-5 second conversation that *I* initiated with it.
(Anonymous)
How would you drag files on the playlist in that case?
~~ Olivier.
Overall I've never been a big fan of DND though; the core failing being that it's very non-discoverable.
In the particular case of Rhythmbox, the general idea is we already know about all of your music, right? Where we don't, we should treat that as a bug and fix it. For example, if you download some random mp3 from the web browser we should ensure that the desktop detects the content type and adds it to Rhythmbox automatically.
(Anonymous)
a) You want to require that users use Rhythmbox (i.e. auto-add music to rhythmbox when it gets downloaded).
But...
b) At the same time disallow users to decide for themselves how they want to organize and handle their music (for example break DnD because you are "not a fan").
Having a bunch of applications all behave differently is a good way to break HIG. That doesn't make things easier or the desktop a smoother experience - quite the opposite.
I'm puzzled as to why you'd want to do this. Unless you honestly expect that all users, all the time, listen and handle their music files just like you do.
click-outside-to-minimize is a terrible idea
For rhythmbox:
* drag-n-drop
* web browser ("I want to look up some reviews for that album -- oops, the rhythmbox window disappeared")
* acquiring music ("Should I download/rip this song? Do I already have it in my collection? What about this one? What about that one?")
For network manager:
* lookup and copy/paste login info, SSIDs and so forth from various sources (emails from the admin, login webpages, corporate vpn documentation etc.)
etc. Basically, anything more complicated than an ok/cancel dialog should not disappear on click-outside.
Re: click-outside-to-minimize is a terrible idea
Reviews - Should be an option directly from the album ideally, if the system knows e.g. that you use Last.fm
Acquiring - You can just click again
-Copy/paste -You can just click again
Basically it's optimizing for what I do believe are the more common cases.
Re: click-outside-to-minimize is a terrible idea
That assumes there is only one target for dropping. For instance, what if I want to drag and drop a file into a specific playlist?
> Basically it's optimizing for what I do believe are the more common cases.
I would disagree. It adds major annoyances for some use cases, and does not improve user interaction for any use cases.
Minuses:
* breaks any use case where you want the transient app window to be visible while you are interacting with another window.
Pluses:
* none?
The only reason I can think of for minimizing on click-outside is if transient apps are always-on-top, like notification bubbles. But there is no good reason for a full-fledged app to behave exactly like a notification bubble. Once you let a transient app be on any level in the window stack, click-outside-to-minimize no longer makes any sense.
Re: click-outside-to-minimize is a terrible idea
Until notification area/ panel applets/ launchers have merged...
http://library.gnome.org/devel/hig-book/s
Re: Until notification area/ panel applets/ launchers have merged...
It seems to me like these little icons in the status area are much like entries in the task bar, except you get one for a running app rather than window, and they're kinda "global".
If we're worried about taking up space on the taskbar, can't they just be minimised to icons? If they need to be available on all views, can't they be set off to the left in their own little area?
It does feel like this is getting more and more complex for not much obvious gain. I don't like the idea of windows which behave in a special way because the app is somehow 'background'.
Tray icons
(Anonymous)
Re: Tray icons
Still, the problem remains that GNOME badly needs a review of the HIG particularly regarding big picture desktop interaction at the WM/panel/dock level. I'm not talking about academic human-machine interaction studies which would break all current assumptions. I'm speaking of an incremental clean-up-the-house kind of review which could be built on the current GNOME 2.x or soonish to be 3.x desktop.
The problem here is (as almost always) a lack of leadership and being able to bring everyone into the same page. Especially, making the design and usability people work together to come up with a sensible default desktop.
Workspaces
good discussion
You all have been watching Federico, right? Could this combine with tabs stuck to the desktop border? Back in Mac OS 9 there was this nice concept of tabbed windows.. you could drag a window to the screen border and it would make a tab that popped up if you dragged to it or clicked on it.. just for file browser windows, but this is sort of that for applications instead. And the concept was spatial in that you could drag a normal window to the border to make a tabbed window, then you could pull it loose later. However, it is not discoverable, but has to be introduced somehow.
Systray abuse
(Anonymous)
Not discoverable
In fact, most developers on the mailing list seem to oppose random stuff (IMs/multimedia apps) in the notification area at all. They want to keep it just for notifications.
Finally, I think there's the Gnome HIG to worry about.
woo hooo!