Closed Bug 282696 Opened 20 years ago Closed 19 years ago

"most popular" should sort by <downloads this week> not <total downloads>

Categories

(addons.mozilla.org Graveyard :: Public Pages, defect)

x86
All
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: antonsforums, Assigned: morgamic)

References

()

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7.5) Gecko/20041107 Webunicorn/1.0 (Firefox/1.0 polymorph)
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7.5) Gecko/20041107 Webunicorn/1.0 (Firefox/1.0 polymorph)

The title says it all, really. It appears that sorting Firefox extensions by
popularity yields results based on downloads per week. I can see no good reason
for this. The listings would be far more stable if total downloads were used as
the metric. (I would imagine that for most extensions, download numbers do not
increase linearly with time, and so we have extensions significantly jumping
about from day to day.)

On a related note, the use of the word "popular" is slightly ambiguous, because
it is not explitly clear what it refers to on u.m.o. It should be clarified that
it refers to download numbers.

Reproducible: Always

Steps to Reproduce:
If we sorted by Total Downloads, then something that has been around for 6
months and has 10 versions would be considered more popular than something that
has been around for 1 month and has 1 version.

The page title is ambiguous and should have a description.
I see alanjstr's point, but I also don't think that simply the past week is good
as it favors new/newly updated extensions over old but popular ones. Perhaps
until someone comes up a with a good algorithm for it, they could be listed by
taking whatever version of the extension has the most downloads, and using that
to calculate popularity? This has problems of its own, but fewer, it seems.
OS: Windows ME → All
Or we could just provide both (Example of use can be seen at http://download.com)
Assignee: Bugzilla-alanjstrBugs → morgamic
QA Contact: mozilla.update → web-ui
https://addons.mozilla.org/search.php?app=firefox&sort=downloads is the link from the frontpage now :)
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Oh dear me. You actually did this?

This is ridiculous.

Sorting by total downloads is completely meaningless! I don't care much about the front-page/RSS list, but there is no point sorting search results by total downloads. At the absolute minimum, add an extra option to use the weekly count.

I should point out to dolphinling that upgrades via Firefox do NOT count at all (unless something drastic has changed) and an extension only stays on the recently updated list for a few hours.
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
We should undo this (possibly inadvertent) change, indeed.  Downloads-per-week is a bad enough metric, but downloads-since-the-dawn-of-time is worse still.

Assignee: morgamic → nobody
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: "most popular" should sort by <total downloads> not <downloads this week> → "most popular" should sort by <downloads this week> not <total downloads>
Target Milestone: 1.0 → 2.1
Assignee: nobody → morgamic
Status: NEW → ASSIGNED
Ok, so here are the sorts I can see us having:
* Newest, sorted by creation date
* Updated, sorted by updated date
* Rating, sorted by rating
* Popular, sorted by weekly download, then rating ???

We could just drop Popular, if that is what people want.  The fix itself is pretty simple.

What do you guys want to see?
The popularity (as measured by weekly downloads) is good enough for the front page, it should be good enough for search. I don't see any need to drop it.
Fair enough -- this fix will get pushed with the next batch.
Was pushed a while back -- resolving.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
Target Milestone: 2.1 → ---
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: