Widgets page: make the "Block navigation" tool provide full correct info on the widgets

[afercia]

Describe the bug

In the new Widgets page, the "Block navigation" tool doesn't seem to provide meaningful info on the used widgets.

Also, its content appears to be "contextual" based on the selected widgets area, which is confusing. While this behaviro is similar to the one of the Bock navigation in the block editor, I'm not sure it's ideal for the Widgets page (honestly, I'm not sure it's ideal for the block editor as well).

To reproduce

• add 3 "legacy" widgets in a widgets area:
  • Pages
  • Meta
  • Recent Posts
• click "Update"
• make sure the widgets area is selected
• click the Block navigation button: a panel opens
• the panel displays only the selected widget area and the tree of the active widgets within it
• the tree displays a generic name "Legacy Widget (Experimental)" for all the three widgets

This doesn't help users to get an overview of what the actual widgets are. Also, it doesn't help navigating the content: worth reminding the "Block navigation" is also a tool that allows navigation by jumping to the content corresponding to the button that has been clicked. How users are supposed to be able to jump to the relevant content if the widgets aren't clearly identified?

Second issue:

• click on an empty widget area (in my case, Footer Add/local build #2 is the empty one)
• open the Block navigation again
• the panel now displays the available widgets areas plus the "inactive widget" area
• Footer Add/local build #2 is selected

This is very confusing to me, because the panel content changed. Also, there's no way to expand the Footer #1 tree. Actually, what is represented in this scenario isn't a tree: it's a list.

• same when clicking on an empty area of the page e.g. the grey background
• the panel displays the available widgets areas plus the "inactive widget" area (no area is selected)

I do realize this behavior is the same of the Block navigation in the block editor. However, I think it's confusing in this context.

Overall, I'd tend to think the Block navigation tends to be too "smart" with its contextual behavior. I'm not sure users are getting a great benefit from this smart behavior.

More importantly, since it's a navigation tool I'd expect the Block navigation to allow to display the whole tree of the content at any time, and allow me to jump to any of the "blocks", whether they're in the selected area or not.

I'd like to suggest to reconsider this implementation also in the context of the block editor.

[afercia]

Related: #24566

[mapk]

I hear ya! This does get a bit witty causing perhaps some confusion. However, this doesn't appear to be concerning the Widget Editor only... this is how it works in the Block Editor (post editor) too. I know @shaunandrews has been working on some new List View redesigns and it might make sense to carry over your comments there: #24029

[afercia]

Thanks for the info. There's a difference though. The implementation in the block editor is already released. Instead, this is a new feature landing in WordPress so I'd expect it to be prioritized and fixed for the 5.6 release.

[draganescu]

@talldan is this something that ListView will support? I remember we had some plans about displaying more info on each item besides the block's type. Also @adamziel mentioned that using variations of the LegacyBlock could solve the 1st part.

[talldan]

@draganescu If you have the name of the widget in an attribute, it can be output in List View using the __experimentalLabel block setting pretty easily:
https://github.com/WordPress/gutenberg/blob/master/packages/block-library/src/navigation-link/index.js#L70

If that data isn't available client side then unfortunately things will be a bit more complicated.

[mapk]

Looks like we have a dev solution figured out for issue 1.

As for issue 2, it appears to have been a purposeful decision to show full layout of high level blocks when nothing is selected or, in the case of the Widget Screen, when a Widget Area is selected. If a parent block with nested blocks is selected that becomes the top level for which the List View shows.
I'm fairly certain that additions to the List View in the Navigation screen will be ported over to this List View as well which will include things like movers, dragging, etc.
So issue 2 doesn't appear to be a bug, but rather a design decision by those involved in the List View.

Let's move this to dev. :)

[talldan]

For issue there's now a PR - #26138.

For issue 2, I did a quick experiment and showing all blocks gets out of hand pretty quickly:

I feel like we need the expand/collapse feature in List View to solve this.

[garretthyder]

I would suggest we only have the current sidebar section expanded and collapse the rest until click at which point they open and the previous closes.

[talldan]

I made a separate, brief issue for expanding/collapsing as this wasn't being tracked - #26141

If there are other ideas I think we can either comment on that issue or here.