Gutenberg: List View Design Updates

[shaunandrews]

The List View (a.k.a. the block navigator) is used in a few places as a way to see an overview of blocks, and their general hierarchy and types. You've most likely used the List View (in a popover) from the editor's toolbar:

The Navigation block offers another way to access the List View (in a modal!) directly from the block's toolbar:

Related to this is the ongoing work on the (experimental) navigation screen, which uses a variation of the List View with some special enhancements like movers, and adding blocks:

--

As we add more functionality and consider moving the primary List View interaction from a popover, to a sidebar (#22113), I'd like to update the design a little and clean things up.

Reduce overall size

In general, I find the current size of list items to be too large. With more than a few blocks in the list, it quickly grows longer than the height of my browser window. In an effort to increase the number of items visible at once I'd like to reduce the size of the blocks from 48px down to 36px.

Nested block indentation

Nested blocks are becoming more and more _normal_, especially with full site editing becoming a reality. The current list view displays a series of lines along with an indentation for nested block. In an effort to reduce visual complexity and reserve horizontal space I'd like to remove the lines and focus more on indentation as an indicator of nested blocks.

(It should be noted that there likely will need to be further consideration for deeply nested blocks, as outlined in #23583.)

The actual size of the block in the list is consistent regardless of it's parent. Nested blocks are the same size as their parent, but their icon and title are indented based on their level of nesting. This means that the clickable _hit area_ of the block is the same throughout the list. This is perhaps more evident in the GIF below:

Toggle child blocks

Having nested block visible at all times can lead to an overwhelming list of blocks, making it difficult to find blocks in the list. Adding a way to toggle a block's children can help add focus to a potentially long list. The toggle also serves as an indicator that a block _has_ children.

The toggle button can be clicked independent of selecting the block. However, selecting a block would also force the toggle open and displaying a block's children.

Movers and More menu

Some variations of the list view already have movers and a more menu (the Navigation block modal, and the Navigation screen), so this isn't new so much as exposing them in all instances of the list view. The More menu would mirror the existing More menu from the block toolbar. Both the Movers and the More menu would be hidden by default, appearing when a block is _focused_, _selected_, or _hovered_.

Since the list view is not a visual representation of blocks, there will only ever be vertical movers — even when the visual display of blocks might suggestion horizontal movers.

Focus border

When the block in the list is focused, it should have the normal blue border encapsulating the entire list item. When focus is moved to one of the inner buttons within the block (Toggle, Movers, More) the focus border should encapsulate only those buttons.

Add blocks

Both the Navigation block and the Navigation screen allow for adding blocks directly from the list view. The add button appears at the bottom of the selected _level_ in the hierarchy of blocks. For example, if no block is selected (the document is selected) then the add button appears at the very bottom of the list. If a block that is capable of nested is selected, then the add button appears nested under this block, below any children.

[mapk]

Lots of thought went into this! Thanks, @shaunandrews.

• I agree, the line-height of each block was too large. Good call minimizing that.
• The triangle icon indicating nested blocks feels really tiny and its proximity to the block type icon is too tight. I wonder if just allowing more padding between it and the block type icon would help?
• The indentation of a nested block is also difficult for my eyes to discern accurately, especially when looking at something like this:

• Without the tree connecting lines, I think the indentation should be a little larger.
• I love that no matter how indented the nested block is, the whole bar is still clickable!

Further explorations

• How does drag and dropping fit into this? Does it?
• Will there be a time when I can move my block outside the parent block from within the List View? Should that be allowed?

[SchneiderSam]

Looks very very cool

[ZebulanStanphill]

Some quick thoughts:

Likes:

• Being able to collapse and not show the children of a block is a great idea. Divi Builder's Layers View has this.
• Removing the visible lines and relying on visual indentation is probably a good idea.
• I really like the idea of the appender to add blocks.

Dislikes:

• Small buttons are bad for accessibility. The mover buttons in the current block toolbar design are already considered by the accessibility team to be rather small. The ones in your List View mockups would be even worse in that regard. I strongly suggest unstacking them. Remember, everything should be comfortable to use with a touchscreen.
• And ellipsis is supposed to represent "more controls", and so it should be the last thing in a group of controls. The movers should come before it, not after. Remember, everything should be placed in a logical order for keyboard + screen reader users.
• The icon to indicate showing/hiding children should just be a chevron like the existing accordions throughout the editor. However, this would be confusing next to the movers which use the same icons. This is indicative of a larger issue that remains unaddressed, though: we need unique icons for up/down versus expand/collapse.

Other:

• The indentation for child blocks may need some adjusting. It feels a bit too small. I do realize that deeply nested blocks may be an issue, but that will have to be dealt with either way.

[MichaelArestad]

I think this is already worth trying out as proposed. I'd like to get this into a PR so we can get a feel for it and make changes as needed.

• We can finesse the indent in the PR (in context with actual blocks).
• The mover arrows face the same problems as in the Block Toolbar and whatever ends up being the resolution there could likely be used here. I would rather not focus on it on this issue, but rather in a focused followup PR.
• We could try a new accordion icon here if needed. I don't think it's a dealbreaker.

[talldan]

We discussed the design changes in the navigation triage (https://wordpress.slack.com/archives/C02RQBWTW/p1595402238050400).

Just wanted to mention some of the previous explorations on this, as I think a couple of aspects have already been discussed or tried. I think the main points are:

• The horizontal ellipsis icon was one of the iterations tried when it was implemented, but not used because it's wider than the vertical ellipsis. As the items in the list become more indented, horizontal space becomes limited, so the narrower icon button is beneficial. (https://github.com/WordPress/gutenberg/pull/22427#issuecomment-631279353)
• I definitely agree the rows do seem big. Shorter rows have been tried, but the stacked mover buttons become too small. 16px isn't enough for a touch target. The situation in List View is also worse than the block toolbar because of the close proximity of mover buttons on the rows above and below as well. (https://github.com/WordPress/gutenberg/pull/22314#issuecomment-635790113, https://github.com/WordPress/gutenberg/pull/22796#issuecomment-638024569)

cc @jasmussen, as he seems to have made those comments 😄

Probably the icon isn't a massive issue, but I definitely feel the movers is a recurring problem that we seem to be bumping up against. There's a desire to maintain consistency with the block toolbar, but also this is a smaller space.

[jasmussen]

Yep, 24x24 feels like a good baseline for "smallest button size", and it's the reason why rows are 48px tall, so as to accommodate those above and below each other.

One way to address this is to allow them to overlap. That is, the clickable hit are remains 24x24 and 48px stacked, but the buttons technically overlap adjacent menu items. This, however, would not work well with those items being available on hover, so this solution might be good to pair with showing those items only _on select_. Which seems fine to me, as it matches how blocks behave.

[shaunandrews]

Thanks for the feedback everyone. I've worked up another design iteration and created a draft PR to experiment with these changes in code.

Some quick notes:

• I've updated the designs to use the vertical ellipsis (#23889)
• In order to keep the smaller height of the rows, I've uncoupled the Mover controls and placed them side-by-side. They only appear when a block is selected.
• I've increased the size of the expand/collapse toggle, and kept the _new_ triangle icon in the designs.
• Adding blocks from within the popover is a little weird. It makes more sense in the sidebar. In general I'm thinking that adding blocks from this UI might only make sense in scenarios like the Navigation screen.
• In some scenarios its a little weird to have duplicated movers and another more menu when a block appears both in the list view and on the canvas. We already restrict Movers to the Navigation screen. I think this is something we'll get a better feel for in the PR.
• I briefly explored how to handle _deeply nested blocks_, adding a button that goes "down" a level in the list along with a button to go back.

--

Here's a few other explorations I did that I don't think worked out, or are a bit of a tangent to this issue:

I was looking at reducing the visual overhead, and thought about reducing or removing the icons:

I wondered about showing more information:

I looked at variations for the select and focus state:

[jasmussen]

I do miss the stacked movers, and the connector lines on sublevels. But probably fine to try this out in implementation. Let's look at using that triangle for accordions also.

[SchneiderSam]

As target group here is my short feedback: I use the List View very often. The implementations mentioned here are really very useful. I am looking forward to it.

[shaunandrews]

Here's a look at how drag-and-drop (#23952) could work for the List View:

When you tap-and-drag a block it follows the same pattern as drag-and-drop in the canvas; The block itself is removed from the list and a drag indicator is now attached to your pointer. In the List View, the currently select block should visually change to avoid having two large, dark elements on the screen at once.

As you move the block around a blue line indicates where the block will be place when you _drop_ it.

--

When dropping a block _on top_ of a parent block (like Group, Cover, Columns, etc) the moved block is added to the bottom of the parent. You could also hold a block _on top_ of a parent block — without dropping — to expand the row and show nested blocks, allowing you to better control _where_ the block is dropped.

When dropping a block _on top_ of a non-grouped block (like Paragraph, Post Author, etc) a new Group is created, with the moved block added to the bottom.

Some blocks are restricted in their movement; A social icon block can only exist _inside_ a Social Icons block. When dragging blocks, restricted drop targets are shown greyed out and disabled:

[paaljoachim]

This is just so awesome!
I too look forward to testing this out. With a hands-on one gets a feeling for how it works. Getting this as an experiment into Gutenberg will help a lot and bring it out so people can easily test it.

[shaunandrews]

You're in luck! I created a PR for some of these updates over here: https://github.com/WordPress/gutenberg/pull/24419

[afercia]

From a technical perspective, this should be implemented with an ARIA tree view pattern: https://www.w3.org/TR/wai-aria-practices-1.1/#TreeView see also the different implementation examples there.

Noting that the _current_ block navigation in WP 5.5 uses a treegrid role instead and I'm not sure that's correct as there's no "grid" in this UI.

The additional controls to display for each tree item are in a way unexpected in the tree view pattern so this part should be thoroughly tested with various browsers / assistive technology combos.

I'd totally second @ZebulanStanphill feedback to not "squeeze" UI controls just because there's a limited space. Buttons need to be bigger, especially the movers one.

Regarding the mover buttons, one more thing I find confusing is that although they're now stacked vertically, keyboard navigation works with the left and right arrow keys, which is unexpected: I see controls arranged _verticallly_ but in order to use them with the keyboard I have to use the _horizontal_ keys. To me, this is one more reason to review the design change of the mover buttons and revert them to two normal-size buttons arranged horizontally.

[shaunandrews]

Noting that the current block navigation in WP 5.5 uses a treegrid role instead and I'm not sure that's correct as there's no "grid" in this UI.

I'm not super familiar with the use-cases for treegrid vs. the tree view pattern. I've been playing with these design changes in #24419 — I think there might be a grid here? You'll notice the movers are placed side-by-side next to the more button; With the current treegrid you can move between controls very quickly:

not "squeeze" UI controls just because there's a limited space. Buttons need to be bigger, especially the movers one.

The buttons in that PR are 36px squares.

[afercia]

I'm not super familiar with the use-cases for treegrid vs. the tree view pattern

In the link I shared above you will find _detailed_ explanations of the expected interaction and _working examples_ for both the tree view and tree grid design patterns.

Roughly, a "grid" is closer to a table but it's interactive. A "tree grid" combines the concepts of grid and tree together. However, the "grid" pattern is very debated amongst a11y specialist and I'm not sure I'd recommend its usage. Reference: https://adrianroselli.com/2020/07/aria-grid-as-an-anti-pattern.html

[talldan]

@afercia One thing that the treeview pattern examples don't detail is how to access multiple focusable elements in the same row, which is why treegrid was implemented instead.

Any suggestions on how that can be achieved?

[afercia]

@talldan yep I know and that's what I meant above by:

The additional controls to display for each tree item are in a way unexpected in the tree view pattern so this part should be thoroughly tested with various browsers / assistive technology combos.

I still think the treegrid role is not correct. I none of treegrid or treeview can be used then we should explore a different solution. Also, did you read the post by Adrian Roselli? Highly recommended to understand why the concept of "grid" is problematic.

[enriquesanchez]

@afercia Thanks for the links you shared above. It was a very informative read.

After reading them, it sounds to me that we are not on the wrong path by choosing to follow the ARIA grid pattern:

If the primary purpose is to provide an interface for the user to edit, manipulate, or otherwise interact with the content it presents, then it leans towards being a grid.

_From https://sarahmhigley.com/writing/grids-part1/_

This is an interactive set of rows that have ordering buttons and settings within each. The keyboard navigation pattern that the grid brings seems to be more efficient for this kind of content:

If a control is primarily intended to enable a user action or set of actions, it's more likely that a user will spend most of their time moving between and interacting with controls within the grid. In that case, efficiency in moving keyboard focus has a high priority.

_Also from https://sarahmhigley.com/writing/grids-part1/_

---

The one issue I'm still struggling to understand is the suggestion to not use treegrid. I too have the same comment as @talldan above:

One thing that the treeview pattern examples don't detail is how to access multiple focusable elements in the same row, which is why treegrid was implemented instead.

Knowing that the contents of each row are interactive, and this UI is representing a hierarchy (parent and children), I assume it aligns to the definition of treegrid:

A treegrid widget presents a hierarchical data grid consisting of tabular information that is editable or interactive.

Is it because this is not tabular data? If that is the case, then a tree view seems to be worth looking at?

A tree view widget presents a hierarchical list. Any item in the hierarchy may have child items, and items that have children may be expanded or collapsed to show or hide the children. For example, in a file system navigator that uses a tree view to display folders and files, an item representing a folder can be expanded to reveal the contents of the folder, which may be files, folders, or both.

But what about the interactive controls inside each row?

[afercia]

@enriquesanchez what you're missing is that the gridcell itself is supposed to be the interactive element, not its content. See https://www.w3.org/TR/wai-aria-1.1/#gridcell

More or less, conceptually, like an editable table cell.

Also, a big concern is the actual support by assistive technologies which is, at best, "partial". See https://a11ysupport.io/tech/aria/grid_role. Warning: highly technical reference.

[afercia]

On the idea of adding extra features like the Moers, More menu, etc.), please see my comment on the Draft PR: https://github.com/WordPress/gutenberg/issues/22113#issuecomment-693438571