Navigator iterations: Selection and focus

[adamziel]

The problem

This continues the discussion about selection and focus started in #22089 (comment)

At the moment clicking on an item in BlockNavigation selects the block in the editor area. This was the original goal of the BlockNavigation and it feels natural in the post editor:

On the menu management screen this behavior does not feel natural to me at all - especially if you primarily use the keyboard. On that screen, the BlockNavigation is no longer supposed to be a shortcut to find the proper block in the editor area. Instead, it's became a kind of an editor itself - it allows you to move the block around, duplicate/delete/copy it, edit the label, and so on. Once the focus is inside of the BlockNavigation, it only makes sense to keep it there. Transferring it to the editor area is confusing and a little bit frustrating:

(which also means we should change the name BlockNavigation or use a different component)

I found it pretty hard to make progress on the ellipsis menu (#22089) without clarity on the details of selection/focus interactions. We know that moving the focus over to the editor area is confusing, but what exactly should happen? This affects many of the explored navigator features such as duplicating/removing/clicking an item, editing the label, or editing the link.

The explorations

I played with selecting the navigator item AND corresponding editor area block on single click, and enabling the edit mode inside of the navigator on double click.

Mouse interactions seemed pretty natural. Keyboard navigation still need a good equivalent of a double click. Perhaps pressing the enter for the first time = selection, pressing enter for the second time = edit mode?

Also, as you can see on the gif above, it's possible to use the keyboard to focus on a non-active/selected item. Here's an experiment where a related editor area block is automatically selected when the focus shifts in the navigator:

And then I thought - maybe we don't need to synchronize the selection with the editor at all if the navigator is supposed to provide most or all of the editor features (editing the label and link, moving the block, duplicating, and so on). Here's how that looks like:

In this scenario, a single enter would enable the edit mode.

cc @karmatosed @tellthemachines @noisysocks @draganescu @talldan

[adamziel]

I moved the part about the BlockEditor into it's own issue #22706

[gziolo]

What is the primary reason for making Navigation structure so powerful? Why user would prefer it over the block edit interface?

In many ways, the screencast shared resembles the experience from Customizer where you need to use the sidebar to edit content. My biggest worry is that people would have this parallel in mind when using this interface.

[draganescu]

You do hit a nail in the head @gziolo. The problem is that the block interface is not well adjusted for structured tree data, and all block nesting is basically a tree. Manipulating the tree in a WYSIWYG UI is cumbersome compared to a bird's eye view of that tree.

The reason of the ever increasing features for the navigator is the "while we're here" problem, which means that if you'd use the navigator for manipulating the block nesting tree you might want or need to do a set of related actions from the same place: rename a label, duplicate a block, add a block and so on.

[gziolo]

Manipulating the tree in a WYSIWYG UI is cumbersome compared to a bird's eye view of that tree.

Yes, it's true. Is there any major blocker that prevents from having the same tree view inside the block editor canvas?

[karmatosed]

@gziolo I don't want to steer to far from the focus of this issue, but yes there are a few reasons. The biggest is that the existing nav-menus.php uses this section for adding, therefore repurposing this area for navigator does make sense. In the original explorations, there were some that used just a single column, however it was decided this route was a nice interim step. That's not to say it's not something to consider iterating again, just framing.

I do think there's a difference though between using the block as tree view and using the interface in the editor canvas. We've tried both in the evolutions of navigation - it's been a journey and one we're all still on.

Perhaps we can focus however on what problem we are trying to solve now and iterate in the existing interface, I'm reluctant to right now jump into yet another brand new exploration.

My vote is for a single enter doing an edit. If we, however, do find that the block navigator is becoming a full editor now that feels a wrong experience, I don't see that right now, but open to that problem.

I'm going to loop in @enriquesanchez as want to be very sure of unexpected keyboard interactions as this potentially is something we're laying traps for.

[ZebulanStanphill]

Having the tree view display on screen simultaneously with the standard editor canvas is convenient, because you can do things like highlight the block you're hovering in the tree view in the editor canvas, which gives you an idea of what block you're interacting with. Without that info, it becomes a lot more difficult to tell the difference between 20 blocks of the same type.

Existing page builders like Divi, Elementor, and Oxygen all have similar interfaces, which are always shown as a persistent modal or sidebar meant to be used alongside the standard editing canvas.

Without a doubt, there's a need for a direct, tree-based view for manipulating blocks. In a lot of the nested block situations, the parent blocks have little to no padding, so they are effectively invisible on the page. The footer breadcrumbs only show a very narrow view of the immediate hierarchy, with no info about siblings and their children. (Speaking of which, after turning the block navigator into a tree/list view for block manipulation, I think we could remove the footer breadcrumbs.)

It is really frustrating to try and move things between Groups and other parent blocks in the block editor. Because the Groups are mostly invisible, it's difficult to tell when you're dragging something into a Group or right above/below it. A tree/list view solves that by making it extremely clear where blocks are in relation to each other.

[enriquesanchez]

Thanks for the ping @karmatosed 👍

Once the focus is inside of the BlockNavigation, it only makes sense to keep it there. Transferring it to the editor area is confusing and a little bit frustrating.

@adamziel I agree with you. Focus should not jump unexpectedly.

maybe we don't need to synchronize the selection with the editor at all if the navigator is supposed to provide most or all of the editor feature

This scenario feels right to me and aligns with the expectations from tests we did in the past. It also provides a much clearer sense of place, because focus is (visually) only on one element at a time.