Re: [Rhythmbox-devel] The Queue, Playlists, & The Library (follow up to Interface Ideas)



On Tue, 2005-05-10 at 16:39 -0700, Rene Valois wrote:
> I really like your ideas, they make sense to me.

Well that's the intention, to make Rhythmbox 'make sense' as a UI rather
than something that potentially confuses.  I just can't imagine my Dad
using it and understanding it right now without it being a bumpy ride.

> Also, how are playlists represented in this model? Might be confusing to
> have playlists listed along with the Queue if double clicking them adds
> them to the Queue.. Or maybe not ;P

Playlists are, in this model, just pre-prepared queues.  Using playlists
becomes just adding them to the queue.  Think of playlists more as an
alternative to albums (with an album being a playlist prepared by the
artist).

> I'm a really, really big fan of double-clicking to add to Queue though..
> WAAAY more convenient than drag-and-drop to a playlist. However, I think
> it's better to have the default action to be clearing the Queue and
> playing the song immediately. Consider this scenario:
> 
> A New User double-clicks on a song, and it begins playing (because the
> Queue is empty). New User then double-clicks on another song expecting
> the same behaviour, but instead, the first song continues playing
> (because the second song was put in the Queue after the currently
> playing song).

There would need to be more visual feedback.

The queue should state how many songs are in it.  So it should register
on-screen as 'Queue [Empty]'.  After hitting a track, it'll become
'Queue [1 song]'.

The thing is, you want double-click to represent the most common need.
In a file manager, for instance, this means opening a file with it's
default application.  In Rhythmbox, I believe this would be adding the
file to the queue.  You almost always would want to enqueue rather than
play a song directly.

To get around 'first time user' issues, it'd be easy to implement a
dialog that notifies the user what's happening, with the dialog having a
'Do not show again' option.  (Think of when you use a browser on a fresh
computer, all the dialogs that warn of various things.)  In this case,
Rythmbox would check if there was a song already in the queue, and if
there was pop up a dialog along the lines of:

  .------------------------------------------------------------------.
  |                                                                  |
  |  Double-clicking on a song adds it to the queue by default so    |
  |  it will not play immediately.  To play the song immediately,    |
  |  right click and select 'Play immediately'.                      |
  |                                                                  |
  |    [x] Do not show this dialog again                             |
  |                                                                  |
  |                                         [Continue] [Cancel]      |
  '------------------------------------------------------------------'

Or something similar.

> Maybe CTRL+Click could Enqueue? Or even better, middle-click (a-la
> Firefox)?

Maybe.

The problem with this is that it needs to be learnt.  As a UI, we want
to keep learning to a minimum for the user, it should just work in a way
that satisfies the majority of users.  'Sane defaults', the Gnome ethos.

It's just a case of reaching a consensus on what is the ideal behaviour
then using a few good UI tricks (like the dialog above) to overcome any
potential initial stumbling blocks for new users.

I'm starting to think that the queue should be consuming by default.
That is, once it's played a song/album/playlist, it should remove it.
In fact, there should be 2 modes for the queue, 'repeat' or 'consume'
with it set to consume by default.  If 'repeat' is toggled then it
shouldn't consume songs (because it wouldn't be able to repeat them).

Are any of the developers going to be on irc any time soon?  I'd love to
hash this out further and start implementing it with somebody to help me
get familiar with the code.  (That and my C++ currently sucks, but I'm
willing to overcome this.)

- C



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]