Navigation Block: sub-menu items design

[mtias]

The design of the sub-menu should correspond to what is shown on the front-end (right now it's a dropdown on hover/focus). The editor is showing just an indented list:

This is a block that should have opinionated styles (assigned to theme.scss) that themes can opt into.

[karmatosed]

💯 for this. I also notice that for example on front it shows extra characters

[getdave]

Can I clarify the intent here:

Are we saying we want the Editor and Theme (front of site) to utilise a common set of "opt in" styles for the Nav Block whichL

1. Ensure it's a horizontal nav on large screens (presumably "stacked" on small screens?).
2. Create dropdown menus for sub items.

Questions:

• what about sub-sub items?
• how do sub menus work/look on small screens?

[retrofox]

for this. I also notice that for example on front it shows extra characters

is it defined by the list-style?

[retrofox]

for this. I also notice that for example on front it shows extra characters

is it defined by the list-style?

No, it is not.

[karmatosed]

Noting the bit 'to do' on this is reflecting in the editor itself.

[karmatosed]

A few points on this. Right now there is some very opinionated styling as default, I am not sure if we reflect that but having a way to avoid this, for example, would be great:

More in: #18830

I wonder could we have something like this:

I think directly having the arrow might be too much as in:

A suggested middle ground would be a white background:

[karmatosed]

If we are making this as much like front as possible, potentially adding + within works:

[apeatling]

Related: #18830

[getdave]

@karmatosed @shaunandrews Just noting that there might be some overlap between this and #18830. Do we need to take account of that and/or update the designs?

[apeatling]

Not sure I follow what you mean here.

I mean matching the new design of the menus in the editor as well as the front end. So that there is greater visual separation between inserters and avoiding the bunching of inserters we currently see.

[retrofox]

by your leave, I'm going to start to work on this. :-D

[frontdevde]

@karmatosed Could you confirm whether the design you shared here #18310 (comment) is ready for implementation?

I'm asking as the issue is still labeled Needs Design Feedback and the design feels quite wireframe-y (which might be the intended look?). I would just like to make sure we have a clear direction of where we're heading before we potentially start implementing a solution that doesn't solve the UX issues.

[karmatosed]

I did intend it to be wireframey as the idea was that we came up with a basic style which would work across as many themes as possible, including dark and light modes. For that reason, I want to avoid things like shadows and too much in-depth styling. It doesn't mean we can't get a tiny bit more opinionated though and I have done some iterations to show states.

Back hover dark

This is a bit heavy but would swap light / dark for a hover.

Back focus dark

This brings in the dark only on focus menu

Back minimal

This brings in link styling from the theme, so that we bring in for example blue in Twenty Nineteen. Hover is simply underline.

Important to note in above the appender only appears when 'in' sub menu and only one shows.

Let's move onto the front now and explore beyond 2 levels deep. I started to explore how this could adapt for multiple. It's worth noting the back end will also have same sub menu styling.

Front all way across

Front second level drop down

Front second level drop down and minimal styling

There are benefits in the last one as more economical on space and also it can be easily styled, with a dark variation easily done.

[shaunandrews]

I think we can simplify even more, reducing the need for the pointers. Here's another take for how the submenus and inserter can work:

When rendered, here's how the navigation submenus would work when hovered:

[mapk]

Looking at these mockups, here's a few thoughts.

1. I like the addition of an arrow in @shaunandrews' mockups for the top level that includes a sub-nav. It's a great visual indicator that there exists a sub-nav.

2. Showing the sub-nav as aligned to the right (and not below) the parent nav item, as proposed in both @karmatosed and @shaunandrews' mockups, feels right and adds visual clarity.

3. Shaun's continuation of the arrow treatment is nice, except it gets a bit tricky at this intersection. Thinking through the block toolbar in relation to the sub-navs gets complex and I'm glad it's being shown here.

[karmatosed]

Regarding the arrow indication, we can merge #18396 maybe into this which is set to bring that in with this iteration - 2 issues with one!

[frontdevde]

@karmatosed @shaunandrews @mapk

Would it be possible to distil the design explorations above into one representational design that we can then implement? Mainly thinking about this in terms of efficiency as it can potentially be quite an effort to rework in code if we walk down the wrong direction. Thank you!

[shaunandrews]

Would it be possible to distil the design explorations above into one representational design that we can then implement.

I think of the GIFs I posted yesterday as a distillation of the previous explorations, and would be what I prefer we implement.

[frontdevde]

I think of the GIFs I posted yesterday as a distillation of the previous explorations, and would be what I prefer we implement.

Thank you for providing us with a clear design decision here. 👍 Just linking to the GIFs we'll implement here again for anyone that didn't follow the thread: #18310 (comment)

[shaunandrews]

If people get wacky, they can keep adding submenus. Those additional submenus should continue to stack onto the right. Here's what it'd look like with another submenu:

[frontdevde]

@shaunandrews

Should the colors selected in the navigation color picker propagate to the submenu? Both from a design perspective but more importantly from a UX perspective: What would the user expect?

Otherwise it would look something like this (light style variation):

Or something like this (dark style variation):

[apeatling]

I think if the top level link color changes the submenu colors as well, you’re going to get clashes because the user does not have control over the background color of the submenus at this point.

It’s better to do light/dark and deal with colors when we can provide full control to users. Otherwise a situation where background color on the top level is light grey, the text color black, and they select the dark style means links in submenus are going to be unreadable.

[retrofox]

Otherwise a situation where background color on the top level is light grey, the text color black, and they select the dark style means links in submenus are going to be unreadable.

Just to be clear about technical implementations. We can propagate the colors of text and background to the sub-items and completely ignore the light/dark styles here, as the primary menu (items in level 0) already does.

[apeatling]

Right, but I don't want to end up in a situation where the nav looks like this with no control over the submenu colors:

[apeatling]

To be clear, although subjectively I don't think the above looks good, if there is control over the submenu colors I think this is a fine outcome.

[shaunandrews]

Should the colors selected in the navigation color picker propagate to the submenu? Both from a design perspective but more importantly from a UX perspective: What would the user expect?

As a user, I would expect the colors to propagate to the submenu. But, I'd probably also expect to be able to change the colors for the submenu independently. However, the current UI gets pretty overwhelming if we add two more color options:

But we could move the submenu color options to the toolbar when a top-level item with children is selected:

--

For now, I think we should just keep the colors tied to the top-level items and look at adding color options for submenus in another PR.

[apeatling]

As a user, I would expect the colors to propagate to the submenu. But, I'd probably also expect to be able to change the colors for the submenu independently.

I think this is the ideal setup, and what we should be aiming for. The light/dark styles were a stop-gap until we could support color changing. By the sounds of it this is causing implementation confusion.

Here's a suggestion building from Shaun's above, please chime in with thoughts:

1. Remove the light/dark style variations
2. Propagate the color changes for background and text through to all submenus
3. Implement and merge the new submenu design with the above two items considered
4. Follow up immediately with support for submenu text and background color changing support

[retrofox]

Here's a suggestion building from Shaun's above, please chime in with thoughts:

1. Remove the light/dark style variations
2. Propagate the color changes for background and text through to all submenus
3. Implement and merge the new submenu design with the above two items considered
4. Follow up immediately with support for submenu text and background color changing support

Sounds like a nice plan. Going to add these points in the PR #19681

[karmatosed]

I like the plan apart from removing light / dark styles beyond a temporary removal. If we bring those back later I would be ok with it as we create the new style.

[retrofox]

We haven't talked about how to apply the border-color for sub-menus. What we did, as an experiment, was applying the same color that the text if it's defined. If not, it will apply the Light/Dark color.
Another option is adding a new border color section in the color selector popover.
Ideas and suggestions are over welcome. Thanks, folks!

[karmatosed]

Could border color just balance off from the base of background? Looping @ItsJonQ in here as know this is something we are exploring in global styles where one style generates other options using CSS variables.

[retrofox]

Could border color just balance off from the base of background?

Do you mean for instance applying a kind of filter or rgba()?

other options using CSS variables.

No IE11 support, then ;-)

An aside note related to this: Using CSS vars would make all these implementations soooooooooo easy

[karmatosed]

@retrofox personally I think for 'additional styling' the support isn't an issue and in #19611 along with other places this has been discussed. It's a case of having a decent baseline so it looks good across all browsers, then extras come if can support.

I do think if we don't go that route them filter or some method of rgba (even opacity) could work. I just think we have to be careful about at least for now not having so many color options it is a confusing interface. If I set a background I would want things to just work out, as a baseline.