-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Meta] Kibana global header #62010
Comments
Pinging @elastic/kibana-core-ui (Team:Core UI) |
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. |
@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. |
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
Yea, 'plain' plugins will/should still not be aware of other kibana deployments. It will be to the
Will requires the introduction of a new API to enable (show) and feed the switcher options, and consumption of this API, probably from the Phase 3
We'll need a way to alter / edit the values sent to kibana/src/core/public/chrome/chrome_service.tsx Lines 386 to 389 in 4deea08
for that. We could either introduce something like |
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 |
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)
Stacked header feature set
This new solution will be delivered in stages and encompasses the following changes:
GlobalNavigational searchRollout plan
Phase 1
Implement the first version of the new stacked header, including search
Phase 1 work list
* Need cross-team issue to track migration of app menus into header
The first version will include the aforementioned changes with the following caveats:
Phase 2
Expanded search and breadcrumbs
Phase 2 work list
Phase 3
Cross-deployment enhancements
Phase 3 work list
The text was updated successfully, but these errors were encountered: