517187 - Need new, consistent, and reordered set of labels (strings) for Quick Search Filters

Status: RESOLVED DUPLICATE of bug 554200

(Thunderbird :: Search, defect)

Description

[Thomas D. (:thomas8)]

There has been a couple of changes (some of them still worked on) that will require renaming the display strings we use for Quick Search Filters, and I've seen a lot of discussion and suggestions about the strings in various bugs.
I think this needs a uniform approach, rather than discussing individual Quick Search Items.

In bug 462578 (Implement "Subject, Sender or Recipient filter" to filter for full conversations), Andrew Sutherland hinted there might even be a chance to realize such string changes for TB3 RC1:
> I think we still have some latitude for string changes in the immediate future
> for rc1, but not a lot... September 29th is the current planned string freeze
> date.

Relevant developments that require string changes include:

1) BCC has been / will be included in any searches that currently have To or CC, so these need to be renamed (e.g. Bug 213318; yes, and BCCs can be anywhere, even in your inbox, as per bug 310359, comment #9 by Wayne Mery:
> which can of course these days be *any* folder, because of manual copies,
> automated copies via filters, and compose-related UI where user specifies the
> target (in my case, Inbox)

2) New quick search scopes have been / will be introduced: Most of them cover more comprehensive scopes, some of them fill the gaps for some specific searches.
- Subject, Sender or Recipient filter (bug 462578)
- All Addresses filter (bug 310359; bug 161338)
- All Headers filter (not the same as all addresses!)
- Entire Message filter (it doesn't exist yet!!! not the same as "search everywhere"; Bug 271222 with 28 votes; Bug 229142 with 16 votes; cf. 3)

3) Some existing Quick Search Strings are wrong and have to be corrected:
- "Entire Message" filter needs to be renamed, as it's only searching the message body (bug 353347)
- account for bcc's (see 1)

4) With new options added, useful order of options needs to be reconsidered (which may influence string names)

The list of bugs above is NOT comprehensive, please add relevant bugs that are about adding new searches and/or discussing the strings.

Factors to consider for good strings:
- short
- not too complex, avoid too technical
- natural language, understandable
- but still precise, avoid fuzzyness
- consider terms we use in other places of the UI: message header pane (from, to, subject...), advanced search messages (ideally should be consistent with quick search strings!), faceted search (People, involves...)
- consider a useful order (which may have implications for naming as well)

I know this is more like trying to square the circle, but still, it deserves the effort because efficient searching is one of the most important facets (pun intended...) of the application.

I started thinking about this from Bug 462578 (implement "Subject, Sender or Recipient" filter), where the current string suggestion is "Subject, Name or Address". That string in itself maybe ok, but it would be a complete alien between existing strings, as the following chart shows:

(Current strings, *bcc missing, and °bad way of introducing new strings)

Search everyhwere [new default]
------------------
Subject filter
From filter
Subject or From filter [former quick search default]
To or CC filter*
Subject, To or CC filter*
Subject, Name or Address°
Entire message filter
-------------------
Save search as virtual folder

I think in view of bcc and new search scopes, one major decision is
a) use headers as in header pane (subject, to, from etc.; need to include bcc -> gets kinda long and more complex)?
b) or rephrase and sum up in natural language?

I believe b) will be better and in line with the general strategy of TB to label things in natural language.

But let's try a) first:

