Kibana: Integrate tags to navigational search results

[alexfrancoeur]

With tags coming soon (https://github.com/elastic/kibana/pull/79096) and support for fleet integrations on the horizon (https://github.com/elastic/integrations/issues/327), I'm beginning to think we'll need to surface tags in the saved objects results of navigational search. There are a few reasons I think we should do this.

• Consistency: Tags will be present in other searchable views, why not in the most prominent search box
• Object differentiation: Saved objects may have similar names but different context when it comes to tags
• Filters: While https://github.com/elastic/kibana/issues/74290 is probably a little further out, it'd be good to filter your navigational search results on tags. Or searching for a tag returns all SO's with that tag.

I'll definitely need some design help here, but here's a quick PM mock of how this could look visually

Today:

Support for tags:

I'd love to hear the teams thoughts on this. It feels like something we should support in a post-tags world, but let's discuss.

cc: @pgayvallet @ryankeairns @myasonik

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[pgayvallet]

I don't see any technical blocker to enhance SO search results with tags. I don't know the EuiSelectableTemplateSitewide EUI component we are using for the search bar well enough though. @myasonik, on the UI side, does that seems doable? I see we are using a meta attribute to display the category. I guess we could do the same to display the tags?

[ryankeairns]

On the surface, it seems like this might get very noisy. I wonder if the more optimal UX thing to do with tags is work them into the search syntax idea. For example tag: tagname and get SOs with that tag (and perhaps show that single tag in the meta).

If the consensus is to go the 'display tags by default' route, then let's have a designer iterate on that a bit.

[myasonik]

Technically, we can achieve this pretty easily though it isn't built into the component as is right now.

For the meta data, there are 5 types ('application', 'deployment', 'article', 'case', 'platform') which I think each just align to specific colors. But we could create a custom type of meta data (e.g., 'tag') and render it however we wanted to.

[pgayvallet]

Another subtask of https://github.com/elastic/kibana/issues/74571 regarding the navigational search integration is Add tags to search results. I wonder where the user should be redirected when selecting a tag from the search though. @alexfrancoeur ?

[ryankeairns]

Re: clicking, I didn't envision tags as being search results themselves, but rather used as (non-clickable) metadata or as a search syntax key/term. If, in the future, we have an advanced results page, then I could see a tag result taking you there to a filtered list of 'stuff'.

[alexfrancoeur]

I was thinking of supporting tags in two ways

1. Visual identifiers - this SO has tag x, y and z
2. Additional filtering capabilities when we have more advanced syntax. type:dashboard and tag:alex

I had been thinking we can focus on the first item first, but it seems like there are some design concerns. @ryankeairns @MichaelMarcialis do we think this would be too busy? I was aiming for consistency and object differentiation, but I can see the argument for noisy. Is it worth putting some quick mocks together?

If we think it's visually too noisy, I think we can probably close this out and add tags as a requirement for https://github.com/elastic/kibana/issues/74290 and the advanced results page (couldn't find an issue)

[myasonik]

Maybe this gets into the realm of more UI configuration than we typically support, but it would be kind of neat if users could opt-in/out of showing the tagging. I imagine it'll be more important to some users rather than others.

[ryankeairns]

Yeah, we can do some mockups and see where it goes.

[alexfrancoeur]

++ @myasonik, I agree - perfect requirement for a user setting!

@ryankeairns visually, I wonder if it would feel less busy if we kept tags monochromatic or text only in the search results

[pgayvallet]

@ryankeairns any progress on that one?

[ryankeairns]

@pgayvallet No, not yet. I had presumed this was further out but can get something up quickly.
We have a separate meeting today re: tagging, so I'll tack on a quick discussion to align on search priorities.

[MichaelMarcialis]

Hey, all. I've put together a quick mockup and prototype for how tags could potentially appear in the global search experience. Whenever you have a moment, please take a look at the design overview video I've linked below for a detailed walkthrough.

• Design overview video
• Figma mockups
• Figma prototype

As always, feel free to leave any feedback here or in Figma via the commenting tool. Otherwise, if you'd like to meet to discuss further, let me know and I'll throw something on the calendar. Thanks.

[pgayvallet]

I think most of the propositions make sense. I personally find the tags being displayed on the right to not be obstructive, and it even adds a nice touch of color to the result list.

Still got a lot of questions, but most of them are regarding the technical implementation and feasibility.

The tag:logs - filter by tag name suggestion item (at 0'59'')

I honestly love that. It's rather obvious that users may be trying to search by tag by typing a tag name, so having this feature allow to both help the user, and educate him on how to properly use the search syntax (now, the dev speaking: as long as we only check for an exact match between the search term and the existing tag names)

Do we want the same thing for the type filter? Like, if the user types dashboard, should we add an option to suggest him to use type:dashboard instead? We probably do, right?

Now regarding the technical implementation:

• we need to confirm that injecting arbitrary items in the EuiSelectableTemplateSitewide is possible
• we are currently extremely constrained by this component's behavior and format. Having thing such as the goto button renamed to apply, or the fact that the text is blue instead of black, is just not possible at the moment.

regarding the tag:log OR log query / syntax you did in the demo (at 3'19'')

you can exclude that (at least for short/mid term). It's neither supported by EUI's Query language nor the SO find API. What you can do is tag:log log, which would return results having both the log tag and log in their searchable text. See https://github.com/elastic/kibana/issues/74290 for more details.

Icon alignment (at 4'26'')

That's way better in term of design and eye-flow imho. Here too, we may be limited by the underlying EUI component.

Tags displayed on the right

That position seems rather obvious to me. However, here again, technically this is not something allowed by the EuiSelectableTemplateSitewide default rendering

'Goto' button appearing at the right of the tags the the option is active (at 5'36'')

Same, not possible with the default rendering

max number of tags / max length of tag label (at 7'10'')

Ensuring that the tag the user is searching for is always displayed makes sense.

Limiting the number of tags AND the max length of the displayed tag labels is rather easy. What would be way harder would be to 'please display all the possible tags until a size limit is reached', so I would directly ask the others to NOT suggest that (pretty please).

So, techically

I think that for most of these changes, we will need to implement a custom option renderer (EuiSelectableProps.renderOption) for the EuiSelectableTemplateSitewide component we are using inside our SearchBar. @myasonik, do you agree?

[myasonik]

I think that for most of these changes, we will need to implement a custom option renderer (EuiSelectableProps.renderOption) for the EuiSelectableTemplateSitewide component we are using inside our SearchBar. @myasonik, do you agree?

Yup, the amount we're doing that isn't part of the default component I think is starting to outweigh the utility in sticking to the default but I'm a little concerned about the shift from an EUI-owned cross-solution component to a Kibana-owned "enhanced" version and I'm not sure how we want to go forward ultimately...

@cchaos thoughts?

[MichaelMarcialis]

Do we want the same thing for the type filter? Like, if the user types dashboard, should we add an option to suggest him to use type:dashboard instead? We probably do, right?

Yes, exactly! If we could make smart suggestions like this while also educating users about the filter syntax options, that would be great.

• we are currently extremely constrained by this component's behavior and format. Having thing such as the goto button renamed to apply, or the fact that the text is blue instead of black, is just not possible at the moment.

If it's not possible to change the text within the key indicator badge, perhaps we just shorten it to show the ↩ symbol in all cases? Thoughts, @ryankeairns?

As for the blue colored text on hover/focus, I believe we already do that currently, though it appears that the highlighted/marked styles applied to keyword matches is overriding the color styles. We may need to either ask for an EUI CSS tweak here.

you can exclude that (at least for short/mid term). It's neither supported by EUI's Query language nor the SO find API. What you can do is tag:log log, which would return results having both the log tag and log in their searchable text. See #74290 for more details.

Gotcha. I wanted to use an or operator in my example to show both keyword and tag matches for both apps and saved objects. Will we be offering a way to perform an or operation for MVP? Or are we don't and only for now?

[pgayvallet]

@MichaelMarcialis

Will we be offering a way to perform an or operation for MVP? Or are we don't and only for now?

We have OR (and only that) inside filters. You can filter by tag:(tag-1 OR tag-2). But all the filters and term are aggregated using a AND. type:dashboard tag:(tag-1 OR tag-2) term will search for objects that matches all the conditions: are of type dashboards AND are assigned to either tag-1 or tag-2 AND contains term.

(Also, to be totally honest, as this is limited by both EUI's Query syntax AND the savedObject find API, it would need a very significative amount of work to go further)

If it's not possible to change the text within the key indicator badge, perhaps we just shorten it to show the ↩ symbol in all cases

yea, it's not only that. With the default renderer, we can't have non-text meta I think, and we definitely can't render the tags where they are in the mockup anyway.

@myasonik

Yup, the amount we're doing that isn't part of the default component I think is starting to outweigh the utility in sticking to the default but I'm a little concerned about the shift from an EUI-owned cross-solution component to a Kibana-owned "enhanced" version and I'm not sure how we want to go forward ultimately...

++ on that. But the default option renderer of the component is just not compatible with the advanced display we would need to match the design here.

Also as this seems fairly specific to this exact and only need, I don't really see the component / option rendered being provided by EUI. I mean, that's what renderOption was created for I guess. But I think just providing a custom option renderer would be enough, right? Or do you think we would need to totally remove the usage of the EuiSelectableTemplateSitewide we are currently using?

[ryankeairns]

The designs look great, thanks for putting them together @MichaelMarcialis !

It's natural (and likely a sign of excitement) for the conversation to move into implementation complexities, but let's not lose sight of what we were hoping to achieve here with these particular designs - what would it look like? and is it worth pursuing?

It seems we're all on board with the general approach, so it's reasonable to next outline the changes we would need from EUI. As we dive into that request, let's also keep in mind how/if others would leverage this approach (i.e. Cloud and Dream Machine).

In the short term, it sounds like we need to get consensus on whether or not we're ok with adding the syntax sans showing tags in the UI. I think we have consensus on that being the initial version, but speak up if you disagree.

@alexfrancoeur does that work for you?

[cchaos]

Nothing in this proposal deviates so fully from the template in EUI that would make it seem unreasonable to add these updates to the EUI component. I'm excluding the search syntax from this for now as that is just a more technical request.

Icon alignment ... Here too, we may be limited by the underlying EUI component.

All you have to do to support this is to pass an iconType="empty" which will allow the space reserved for the icon to be included but no icon to show.

'Goto' ... not possible with the default rendering

The underlying component allows this to be configurable, so from the EUI side we just need to expose this at a higher level for customizing per item. Should be easy.

it appears that the highlighted/marked styles applied to keyword matches is overriding the color styles. We may need to either ask for an EUI CSS tweak here.

Yes, I think that is a text-color inheritance issue and we can look into fixing.

Tags displayed on the right ... However, here again, technically this is not something allowed by the EuiSelectableTemplateSitewide default rendering

This is the biggest change that will be needed from the EUI side. But I think we can just make it general enough that EUI provides an "area" that can be placed on the right containing anything. Or open up the area where the current Space avatar exists to be customized. Again, this shouldn't be too difficult to provide either.

---

One question I do have though, is if the designs have taken into consideration the future plans of adding the Space avatar. How will these interact?

[MichaelMarcialis]

One question I do have though, is if the designs have taken into consideration the future plans of adding the Space avatar. How will these interact?

Yeah, this is a great question, and one I had not taken into account here. Ryan made me aware of this future addition to search results after sharing these designs and it's one we'll definitely have to take into account. Does it make sense to move the space avatar to a different location to accommodate this placement of tags? The first thing that jumped to mind was presenting the space avatar in the empty icon area to the left of saved object results (assuming only one space avatar is being shown).

Further complicating matters is the fact that saved objects will be able to be shared across multiple spaces in the near future. So does that mean the same saved object appears multiple times (one for each space it exists within)? Or do we show the saved object once with multiple space avatars displayed? If the latter, which space is the user taken to when interacting with that search result?

[ryankeairns]

Some thoughts regarding Spaces:

Moving Spaces to left

• If we show separate records per Space (which seems likely given Michael's navigation point), then moving it to the left seems doable. SOs wouldn't have an icon and I don't _think_ we would show multiple apps for each Space... but maybe we would? As those are determined client side, this may not even be possible early on.

Keeping Spaces at right

• We could consider only showing the tags once context has been entered (i.e. type in tags:abc then show tags in the results)
• Further, consider only showing the tag(s) being searched upon
• If we do those things, then we likely have room to keep Spaces on the right alongside the active tag(s)
• We could also play with hiding some stuff in the focused state (e.g. keep the Space and 'Go to' but hide the tags)

[pgayvallet]

Further, consider only showing the tag(s) being searched upon

This has, imho, low value, as the info is already in the searchbar. The only usage I can see is when the user is searching for multiple (OR) tags, to dissociate the tag that returned each result.

SOs wouldn't have an icon

They actually do (well, if we want them to). I looked at the SO metadata, and we have an icon, that is currently used in the SO management section. The wiring was quite easy, and the result is:

I implemented this in https://github.com/elastic/kibana/pull/83422, but I can also revert that if we don't want it. What do you think?

Another question regarding the did you mean tag:term? suggestion when the user is typing a term that matches a tag or a type. When there are no results, we currently display the empty placeholder:

How would that work this this new 'suggestion' option? Would we be just displaying the suggestion instead?

[ryankeairns]

SOs wouldn't have an icon

They actually do (well, if we want them to). I looked at the SO metadata, and we have an icon, that is currently used in the SO management section. The wiring was quite easy, and the result is:

I implemented this in #83422, but I can also revert that if we don't want it. What do you think?

I'll be curious to check this out. The design team was instructed to steer away from these app-level icons, however the case is not closed. We've had recent discussions of potentially re-purposing these as an object-level set.

How would that work this this new 'suggestion' option? Would we be just displaying the suggestion instead?

Curious to try this one out as well. The UX here (especially as we launch without visible tags in the results) feels a bit rough with regards to how we handle/educate on the syntax keywords, and the fail state (illustration) is appearing to frequently for my taste :) This addition of this suggestion may just do the trick. The other common pattern I see is suggested text, but that feels more complicated on the surface (e.g tags:name, where :name is subdued text).

[alexfrancoeur]

Regarding launching the advanced syntax without showing tags in the results. If we showed just text of tags initially, would that be a bit easier to consume?

I really like the suggestions to help our users learn syntax and agree with @pgayvallet that it'd be good to support for type too. This might be a good way to discover the advanced syntax initially.

Related to returning results for multiple spaces, I've been trying to think through this. We either need a separate result returned for each SO, or some UX that allows you to choose the SO returned and then choose which space you want to navigate to. This feels increasingly complex for things like applications. If I type Dashboard and have 20 spaces with access to Dashboards, whats the UX? If we introduce cross-deployment results, what's the UX for that? Navigation will get overly complex pretty quickly in larger environments.

[pgayvallet]

Created https://github.com/elastic/kibana/issues/83888 for the 'suggestion option' part of this issue, as this is not only related to tag integration into the search.

[ryankeairns]

This is the biggest change that will be needed from the EUI side. But I think we can just make it general enough that EUI provides an "area" that can be placed on the right containing anything. Or open up the area where the current Space avatar exists to be customized. Again, this shouldn't be too difficult to provide either.

One question I do have though, is if the designs have taken into consideration the future plans of adding the Space avatar. How will these interact?

In response to the question about what to do with Spaces, I've added a comment with our (@myasonik @MichaelMarcialis ) initial thoughts to the _[GS] Search across Sapces_ issue.

In short, we're comfortable with using the right-hand space for tags (as proposed by Michael above) and revisiting alternatives for the cross-space UX. I've noted some of those alternatives in the aforementioned comment.

[alexfrancoeur]

With https://github.com/elastic/kibana/issues/74290 closed and merged, are we keeping this open to provide tags in the search results themselves?

[ryankeairns]

With #74290 closed and merged, are we keeping this open to provide tags in the search results themselves?

Yep. Michail is currently working on an EUI change to support this.