Search results rankings are not always what I'd expect

[Hixie]

I'm not sure what to recommend regarding the sort order of members in the search results but here are some cases where I did not get the order I expected intuitively:

• [min]: the top-level member in dart:math seems more important than the properties on classes in dart:html, but the initial list only includes the latter.
• [max]: weirdly, [max] gives a very different set of results than [min], though it also doesn't include dart:math's max which would be my top choice. I suspect most of the instances of max have a corresponding min and I would expect the results to reflect the same order for both.
• [Element]: This may seem backwards given what I just said about dart:math but I think the widgets library should take priority over dart:html in the Flutter docs.

[srawlins]

I think we currently use no heuristics regarding search order. So we're pretty free to implement anything that would improve anything 🤣 . There might be some logic about preferring top-level elements over instance methods, etc. But it's very light.

I think there is a pretty simple set of rules which would help these examples:

When documenting package X, and including the docs for other packages, Y, Z, and dart: packages:

• prefer results from package X
• then prefer results from the "core" SDK libraries: dart:async, dart:collection, dart:convert, dart:core, dart:developer, dart:math, and dart:typed_data, plus dart:ui and dart:web_ui.
• then prefer the other dart: libraries
• then prefer the other packages, Y, Z.

Maybe weights need to be used so that a top-level element (maybe json`) from an SDK library is still preferred over an instance method on a class in package X.

[Hixie]

We could try to be clever and add in some logic where members that are referenced more get higher rank, too. That would leverage the many cross-references in the Flutter docs. cc @gspencergoog

[Levi-Lesches]

On top of the above heuristics, I'd suggest, for a search query q:

1. A class that matches the whole of q
2. A top-level function/variable that matches the whole of q
3. A member of a class that matches the whole of q
4. A class that contains q
5. A top-level function/variable that contains q
6. A member of a class that contains q.

That should fix the issues with min and max

[InMatrix]

What @Levi-Lesches suggested sounds like an improvement. The current ranking method (or lack thereof) often leads to a quite broken experience. Here's what I got from searching "button":

None of the button widgets in the material library showed up on the list. We should fix this sooner than later.

[srawlins]

@InMatrix agreed. For clarity, what are the names of the button widgets in the material library? I think the top three suggestions (button, button, and button) are correct, and match @Levi-Lesches 's top three rules. Next come 7 classes that start with the word Button. What criteria would move the button widgets above those classes?

[InMatrix]

@srawlins I was looking for FilledButton specifically, but I didn't know it's full name at the time. Common buttons in Material Design also include ElevatedButton, TextButton, and OutlinedButton.

It seems that @Levi-Lesches's heuristics won't help in this specific case. I would prioritize classes over properties or provide a "widget only" filter.

I know the current search is very simple and there's no backend. If we ever add a server-side to this search box, we could rank the results using page view data from Google Analytics or ranking data from Google Search, which actually produced quite reasonable results: https://www.google.com/search?q=button+site%3Aapi.flutter.dev&oq=button+site%3Aapi.flutter.dev&aqs=chrome..69i57.7166j0j4&sourceid=chrome&ie=UTF-8#ip=1.

[srawlins]

All good ideas.

We've discussed supporting a fuzzy search too (so that a query like elevbu would find ElevatedButton), which would be very simple to implement (can use the same fuzzy search in analyzer's code completion mechanism).