Emphasise a current popularity metric instead of total downloads

[adamralph]

"Total downloads" seems to be the currently emphasised metric. For example, when I browse to my profile page, the packages are listed in descending order by number of total downloads. The preview tile for each package also shows the number of total downloads.

I propose that number of total downloads is not the most interesting metric, and certainly not the metric which indicates which packages are "hot". The more interesting metric is average downloads per day. I'll explain why. The number of total downloads is heavily influenced by the length of time a package has been on the gallery.

For example, https://www.nuget.org/packages/LiteGuard.Source/ only gets 9 downloads a day, but it's been on the gallery since early 2013, so it currently has around 21K total downloads. On the other hand, https://www.nuget.org/packages/MinVer/1.0.0 currently gets 77 downloads day (more than 8 times as many as LiteGuard.Source) but because it's only been on the gallery since late 2018 (6 months) it only has 15K downloads.

Currently, LiteGuard.Source is sorted above MinVer on my profile page, but it's clearly the less popular package. MinVer is more than 8 times as popular, as proven by its downloads per day.

I propose the following (for all relevant pages in the gallery, not necessarily just profile pages):

• Add downloads per day to the package tile and emphasise it. E.g.
• Change the descending sort order to be based on avg downloads per day instead of total downloads.

[joelverhagen]

Great idea! Thanks for the suggestion. As far as I can remember right now, the profile page is the only one that is sorted just by simple total download count. Search (which is being improved right now) takes your search term into account as well as downloads and other factors we are considering.

Another way of getting hot packages to stand out is total download count over the past N days.

One question I have is this: as a package CONSUMER do you use the profile page for discovering new packages that you don't know about yet? Or for finding a package ID you forgot? Or something else?

Above you mentioned your own profile page. As a package AUTHOR how do you use your own profile page? I feel like in this scenario (package author on his own page) we may have to guess the sort order.

Perhaps on profile page we just need a drop-down so you can pick the sort order... Needs more input from users perhaps.

In short, it's not clear to me yet how people use the profile page and the right sort order may vary from use case to use case.

[adamralph]

One question I have is this: as a package CONSUMER do you use the profile page for discovering new packages that you don't know about yet? Or for finding a package ID you forgot? Or something else?

I use it to see what are the most interesting packages produced by that author/organisation. If package net-hotness has 1,000 downloads a day but has only been on the gallery for one month, I want to see that before package old-dinosaur that's been on the gallery for 5 years but only has 20 downloads a day (currently the old-dinosaur would show before new-hotness).

Above you mentioned your own profile page. As a package AUTHOR how do you use your own profile page? I feel like in this scenario (package author on his own page) we may have to guess the sort order.

I want to use it to see which of packages is most interesting to the community, but currently, it's highly skewed to which packages have been on the gallery the longest. It's effectively the same use case, and the same problem, as when I'm browsing as a CONSUMER of someone else's profile page.

Perhaps on profile page we just need a drop-down so you can pick the sort order... Needs more input from users perhaps.

Yes, that could work.

Another way of getting hot packages to stand out is total download count over the past N days.

I think I prefer avg downloads per day. The number of downloads over the last N days can be erratic, and it an even shorter term metric. The avg downloads per day still take into account the historic value of a package, even if it's popularity is tailing off. Just by taking into account length of time on the gallery, it's already a more interesting metric than an absolute number of downloads.

---

Perhaps this issue should be split into two?

• Add avg downloads per day to package tiles (in all views)\
• Sort profile pages by avg downloads per day

[joelverhagen]

Perhaps this issue should be split into two?

• Add avg downloads per day to package tiles (in all views)\
• Sort profile pages by avg downloads per day

Maybe keep them as one for now.

@anangaur @karann-msft, thoughts?

[anangaur]

IMO total downloads doesn’t even make sense. It’s a vanity metric for authors 🙂. From consumers, a recent download metric makes sense like weekly or monthly download count. We can do away with other metrics on the details page and put them into stats, if required

[anangaur]

For profile page too we could have monthly/weekly downloads along with total downloads for the packages. And sort them by monthly downloads descending

[adamralph]

To clarify, does "monthly/weekly downloads" mean downloads in the last month/week, or average number of downloads per month/week?

[anangaur]

Last one month/week as it reflects the current popularity

[adamralph]

