Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Navigation menu block: Reuse existing design patterns for menu item controls #16974
Exploring the problem
Introducing a new pattern just for the navigation menu item block controls forces users to learn a new pattern that isn't reusable elsewhere, potentially leading to confusion.
How we determine if the solution has succeeded:
Whatever we land on needs to allow for vertical and horizontal rearranging in a relatively small space. (This will be explored in more depth next, but it's worth keeping in mind here since it will impact things here.)
We also don't want to lose all the work we did in the accessibility walkthroughs. How do we allow keyboard and screen reader users to easily move elements without drag-and-drop?
A refresher on the original designs we landed on. These tested well with users but represent a new pattern for users to learn, since they use custom controls.
Gallery style controls
Following the inner-block pattern used here by the gallery block allows us to keep things a bit more visually simple whilst still avoiding introduction of a new pattern.
This allows us to also extend these changes to the gallery block, should galleries need more advanced controls. We can use a custom ellipsis dropdown for advanced move controls, and move the simple (back/forward) move controls directly into the block controls, keeping things more streamlined.
Technically, the gallery isn't a good example to copy—we aren't providing controls for a block, but rather an item inside a block. But this is a technical distinction. Do users know or care about this distinction? Is it important to their understanding and mental model of how the system works?
The Block Toolbar
This was modelled after the columns block, which uses blocks inside blocks. The columns block is sort of notoriously hard to use (I keep getting the + icon jumping all around and all over the place whilst trying to use it.) I'm a bit concerned this may become extremely difficult to work with when we'll have a whole lot of pretty small blocks closely aligned.
Can we add anything to the ellipsis menu if we follow this approach? Do we need an extra flyout to represent advanced move controls? Do we need to drop advanced move controls, or move them to a sidebar, neither of which feels like a super accessible solution.
Thanks for breaking this out, @sarahmonster! I really dig the explorations.
Right off the bat, I'm immediately pulled to the Block Toolbar option. The familiar pattern of blocks within blocks just works for me here. I also imagine it would be helpful to see the dotted borders of the parent/nested blocks as worked on here: #14961
This sounds like a great opportunity to figure out within the context of the Nav block and extend to the Columns block.
Great point. If several of the nav items are 4 letters long, this could be lots of small blocks. Do we use flexbox to equally spread them regardless of the length of word? Should we allow the unselected inner block to size down to the word, while the selected inner block expands to allow editing? I don't like that latter option, but raised it anyways.
I'd say, "yes". I figure you're asking this because of the options like
Probably not if they work well within the ellipses dropdown.
Thanks for presenting the three options.
I think we'll get to a point where we can have child blocks for each gallery item, which will bring a few consistent interactions for free — like drag and drop to reorder, individual control over an image link, etc.
I'll follow up with some mockups of my own for the third option (block toolbar).
The main reasons for following standard block patterns are both familiarity to users but also that it would force us to solve design problems more systematically. If narrow nested contexts are suffering interaction wise, we can solve that generally and improve the experience of not just our core blocks but any 3rd party blocks.
This can be reflected already in some general concerns:
One idea I have for simplifying toolbar handling in nested contexts is to optionally allow an inner block container to say that it wants to absorb the toolbar of all the children. In those cases, selecting a child block within that area would change the toolbar content but it would be positioned at the level of the parent. This could be really useful for the navigation menu block, as selecting different items would remain coherent while offering specific tools for the right contexts. cc @jasmussen
The main block is the Navigation block. It defines the menu area and contains all the menu items. This is already the case in all previous presentations, so let's dive into some of the details.
A crucial aspect here is that I think we need to make the block navigator front and center as a viable interaction pattern for this block, as with complicated nested structures it might offer the best and most clear organization. Particularly relevant would be implementing #11408.
The other aspect is that this block needs to be dynamic. (#16810.)
Link (Child Block)
The only child block allowed under Navigation is the Link block (or Menu Item). It is inserted automatically when pressing the
One thing I'm interested here is evaluating if a Link block can be something we make available in general to be inserted anywhere. The main aspect is that it keeps a tight relationship with a site property (unless link is custom), so that updates to a site domain, permalink structure, etc, would naturally work.
The main interactions here would be adding a new item (expose existing pages, posts, categories, etc) and editing an existing one. The text label should be directly editable always. The relationship to an existing site property (a page, a post, a category view, etc) should be made extremely clear to the user as well, either in the toolbar, the inspector, or both.
Nested menus are going to be tricky because we'll have a permanent tension between faithfully representing the front-end and optimizing for managing complex menu structures. This will be generally at odds. That's why I think leveraging the block navigator is going to be crucial for managing this elegantly and efficiently.
That said, we should still find ways to present things directly on the canvas the best way we can. Selecting an item that has children, could automatically show them, for example, or we could have a toggle.
This is definitely tricky to get right, and I hope we can receive a lot of divergent explorations on what this might look like. But I do strongly agree that if we can find a consistent pattern for this, it will benefit every single block.
One ingredient for starters, could be a solid solution to #16681. Another ingredient is to reduce the surface area of the "mover" component. Right now it includes a draggable handle, which has been necessary in the current design. But if there was a way we could improve how drag and drop worked to not need an explicit handle like this, it would simplify the component a fair bit.
I'm unsure if it could work, but if it could, here are some quick and dirty mockups along that vein. Vertical:
I am really keen on using child blocks for this and love to simplified explorations. I will also add I think using existing patterns is absolutely the right option.
The idea the toolbar changes I think has the potential for other instances moving on if this happens for navigation. Just to add a point, contextually adapting could open up a lot of potentials and know it's been floated around a fair bit recently as an idea. I really like it as a concept, moving forward.
For me, a block transformation seems sensible there.
I am torn on this one. I can see a stress case for repeat use but the pattern of reusable blocks is a strong one to lean on.
I really think the minimum is:
I feel we can lean on link searching for this.
Yes! I really like the idea we offer that.
Yes, so much!
I sort of really like the horizontal variation for movement, this could help with layouts.
Thanks for sharing those additional mockups, @mtias! Very helpful!
For me, I think it's a block property because Transforms seem to transform one block into another somewhat different block. Changing layout doesn't warrant a transform. For example, take a look at the Posts block.
I'd agree that the reusable block paradigm would be the good route here. Here's an example of how the current reusable pattern works when trying to create a nav within it.
I like this idea. Let's make the inner blocks as simple as possible by moving what we can to the parent block.
I think a couple of these might work well in a Nav block placeholder/setup screen. When adding that block to the page, there could be a couple options; 1) Select existing nav to convert to this block, 2) Use all top level pages, 3) Start anew with a blank nav.
I agree. A toggle in the sidebar might do well.
Yes. I remember the original did promote "Search" as the primary choice, but there was thought around a "Browse" tab as well. I don't remember if this was mocked up or not though. Presenting top-level pages in addition to search might be a good exploration.
Very true. I'd like to follow a similar pattern to how we do the Category block today with the "dropdown" option toggled "on." Basically you can click to open the dropdown, but clicking any of the links in the dropdown won't do anything. Example below.
In regards to my comment above...
Here's an example of what I was thinking. It's not the best wording, but something visual to think through.
Since there's a lot of different pieces to unpack here and more exploration needed on different parts of the problem, let's aim for moving some of the conversations to the relevant issues:
I'd encourage us to think of this question, not from a technical perspective, but from a user's perspective. As a user, is a horizontal menu the same as a vertical menu, or are they different? I'm not entirely certain of the answer here, but my hunch would be that they're the same—they're just styled differently.
The original proposal included a mock up of the browse interface, but suggested search as a primary action:
I'd love to see us move away from the named menu paradigm. The majority of users aren't likely to need to insert the same menu in multiple places—you add a menu to your site header, you're good to go. Using reusable blocks seems sensible, especially when this behaviour is unlikely to be the primary use case.
I've updated the mockup here to include the child/parent/sibling dotted borders introduced recently, so we can see how those would impact the visual styling here: