Spacing inconsistencies in Navigation

[yanwalton]

@dimadavid made me aware that we have spacing inconsistencies throughout our navigation. It would be good to find out why this happened and make the fix so that switching between navs is graceful.

Let's investigate what the final spacings should be @ryankeairns and @MichaelMarcialis and who can fix this - either Shared UX or EUI

CC: @JasonStoltz and @petrklapka

Screenshot here

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[ryankeairns]

For reference, the EUI components were aimed at producing a design with spacing as seen here

Screenshot from linked storybook

[petrklapka]

The sidenav component can be customized to have flexibility in the spacing. The flyout component can hold either a standard panel or a custom component. In the case of security they use a custom component (cc: @semd ). SharedUX will be happy to fix common components once design settles on a standard.

[MichaelMarcialis]

Hey, all. I've been far removed from this project for quite a while now. However, based on what I'm seeing in the current serverless environments, it seems that most (if not all) of the inconsistencies are self-inflicted by the aforementioned solutions. The Elasticsearch solution's navigation in serverless appears largely as intended (compared to Ryan's Storybook example), but both Observability and Security solution navigations appear to be injecting a lot of spacers in various locations. These bespoke spacer injections are what is creating these inconsistencies.

I'm assuming the ability to add custom components (such as spacers) was provided to ensure ultimate flexibility with these navigations, but this flexibility is resulting in inconsistency. If they wish to be consistent, I imagine the simplest direction is to advise them to follow the Storybook example and not deviate (acknowledging that if they do decide to deviate, it will result in these sort of inconsistencies). Alternatively, we could consider being more strict about the sort of customizations that could be made to the navigation, but I'm guessing that isn't desired by the solution teams (recalling from past navigation conversations).

Anyway, I'm happy to help in any way, but this looks like something that will ultimately need to be addressed by the Observability and Security engineers.

[petrklapka]

Hey @ek-so & @tsullivan , and @MichaelMarcialis , with Seb gone, we've lost engagement on this and I want to rekindle. This seems super straight forward. Decide on what the spacing standard should be, and we fix it. Is the effort to get a design consensus on this still active or do we need to rekindle as well?

[ghudgins]

++ this is one of the items we have on our enhancements list for Q4. will be reviewing designs in the WG

[tsullivan]

The Elasticsearch solution's navigation in serverless appears largely as intended (compared to Ryan's Storybook example), but both Observability and Security solution navigations appear to be injecting a lot of spacers in various locations.

Current state

Consistency of navigation across solutions

• It looks like Observability is following the intended design (no more "lot of spacers in various locations"). Observability looks consistent with Elasticsearch.
• Security uses the navigation tree framework for the main nav. The spacing appears inconsistent with other solutions because in Security there are untitled groups of items that each have space above them (see the first bullet point of the "Other notes" section below).
  • Even though the main nav panel of Security uses a custom component, when links open a side panel / flyout, the panel component is the same as the panel component used in other solutions. This is in fact only the case for the "Stack Management" side panel in Security. All other side panels in security use a custom component.
• Some links require certain data or integrations to be installed in the deployment to be visible.
• Stack Management:
  • When projects are run as stateful, each of the 3 solutions show Stack Management links in a side panel / flyout. Clicking the Stack Management link, rather than the "four squares," opens a pseudo-landing page.
  • When projects are run as serverless, Stack Management is only shown as a landing page. There is no side panel / flyout.

Other notes about the navigation tree framework

• A group of links has extra space above the group. This effect works better when there is a title for the group. In many implementations, there is no title above the group. This can make the spacing appear arbitrary or inconsistent.
• Regular links can also have a "space before" attribute, which adds an EuiSpacer above the link.

Screenshots of current state: 2025-01-23-current-state-screenshots.zip

[tsullivan]

I've summarized issues with the current state in two parts:

• [Meta][Solution Side Nav] Styling issues #210219
• [Solution Side Nav] Telemetry issues #210221

[tsullivan]

@yanwalton I think we can replace this issue with https://github.com/elastic/kibana-team/issues/1439, yes?

[yanwalton]

@tsullivan Yes, i'll close this older issue now as you are covering it in that newer issue