https://openui5nightly.hana.ondemand.com/#/search/QuickViewGroupElementType
The search result page includes all mentions of the searched query. In the above case, the API reference page of sap.m.QuickViewGroupElement should be included in the result page as well.
The result page doesn't show everything even though the search query is clearly mentioned in other locations within Demo Kit.
It would be nice if the global search is enhanced / fixed so that users can easily find out where the entered (enum) type is used. Currently, this doesn't work.
For example, how can I find easily all uses of a certain type like sap.m.Button?

"target conflict" :-(
We intentionally left out signatures (including types of settings) from the search index as this creates a huge noise in the search results. It's IMO hard to judge (by built-time code) whether a page helps to explain a symbol or not. In this case, the usage of the GroupElementTypemight be helpful for you. But would all the search hits for sap.ui.core.CSSSize be helpful to learn something about CSSSize? I don't think so.
Until someone suggests a clever (and feasible) way to distinguish the two cases, I would vote not to change this.
But there's something else that IMO is missing in the SDK: a "where used" information. Would that have helped you in this case?
I understand, however, that using a single mechanism "search" is far more convenient than first deciding whether "search" or "where used" is more appropriate. Mhmm, maybe the "where used" could be integrated in the search as a fourth tab. It would only show up when the search topic names an API entity (or parts thereof). Just thinking...
But there's something else that IMO is missing in the SDK: a "where used" information. Would that have helped you in this case?
Definitely, and I agree. I often want to find out "where is this and that used"? But then I end up searching on GitHub instead.
I understand, however, that using a single mechanism "search" is far more convenient than first deciding whether "search" or "where used" is more appropriate.
True. Although personally, I'm fine with "where used" being separated from the search page as long as there is a way to get the information conveniently within the SDK. But for now, I like the idea to have an additional tab in the search page. Curious what others think. This needs some discussion I guess.
Thank you for the initial thoughts!
Hi @boghyon,
As @codeworrior has answered your questions, i will close this incident.
Best Regards,
Gery
@codeworrior Are method descriptions also intentionally left out from the global search? Because when I searched by "InstanceManager" (after I failed to find it from the API Reference), the results were quite empty.

I expected at least the sap.m.MessageBox to be included in the search results but it wasn't there even though it mentions "sap.m.InstanceManager" in one of its method descriptions
No, definitely not. If you search for the word "tapping" which is used in the same description as InstanceManager you'll also find the MessageBox among the search hits.
I guess the reason why InstanceManager is not found might be a too aggressive cleanup of the input text. Maybe all tags together with their content are removed (...InstanceManager...), but that's just a guess. I'll look into it and let you know.
_"A dot is a dot is a dot"_ (based loosely on this one)
My guess was wrong, it's not a cleanup issue. When you search for "sap.m.InstanceManager.closeAllDialogs", you'll find the expected hit in MessageBox. The indexing currently doesn't understand what it is indexing. Qualified names look all the same for it, it is not able to split "sap.m.InstanceManager.closeAllDialogs" into class name and method name.
I think we can improve this. At least in the context of a @link tag, we should be able to recognize cross references and handle them accordingly.
Most helpful comment
_"A dot is a dot is a dot"_ (based loosely on this one)
My guess was wrong, it's not a cleanup issue. When you search for "sap.m.InstanceManager.closeAllDialogs", you'll find the expected hit in MessageBox. The indexing currently doesn't understand what it is indexing. Qualified names look all the same for it, it is not able to split "sap.m.InstanceManager.closeAllDialogs" into class name and method name.
I think we can improve this. At least in the context of a @link tag, we should be able to recognize cross references and handle them accordingly.