Feature Request - UX - Expand/Collapse subtree on double click on a List View item

[tresorama]

What problem does this address?

When working with a lot of nested blocks, expanding and collapsing subtree is suboptimal because you need to "precisely" click on the Chevron icon at the left side of the block name.

Double Clicking on an item doesn't do anything, so the "double click" keybinding is "free" to use...

It's personal preference but maybe other folks have the same expectation when double-clicking on items.

What is your proposed solution?

As a personal preference, I'd like that when double-clicking an item, like ...

... the subtree is expanded like ...

... and on double clicking again the subtree collapse (close).

[tresorama]

In the #51327 PR (great work by @torounit) it has emerged that on another PR #42605 a "rename" block feature is "booked" to be assigned to double click shortcut. The rename feature is currently a work in progress and is tracked at #42605 .

---

It's also emerged that the "rename" feature should have more priority due to be intuitive for a non-power user. In contrast with "expand/collapse" which could be used by a more "developer-ish" audience.

I would expect that double click would be to rename. Expand the entire tree feels like a power user level feature and so it would be ok to have this behind a modifier key requirement.

Originally posted by @getdave in https://github.com/WordPress/gutenberg/issues/51327#issuecomment-1582606060

So It could be ideal to consider the double click shortcut to be assigned to "rename" in the near future, and because of this migrate "expand/collapse" to something like ctrl + click / cmd + click.

[JosVelasco]

Since expanding/collapsing is more common than renaming, I would prefer to use the three-dot options menu at the end of each block to add an option for renaming.

Double click makes more sense to me to expand/collapse.

[getdave]

Pinging @WordPress/gutenberg-design for their thoughts.

The question is should the "double-click" action on the List View:

• expand/collapse a entire tree section (including all children)?
• allow for renaming the node (as per https://github.com/WordPress/gutenberg/pull/42605)?

[paaljoachim]

I very much agree with @JosVelasco Jos

Since expanding/collapsing is more common than renaming, I would prefer to use the three-dot options menu at the end of each block to add an option for renaming.

Double click makes more sense to me to expand/collapse.

On my Mac I double click a folder to open it. Double clicking to open something feels more natural compared to double clicking to rename. Having the rename in the three dot options menu is a good place to have it.

---

In regards to custom labeling/naming. It would be most helpful to have this automatic. Having the first certain amount of characters used be seen next to the block icon. If there is a need to rename then one can click the 3 dot options menu to do so. As I believe I would not spend a lot of time renaming blocks through the List View. Having it automatic would be very helpful and save time as well as make it easier at a quick glance to see what is what in List View.

[jasmussen]

I lean towards the Figma model which is to click the chevron to open. It works well there because clicking an item in the canvas focuses, expands, and scrolls in to view the block you selected, keeping the list view panel all the more resilient. Also, because at this point we're using the list view in quite a few different contexts, including the navigation inspector (where single-clicking offers a drilldown), and site view:

It also doesn't feel like standard behavior to me. In the MacOS finder with tree view, double-clicking opens the file, it doesn't expand the tree.

Ultimately for me it's not a strong opinion to maintain that behavior. The list view is meant as a quality of life structural tool and it's good to refine with power user options. However we have quite a list of tasks on our table to improve drag and drop, and combined with the dual behavior the list view having drilldown behaviors on single click in some cases, I worry that if we start implementing this now, it'll end up adding complexity on an interface that is still a bit in flux and largely buggy. So I would put this one in the followup category, once the base component is a bit more resilient. What do you think?

[paaljoachim]

I worry that if we start implementing this now, it'll end up adding complexity on an interface that is still a bit in flux and largely buggy. So I would put this one in the followup category, once the base component is a bit more resilient. What do you think?

That is a very good point!

[richtabor]

I lean towards the Figma model which is to click the chevron to open.

Agreed.