[Feature Request]: Inline user playlists in sidebar on desktop view

[kommunarr]

Guidelines

• I have searched the issue tracker for open and closed issues that are similar to the feature request I want to file, without success.
• I have searched the documentation for information that matches the description of the feature request I want to file, without success.
• This issue contains only one feature request.

Problem Description

The flow of accessing favorites is more jarring for desktop view with the inclusion of user playlists, now having to click the Playlist tab, wait for the /userPlaylists route to load, then click my desired playlist to get where I want to be. It would be desirable if I didn't have to do two actions to access my playlist of choice (as was the case before).

Proposed Solution

Inline the user playlists in the side nav for the desktop view, much like the YT implementation. This makes this for a more streamlined UX flow that matches how I used it before.

One major question is what we do with the Playlists tab on the desktop view. I say hide it because it then no longer serves a real purpose other than easy access to the "Create New Playlist" button. We can probably add an "Add New Playlist" button as a sidenav option to compensate.

Another major question is if we add a "Show more" / "Show less" button like YT. I say yes to this as well, because users might have a significant number of playlists.

A third major question is if we show a playlist that exists outside of the "Show more". Yes: the quick bookmark target.

Nothing should be changed at all on the mobile view.

Alternatives Considered

• Keep Playlists tab on desktop view below all playlists in lieu of an inline "Create new playlist" button.
• Place items in top nav instead of side nav (bad idea - too short/valuable of real estate, and isn't where users recognize it to be).
• No "Show more" / "Show less" button in MVP (it's not going to be the worst thing ever, but some users will be pretty severely impacted. I see no reason to rush this out the gate).

Issue Labels

ease of use improvement, improvement to existing feature

Additional Information

No response

[absidue]

I would like to add two things onto this:

• The playlists should only be shown when the side bar is expanded, that way it keeps it compact and avoids having to show unidentifiable playlist thumbnails. In compact mode the playlists button would continue to be shown like, it is now.
• We should probably only show a limited number of playlists in the side bar to avoid making it too cramped e.g. quick bookmark (if set) + the 3 most recently modified ones and then have a "View All" button that takes you to the playlists page.

[Skidout]

I'd like to try this one.

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

@Skidout before you go at it. Please answer the major questions in the issue because discussion about that is still needed. If you answered those the team can check if that aligns with us

[Skidout]

• The Playlists tab should stay since someone that has many playlists would get their sidenav cluttered. If they want to, the user can bookmark as many playlists as they want.

• There should be no limit to the number of playlists the user can bookmark, but the most recently played playlists should only be shown in the first 3 slots.

• At least the 'Favorites' & 'Watch Later' playlist should still be shown in compact mode. Thumbnails are probably not going to be identifiable regardless, so we should use an icon instead.

• For people like OP, there should be a 'Bookmark All' switch in settings so that all playlists can be accessible on the sidenav & any new playlists are automatically added to the sidenav. With this switch enabled, the Playlists tab will be hidden. If the switch is in the Playlists tab, it would be impossible to turn it off.

• The 'Favorites' & 'Watch Later' playlists should be their own icons

• A 'Hide Favorites', 'Hide Watch Later', & 'Hide Recently Viewed Playlists' switch should also be added under Side Bar settings.

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

I would like to hold this off until we have released v0.20.0

[Skidout]

Ok, Understood.

[kommunarr]

@Skidout v0.20.0 has been released. Are you still interested in taking this one on?

[Skidout]

Yes. Have they decided on the major questions?

[kommunarr]

I'll invite the other teammates to discuss. CC: @absidue @efb4f5ff-1298-471a-8973-3d47447115dc @ChunkyProgrammer @PikachuEXE @MarmadileManteater

The main concerns I'm thinking about:

1. Adding more controls & optionality is something we would prefer not to do. We would prefer the solution that had the fewest amount of additional controls or settings added because we want to be conscientious of cluttering up the UI (more than it already is, but we're working on that).
2. As a corollary of 1, that means making development choices that:
   a. have good-for-most-everyone default behaviors, and
   b. (when 2a does not suffice) lean into our existing settings and controls without having to add additional ones.

Because of the above, I disagree with any implementation that adds an additional control to bookmark playlists specifically for this purpose, especially given that we already have "quick bookmarks" available for a different purpose altogether.

To revisit the implementation questions now, here are my recommended answers:

1. I have changed my mind and agree with you that we should still keep the Playlists tab in the side bar, because it has some specific utilities that we would like to keep around (e.g.., the User Playlist search function, and a visual central hub for playlists).
2. We should have a "Show more" / "Show less" button like YT.
   i. I didn't ask this question originally, but here it is: "In which order do we show the 'Show more' playlists?" Answer: use the sessionStorage's 'UserPlaylists/sortBy' value. This complies with 2b in that we're not adding an additional control, and instead leveraging the user's preference they provided elsewhere.
   ii. Here's another new one: "How many playlists do we show in the 'Show more'?" I think this is one that's easy to overthink the edge case of someone with 50 playlists. Most people have very few, so I think this is far less important of a question than we sometimes have treated it as. I think you should just pick any arbitrary number. I like 10. You pick the first 10 from the sorting mentioned in 2i. This complies with 2a as a simple default that's good-for-almost-everybody. Worrying about trying to maximize the satisfaction of people by having long debates over what the default value should be, or worse, adding more controls in, is a trap.
3. "What playlist exists out of the 'Show more'?" Why, the quick bookmark target! Perfect example of employing 2b.
4. Paraphrasing from @absidue above: "Should the playlists only be shown when the side bar is expanded?" I agree with absidue that this should be "yes".

This is my personal recommendation, but I'm also fine with @absidue's recommendation of this as an alterative to 2/3:

We should probably only show a limited number of playlists in the side bar to avoid making it too cramped e.g. quick bookmark (if set) + the 3 most recently modified ones and then have a "View All" button that takes you to the playlists page.

With only the minor quibble that we should use the sessionStorage's 'UserPlaylists/sortBy' value instead as the sorting preference, and also always include the Quick Bookmark target at the top of the list.

Let's get at least a couple of other FT contributor voices on this, but I think either of the above options would be fine.

[redactedscribe]

I'm hoping pinning a playlist to the top of this list of playlists (or potentially as a separate button as per #4861) would be possible. The benefit is immediate access to a commonly viewed playlist. However:

We should probably only show a limited number of playlists in the side bar to avoid making it too cramped e.g. quick bookmark (if set) + the 3 most recently modified ones and then have a "View All" button that takes you to the playlists page.

This would mostly solve it. The goal for me is for my "watch it later" playlist to be at most one click away. The only small issue which remains with the inline list suggestion is that you still must hunt for the playlist out of the limited set displayed as it may not be in the same position each time on screen (due to which playlists have been recently modified). This is why I initially wanted to pin a single playlist as a button, i.e. essentially the pre-v0.20 "Saved Videos" button.

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

I agree with everything that is mentioned by @jasonhenriquez and @absidue. I have nothing to add.

[Skidout]

Maybe the quick bookmark target should still be shown in compact mode, that way people using compact mode can use the new feature. There wouldn't be any problems with identifying it since the user chooses the playlist manually.

@absidue's suggestion for 2/3 seems like the better suggestion since the difference between a show more button & the playlists tab button would be very little if only the quick bookmark target is shown at first, but the playlists tab would let you sort & search while the sidebar would let you navigate through playlists without navigating away from the current page or opening a new window. However, the sorting order should follow the one the 'UserPlaylists/sortBy' value.

[kommunarr]

Sounds good to me @Skidout!

[kommunarr]

Would you like me to set you as the assignee on this one? @Skidout

[Skidout]

Yea that would be good.

[Skidout]

Everything is going pretty well, just need to add the 'show more' button & do some testing. Only thing I'm not sure about is what icons to use. Right now I've left the playlists tab icon as 'fas bookmark', the quick bookmark playlist is 'fas heart', & the other playlists as 'fas list'. I'm thinking that 'fas bars would work well for the playlists tab, then it would make sense to change the quick bookmark playlist to 'fas bookmark', & I feel like there might be something better than 'fas bars' for the other playlists. I'd like some input on what you guys think would be good.

[absidue]

I wouldn't use fa-bars for the playlists button, as it is visually very similar to the icon used for the channels one. So when the side bar is collapsed and the "Hide Side Bar Labels" setting is turned on, the two icons would be hard to distinguish from another at a quick glance, especially when you keep in mind that you can hide quite a few of the side bar items, so they could be right next to each other.

Using it for other playlists is okay though, because if you are implementing it as discussed above, then they won't be visible when the side bar is collapsed, so there would be no issue, as the only times those icons would be visible is when they have a label next to them.

[kommunarr]

Great work @Skidout! Feedback: I can see that the heart is being used to represent the Quick Bookmark playlist, but I don't think that indicator is needed, at least so prominently, as it seems to visually suggest that it's of a whole separate category/type than the others, which is an overstatement. I'd prefer either making it use the same icon as the others or putting a very small heart by or inside the same icon (decently harder request, fine if not feasible).

[Skidout]

@absidue I meant 'fas bookmark', not 'fas bars', sorry.

[Skidout]

@jasonhenriquez I'll see if I can put the heart icon alongside the bars. If not, I'll use 'fas bars'.

What do you guys think about using 'fas table-list' for the playlists tab since it's for all the playlists & not just saved videos anymore.

[kommunarr]

It looks too similar to the Channels tab IMO (list). I like the idea of keeping the Playlist tab the same, making the playlist entries have lower vertical gaps between them, and possibly slightly reducing the font size on the playlist entries to more clearly communicate their visual grouping and relationship with the Playlists tab. But I'd have to see how that looks in practice before committing to that.

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

Hi @Skidout could you provide a status update

[Skidout]

Still working on it, been busy with appointments.