[GS] Register aliases or keywords for navigational search

[ryankeairns]

Is it possible or are there plans to allow us to register aliases or keywords? So ml would match machine learning

We don't have an issue for this yet, but allowing apps to register searchable 'aliases' could make sense. We could also just search the app's id in addition to its title. If we do it, that will be in a follow-up though.

Originally posted by @pgayvallet in #72331 (comment)

---

I have serious reservations about doing this in this PR. Without it being centrally managed, it seems potential issues could develop if/when authors are potentially competing for the same or simliar keywords.

I share similar concerns, most from a UX perpsective. I think we want to be careful to make the search results pretty consistent between versions since users are going to build muscle memory and usage habits based on these results. So if we're going to introduce new concepts like actions or reserve keywords for specific items, we should be fairly confident that these aren't going to change significantly with each release. Fine-tuning over time is to be expected, but I don't think we want to drastically change the interactions or ordering of results on a regular basis.

All that to say that if we're going to add additional keywords for this Lens result to match on, we should be confident that this fits into the longer-term vision of how we want Global Search to respond to user input over the next few releases and that anything we match on today isn't going to be removed in the near-term.

_Originally posted in #77448 (comment)

[elasticmachine]

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

[sorenlouv]

This feature would be very useful to APM. We'd like to register terms like "Traces", "tracing" and "distributed tracing" as aliases for APM.

Am I correct in understanding that until this is built-in we can register aliases using the registerResultProvider hook?

[elasticmachine]

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

[ryankeairns]

@pgayvallet or @joshdover , can you answer @sqren 's question regarding the current state of aliases for search?

[tbragin]

Big +1 on this one for observability. Some examples -- searching for "application" should find "APM", searching for "monitoring" should find some of the apps under "metrics", etc..

[pgayvallet]

As application results are computed from the public info of the registered apps (accessible via the application.applications$ core API), I think the only technical option we have to allow registering 'keywords' for individual applications would be to add new field(s?) to the core App type. As this new 'keyword' concept is not data, but metadata, I would avoid polluting the root type and create a nested meta property.

Registering keywords for an app would be done that way:

core.application.register({
  id: 'myApp',
  title: 'Translated title,
  mount,
  meta: {
     keywords: ['tracing', 'distributed tracing']
  }
})

I already shared my questions / concerns regarding executing the search against other fields that the app's title here: #81352 (comment). These questions are the same for this option:

• we would need to think a little about sorting/scoring, as apps can now be returned because either their name OR their category's name matches.

• We would not be highlighting the matching term in the app's name, as it would match the keyword instead. We probably want some design change to reflect that an app is displayed for another term than its name.

Without it being centrally managed, it seems potential issues could develop if/when authors are potentially competing for the same or simliar keywords.

I also have a strong +1 on that. #81352 is about searching app by already existing 'fields' such as its category's label. Allowing developers to manually choose keywords means the GS api does not have full control about the results displayed.

There is also a question about performances here. App matching is done on the client-side, using a lev-distance algorithm. Having to compute the distance against one term, is something. Doing is against an arbitrary number of keywords might cause perf issues on the client-side (did not benchmark though)

[joshdover]

cc @TinaHeiligers

[alexfrancoeur]

@TinaHeiligers as part of your PR did we add any aliases or just the capability to register them? Also, how do they play with relevance ranking?

[TinaHeiligers]

@alexfrancoeur I only added the capability to register them.
We decided to go for a reduced score when matching by keywords (a.k.a aliases), weighting the score 20% lower than a match by title.
We used the same algorithm to match by keywords as by titles, hence the simplistic approach of reducing the match-weight.

[alexfrancoeur]

@TinaHeiligers @joshdover do we have plans to communicate this capability to relevant stakeholders in a similar fashion as with deep links?

[TinaHeiligers]

GS was somewhat deprioritized after this work was completed and we haven't made much noise about the new capability.

@alexfrancoeur @joshdover Should we open a meta issue and ping specific teams about the new capability to register keywords/aliases for their apps or add a comment to the next Kibana Contributors newsletter?

If the former, are there any specific teams we should notify?

[rudolf]

Setting to "Close as not planned" to clearly signal that although we've added the capability we don't yet have any plugins registering such aliases.

[TinaHeiligers]

Setting to "Close as not planned" to clearly signal that although we've added the capability we don't yet have any plugins registering such aliases.

so sad...