Make layout full-width

[kommunarr]

Make layout full-width

Pull Request Type

• Feature Implementation

Related issue

closes #5007
closes #5296

Description

Co-authored-by: @pkrasicki
(reusing some of the work from #4379)

Summary:

• Makes layout full-width, ignoring only the Settings page
• Limits grid view number of columns to 5 (technically was already an encounterable UX issue, but with this change, it would otherwise have been problematic for a greater percentage of devices)
• Adjusts playlist page styling to avoid breaking regardless of viewport width, grid or list view, or length of playlist title / description

Note: will have to revalidate the Settings page if #5029 is merged first

Screenshots

List view, large screen:

Grid view, large screen:

Grid view, normal screen:

Testing

• Test any grid view is limited to 5 columns at large enough viewport widths (>= 1475px wide)
• (REG) Test different types of page routes appear normal on mobile & desktop view
• (REG) Test that settings page is unchanged
• Test playlist page A) grid / B) list view responsive design from I) mobile to II) desktop viewport sizes with i) overly long and ii) regular length playlist descriptions and titles

Desktop

• OS: OpenSUSE
• OS Version: TW

Additional context

We have so many different card classes and styling rules throughout the app, mostly just to set margin-inline: auto and margin-block: 0 60px or margin-block: 0 15px. This is a potential future cleanup opportunity (i.e., including these into the default styling of the ft-card component, or setting a theme variable based on which version we want to invoke).

[PikachuEXE]

With 2K monitor I think limiting no. of columns to a fixed value on a wide screen makes things appearing too large

Original size is 262px and now it's doubled
I don't even have a 4K monitor yet to test this fully

From #5007

the current padding limits the number of videos that can be displayed in favour of empty space, particularly on small screens or at higher zoom levels.

I suspect limiting the no. of columns is making this worse?

[kommunarr]

With 2K monitor I think limiting no. of columns to a fixed value on a wide screen makes things appearing too large

Is the suggestion to set it to 6? This default was inspired from Piped, which uses 5. Invidious uses 4. YT uses 6, albeit with a secondary rule of capping the video thumbnail width at 500px, which is only reached on viewports greater than 3200px in width.

I suspect limiting the no. of columns is making this worse?

Worse how? This behavior was specifically requested by a teammate, who said that they did not like this original feature suggestion because it did not have this behavior implemented. Using larger visual real estate to fit in an arbitrarily large number of columns of videos is a worse and more overwhelming UX.

[PikachuEXE]

the current padding limits the number of videos that can be displayed

This PR reduces the limit on the number of videos that can be displayed

At least I disagree this closes #5007, whether piped design should adopted is another thing

[kommunarr]

I respect your opinion on a lot of things, Pika, but this is the behavior of every major video app, not just Piped. I'm open to leaving that part of the PR into a separate one if it's requested, but I'm only bundling it in here directly because a teammate explicitly communicated to me that the absence of that feature was what made the previous version of the full-width layout PR an undesirable user experience. I'll check with the issue author on whether they think it resolves the issue on paper, but ultimately, I care about improving the UX more than anything else.

[kommunarr]

Hi @deepspaceaxolotl, does this PR adequately address your original issue? The main point of contention is whether it meets your intended definition if it also caps the max number of grid columns to 5 at large viewport sizes. This is behavior adopted from other major video apps to prevent an overload of information:

This default was inspired from Piped, which uses 5. Invidious uses 4. YT uses 6, albeit with a secondary rule of capping the video thumbnail width at 500px, which is only reached on viewports greater than 3200px in width.

[deepspaceaxolotl]

5 columns should be enough for most screens! My main concern was getting to 4-5 columns, so this should work well, thank you everyone!

[PikachuEXE]

I am fine with #5007 as the issue opener agrees
Now the only point left is using 4/5/6 columns...

[kommunarr]

How about 6 columns max after a 2000px breakpoint? This is roughly what YT does (I say "roughly" because oddly enough, I can't seem to get a consistent value at which it occurs with however they've implemented it)

[kommunarr]

Updated with the above change, as well as adopting behavior inspired from YT's, where the max card width is now 2800px. Below are screenshots of the app at a simulated 4096px width:

[kommunarr]

I also have a fix for #5296 included in a commit built off this PR (5a86911), but I can save that for a separate PR if desired. I think it would probably be wise to include it, just to minimize unique instances of the team having to test card sizing stuff, but up to us.

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

I cant make it out from the screenshots but does this fix #4535 ?

[kommunarr]

No, it does not

[PikachuEXE]

Pending reviews from others especially on mobile side

[pkrasicki]