OK, but in that case I would propose using month as the primary metric. One week could be too erratic.

[anangaur]

OK, but in that case I would propose using month as the primary metric. One week could be too erratic.

Agree 👍

[adamralph]

What is the current status of this?

[skofman1]

@adamralph , we have added this to our backlog. We will prioritize the work based on the other items we got.

[adamralph]

Any movement?

[chrisraygill]

Hi @adamralph, we haven't been able to prioritize this work yet, but we still believe that it's important and will likely improve our search relevancy. I will update this issue we get started on this feature 😊

[adamralph]

Is there anything I (or anyone else) can do to help get this prioritised?

[joelverhagen]

Hey @adamralph, apologies on the day in responding here. Generally speaking, this is something we're interested in the potential of. However we haven't had the time to formalize any particular ideas or a proposal. Today our stats pipeline has some scalability issues but we're in the process of modernizing how we ingest download logs and process them into reports. In other words, potential blockers we had in the implementation will soon be going away so I think it's a good time to at least start a conversation about what this change would mean for NuGet.org.

Is there anything I (or anyone else) can do to help get this prioritised?

I'm glad you asked 😃. In the past 6 months or so, we have formalized the proposal process so that changes to NuGet.org or to NuGet client software can be spec'd in the open and we can gather feedback from the community more easily. Would you be interested in creating a proposal spec, per this guide? https://github.com/NuGet/Home/blob/dev/meta/README.md

Here are some open PRs on NuGet/Home, many of which are other public NuGet proposal (some by the team, some by external contributors like yourself): https://github.com/NuGet/Home/pulls?q=is%3Aopen+is%3Apr

In short, a great thing you could do to help get this prioritized is to create a proposal of the change in experience that you'd like and we can discuss on the proposal PR.

Some questions to consider for your proposal:

1. What time window do you think makes sense to calculate the average over?
2. Should this change only affect the NuGet.org UI? Or should it also affect search ranking? (We have to be careful with search ranking)
3. What are all of the specific places that need to show this new average? Some places have more visual space than others.
4. How would this change get plumbed down into the Visual Studio client, if at all? Roughly 90% of the NuGet searches performed against NuGet.org are actually done in the Package Manager UI in VS, but VS changes are hard to land and nearly impossible to revert 😃 (so higher risk).

[adamralph]

@joelverhagen thanks very much for the detailed response.

Initially, I was thinking of only a baby step — changing the profile page to default to sorting packages by the number of downloads in the last 6 weeks, with an option to switch back to sorting by total downloads. For example (hacked in with no explicit consideration for styling):

BTW I'm using 6 weeks as an example because the package stats pages are already for 6 weeks, so users are already primed to think of 6 weeks as being current/recent.

[adamralph]

@joelverhagen apologies, please disregard that last comment in favour of this one. I got my wires crossed with a different idea. I believe the following is better:

Initially, I was thinking of only a baby step — changing the profile page to default to sorting packages by the average downloads per day, with an option to switch back to sorting by total downloads. For example (hacked in with no explicit consideration for styling):

[joelverhagen]

I like it! One thought is that the (somewhat similar) package search page has a filter expander with more options which feel a bit like your suggested dropdown. Perhaps we should just extend that experience and add it to the profile page? Just a thought, feel free to take your proposal document any direction you want.

Could you open a proposal PR? It can be relatively small, if you want to scope it to something minimal right now.

Once there's a proposal PR, we can boost the visibility on Twitter and gather broader input from the community. We've found a PR is a better place for these sort of discussions since we can comment on specific parts of your idea more clearly. Also, it's a lot easier for newer people in the community to understand if there's a document that can be read instead of a mega issue comment thread 😅.

[anangaur]

/cc: @jcjiang

@adamralph, any reason why you switched the popularity metric?

I think avg. downloads per day may still be skewed to show high number for really old packages that initially had very high downloads but not any more. In that way, I somehow liked the "downloads in last 6 weeks" as it's a better indicator of recent popularity. Thoughts?

[adamralph]

@anangaur fair enough, maybe "downloads in last 6 weeks" is indeed better. Or perhaps we can provide both. I'll open the proposal PR ASAP.

[adamralph]

FTR this hasn't been important enough for me to dedicate the time to raise the proposal PR and I currently have no intention to do so.