554200 - Simplify labels for Quick Filter Options by using consistent natural language terms (Subject, Sender, Recipient, etc.)

Status: RESOLVED FIXED

(Thunderbird :: Search, defect)

Description

[Thomas D. (:thomas8)]

+++ This bug was initially created as a clone of Bug #517187 +++

This is a transition223 issue because we have added new options to the Quick Filter dropdown list; for the now longer list, it's even more important that it should be simple and understandable for non-techie human users.

STR

1) Have a look at current Quick Filter Labels:

Subject, From or Recipient Filter
Subject or From Filter
Subject, To or CC Filter
Subject Filter
From Filter
To or CC Filter
Message Body Filter
Entire Message Filter

Actual Result
- Avoidable confusion and complexity
- Weird mix of natural language and tech-terms (e.g. "From" as a preposition and technical term is both grammatically and structurally in a totally different category compared to "Sender" and "Recipient" as natural language nouns).
- wonder if developers had a bad day when they created/accepted this conglomerate

Expected Result
- Natural language, terseness and simplicity
- Less is more
- Pragmatism instead of nit-picking
--> Simplify those labels, like this:

Proposed new set of labels (simplified, consistent, natural language)

Subject, Sender or Recipient Filter
Subject or Sender Filter
Subject or Recipient Filter
Subject Filter
Sender Filter
Recipient Filter
Message Body Filter
Entire Message Filter

Compare this with the current set:
- Which set is easier to parse, visually?
- Which set will be better understandable for average user?
- Which set reveals the significant differences between these options more clearly?
- Which set feels like it's consistent and naturally worded?
IMHO the answers to all of these questions is obvious.

Interestingly, while EN stubbornly sticks to the old set, Translations like German have already moved on to the new set that's proposed here:

Filtern: Betreff, Absender oder Empfänger
Filtern: Betreff oder Absender
Filtern: Betreff oder Empfänger
Filtern: Betreff
Filtern: Absender
Filtern: Empfänger
Filtern: Nachrichtentext
[...]

This is interesting in that the German translators didn't even bother translating the conglomerate we have in EN, but decided on their own to do the only sensible thing: Make it simple, short, and understandable (as proposed in this bug). (Side note: I am not a German translator, and I didn't influence them in any way).

Refuting counter-arguments
a) "We can't use "Sender" (instead of from) because it could be confused with the actual header "Sender:" that's officially in the RFCs.
-> Answer: Nonsense!
Sender: header isn't implemented in Thunderbird's UI (try to compose with using Sender:), and I haven't come across any mail program where it is. Even if there might be some, the vast majority of users has no idea of this obsolete header (read the rfc and you'll know why no one ever uses this). But first and foremost, this nit-picking approach applies only to EN because it happens to be the language of the protocol. In all other languages, this simply doesn't apply: E.g. German has "Absender" for English "Sender". Therefore, it would be completely non-sensical to force German into translating "Subject, From, or Sender" to "Betreff, Von, Empfänger" (gosh, it sounds awful). But as a matter of fact, English happens to be the role model for translations. So the English labels should also be chosen with translations in mind.

b) we can't use "Recipient" for all relevant options because some of them don't include bcc yet.
- true, but that's really nit-picking. We have never had quick filter support for BCC yet, and we can safely assume that quick filtering for bcc is something 98% of users will never ever do. They can, if they want, in "Advanced Search". We should also fix quick filters to include bcc's, and we have bugs for that.
But in the meantime, it's really not worth having the bad labels for everyone, just for the sake of formal precision. Let's have good and easy labels now, and deal with the backstage nits lateron.

I am proposing this enhancement on the assumption that bug 545955 is not very likely to happen very soon, so we should try and improve things until such time when bug 545955 will probably obsolete the whole issue by removing the quick filter dropdown and changing it into a quick filter bar. Btw: Guess what, Mozilla's Andrew Sutherland, who is working on the filter bar, chose these as filter facets:
Subject, Sender, Recipient, Body. As proposed by this bug. I wonder why.

We need to decide on this quickly if we want to get this in for TB3.1.

Comment 1

[Thomas D. (:thomas8)]

Attachment: Urgent: Simplify Quick Filter Labels by using consistent natural language terms (Subject, Sender, Recipient etc.)

Comment 2

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 434094 [details]
Urgent: Simplify Quick Filter Labels by using consistent natural language terms (Subject, Sender, Recipient etc.)

I think this has promise but I'm not really inclined to change the strings as I'm assuming that bug 545955 will continue to block the release and eventually land with new strings.   So I'll put a minus for now and we could revisit (before string freeze) if bug 545955 doesn't end up landing for some reason.  Otherwise the l10n people will be annoyed that we changed strings and then removed them all a week later.

Comment 4

[Thomas D. (:thomas8)]

Meanwhile, the new, consistent and natural language set of quick filter strings
(as requested by this bug) has been implemented by the new quick filter bar (as of TB 3.1RC1), which turned the quicksearch dropdown into a more intuitive secondary filter modification bar (bug 545955), with the following wording on filter buttons:

Sender - Recipients - Subject - Body

As proposed by this bug :)))
Good ideas don't die.

-> FIXED by bug 545955.

Mental note: We still don't have an "All headers" filter that searches the *complete* header (not just from, to, cc and bcc), but not the body. Not sure if that's really needed, it's definitely for advanced users only. We may or may not wish to add that one day to the traditional "Search Messages" dialogue as a search range.