663859 - persist date and relevance setting in facet search results

Status: RESOLVED FIXED

(Thunderbird :: Search, enhancement)

Description

[Wayne Mery (:wsmwk)]

persist date and relevance choice/setting in facet search results. if a user selects a different choice, it should persist for future searches.

requested in http://getsatisfaction.com/mozilla_messaging/topics/default_search_result_by_date

Comment 1

[sunk818]

Thank you. Relevancy as the sort method in results is often not the  is not the ideal sort method in many instances.

Comment 3

[bill9]

This is NOT  duplicate of "Duplicate of this bug: 680168", because this one came first.

However, the fact that duplicates are being entered is information to change the default to "date". I have used thunderbird almost as long as there has been a thiunderbird, use search constantly, and have NEVER had "relevance" produced results that are in fact more relevant. 
I was about to submit yet another duplicate.
This has been in the system for almost 2 years. 
How long till someone takes the 5 seconds to fix it?

One should not confuse the intent with the result. "date" produces at least a well defined and understandable result, which is often the desired order. Probably "recent" tends to be more relevant than any other test that can be mechanically applied. 

Which is to say, "date" produces a more relevant order than "relevant" does,
most often.

So how about listening to the users and setting the default the way they want it, its a 5 second fix.

Alternatively, let it be "sticky" and remember the last setting.
Or go all out and allow selection of default. Maybe a little checkbox for
"make this the new default".

But before wasting valuable time on that, perhaps there is no case for keeping "relevant" at all? How does it tell what is relevant? I doubt I could hand someone results more "relevant" to someone's intentions, and I can almost speak the language. This seems to be copying shopping carts, which don't have a useful relevance check either, they just put up what they make more money selling. 
Not invalid for commerce, but copying the poor design doesn't leave. any room for
deciding what is relevant. If I search for "blue" what is relevant? color, sadness? Its nonsense because no one knows what it is doing except the guy who wrote some arbitrary relevance test. Generating a number is easier than generating a meaningful number. A better argument can be made for removing "relevant" altogether, because its not actually relevant :-).

Comment 4

[sunk818]

(In reply to bill9 from comment #3)
> This is NOT  duplicate of "Duplicate of this bug: 680168", because this one
> came first.

I think you and Wayne are in agreement. The wording may be confusing, but it is saying that this Bug 663859 is the original report and that 680168 will be marked as resolved because it is a duplicate of this Bug report.

Otherwise, I agree with the sentiment of your post.

Relevancy makes sense when searching Google. When searching e-mails, the relevancy is often a sorted Dated (I prefer descending).

Comment 9

[Anje]

I report this bug 5 years ago. see bug 947268

I'm now using 52.9.1 and naturally the bug still exists.
I'm aware that as a Vista user I'm stuck with bug or use an addon or get a newer OS.

However, that addon is currently not suitable for those using version 60 onwards.

Over the years various people in forums have asked how to get this annoying problem resolved.
The support forum is still getting requests on how to fix this issue.
Is there someone who could please look at this bug as there is currently no addon that can fix it?

Comment 11

[Anje]

Thunderbird Support Forum: https://support.mozilla.org/en-US/questions/1236892#

Comment 12

[CC]

In case anyone finds this bug, I have maintained an add-on for this issue for 9 years. It's called "Search Results Sort By Date Not Relevance" and is available at addons.thunderbird.net: https://addons.thunderbird.net/en-US/thunderbird/addon/srsbdnr/

For developers: the add-on has traditionally had almost 5k daily users (and will again soon, I imagine, now that I finally updated it for v68). I know that's relatively few, but maybe it's enough for this bug/enhancement to be prioritized?

Perhaps a poll could be conducted to see what the average user prefers?

In case it's helpful to anyone considering a patch, AFAIK the default could be permanently changed by changing the five lines starting here: https://hg.mozilla.org/comm-central/file/d7074a5597c76e36322ee3af1198b803cca24eb4/mail/base/content/glodaFacetView.js#l545

...to be simply:
this._sortBy = "-date";

Comment 13

[CC]

Attachment: Bug 663859 - persist user choice of gloda facetview search sort order, with optional forcing of setting

Comment 14

[CC]

Hello - I have implemented a fix for this bug and generated a phabricator revision: https://phabricator.services.mozilla.com/D74731

This is my first-ever patch, so I'm sure I did something wrong somewhere. :-) But I have tested the fix (on linux) and it works for me.

It creates a new pref: gloda.facetview.sortby, default value, where the values correspond to this behavior:

0 : same as old behavior: every search opens with "relevance" sort order
1 : same as 0, except every search opens with "date" sort order
2 : [default] new searches sort by relevance, but if user changes to "date", this pref changes to value 3
3 : new searches sort by date, but if user changes to "relevance", this pref changes to value 2

If I have left out any steps here (especially with phabricator, as I have only the faintest notion of the proper procedures there) I'd appreciate any guidance. E.g. will this automatically get reviewed, or do I need to take additional steps?

Comment 15

[CC]

Attachment: Bug 663859 - persist user choice of gloda facetview search sort order, with optional forcing of setting r=aleca

Comment 16

[Alessandro Castellani [:aleca]]

Comment on attachment 9158074 [details]
Bug 663859 - persist user choice of gloda facetview search sort order, with optional forcing of setting r=aleca

[Approval Request Comment]
Regression caused by (bug #): none
User impact if declined: not major as it's kind of a marginal feature, but since it's a 9 years old request, it would be nice to ship it in 78.
Testing completed (on c-c, etc.): soon on c-c
Risk to taking this patch (and alternatives if risky): low as it doesn't affect strings and it only adds a pref to remember gloda search setttings

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/3b00131dbe1d
persist user choice of gloda facetview search sort order, with optional forcing of setting. r=aleca

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/9494e0c41d2c
follow-up: Fix linting errors. rs=linting

Comment 19

[Wayne Mery (:wsmwk)]

Comment on attachment 9158074 [details]
Bug 663859 - persist user choice of gloda facetview search sort order, with optional forcing of setting r=aleca

Approved for beta - let's get this into 78

CC thanks for the patch!

Comment 20

[Geoff Lankow (:darktrojan) [PTO, back 8 Dec]]

Comment on attachment 9158074 [details]
Bug 663859 - persist user choice of gloda facetview search sort order, with optional forcing of setting r=aleca

This is already in comm-beta (79), changing the flags for uplift to 78.

Comment 21

[Wayne Mery (:wsmwk)]

Comment on attachment 9158074 [details]
Bug 663859 - persist user choice of gloda facetview search sort order, with optional forcing of setting r=aleca

Approved for esr78

Comment 22

[Rob Lemley [:rjl]]

Thunderbird 78.0.1:
https://hg.mozilla.org/releases/comm-esr78/rev/d25d26fe1df4
https://hg.mozilla.org/releases/comm-esr78/rev/15cd2997978f