Kibana Navigation Redesign for 7.x

[ryankeairns]

Summary

The need for improved navigation has been expressed through customer feedback, internal stakeholders, surveys, the addition of new solutions to Kibana, and the interrelated efforts on Cloud.

Target outcome

Design a long-term, scalable navigation solution that enables users to quickly switch between Elastic solutions.

Considerations

Scope

Initially, any conceptual work can and should span to affect both Cloud and Kibana. In the future, this might change due to various requirements, but at this time there are no limitations to how broad these changes can be.

As this project progresses, we will break down the desired solution set into iterations aligned to Kibana releases.

Objectives

Listed below are several goals and requirements that need to be addressed in any mockups/prototypes/concepts that are created:

• Prepare for scalability and growth. The new navigation should plan and allow for the addition of many more applications/products/solutions as well as cross-platform support.
• Make it utilitarian in nature. Allow for recently used, hideable, and pinnable applications so that users can quickly access their most-used applications. - [K7 Navigation] Pin applications and saved objects to navigation #25738
• Make it clear via text. Avoid the use of icon-only based links. Icon metaphors are breaking down, so we need to make sure that text becomes the primary product communication to users. - Icon mania in kibana #36413
• Make context switching quick & easy. Provide navigation to allow users to easily switch between solutions and cloud instances.
• Communicate globally. Adopt a globally unified header across all products/solutions. Technically, this might require code repetition, so make sure that a global header is easily repeatable.
• Remove reliance on Icons. Kibana is constantly adding new apps and the ability to visually represent each application with an icon is cumbersome. Outside of the top level groupings we should remove the need for individual app icons.
• Feel free to move features. The migration of some admin features from Cloud to Kibana might be necessary to help the navigation become more intuitive. Feel free to pitch these types of changes.
• Improve EUI. This is a great chance to retain and/or improve accessibility and mobile support specifically within EUI.

Search as Navigation

Moved to #57576

Project milestones

• Create design mockups that address the aforementioned objectives
• Build an interactive prototype based upon those mockups
• Conduct user research on the prototype (usability testing, customer interviews, survey, etc.)
• Build new EUI components - [Feature Branch] EuiCollapsibleNav eui#3019
• Build out the existing Kibana navigation

Build out checklist

• Display Kibana, Observability, Security, Management accordion sections
• Observability section should be: Logs, Metrics, APM, Uptime Kibana Navigation Redesign for 7.x #56232 (comment)
• Change order of Visualize apps - Dashboard first; Visualize last [Discuss] Move dashboard app as the first application in Kibana section  #63429
• Store state of docked navigation
• Add accordion section for Recently viewed (temp until global search is added)

---

• Store pinned items (using localStorage)
• Add Cloud link (see comments below)
• Add telemetry (Alex will create an issue; here is the telemetry issue from the prior grouping effort)

---

Prototype

https://ela.st/k8

---

Decision log

• If a group only has one item, it will still live under a group. In the previous grouped nav design, we converted the parent to be clickable, but that is no longer the desired outcome. This is somewhat mitigated by the use of pinning - pin the single app to the top; ignore the group. (It's possible to make the parent clickable and we'll revisit that later in the sprint)
• Plugin authors can define the group where there plugin will appear (this could be an existing or new group). If no group is defined, then we'll place the plugin into a 'Custom plugins' group.

[elasticmachine]

Pinging @elastic/kibana-core-ui (Team:Core UI)

[ryankeairns]

@andrew-moldovan pointed out that with the most recent designs, we seem to have displaced the links back to the deployment views in Cloud. In early discussions, we settled on having two links in the top/black section of the left nav:

1. A link back to the deployment page for this instance and
2. A link back to the full list of deployments

With the stacked header, the deployment switcher moved up into that top black header bar. However, that new switcher seems to only serve the purpose of switching directly between kibana deployments without ever seeing the Cloud UI. Perhaps we can accommodate these links up there (cc:/ @johnbarrierwilson ), however we will need an interim solution until the header and switcher are both in place.

Long story short, should we still add those two links atop the header? The good news is that EUI built that top section into the collapsible nav. The last piece of the puzzle then would be figuring out how we get the deployment id and in order to build the links.

Proposed links

[johnbarrierwilson]

The current mockups (for the future solution) should account for this: clicking on the deployment name in the top header will open a switcher modal. The modal will have links to various things...

Obviously this is a far-reaching future solution, so the dropdown/popover with deep links (such as "scale and configure", "activity feed", etc.) back into Cloud might not be possible once the headers actually arrive, so we can just change the three dots to a simple "manage deployment" link, if needed.

[johnbarrierwilson]

Something to note: the interim solution (screenshot above from Ryan) includes the deployment dropdown as part of the sidebar. I've been viewing that specific piece of the design as an artifact from earlier designs that shouldn't be included in the interim between now and the future solution. The reasoning is that, as a user, it might be difficult and confusing to learn the paradigm of deployment navigation within Kibana to only have it moved and changed again once the stacked header arrives. Double-taxing the users to figure out a singular feature two times could have adverse effects. Let me know your thoughts!

[andrew-moldovan]

In the future state, I'm happy with the View All Deployments button being in the deployment switcher. It's also a good aspirational goal to be able to link to activity feed from the context menu (dots) for each deployment. However, that still leaves how a user goes back to the deployment they're currently on. It'd be weird to have to find the deployment you're currently on in the switcher just to be able to find the Cloud links. A link back to the Cloud view of this deployment should live somewhere else.

And so in the intermediate state, we still need that one link back to the Cloud view of a deployment. Could be the same as the future state or not.

I'm fine with leaving out the black section of the navbar, but I think a link back to Cloud should be there. Maybe under Cloud Management?

[ryankeairns]

Clarifying question, @andrew-moldovan you would like to have a link back to the Cloud view of this deployment ASAP, right?

In other words, if the header redesign and switcher push out to 2+ minor versions away, then we need an intermediate solution within the current header layout (or new left nav). Correct?

Let's hope we hire somebody and can ultimately avoid this, but depending on the simplicity of this solution we may also be able to get this into the imminent left nav work, if necessary.

[andrew-moldovan]

yes exactly. We can't switch over to defaulting to Kibana in Cloud until we having this navigation back to Cloud. 2+ minors is too long.

[johnbarrierwilson]

It'd be weird to have to find the deployment you're currently on in the switcher just to be able to find the Cloud links.

Good point, and I agree. This specific problem could easily be solved by simply labeling the current deployment within the switcher (see image below). I think it's a good thing to keep all cloud links within the switcher as the user will already have the context that the switcher is where they interact with cloud-based actions. If we were to bring these links out of the switcher—either into the sidebar are somewhere else—it would potentially begin confusing the user since they will end up going to the switcher for some cloud actions, and another place for other cloud actions. Ultimately, leaving them with an inconsistent UX.

...we need an intermediate solution within the current header layout...

I agree that links to the deployment in Cloud should be in the sidebar in the interim. It should also be prominent since we want to begin communicating to users that the experience is moving towards a cohesive concept. How's this solution (see image)?

[andrew-moldovan]

Yep, I like the interim solution. Not 100% about the wording. Since there's already a management link at the bottom which is the ES-UI area. But I think it's good enough.

For the future state, I'm not sure I agree that all Cloud actions should be in the deployment switcher.

1. If we're fully integrated products, there should be more than just a single interaction point. By forcing all Cloud things to go into the switcher you end up highlighting that there's a difference
2. Viewing the Cloud page of this deployment is a totally different task from switching to a different deployment. Remember that the default action in the switcher is to go to another deployment's Kibana, not Cloud. So the switcher won't necessarily tell the user that these are Cloud actions anyways.

[johnbarrierwilson]

Cool. @gjones might have some input here since this is what we were working on together. We discussed using the modal for cloud-related items—but I'll hold my opinions until Gareth gets a chance to chime in.

[gjones]

For the future state, I'm not sure I agree that all Cloud actions should be in the deployment switcher.

The idea was that the table in the switcher has the same behaviour / options as the deployment list page, potentially this consistent interaction could be expanded to other areas where ewe list the deployments in the future, in and out of kibana.

I was under the impression that any future state would always allow users to get to the cloud page in the sidebar, in the prototype last month in was called infrastructure settings under management, which I think presents a few problems, but in general the idea would be an ever present link.

[andrew-moldovan]

The idea was that the table in the switcher has the same behaviour / options as the deployment list page

Fair enough, will be basically impossible to keep it the exact same behaviour over time, but good thing to strive for.

