Navigator iterations: ellipsis and movers

[karmatosed]

This is pulling out just the navigator improvements from #21727. This brings also in the movers work, but shows it all together. The illustration here is for the navigator within the navigation block, however, this could apply to any place eventually where it's used.

What this does:

• Ellipsis menu comes in by the navigation element. For now, I brought in 'delete' and 'duplicate'.
• Brings in movers from 5.4.1 Backports #21793

Note, I also brought in an active state that could be explored without.

Exploring moving the +

One potential could be to as @mtias noted in #21727 (comment):

The action to add a sub-menu should be available in the corresponding navigator item (either in the ellipsis menu or as its own button).

During this he also said:

The ellipsis menu in the navigator UI should replicate the block ellipsis menu (duplicate, remove, etc).

You can see the ellipsis being used above, however what the adding could evolve to is explored here:

A benefit of this could be removing completely the + and just having you click to add directly where you are. I really like this idea as it takes away the visual complexity.

Further exploring

A few other options could be:

Making the size wider

Removing icons

It's good to keep the spec for this a little narrow to bring in iterations, so whilst there could be more, for now these bring in what was being explored in a larger issue.

[mapk]

I enjoy watching the iterations happen with this block! These Navigator iterations will be very beneficial.

1. Movers

Brings in movers from #21793

This linked PR appears closed. Was there another one working on including movers?

2. Missing tree structure connector

The mockups above don't include the tree connector like the current iteration. It helps me visually make the connection that this is a sub-tree of a particular item. Can that be added back?

3. Animation

When moving the blocks up or down, it would be great to include animation like we do with blocks. I'm sure this was probably just difficult to achieve with the prototype (and probably on your radar already), but wanted to note this anyways.

4. Similar to a selectbox

For me, this state looks so similar to a selectbox. Is there another iteration that can place the movers side-by-side? This will also allow for a larger tap/click area.

5. Good menu items

The options in the ellipses menu work really well. (ie. Add link, Duplicate, Remove link) I notice that two options have the word "link" and the other doesn't. How do you feel about that? Should just the first item include "link" since it is an option that doesn't apply to the selected subnav link?

[karmatosed]

#21935 is the movers PR, goodness that was a wrong link, fixed now.

The mockups above don't include the tree connector like the current iteration. It helps me visually make the connection that this is a sub-tree of a particular item. Can that be added back?

It can, I sort of prefer it without, if feedback falls on adding back in it can.

Animation can be added for moving them up and down, that's already been in progress in the existing moving PR.

For me, this state looks so similar to a selectbox. Is there another iteration that can place the movers side-by-side? This will also allow for a larger tap/click area.

I don't mind how the movers look but #21935 has them as I mocked, whatever is decided there can reflect here. As a note the original implementation is side by side, so it's just a case of adding the ellipsis to whatever settles.

Regarding the word link, I on reflection would be happy for it to just say 'remove' and avoid the word link full stop.

[mtias]

For the ellipsis menu we should aim at replicating the exact menu that the block provides already (with its shortcuts) to the point of technically reusing the same component. I noticed we don't have the "insert before" and "insert after" actions on child elements here. We should figure out why they aren't. cc @talldan

[manmotive]

These designs look good! To me, the hierarchy looks clearer with the tree structure connectors. It would be interesting to see how it looks with menu items with long titles, and for deeper menus (5+ levels).

