Add "Favorite Count" to Plugin Pages

[mrwweb]

I'd love to see the total count of favorites for a plugin. It would be one more useful piece of data when evaluating a plugin. I imagine that most people have a fairly high-threshold for favoriting and use it more as a bookmarking feature, but I think that might make it a particularly good indicator of popularity.

Here are a couple images of how that could look:

[samuelsidler]

If we do this, we'll have to be cautious of Favorite spam, or perhaps just make sure we don't use favorite data in generating search results or other lists.

[marcelomazza]

Personally I find more relevant the rating information than the favorite number. So, IMHO, what we should do is give more prominence to the rating sections. Just an idea :)

[coffee2code]

Attached 865.favorites-count.png​ as an example of a prototype I've been running locally for awhile.

[ramiy]

I think we should adopt the new "Theme Directory" design.

Large Icon, no text, no count!

[samuelsidler]

We should consider including the number of favorites; there might be a good way to do it. But either way we should also include the favorite count in the criteria when searching.

On this ticket, I think we still need UI to know exactly what it should look like. It's probably worth comparing with other sites to see what they do.

[andg]

Since the number of favorites can grow big pretty fast and knowing the exact number of favs isn't that relevant (it could be relevant to the plugin author, though), maybe the number of favorites could be shown in a plugin active installs kind of fashion, like 50+ people favorited this plugin, or something along that.

[joyously]

IMHO, since calling it "Favorite" is arbitrary (could be Bookmark or Quick Access or My List or Similar), it shouldn't be used by the search or the display of data, because each user can have a different intent when using the Favorite feature.

To get more useful data for "ranking" plugins (in regard to search results or user evaluation), it should be a computed value that only the plugin directory can compute. This would be something like a ratio of the number of downloads to the number of active installs. The two numbers aren't that useful alone, but together they give a better picture of whether people try it and delete or try it and keep it. This data can be gamed (robo-download?), but it is less likely, and when two numbers are combined, gaming the download number is detrimental to the result unless the other number is also gamed (robo-sites?).
Regardless of how the user comes to the conclusion of deciding to use the plugin, they are influencing the search results for the next guy, and not themselves (since they likely stop searching). Use of the ratio by the search would automagically incorporate user search behavior into the ranking. It is my opinion that the search results should not use an internal method to "rank" the plugins, but let the user set the criteria for how to display the relevant results. Any criteria that the search uses internally, will only further promote those plugins that are already on top.

[danieliser]

After speaking with the design team at WCUS contributor day the consensus was that this should really only be an admin facing metric. There is really no place for it in the new plugin directory other than in the admin stat section just below Active Installs on the right sidebar.

I agree that this should be as accurate as possible, but also that it will never have any bearing on search results.

It is purely a vanity metric.

I have been looking to get this one in soon, possibly before they make the switch. So if you have feedback would love to hear it now.

[dd32]

FWIW, I don't see any point in adding it as a author-only number, it should just be displayed publicly (but not used as a search signal IMHO).

Come up with a design that fits into the new directory, and it can be done, even though it's not as straight forward to count it as it should be. It won't happen until after the launch of the directory though.

[coffee2code]

#2731 was marked as a duplicate.