Model A): Named Headers (+ bcc added, # corrected, * new)

Search everyhwere
------------------
Subject filter
From filter
Subject or From filter
To, CC, or BCC filter+
Subject, To, CC, or BCC filter+
Subject, From, To, CC, or BCC filter*
[Message header filter *]
Message body filter #
Entire message filter *
-------------------
Save search as virtual folder

It's good to use headers as in header pane, but I think with the BCC's, it's too cluttered and complex.
I like the bottom part: Message header, Message body, Entire Message. That's clear and simple, and systematic. I think both experts and average users can understand the terms well.
Here's my proposal:

Model B) Rephrased and Reordered (+ rephrased, # corrected, * new)

Search everyhwere
------------------
Subject filter
Sender filter+
Recipient filter+
Subject or Sender filter+
Subject or Recipient filter+
Subject, Sender or Recipient filter*
[Message header filter *]
Message body filter #
Entire message filter *
-------------------
Save search as virtual folder

I skipped "All Addresses filter", because I think for those who need that advanced functionality (e.g. for searching "Received" headers), "Message header filter" will do.

I reordered items in a more logical and less complex way, easier to view.
Aspects for ordering:
- single-header items first (to avoid visual clutter where each line has a different length so it looks untidy)
- logical order of headers/parts: sender before recipient; header before body
- in the same order as single-header items: add subject to single headers
- smallest scopes on top, most comprehensive scopes at the bottom:
sender < recipient
subject + sender < subject + recipient < subject + sender + recipient
message header < message body < entire message (=header+body)

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

Comment 1

[Thomas D. (:thomas8)]

For added comfort and precision, we could include the details in a tooltip for each option, e.g. for "Subject or Recipient", the tooltip would be:

Filter for messages containing "search words" in Subject, To, CC or BCC

...where "search words" would be dynamically replaced with the current search expression in quick search box, if there is one. If search expression is empty, use "search words" as string.

So technically, we'll probably want to build the tooltip from four strings:
QSTooltipPart1 = "Filter for messages containing"
QSTooltipPart2 = "search words" [default] or dynamical Quick Search expression
QSTooltipPart3 = "in"
QSTooltipPart4 = "Subject, To, CC or BCC" [can mostly use existing variables here]

This would also inform users that traditional Quick Search unfortunately handles multiple search words completely different than "Search everywhere", because Quick Search filters don't use all words as substrings (cf. SM bug 123788).

Comment 2

[Thomas D. (:thomas8)]

Bug 353347 suggests a patch to correct the wrong label for searching the body. The suggested label there is "Message body filter", which is in line with proposed Model B) of this bug's comment #0.

Comment 3

[Peter Lairo]

A few suggestions (some taken from bug 462578):

- The order should be from most inclusive or likely-of-interest (Subject, Sender, or Recipient) to less inclusive (e.g., Recipient), with "Message Body" being last (to keep all the Subject, Sender, and Recipient options grouped together). Find more stuff at top.

- Drop the term "filter" after each item. It's obvious, very hard to read, and the menu is already too cluttered. Perhaps add a line above the filters:

     "Search current view for:"

