Establish a consistent pattern for navigation buttons that open sub-panels

[afercia]

Description

In the Site editor, some settings panels have sub-panels (drill-down menus in design jargon). The controls to open these sub-panels are usually NavigationButtonAsItem components (under the hod it's a Navigator.Button).

Some of these buttons do show a chevron icon to visually communicate they open a drill-down menu. Some don't.

It's not that clear to me what the criteria is to determine which buttons should show a chevron and which ones should not.

There may be reasons why some don't but I'd tend to think a chevron icon adds value as it makes the user experiences more predictable and communicates well what's going to happen when clicking one of these buttons.

There are other minor inconsistencies, for example some of these buttons have a border. Some don't.
I do realize the navigation buttons that are grouped in a set of logically related items need to be styled a bit differently. Still, the lack of a chevron icon introduces inconsistency and doesn't help predictability.

A few examples:

The following navigation buttons show a chevron icon:

• Styles > Colors > Edit palette
• Styles > Typography > Font size presets
• Styles > Browse styles
• Styles > Blocks
• Styles > Additional CSS

The following navigation buttons do not show a chevron icon:

• Styles root menu: Typography, Colors, Background, Shadows, Layout.
• Styles > Typography > Elements

The buttons undeer 'Elements' are particularly confusing to me. They look like the fonts ones above. However, the fonts ones open a modal dialog while the Elements ones open a drill-down menu. They basically look the same, but they do different things.

One more example:

• The custom shadows navigation buttons don't show a chevron icon. It's particularly confusing when there's only one custom shadow:

I'd like to propose to use a chevron icon for all the buttons that open a drill-down menu.
Also i'd suggest to consider some more consistency about borders and margins.

Step-by-step reproduction instructions

N/A
See the examples in the Site editor > Styles panel

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[afercia]

Re: borders around the items: quoting @jameskoster from #66476 (comment)

I lean towards no strokes, because the 'contained' style feels better suited when items in the list are directly related to one another, e.g. managing shadow styles or font size presets.

I would agree that borders should either be used with some consistent meaning ot not be used at all.

What about:

• Use borders to separate items that are not logically grouped e.g. the items in the root of the menu: Typography, Colors, background...
• Do not use borders, and maybe use a border around the group, for items that are logically grouped.

[jameskoster]

I agree it would be beneficial to tidy this up. There's a lot to cover, so when we arrive at a satisfactory design we might start by documenting this on Storybook as a source of truth before implementation.

Use borders to separate items that are not logically grouped e.g. the items in the root of the menu: Typography, Colors, background...

The two 'types' of groups identified make sense, but in this case I would just use no borders. It seems to me the expectation is that menu items are unrelated unless otherwise indicated by the UI.

For instance adding a stroke to the container helps indicate the relationship of the children, and is a common existing pattern.

Other considerations:

• Should we use the smaller chevron icon (like in the navigation sidebar)? This might help indicate at the decorative nature of this element.
• Should the chevron only appear on hover/focus to avoid adding unnecessary noise to the UI?

[afercia]

For instance adding a stroke to the container helps indicate the relationship of the children

I'd agree a border around items visually suggests they're logically grouped items.
A order between items should be used to visually communicate they're logically separated.

[jameskoster]

I don't think we need to explicitly indicate both cases. If a border on the container denotes the relationship of the children, then the absence of a border inherently indicates the opposite, with clearer visual distinction.

Let's see what @WordPress/gutenberg-design thinks though.

[jasmussen]

Chevron to indicate drilldown makes sense, and related items in an itemgroup (bordered) could similarly have chevrons. In the case of fonts, though, these open a modal, so they should probably not have the chevron.

[jameskoster]

@jasmussen we're discussing patterns that indicate when drilldown items are directly related (e.g. font size presets) versus those that are not (e.g. top level menu items). Examples in #66448 (comment).

Also:

• Should we use the smaller chevron icon (like in the navigation sidebar)? This might help indicate at the decorative nature of this element.
• Should the chevron only appear on hover/focus to avoid adding unnecessary noise to the UI?

[auareyou]

It seems the immediate accessible solution here would be to add chevrons (or another clear affordance) that make the drill-down behavior obvious to everyone. However, if adding chevrons to all buttons introduces too much visual noise—which I agree it does—it might be worth reconsidering the overall visual language around settings.

For instance, if we take the Typography roles list as an example, perhaps changes could happen in place with a different type of control, such as a select menu, an accordion, or another component that doesn’t pull users away from the main view of the typography panel.

Looking at industry standards in other design and development tools, the inspector panel typically keeps sections corresponding to the user’s selection always visible. Advanced settings or drill-downs often occur within popovers, reducing the number of "round trips" while still allowing for focused interactions.

Example from Figma:

Example from Webflow:

[jasmussen]

Nice one. Yep, the flyouts are useful, and often used in conjunction with the ItemGroup. Some of the challenge lies in the cases where a drilldown/sub-panel is already in use: what's the best pattern for those?

Absent larger undertakings, showing the drilldown on hover seems a good immediate path forward for those.

[matt-west]

+1 to adding chevrons to indicate a drill-down. Making these visible on hover/focus makes sense to avoid unnecessary visual noise.

Do we need the border to visually group related items? There’s usually a header that communicates the items are related.

Examples:

[afercia]

Making these visible on hover/focus makes sense

I would recommend against making the chevrons only visible on hover/focus. Some users do use devices and technologies that don't use hover/focus. Voice control or speech recognition software, for example. Cognitive load is also impacted with information that is only shown on hover/focus. Providing an equivalent experience to all users is a principle of inclusivity and accessibility and it should prevail on the argument of making the UI 'cleaner', which is highly subjective.

[fcoveram]

+1 to show the chevron icon to indicate drill-down. And I second @afercia suggestion of not hiding it on hover/focus.

[jarekmorawski]

I agree that we should show the chevron icon at all times, not just on hover/focus. Otherwise, it may not be clear to some users that they're drilldowns; it's like making a door handle magically appear only when you're about to leave the room.

The icon will also help differentiate drilldowns from buttons that open popovers (like the background image button in the Group block in the editor), which could become a problem should we decide to consolidate the appearance of such elements across the whole UI.

[afercia]

Related to the ItemGroup styling and the discussion about borders to indicate grouping / separation, it's worth reminding that other components don't use the ItemGroup directly but they do emulate its styling. For example, the color settings:

Related to the ongoing discussion on #58936

[afercia]

Also relevant: #55730

In teh Inserter, navigational items that open sub-panels now show the chevron icon only on hover/focus and as indication of the selected state. That's one more inconsistency.

[jameskoster]

Cognitive load is also impacted with information that is only shown on hover/focus

I think it can be argued that this goes both ways. Once you're familiar with the behviours of the UI, certain visual cues risk becoming unwelcome distractions.

I'm not against making the chevrons permanently visible, but I wonder if we can reduce their relative prominence a little, in an accessible way. For instance using the small chevron icon variant (like we do in the dark sidebar), or a lighter color, or both.

I'm also curious about how this should be managed in a sustainable way. Do we need a new component?

[afercia]

I wouldn't be opposed to try a smaller icon. The current one looks big indeed. Can we use an icon where the actual glyph is 24 by 24 pixels? It's not a strict requirement, I'm just borrowing it from the WCAG target size, but I can't think to any other reference to determine how bic an icon should be to be perceived by everyone regardless of ability.

[jameskoster]

I fear a 24px glyph would look comically large and entirely out of proportion with the rest of the UI 🙈

[afercia]

I fear a 24px glyph would look comically large and entirely out of proportion with the rest of the UI 🙈

Ouch, yes, I see 😿 Hm then I would say the icon glyph should be no smaller than the uppercase font?

[afercia]

One more inconsistency is for the list of blocks in Styles > Blocks. They do open a drill-down sup-panel but there's no visual indication at all that they are navigational items:

[jameskoster]

Extracting from the conversation in #55730; Let's talk about vertical tabs. Specifically, should tabs be treated the same way as drilldowns whereby the chevron is permanently visible?

Arguments for showing the chevron permanently

Vertical tabs function similarly to drilldowns (e.g., loading or navigating to a new panel or view), so using the same icon could establish a consistent expectation for how the interaction works.

When users encounter tabs and drilldowns within the same interface, consistency in icon usage can reduce cognitive load. For example, they might associate the chevron with "navigating into related content" universally.

Arguments against

Drilldowns represent hierarchical navigation where selecting an option moves the user deeper into a structure, potentially hiding the current view.

Meanwhile, tabs typically represent parallel and equally accessible content sections. A user clicks a tab, and content changes in the same view without implying hierarchy or navigation depth. Adding a chevron to the tabs might incorrectly suggest hierarchical navigation or a drilldown behavior, which is not the case.

Icons are an important visual cue but should match the underlying behavior. If the chevron is used inconsistently or inappropriately, it could lead to confusion for users relying on visual scanning or assistive technologies that describe icons.

---

On balance I think I would prefer to treat tabs differently to drilldowns; only show the icon on hover/focus/active states. I'd even consider using a different shape to avoid confusion with drilldowns. There could be opportunity for closer alignment between horizontal / vertical tab treatment. Rough sketch:

[afercia]

Thanks for your thorough analysis @jameskoster. To me, the underlying problem is that the current workings of the vertical tabs with no tabpanel open by default resambles the interaction model of a drilldown menu. Of course there are differences as you pointed out.

consistent expectation for how the interaction works

In the above scenario, the interaction works similarly to a drilldown menu. As such, I would say the expectation should be made consistent by providing a similar visual indication.

However, the vertical tabs with no tabpanel open by default is fundamentally a broken pattern. It shouldn't be used that way. Tabs should have a tabpanel open by default. In this case, a chevron icon would be inappropriate. Rather, the design itself of the tabs/tabpanels should make clear the expected interaction. I would argue that the current 'light' design of the tabs could be reconsidered because they don't look like tabs. Please excuse the crudity of the screenshot below, it's just to illustrate how the design itself of the active tab and the active tabpanel should make clear what the expected interaction is:

[jameskoster]

that the current workings of the vertical tabs with no tabpanel open by default

For the purpose of this discussion I think we should put that to one side. It is a separate issue relating specifically to the Inserter. When making decisions about the components we should assume appropriate use. In other words, assuming a panel is visible by default, how does that change your thinking on this, do you still feel the chevrons should be permanently visible?

[afercia]

Well, assuming the Tabs component is used appropriately with a tabpanel open by default, no the chevron wouldn't be appropriate. However, I'd still love to see improvements to the Tabs component design to make the expected interaction clearer.

[afercia]

To illustrate: this is an example from the current Tabs in the preferences dialog. The chevron for hover/focus/selected doesn't make this UI look like a tabbed interface and I wouldn't expect the Tabs interaction model to work here. As you pointed out, a good UI should establish a consistent expectation for how the interaction works. Which doesn't appear to be the case here:

[jameskoster]

Thanks for clarifying. So in terms of this issue we don't need to change anything about the Tabs component. Separately we might consider:

1. Updating Tabs behavior in the Inserter to ensure a tab is selected by default, or use a different component.
2. Update Tab visual design (more cohesion between vertical/horizontal, more 'tab-like' appearance).

Feel free to open new issues to discuss those details.

---

Going back to the drilldowns, unless I'm mistaken there seems to be consensus around;

• Show chevrons permanently.
• Use the chevronRightSmall icon.
• Try a lighter (but still accessible) color ($gray-700).

Want to update the issue/labels to make this actionable, or did I miss something?

[afercia]

Separately we might consider:

1. Updating Tabs behavior in the Inserter to ensure a tab is selected by default, or use a different component.
2. Update Tab visual design (more cohesion between vertical/horizontal, more 'tab-like' appearance).

Yes I'd agree those should be addressed separately. Thanks for summarizing the action points @jameskoster.
I'd appreciate follow-up issues to be created and prioritised with some decently high priority as the Tabs UI is a pretty important UI in the editor.