-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Align block hover and select styles across list view, site editor, select mode #31277
Conversation
Size Change: +364 B (0%) Total Size: 1.03 MB
ℹ️ View Unchanged
|
Looking at the videos, and the reasoning, this seems like a good step in the right direction. I'll need to dive in a bit more to marinate on the edgecases. Thanks for your work! |
I took this for a spin and I'm not actually convinced the heuristic is quite obvious to me, which could mean it needs a little tinkering. Here's edit mode: In this one, it feels opposite that hover is bold and select is 1px, but I could probably get used to that. Though there's still the conversation about selected & focused, vs. just selected. Moreover, I did like the consistency between the 1px sibling inserter and the hover style. If we do change defaults here, we'd probably want to update the sibling inserter width as well. Here's select mode: I'm not sure what's up, but in some cases here, the hover style is 1px. Since part of the goal is to unify edit and select tools between post and site editors, one could imagine that testing this in the post editor would be a more representative experience since that keeps a classic edit and select mode switch. But I ran into bugs here: Escape doesn't consistently invoke select mode, and select mode no longer requires two clicks to go out of it. I'm going to test in trunk and see if that regressed there as well 🙈 |
Thanks for the test! I agree on the outline differential you spotted between edit/select mode. But I don't know how much we should concentrate on that right now, because once we finish enhancing select mode I would imagine that the outlines in edit mode (in the site editor) could be removed, and Select made the default mode there. For me the 1.5px hover really comes in to its own when you start using the list view. I find the consistency there makes the overall UX feel more comfy.
I'm not really surprised, the selectors for these styles are kind of messy and difficult to track down 😬 Was there any blocks in particular where you noticed this?
Yes I noticed these issues while working on this PR, so I think they also exist in production. Sometimes clicking a block keeps you in Select mode (intended), other times it seems to transport you directly to edit mode. |
Confirmed, they're separate! Phew :D |
I took this for another spin, and although I deeply appreciate 90% of the effort, specifically the effort on consistency, and the effort on colors, I'm stuck on the inversion of selected vs. hover widths. I think this is potentially still something we can do, but I think that effort should be separate from consisting things up first. I'll get back to why in a moment, first GIFs. Before: After: Coming back to why I'm stuck on the inversion; I know Figma does bold hover and thin select. I also agree it makes quite a lot of sense there. The primary reason I think it's different here, is that we emphasize focus a fair bit more than Figma does, and we employ that 1.5px focus style across components specifically to differentiate 1px black from 1.5px focused. This is particularly noticable when you select an Image block: The image block above is focused. It happens to also be selected, which means if you press the delete key, the block gets removed. And while it's important for us to consider the difference between seleted and focused, in this particular case, and in the select mode case, any block that has the 1.5px blue border can be deleted, which means it's both selected and focused. All that is reason to say, let's get the consistency in, and then continue exploring what focus and select means for us across blocks and components. |
All good points. Let's focus on achieving alignment across the modes for now. I've reverted the border widths. |
This is looking good. The first thing I spotted is that the 2px border radius on placeholders is gone. That's a separate issue that I submitted a separate fix for, but it's the reason why I'm pausing there in this GIF: So the post editor looks good, nice work. In both template editing mode and the site editor, I'm not consistently seeing the 2px select style for blocks. Can you reproduce? |
That's strange, it looks like the stronger outline is applied to some blocks but not others. I'll investigate. |
Not so strange after all, I missed a selector 🙈 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR seeks to align the hover/select interaction styles which are currently expressed in three different ways across different editor UIs.
At the moment we have:
Select mode
select-before.mp4
Edit mode in the Site Editor
site-editor-before.mp4
List view + Canvas combo
In list view itself we see:
On the canvas we see:
list-view-before.mp4
In this PR I am trying the style from List view, IE a 1.5px blue outline on hover. I've combined this with a 1px blue outline on selection (on the canvas) to differentiate the two states. A thicker outline gives a stronger indication of the hitbox which works quite well imo. The thinner outline on selection reduces noise when editing which is arguably beneficial as well. It may be that we can even align these two styles in to a single visual treatment.
Here's the result:
after.mp4
Thoughts?