As part of the navigation redesign project, a new stacked header design will be implemented that sets us up for global navigation across Elastic products.

This new solution will be delivered in stages and encompasses the following changes:
_Implement the first version of the new stacked header, including search_
| Status | Feature | EUI | Platform/API | Cloud/API | Core UI |
| --- | :--- | :--- | :--- | :--- | :--- |
| 🚧| Cloud deployment link | X | X | https://github.com/elastic/cloud/issues/57690 https://github.com/elastic/cloud/issues/54009 | #65089 → PR |
| 🚧| Cloud profile links | X | X | https://github.com/elastic/cloud/issues/57695 | #62863 → PR |
| | Stacked header design* - ship with Nav Search; remove old left nav | https://github.com/elastic/eui/issues/3489 | X | X | #65787 #64541 #68524 |
| | Navigational Search V1 - single Space | https://github.com/elastic/eui/issues/3490 | #64284 #61657 → Search plugin PR → App provider PR | X | #58049 |
_* Need cross-team issue to track migration of app menus into header_
The first version will include the aforementioned changes with the following caveats:
_Expanded search and breadcrumbs_
| Status | Feature | EUI | Platform/API | Cloud/API | Core UI |
| --- | :--- | :--- | :--- | :--- | :--- |
| | Enhanced breadcrumbs | X | X | https://github.com/elastic/cloud/issues/57690 https://github.com/elastic/cloud/issues/54009 | Need issue |
| | Navigational Search V2 - multi Space | X | https://github.com/elastic/kibana/issues/67977 (related #61657) | X | #27003 (update) |
_Cross-deployment enhancements_
| Status | Feature | EUI | Platform/API | Cloud/API | Core UI |
| --- | :--- | :--- | :--- | :--- | :--- |
| | Deployment switcher | https://github.com/elastic/eui/issues/3504 | X | https://github.com/elastic/cloud/issues/57553 | Need issue |
| | Navigational search - Cross deployment | X | Need issue | Need issue | Need issue |
Pinging @elastic/kibana-core-ui (Team:Core UI)
Pre-requisite: New/updated EuiHeader component(s)
Who is building this? Do we have an issue for it?
@andrew-moldovan The EUI team will be building the new header component. They do not have an issue yet, but they're very much involved with the design effort and @snide has proposed a phased approach with this landing in the 7.9 timeframe.
The newest mocks have not been translated to requirements from the EUI side. It's mostly domain knowledge on the EUI side and involves supporting dark components in light theme, and double-height. Otherwise, the main components are already available.
The newest mocks have not been translated to requirements from the EUI side
@cchaos just to make sure I understand and we're being super explicit, is that something you need from Cloud/Kibana or "just hasn't been done yet, but we know"?
The requirements would be coming from Cloud and Kibana, but dictated by the cross-team effort. EUI is aware of most, if not all, of the current requirements but hasn't been formally written down.
The EUI work covers much of the frontend, but the backend portion of this equation is still undetermined. There have been suggestions from the Kibana side (while reviewing the navigation/header designs) that there be a Cloud plugin to support features that rely upon Cloud-related content (e.g. deployment switcher and search).
With regards to global search, the MVP will rely upon the beginnings of a search service however it will be a thin layer that meets the objectives of the MVP (return apps and objects for the current instance/Space). In relation to the MVP, brief conversations were had around the idea of registering data sources to further the scope of searched content. To the point in the previous paragraph, it might be that this Cloud plugin also register a data source to the search service, for example.
Suffice it all to say, we have a plan to achieve the initial version of the header within Kibana, but more discussions are needed to define an approach that gets us to the full header and search experience.
FYI, @alexfrancoeur has offered to help with coordination on the Kibana side.
...a Cloud plugin to support features that rely upon Cloud-related content (e.g. deployment switcher and search).
FYI there's an existing Cloud plugin that can house the functionality that needs to be added: https://github.com/elastic/kibana/tree/master/x-pack/plugins/cloud
Some technical remarks:
Global search will not yet search across deployments. [...] but the registry approach would essentially allow plugin authors to register additional data sources thus also enabling a true cross-deployment search.
Search is cross-deployment (Cloud registers additional data to the search feature)
Yea, 'plain' plugins will/should still not be aware of other kibana deployments. It will be to the cloud plugin (or any other cloud-related plugin we'll introduce) to register a datasource to be able to fetch/collect any expected results from the other deployments. Even if I don't see any technical blocker on this, it still appears as non-trivial and would requires some thinking on the best way to gather results from other deployments. We may need some development / API exposed from cloud itself here.
Deployment switcher is added
Will requires the introduction of a new API to enable (show) and feed the switcher options, and consumption of this API, probably from the cloud plugin. Don't seems like big work.
For Cloud users, the breadcrumbs will include additional links reaching back to the deployment itself (linking back into the Cloud UI)
We'll need a way to alter / edit the values sent to
for that. We could either introduce something like
registerBreadCrumbInterceptor(breadcrumb: ChromeBreadcrumb[]): ChromeBreadcrumb[]
API for that, that would address the need, but ATM it feels like overkill regarding the need, and adding something like setBreadcrumbPrefix(prefix: ChromeBreadcrumb[]) to allow prepending elements to the displayed breadcrumb seems sufficient.
What is the plan for coordinating the changes need for applications that need to move their UI buttons / controls into that header space along side the breadcrumbs?
I suspect that will be non-trivial and require a good amount of coordination. Are we okay with shipping a version of the new header where not all apps move their buttons or do all apps need to switch in the same version?
I think practically we have to be ok with some apps migrating in a future version but I think we can optimize for getting as much done as early as possible.
So to merge the header, I think we do it in just a couple of high traffic apps (Discover and Dashboard as an example, maybe we pick something outside of Kibana App too just for variety).
And I think we merge it at the very start of a new minor version. This gives teams the whole minor version to make time for migrating their own apps.
Likely some still won't but I think that's ultimately ok.
+1 to what @myasonik framed up.
I ran this by @snide earlier today and will set up a quick meeting for us all to talk through a rough plan.
cc:/ @joshdover
Most helpful comment
Some technical remarks:
Phase 2
Yea, 'plain' plugins will/should still not be aware of other kibana deployments. It will be to the
cloudplugin (or any other cloud-related plugin we'll introduce) to register a datasource to be able to fetch/collect any expected results from the other deployments. Even if I don't see any technical blocker on this, it still appears as non-trivial and would requires some thinking on the best way to gather results from other deployments. We may need some development / API exposed from cloud itself here.Will requires the introduction of a new API to enable (show) and feed the switcher options, and consumption of this API, probably from the
cloudplugin. Don't seems like big work.Phase 3
We'll need a way to alter / edit the values sent to
https://github.com/elastic/kibana/blob/4deea08f23c63870daedc5612698be8ea17103d2/src/core/public/chrome/chrome_service.tsx#L386-L389
for that. We could either introduce something like
registerBreadCrumbInterceptor(breadcrumb: ChromeBreadcrumb[]): ChromeBreadcrumb[]API for that, that would address the need, but ATM it feels like overkill regarding the need, and adding something like
setBreadcrumbPrefix(prefix: ChromeBreadcrumb[])to allow prepending elements to the displayed breadcrumb seems sufficient.