- "Subject, Sender, or Recipient" needs a comma before "or" (bug462578#63, bug462578#69, and http://www.drgrammar.org/faqs/#26).

- "To, CC, and BCC" should be called "Recipient". It's infinitely easier to read, and it's easier to grasp the meaning.

- Labels should be nouns: Subject, Body, Header (and thus) Sender, Recipient

- I agree that the list should be shortened. Perhaps:

     Subject, Sender, or Recipient
     Subject
     Sender, or Recipient
     Message Body

 Anything more detailed should go into search results/manipulation tab. We need room for later additions (e.g., Header)

- Change "Search everywhere" (which is misleading: the internet too?) to "Search all messages"

(OT) Should the search bar remember the selected filter type across sessions?

Comment 4

[Peter Lairo]

(In reply to comment #1)
> Filter for messages containing "search words" in Subject, To, CC or BCC

The most relevant info (filter criteria) is at the very end of the tool-tip. If there are many or long search words, then the relevant info will be waaay back at the faaar end. I'd not insert the search string into the tool-tip.

For some reason, "To, CC, or BCC" is *very* hard for me to read. Why not just use "Recipient"?

Comment 5

[Peter Lairo]

(In reply to comment #4)
> For some reason, "To, CC, or BCC" is *very* hard for me to read. 

I think it's astigmatism, which many have - but apparently not any programmers. ;-)

Comment 6

[Thomas D. (:thomas8)]

Added dependent bugs, please add more related bugs if you come across them.
Have a look at the sample screenshots in Bug 462578, attachment 402165 [details] and attachment 402185 [details] (including simpler tooltips): These show what I originally wanted in this bug. To compare, attachment 402635 [details] has a screenshot of where we currently are for TB3rc1 (with some of this bug's suggestions or variations thereof already implemented).

(In reply to comment #3)
> A few suggestions (some taken from bug 462578):
I widely agree with Peter's suggestions, as they're not substantially different from mine, just changing some small details. Some of our suggestions have already been implemented as part of the fix for bug 462578, so this is making progress.

> - Drop the term "filter" after each item. It's obvious, very hard to read,
Personally, I agree with that, but devs aren't ready for that yet as it's a new-born baby ;) But I feel you're right in bug 462578, comment #73:
> BTW: The word "filter" everywhere is really bothersome. I don't think it adds
> much value to real-world use. And after using the filter once or twice, users
> will quickly understand what it's doing (after all, it's a search-box, and it
> has a magnifying glass icon) - and remain bothered about the clutter forever.
BTW, mentioning the word "filter" in the tooltips of those labels (as I suggest) might help the newbies know what this is about without cluttering the labels.

> Labels should be nouns: Subject, Body, Header (and thus) Sender, Recipient
Absolutely. "Sender" should be used as a more natural noun label to refer to "From:" header (if relevant at all, rarely-used "Sender:" header - http://tools.ietf.org/html/rfc5322#section-3.6.2 - could be subsumed under the term "Sender", too, together with "From:" header, in much the same way as we currently subsume To:, CC:, BCC: headers under the natural language term "Recipient").

> - "To, CC, and BCC" should be called "Recipient". It's infinitely easier to
> read, and it's easier to grasp the meaning.
Very true. That's why I suggest "Recipient" as quicksearch filter label for current "To or CC", and we could just keep that after bug 213318 will add "BCC".
As opposed to short and natural labels for quicksearch filters, I suggest the *tooltips* of those filters should actually mention the detailed list of official headers (Subject, From, To, CC, BCC). So should one EVER doubt what "Sender filter" is really about, he'll find "From filter for current view" in the tooltip to reassure himself that we're NOT searching "Sender:" header, and we probably never have.

> (OT) Should the search bar remember the selected filter type across sessions?
It should, and it does. If it doesn't, it's most likely a bug.

That's it for now, much to the relief of readers I forgot whatever else I might have wanted to add ;)

Comment 7

[Magnus Melin [:mkmelin]]

(In reply to comment #6)
> > Labels should be nouns: Subject, Body, Header (and thus) Sender, Recipient
> Absolutely. "Sender" should be used as a more natural noun label to refer to
> "From:" header (if relevant at all, rarely-used "Sender:" header -

Re Sender - strongly disagreed. Besides, "Sender:" is fairly common.

Comment 8

[Thomas D. (:thomas8)]

In view of recent developments, I had posted bug 554200 as a followup bug.
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, 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 :)))

Good ideas don't die.

Mental note: We still don't have an "All headers" filter (for advanced users only) that searches the complete header (not just from, to, cc and bcc).

Comment 9

[john]

While there are inferences that the Recipients button should/would be so named because it includes BCC, it still doesn't into Ver. 12.   Perhaps, moving back to "To/CC", as the text, is appropriate until the various bugs are resolved, including 586101 or 213318.   

See bug 763631.

Comment 10

[Thomas D. (:thomas8)]

(In reply to john ruskin from comment #9)
> While there are inferences that the Recipients button should/would be so
> named because it includes BCC, it still doesn't into Ver. 12.   Perhaps,
> moving back to "To/CC", as the text, is appropriate until the various bugs
> are resolved, including 586101 or 213318.   
> See bug 763631.

John, pls always use "bug 586101" syntax so that autolinkification in bmo works.

Bug 213318 and Bug 763631 are duplicates of Bug 586101, which is currently in the process of being fixed. I don't think it's worth changing the caption of quick filter button for "Recipients" in the meantime because many users will not search for bcc recipients. Those who do are probably capable of figuring out that bcc is not included. Perhaps we could add tooltips to the secondary quickfilter buttons, e.g. "Recipients" button could have tooltip "From, To, or CC" for interim period (now) or, after bug 586101, tooltip "From, To, CC or BCC".