686959 - improve multiple selection colors on windows theme; fix focused vs. unfocused selection colors

Status: RESOLVED FIXED

(Thunderbird :: Theme, defect)

Description

[David :Bienvenu]

If I have two messages selected, the thread pane lines have very different colors - the one with focus is much darker, so it can be unclear that both messages are selected. Blake suggested making the colors closer, or even, the same.

Comment 1

[Jim Porter (:squib)]

What version do you see this on? I don't see it in 6.0.2.

Comment 2

[Andreas Nilsson (:andreasn)]

Attachment: showing both two and four messages selected

I can confirm this.
Showing that one of them is the selected one don't buy us much, since the message summary will show all four and hitting Enter will open all four.
For reference the File Explorer (in Vista) don't seems to make a difference between several selected tree items.
+1 for giving them the same color.

Comment 3

[Jim Porter (:squib)]

(In reply to Andreas Nilsson (:andreasn) from comment #2)
> Showing that one of them is the selected one don't buy us much, since the
> message summary will show all four and hitting Enter will open all four.

I really don't see a difference between any of the rows. Am I missing something?

> For reference the File Explorer (in Vista) don't seems to make a difference
> between several selected tree items.

However, I *do* see a difference in the Windows 7 explorer. The focused item is slightly darker than the other selected ones (an easy way to see this is to select a few and use Ctrl + arrow keys to change the focused item).

Comment 4

[Andreas Nilsson (:andreasn)]

(In reply to Jim Porter (:squib) from comment #3)
> (In reply to Andreas Nilsson (:andreasn) from comment #2)
> > Showing that one of them is the selected one don't buy us much, since the
> > message summary will show all four and hitting Enter will open all four.
> I really don't see a difference between any of the rows. Am I missing
> something?

So I opened it in GIMP and did some copy-pasting and I think it might have been an optical effect I was looking at. Sorry for that. :/

Comment 5

[Jim Porter (:squib)]

I think the biggest difference between us and Windows explorer, aside from some slight color differences, is that in Windows, there's either a 1px space between the borders of each row, or the borders are collapsed. We end up showing adjacent borders separately, which makes interior items in the selection look like they have extra-thick borders.

At one point, I tried to get the borders to collapse, but I couldn't get it to work right due to the particulars of how <tree>s render themselves.

Comment 6

[Richard Marti (:Paenglab)]

The double border buggered me also all the time but I haven't found a solution to collapse them.

Comment 7

[David :Bienvenu]

(In reply to Jim Porter (:squib) from comment #1)
> What version do you see this on? I don't see it in 6.0.2.

I'm on the trunk.

Comment 8

[Richard Marti (:Paenglab)]

Attachment: More like Explorer

Make the difference between selected and current less visible like on Explorer.

Comment 9

[Richard Marti (:Paenglab)]

Attachment: Comparison between before and after patch

Comment 10

[Blake Winton (:bwinton) (:☕️)]

(Drive-by UI-Review!)

I think I'ld like to see the selected-and-non-focused items be even a little darker than your patch has them.

Thanks,
Blake.

Comment 11

[Richard Marti (:Paenglab)]

Attachment: More like Explorer v2

As asked by Blake the selected-and-non-focused items a little bit darker than in the patch before.

Comment 12

[Richard Marti (:Paenglab)]

Attachment: Screenshot with patch v2

Comment 13

[David :Bienvenu]

Comment on attachment 560689 [details]
Comparison between before and after patch

thx, this is better. I'll try the newer patch now.

Comment 14

[Andreas Nilsson (:andreasn)]

Comment on attachment 560711 [details] [diff] [review]
More like Explorer v2

(I did the see the issue now on my fresh Win7 build :)
It's pretty hard to see the difference between .93+.75 and .9+.7 with the naked eye, I actually had to open GIMP to see the difference (although this screen is not the best one I've come across) so I wouldn't mind seeing those values being the same (as mentioned in comment #1).
Apart from that, ui-r+ from me.

Comment 15

[Jim Porter (:squib)]

(In reply to Andreas Nilsson (:andreasn) from comment #14)
> Comment on attachment 560711 [details] [diff] [review]
> More like Explorer v2
> 
> (I did the see the issue now on my fresh Win7 build :)
> It's pretty hard to see the difference between .93+.75 and .9+.7 with the
> naked eye, I actually had to open GIMP to see the difference (although this
> screen is not the best one I've come across) so I wouldn't mind seeing those
> values being the same (as mentioned in comment #1).

I don't think we should make them the same, since that would make it impossible for people to follow the current item when moving around with Ctrl+Up/Down.

Comment 16

[Jim Porter (:squib)]

Comment on attachment 560711 [details] [diff] [review]
More like Explorer v2

Review of attachment 560711 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry about the delay. It took me a little while to calculate the expected color values based on Windows Explorer. In light of that, I'm going to have to r- this, but I'll post an alternate patch shortly based on my calculations of what the alpha values should be to match Explorer.

Comment 17

[Jim Porter (:squib)]

Attachment: An alternative patch

Here's my alternate take on the alpha values. I looked at Windows Explorer and got the following RGB values for the various selection states:

          Top RGB         Bottom RGB
Current   220, 235, 252   193, 219, 252
Selected  235, 244, 254   192, 221, 252
Hovered   250, 251, 253   235, 243, 253

The "Highlight" CSS color is RGB 51, 153, 255 on my machine, so plugging these values into the following equation derived from the W3C simple alpha compositing equation[1]

  alpha = (expected_color - highlight_color) / (white - highlight_color)

yields the following approximate alpha values (I just calculated based on the red values here; using green or blue gives slightly different values, but they're close enough that I'm sure no one will notice):

           Top  Bottom
Current    0.8     0.7  
Selected   0.9     0.7
Hovered   0.98     0.9

[1] http://www.w3.org/TR/2003/REC-SVG11-20030114/masking.html#SimpleAlphaBlending

Comment 18

[Jim Porter (:squib)]

Attachment: What it looks like

Here's what my patch looks like:

* Row 1 is the hovered (and unselected) state
* Row 2 is the currently-focused (and selected) state
* Row 3 is the selected (but not currently-focused) state

With the exception of the borders, which we can't really improve, these are all virtually identical to Windows Explorer.

Comment 19

[Jim Porter (:squib)]

Attachment: Hover state on the folder pane

One thing you might notice with this patch is that the hover state over the folder pane (or in the address book) is pretty bright. I don't think this is really a problem, but I just wanted to point it out for thoroughness.

Comment 20

[Andreas Nilsson (:andreasn)]

If we're aiming as close to Windows Explorer colors as possible, perhaps it would be cool to get the outline colors right as well. It also seems the window unfocused state don't do much right now.

Comment 21

[Jim Porter (:squib)]

(In reply to Andreas Nilsson (:andreasn) from comment #20)
> If we're aiming as close to Windows Explorer colors as possible, perhaps it
> would be cool to get the outline colors right as well. It also seems the
> window unfocused state don't do much right now.

If we want to keep using the platform "Highlight" color as the basis of our selection colors, this will be pretty hard. You can get close by using multiple inset CSS box-shadows, but round borders have seams on them and it doesn't look good.

We could just give up on using the Highlight color and hard-code the colors in, which is what Windows Explorer appears to do as well (changing the Selected Items color in the OS settings doesn't affect the selection color in Explorer). Given that we're already using mostly-hardcoded colors (that is, between 70%- and 93%-opaque white), we probably wouldn't be losing much by doing this.

Comment 22

[Jim Porter (:squib)]

Attachment: Windows Explorer selection states

Just for reference, here are all the selection states in Windows Explorer (all the unfocused ones look like the last one, or are undecorated). Hover/Selected and Hover/Selected/Current might be the same, but I'm not 100% sure.

Comment 23

[Andreas Nilsson (:andreasn)]

I'm leaning toward hardcoding (for Aero specifically), since it's like impossible to find where to change this in the Win7 control center anyway (or am I looking in the wrong place?).
Richard, Blake: Any opposition?

Comment 24

[Blake Winton (:bwinton) (:☕️)]

Nah, go for it, I guess.  As long as it continues to work when I choose the Pink aero theme…  ;)

Comment 26

[Thomas D. (:thomas8)]

Pls ensure the following:
- that we always have a clear indication of the focused item (even within a multiple selection, and hopefully with a clearer contrast than in Windows explorer), and
- that there's an even clearer difference between focused vs. unfocused selections (along the lines of Win Explorer where unfocused selections have light-greyish background with light-grey borders)

cf. duplicate bug 692062 about the importance of a unique and clearly-marked focus, at any given time!

I like the test of Bug 491338 Comment 1 to check wether focus indication is clear enough:
> 3. Go get a cup of coffee.
> 4. Focus, focus, who's got the focus?

I suppose we want to follow the basic theme patterns of windows explorer, but can't we make them clearer?

Comment 27

[Thomas D. (:thomas8)]

fwiw, any solution that seeks to level away the differences between focused and non-focused selection items is in violation of the most basic UI design guidelines since any interaction with software relies on focus. I am shocked to see that comment 0 (at the end) simply suggested no less than removing unique indication of focus. Against such dark desires, Jim's comment 15 gets it right: :)

> I don't think we should make them the same, since that would make it
> impossible for people to follow the current item when moving around with
> Ctrl+Up/Down.

(In reply to Thomas D. from comment #26)
> Pls ensure the following:
> 1) ...
> 2) that there's an even clearer difference between focused vs. unfocused
> selections (along the lines of Win Explorer where unfocused selections have
> light-greyish background with light-grey borders)

By that I mean when the entire selection, i. e. the whole tree, loses focus, I think that's what comment 20 refers to as well:
> It also seems the window unfocused state don't do much right now.
Which is currently a big usability problem as described in bug 692062.

Comment 28

[Blake Winton (:bwinton) (:☕️)]

Thomas: There is that factor, but there's also our desire to fit into Windows, and look and behave like the other apps on the system.  It's more of a balancing act than you make it sound.

Thanks,
Blake.

Comment 29

[Thomas D. (:thomas8)]

(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #28)
> Thomas: There is that factor, but there's also our desire to fit into
> Windows, and look and behave like the other apps on the system.  It's more
> of a balancing act than you make it sound.

I'm not sure which factor exactly you are referring to, and perhaps I've been misunderstood. My vote was *in favour* of fitting into windows and of looking and behaving like the OS (which we don't, at the moment, unless bug 692062 is something which happens on my machine only). When the focus goes away from a tree/list view control, windows *does* clearly de-focus the entire multiple selection by changing selection colors into light-grey. Also, windows *does* have a different background color (albeit only slightly different) within a multiple selection to indicate the unique list item which currently has focus (test with Ctrl+up/down to see it moving). My vote was to implement correct behaviour like on windows, but perhaps make the background color shade differences a bit stronger than on native windows (I'm not happy with the subtlety/fuzziness of the windows OS theme in general, but I know we have to go along with it).

Comment 30

[Blake Winton (:bwinton) (:☕️)]

Thomas:

Oh, I read your message as being against the only-slightly-different background colour within the multiple selection, and that you wanted it to be more different.  Now that you've explained what you meant, nevermind.  :)

(And now I'll start reviewing this patch...)

Comment 31

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 562282 [details] [diff] [review]
An alternative patch

Review of attachment 562282 [details] [diff] [review]:
-----------------------------------------------------------------

I don't have a problem with the code that's there, but I agree with comment 26.  When we're on the folder pane, the selected items in the message pane should be grey (as per Windows Explorer), and vice versa, and when we're on the message itself, they should both be grey.

So, I'm going to say r- cause I want to see that code too.

Thanks,
Blake.

Comment 33

[Jim Porter (:squib)]

So, while my build was broken, I took a look at this and I think I've figured out the appropriate CSS rules (just as userChrome for now). One of the big differences between my way and the status quo is that I'm using translucent blue on a (usually) white background, whereas the status quo uses translucent white on a (usually) blue background.

My way has the benefit of having a maximum alpha of 0.5, whereas the status quo maxes out at 0.98. This is good because it means that more of the composited color comes from the OS theme, so if your theme uses white text on a black background, it'll still be readable.

The downside is that this means we'll need to create tagColors-aero.css, but that's easy enough to generate via a script.

All of this still doesn't get rid of the doubled borders mentioned in bug 714333, but it gets us quite a bit closer to fitting in with Windows. I'm already enjoying the slightly less garish border colors from the userChrome. :)

Comment 34

[Richard Marti (:Paenglab)]

De-assigning me. Maybe Squib wants to take this bug with his approach.

Comment 35

[Thomas D. (:thomas8)]

(In reply to Richard Marti [:paenglab] from comment #34)
> De-assigning me. Maybe Squib wants to take this bug with his approach.

Jim, what's the way forward here? Do you take this bug?

Personally, I don't care much about subtle colors, in fact, I don't like them so much because I assume that what Jim calls "garish border colors" might be to me the good, old, and clear "blue background with white text and dotted black border" contrast for focused items...

However, I really think we should fix Bug 692062 asap (per Blakes comment 31) - not to know where the focus is, that's a major usability issue.

Comment 36

[Jim Porter (:squib)]

(In reply to Thomas D. from comment #35)
> Jim, what's the way forward here? Do you take this bug?

I'll take this bug, but I'm not planning on working on it until I'm done with the other stuff in my queue. I have some userChrome to fix this, but I need to write some automation code to generate CSS for tag colors.

Comment 37

[Jim Porter (:squib)]

Standard8: since this patch will require changing tagColors.css for aero, should I just generate the file myself and add it to the patch, or muck about with the build system to generate the file during builds?

Comment 38

[Mark Banner (:standard8)]

(In reply to Jim Porter (:squib) from comment #37)
> Standard8: since this patch will require changing tagColors.css for aero,
> should I just generate the file myself and add it to the patch, or muck
> about with the build system to generate the file during builds?

hg copy the file to tagColors-aero.css, and then alter this line: http://hg.mozilla.org/comm-central/annotate/5df553de0a84/mail/themes/qute/jar.mn#l293

Comment 39

[Jim Porter (:squib)]

(In reply to Mark Banner (:standard8) from comment #38)
> (In reply to Jim Porter (:squib) from comment #37)
> > Standard8: since this patch will require changing tagColors.css for aero,
> > should I just generate the file myself and add it to the patch, or muck
> > about with the build system to generate the file during builds?
> 
> hg copy the file to tagColors-aero.css, and then alter this line:
> http://hg.mozilla.org/comm-central/annotate/5df553de0a84/mail/themes/qute/
> jar.mn#l293

Oh, I know that. What I mean is that tagColors.css is just a bunch of repeated definitions for different colors, and it's the exact kind of thing I'd write a script to generate. I'm just wondering if that script should be something for my own personal use to generate the file one time, or if I should add it to the Thunderbird build system so that future people can just modify the script to change the resulting CSS in tagColors.css (or tagColors-aero.css).

Comment 41

[Thomas D. (:thomas8)]

Bug 745892 (see screenshot in attachment 615425 [details]) mentions a new aspect which iirc has not been noticed so far in this bug: At least for Win7 theme, with some messages selected, hovering over an unselected message will cause that msg to look selected without any way of distinction vs actually selected msgs except moving the mouse around, which may not help much because it can easily cause yet *another* unselected msg under the mouse pointer to wrongly look selected.

Comment 42

[Jim Porter (:squib)]

Attachment: Some userChrome to fix this

I'm sure there's someone out there with more time than me (not to mention a working Windows dev environment) that could take a look at this. I managed to write some userChrome to override the default CSS, and I think it looks pretty close to Aero's native theme.

I'm going to unassign this from myself for now. If anyone would like to work on this, I'm more than happy to help, but I'd rather it not languish forever while waiting for me to set up builds on Windows.

Comment 43

[Richard Marti (:Paenglab)]

Attachment: patch

Patch based on Squib's userChrome. And yes Squib, it took a lot of time to check every tag color ;)

Sorry for this boring huge patch in tagColors-aero.css but all the styles are needed to look good also with tagged messages. The dark tagged selected messages have a white text and the light tagged have black text. It wasn't so easy on middle colors to say when the change from white to black should happen, but I think like it is now it is always readable.

Comment 44

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 639948 [details] [diff] [review]
patch

I like the look.  ui-r=me!

And the code seems good, too.  r=me!

Thanks,
Blake.

Comment 45

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/comm-central/rev/f01683f0ef7e