Dynamic Playlists/Watch Queue

[deepspaceaxolotl]

I can say I really appreciate the direction Freetube is going in terms of customisability, it's quite heartening. On that topic, I would like to pitch in to keep the Watch Later button in the corner of videos/as an option under the player alongside that tab, as well as, rather than in place of, the upcoming on-the-fly playlists. I never used the Watch Later feature on YouTube, but have found it very useful in Freetube, especially with navigating in only one tab, and for keeping up with many subscriptions.

A separate Favourites tab would also be nice so I don't have to mix my 'bookmarked' videos and those I want to watch later, but just the functionality that's present in the old app would be enough for me to upgrade right away. (And exporting this list/these lists would be great! Another reason I sadly can't test out the new rewrite, losing my watch later videos.)

And of course, switches in the settings for showing or hiding those tabs (in conjunction with other distraction-free mode options) would be a great idea.

[GilgusMaximus]

Thanks for the appreciation. First I'd like to say that I would appreciate it a lot if the issue templates are used in the future. Makes everything tidier.

1. The dynamic playlist was a proposal from play all videos in the current profile #413 and [Feature Request] Video setable skips, on the fly playlists, and watched video variants  #519. Its concrete implementation is yet to be discussed and probably 2 releases away with the playlists coming up just in the next release. Your idea only has differences at a few points. So your proposal will definitely be included in the discussion.

2. With custom playlists in the next release you can make as many playlists as you want, including a favorites playlist. An additional tab wouldn't differ much from a normal playlist, However the idea of adding a favorite button so the video gets added to a favorites playlist could be a good compromise.

3. That depends on the concrete implementation of the UI. That is usually something Preston does.

[deepspaceaxolotl]

Oh, apologies! Am still a bit confused with the etiquette here, this wasn't really a bug report so I just went with a paragraph style... I'll keep it in mind for next time if it comes up.

Thank you for the response, and for linking those issues about custom playlists! Yeah, I'm liking the direction of flexibility you are heading in. I guess tabs aren't that big of a thing really, just would miss the button in the corner of video thumbnails as it's super easy to access, which is good for a click-and-forget feature like Watch Later. ^^;

[kommunarr]

@PikachuEXE has implemented this functionality with #4234. Is there any specific feature requested in the original issue description that is not yet implemented?

[deepspaceaxolotl]

Works great, I love the flexibility and customisability! I think the only thing I find myself missing (unless I've just not been able to find the setting) is a grid view like the old watch later/favourites tab, it made it a lot easier to see what I've marked for later at a glance and decide on what to watch. Otherwise, excellent work!

Edit: I see this has been requested already #4708!

[deepspaceaxolotl]

I think since there are other issues addressing the few nitpicks I have left with the new system, I'm going to close this. Thanks to everyone for implementing it!

[efb4f5ff-1298-471a-8973-3d47447115dc]

I'm going to keep this open because the watch queue and dynamic playlists aren't implemented yet and are huge features. If its unclear what these features are let me know and I'll upload some examples

[deepspaceaxolotl]

I'd appreciate that, I'm not very familiar with them!

[kommunarr]

@efb4f5ff-1298-471a-8973-3d47447115dc Same here if you don't mind. I'm not familiar with the nuances of these terms

[efb4f5ff-1298-471a-8973-3d47447115dc]

Here you see me queuing videos. There is a normal Enqueue option and a Enqueue Now option. Enqueue will add the video to the end of the queue. Enqueue Now will put the video after the current playing video in the queue. The on the dynamic playlists part is shown later in the video. Dynamic playlists lets me create a playlist of the videos I just put in a queue so i can watch them later for example.

signal-2024-05-02-201035_004.mp4

Here you see me going to a creators channel page and watching one of their playlists. While watching their playlists I decide to add a video to the queue. I decided i have watched enough and create a playlist so i can watch it later. Notice that the video i added to the queue is also added to the list.

signal-2024-05-02-201035_003.mp4

This is my own created playlist i start watching. While im watching the video in my playlist I see another video and add it to the queue. Notice that the playlist it self is unaffected by this. I noticed a video in the queue that dont want to watch and remove it. Notice that the playlist itself doesnt change.

signal-2024-05-02-201035_002.mp4

[kommunarr]

Thanks for explaining. I can get the appeal for this feature, particularly with wanting videos added ad hoc to be "up next" rather than somewhere else when using Autoplay Playlists and/or being far from the top/bottom of the playlist positionally. I would make clear that we should map out our UX ideas for it rather than rely on any existing implementation entirely. Thoughts:

• Enqueue is almost a bit too technical as jargon, and yet Enqueue Now is not really technical or meaningful language by itself. Insert at Front of Queue and Insert at End of Queue are two labels that I would consider clearer and less esoteric.
• Our playlist display UX & logic is currently at odds with this suggested implementation, at least if taken directly. Watching a playlist in FreeTube, you currently have numbered entries and the actual playlist itself that you're manipulating. In the app you're using, from what it looks like, playlists when opened become an unnumbered queue, where you manipulate the queue rather than the original playlist (I think? You would have to show me how reordering a queue, removing a video from the "playlist" queue, and solely adding/removing a video from the currently watched "playlist" all affect the underlying playlist and queue). We would most likely have to sacrifice our playlist video numbering to avoid confusion on that, and spend time coding in all of the aforementioned interactions, but on the other hand, it would make the separate proposed feature of dynamic playlist video reordering with dragging (where you shouldn't be able to override the logical sort order in an permanent manner) very easy.

[efb4f5ff-1298-471a-8973-3d47447115dc]

(I think? You would have to show me how reordering a queue, removing a video from the "playlist" queue, and solely adding/removing a video from the currently watched "playlist" all affect the underlying playlist and queue).

Sorry my brain broke a bit when reading this. Could you explain to me what you want me to show you?

[shadoxxhd]

For a quick temporary implementation, I'd suggest the following:

• add a button next to the "Favorite" button on videos, that adds videos to a "queue" playlist instead (just needs an icon, so the "enqueue" vs "insert in queue" question isn't that important) (a favorite playlist is useful in addition to a play queue, so repurposing the favorite queue would be sub-optimal)
• add a setting (per-playlist?) that determines whether new videos are added to the beginning or the end of a playlist (this is the main reason that prevents me from co-opting the "favorites" playlist for that purpose)

This is already sufficient for a very bare bones play queue implementation, but still has some issues:

• Multiple windows couldn't use different queues
• drag and drop reordering videos in a playlist isn't possible yet
• automatically selecting the queue playlist as "active playlist" would cause problems with multiple windows, and it's not easy to say what the behavior should be when clicking on another video while in the queue (add it to the back of the queue and select / add to front and select / add to "front" of queue (ie. after currently playing video))

However, many aspects are less problematic than you seem to think:

• numbered entries don't really matter - at worst, it might be slightly inconvenient to tell how "far away" a certain video is from being played (you'd have to subtract the current index from the target index in your head; automatically doing that in the background would show a typical "0 for current video, 1 for next, -1 for previous, etc." labeling)(or you could just hide the index, if you prefer)
• all normal playlist actions would 1:1 work on the "queue" playlist backing the play queue; when playing from a non-queue playlist, queue specific functionality would be simply unavailable, like it is in web youtube (ie.
• drag & drop playlist reordering is a nice feature anyway, and would be useful for normal playlists just like it would for the queue

gradually improving that intermediate implementation to a fully featured "local queue" that works well with multiple tabs seems to be more or less straight forward as well:

• "play next" vs "add to queue" could use the same button depending on a modifier (eg. shift), with a setting to determine which is the default
• instead of queue functionality being based on one unique, special playlist, each window (tab if implemented) could have its own internal "queue" playlist (could optionally by stored somewhere on closing the window, if users desire persistence of these queues)
• these playlists could simply have special names that hide them from the normal playlist UI ("__queue__20240717_001")
• additional buttons that act on these special playlists would also be very simple to implement (simply applying certain "actions" on playlist/video(/current index) tuples, where "playlist" and "current index" depend on the open window and "video" on which video the button was on)
• advanced "queue in another window" functionality could be managed via drag&drop (drag source determines video, drag destination determines in which queue and at what index to insert - ideally, the target window should highlight "play next"/"play at end of queue" regions during drag)
• advanced compatibility with normal playlists could also be added - playlist content could be transferred/added to a queue playlist if desired, and then modified without affecting the underlying playlist. That functionality would even allow queuing multiple playlists, though obviously (and by design - otherwise, dynamic reordering without permanent effect on playlists would be impossible) you could only modify a playlist with the "currently playing" UI if it was opened directly, without queue functionality
  • this is similar to web youtube, where you either play a fixed playlist (and can only modify it by permanently reordering/adding videos to it), or use the play queue
• highly advanced (and probably "overkill") features like structured playlists (tree-like structure, where trees can be dragged around as a single object) or "by reference" addition of playlists (so changes to order/content affect the underlying playlists) would need some modification to how queues are stored internally, but could still be done in a backwards compatible way
  • this seems to me to be the only way hybrid unified playlist/queue functionality could ever be implemented
  • with such a tree-like view, you could even optionally unify multiple windows with different queue configurations into a single view, use it for "view session management", etc. (such features would need further specific implementation extensions, but we are far beyond "state of the art" at this point anyway)

[kommunarr]

Sorry my brain broke a bit when reading this. Could you explain to me what you want me to show you?

1. Reorder a queue: does it reorder the actual playlist?
2. Remove a video from the queue: does it remove it from the actual playlist?
3. Enqueue a video: does it add it to the actual playlist?
4. Remove a video from the playlist itself in a separate screen and return to the queue; is it removed now from the queue?
5. Add a video to the playlist itself in a separate screen and return to the queue; is it added now to the queue?

[efb4f5ff-1298-471a-8973-3d47447115dc]

1. Reorder a queue: does it reorder the actual playlist?

No.

Trim.20240720.171523.mp4

2. Remove a video from the queue: does it remove it from the actual playlist?

No.

Screen-20240720-172205.mp4

3. Enqueue a video: does it add it to the actual playlist?

No.

Screen-20240720-172447.mp4

4. Remove a video from the playlist itself in a separate screen and return to the queue; is it removed now from the queue?

No.

Screen-20240720-172700.mp4

5. Add a video to the playlist itself in a separate screen and return to the queue; is it added now to the queue?

No.

Screen-20240720-173113.mp4

[kommunarr]

Thanks so much for testing and confirming these behaviors! If I'm understanding correctly, it seems like opening any playlist is actually cloning it as a transient queue, and any action you take on one from that point has no effect on the other. It's kinda weird compared to how I currently use FreeTube, where I often want to add + enqueue, or perma-remove, and now doing this actions together is made more inconvenient by this different process in exchange for the greater flexibility to do them individually. It's kinda weird of a model to me because the main benefit of a queue from my perspective is customized control over the ordering, not finer granularity over the addition/removal process, where I have to make a conscious decision if this is a video I want to watch in this session, save for later, or otherwise have to make two selections to punt the choice.

It's interesting to contrast with @shadoxxhd's suggested behavior:

add a button next to the "Favorite" button on videos, that adds videos to a "queue" playlist instead (just needs an icon, so the "enqueue" vs "insert in queue" question isn't that important)

Under this proposed model, playlists work as they do today until you "create" a queue from scratch. It presumably acts the same in terms of operations, but it makes a clearer distinction to the user of "being in a playlist" versus "being in a queue", where perhaps there would be less confusion around whether any operations affect the underlying playlist, you have to manually add videos to that queue instead of starting out from an initial place, and you could have an option for bulk-adding those videos to a playlist. That has the aforementioned tradeoff of having to manually curate the queue's elements, and questions around what happens when you want the playlist videos "open" as they are today in a box for new additions to the queue once you're watching a new video "in the queue".

I'm not familiar with how YT does this, but it seems like you're saying they have something like this, which I wasn't familiar with. I want to learn more, talk about, and try these systems out before we can even draft the requirements for this proposed feature, as it seems like it's a pretty meaty system to add for arguable upside. We'd need to rate on such factors like UX mental model familiarity, learning curve, utility, and maintainability.