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
- [ ] `EuiCollapsibleNav` - remove borders
- [ ] `EuiCollapsibleNav` - change button styles
- [ ] `EuiCollapsibleNav` - change accordion arrow icons
- [ ] `EuiSideNav`- change item styles
- [ ] `EuiSideNav` - change accordion arrow icons
- [ ] `EuiSideNav` - change borders on children
- [ ] `EuiSideNav` - change text color on children
- [ ] `EuiSideNav` - change bottom padding on parent group

#### Tasks - Functional enhancements
- [ ] `EuiSideNav` - Display (optional) right-aligned icon on items
- [ ] ⏸️  **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.