List View: Explore Alternatives to TreeGrid

gwwar commented 3 years ago

The List View component is used in several places, and is currently backed by a Tree Grid implementation. A Tree Grid allows for multiple focusable items in a row, but the tradeoff is that the markup and implementation is more complex, making it more difficult to maintain and add features for.

Persistent List View in Site/Post Editor	Navigation block (in all editors)	Widgets List View

Before we get too far in List View Improvements, there was some interest in revisiting if our current approach is more complex than it needs to be.

Some prior discussion mentions the possibility of using a TreeView or a simple List instead.

List View - Features/Requirements?

What types of tasks/flows do we plan on having List View facilitate? One key flow might be helping navigate block structure and complexity, so being able to drag and drop might be one feature. Does this mean that we also need mover controls as a requirement? Do we still plan on allowing folks to perform actions, like inserting/deleting a block?

Favoring one implementation over another is going to depend on if that approach will meet our overall needs.

Folks are also welcome to edit the summary with additional context, if I missed anything.

cc @shaunandrews @jasmussen @talldan @priethor

jasmussen commented 3 years ago

What types of tasks/flows do we plan on having List View facilitate?

When I think of the List View, I think of it as a compressed, abstract representation of the content of your page. Like a layers palette in Figma, this can give a handy overview of what you're looking at, and its hierarchy. Because of that, I also think it will be reasonable to intuit a few behaviors work similarly in the List View as they do for blocks in the canvas.

Dragging and dropping an bock in the list view to reorder items in the canvas:

I imagine the block type indicator would show a drag handle when hovering the item.

We'd also need an ellipsis menu where you could choose a "Move to" option for a keyboard interface:

The chevron for expanding/collapsing container blocks.

There's also already HTML anchor indication in the list view:

I'm still finessing the margins and paddings.

So that's quite a few tools to show, even if most of the time they are contextually hidden.

talldan commented 3 years ago

Just to document it, another option explored for adding functionality to List View was a separate toolbar (inspired by Photoshop's layer's panel, which has a toolbar at the bottom) - https://github.com/WordPress/gutenberg/pull/21372

Some were in favour of exploring that more, others weren't. It definitely makes more sense in the persistent list view panel.

The idea would allow for simplifying the markup to a TreeView. The main thing it'd change is how blocks are selected—List View wouldn't be able to transfer focus to a block on selection as otherwise it'd be really difficult to use the toolbar. A separate toolbar or block settings menu button could be used to jump to a block though.

noisysocks commented 3 years ago

We've also discussed adding actions which are block dependent. For example in https://github.com/WordPress/gutenberg/issues/29148#issuecomment-814941699 @jameskoster describes an Edit template part button that only appears on Template Part blocks.

noisysocks commented 3 years ago

I spent today learning about the options here and playing with a few different approaches.

`treegrid`

The problem with treegrid is that it's really meant for tabular-ish data. Specifically, it's expected that you have an equal number of columns per cell. Right now this is okay for the List View but going forward it seems we will want to have a different number of controls depending on the block type. For example, a Heading block might display its slug or a Template Part block might have an additional Edit template part button.

So, I don't think treegrid is suitable.

`treeview`

Using a treeview makes a lot of sense for the List View since it literally displays a tree! 🌳

For this approach to work we need to have multiple buttons in each treeitem. This lets us have Move up, Move down, and More controls for each block. In theory this should work fine as the spec does not forbid it. In practice, however, I ran into issues with VoiceOver in Safari not announcing any of the buttons in non-leaf treeitems.

You can see what I mean in the first example of this JSFiddle.

So, I don't think treeview is suitable, though I would love for one of my smart colleagues (@tellthemachines) to prove me wrong.

`list`

The last approach I tried was just a regular unordered list.

This works much the same as most site navigations out there on the web so I think it will be pretty familiar for users using screen readers.

It's not quite as nice as using a treeview because, in my testing, VoiceOver in Safari didn't properly announce what level you are at while navigating the tree. Probably I am doing something wrong or we can address this using our own custom aria-labels.

I found that if I wrapped the block's controls (Move up, Move down, etc.) in a <div role="group"> or <div role="menu"> then it made navigating the List View easier as you can skip past the controls which quickly become repetitive. If we find that it's still too repetitive we could also look into using aria-haspopup to hide the block controls from screen readers until a block is selected using the keyboard.

You can see this for yourself in the second example of this JSFiddle.

So, I think a list is boring but probably adequate.

Aside: Keyboard navigation

No matter what markup we use, we should definitely implement support for navigating the List View using the arrow keys. I found that this makes the whole thing feel really intuitive.

This section in one of the W3 examples describes nicely what each arrow key should do in a tree context.

I experimented with adding keyboard navigation to a list in this JSFiddle.

Aside: Useful resources

So that I don't lose them, here are the resources I found most useful while digging into all this:

WordPress / gutenberg