Site Editor: Open block settings upon block selection

[annezazu]

This came up as part of the Hallway Hangout on improving accessibility in the Site Editor when @alexstine demonstrated how, upon selecting a block, the block settings aren't automatically opened. This causes additional labor to open it and doesn't match the experience in the Post Editor. My best guess is that this is due to Styles having a tab and not wanting to override that experience while also providing deep linking built into Styles upon block selection but I'm not quite sure. Let's discuss further here!

[afercia]

upon selecting a block, the block settings aren't automatically opened. This causes additional labor to open it and doesn't match the experience in the Post Editor

Maybe I'm missing something but in the Post Editor the Settings panel doesn't automatically opens upon block selection for me?

[alexstine]

@afercia In the post editor:

1. Select a block.
2. Press Tab.
3. Focus should land in the block settings.
4. Try the same in the site editor.
5. Focus does not land in block settings as they need to be expanded first.

[afercia]

@alexstine I guess that is because the Settings panel is already open in your editor.

The point here is whether the Settings panle should expand automatically upon block selection. Right now, it doesn't.

• Close the Settings panel.
• Select a block.
• Press Tab.
• Focus lands on a button "Open Document settings". This button is the only content of the Settings landmark region.
• At this point, the Settings panel is not expanded.
• Visually, there is no right sidebar.

[alexstine]

I think it should open automatically. This flow would feel more natural given how the editor experience currently works.

[joedolson]

If it were 100% up to me, it wouldn't be possible to close the settings panel, and it would always be present.

However, since that's not what we have, it is a reasonable question whether selecting a block automatically presumes that the settings for that block should be available. Does editing a paragraph imply that you want access to the controls to change the style of the paragraph? I'm sure that editing more complex blocks does imply that you need access to their settings, but I also think it would be a chaotic experience for blocks to behave differently. Consistency is very important here.

[joedolson]

Reading through the conversation here, one of the points of confusion is whether or not the settings panel is open. @alexstine had it open in the post editor, and reasonably assumed it would have the same behavior in the site editor. However, toggling the settings panel in the post editor has no impact on its visibility in the site editor.

Should these be considered completely separate interfaces, or should they share preferences? The behavior and layout is more consistent if opening the settings panel in one editor also opens it in the other - there'll be less disruption between views as you navigate, and access to block settings will be more direct in this scenario.

[annezazu]

Noting that if the Styles panel gets moved out of the same section as block settings as shown in these designs and the Styles details view gets overhauled with the controls, I imagine this could then function the same way in post and site editor.

[getdave]

Noting that @youknowriad is currently working on unifying the codebases of the Post and Site editors which will hopefully result in behaviour between the two being unified as well.

[creativecoder]

I came across this issue multiple times while working with users this week who were newer to using the Site editor.

A common sequence was

1. Create or open a template
2. At some point, switch to making edits to Global Styles in the right sidebar
3. Click back on the template to add or edit blocks

Because the Global Styles panel remained open in the right sidebar after step 2, individual block settings were easily missed. I think the right sidebar should switch back to the block settings panel after a block is clicked.

[joedolson]

It seems like there are two outstanding issues here, discussed in today's accessibility bug scrub:

1) Synchrony of state between the post editor and the site editor. 2) Whether the sidebar should make assumptions about the user's intent when selecting a block.

For #1, can we get an update on the progress towards synchronizing the code bases? For #2, we think that this may need a trial PR, to see what the impact of automatically opening the block settings would be. I'm concerned it could create some undesirable behaviors in terms of taking away user control of their interface, but I feel like I'd need to actually use it to be sure.

[afercia]

For https://github.com/WordPress/gutenberg/pull/2, we think that this may need a trial PR

I'd totally agree such an important behavior should not make assumptions. This is a case were actual user testing would be greatly beenficial. I'd love to see an A/B user testing with a divers group of users.

[t-hamano]

Synchrony of state between the post editor and the site editor.

I couldn't find a PR on this, but in the latest Gutenberg, the open/close state of the block settings sidebar should already be consistent between the post editor and the site editor.

[jeryj]

For 2, we think that this may need a trial PR, to see what the impact of automatically opening the block settings would be. I'm concerned it could create some undesirable behaviors in terms of taking away user control of their interface, but I feel like I'd need to actually use it to be sure.

Here's an experimental trial PR: https://github.com/WordPress/gutenberg/pull/63632

I have not thoroughly tested it, so it may not work as described, but I think it will be good enough to see how it is in practice.