Navigation menu block: Visual styling

[sarahmonster]

This is intended to splinter conversation from #13690 and allow us to focus the conversation on one part of the problem at a time. We'll loop back to the tracking issue when we've determined a path forward. For this issue, we're focussing on visual styling:

How are menus and menu items presented visually?

[sarahmonster]

After some initial sketching, I explored three different directions for the visual display of the selected menu and menu items. These mockups are still a bit rough and could use finessing once we determine a solution.

The aim here is to map the selected state of the menu as closely as possible to the front-end output so that users can easily understand what they're building and how it will look on their site. This presents some tricky scenarios, most notably with regards to horizontal vs vertical menus.

I've shown both horizontal and vertical menus here, and I'm a bit torn about how best to approach these. In the context of a full-site editor, it would make sense for the selected state of the block to match the frontend output, and it would also make switching focus less jarring and jumpy. That said, changing the layout between horizontal and vertical menus introduces a lot of complexity, especially for multi-level menus, and forces users to learn a slightly different model for building their menus, which may not be ideal. There's also the reordering of items to think about: our current Gutenberg patterns allow for this in an up-to-down way, but not so much in a side-to-side way. Introducing a new pattern here, even if it's just a change in orientation, may introduce cognitive load to an already complex task.

In all of these explorations I've defaulted first to a horizontal menu, since that's the more common usage. I think a horizontal setup could work even on smaller screens (or with larger menus) by fading and then scrolling horizontally:

I've also included:

• a selected menu, with no menu items selected
• a menu with an individual menu item selected
• a menu with an expanded sub-menu

I've also experimented a bit with shifting the [+ Add new item] button depending on the selected menu item, so it's easier to add an item where you want, rather than being forced to add them at the bottom of the page. Again, there are pros and cons to this approach, so it's worth discussing in a bit more detail.

Figma source file

Links

This concept uses plaintext links and a child-block model to surface individual menu items settings:

Pros:

• Visually clean.
• Clear identification with links elsewhere.
• Fits with Gutenberg's overall aesthetic.

Cons:

• Gets messy as complexity is introduced.
• No clear boundaries between items.
• Spacing is less consistent between selected and unselected menu items, potentially leading to jumpyness.

Chips

This one borrows from Material Design's input chip pattern to represent complex information in a compact form:

Pros:

