430767 - clean up / tweak site identity button DV and EV states on Windows and Linux

Status: VERIFIED FIXED

(Firefox :: Theme, defect)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to bug 417844 comment #97)
> Created an attachment (id=317560) [details]
> (Vista) using dao's no-whiteline images

So, I actually think this looks pretty good, modulo:

 - getting a slightly lighter gradient so that it's not interfering with the favicons and text as much as it currently is, and,
 - adding a dark blue / dark green keyline at the top, bottom and right hand side to make the edge look more like the edge of the back/forward buttons

Comment 1

[Alex Faaborg [:faaborg] (Firefox UX)]

> - getting a slightly lighter gradient so that it's not interfering with the
>favicons and text as much as it currently is

Can we take the gradient off of the small keyhole navigation buttons?

http://mxr.mozilla.org/seamonkey/source/browser/themes/winstripe/browser/Toolbar-small-aero.png

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Sure, that sounds good to me. Can we just extract that without needing the iconfactory to do it?

Comment 3

[Alex Faaborg [:faaborg] (Firefox UX)]

Dao has modified the site buttons to be 1 pixel wide so I think it would be fastest if he copied in the gradients from Toolbar-small-aero.png.

Are we still planning on doing normal/hover/hit states?

Comment 4

[Dão Gottwald [:dao]]

The second point in comment 0 is pretty vague, I'm not sure at all what the expected look is. Can somebody create a mockup?

Comment 5

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Mockup testing out colored curve lines

I was curious what how colored curve lines would look, so I tested it out using the end caps of the source artwork from the iconfactory.  It seems odd to have the left edge not be the same color as the top and bottom line, but after looking at it for awhile, I think it looks better than using the system color line on the left edge when viewed at normal resolution.  The button feels softer, and it mirrors the forward button more, especially in the SSL state.  The current grey line is anti-aliased ok, but perhaps the increased contrast with the background and the face of the button is perhaps is making it look a little rough?

Now that I am looking at this, I probably should have tried changing the vertical line on the right as well.

Comment 6

[Alex Faaborg [:faaborg] (Firefox UX)]

>The second point in comment 0 is pretty vague, I'm not sure at all what the
>expected look is. Can somebody create a mockup?

I'm not sure what a keyline is, but aren't the edges directly under/above the outer border light on the forward button, and not dark?

Comment 7

[Dão Gottwald [:dao]]

