Re: [Rhythmbox-devel] rhythmbox interface

[Jorn Baayen <jorn nl linux org>]

On Fri, 2002-11-22 at 21:51, Donovan Lange wrote:
> On Fri, Nov 22, 2002 at 08:28:32PM +0100, Jorn Baayen wrote:
> > ...snip...
> > This is already the done in CVS, and in all the shots I put up :)
> 
> Doh, I'm such a boob. :) 

:P

> 
> > > 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.
> 
> Hmm... but isn't it reasonable for people to want to search _regardless_ of what
> source/group/library/foo they are currently viewing?  I mean, isn't this the
> perfect example of a user interface feature that should always be consistently
> present?

I think searching only makes sense for the library; since the search
filters unwanted stuff out. This would be rather useless for playlists
which are fixed, ordered sets of songs.

> 
> What would you think of:
> o Search... just accessible exclusively from the menu?  Or,
> o The search field is always displayed on the toolbar... when a user
>   hits enter, it first switches to the Library view before beginning the search.
>   If you believe that it's non-intuitive that the search only searches the
>   library, it might be possible to reword the text (ie, Search the library) so
>   that the wording could be changed slightly to make it more obvious what is
>   being searched.  Lastly, 
> o If it's conceivable that users would want to search just a group (ie,
>   search the results of a previous search) then perhaps a drop down box next to
>   the input field (ie, Search for ____ | in the Library v |, where the available
>   options are Library, current view, etc. might be appropriate.  

Actually I think it would be fine as is :)
I never found myself in any need of searching my results, and I doubt
anyone needs that - music management isn't that complex really ;)
Further I think the search field should definetely be easily accessible
from the lib, since it's used a lot. (And it should prolly be near the
treeview, instead of on the toolbar - to clarify what it does).

Like I said before, I think search for groups would be rather useless...

> 
> Maybe I'm off my rocker, but I think any of these would reduce some of the user
> interface inconsistency problems that you alluded to in your first email.  And
> would additionally be a win for usability.
> 
> I'm also curious to see what happens when searches get more complicated... ie,
> if users want to search based on more properties than just their title.  

Right now search searches for title, artist and album, iirc.

Support for 'smart playlists' is planned, so that you can give a set of
criteria, and a playlist filtering all songs with them will be created.
(And kept in sync)

> 
> In addition to breaking the model of "this part of the screen has things that
> apply to the current song", there's something to be said about having widgets
> right-aligned -- it makes it impossible for a user to memorize where a widget
> is located, as it's dependent on the window size and can change.

Good point. I'm not sure how often a music player window is resized
though. Personally I think it's more important that the search entry is
near the treeview, rather than left aligned -- but I could be on crack.

> 
> Mind you, design is oftentimes subjective.  Feel free to tell me that I'm on
> crack... I don't mind.  ;p

You're on crack *G* :) Just kidding, please keep the suggestions going
:)

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

Cheers
Jorn

> 
> --
> donovan.lange