-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Update layout / alignment metrics in the Site Editor's "Browse" mode. #49028
Conversation
Size Change: +340 B (0%) Total Size: 1.34 MB
ℹ️ View Unchanged
|
I like the site icon + frame alignment very much. Before/after screenshots: I'm not entirely sold on the layout formulation, though. I can see how things align when you are hovering a button, but whenever you're not, it looks misaligned: Until we have a more solid plan for those metrics, I'd keep items aligned to the detail page title as it is in trunk. But let's not let that block us from the padding improvements, which I like so so much. But we might want to polish it a bit still. get the math just right. As it is, the outer padding is 16px, matched in the logo, which feels good to me. However, going in and out of the editor, that math changes a bit, causing the site logo to shift 2px: This shift isn't problematic per se. But mainly I feel that either the site icon should visibly move, or not move at all. It's just this teeny in-between that frustrates me slightly. The math is that inside fullscreen, the toolbar is 60px tall. With a 32px site icon inside, the padding comes to 14px. Outside fullscreen, we change the padding to 16px, hence the 2px shifting. To fix it we can either:
What do you think? |
Thanks for the detailed inspection, I appreciate there's quite a lot happening here.
This part is tricky. But I'd love to solve it here if we can :) As you know, the problem is that icons always occupy a 24px square, but for many of them the part that's actually visible only occupies 16px. So you get this perceived misalignment, despite the elements technically being lined up correctly as illustrated below: I chose to align the 24px footprint because it's the only constant we have, and didn't necessitate more code. Alternatively we could adjust the padding when an icon is present to get things lined up visually, but if we do this then we concede that any icons occupying >16px will be misaligned, like the Template Parts icon: My systems head tells me to align to the 24px footprint because it's constant, but my design head acknowledges the visual misalignment. So no strong feelings from me, it's just a decision we need to make around which trade-off is more/less desirable:
This would be my preference. Not only because it circumvents the 14px values which don't align neatly to a 4px baseline, but also because there's something about an anchored site icon that helps establish it as a UX landmark. I figured this would be something to explore in a follow-up though, as there may be knock-on effects. |
Oh I see, yes, let me try budging the panel title over a little bit. |
Flaky tests detected in d2c7313. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4425761502
|
What?
Updates the general spacing of the UI in Browse mode.
Why?
This is mostly an experiment for optimising the space for the content therein. Currently the sidebar occupies a large footprint with lofty spacing that may not scale well as more complex interfaces appear here. Indeed we're already running into minor issues with the readability of longer template descriptions. A before/after can be seen in the gif below:
Most significant changes:
subheadline
in the experimentalText
component<
button† In order for this to work I had to increase the W button dimensions to 64px x 64px. The result is a small animation between browse and edit modes, since the W button needs to be 60x60 in edit mode to fit nicely in the top bar. I think we can discuss this, and personally I'd lean towards increasing the entire top bar to 64px in edit mode. That would be something to tackle separately, and the small animation might serve as a temporary solution.
Here's a gif demonstrating the layout formulation:
Clearly there are a lot of changes here. In an ideal world we might tackle each item piecemeal, but I think doing so would result in awkward inbetween states where things get worse before getting better. Since the changes here are 90% css, I think there's an argument to deploy them altogether.
One other thing we might consider here is the width of the sidebar itself. The tighter spacing in this PR creates scope for us to reduce that if desirable.
How?
Mostly css changes.
Testing Instructions
To reiterate: I see this as an i1 experiment, and certainly something to be refined.
cc @WordPress/gutenberg-design