Update layout / alignment metrics in the Site Editor's "Browse" mode. #49028
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jameskoster
added
Needs Design Feedback
|
Size Change: +340 B (0%) Total Size: 1.34 MB
ℹ️ View Unchanged
|
|
I like the site icon + frame alignment very much. Before/after screenshots:
After: 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 don't mind optically aligning the menu item icons with the text above and below. The misalignment I was referring to was this: Either the text should optically align with the < back chevron, or they should align with the Design heading. Right now it doesn't seem like it aligns with either. |
|
Oh I see, yes, let me try budging the panel title over a little bit. |
|
The drawback with this is that the We could shift that over as well, but then the alignment with the Site Icon is broken. Perhaps that's better though:
Please feel free to push to this branch is inspiration takes hold :) |
|
Flaky tests detected in d2c7313. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4425761502
|
|
The problem with moving things leftwards is that then they start to feel misaligned with the site logo. I hate to say it, but I'm coming back to some of these metrics being somewhat cogent after all:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
subheadlinein the experimentalTextcomponent<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