Kibana: [Meta] Kibana global header

Created on 31 Mar 2020  Â·  12Comments  Â·  Source: elastic/kibana

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.

Feature set

Proposed design (as of May 19, 2020)

Screenshot 2020-05-19 16 29 31

Stacked header feature set

This new solution will be delivered in stages and encompasses the following changes:

  1. A new, second (upper/black) header bar that will contain:

    • Home button (cluster logo)

    • Deployment switcher (for Cloud users)

    • ~Global~ Navigational search

    • Support

    • Profile

    • Notification badge/banner (TBD)

  2. The current (lower/white) header bar will contain:

    • Navigation menu toggle button

    • Spaces button

    • Breadcrumb navigation

    • Application menu

Rollout plan

Phase 1

_Implement the first version of the new stacked header, including search_

  • Swap in the new/updated components from EUI (i.e. add the black bar; relocate buttons)
  • Include first version of navigational search (apps and objects within a single Space)
  • Relocate app menus into the header

Phase 1 work list

| 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:

  • Navigational search will be in its MVP state, returning applications and saved objects for the current Space of the current instance. The search API will be designed to support the registering of additional search content. The next version of the search API will support multi-Space search followed by (at a yet-to-be-determined future version) supporting cross-deployment search. (👇 See Pierre's comment below for a better technical description)
  • In addition to the scope of search, there will also be a concerted effort to move application menu bars into the lower header. The Kibana Design/EUI team has handled such migrations before and is prepared to guide/assist solution teams in this effort. This change will ultimately be at the discretion of individual teams and, by opting out, they can simply keep their existing app menu within the page body/below the header. The advantage of relocating their app menu is that they gain back vertical real estate.

Phase 2

_Expanded search and breadcrumbs_

  • Search is multi-Space
  • For Cloud users, the breadcrumbs will include additional links reaching back to the deployment itself (linking back into the Cloud UI)

Phase 2 work list

| 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) |

Phase 3

_Cross-deployment enhancements_

  • Deployment switcher is added
  • Search is cross-deployment (Cloud registers additional data to the search feature)

Phase 3 work list

| 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 |

Core UI

Most helpful comment

Some technical remarks:

Phase 2

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.

Phase 3

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

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.

All 12 comments

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:

Phase 2

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.

Phase 3

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

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.

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

timroes picture timroes  Â·  3Comments

socialmineruser1 picture socialmineruser1  Â·  3Comments

MaartenUreel picture MaartenUreel  Â·  3Comments

bhavyarm picture bhavyarm  Â·  3Comments

celesteking picture celesteking  Â·  3Comments