But yes, we should be able to go to the Cloud view of a deployment from the left nav I think

[ryankeairns]

@andrew-moldovan can you provide us some guidance on how we should build this Cloud deployment link?

[andrew-moldovan]

Sure.

Kibana has the cloudId in the Cloud plugin whenever it's running in Cloud.

A cloudId is a 64bit encoded string and breaks out into <regionId?>.<provider?>.<cname>$<esClusterId>$<kibanaId>. Eg. us-east-1.aws.found.io$f0e7f777a2bb4a2cb42b142ef2f095ca$5a69c20b264a4b5dbbd71fa30bc0dca2

So in ESS creating the link is pretty simple.

cloud.elastic.co/deployments/resolve/cluster/:regionId/:esClusterId/

And that will take you to the overview page in Cloud.

In ECE the url doesn't change much we just need to replace cloud.elastic.co with the cname provided. However, the admin can change the cname and that presents a lot of challenges. I don't know if we have a good answer today for this. I'm going to try and get an answer in https://github.com/elastic/cloud/issues/54009 and circle back here. The work can start on the ESS side for now though.
ECE is a bit of a problem, going to try and get an answer in https://github.com/elastic/cloud/issues/54009

See below for some example cloudIds

ESS:

eastus2.azure.elastic-cloud.com:9243$59ef636c6917463db140321484d63cfa$a8b109c08adc43279ef48f29af1a3911
us-east-1.aws.found.io$a2a21d1fe8c33036e62fa144f7760893$76498e5ec1298d14d47560955f1ef774
us-west-1.aws.found.io$21e7851922104b0f9715fb41114afc35$7d81e1320baa47a6bbcb16e7faaeb703
us-central1.gcp.cloud.es.io$3e83fc465b934d2582175dfffd9b34a6$bac3be47a4d34732bccba675d89e9eb3

ECE:

192.168.44.10.ip.es.io:9243$38ab00fbf02446a4b9ab2cebc58e7921$d721383b0de0488caa427d5871fa9493

192.168.44.10.ip.es.io is the cname in ECE, so it's a bit hard to know exactly how to differentiate between ESS and ECE. I guess look for the region/provider structure and if you don't find it, just assume it's ECE.

[alexfrancoeur]

Dropping this in here just to make sure it's captured. The Observability team saw in some mocks that the ordering of apps was incorrect. To clarify, the expected order under Observability is meant to be this:

• Logs
• Metrics
• APM
• Uptime

Related (though I believe this team is already plugged in), the Kibana app team is planning to move Dashboard to the primary action for the Kibana grouping: #61632

[ryankeairns]

@andrew-moldovan are there conditions where the deployment link would not display? For example, if I log in to a Kibana Cloud instance using the basic username/password form (not SSO)?

[andrew-moldovan]

Yes, I think if the user has logged in with a native user (non SSO) then we shouldn't be showing them this link, just like we don't show them the account links

[ryankeairns]

@andrew-moldovan Michail has a draft PR up and is now working through the broken tests and adding new tests. That work is obviously critical to getting this PR into a 'green', passable state in time for the 7.8 feature freeze cutoff, but that also means there are some unfinished features.

Once the testing work is complete, and barring any necessary bug squashing or other critical adjustments, the Cloud deployment link and pinning are next up (in that order). Given all that, and the amount of presumed work for adding the deployment link, there is a good chance that it will not make it into the 7.8 release. We anticipate having additional eng support immediately following the 7.8 FF at which time this item will be addressed.

Let me know if you'd like to discuss this further and I'll keep you posted as things progress.

[andrew-moldovan]

Thanks for the update! That sounds good, not much we can do

[ryankeairns]

@andrew-moldovan we have another engineer joining our team next week and would like to have her start on the cloud-related links (deployment link in nav; account links in profile).

Given the outstanding nature of https://github.com/elastic/cloud/issues/54009 , should we still proceed with this work or wait until the ECE URL is being captured and passed? Is there a way we can start with ESS in the meantime since it seems 'ready'?

cc:/ @bmcconaghy

[andrew-moldovan]

I would start with ESS by just basically assuming that you're in ESS always. After https://github.com/elastic/cloud/issues/54009, there will probably be a new variable passed into the kibana yaml file (cloudBaseUrl or something) that you can use instead of cloud.elastic.co, but the required changes should be just a single line