Improve the UI of the Navigation block display section

[javierarce]

The current interface of Navigation block display section is quite convoluted.

Because the preview sits on top of the section, if the user selects "Mobile" or "Always" in the segment control and then expands the preview, the main setting gets pushed to the bottom, making the UI confusing.

See initial proposal

I propose we switch the order of the setting and tweak the height of the preview and the size of the X icon:

This enhancement will also help us address this feature request to customize the labels:

---

Proposed design for implementation (2022-09-13)

Design - Prototype

Proposed position on the sidebar

[mtias]

I think the preview being an interactive element is a bit of an obscure interaction, so improving that would be useful. Instead of a toggle for "Use icons" can we try another segmented control that says "Icon / Text" that toggles between the options? I'm not sure we should allow picking the menu and close set ups separately, it seems to add a bunch of cognitive complexity.

Also, when the label is set, we should probably allow further customization (typography, border, etc).

[javierarce]

I agree with you about the preview being problematic. Here's an iteration based on your feedback:

• The preview is expanded using a simple toggle
• We use a segment control to choose between icon and text modes
• The segment control acts as the labels for the components below
• Prototype

Also, when the label is set, we should probably allow further customization (typography, border, etc).

Since we have typography and color settings in other sections of this block, I understand you mean that you want to allow customizing these labels independently from the rest of the menu, right? But wouldn't that make things more complicated?

[javierarce]

Added a final iteration based on @jasmussen suggestion: instead of a toggle, use the settings icon as we do in other sections.

[jasmussen]

Wanted to note that for now we've removed the two ellipses from the icon options. (Let's explore a couple of excellent replacements, not necessarily as part of this PR, just noting)

[javierarce]

Thanks, @jasmussen, I've updated the design in Figma and in the issue description to reflect that change.

[javierarce]

I updated the original issue above to show the proposed position of this section in the sidebar: currently, we show the Display section under Layout and Menu, but it should appear above Layout since Display defines the basic appearance and behaviour of the navigation.

[getdave]

@aaronrobertshaw Are you aware of a way we can force the Display section to appear above the Layout section? I know you worked a lot on InspectorControls grouping and tabs. Any help appreciated 🙇‍♂️

[getdave]

@SaxonF It would be worth adding this to tasks to complete in 6.3 - are you happy with the design proposed above?

Reorganising this sidebar a bit may well improve user interactions with key tasks. Currently it feels way too focused on advanced controls such as layout where I expect that 80% of user interactions will be for:

• color
• overlay menu settings

[SaxonF]

@getdave Looks good to me. I'd personally like to see layout grouped with dimensions, which this issue looks at, so the positioning question might not be an issue anymore.

[aaronrobertshaw]

Thanks for the ping @getdave 👍

Are you aware of a way we can force the Display section to appear above the Layout section?

Both the Nav block's Display panel, and the Layout block support panel, render to the default group for the InspectorControls. There isn't currently any means to order that slot's fills. As the Layout panel is from block supports, I believe that gets added reliably to the fills first, hence its current position.

There could be a couple of options here but none that came to mind were particularly clean or elegant.

1. Add a new InspectorControls group that can be rendered before the default group.
2. Add a new InspectorControls group for layout which can be added after the default group.

Both of those options, leave us open to plugins abusing the top group's slot for promoting their controls beyond the prominence they warrant.

Assuming we can find a means to restrict the use of a new group to only the desired blocks, and only core controls, then option #1 might work.

I'm not sure of its relevance here but there was an old issue (#35541) that evaluated the order of block support panels in the sidebar. So the current order was at least deliberate.

I'd personally like to see layout grouped with dimensions, which #47902 (comment) looks at, so the positioning question might not be an issue anymore.

If Layout was merged with Dimensions and that panel relocated to the Settings tab, we'd avoid the need for a layout group but still face the same decision around allowing the block's default controls (and therefore plugins') above the layout supports.

[jasmussen]

Looks good to me. I'd personally like to see layout grouped with dimensions, which #47902 (comment) looks at, so the positioning question might not be an issue anymore.

I've not had a chance to form deep thoughts here, but if we do consolidate dimension controls in the layout panel, it needs a somewhat solid mockup that considers all the use cases, including how dimensions change depending on the layout type.

[getdave]

Thanks Aaron 👍

Assuming we can find a means to restrict the use of a new group to only the desired blocks, and only core controls, then option #1 might work.

Yes it feels like Core should be able to decide how it wants to order the panels. How to do that....is another question 😄

[aaronrobertshaw]

How to do that....is another question

I haven't looked into it but it would be nice if we could use the lock/unlock feature to make the new InspectorControls group "private" or "core-only".