I should have included this in my design. I missed this issue, because I don't have a big enough screen. This looks good, but in list view, the "More Options" menu button should be located right where video description ends just like on YouTube. Currently it's a big distance to travel with the mouse. So I guess the description's width should be limited.

[pkrasicki]

But when I go to YouTube's grid view at 4096px it looks different:

Their grid view is the same as in Piped and Odysee, except it doesn't stretch after 4k 3k.

Edit: Never mind. It looks like you replicated their grid view perfectly. I was just confused.

[kommunarr]

But when I go to YouTube's grid view at 4096px it looks different:

Their grid view is the same as in Piped and Odysee, except it doesn't stretch after 4k.

Could you contrast the current state of the PR versus what you're showing? I can't tell a substantive difference:

[pkrasicki]

Yes, sorry, I made a mistake. The grid view is perfect.

[kommunarr]

Updated now with a 10 line change (after hours of pain):

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

@kommunarr are there still changes needed?

[kommunarr]

Yes, I have some changes locally that are forcing the grid view for the one-column width breakpoint, but the User Playlist mobile view still has some issues.

[kommunarr]

The User Playlist mobile view and the User Playlist list view are my white whales on this one that I really don't look forward to debugging. I'm not saying I won't ever return to this, but I'd strongly recommend anyone with more passion on this issue to push commits to this PR if they would like a speedier push on this change.

[pkrasicki]

Here is a patch with a possible fix for mobile. It removes the padding on playlists page, which might not be what you wanted, but it seems to work. I think this should be done on all of the pages on mobile, since there really isn't enough screen space for all that padding and every card already has its own padding.

Profile settings page seems to have the same problem as playlists and it looks like you can fix it the same way (removing margin from page's routerView + changing max size for the cards). But I doubt that's caused by your PR. Trending page overflows too ever since tabs were added to it.

0001-Fix-playlist-view-on-mobile.txt

[pkrasicki]

Can you describe the issue with the list view?

[kommunarr]

Thanks @pkrasicki, I added you as a collaborator to my fork for you to push this.

[kommunarr]

IIRC, the Playlist page list view broke sometimes when testing at different viewport widths. It may also be affected by the length of the playlist title or description.

[pkrasicki]

I think I fixed the overflow problem with playlists in list mode and I'm currently not seeing any other issues. Let me know what you think of the changes.

[pkrasicki]

I guess one issue is that the right panel doesn't fully extend like it should. There is always a big gap on the right side.

Edit:
I think this can be fixed, but having two layouts is bad. Why do we do that? Why not have a single column layout in both grid and list mode? Channel page doesn't have two layouts. This adds unnecessary work (this CSS is complicated to understand and testing is hard) and makes it difficult to keep things consistent. In grid mode (one column layout) we don't display a thumbnail on the playlist page. In list mode (two column layout) we do display it, but only above a certain resolution and at one resolution the image suddenly becomes crazy big.

Let's remove the two column layout entirely, focus on improving the one column layout by adding a thumbnail to it and making sure it scales properly. Less code, easier to test and everything will fit nicely on both mobile and desktop without hacks. Maybe we can even try to make it look similar to channel page, since that design works well and users are already familiar with it.

[kommunarr]

I agree with much of what you're saying, although I'd recommend separating that out as its own ticket and/or PR. There are a lot of developer opinions about some of these topics, and it's best that we don't hold the initial enhancement hostage to the discussion.

[kommunarr]

Also please run npm run lint/npm run lint-fix to resolve linting issues

[pkrasicki]

Done. The right panel should be fixed now too.

[pkrasicki]

I tested YouTube a little bit and wrote down what they do in case you prefer to copy their behaviour (kinda like the previous solution did) instead of having these scrollbars.

YouTube:

• never shows more than 2 lines of text (not even on desktop it seems), here is what they do to achieve this:

display: -webkit-box;
-webkit-line-clamp: 2;
-webkit-box-orient: vertical;
overflow: hidden;
text-overflow: ellipsis;

• if text is bigger than that, it gets cut off and ellipsis is shown
• there is no way to view the full playlist title (in this view at least)
• playlist description is clickable - on click a popup displaying all of the text is shown
• when description is too big, there is also a "more" button to indicate that it can be clicked to read more text
• thumbnail is displayed on all resolutions

A compromise could be to cut off playlist title (maybe show the full title on hover at least? won't work for mobile users, but it's something), but have a scrollbar for the description just like we do for video description on watch-video page.

---

I suspect that it might be possible to get rid of the third scrollbar (for the panel itself) by rearranging things in the template and changing some styles.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

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

@kommunarr @pkrasicki are there still things that need to be done?