Site Editing: Persistent block navigator and hover indications on the Canvas

[jameskoster]

In light of #27271, I think it might be worth bringing these new interactions to the block navigator, and making that panel persistent in the Site Editor.

The subject of making the block navigator persistent was discussed at length in #22113 with generally positive sentiment.

But the conversation veered off to explore things like adding blocks directly in the navigator, dragging blocks from the inserter in to the navigator, and dragging existing blocks in the navigator around as well. All valuable explorations, but perhaps a little 'in the weeds', and too far away from the original proposition.

I'd like to bring that conversation back around to simply making the panel persistent, and synchronising the hover treatment with those merged in #27271

I think this would be particularly helpful in the Site Editing context since template editing exercises frequently involve interactions with heavily nested blocks, and selecting those blocks on the Canvas (even with the outline helpers) can sometimes be quite frustrating.

From there we can potentially explore more complex interactions like those mentioned above, and the list view enhancements detailed here: #24029

If it works well in the Site Editor we can consider bringing it to the content editor as well.

[youknowriad]

I think this needs some thinking about how keyboard interactions work. So far we haven't been able to find a good model for things like persistent sidebars. The compromise we landed on is using a popover behavior which means the sidebar closes itself as soon as the "focus" leaves the sidebar making it non-persistent. cc @folletto

[jameskoster]

Why does it need to close when the focus shifts to the Canvas? 🤔 Here's what I was thinking:

• Ctrl+Alt+O opens the block navigator and focusses the first block in the tree
• ▲ / ▼ cycles focus through the blocks in the navigator, and toggles the is-hovered class on the associated block on the canvas
• Return shifts focus to the associated block on the Canvas, and toggles an is-selected class on the block in the navigator
• Ctrl+Alt+O returns focus to the navigator, and focusses the block that was selected on the Canvas (if there was one)

[jameskoster]

Since this is a must have for 5.7 I think we can probably move to dev now. I would be interested to hear more a11y considerations, but hope we can tackle any such issues that arise during implementation.

[SchneiderSam]

@jameskoster Oh, that are amazing news! Thanks so much!!!

[sarahricker]

@jameskoster Let's chat a11y as you move this into dev!

[mtias]

@alexstine mentioned in another thread the affordance of Ctrl+Enter to transfer focus. In this case, since we don't have the duality of "add block" / "add block and focus that block" it seems that Enter on its own could also transfer focus. However, that means we'd have two panels with a different behaviour (Inserter and List View). My impression is being consistent here would be useful.

[alexstine]

@mtias At minimum, maybe it would be a good idea to support both. Would that complicate things too much? Users will be used to CTRL+Enter if it's something we stick with and then Enter since it's able to work, why not allow it. I see no issue with that as long as for sure there's one global that works everywhere.

Thanks.

[mtias]

Yes, this makes sense. The only caveat would be if there's some reasonable task to do upon selection within the list view panel — like reorder, etc.