516261 - [faceted search] further improvements to search results look&feel

Status: RESOLVED FIXED

(Thunderbird :: Search, defect)

Description

[Andreas Nilsson (:andreasn)]

Spun off from Bug 515653:

The blue subject text on grey background when hovering over a message actually decreases the contrast, which feels off. Maybe a darker shade of blue?  Maybe a lighter background? Maybe a more sophisticated border with a very light background?

Comment 1

[David Ascher (:davida)]

A few other thoughts:

1) the current top part of each result is really crowded

2) we will want to be able to highlight text matches in the subject, body, attachment names and maybe people -- so it'd be good if the design didn't use bold for any of those (although we could use a different text color or a background color to highlight them if necessary)

3) some messages have really long subject, so we want at least up to two lines as part of a normal flow.

4) this is a search UI, so we don't need to worry too much about displaying email addresses -- names are likely much more useful to most search queries.

5) metadata we want to display: attachment names, tags, and star status.  (possibly "in trash", and "marked as junk"?)

Comment 2

[Andreas Nilsson (:andreasn)]

Attachment: mockup with colors and position of elements

We could do the message header as one line and the other stuff as another line beneath it. As it is now, the header tends to always split into two lines, making it slightly harder to read.
As seen in the mockup, both could split into two lines if needed.

Comment 3

[Andreas Nilsson (:andreasn)]

Attachment: mockup with same as above, but repositioned additional data

Another approach would be to place the "other" data beneath the message. This would help in the case of long subjects.

Comment 4

[Andreas Nilsson (:andreasn)]

Blue is #3465a4 and hover-gray is #e5e8e3

Comment 5

[David Ascher (:davida)]

I think 400501 isn't the right attachment.  try again?

Comment 6

[Andreas Nilsson (:andreasn)]

Attachment: this should be the one

this should be the right mockup

Comment 7

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

Attachment: gloda search results cleanup

here's my patch to clean up the search results.  I tried to use a similar design pattern as we have before on the multi-selection and collapsed threads.

* bold is only used to indicate result matching
** for other areas this was unread
** for search results we should bold matching parameters

* use color and larger font for subjects to differentiate

* make result text selectable

* make subject click target

* keep sender and date information clear and to the right for easy scanning
** i think we'll also want to clear new click targets for senders to say (from this person or not)

* push attachments off to the right hand side so they are more visible against the likely white space

Comment 8

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

Attachment: screenshot of patch in action

here's a screenshot of the patch with various search results to test.

basic layout of the message is this:

(s) $subject [tags]                       $sender
   to: $recipients                        $date
   $messageBody
                                     $attachments

I'm not really happy with the "to:" section as I think it looks odd sometimes.  However I think the other pieces are coming along well.

I've lightened up the top results bar so it's not such an eye catcher and converted it into a CSS table as well.

I would really like to improve the look of the tags while I'm here.  I've already done some of that work in my header extension so I should just pull that in so we have a more modern looking tag.

Comment 9

[David Ascher (:davida)]

Quick feedback:

1) whoa, nice.
2) font size on pinstripe in the header area (show all as list, sort order) is a tad too small -- we may need to make per-theme font sizing choices, unfortunately.
3) somehow one of my messages shows an attachment icon but no name, and it doesn't really have an attachment
4 [review]) with multiple attachments, the names are concatenated w/ no space in between (not new, just a TODO)
5) there's no space between "Search for" and the search words
6) agree that the to: line looks a bit odd.

7) whoa, again.

Comment 10

[Andreas Nilsson (:andreasn)]

Attachment: button look on hover

small artifact from making it a table-cell, will figure out how to fix

Comment 11

[Andreas Nilsson (:andreasn)]

Attachment: modified patch that fixes the issue above

and introduce new ones? ;)

Comment 12

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

Attachment: small update to andreas patch

ok, I only had one change to this which reverts a change I made previously.  I think this is ready to land so we can continue to get more feedback and press on.

Comment 13

[David Ascher (:davida)]

Attachment: patch w/ some mac tweaks, and some general tweaks

some more tweaks, done w/ bryan looking over, on the mac.

Comment 14

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

Comment on attachment 400812 [details] [diff] [review]
patch w/ some mac tweaks, and some general tweaks

This looks fine on Linux.  I'd like to take one quick look on windows and then I'd say we're good to land this and move on to another round of iterations.

Comment 15

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

Comment on attachment 400812 [details] [diff] [review]
patch w/ some mac tweaks, and some general tweaks

ok, the sizes look fairly good on Vista however teh "show all as list" and "sort by" are very small.

Comment 16

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

Attachment: update search results patch

Ok, the major OS vendor muscle is coming down on me. :)  This patch inverts the font choices such that Linux adapts from the defaults that work well for both Mac and Windows.

davida, can you take a look?

Comment 17

[David Ascher (:davida)]

Comment on attachment 400834 [details] [diff] [review]
update search results patch

>fixes bug 516261 to improve the gloda search results list
>
>diff --git a/mail/base/content/glodaFacetBindings.xml b/mail/base/content/glodaFacetBindings.xml
>--- a/mail/base/content/glodaFacetBindings.xml
>+++ b/mail/base/content/glodaFacetBindings.xml
>@@ -1186,62 +1188,62 @@
> 
> <binding id="result-message">
>   <content>
>     <html:div class="message-header">
>       <html:div class="message-line">
>         <html:div class="message-meta">
>           <html:div anonid="addresses-group" class="message-addresses-group">
>             <html:div anonid="author-group" class="message-author-group">
>-              <html:span anonid="from" class="message-from-label"></html:span>
>+<!--              <html:span anonid="from" class="message-from-label"></html:span> -->

can you get rid of that?


>+//        let fromNode = anonElem("from");
>+//        fromNode.textContent = glodaFacetStrings.get("glodaFacetView.result.message.fromLabel");

