Skip to content
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

Full Site Editing: Block selection #27239

Closed
jameskoster opened this issue Nov 24, 2020 · 4 comments · Fixed by #27271
Closed

Full Site Editing: Block selection #27239

jameskoster opened this issue Nov 24, 2020 · 4 comments · Fixed by #27271
Labels
[Type] Discussion For issues that are high-level and not yet ready to implement.

Comments

@jameskoster
Copy link
Contributor

Anyone who has spent some time playing with the Site Editor – and Template Parts in particular – will likely empathise with the struggles one can face when interacting with these container blocks and their children.

I frequently feel a distinct lack of confidence in any attempt I make to select a template part via click. More often than not I inadvertently select a child block, and from there I have to decide whether to:

  • Persist with my clicking attempts (getting more frustrated with each failed click),
  • Utilise the block list view (ugh two clicks + visually scanning through a list),
  • Or admit defeat by selecting a child block and then using the parent selector pattern – multiple times if there's a lot of nesting.

It probably shouldn't be this difficult to simply select a container block like a template part of a group.


Since the template editing experience in the Site Editor will largely revolve around interactions with container blocks like Template Parts, Queries, and Groups, I'm wondering if that environment might be a good space to explore solutions to this problem.

Doing so should also address the final high priority item in part 2 of the Site Editing Infrastructure and UI milestone.

A prototype

To tackle this head-on I put a rough prototype together which addresses the aforementioned issues via a combination of UI adjustments.

select

Take it for a spin yourself.

  • Hovering any block will outline its boundary, helping clarify what will actually be selected when you click.
  • Selecting a block removes the border, with the exception of container blocks as it is important to understand the outer boundaries of a container. This avoids borders distracting you from interacting with actual content.
  • Template parts have a different border color to indicate that they are special. More context on this in Site Editor: Distinguish Template Parts #26599
  • When a child block is selected a permanently-visible shortcut to select its parent appears left of its toolbar. Hovering this shortcut reveal the parent boundary.
  • If the selected child block is inside a Template Part, that Template Parts name is highlighted in the Top Bar, and can be clicked to navigate directly to the template part. This is helpful if the nesting is deep, or the layout is convoluted.

The prototype includes regular blocks, two separate template parts, and a group block as examples.

I appreciate we've had borders outline blocks similar to this in the past, and moved away from that pattern. But in the context of editing templates with lots of nested elements I find the indications to be very helpful and intuitive. I'm sure there is a lot of refinement still to do, particular around the visuals (border widths, color treatments, etc), but this feels like a decent starting point to me.

cc @jasmussen @shaunandrews @kjellr

@jameskoster jameskoster added [Feature] Full Site Editing [Type] Discussion For issues that are high-level and not yet ready to implement. labels Nov 24, 2020
@kjellr
Copy link
Contributor

kjellr commented Nov 24, 2020

Thanks for sharing this exploration!

I appreciate we've had borders outline blocks similar to this in the past, and moved away from that pattern. But in the context of editing templates with lots of nested elements I find the indications to be very helpful and intuitive.

In the context of the post/page editor, the outlines really got in the way of writing. But you're right that they may make more sense here since the site editor is distinctly more of a "building" environment.

There are borders available in the post editor today if you switch to "Select" mode. Maybe this is just that, but on by default in the Site editor?

Screen Shot 2020-11-24 at 10 47 20 AM

cc @jasmussen since I know you have a lot of knowledge and thoughts on this topic.

@jasmussen
Copy link
Contributor

I appreciate we've had borders outline blocks similar to this in the past, and moved away from that pattern. But in the context of editing templates with lots of nested elements I find the indications to be very helpful and intuitive. I'm sure there is a lot of refinement still to do, particular around the visuals (border widths, color treatments, etc), but this feels like a decent starting point to me.

... and ...

There are borders available in the post editor today if you switch to "Select" mode. Maybe this is just that, but on by default in the Site editor?

Good thoughts, both. The instinct to resurface some block boundary indications, especially in context of the site editor, is a good one. But I don't think we should mess with the tool defaults, the two editors are close enough in appearance that the change will likely just confuse.

But thank you for bringing it up, because there's an important aspect about focus and "block selected" to keep in mind. Specifically, the blue thicker border means focus, and it often also (but not always) means selected, implying you can press the Delete key to remove the block. That overlap is the cause of the the intentional overlap with the select tool where a block with a blue border is both selected, and has focus.

This ticket seems focused on the hover effect, and is limited to the site editor which is in beta. That seems fine to me as a way to test this out, see how/if it helps. But testing out the prototype opens a couple of questions:

Screenshot 2020-11-25 at 13 53 20

Why is the border orange here? I see there's an orange "symbol" icon in the toolbar, and being a Figma fan myself, I sense that it has to do with template parts. But the problem with adding color here is that those colors are neither theme background aware, nor wp admin theme aware. I would avoid adding any new colors other than the spot color (blue by default).

Screenshot 2020-11-25 at 13 55 06

When I select the group, there's a blue 2px border around the box. When I select a group in the block editor, there is a 1.5px focus rectangle around the block, with a 2px border radius, and this focus rectangle disappears when focus lands elsehwere. I assume the difference here is primarily due to this being a prototype, but I wanted to explicitly note it. Revisiting borders is fine, but we should take very careful and minimal steps, one at a time.

Therefore, just to set out some boundaries for these explorations:

  • Thicker border means focus. If the block itself does not have focus, the border should not be thicker.
  • For example a group, right upon insertion, has focus and therefore a tick border. As soon as you click the appender inside, focus — and the thick border — moves there.

In that vein, a 1px border for hover seems a good thing to experiment with. I've tinkered myself with showing a 1px border around the immediate parent block, to indicate its boundaries, and to look for ways to improve selecting the parent.

@jameskoster
Copy link
Contributor Author

On the subject of color, your sense is correct, it is used here to highlight template parts. I've used orange in the prototype (red in the PR) just as an example, the final choice should of course be color-scheme-aware, etc.

Exploring that here is perhaps taking the issue a step too far, but I wanted to get an idea of what that felt like in something beyond the static prototype. There is a separate issue here to discuss further.

@jasmussen
Copy link
Contributor

jasmussen commented Nov 25, 2020

For the sake of shipping this as a cool improvement, probably best to keep the color stuff as a separate exploration. (Which by the way I agree should happen, it would be helpful to show different colors in a multi user editing environment, for example.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Discussion For issues that are high-level and not yet ready to implement.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants