-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
List View Design Updates #24029
Comments
Lots of thought went into this! Thanks, @shaunandrews.
Further explorations
|
Looks very very cool |
Some quick thoughts: Likes:
Dislikes:
Other:
|
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 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:
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. |
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. |
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:
-- 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 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. |
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. |
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: |
This is just so awesome! |
You're in luck! I created a PR for some of these updates over here: #24419 |
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 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. |
I'm not super familiar with the use-cases for
The buttons in that PR are 36px squares. |
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 |
@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? |
@talldan yep I know and that's what I meant above by:
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. |
@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:
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:
Also from https://sarahmhigley.com/writing/grids-part1/ The one issue I'm still struggling to understand is the suggestion to not use
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
Is it because this is not tabular data? If that is the case, then a
But what about the interactive controls inside each row? |
@enriquesanchez what you're missing is that the 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. |
On the idea of adding extra features like the Moers, More menu, etc.), please see my comment on the Draft PR: #22113 (comment) |
As I don't currently see any PRs in progress to address the Issues raised here I'm going to move this back to |
We have most of this implemented. Let's open more concrete issues for any remaining bits (ellipsis menu affordances, isolated mode, etc). |
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.
The text was updated successfully, but these errors were encountered: