Re: [Rhythmbox-devel] rhythmbox interface

[Jorn Baayen <jorn nl linux org>]

Hi,

On Fri, 2002-11-22 at 19:26, Donovan Lange wrote:
> I've been a silently cheering member of the Rhythmbox audience for a while; and
> rather than study for my Japanese quiz I figured I'd chip in to the discussion
> with my $0.02 instead.
> 
> Personally, I'm not utterly convinced that the current UI deficiencies
> identified by Jorn are insurmountable.  Certainly, it's easier to keep the
> interface simple if the Audio CD, Internet Radio, CD Burning, etc. features are
> removed; but I sincerely hope that as a user that this is not the direction
> the Rhythmbox pursues.
> 
> I took a stab at addressing some of the interface challenges mentioned earlier
> in this thread.  Forgive me for any naivity on my part:
> 
> http://ir.chem.cmu.edu/lange/rhythmbox-mockup.png

I like it; b

> 
> I also believe that it's an inconsistency for the "Currently Playing" view to be
> situated within the target area of the sidebar, as it representation is
> independent of the currently selected music source (ie, it's static).  However,
> rather than deprecating the sidebar, an easier solution may be to just move the
> sidebar _below_ the "Currently Playing" region.  This also provides more room
> for the future addition of features such as album covers, visualizers, etc.,
> which will also need to be situated in the region representing the current song.

This is already the done in CVS, and in all the shots I put up :)

Indeed this was a cause of confusion.

> 
> I moved the search bar to the toolbar, with the justification being that it
> presumably operates on all available music sources and is therefore a global
> operation.  Hence, it probably shouldn't be located within the "Currently
> Playing" region.  

It doesnt apply for all views; only for the library one. So it shouldnt
be in the toolbar prolly, and near the songs view as well, so that it is
clear what it searches.

> 
> (An aside: there's an argument to be made that the search field doesn't really
> belong on the toolbar either, as the other toolbar operations all operate on the
> active playlist: next song, shuffle, etc.  One workaround to this problem may be
> to keep all global operations that evolve on a separate toolbar that may in
> actuality be positioned within the same space but is separated by a toolbar
> handle so that it can be moved.)
> 
> I believe that the easiest way to solve the reordering problem is to simply
> allow drag and drop operations within a group view.  This would mean that
> clicking on a header (such as Track, or Artist) is a sort action, rather than
> setting a persistent sort order.

Yeah, this should definetely be done. It's hard to do though, which is
why it's still not done.

> 
> My internal model of the sidebar is as a representation of the music "sources".
> There's an icon for the CD drive, and an icon to switch to the Internet Radio
> interface.  As a result, for CD-R burning, I think it would be entirely
> consistent to only represent it provide it as a menu option that brings up a
> non-modal dialog stepping the user through the rest of the process.

Yeah, this is how the sidebar is handled in rb atm.

> 
> Other points of interest:
> 
> In the sidebar, it would be great if one could great shortcut groups, a la
> Evolution.  IE, it should be possible to keep playlists/groups on a separate
> pane from the music sources if a user so desires.

Hm, this may be a bit confusing. But spasce shouldnt be a prob once the
sidebar is gone and a plain list is there instead.

> 
> What's currently unclear to me is the optimal method for representing the
> current queue to the user... perhaps a special group view on the sidebar?

That's an option.. although it might be worth to put the queue, since
it's not really a source, in a more prominent position.

> 
> Anyways, I hope that these suggestions may be of use to people.  Feel free to
> comment or ask questions.
> 
> Cheers,

Thanks,
Jorn

> 
> --
> donovan.lange