Create navigational/header search solution

[ryankeairns]

Related to #3489

In order to track work on the global header/navigation solution, I am creating this issue to track the new pattern/component to support the V1 Navigational Search feature as seen below.

From the new stacked header, a user will activate the search UI either through keyboard or mouse. On activation/focus, a popover will appear that initially displays recent items (in Kibana, this will differ across products), and typing will provide a typeahead set of results containing apps and saved objects (again, Kibana specific in terms of result types).

The user will be able to tab through the items and navigate to the active item upon clicking or pressing Return. As a nice to have, active items will display a badge to further indicate this is the active item and inform that pressing Return will result in navigating to said item.

While all list items will be the same height, we would like to adjust the content dependent upon result type where, for example, apps would display an icon while other results show only a title and description.

Result types to support

Description	Display deployment?	Display space?
Saved object that lives with an app (a dashboard, a viz...etc)	✅	✅
The app itself (Logs)	✅	✅
The solution itself (Observability)	✅	✅
The deployment itself (essentially what you'd get if you used the switcher)
Sub features of applications (CCR, Index management, space management...etc)	✅	✅
Users, Roles (in the near term, those live possibly in Cloud and Kibana)
Help content / docs
Cases within dream machine
Sections within dream machine
Sections within the cloud console (billing...etc)

Mockups of various states

Input focus states:
https://user-images.githubusercontent.com/549577/82465809-af47b580-9a8d-11ea-905c-d3cab06ad8b8.png

Figma file

https://www.figma.com/file/AngVp8Bexq2UjN7G44IsuZ/Holistic-Experience?node-id=1143%3A5

[cchaos]

Thanks @ryankeairns. Can you also list out the different states for the search input? Perhaps a link to a Figma file as well?

[ryankeairns]

@johnbarrierwilson can you post mockups as you have them? Thanks!

A few of the states we discussed were:

• empty
• loading
• results returned (logos for apps, in the Kibana case)
• focused result/row
• themes (dark vs light/K7 vs Amsterdam)

[johnbarrierwilson]

A quick screenshot for each of the result types:

All results are the same height. Once we get a general agreement on these mockups, I'll update the description.

Do these layouts cover all the use cases we would need?

[cchaos]

Thanks @johnbarrierwilson & @ryankeairns. Can you detail the different states for the actual search input as well?

[snide]

@johnbarrierwilson my guess is we don't need that much variety in the styling. Just talking through this I would say you can standardize this into a more readible format by only using these, presented in the same way regardless of the result type.

1. Name of thing
2. Substring of thing (description, URL...etc). Subtext coloring.
3. Type of thing (dashboard, viz, case..etc). Utilize color.
4. Location of thing (deployment name, space...etc). You'll need this for cross-deployment / application concepts. I think in most cases this will be the space something lives in.

All four should remain in the same location within the result row so it's quick to read.

I would drop the use of icons. They aren't going to be consistent, and won't effect the weight selection.

[ryankeairns]

For Kibana, I would like to try and keep the solution logo alongside the app results in order to visually differentiate them (in a clear way) from objects. This also is a nice way to relate them to the left nav groupings.

[ryankeairns]

@cchaos can you clarify what you mean by states in this context?

[cchaos]

I'm trying to gauge the literally "states" (normal vs focus). From what I can see in the mocks it's using multiple themes. In the default (normal) state, the input is displaying as our "Dark theme, but in light mode", however, this "focused" version in your mock is back to showing the typical light themed search input. I just need clarification that this is what you need.

It makes it more complicated, not impossible, but better have to this knowledge up front.

[johnbarrierwilson]

@cchaos Yes, that's the extent of the states. Gray for unfocused; white for focused. The switch to white will be super helpful when a user engages with the search using the command + K shortcut.

@snide @ryankeairns Yea, I could have done a better job providing context.... The layout for these results are definitely all the same. See diagram:

I think Ryan hit on a good point that the icons will do a good job differentiating larger concepts (ie. solutions) from standard concepts (ie. objects). In that same vein, recents need to look slightly different so that a user doesn't think they are actual search results for a blank query—and support being similar in scope/size to a solution.

[snide]

Sorry if this stuff is in a spec somewhere, so I may be way off. I tried searching for one, but didn't see anything that covered the full details yet.

My suggestion is that we should sketch out a lot more examples of the results before we commit. I think you'll find this is going to get a lot more complicated, and then you might up going a lot more simple because of that.

Here's a decent list of the top of my head that would show in results

• Saved object that lives with an app (a dashboard, a viz...etc)
• The app itself (Logs)
• The solution itself (Observability)
• The deployment itself (essentially what you'd get if you used the switcher)
• Sub features of applications (CCR, Index management, space management...etc)
• Users, Roles (in the near term, those live possibly in Cloud and Kibana)
• Help content / docs
• Cases within dream machine
• Sections within dream machine
• Sections within the cloud console (billing...etc)

Likely if those all look slightly differently in the display we might find that it just comes out busy and hard to read, rather than distinct.

Almost all of these things in a cross-deployment search will come with the baggage of being in a different location (different cluster, different space) that will need some manner of keying in the result (aka: what context will i arrive in). What happens when saved objects themselves can be cross-space?

We might want to be pretty prescribed with how the meta data is rendered, and not allow much variation there (meaning: always use a badge to indicate the type of thing, optionally include a describer...etc). This makes a difference in the component, with whether we want meta to be a node type or have individual, separate pieces.

I'm personally a little hesitant with the logos, though I could go either way. When do you show them for things in that list, for saved objects within the solution, for the solution itself, for the apps in the solution? How does that get confused when you're talking about spaces...etc. Do you see 5 results for the logs app across 5 different clusters with 5 spaces each...etc?

I know this thinks forward from the MVP a bit, but it seems like something that would be a good exercise to go through.

[cchaos]

Also a reminder that the search item result itself if completely customizable by the consuming application. We can provide some patterns and maybe some specific components, but truly it's up to the consuming app.

[ryankeairns]

@cchaos regarding themes/states... as I understand it, there is only one version of the top black header. The black vs white input is a matter of focus (dark by default; white when focused).

@johnbarrierwilson is that accurate and did you envision the menus (search, deployment switcher, and profile) to always have a white background as well? (ie. to look the same for both dark and light themes)

[ryankeairns]

While that list of content @snide outlined initially looked daunting, I can envision all of those fitting into the template that John shared above. Some but not all were captured in a Kibana Global Search doc, I can add the remainder.

It's still a good idea to mock some of these up to prove my assumption, but I don't think we're painting ourselves into a corner especially if EUI goes the route of providing patterns and parts versus a whole component, as @cchaos noted above.

I'm also sensing a rather lengthy timeframe on this feature for Kibana, so we have plenty of time to adapt in the future where so much remains unknown. As of now, we've had no discussions regarding the prioritization of additional content and the concept of 'registering data sources' has yet to be socialized... so that too will take some time. cc:/ @alexfrancoeur

[johnbarrierwilson]

It's still a good idea to mock some of these up

Yep—was on my list to do. Will post here with more visuals.

I agree with @ryankeairns that the majority of those in the list could fit into the template. It will help to make sure we cover those edge cases. Especially around different spaces/deployments.

[johnbarrierwilson]

Making note: I added a table up top that summarizes various result states we should take into account. Please add more items/details as necessary.

[johnbarrierwilson]

Here's a run-through of all the different iterations (mistakenly referred to as edge-cases) using the pre-defined template:

👨‍💻 Screencast | 🎨 Mockups

[cchaos]

Closed via #4008 🎉