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):

[kommunarr]

Update: After many hours working on this PR and losing my mind, I am almost done. Last bugged state to fix seems to be the user playlist mobile list view

[pkrasicki]

Nice! That update notification on top should have the same size as the Card component, though. That's another thing that I missed, because it's usually not there :D.

Edit: It could even be smaller than that, but I don't know what size would be best. Here is what 85% of width (I guess that's previous card size) looks like (at 1080p):

[kommunarr]

Interesting, I didn't have a clear idea for this one. Ideally, a solution that maximizes alignment is best, so it would make sense to align with either the top nav or the card. Card makes sense for regular viewport widths, and is what we've done before, but it kind of looks weird to have it shrink to card width at >2800px widths, so my reasoning was that it would make sense to stay more aligned with the top bar than anything else. I typically think of banners as full-width as well. What do you think?

[pkrasicki]

So the card size is full width until window size reaches around 3k. I think the banner size could be 85% until window size reaches around 3k. After 3k it could be 85% of the card's width. But if that's too complicated, you can just always make the banner 100% of card size. There probably isn't a perfect solution here.

In general it's not a good idea to have huge brightly colored rectangles, unless you want to display a critical error or something else that demands user's attention immediately. The banner is annoying and I have to close it every time when running an old version. Let's do the above solution for now, but I will create an issue with a proposal to replace the banner with something else.

[kommunarr]

Mobile list view is just so ugly and hard to work with. I'm thinking about implementing #5012 in this but with grid view as the ruleset instead, because that would be so much easier. I hate to bundle in so much stuff, but it's just such a headache, we might as well get all of the related testing out of the way in one PR.

[kommunarr]

Yeah, I don't think we're in any disagreement. I think we can acknowledge the importance of research-backed design improvements, while also acknowledging that aligning it with the language of linear progress misrepresents the complexity of the problem domain and solution space. Particularly that our understanding of it is quite ideological, interwoven with things like the profit motive, valuation of the idea of engagement maximization, dogmatization of principles, and devaluation of the experimental and untested. It's far too esoteric for what's currently under discussion, but I think it's always important to be cognizant of the framings that we employ in our understanding.

[github-actions]

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

[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.