Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b2) Gecko/20100720 Firefox/4.0b2 When you start a search for add-ons, i.e. by typing "url" in the search bar and hit Return or click the magnifier glas, the results aren't sorted. The question is if we should sort by name or rating initially. I would tend to say rating, because a couple of results don't have the search string in its name but in the description. Showing up add-ons with the highest rating first, would allow users to directly install those without scrolling too much.
Summary: Search results aren't sorted alphabetically per default → Search results aren't sorted per default
They are being sorted by relevancy by default, which isn't terribly well exposed in the UI. We probably need to add this to the sort chooser for the search pane.
Assignee: nobody → bparr
blocking2.0: ? → final+
Summary: Search results aren't sorted per default → Search pane needs to expose the relevancy sort order
This is different from the rating and comes from AMO?
It is based on how well the result matches the search terms and does not come from AMO
Re-nominating for beta5 - this needs a string change.
blocking2.0: final+ → ?
So it does.
blocking2.0: ? → beta5+
Created attachment 469423 [details] [diff] [review] Patch v1 Also removed the old sort by ratings entities left over from bug 585950. Don't think it needs additional automated tests - since its just exposing something that was already working (and tested).
Attachment #469423 - Flags: review?(dtownsend)
Comment on attachment 469423 [details] [diff] [review] Patch v1 >diff --git a/toolkit/mozapps/extensions/content/extensions.xml b/toolkit/mozapps/extensions/content/extensions.xml >--- a/toolkit/mozapps/extensions/content/extensions.xml >+++ b/toolkit/mozapps/extensions/content/extensions.xml >@@ -239,33 +239,43 @@ > <content orient="horizontal"> > <xul:button anonid="btn-name" class="sorter" > label="&sort.name.label;" tooltiptext="&sort.name.tooltip;" > oncommand="this.parentNode._handleChange('name');"/> > <xul:button anonid="btn-date" class="sorter" > label="&sort.dateUpdated.label;" > tooltiptext="&sort.dateUpdated.tooltip;" > oncommand="this.parentNode._handleChange('dateUpdated');"/> >+ <xul:button anonid="btn-relevance" class="sorter" hidden="true" >+ label="&sort.relevance.label;" >+ tooltiptext="&sort.relevance.tooltip;" >+ oncommand="this.parentNode._handleChange('relevancescore');"/> Double check with Boriss whether this should go on the left or right. I kind of think that if it is going to be the default for searches then it should be the right. >diff --git a/toolkit/mozapps/extensions/content/extensions.xul b/toolkit/mozapps/extensions/content/extensions.xul >--- a/toolkit/mozapps/extensions/content/extensions.xul >+++ b/toolkit/mozapps/extensions/content/extensions.xul >@@ -210,18 +210,18 @@ > label="&search.filter2.installed.label;" value="local" > tooltiptext="&search.filter2.installed.tooltip;"/> > <radio id="search-filter-remote" class="search-filter-radio" > label="&search.filter2.available.label;" value="remote" > tooltiptext="&search.filter2.available.tooltip;"/> > </radiogroup> > </hbox> > <hbox class="view-header" pack="end"> >- <hbox id="search-sorters" class="sort-controls" sortby="name" >- ascending="true"/> >+ <hbox id="search-sorters" class="sort-controls" >+ showrelevance="true" sortby="name" ascending="true"/> Should sortby default to relevance? r+ assuming you get answers to those two from Boriss and flip accordingly.
Attachment #469423 - Flags: review?(dtownsend) → review+
(In reply to comment #1) > They are being sorted by relevancy by default, which isn't terribly well > exposed in the UI. We probably need to add this to the sort chooser for the > search pane. Yes, they should be ranked by relevancy by default, and one of the drop-down sorts at the top right should be "Keyword Match" (instead of "relevancy" for consistency with AMO). The other should be "name." The plan is to show a fixed number of results, with the final item being a link to go to AMO for complete results. Since the results don't populate further as the user scrolls down, we should be working with a fixed & sortable set. Tthe relevancy title in the top right should act as a button rather than a drop-down, since sorting by increasing relevancy is kind of useless.
(In reply to comment #7) > Double check with Boriss whether this should go on the left or right. I kind of > think that if it is going to be the default for searches then it should be the > right. Yes, it should go on the right. > Should sortby default to relevance? Yes, though the string should be "Keyword Match" to be consistent with AMO.
Talked to Blair: though "Keyword Match" is the most consistent with AMO option, "Best Match" is really a more appropriate string (a search term is not necessarily a keyword). So, let's use "Best Match" and ask AMO nicely if they could change to that too.
(In reply to comment #7) > Should sortby default to relevance? The search view automatically sets it to sort by relevance each time you do a search, so the default on the sorters widget is never actually used there.
Created attachment 470039 [details] [diff] [review] Patch v1.1 - ready for checkin
Attachment #469423 - Attachment is obsolete: true
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b5pre) Gecko/20100829 Firefox/4.0b5pre Is sorting covered by an automated test or should we have a manual one?
Status: RESOLVED → VERIFIED
Its covered by automated tests elsewhere. And I *think* there's already a manual test for the sort buttons - if not, would be good to have a manual test. Would only need to cover making sure the buttons work and look right. The order of the items in the list is already quite well tested by various automated tests - so no need to test that again. And anyway, manual testing of the relevancy order would be quite difficult, I would think.
Flags: in-testsuite? → in-testsuite+
Added Litmus test: https://litmus.mozilla.org/show_test.cgi?id=15174
Flags: in-litmus?(vlad.maniac) → in-litmus+
You need to log in before you can comment on or make changes to this bug.