Exploration: Simpler outlines and synced pattern interactions #60286
Conversation
could potentially remove the class altogether
|
Warning: Type of PR label mismatch To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task. |
richtabor
changed the title
richtabor
changed the title
|
Size Change: -502 B (0%) Total Size: 1.72 MB
ℹ️ View Unchanged
|
Conceptually, I like this approach, but in practice, it felt disjointed. Some blocks were outlined when I selected them, and others were not. Also, I noticed that list items were outlined when normal paragraphs were not.
I like this change. It's also consistent with the space between the block icon and the toolbar. 
I like this a lot, especially the border-radius being removed. The uniform border width is also a nice touch.
No strong preference here. I still think that the different colors (blue vs. purple) are very confusing for new users. Don't have any better suggestions though 😅 |
I think this works better than the dotted outline 👍
This feels nice.
May need to check a11y guidelines around this, I think hover/selection may need to be different? It may not work, but I've often wondered if it'd be worth trying the reverse... stronger outlines seem more useful when you're trying to select the right block, and 1px on selection would harmonize with the block toolbar outline. Could also work better when selecting immediate descendants too... Here's how it would look when hovering an image inside a selected group: 
Versus trunk, which feels backwards to me: 
Maybe worth a try, maybe not :)
I think I agree with Nick on this. Seeing the outline on selection helps you understand the overall footprint, and since the outlines disappear when you begin typing the distraction should be minimal in practise.
👍
Love it, this one has always bugged me. These outlines are a very practical element, and imo we should exert minimal brand expression upon them. Along that train of thought, should we try removing the subtle fade-in animation of the outlines on hover? The UI feels snappier without it imo. |
I think we need a bit of education in the editor, perhaps the first time you select a template part or synced pattern. It's quite helpful, when you know what it is. |
Yeah, the colors are fantastic if you first understand what a template part and synced pattern are. |
|
There's a lot to like here. Overall some things feel simpler as a result of this, much less noisy. So although I echo Jay's comments in general, this really does simplify the outlines. That said, I'm really missing the 2px rounded radius :)
|
I thought you'd say that :) I think we should consider no radii on the outlines still. It does lead to sharper corners and intersections, both in relation to other outlines, but also the surrounding interface. No radius
Radius
|
The problem with using width to distill hover or selected, is that when outlines intersect, we end up with this:
|
I think that could work. |
|
The with-radius looks great to me still. This is one of those areas where I feel pretty strongly about it, but I would never want to block this from moving forward if the rest of you are similarly strongly in the other camp. For me the radius is a branding element, because it matches the block toolbar. |
Is that still a problem if we use 
|
|
Noting that color matters so much here and it's something I'm a bit worried about with this effect. Here's an example where it's just simply hard to see what's going on: color.movIf I didn't know those were editable fields, I might worry that I just added some sort of animation to the pattern haha. There's also some weirdness where, when you're selecting the synced pattern, it continues to show the content only editing for the entire page, rather than jumping to the pattern view: content.only.movI also set the cover image so it could be changed/overridden yet don't see that shown in the Content section (likely outside of this PR and can open an issue if so): no.background.image.mov |
|
Pinging the crew in the #outreach channel @WordPress/outreach so they are aware of this exploration and offer input. |
|
Either adding a third tab “Pattern” to the existing “Page” and ”Block” when working with a focused pattern would be the clearest UX. If there's insufficient space, then perhaps rename “Block” to “Pattern” on the fly, but that'll probably confuse less-experienced users. |
I think these are a nice improvement.
This is not disruptive to me, and I would leave the outline.
I vote for
I think the lack of radii on these elements is a good deviation.
I was not entirely clear as to their impact when reviewing these changes. Therefore, I'm refraining from feedback. Although 6 feels like it was likely an extension of 2. Thanks |
Additional note, now that I've seen this has been implemented in 6.5. I understand more fully what the idea is and I feel that it definitely needs improvement. Firstly, it's not immediately obvious how to get back to the page content once you're in the Pattern editing view. The “back” link in the top toolbar is very small and grey, so a) it's very hard to find and b) has the appearance of being inactive. In an example I've been using for a while, the pattern could formerly be edited directly in place and so I was always able to adjust the focus point of my reusable pattern—a cover block linked to the featured image of the current post—and see the results immediately. By detaching the user from the current page content and switching into ”pattern” edit mode, I can no longer see the featured image: the cover block is just a grey rectangle. That means the editing process I've been using so far no longer works as required. |
|
And another question: if I have a synced pattern, as is now the case, is it not possible to unsync an existing pattern? (As in, retain its status as a pattern, but stop it from being synced.) |
@markhowellsmead to quickly answer this question: you can duplicate and change sync status. Here's a video I made for someone yesterday (used "reusable" language to help guide them :D ): change.sync.status.mp4 |
That's great, thanks Anne. So there's no way to unsync them from the block editor? That means having to hunt them down everywhere in the content and re-link them with the new version, then. |
|
Unsyncing a pattern can have quite severe consequences, depending on usage (#60205). It's basically the same as deleting in that respect, so we need to get the design right.
Instead of creating a new synced pattern, why not just edit the existing one? Describing the workflow in more detail (ideally in a new issue) would be really helpful! :) |
|
Thanks for the feedback, James. I think this is an extreme edge-case and so not worth discussing for general implementation. |
It's meant to be a guide, if necessary. As it's as big as your viewport, the effect is less clear — but then you can clearly select on the text and quickly understand its editable. If you have a pattern with more parts to it, it becomes more clear what's editable. |
@ndiego @jameskoster Noting that the post editor does not have those outlines when selecting Rich Text blocks. If we're going for 1:1 we should lean one way or the other perhaps. After feeling it out a bit, I think I like it. Let me finesse it a bit and I'll pitch it back for another look. |
|
@fabiankaegy have ideas/thoughts? |
|
@richtabor My thumbs down was meant to agree with @annezazu's point that I think the current proposed state here has too little contrast and is hard to see in many instances. If I look at the way Figma has implemented this in the preview mode it comes through much more clearly whats selectable. Maybe it is the fact that the animation starts of with less opacity / more brightness.
|
Yea, I'll play around with the values a bit. Thanks for sharing! |
Not intended for direct merge.
This is an exploration of a number of ideas around block selection, outlines and related interactions, combined to get a solid sense of how these will work together.
My goal is to try and make it less "weighty" selecting blocks in the Site Editor, more predictable, and less concepts to understand. Less moving parts if you would.
If we like the direction we can split it into proper PRs.
What?
outlineandoutline-offsetas the mechanism for visible outlines, rather than shadows. Allows for borders to be clearly seen on fullwidth block selection, while also reducing clashing borders when hovering/selecting blocks near each other.var(--wp-admin-border-width-focus)width for outlines, rather than1pxon hover and1.5pxon selection..is-selectedoutline when selecting RichText, making text editing less disruptive by outlines.Testing Instructions
Screenshots or screencast
inert.mp4