Search for a package with its verbatim name still does not display the package in first position

[crcdng]

When I search for flutter_animate, a well-maintained package with high stats, the default ("Sort by search relevance") search result does not display the package in first position.

Instead, it is shown somewhere down below, currently at 8th position, below a totally unrelated package named map_picker.

The expected result is:

• flutter_animate in first position
• followed by other packages that are related, e.g. with similar names.

This is a long-standing issue with pub.dev that affects numerous packages.

[isoos]

@crcdng Thanks for reporting it!

@jonasfj @sigurdm:

This seems to be a tough case, because for the given search query:

• it is not the most liked https://pub.dev/packages?q=flutter_animate&sort=like
• it is not the most downloaded https://pub.dev/packages?q=flutter_animate&sort=downloads
• it does not have maximum points (150/160) while other packages have that

I'm 95% certain that if those static analysis points were fixed, it would be on the first few spots, likely on the first.

I'm inclined to say that the points in this case are causing a bit more divide in the ranking than warranted. Maybe we should dampen the difference somehow?

[sigurdm]

To me it seems fair that the package is not at the top, given that it is not the most popular by downloads nor the most liked nor has the most analysis points. This looks like it is working as intended.

We do show the exact package name match at the top:

[crcdng]

To me it seems fair that the package is not at the top, given that it is not the most popular by downloads nor the most liked nor has the most analysis points. This looks like it is working as intended.

We do show the exact package name match at the top:

It's funny - I did not see the "Matching package names..." until mentioned.

I would still argue that a package repository should always display the (one) direct match in the first place regardless of metrics.

[sigurdm]

I would still argue that a package repository should always display the (one) direct match in the first place regardless of metrics.

I think this was once the actual behavior, and was decided against. There can be abandoned packages that happen to have squatted some keyword. They should not be shown at the top of the list IMO.

We show direct matches, and we show a ranked list of matches.

I believe having the match in the package name ranks the package slightly higher (@isoos please confirm) but in this case it seems to be not enough.

I agree with @isoos that if the package score was fixed this package would most likely rank much higher.

[isoos]

I believe having the match in the package name ranks the package slightly higher (@isoos please confirm) but in this case it seems to be not enough.

Right now it ranks the same as if the description or the topics had the same keywords, so not entirely higher. (Similar to the exact matching, this was higher before, but other search examples prompted us to lower the match significance).

[orestesgaolin]

Imho it's worth comparing to npm which despite having lower number of downloads includes the exactly matched library at the very top with a tag exact match

[isoos]

@orestesgaolin: I'd llike to emphasize again: we actually had it in the first position as part of the regular results, but then we got complaints: the package was no longer relevant for the query, despite the name match. Hence the current compromise with exposing name matches separately. It is not clear which solution is really better.

[Albert221]

Maybe introduce some threshold that decides whether the exact match is still relevant? E.g. if it got an update in the last x months, got liked n times in the last n months or something like this. So we could skip the name squats but otherwise put the exact match at the top, in a manner that we all scan for, so a normal row with package info, not a small paragraph with a small link :)

[isoos]

@Albert221: We are not removing the package from the result list. If it is relevant, it will be listed in (one of) the top position(s), and at the moment we don't have yet-another-relevancy score to up-or-downrank special cases.

[filiph]

FWIW, this has tripped me up several times as a user. I overlook the "Matching package names" line and then only see the one or two leading packages being different from what I'm searching for. I almost had a heart attack when this happened the last time — I was searching for package:xml and got this:

https://pub.dev/packages?q=xml

If you're not trained to look for the exact match line, you can easily think that the package has been discontinued or removed or something.

Only after remembering that this has happened before and scrolling down did I find the actual package.

[orestesgaolin]

I think we could rephrase this problem and ask for more explicit presentation of directly matched package. Perhaps card-like style similar to all the remaining entries could help with discoverability. This way we could avoid tweaking the search relevance algorithm and just apply relatively straightforward UI change.

Despite using pub.dev daily, I get confused all the time. It could make an interesting case in ux study ;)

[crcdng]

FWIW, this has tripped me up several times as a user. I overlook the "Matching package names" line and then only see the one or two leading packages being different from what I'm searching for. I almost had a heart attack when this happened the last time — I was searching for package:xml and got this:

exactly, the current design creates a perceptual trap similar to this one:

[filiph]

One obviously needs to take into account packages that don't "deserve" to be listed first for a given search term. For example, if there's a Foo Database and, before it gets its own quality, official API (pkg:foo_database), someone else releases an inferior pkg:foo, you don't want the exact match to be forever number one in the search results.

So this has no simple solution. But I'd propose tweaking the weight of exact match, or the formula that combines the different signals together. You generally want high quality, popular packages with exact match (like pkg:xml) appear first even when there are packages with higher scores that also match the query.

[sigurdm]

@jonasfj you looked at the top queries, and concluded that most search on pub.dev indeed is for a known package. Did I get this right?

If that is indeed true, then I agree, we should probably do either or both of

• styling the "exact match" better to make it more obvious
• giving higher ranking for a close-name-match