Home

Advertisement

Customize

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.

Comments

(Anonymous)

no min/max?

why would you get rid of min/max buttons?

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)
IMO we really all need to sit down and discuss what the notification area means, because it's not a notification area any more. There's been some semantic drift, and that is not a bad thing, but having some documentation about where it's drifted *to* would be helpful.

(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)
I think the Alt-tab/tasklist model works fairly well for non-transient applications, so yeah, I think we do want two "minimization models".

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).

Actually, I use a gnome panel applet called "music applet": http://www.kuliniewicz.org/music-applet/ . It presents a limited UI front end to a number of backends. Between that and my keyboard multimedia keys, I have a perfectly fine UI that only occasionally needs the full rhythmbox window.

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.
I like what avant-window-navigator does. I'd like to see the notification area AND the taskbar abandoned for something similar, if I had my druthers, which I don't.

(Anonymous)

Simpler solution (but in a technical sense)

Yay! Anything that kills the taskbar ;)

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)

Good point. I think we can do this by taking the general principle that things in the notification area are also persistent. What this means is that once you launch them from the Applications menu, they are automatically run on session startup thereafter.

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)

See topic.
Please make these changes optional if you implement them. This idea involves many assumptions about how people use rhythmbox. I also am not sure I like increasing the number of types of programs that users will be required to understand; certainly this is contrary to prior user interface expectations. I also am dismayed by the windows-style multiplication of locations where programs are listed or launched from.
Well, I don't like adding options. On the second point - several applications already use the notification area, this is basically just a refinement on that. So I don't think we're adding to any problem.

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

I understand where you're coming from, but working with things that tend to sit in the background is where I think applications like Gnome Do (and katapult I guess) come in real handy. Why even launch that whole ui, when you could use a standard interface like Gnome Do as a front end to find the next album you want, and play it, all without these large windows, custom uis, large windows, etc.

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 for one think that computers are for people to accomplish real life tasks, let it be entertainment or productivity use. I do not think it is a human's task to tend computers. The bug you linked at the very beginning, ahhh...

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)

* Clicking anywhere outside of the window causes it to minimize back to the tray icon.
How would you drag files on the playlist in that case?


~~ Olivier.
Yeah, this would break drag and drop.

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)

And what if I don't want Rhythmbox to "manage my music"/"organize my music" for me, but just use it as a simple player due to not all music being tagged perfectly? Sounds to me like:

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

Have to agree with anonymous here. Click-outside-to-minimize is a terrible idea for any non-trivial application. There are many use cases when you need to constantly switch between the transient app and another application window, and have both be visible.

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

Drag and drop - you can still DND to the applet area, but I admit this is somewhat of a pain. In any case I think DND is pretty broken fundamentally

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

> you can still DND to the applet area

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

The main advantage is that you only have to move your mouse once and click on the applet area, instead of twice.

Until notification area/ panel applets/ launchers have merged...

...could you follow the HIG, pretty please? Thanks!

http://library.gnome.org/devel/hig-book/stable/desktop-notification-area.html.en

Re: Until notification area/ panel applets/ launchers have merged...

Well, yes. For now. But I get the impression that this is intended as a thinkpiece to say, should we rewrite the HIG to reflect that usage has shifted.
I'm really stuck between whether or not this is a good or terrible idea. Having 'X' mean minimise rather than quit application seems pretty awful to me - it's close to what PackageKit does right now, and it must have taken me ~1.5months of use before I realised "Close" didn't mean "Quit" on the dialogs it pops up.

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'.
I find it a bit amusing that you've chosen to demonstrate how Rhythmbox might work on a system with no sound (or music).

Tray icons

I have an even better idea. Force all GtkStatusIcons to have blinking=1 all the time. This should teach wannabe GUI designers that notification area is for notifications and is not yet another task list. How's that for an improvement?

(Anonymous)

Re: Tray icons

Force all gtkstatusicons to blink constantly? SERIOUSLY, this is a very clever idea. Let's do it. Should enforce the HIG a tiny bit. But I doubt gtk maintainers would have the guts to pull a stunt like that :|
I really like your idea - and it could also be neatly applied to Transmission.

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.
Agreed.

Workspaces

Place for transient apps? That what distant desktop are for! I often open music player on sixth desktop where it sits playing music and not interfering with anything.
Or someone could merge desrt's new applet code http://blogs.gnome.org/desrt/2006/08/21/your-domain-lowercaseca-is-expiring/ and go from there.

good discussion

it's a good discussion, but I too think that sometimes I like to maximize rhythmbox and work a bit longer with it, managing playlists or ratings.

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

IMHO, the system tray should remain a system tray, not a junkyard for random applications. Yes, I know that some applications are already using it (both GNOME and KDE apps; thankfully most of them allow you to disable this "feature"), but that doesn't mean it is a good idea. Have you ever seen a Window$ desktop with the systray polluted with a dozen or more icons? It's so bad that M$ has made it retractable (which is a huge PITA when you want to use an icon which is currently hidden). Do you really think this is an example to follow? Application windows are what the task bar is for.

(Anonymous)

Not discoverable

This idea sounds nice on first pass, but no other Gnome programs use this concept so it will be very frustrating for the user. The user will be randomly clicking ON the application, getting more and more upset when it doesn't go anywhere.

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!

I really like the idea!

Advertisement

Customize