517449 - [faceted search] Suggested string changes for search

Status: RESOLVED FIXED

(Thunderbird :: Search, defect)

Description

[Gervase Markham [:gerv]]

As discussed in mozilla.dev.apps.thunderbird (see there for more detailed rationale and discussion) I would like to see:

Search Box 
----------

Type "Fred Bloggs"; shorten existing text search text to the single line ->

Fred AND Bloggs

Fred OR Bloggs

Rather than caps, it would be better if AND/OR were bold, or coloured, or something. 

Results Page
------------

* The words "Filter by:" are unnecessary. A title "Filters" would be better.

* "Mail Folder" -> "Folder"

* "Mail List Involved" -> "Mailing List"

* Reduce the words in the title from

Searching for Fred and Bloggs   [ require any of the terms instead ]

to

Search: Fred and Bloggs     [ Fred or Bloggs ]

* Reduce the words in the header above the message list from:

Top 10 messages out of 28  Show all as list  sort by: relevance date

to:

1-10 of 28     As List       Sort: Relevance Date

I would prefer relevance and date to be radios, or two buttons one of which was pressed.

* Show More Hits -> "More...". And left rather than right-justify it.

Gerv

Comment 1

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

(In reply to comment #0)
> As discussed in mozilla.dev.apps.thunderbird (see there for more detailed
> rationale and discussion) I would like to see:

Thanks for all the comments!

> Search Box 
> ----------
> 
> Type "Fred Bloggs"; shorten existing text search text to the single line ->
> 
> Fred AND Bloggs
> 
> Fred OR Bloggs

This looks good to me though I'm wondering why we have this option in the auto-complete; it seems a bit excessive as these choices are always confusing for most users who haven't studied logic.

> Rather than caps, it would be better if AND/OR were bold, or coloured, or
> something. 

Agreed. A lighter color like GrayText but bold would work.  I don't mind the caps as it means something to power users; however see point above.

> Results Page
> ------------
> 
> * The words "Filter by:" are unnecessary. A title "Filters" would be better.

Sounds good

> * "Mail Folder" -> "Folder"

Sounds good

> * "Mail List Involved" -> "Mailing List"

Sounds good

> * Reduce the words in the title from
> 
> Searching for Fred and Bloggs   [ require any of the terms instead ]
> 
> to
> 
> Search: Fred and Bloggs     [ Fred or Bloggs ]

Sounds good

> * Reduce the words in the header above the message list from:
> 
> Top 10 messages out of 28  Show all as list  sort by: relevance date
> 
> to:
> 
> 1-10 of 28     As List       Sort: Relevance Date

I think "As List" needs something more like "Open as List" seeing as it opens a new tab is is often slow to open.  Otherwise this looks good to me.

> I would prefer relevance and date to be radios, or two buttons one of which was
> pressed.

I was hoping for that iPhone style radio option. :)

> * Show More Hits -> "More...". And left rather than right-justify it.

Just More seems fine but without the elipsis.  Most HIGs define the elipsis as "requires further input before proceeding" so maybe we should use one of those web 2.0 double angles. >> 

I would like to try it centered too.

Comment 2

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

Attachment: new gloda strings

Ok, here's an easy string patch that can make most of these changes happen.  I didn't move on the following changes though because I think they need a little bit more thought.

