Navigation menu block: Explore horizontal move controls

[sarahmonster]

From #16821

Refine the horizontally aligned inner blocks.
Explore how this pattern can extend to other blocks like button, columns, etc.
Improve how child blocks perform in narrow spaces.

Exploring the problem

Problem:

Since the block interface has primarily been designed with a stacked vertical alignment in mind, there isn't a good mechanism for manipulating items that are aligned side-by-side. Users need a way of manipulating blocks when they're horizontally, rather than vertically, aligned.

How we determine if the solution has succeeded:

@mtias @mapk @karmatosed How did you want to select the best solution here? Some ideas:

• Run lightweight usability testing
• Take a group consensus / dot voting
• Determine a decider responsible for selecting the best path forward

Potential roadblocks:

We'll want to design this first and foremost for users who don't have access to drag and drop. How do we allow keyboard and screen reader users to easily rearrange elements without drag-and-drop? Drag and drop controls should still be available as an additive functionality.

Controls need to be large enough to allow for reasonable touch target size. What's "reasonable" differs in context, so let's aim to at least provide what the vertical movers allow for, which looks to be 28×24 on desktop, 36x30 on mobile.

Obviously we'll also need to apply this pattern to mobile interfaces as well, which adds an additional layer of complexity.

We'll also want to consider these controls insofar as they impact #16580, since this may determine how we move forward here.

Original controls

Our original explorations centred primarily around the placement of the arrow mover controls. Due to time constraints, these explorations were shared only in Figma and in Slack discussions, so I'm revisiting those explorations now.

For reference, this is the pattern that we eventually landed on:

We also included a whole set of advanced move controls, to take into account accessibility needs and allow for quicker reordering of potentially complex menus:

Usability testing indicated that this was a pretty straightforward pattern. Both new and existing Gutenberg users were able to easily understand how to move and rearrange their menu items.

Explorations

I've updated our original explorations using the new menu block design from #16974, and combining with some of the explorations from #16580.

Current (no background) styling:

Border-box styling:

Inversed:

Mobile is pretty straightforward:

Your feedback

1. Which of these options seems like it would be most intuitive for users?
2. Are there alternative options we should consider here?
3. Are there accessibility concerns with any of these solutions?
4. Does consideration of horizontal movers impact our approach to Block Mover: Try cleaning up the control UI #16580 at all?
5. Do we want to provide a mechanism for more complex block movement options, as per the original designs?

Next steps

Once we've narrowed the explorations down a bit, we can investigate how those different options might work when applied to different blocks to better test these approaches. The styling of the mover buttons is likely to impact which layout options work best here though, so we may want to wait until #16580 has a clear resolution before moving forward.

From #16821, we'll also want to look at

Improve how child blocks perform in narrow spaces.

@mtias, @mapk could you clarify what you mean here so I can be sure to address it?

[ZebulanStanphill]

Splitting the mover controls seems like a bad idea from an accessibility tab-order viewpoint in my opinion, and in most cases it just looks weird.

Having the controls stick out like a flag from the left border of the block also feels weird.

I think it would make the most sense to either use the same position as vertical movers (similar to how the position would be the same for either type on mobile), or put the controls on the bottom.

[karmatosed]

I have a few thoughts buzzing around about this but going to start by answering what you outline for feedback:

Which of these options seems like it would be most intuitive for users?

I have to say all of them for me add a cognitive load to the experience, I don't want to choose one right now as think we can explore through why we are doing this and how. More in next answer.

Are there alternative options we should consider here?

I wonder if we need to explore how drag and drop could work or layering controls. As you are moving do you also need to see the other controls? I wonder if you don't. Here is a super rough sketch, but what if as you were in moving state, the toolbar changed?

Do we want to provide a mechanism for more complex block movement options, as per the original designs?

I think we should consider how simple this could be, or at least what can we boil it down to and iterate?

[sarahmonster]

I'm certainly not opposed to removing the toolbar when the move controls are enabled. A few thoughts to consider:

1. Do we implement the same pattern for vertical move controls? It might be odd if the toolbar disappears only for horizontally-oriented blocks.
2. How does one enter the "moving state"?
3. How does this impact users of assistive software?
4. Usability testing has indicated that sometimes users struggle to find the (current, horizontal) move controls. Would hiding the toolbar for all move interactions help with this problem? Do we need to reveal a visual mechanism to switch between modes? (This may help make 2 and 3 more explicit, but it does so at the expense of the addition of more controls to learn.)

I'd love explore drag and drop as an additive control, once we've sorted out the interaction pattern for users who don't have access to drag and drop (users of assistive technology, users on a mobile device). Our usability testing did indicate that people wanted to use drag and drop to reorder menu items, although they did figure out the move controls relatively easily, even when they weren't familiar with Gutenberg. My expectation here is that the drag and drop would behave the exact same way it does with vertically-aligned blocks, so that the interaction pattern would be consistent throughout—ultimately, I'd anticipate that these horizontal controls should only inherit from the existing patterns set by the vertical controls.

I'm fine with stripping out the complex block movement options, but if I recall correctly, we designed these to take into account those with accessibility needs or who aren't able to use drag and drop for whatever reason. There was also some feedback that people in the community wanted to have more granular controls for reordering large or complex menus. From my research, I'd say that extremely complex menus with a lot of items aren't the typical case, so it's certainly something we could look into adding at a later juncture, but I'd love to get some feedback from an accessibility perspective on that one.

[sarahmonster]

Following a discussion in Slack today (Note: You may need a Slack account to log in.), it seems that none of the options presented are good to work from.

I was working from the assumption that we'd want to reuse the existing control pattern used by horizontal movers, but we clarified that that isn't the case. Instead, we want to try introducing a completely new pattern for horizontal move controls.

Given that time is of the essence here, we agreed to work from these mockups:

and iterate directly in code. (cc @draganescu)

If that doesn't work and we need to go back to the drawing board. Here are some suggestions for areas to explore further, if needs be:

• Put controls into the ellipsis menu.
• Put controls in the toolbar.
• Put controls inside of the block itself (inline).

For the moment, since we're going to move directly to prototyping and iterating in code, this issue can be closed.