Re: [Muine] A few suggestions

[Jorn Baayen <jbaayen gnome org>]

On R, 2005-02-18 at 17:20 +0100, Lars Weber wrote:
> Am Donnerstag, den 17.02.2005, 15:48 +0200 schrieb Jorn Baayen:
> > >         == Library Button Behaviour ==
> > >         
> > >         It's not only inconsistent but I guess also confusing for new
> > >         users that one of the Buttons in the library dialogs ("Play")
> > >         closes the window whereas the other ("Queue") doesn't.  It would
> > >         seem better to me to either change both buttons to close the
> > >         window (and then also change the "Close" button to "Cancel") or
> > >         to change both not to (and then maybe scrap the "Close" button
> > >         altogether).
> > 
> > This one has come up a lot, but:
> > 
> > - It doesn't make sense to click "play" (or "play next") twice.. and
> > therefore it is the kind of action you would expect to close the
> > dialog.
> 
> While it's not common for users to hit play twice I think it's quite
> common for them to want to start playing something and to then to select
> other items to play later (using "Queue").

The main reason why the behaviour is as it is, is because many people
(including myself) often just want to play something, hit 's', type a
part of the name of the song and hit return. But then again, one could
argue the same thing for queueing, so I guess I'll give in and change
the behaviour.

> 
> > - "Queue" on the other hand is a "playlist building" kind of action,
> > when queueing most people queue a few objects, not just one. Having to
> > go into the window over and over again would be a bit of a pain. This
> > argues against having the dialog close on queue.
> 
> Yes, that's true.  For this reason I'd prefer to have both buttons not
> close the window instead of having both buttons close it.
> 
> > >         Of course, browsing would necessarily make the dialogs more
> > >         difficult to understand and this brings up the complicated
> > >         question of where the ideal balance is between functionality and
> > >         ease of use.  Personally I consider basic browse functionality a
> > >         pretty important feature that I'd expect to be a help to quite a
> > >         large percentage of the targeted Muine user base.  Therefore I
> > >         think it justifies a slightly more complicated interface.  The
> > >         following is an example for an interface that I'd say fullfills
> > >         the "slightly" requirement:
> > >         
> > >         http://www.brokenbits.de/lars/cruft/MuineLibAll.png
> > 
> > This is pretty good.. but the amount of widgets and their alignment
> > dazzles me a bit. But I think we might be able to come up with something
> > refining this idea a bit ..
> > 
> > One tiny improvement - I guess - would be moving the "By artist" thing
> > to be under the list, so that things would line up a bit better.
> 
> I personally don't see a problem with the current alignment.  Given that
> the browser-selection and the button row are two separate entities I'd
> even say that aligning both of them would be misleading and therefore
> counter-productive.

The thing is that right now it is not very clear that the left list will
filter the right list. They look like two very separate things. I think
it might be a bit more clear if they begin at least at the same hight
vertically. 

> > Some brainstorming for alternatives:
> > - Using a combo box instead of the list. Or a combo box-like thing,
> > popping down a scrollable list.
> 
> I wouldn't like this because it would make the browser much more
> cumbersome to use.

True. Maybe we should work with an expander widget right under the
search entry? On expand it would show a combo showing what to list, and
a list of artists/genres/whatever. Of course we would remember the
state, whether the dialog is expanded or not.

Jorn