Queue support and The Playlist

[Nikolaj Hald Nielsen]

Yeah, I think I finally grasp what you mean when you distinguish
between a playlist and a queue. It only took me like a year and a
half, but hey, better late than never... :-P

That said, I am not convinced that a major s/The Playlist/The Queue/
is what we really want to do. At least not in the short term. Is this
really a better usage pattern then the very familiar (to so many
people) concept of a playlist? Don't get me wrong, it might be the
case that a queue instead of a playlist, or having both, or ... would
make Amarok a 100 times more awesome, but since you are the big
proponent of this change, the burden of proof falls on you, especially
since the concept is different from a playlist in subtle enough ways
that it is (or at least for me was) really hard getting my head
around.

My feeling right now is that it will get really hard for you to drum
up support for a major change of the way the playlist works (again, I
think I finally understand what is is you want to do, and I am still
unsure if I like the idea at all) without having something to show
first. So I am not sure this is apathy as such, more a reaction
against having to come to grips with yet another very abstract concept
while there are so many concrete things in Amarok 2 that still needs
doing.

So my advice? Do what I always do, prototype the damn thing! Then you
can talk about something concrete instead of something very abstract
like the finer details of the differences between a playlist and a
play queue.

- Nikolaj



On Fri, Dec 19, 2008 at 8:55 PM, Bart Cerneels <bart.cerneels at kde.org> wrote:
> On Tue, Dec 16, 2008 at 3:44 PM, Bart Cerneels <bart.cerneels at kde.org> wrote:
>> Hi all,
>>
>> I promised to start a discussion about the queue manager.
>>
>> Fact: users want the queue manager back:
>> https://bugs.kde.org/show_bug.cgi?id=171939
>>
>> In my mind The Playlist is a queue, and the order of tracks in there
>> is the order they will be played. I couldn't imagine anyone trying to
>> use it any other way. In fact, when I learned about the queue manager
>> I literally didn't understand it's use-case.
>> Now I've realized that the people who use the queue manager for a
>> couple of different reasons:
>>
>> 1) Playlist editor:
>> Because Amarok doesn't have a separate playlist editor, people started
>> using the PlaylistView like the Juk editor. Not wanting to destroy
>> their precious works of (playlist-)art, mainly sort order, they use
>> the queue-manager to play those tracks in an order other then the
>> list-order.
>> note: they could have just saved the playlist to disk and then
>> rearranged, but the human mind probably perceives that as destroying
>> previous work. We can't blame our users for being human, even tough
>> they want us to be super-human.
>>
>> 2) Single click queue adjustment:
>> Not everyone enjoys drag and drop. Especially if you want to arrange a
>> large number of tracks fast clicking is easier. The queue-manager
>> allows you to do that with Ctrl+"Right Click".
>>
>>   There might be other use cases. Reply if you can think of some.
>>
>> These are both useful features, both of which are missing in Amarok 2.
>> A straight port of the queue manager from 1.4 would indeed solve 2)
>> and allow users to do 1) sort of like before. But we still have the
>> opportunity to rethink the concept now and implement it in a simpler
>> way.
>> So I propose we solve both separately, a Meta::Playlist editor and
>> added functionality to PlaylistView for queueing.
>>
>> One click queueing we could easily implement with a mode that sends a
>> track to right below the playing track when left-clicked (think
>> touchscreen). Or use the middle button for this regardless of mode.
>>
>> I propose to make a playlist editing plasmoid to cover 2) and make
>> mass tagging like in 1.4 possible. This should obviously be a
>> spreadsheet view, which some users can't seem to do without. This
>> would *not* be a queue editor. But since playlists can be saved,
>> edited and then loaded in the queue the functionality is the same, if
>> not better. It also allows any group of tracks from a Meta::Playlist
>> to be added to the queue.
>> We could still implement queue sorting in the way leinir proposed [1]
>> but at least it will be used for queue ordering and not the only, or
>> the prefered, UI for playlist editing.
>>
>> Now I understand Seb has queue-manager for 2.0 in a git tree. So
>> perhaps it's similar to what I propose or a port from 1.4, need to see
>> the code. Anyway I've started on the middle-click queue adjustment
>> already, the playlist plasmoid is something I want for 2.1.
>>
>> [1] http://amarok.kde.org/blog/archives/810-The-Old-style-Playlist-Is-Dead,-Long-Live-The-Old-style-Playlist.html
>>
>
> I've had a chat with Nikolaj today which has given both of us some
> more insight into what I'm really talking about here.
>
> In his reply to commentors to his latest blog post [1] (2008-12-18
> 10:57) nhn writes:
>
>    The playlist in Amarok 2 is meant as a much more transient thing.
> Of course you can save and restore playlist, move stuff around and all
> that, but its not meant to be "permanent" in the sense that the
> collections are. This is in contrast to the usage pattern of the
> versions of Winamp I was using many years ago, Xmms and many other
> apps. Which is why, I am guessing, that many users take this usage
> pattern with them to Amarok.
>
> This is exactly what I mean when I say we should separate the
> "permanent" playlist editing from the transient queueing. I take a
> radical stance in this and say we should have different UI's for both,
> with Queue being the main one that is always visible. And we should
> also adhere very strictly to the queue concept, where the only
> navigation to the next track is row++, with the exception of "repeat
> track" and "repeat album".
>
> The main idea behind the Queue is that it is a direct visualization of
> what will be played next and what has already played. With normal,
> sequential, playback this behaves exactly the same as The Playlist
> does now.
> In other modes:
>  Random: when starting playback, on user request or at the end of a
> track, the upcoming tracks are shuffled. This should be animated of
> course. After shuffling the next track in the list is played.
>
>  Repeat Track: stays in the same row but increments a visual counter.
>  Repeat Album: at the end goes back to the first track and increments
> the play counter.
>
> Then only thing you'll have to let go is the "destruction" of the
> order and grouping in the queue. But I believe as long as the playlist
> is represented separate from the queue this is no problem. And as once
> we get more grouping possibilities like "by genre", "by artist", ...
> that might not be such an issue at all.
>
> I've created a page for this idea on the wiki:
> http://amarok.kde.org/wiki/Proposals/Queue
>
> [1] http://amarok.kde.org/blog/archives/854-Amarok-2-playlist-searching.html
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>