Updates to navigation components in support of Kibana nav redesign

[ryankeairns]

As part of the upcoming initiatives, we were tasked with redesigning Kibana's main navigation to accommodate new workstream-driven info architectures (IA). This redesigned navigation aims to unify the existing main and solution-level navigations into a singular navigation. Here are links to our latest designs:

• Classic cloud prototype (Experimental)
• Classic on-premises prototype (Experimental)

The Platform UX team's proposal largely utilizes functionality from the EuiCollapsibleNav and EuiSideNav components, but it does deviate in a number of key ways as outlined below.

Implementation considerations

Before getting into the design details, there is an open question as to how we proceed with the implementation. Some options that come to mind are:

1. Make no changes to the EUI components, and rely on the shared UX team to override styles and functionality and/or create custom components as needed.
2. Make changes to the EUI components on main.
3. Current thinking 👉 Utilize a feature branch and ship changes as a separate package on npm.
4. Add props with options that accommodate for the differences.
5. Create an entirely new EUI component.

Depending on how we split the work in this issue, we may find that the visual design changes, for example, are safe to push to main. That said, it would be helpful to see them in the flesh and try things out in Kibana before committing to main. With this bit of uncertainty, option 3 seems a good path for trying things on in a low-risk manner.

Currently, there are two nav versions in Kibana. One for the current design and a second that is the beginning of this new design (emphasis on chrome service/API not UI design changes). It may be that Shared UX (i.e. Kibana Eng) want to apply this new/alternative package to only the latter for initial launch.

Suggestion

1. Start with the Emotion conversion for these components
2. Tackle the visual design changes together
3. Proceed to functional enhancements

For item 3, the right-aligned icon is likely to be straightforward and relatively small. The new collapsible design will be the largest of all items in this effort and needs further discussion. Given that, I will mark it as hold until we get final alignment from our Product and UX peers.

Design changes

The sections below provide a component-level comparison of key deviations between the existing EUI components and the newly proposed navigation redesign. At a high level, the tasks can be summarized as follows:

Tasks - Visual design changes

Preview Give feedback

1. EuiCollapsibleNav - remove borders
2. EuiCollapsibleNav - change button styles
3. EuiCollapsibleNav - change accordion arrow icons
4. EuiSideNav- change item styles
5. EuiSideNav - change accordion arrow icons
6. EuiSideNav - change borders on children
7. EuiSideNav - change text color on children
8. EuiSideNav - change bottom padding on parent group

Tasks - Functional enhancements

Preview Give feedback