(In reply to comment #1)
> > Type "Fred Bloggs"; shorten existing text search text to the single line ->
> > 
> > Fred AND Bloggs
> > 
> > Fred OR Bloggs

I'm tempted to have this removed as it is excessive, part of faceting search is not requiring people to decide these kind of options ahead of time.  Good search systems handle this with out the question.

> > * Reduce the words in the title from
> > 
> > Searching for Fred and Bloggs   [ require any of the terms instead ]
> > 
> > to
> > 
> > Search: Fred and Bloggs     [ Fred or Bloggs ]

When I had more than 2 search terms this configuration becomes tricky.  I guess it can just be all "AND"s or all "OR"s but it makes it seem more like you should have the permutation of options available. 

e.g.
Search: facet and search and gloda  [ facet or search or gloda ]

Comment 3

[Gervase Markham [:gerv]]

(In reply to comment #2)
> I'm tempted to have this removed as it is excessive, part of faceting search is
> not requiring people to decide these kind of options ahead of time.  Good
> search systems handle this with out the question.

Indeed, but that would require more than string changes. If we can do that, great, but let's make the string change in the mean time.

> When I had more than 2 search terms this configuration becomes tricky.  I guess
> it can just be all "AND"s or all "OR"s but it makes it seem more like you
> should have the permutation of options available. 

I think subsetting your search is the right fix. If you have four words, there's no way we can present the options of:

1 & 2 & 3 & 4
(1 & 2 & 3) || 4
1 & ((2 & 3) || 4)
...

Including precedence, there must be twenty or thirty possibilities. If we must offer options at all, let's offer "all AND" and "all OR", and let people subset.

Gerv

Comment 4

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

seems like bug 515733 might have changed the Top $x of $y on us.  should double check if this still applies.

(In reply to comment #3)
> Indeed, but that would require more than string changes. If we can do that,
> great, but let's make the string change in the mean time.

We can make strings changes if needed, especially if it is the right thing to do.  

> 1 & 2 & 3 & 4
> (1 & 2 & 3) || 4
> 1 & ((2 & 3) || 4)
> ...
> 
> Including precedence, there must be twenty or thirty possibilities. If we must
> offer options at all, let's offer "all AND" and "all OR", and let people
> subset.

I'm not convinced.  This seems a bit too complicated so I'm going to leave as is and if we can work out a simple solution for the future we can move on that.

Comment 5

[David Ascher (:davida)]

Moving to blocking+ to get on string radar, although I'm not clear on what changes really block.

Comment 6

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

Comment on attachment 401564 [details] [diff] [review]
new gloda strings

lets block on this change.  I don't think the rest needs to hold back the release.

Comment 7

[Gervase Markham [:gerv]]

clarkbw: I think there's a bit of confusion here about the multiple-terms thing.

Currently, we have a wordy way of offering 
A AND B AND C AND D
or
A OR B OR C OR D

I'm suggesting we switch to a less wordy way. I think we both agree that this really should be handled internally rather than giving the user the option, but I assert that we should change the strings anyway just in case that doesn't happen before release.

No-one is suggesting that we try and offer all the permutations!

Gerv

Comment 8

[David Ascher (:davida)]

Comment on attachment 401564 [details] [diff] [review]
new gloda strings

looks good

Comment 9

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

(In reply to comment #7)
> clarkbw: I think there's a bit of confusion here about the multiple-terms
> thing.

Right, I understood but didn't mean to be terse and unclear in my comment.  I think the system of switching to OR the terms is a bit too complicated in general and would like to try a different approach.

I think we can gain more (in terms of usability) with a different approach than changing from what we have to a different text representation.  Both the current "require any of the terms" and the logical OR expression seem equally confusing; though the logical OR is likely less confusing to computer nerds so there would be a win there. :)  But overall I don't see the less wordy approach as being better for a general user population than the current approach, more likely they are very even.

I'm filing another bug on a different approach to solving this AND vs. OR issue so we can discuss that there.  I'll also file another bug for removing the match all, match any strings from the auto-complete.

Comment 10

[Simon Paquet [:sipaq]]

Comment on attachment 401564 [details] [diff] [review]
new gloda strings

Generally whenever you change strings (except when fixing typos) you should think hard about whether the change is really minor or whether its meaning is changed. Keep in mind that localizers put a lot of work and effort into localizing their products. When you do change the entity name most localizers will not notice the changes and more than 50% of our users will therefore never notice the work that you put into making these strings more understandable.

Not all, but at least some of the changes in this patch change the meaning of the string, which should correspond with a change of the entity name. This is currently not the case in this patch. Therefore it should not be checked in without a further patch iteration.

>--- a/mail/locales/en-US/chrome/messenger/gloda.properties
>+++ b/mail/locales/en-US/chrome/messenger/gloda.properties
>
> # LOCALIZATION NOTE (gloda.message.attr.folder.*): Stores the message folder in
> #  which the message is stored.
>-gloda.message.attr.folder.facetLabel=Mail Folder
>+gloda.message.attr.folder.facetLabel=Folder

You're changing the meaning here. The old string had a clear identifier for the folder. The new string does not. Please change the entity name and adjust the localization note.
 
> # LOCALIZATION NOTE (gloda.message.attr.mailing-list.*): Stores the mailing
> #  lists detected in the message.  This will normally be the e-mail address of
> #  the mailing list and only be detected in messages received from the mailing
> #  list.  Extensions may contribute additional detected mailing-list-like
> #  things.
>-gloda.message.attr.mailing-list.facetLabel=Mail List Involved
>+gloda.message.attr.mailing-list.facetLabel=Mailing List

You're changing the meaning or at the very least the structure of the string here. Please change the entity name and adjust the localization note.

>--- a/mail/locales/en-US/chrome/messenger/glodaFacetView.dtd
>+++ b/mail/locales/en-US/chrome/messenger/glodaFacetView.dtd
> 
> <!-- LOCALIZATION NOTE (glodaFacetView.showMore.label): Label at the bottom
>      of the results list to show more hits. -->
>-<!ENTITY glodaFacetView.showMore.label "Show more hits">
>+<!ENTITY glodaFacetView.showMore.label "More &#187;">

There's a big difference between the old and the new string. Please change the entity name and adjust the localization note.

>--- a/mail/locales/en-US/chrome/messenger/glodaFacetView.properties
>+++ b/mail/locales/en-US/chrome/messenger/glodaFacetView.properties

> #  application of the facet constraints.)  It takes the following arguments,
> #  you do not have to use all of them.
> # #1: The number of messages displayed in the result area.
> # #2: The pluralized form of "messages" (or whatever you provide in
> #      glodaFacetView.results.message.countLabelMessagePlurals) as it
> #      applies to #1 (the number of messages in the result area.)
> # #3: The number of messages in the active set.
> # #4: The pluralized form of "messages" as it applies to #3.
>-glodaFacetView.results.message.countLabel=Top #1 #2 out of #3
>+glodaFacetView.results.message.countLabel=#1 - #2 of #3

There's a big difference between the old and the new string. Please change the entity name and adjust the localization note.

> glodaFacetView.results.message.countLabelMessagePlurals=message;messages
> # LOCALIZATION NOTE(glodaFacetView.results.message.showAllInList.label): The
> #  label for the button/link that causes us to display all of the messages in
> #  the active set in a new thread pane display tab, closing the current faceting
> #  tab.
>-glodaFacetView.results.message.showAllInList.label=Show all as list
>+glodaFacetView.results.message.showAllInList.label=Open as list

You're changing the meaning here. "Open" and "Show" have different connotations that may be even larger in other languages. Please change the entity name and adjust the localization note.

Comment 11

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

(In reply to comment #10)

Thanks for catching this!  I often forget to rename the entities, sorry.

> 
> >--- a/mail/locales/en-US/chrome/messenger/gloda.properties
> >+++ b/mail/locales/en-US/chrome/messenger/gloda.properties
> >
> > # LOCALIZATION NOTE (gloda.message.attr.folder.*): Stores the message folder in
> > #  which the message is stored.
> >-gloda.message.attr.folder.facetLabel=Mail Folder
> >+gloda.message.attr.folder.facetLabel=Folder
> 
> You're changing the meaning here. The old string had a clear identifier for the
> folder. The new string does not. Please change the entity name and adjust the
> localization note.

That one will be difficult as it uses the name "folder" already, I'll try to figure something out.

> 
> > # LOCALIZATION NOTE (gloda.message.attr.mailing-list.*): Stores the mailing
> > #  lists detected in the message.  This will normally be the e-mail address of
> > #  the mailing list and only be detected in messages received from the mailing
> > #  list.  Extensions may contribute additional detected mailing-list-like
> > #  things.
> >-gloda.message.attr.mailing-list.facetLabel=Mail List Involved
> >+gloda.message.attr.mailing-list.facetLabel=Mailing List

This as well, we've moved more toward what the facet label actually was.  I might just remove the "-" such that it becomes mailinglist.

> >--- a/mail/locales/en-US/chrome/messenger/glodaFacetView.dtd
> >+++ b/mail/locales/en-US/chrome/messenger/glodaFacetView.dtd
> > 
> > <!-- LOCALIZATION NOTE (glodaFacetView.showMore.label): Label at the bottom
> >      of the results list to show more hits. -->
> >-<!ENTITY glodaFacetView.showMore.label "Show more hits">
> >+<!ENTITY glodaFacetView.showMore.label "More &#187;">

Might change this to "pageMore".

> >--- a/mail/locales/en-US/chrome/messenger/glodaFacetView.properties
> >+++ b/mail/locales/en-US/chrome/messenger/glodaFacetView.properties
> 
> > #  application of the facet constraints.)  It takes the following arguments,
> > #  you do not have to use all of them.
> > # #1: The number of messages displayed in the result area.
> > # #2: The pluralized form of "messages" (or whatever you provide in
> > #      glodaFacetView.results.message.countLabelMessagePlurals) as it
> > #      applies to #1 (the number of messages in the result area.)
> > # #3: The number of messages in the active set.
> > # #4: The pluralized form of "messages" as it applies to #3.
> >-glodaFacetView.results.message.countLabel=Top #1 #2 out of #3
> >+glodaFacetView.results.message.countLabel=#1 - #2 of #3

I'm tempted to change this and the one below from results.message to results.header in order to get the arrangement correct and have a new entity.

Making this "results.header.countLabel"

> > glodaFacetView.results.message.countLabelMessagePlurals=message;messages
> > # LOCALIZATION NOTE(glodaFacetView.results.message.showAllInList.label): The
> > #  label for the button/link that causes us to display all of the messages in
> > #  the active set in a new thread pane display tab, closing the current faceting
> > #  tab.
> >-glodaFacetView.results.message.showAllInList.label=Show all as list
> >+glodaFacetView.results.message.showAllInList.label=Open as list

And this results.header.openAsList


Will figure the rest out tomorrow.

Comment 12

[David Ascher (:davida)]

Attachment: More correct patch

Ok, this turned out more complicated than planned.

1) I've changed a bunch of the IDs as their semantics had indeed changed.

2) For the change from "Mail Folder" to "Folder", that proved complicated, because those string IDs are actually generated by the search results code, so as to be generic if add-ons create new facets.  In hindsight, the en-US strings were wrong, but there's no way to know whether localizers picked up on the intended semantics, or the expressed ones.  I've tried to clarify that in the localization note at the top.  In order to be safe, I've changed "facetLabel" to "facetNameLabel" _everywhere_, which includes the faceting code, as well as a facet-related bit of gloda.js.

3) bryan's patch re: the #1 - #2 of #3 bit was wrong.  He's approved the change that I have here ("#1 of #2", with no mention of the messages).

Comment 13

[David Ascher (:davida)]

Attachment: without random css change

The timeline location is off, but that's for another bug.  getting rid of css part of patch.

Comment 14

[David Ascher (:davida)]

Attachment: without random DTD change

Comment 15

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

(In reply to comment #13)
> Created an attachment (id=403290) [details]
> without random css change
> 
> The timeline location is off, but that's for another bug.  getting rid of css
> part of patch.

that's filed as bug 519253

Comment 16

[David :Bienvenu]

Comment on attachment 403291 [details] [diff] [review]
without random DTD change

taking r from dmose, r=me.

Comment 17

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

Comment on attachment 403291 [details] [diff] [review]
without random DTD change

our Open as list button is creeping in on the # of ## now so we'll need to fix that in another bug.  I think it just needs .results-message-showall { text-align: center; }

I'll take that nit on in another bug.  This is ui-r+ from me.

Comment 18

[David Ascher (:davida)]

Attachment: debitrotted patch

Comment 19

[David Ascher (:davida)]

Comment on attachment 403422 [details] [diff] [review]
debitrotted patch

no, that's not quite right.

Comment 20

[David Ascher (:davida)]

Attachment: better debitrotting

once more.

Comment 21

[Simon Paquet [:sipaq]]

Comment on attachment 403423 [details] [diff] [review]
better debitrotting

>--- a/mail/locales/en-US/chrome/messenger/gloda.properties
>+++ b/mail/locales/en-US/chrome/messenger/gloda.properties
> 
> # LOCALIZATION NOTE (gloda.message.attr.tag.*): Stores whether the message is
> #  starred or not, as indicated by a pretty star icon.  In the past, the icon
> #  used to be a flag.  The IMAP terminology continues to be "flagged".
>-gloda.message.attr.star.facetLabel=Starred
>+gloda.message.attr.star.facetNameLabel=Starred

This string mentioned in the l10n note does not match the entity name (tag vs. star). Please fix this before checking in.

Comment 22

[David Ascher (:davida)]

Attachment: fixed l10n note

nice catch sipaq.

Comment 23

[David Ascher (:davida)]

Attachment: debitrotted patch

given the low-riskness of this patch, and the deadline, carrying forward r/sr.

Comment 24

[Rain [:rain1] (inactive)]

http://hg.mozilla.org/comm-central/rev/31bcbe6377a9

Comment 25

[Francesco Lodolo [:flod]]

Why glodaFacetView.search.label is used instead of glodaFacetView.constraints.query.initial?

This is breaking localizations that were correct in beta4 (or, at least, it happened for the Italian localization.

Comment 26

[David Ascher (:davida)]

The semantics of the UI changed from being a sentence (Searching ...) to being a heading (Search).  Changing the ID seemed like the right thing.  Sorry if that's confusing.

Comment 27

[Francesco Lodolo [:flod]]

glodaFacetView.constraints.query.initial is not used anymore? Maybe a tweak to the localization notes, explaining all possible combinations, could be useful.

Is there a plan to change the layout of that page? Right now it's more like a sentence than an heading: same line and font if you search contacts/labels, only a change of color if you search terms, so a sentence-like translation seems to be the most natural solution.

Comment 28

[David Ascher (:davida)]

Sorry for the delay in answering:  I put up screenshots on  Bug 519006, which I hope will explain the change in semantics that I refer to.

Comment 29

[Francesco Lodolo [:flod]]

(In reply to comment #28)
> Sorry for the delay in answering:  I put up screenshots on  Bug 519006, which I
> hope will explain the change in semantics that I refer to.

Thanks David, that screenshot solved my doubts :-)