(In reply to comment #5)
> Created an attachment (id=317986) [details]
> Mockup testing out colored curve lines
> 
> I was curious what how colored curve lines would look, so I tested it out using
> the end caps of the source artwork from the iconfactory.  It seems odd to have
> the left edge not be the same color as the top and bottom line, but after
> looking at it for awhile, I think it looks better than using the system color
> line on the left edge when viewed at normal resolution.

I think it looks more like an unintended artifact. The left side looks more integrated to me.

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #4)
> The second point in comment 0 is pretty vague, I'm not sure at all what the
> expected look is. Can somebody create a mockup?

Right now the line at the edge of the gradient has been removed (by you). I'm suggesting we make it a darker line to put an edge on the gradient that will butt up against the border around the button. The mockup Alex made in attachment 317986 [details] sort of gets at this (along the left side) - I am thinking that if we take that darker 1px colour but put it up against the top/bottom of the gradient, we'll get a dark keyline around the inside edge of the button, right beside the grey border that it's contained in.

(In reply to comment #5)
> looking at it for awhile, I think it looks better than using the system color
> line on the left edge when viewed at normal resolution.  The button feels

I disagree. Without the left edge, I find that it looks like (as Dao said) an unintended error where we forgot to put the border on. I suspect that in usage, as well, this will look particularly egregious since 95% of the time the site button will have a border (in no-SSL state) and when the button changes colour, it will look like we've forgotten to draw it.

I also actually find that I don't see the darkness of the button edge on the left edge of the green button, so really we'd seem to be optimizing for the DV-SSL state only.

Comment 9

[Ryan A. C.]

Attachment: Mockups of a couple stlyes

I tried to create one with the current gradient, but that one just looks funny when you add the darker top/bottom lines to it. The left curve looks completely wrong with anything dark beside it, and even the top and bottom ones look kind of funny with dark colors beside them as you can see in the 3rd one here. The iconfactory guys might be able to find a better color combination, but I can't make it look good inside the border.

Comment 10

[Ryan A. C.]

Attachment: Back button gradient, no other changes

forgot this one, which IMO looks better than current.

Comment 11

[Ryan A. C.]

Attachment: Modified version of Faaborgs mockup

I somewhat agree that changing only the back line alone looks a little odd, but if something like this is possible it looks much more intentional.

Comment 12

[Alex Faaborg [:faaborg] (Firefox UX)]

>but if something like this is possible it looks much more intentional.

Yeah, i think that would probably be ideal, but I was under the impression that it was not possible to implement.

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

The "back button style" of attachment 318033 [details] combined with the "back button gradient" of attachment 318034 [details] seems like a really solid approach. Can you attach the PNGs with those gradients so we can try them out?

Comment 14

[Ryan A. C.]

Attachment: navbar-textbox-buttons with back button gradient

The EV (green) is the same gradient with a hue/saturation shift.
I did a quick photoshop test using attachment 316457 [details] on the tail color past the normal button height, and while it's certainly very pale it doesn't look that bad.

The only difference between the "back button style" and the "back button gradient" is the border around it. Back button gradient is just the gradient extracted from the back button in place of our current gradient, where 'back button style' is the back button itself moved over in photoshop, which would require we use an image over top of the normal border. It seemed in bug 417844 that it is possible to do so, but we didn't really want to do that, though it does look good.

Comment 15

[Dão Gottwald [:dao]]

(In reply to comment #14)
> Created an attachment (id=318248) [details]
> navbar-textbox-buttons with back button gradient
> 
> The EV (green) is the same gradient with a hue/saturation shift.

The white text is significantly harder to read on that. Perhaps we could make the background even lighter (good for the favicon) and make the text black again?

> It seemed in bug 417844 that it is possible to do so

As it stands, there's no solid implementation in sight.

Comment 16

[Ryan A. C.]

Attachment: 50% opacity on colors

How about this one with black text?
I don't actually know how this will turn out, I'm not on vista atm to test, but using a screenshot + photoshop it seems like it would work nicely.

Comment 17

[Ryan A. C.]

Attachment: Screenshot of attachment 318271

The colors look nice, I just don't know if they really 'fit' with the platform really, also the lighter colors have basically no connection to the larry icon except in basic color (though the EV one is close)
The blue also looks a bit purple on the top.
The browser.identity.ssl_domain_display is a little harder to read than EV, but it's not bad, and since it's not default I don't see it being a huge problem.
I quite like the green one, it's the blue that might need a bit of work.

Comment 18

[Alex Faaborg [:faaborg] (Firefox UX)]

We want the change in button state to be pretty noticeable, so I'm worried that lightening the gradient reduces that effect, particularly for DV.

Comment 19

[Ryan A. C.]

My quick testing in the matter, and obviously I alone am not a representative audience:
The bright blue at the bottom of that DV sticks out pretty good. IMHO the fallacy of making the DV button the same as the back button is that it makes it blend with the rest of the UI in the theme, which is of course predominately blue. With everything else in the vista theme being the darker blue, that bright color that looks like it belongs on OS X actually sticks out quite nicely. The top of the DV button however not as much, in fact the hover state is almost exactly 'sickly purple'.

Comment 20

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #18)
> We want the change in button state to be pretty noticeable, so I'm worried that
> lightening the gradient reduces that effect, particularly for DV.

True, but I agree with Dao that at 100% opacity, the favicon gets lost completely.

Ryan, 66% or 75%? I think we're really, really close. I'm also liking the look of attachment 318271 [details], but like Alex, wonder if it's not just a bit too light.

Comment 21

[Alex Faaborg [:faaborg] (Firefox UX)]

What if we add a glow behind the location of the favicon instead of messing with the entire gradient.  I get that we need to make it more visible, but we are also trying to match some textures that already exist in the interface.

Comment 22

[Ryan A. C.]

Attachment: Comparison of 50, 66, 75%

At 66% the DV is just a little too light for white and a little to dark for black :/

I do like the idea of a glow in the background of the favicon, they're a constant size and position, so it should be easy enough to just stick a white blob back there.

Comment 23

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #21)
> What if we add a glow behind the location of the favicon instead of messing
> with the entire gradient.  I get that we need to make it more visible, but we
> are also trying to match some textures that already exist in the interface.

So you mean assemble the image like this:

(|{F}||||||||

where (   is the clipping and -moz-border radius
      |   is gradient tiling
      { } is an image of a white glow on top of the gradient
      F   is the favicon

Yeah, that might solve a lot of the problems.

As for colour, I wonder (and have wondered before) if we might be making a mistake by matching it against the back-forward buttons. What if we used the lighter, upper-portions of the Larry colours instead, along with a lighter gradient - again with darker edging, as I do think that looks quite good even up against the grey outline.

Comment 24

[Mike Beltzner [:beltzner, not reading bugmail]]

Also, is the favicon appearing underneath this gradient? When I edit a field on a page with DV, I notice that the default page icon looks blue.

STR: go to a DV site (like this one!) / edit the location / look at the icon
Expected: white page
Actual: blue page

Comment 25

[Alex Faaborg [:faaborg] (Firefox UX)]

I believe that is because the page is partially transparent in that state, but still above the gradient.

>https://bugzilla.mozilla.org/attachment.cgi?id=318312

What I am worried about is using a gradient that is pretty close to the back and forward buttons, but not the same, and that looking like we made a mistake or weren't very careful (which is ironic considering how many iterations we are going through).

I think the ideal solution might be the glow behind the favicon, if it is possible.  This way at least some parts of the gradient still match so the change looks considerably more intentional.

Comment 26

[Dão Gottwald [:dao]]

Attachment: navbar-textbox-buttons.png with white blob

Comment 27

[Dão Gottwald [:dao]]

Attachment: navbar-textbox-buttons-aero.png with white blob

Comment 28

[Dão Gottwald [:dao]]

Attachment: navbar-textbox-buttons-aero.png with white blob

Comment 29

[Kai Liu]

(In reply to comment #24)
> STR: go to a DV site (like this one!) / edit the location / look at the icon
> Expected: white page
> Actual: blue page
> 

Yea, the icon for no-address (about:blank or if the address bar is being edited) is partially transparent to set it apart from the default favicon, so the background color bleeding in is expected.  See bug 421374

Comment 30

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: glowy, light gradient

So, I think that this is, indeed, getting there. I wonder, though, if the glow might not enable us to go back to a gradient colour that matches the initial gradient we were using which matched against the back/forward buttons, as well as the darker green that matched against Larry.

So:
 - darker gradients matching back/fwd and green-larry
 - glow
 - darker edge line

Comment 31

[Dão Gottwald [:dao]]

> darker gradients matching back/fwd

It's basically the same gradient as in attachment 318034 [details], the glow makes it lighter.

Comment 32

[Dão Gottwald [:dao]]

Attachment: navbar-textbox-buttons.png, darker gradient

Comment 33

[Dão Gottwald [:dao]]

Attachment: navbar-textbox-buttons-aero.png, darker gradient

Comment 34

[Adam Barth]

Alex asked me to file Bug 431461 and make a note of it in this bug.

Comment 35

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: darker gradient, w/blob

This is darker, but I still don't think it's right. I hate to be a bear about this, but I was looking for the gradients we were using in attachment 317560 [details], which were designed to match against the blue in the back/forward button and the green in larry, and were quite dark and looked good with white text.

Comment 36

[Kai Liu]

It may be worthwhile to consider doing the glow as a separate image, as the background for the favicon.  That would eliminate the need for the background to be super-wide, and would also eliminate the fragileness of matching the glow with the favicon's position.

Comment 37

[Dão Gottwald [:dao]]

(In reply to comment #35)
> I was looking for the gradients we were using in attachment 317560 [details]

This is what we're using right now. Why are we talking about the gradients if they aren't expected to change?

Comment 38

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #37)
> This is what we're using right now. Why are we talking about the gradients if
> they aren't expected to change?

The process was:
 - started with dark gradients, white keyline
 - removed whitekeyline
 - landed those, forked this bug
 - as reported in comment 0, dark gradients interfere a lot with favicon
 - tried a variety of lighter gradients that still matched back/foward
 - lighter gradients weren't matching well, made text harder to read
 - struck on idea of adding a glow behind favicon in comment 25
 - the glow alleviates the concerns with the darkness of the gradient

So it's not that they weren't expected to change, it's that we've been sketching and trying things out. I'm sorry if that's been frustrating, and appreciate your patience.

Comment 39

[Dão Gottwald [:dao]]

Attachment: urlbar-favicon-glow.png

Comment 40

[Dão Gottwald [:dao]]

Attachment: urlbar-favicon-glow patch

Comment 41

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: original gradient, white keyline removed, glow, yay

I went and dug up our worst-case favicons (Facebook, Sierra Nevada) and tried them out. I'm pretty thrilled with the results. Thanks, Dao.

Comment 42

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 318776 [details]
urlbar-favicon-glow.png

This is a very zen ui-r.

Comment 43

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 318777 [details] [diff] [review]
urlbar-favicon-glow patch

So we'd make the change to XP and Vista for this? I guess I'm OK with that, but would appreciate seeing an XP screenshot if anyone's got it handy.

Comment 44

[Dão Gottwald [:dao]]

Comment on attachment 318777 [details] [diff] [review]
urlbar-favicon-glow patch

I'll attach a WinXP screenshot later

Comment 45

[Kai Liu]

Attachment: My XP screenshots of the glow

Dude, the glow is freaking awesome.

Comment 46

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 318777 [details] [diff] [review]
urlbar-favicon-glow patch

a=beltzner, thanks, this is great; I poked the proto guys, and they'll be doing something similar.

Comment 47

[:Gavin Sharp [email: [e-mail]]]

mozilla/browser/themes/gnomestripe/browser/browser.css 	1.214
mozilla/browser/themes/gnomestripe/browser/jar.mn 	1.78
mozilla/browser/themes/gnomestripe/browser/urlbar-favicon-glow.png 	1.1
mozilla/browser/themes/winstripe/browser/browser-aero.css 	1.12
mozilla/browser/themes/winstripe/browser/browser.css 	1.215
mozilla/browser/themes/winstripe/browser/jar.mn 	1.96
mozilla/browser/themes/winstripe/browser/urlbar-favicon-glow.png 	1.1 

Comment 48

[Dão Gottwald [:dao]]

Attachment: urlbar-favicon-glow.psd

may be useful for the Mac theme

Comment 49

[[:Aleksej]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050204 Minefield/3.0pre

          http: gray background, glow, favicon
   https://bmo: blue background, glow, favicon
https://paypal: green background, text, glow, favicon

Comment 50

[Mike Beltzner [:beltzner, not reading bugmail]]

Mac bug is bug 431853

Comment 51

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Based on attachment 318834 [details] it looks great with the current trunk builds on Windows Vista and XP for both DV and EV.

The only deficiency when running the Vista Basis or XP Luna theme is the too lighten background of the default identity button background. That's why the glow isn't really visible on the light gray background. Otherwise it looks good with the different themes => VERIFIED.

Comment 52

[Kai Liu]

> glow isn't really visible on the light gray background. Otherwise it looks good
> with the different themes => VERIFIED.
> 

Looks like pinstripe isn't going to use the glow for the non-SSL state; should (gnome|win)stripe follow suit?

Comment 53

[Dão Gottwald [:dao]]

(In reply to comment #52)
> > glow isn't really visible on the light gray background. Otherwise it looks good
> > with the different themes => VERIFIED.
> > 
> 
> Looks like pinstripe isn't going to use the glow for the non-SSL state; should
> (gnome|win)stripe follow suit?

I think we should leave it as is. The glow wasn't added to look cool but to make the favicon more visible. For light themes it doesn't really matter if it's there, but it makes a difference for darker themes.

Comment 54

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Current glow with (black) high contrast theme

Dao, the glow doesn't look well balanced with the high contrast theme. But this happens due to the white lighter shadow of the background at the top. This doesn't happen for DV or EV sites.

Comment 55

[Dão Gottwald [:dao]]

Well, it actually looks OK to me. Things never look great with a high contrast theme. And as I said, the glow might help here to make mid-dark favicons more visible.

Note that you need to restart Firefox once you've switched the theme. Otherwise you'll miss some adjustments especially on the location bar.

Comment 56

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #55)
> Well, it actually looks OK to me. Things never look great with a high contrast
> theme. And as I said, the glow might help here to make mid-dark favicons more
> visible.

Ok.

> Note that you need to restart Firefox once you've switched the theme. Otherwise
> you'll miss some adjustments especially on the location bar.

Yes, I know. That's why I've filed bug 431306. Thanks.

Comment 57

[Alex Faaborg [:faaborg] (Firefox UX)]

I filed a follow up bug for styling the border of the site button based on the state: bug 432355.