1. EuiSideNav - Display (optional) right-aligned icon on items
2. ⏸️ HOLD EuiCollapsibleNav - Add new collapsed, icon-only design that uses EuiContextMenu (for this item, first estimate size, then let's discuss if/how to proceed)

EuiCollapsibleNav Differences

Functional enhancements

• EuiCollapsibleNav currently offers a docked option, which allows the navigation to operate similar to a push flyout, where the navigation occupies and shares space with the adjacent body content (rather than being overlaid). As the new navigation designs are planning to absorb the responsibilities of both the current Kibana main navigation and solution-level navigations, we proposed that the new navigation design be an ever-present fixture on the page (almost as if it were permanently docked).

  • In order to give the user control over how much horizontal real estate this ever-present navigation occupies, we wish to allow them to toggle between a collapsed icon-only version of the navigation (the default setting) and a larger expanded navigation.

  

  • In order to allow users to continue to interact with the navigation in the redesigned navigation's proposed collapsed size, we desire the ability to offer an alternative EuiContextMenu-based navigation, which would utilize nested menus to mimic the nested accordions in the larger expanded navigation designs.

  

Visual changes

• EuiCollapsibleNavGroup components appear to have a top border applied to visually separate siblings. The navigation redesign proposes we omit these borders to cut down on the visual noise in situations where many navigation groups are present.

  

• EuiCollapsibleNavGroup button styles in the redesigned navigation propose different hover and current state styles, different padding, and different spacing between icon and title.

  

• The current accordion arrow button within EuiCollapsibleNavGroup appears to take an arrowRight icon and rotate it 90 degrees to achieve the collapsed/expanded accordion effect. While this effect works great for left-aligned accordion arrows, it feels unexpected when right-aligned (which causes the collapsed right-facing arrow to look more like it will open a menu or navigate you forward, rather than open an accordion). The redesigned navigation also uses right-aligned arrows to indicate the accordion state, but instead of directing them right/down, they are down/up (better indicating that the panel will be sliding down or up with the accordion behavior). The designs also propose a smaller arrow icon (12px) and a low contrast color for the arrow when the accordion is closed to avoid visually overwhelming users if a lot of accordions are visible.

  

EuiSideNav Differences

Functional enhancements

• For non-accordion EuiSideNavItem components, the new designs account for the possibility of a right-aligned appended icon. Specifically, this will be used for the low contrast 12px icon indicating an external links in the navigation.

  

Visual changes

• EuiSideNavItem styles in the redesigned navigation propose different hover and current state styles, and different padding.

  

• The current accordion arrow icon that conditionally appears within EuiSideNavItem appears to use hard-coded arrowRight and arrowDown icons to achieve the collapsed/expanded accordion effect. For the same reasons I detail in the EuiCollapsibleNavGroup accordion comments above, the redesigned navigation suggests using arrowDown and arrowUp icons instead. The designs also propose a low contrast color for the arrow when the accordion is closed to avoid visually overwhelming users if a lot of accordions are visible.

  

• When a EuiSideNavItem component with nested items is expanded, we currently show prepended vertical lines and horizontal ticks to help users better visualize the hierarchy of the items in the list. The redesigned navigation maintains this general concept, but alters it slightly by removing the horizontal ticks altogether (to reduce visual noise) and only using the vertical lines to indicate hierarchy. It also aligns the left side of the vertical line with the left edge of the parent text (rather than being kicked in 8px).

• Nested EuiSideNavItem text receives a subdued color currently. In the redesigned navigation, we're proposing that these nested items maintain the standard text color.

• When a EuiSideNavItem component with nested items is expanded, the redesigned navigation proposes adding an additional 16px of spacing at the bottom of the opened accordion to provide addition spacing between the end of the accordion's contents and the next item in the list.

---

EuiBreadcrumbs Differences

➡️ Moved breadcrumb work to #7015

Functional enhancements

• As part of our design explorations in the main navigation, we played with a few possibilities for where to place project links, cloud deployment links, and the space selector. We ultimately landed on the idea to prepend them as part of the breadcrumbs, as that fit very well hierarchically. Ideally, we'd like the ability to have these prepended breadcrumb items that will trigger a popover when clicked.

  

CCing @tsullivan in case there's anything we missed.

[tsullivan]

Are there changes that need to go into EUI components as part of the new header for serverless projects?

Specifically, creating the nav show/hide button looks like it is to be done with EuiHeaderSectionItem, but will have a box-like border. Is it best to implement that in the Kibana side with custom code, that uses the correct theme color for the border, or should the EUI provide a way to make that box-like header section item?

[cee-chen]

Is it best to implement that in the Kibana side with custom code, that uses the correct theme color for the border, or should the EUI provide a way to make that box-like header section item?

EUI should be handling this on our end.

[cee-chen]

Current thinking 👉 Utilize a feature branch and ship changes as a separate package on npm.
@ryankeairns My strong vote would be to create a new internal (not a public top-level exported) component called EuiCollapsibleNavBeta that merges to main and can be imported in Kibana by diving into the EUI library specifically, e.g.

import { EuiCollapsibleNavBeta } from '@elastic/eui/lib/components/collapsible_nav/collapsible_nav_beta';

Using this approach means significantly less headache with npm exports and staying up to date on main (especially since we have several tech debt items such as node/React versions occurring) while still allowing us to remain flexible and tweak the component as-needed if specific props aren't working as expected.

[ryankeairns]

Roger that regarding an internal component.

On the topic of top header, I suspect we need a separate issue to capture the collapse button design. I don't know that there are other new changes (perhaps breadcrumbs 🤔 ), but I will suss those out.

cc:/ @MichaelMarcialis

[MichaelMarcialis]

I don't know that there are other new changes (perhaps breadcrumbs 🤔 ), but I will suss those out.

@ryankeairns: Aside from what is mentioned in the original comment above (re: inclusion of deployment/project and space as part of breadcrumbs), I don't believe the current designs suggest any changes to breadcrumbs other than to use the type="page" prop to give it that more subdued styling.

The header remains largely the same for both expanded and collapsed navigation modes in larger viewport sizes. The only difference in the two is the icon being used to represent the collapse/expand action.

Where the header (and navigation) does start to exhibit some more significant change is at smaller viewport sizes (see Figma examples).

[cee-chen]

Michael, you're a mind-reader! I was just about to ask for mobile views :)