-
Notifications
You must be signed in to change notification settings - Fork 827
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make layout full-width #5294
base: development
Are you sure you want to change the base?
Make layout full-width #5294
Conversation
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 From #5007
I suspect limiting the no. of columns is making this worse? |
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.
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. |
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 |
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. |
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:
|
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! |
I am fine with #5007 as the issue opener agrees |
I cant make it out from the screenshots but does this fix #4535 ? |
No, it does not |
Pending reviews from others especially on mobile side |
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. |
Yes, sorry, I made a mistake. The grid view is perfect. |
6b0d9fb
to
83e79e1
Compare
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 |
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): |
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? |
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. |
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. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
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. |
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
@kommunarr are there still changes needed? |
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. |
…at/add-full-width-layout
Conflicts have been resolved. A maintainer will review the pull request shortly. |
Make layout full-width
Pull Request Type
Related issue
closes #5007
closes #5296
Description
Co-authored-by: @pkrasicki
(reusing some of the work from #4379)
Summary:
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
Desktop
Additional context
We have so many different
card
classes and styling rules throughout the app, mostly just to setmargin-inline: auto
andmargin-block: 0 60px
ormargin-block: 0 15px
. This is a potential future cleanup opportunity (i.e., including these into the default styling of theft-card
component, or setting atheme
variable based on which version we want to invoke).