I realise I may be thinking a long way ahead here, but plugin/theme developers will need a way to extend the options for menu items (in a similar way to https://make.wordpress.org/core/2020/02/25/wordpress-5-4-introduces-new-hooks-to-add-custom-fields-to-menu-items/), and this looks like the most suitable place to add new options. Can this be kept in mind whilst developing this feature?

[adamziel]

It can, I sort of prefer it without, if feedback falls on adding back in it can.

Just chiming in - I prefer it with the connectors, the hierarchy seems cleaner to me that way.

[adamziel]

Also, #21948 makes the navigator items customizable using slots - merging it would pave the way forward for some early prototypes of this feature.

[karmatosed]

As the conversation seems to be more or less agreeing in way forward, let's mark this for development. There are some refinements can be discussed, but that shouldn't stop us moving into producing. Thanks everyone.

[talldan]

#18014 is the PR where I've been working (for a long time) on adding the movers.

The blocks are animated when they move 👍

The main difference at the moment is that the mover buttons are side by side in that PR. I have a feeling they might be too small if implemented on stacked like they are in the design.

These designs look good! To me, the hierarchy looks clearer with the tree structure connectors. It would be interesting to see how it looks with menu items with long titles, and for deeper menus (5+ levels).

This is a good point and would be good to explore separately. Making it possible to expand/collapse parts of the tree might be one way to help improve that.

[talldan]

@karmatosed @mapk I put together an experimental PR to try the stacked movers in block navigation instead of having them side-by-side - #22314.

To me, the buttons seem too small, and also keyboard navigation was also confusing in this configuration.

The issue with the buttons being small seems to be exacerbated by there potentially being other movers in very close proximity on the row above and below. It's pretty easy to mis-click.

[talldan]

I noticed we don't have the "insert before" and "insert after" actions on child elements here.

@mtias These actions seem to insert the default block, which isn't insertable in the Navigation Block.

A good fix would be to borrow the appender logic and check whether only a single block type is insertable, and if so that could be used.

[mtias]

@talldan yes, that would make sense. It's a function that should be available in social-icons, buttons, etc. But we can make a separate issue for it.

[adamziel]

This PR explores the ellipsis menu itself: #22427

[adamziel]

Today I merged #22427 which means we now have a very simple version of the ellipsis menu. It also surfaced a conceptual issue.

In the post editor, the block navigation makes it easy to reach a deeply nested block. You just click on the navigator item you're interested in, and magically the block becomes selected in the editor.

In the experimental navigation screen navigation items are editable, which means that clicking on them allows you to type right where you clicked, but the related block in the editor does not become selected.

How is it related to the ellipsis menu you ask? Let's take a look at the "Duplicate" option.

If you duplicate the block using the ellipsis menu in the block toolbar, a new navigation item block is immediately created and selected. This is expected, and a good user experience.

If you duplicate the block using the ellipsis menu in the block navigation, a new navigation item block is immediately created and selected. This is unexpected, as the focus is shifted from the block navigation over to the editor area.

I have been exploring possible solutions to the focus problem here #22524, but then @youknowriad made me realize we have a bigger issue here. Namely: What purpose does the block navigation serve on the experimental nav-menus page?

My understanding is that the original name "block navigation" comes from the fact that it allows you to easily navigate to blocks. This is not the case on our menu management page - block navigation items aren't buttons, instead they are <RichText /> components that make it possible to edit the link text. This means that the primary use case of this component have changed.

I think we should choose one model and stick to it. Let's either make make the navigation selection-oriented or editing-oriented, but let's not mix the two. If we make it selection oriented, then we are bound to run into situations where users are moved over to the editor area. If we make it editing-oriented, then let's discuss how that would look like. For example, the selection in the block navigation could be completely separate from the idea of selected block.

CC @karmatosed @mtias @draganescu @talldan @noisysocks @tellthemachines @mapk @manmotive

[talldan]

I agree we've approached a conceptual issue. I do think we should try to make sure that the block navigation interface is (eventually) consistent on all forms of the block editor, so need to consider what the experience will be like in the post editor too.

An issue I've noticed at the moment is that some blocks are editable, and some blocks are selectable, and the difference isn't made clear to a user. At the moment this isn't very visible on the navigation menu page, but it'd be a much bigger issue if we moved the changes to the post editor where there's a wider variety of blocks.

Not every block will be editable in the block navigation interface, so that inconsistency makes me think that the primary interactions of the interface should be built around navigating and organising, things useful for every kind of block. That doesn't mean that editing couldn't be possible, but maybe it should be secondary, like an option in the new settings menu.

I do also think the way selecting works is becoming an issue. That clicking or selecting a block transfers focus out of the block navigation means that the other tools being added (block movers, block settings menu) are harder to access. I did wonder if blocks should only be highlighted in the main editing interface when chosen in the block navigation, similar to how the highlighting works in navigation mode. I could imagine a Select block option in the settings menu (at the risk of making the settings menu really big) for actually jumping to the block.

[mtias]

"Block navigator" is a name we should probably aim to drop at some point — it's just how this particular interface started. What we are dealing with is a different representation of blocks (block tree) compared to the rendering of edit (standard view). This representation can support different interactions based on context (props of the block tree). Also, selection and focus are related but not the same concepts. Selecting a block in the block tree should probably not always transfer focus to the main block editor even though it still selects a block (showing borders, etc). We might support things like pressing enter to go into edit mode (in the main view).

That doesn't mean that editing couldn't be possible, but maybe it should be secondary, like an option in the new settings menu.

Probably, yes. I think using rich text for the label was worth trying but if it starts to get too complicated, an "Edit" in the ellipsis menu could make sense. (This is also why double-long-click exists on OSes for editing file names :P )

[karmatosed]

Looping in the work going on in #22497 here as relevant. I agree that adding an edit link makes a lot of sense.

[ZebulanStanphill]

@mtias It's worth noting what existing page builders call their similar interfaces.

Elementor also has something similar which they simply call Navigator. However, I agree that's probably not the right term for this interface anymore. (I think "Block Navigator" would definitely be less confusing than "Block Navigation", though.)

Divi has a similar interface which they call Layers View. I don't think "layers" is quite the right term, but the "___ view" naming might be the right terminology.

[adamziel]

That's a lot of good notes, thank y'all! I made the navigator items non-editable for now. Let's look into making them editable based on a user action soon some time soon.

[mtias]

@ZebulanStanphill yes, indeed. When we first did this feature I thought "Outline" was a good differentiator, but we had used it just for headings already. I think something like "List View" might be ok-ish.

[adamziel]

I think these two issues may have to be resolved before making more progress here: #22706 #22705

[ZebulanStanphill]

@mtias "List view" is definitely the best potential label I've heard so far. 👍

[draganescu]

So #22427 has brought the ellipsis menu to the items in the navigator, but the issue is that we're still uncertain on what items should this menu include and how does #22656 (adding other kinds of blocks to the navigation menu) affect this menu as well.

cc @mtias

[adamziel]

I think these two issues may have to be resolved before making more progress here: #22706 #22705

These two are resolved by now:

• The navigator selection is now completely separated from the editor selection.
• For the time being, it probably doesn't make sense to bring the navigator into the editor

[adamziel]

This issue is almost there, see an actual screenshot:

The only remaining thing is making a final decision about the specific menu items. At the moment, the same 5 items are being displayed in every navigator ellipsis menu (see the screenshot above). Should there be any more? If so, what should they be? If we wanted to offer the same actions as in the block toolbar, there would need to be an "Edit link" menu item, what would it do? "Transform block" doesn't make sense to me either. "Add submenu" is taken care of by the inserter. The only useful one I am able to come up with is "edit label", but it's not clear what it would do for other types of blocks like the search form. Maybe the menu on the screenshot above is good enough already and this issue could be closed?

CC @talldan @shaunandrews @draganescu @mtias

[draganescu]

Let's close this issue. Since we have a menu implemented in the navigator any required items in that menu will be tied to the issues they are part of.