Re: [Rhythmbox-devel] rhythmbox interface

[Donovan Lange <lange chem cmu edu>]

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

> > 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?

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.  

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.  

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.

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

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

--
donovan.lange

PGP signature