• Leverages an existing pattern rather than creating something new.
• Apparent differentiation between items.
• Effective at fitting information into a small space.
• Allows for quick deletion of menu items (potentially useful depending on how we approach Navigation menu block: Smart defaults #13786).

Cons:

• Non-standard usage: according to Material guidelines, chips "enable user input and verify that input by converting text into chips", but here, we show them as enabling user input while still in chip format. This may be solvable, but we may also be forcing a round peg into a square hole.
• Looks awkward with a vertical layout.
• Probably the most non-Gutenbergy of all the solutions.

Blocks

This one represents navigation items as blocks and simplifies the selected state down to the bare minimum:

Pros:

• Probably the closest representation to the most common front-end output (this is what most menus look like).
• More menu can be leveraged to show additional settings without adding a lot of extra weight.
• Works well both horizontally and vertically.

Cons:

• Simplified settings may diverge a bit too much from established patterns—we may need the heavier child block approach here.

Your thoughts

I'd love some feedback before exploring further:

1. Which of these approaches feels the most natural?
2. Are there critical states I haven't shown here?
3. How do these solutions stack up from an accessibility perspective?

[melchoyce]

1. Which of these approaches feels the most natural?

I think Blocks is the clearest, though also visually the heaviest — might want to explore alternate block colors and borders.

In terms of flexibility, the Links option feels the most extendable and the most neutral of all the options. I imagine in the future, themes that embrace editor styles will have custom styles for this block, and we need to create something that's going to still make sense in those cases.

2. Are there critical states I haven't shown here?

What does selecting a child menu item look like?

[sarahmonster]

I'm definitely leaning toward the Blocks treatment, although I agree with you on the heaviness. I've tried lightening it up and applying a selected/edit state more closely aligned with explorations in #13790:

My concern with the light grey is that it's similar to the visual styling used for placeholders. I'll experiment with a few different solutions here.

What does selecting a child menu item look like?

Pretty weird right now, although I'm going to blame Figma and/or my lack of Figma knowledge:

(These elements should definitely be properly aligned!)

I'll add this to my list to explore a bit more as well.

[melchoyce]

I think that's definitely getting closer.

I wonder if the up/down arrows in the move & drag tool should be left/right on horizontal menus?

[kjellr]

I'm most drawn to the Links variation personally. I appreciate the barebones quality of it, and it's similar visually to other parent/child block situations we're using today. I also really like that it's the least prescriptive from a styles perspective (which I think sets us up well for theme styles later on).

The aim here is to map the selected state of the menu as closely as possible to the front-end output so that users can easily understand what they're building and how it will look on their site.

Menus across the web look and behave very differently. Once themes begin styling this block, I imagine we'll see a lot of variations. Once we move into full-site editing, some themes will likely want to drastically change the menu's appearance on mobile vs. desktop, some will want to expand all menu items, some will want to use dropdowns, etc. It's bound to get very complicated.

Anyway — given that, I do think we have some wiggle room here in terms of how closely the selected state maps to the front end view. We should feel free to move a bit away from a 1:1 representation while in editing mode in order to make interaction a bit easier (we're doing that a bit in In #9628 for example).

In that vein, have we considered having the deselected state be a super-plain Links-style version, but then switching to something like Chips or Blocks when the block is selected? It might be a bit of a jump, but it could help make editing more consistent.

[jwold]

Wow. First, great work on putting this together! This is some serious progress in moving this challenging issue forward. Really loving what has been shown so far.

As I've dove into this problem over the past year, I often come up feeling overwhelmed, thinking that we have to solve all the problems that arise off the bat.

The work that you've shown here addresses many of the issues that could arise. However, I think it's ok to say that we can do this work with limitations. If we can make a decent nav menu that is useful in a lot of cases, then we'll have been successful.

For instance, even in deciding the visual style, we can make the tradeoff of having almost no styling in Gutenberg, and letting the themes decide, or we can go in relatively opinionated and let the themes override it if they see fit.

The win here is making a visual style that works most of the time for a good number of websites. We don't necessarily need to solve a triple or quadruple dropdown, or figure out how mega menus would work. That could come later, or not at all. That's why this is WordPress, if it doesn't make sense to make a mega menu (just picking on this example), I'm sure someone can make a custom block for it.

---

As to the three options presented:

• Links: If we decide that the frontend and backend should have a 1:1 visual representation (I'm not sure that we should), then this one makes a lot of sense. In my mind it's actually closest to what I'm seeing for a lot of WordPress themes. A simple link interface, with the rest of the header allowing for more visual creativity. We could even extend the block later to have a few simple style options: Light or dark text, underline or not, increased spacing between words
• Chips: If we don't have a 1:1 relationship between the frontend and backend, then this feels great. It seems like it would be easy to work with and manipulate.
• Blocks: I like the further explorations of making it lighter. I think we could play with this more and refine it slightly.

Overall any of these options feels like they could work. I'm still not sure if the process of using this will feel intuitive, and guessing a clickable prototype will solve that. Regardless, I'd feel comfortable seeing any of these taken to the next level of fidelity to play with.

[youknowriad]

The block option seems the most sensible to me at first sight because of the different built-in features we get for free. Improvements to selections, re-aranging, border styles can be explored for the innerBlocks.

Also the block option is the best because of its flexibility. How can I add the search block in a menu if it's not using innerBlocks? how can I add a static text to a menu?...

[sarahmonster]

Since design explorations have largely concluded here, I'm closing this ticket as non-actionable, and we can loop back to #13690 or new issues for any further conversation that comes up as development work progresses.

Thanks everyone for all the feedback! 🙌