and those.



>diff --git a/mail/themes/pinstripe/mail/glodaFacetView.css b/mail/themes/pinstripe/mail/glodaFacetView.css
>--- a/mail/themes/pinstripe/mail/glodaFacetView.css
>+++ b/mail/themes/pinstripe/mail/glodaFacetView.css
>@@ -1,1 +1,2 @@
> @import url("chrome://messenger/content/glodaFacetView.css");
>+

that one's not needed, but no big deal.

r=davida with those nits fixed.

Comment 18

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

Attachment: [checked in] search results patch with comments addressed

here's a final version.  The only thing changed outside of the comments was cleaning out some trailing whitespace I noticed creep in.

Comment 19

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

Comment on attachment 400953 [details] [diff] [review]
[checked in] search results patch with comments addressed

carrying forward the pluses

Comment 20

[David Ascher (:davida)]

This is a huge esthetic/usabilty win IMO (and safe, and done).  We may need further tweaks of course.

Comment 21

[Gervase Markham [:gerv]]

I was asked to add CSS tweak suggestions here, although it looks like this patch is done and any further changes would need to be another one.

* My overall thought is that the look and feel of the search results page doesn't match the rest of Thunderbird. The rest of Thunderbird looks and feels like desktop application - some 3Dness in the widgets, grey, etc. The search results look and feel like a web page - flat, blue, lots of font variation. That might be because they are a web page, but it would be good to draw the look closer to the rest of the application.

* Greying out filters which have no effect, such as "Starred", just makes one take five seconds trying to work out why that filter isn't applicable. Just leave it enabled; if you click it and all the messages disappear, it's obvious what happened. You just unclick it and they all come back.

* If the whole message is clickable to open that message, then the highlighting should show it. Currently, just the header changes on mouseover. It needs a border.

Hope that's useful :-)

Gerv

Comment 22

[Jim Porter (:squib)]

(In reply to comment #21)
> * My overall thought is that the look and feel of the search results page
> doesn't match the rest of Thunderbird. The rest of Thunderbird looks and feels
> like desktop application - some 3Dness in the widgets, grey, etc. The search
> results look and feel like a web page - flat, blue, lots of font variation.
> That might be because they are a web page, but it would be good to draw the
> look closer to the rest of the application.

I agree with this. I think making the left pane visually reminiscent of the folder pane in the 3-pane tab would be a great way to tie the two together. I don't have a problem with the results looking "web page-y" since it's not far off from how the thread summary looks in the 3-pane, but the left pane does look wholly different from anything else in Thunderbird. To be fair, that's probably because it's a pretty big change in terms of what Thunderbird does. :)

Also, I haven't had a chance to try out the patch, but based on the screenshot, it does seem to resolve the issue I had with the current nightly (20090918): http://img142.imageshack.us/img142/7525/gloda.png

(Note: I didn't want to attach the image to the bug since it should be rendered irrelevant whenever attachment 400953 [details] [diff] [review] gets checked in. But still, something to look out for.)

Comment 23

[Mark Banner (:standard8)]

Comment on attachment 400953 [details] [diff] [review]
[checked in] search results patch with comments addressed

Checked in:

http://hg.mozilla.org/comm-central/rev/36605f782a1e

Comment 24

[Mark Banner (:standard8)]

Patch is checked in, leaving open as I don't know if this bug wants to cover more (per comment 20 and comment 21).

Comment 25

[Mark Banner (:standard8)]

(In reply to comment #23)
> (From update of attachment 400953 [details] [diff] [review])
> Checked in:
> 
> http://hg.mozilla.org/comm-central/rev/36605f782a1e

Incorrect changeset, it was actually: http://hg.mozilla.org/comm-central/rev/ebee87256887

Comment 26

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

Marking this as fixed since we're done with the current set of iterations.  

Gerv if you could file bugs for any additional items you have.  I'll try to comment on these below.

(In reply to comment #21)
> * My overall thought is that the look and feel of the search results page
> doesn't match the rest of Thunderbird. The rest of Thunderbird looks and feels
> like desktop application - some 3Dness in the widgets, grey, etc. The search
> results look and feel like a web page - flat, blue, lots of font variation.
> That might be because they are a web page, but it would be good to draw the
> look closer to the rest of the application.

We tried to keep the colors very similar to the Thunderbird application and I think can easily take bugs where we look out of place with the Thunderbird theme according to the OS.

We did purposely avoid chrome looking buttons because they draw too much attention where it's not needed.  The ( list all ) button for instance would be much more visually noticeable in a way we don't feel is a benefit to the user.  Similarly for most of the other button like buttons.  Show More at the bottom is probably the exception as it is below the fold and thus not likely to draw unneeded attention.

> * Greying out filters which have no effect, such as "Starred", just makes one
> take five seconds trying to work out why that filter isn't applicable. Just
> leave it enabled; if you click it and all the messages disappear, it's obvious
> what happened. You just unclick it and they all come back.

The behavior we have is how (in general) faceting is supposed to work; only showing filters that could apply to the result set.  In the top filter area we somewhat break the rules by making custom filter widgets that disable when they don't work.  We could try hiding the filters that don't work and thus would be more inline with real faceting behavior.  If you could file another bug on this I'll take a stab at making it happen.

> * If the whole message is clickable to open that message, then the highlighting
> should show it. Currently, just the header changes on mouseover. It needs a
> border.

The whole message is not clickable right now, only the subject which should underline on hover of the message.  I'm not sure this is the best solution however we wanted to allow the text of the message to be selectable and copied by the users without opening the actual message.  I think this will be even more helpful when we highlight and display the actual matching text of the message.  There might be a better way to acheive this balance, I think there is already a separate bug on this but I can't find it right now.