964251 - Better styling for »Exit Customize« button

Status: VERIFIED FIXED

(Firefox :: Toolbars and Customization, defect)

Description

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Attachment: Current state

The button for exiting customization mode is currently both hard to find and a little unclear. I think this is mostly due to its color (blue button on a blue background) and its icon (a plus sign). I'm also not sure if making the button look depressed is ideal.

Michael, I'll put this on your plate since it is a visual design issue.
The first solution that came to my mind is using a green button and a checkmark icon and no depressed appearance, but you'll probably have better ideas :)

Comment 1

[Michael Maslaney [:mmaslaney] ([e-mail])]

Attachment: Screen Shot 2014-01-31 at 5.49.56 PM.png

Option (a): Focuses on the act of exiting "Customize" mode.

Comment 2

[Michael Maslaney [:mmaslaney] ([e-mail])]

Attachment: Screen Shot 2014-01-31 at 5.19.17 PM.png

Option (b): Focuses on the act of proceeding (with changes)

Comment 3

[Michael Maslaney [:mmaslaney] ([e-mail])]

Attachment: Screen Shot 2014-01-31 at 5.29.04 PM.png

Option (c): Neutral

Comment 4

[Michael Maslaney [:mmaslaney] ([e-mail])]

Here's a question, what if we can combine both option (a) and (b)? When the user enters "Customize" mode they are presented with the "Exit" action, but once a change has been made, they are then prompted with a "Proceeding" action.

I like this approach, as it conveys to the user a level of responsiveness, on behalf of the software.

Comment 5

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Yes, that makes sense.

From the pragmatic »let's ship in 29« perspective, we probably can't get that (if only because it would/should involve a string change).

So I'd say we keep this on our radar and instead roll with b) alone for the time being. It is semantically still correct and definitely an improvement over the current state.

Comment 6

[Michael Maslaney [:mmaslaney] ([e-mail])]

Attachment: customize-finish.zip

Adjustments: 


#main-window[customize-entered] #PanelUI-customize {
  color: white;
  background-color: rgb(90,193,165);
  box-shadow: none;
  text-shadow: none;
}

#main-window[customize-entered] #PanelUI-customize:hover,
#main-window[customize-entered] #PanelUI-customize:hover:active {
background-color: rgb(83,178,153);
}

Comment 7

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch

Comment 8

[Michael Maslaney [:mmaslaney] ([e-mail])]

Attachment: b.png

After some debating, we have decided to ditch the teal and go with a more traditional green.

Glyphs remain the same, new values below:

#main-window[customize-entered] #PanelUI-customize {
  color: white;
  background-color: rgb(116,191,67);
  box-shadow: none;
  text-shadow: none;
}

#main-window[customize-entered] #PanelUI-customize:hover,
#main-window[customize-entered] #PanelUI-customize:hover:active {
background-color: rgb(105,173,61);
}

Comment 9

[:Gijs (out for now; he/him)]

Comment on attachment 8369881 [details] [diff] [review]
Patch

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

I have some nits, and you need to update the colors per Michael's last comment, but otherwise this looks good.

Not really too related, but for my sanity, can you file a bug (if we don't have one) on the classic/aero duplication insanity in our windows packaging? Thanks!

::: browser/themes/shared/customizableui/panelUIOverlay.inc.css
@@ +410,5 @@
>    -moz-border-start-style: none;
>    list-style-image: url(chrome://browser/skin/menuPanel-customize.png);
>  }
>  
> +#main-window[customize-entered] #PanelUI-customize {

Nit: wonder if this selector can be improved. At least this:

#customization-panelholder #PanelUI-customize.

Could use a bunch of child selectors, but this is probably more readable.

@@ +470,5 @@
>  #PanelUI-quit:not([disabled]):hover:active {
>    background-color: #ad3434;
>  }
>  
>  #main-window[customize-entered] #PanelUI-customize {

Ditto for this selector

@@ +472,5 @@
>  }
>  
>  #main-window[customize-entered] #PanelUI-customize {
>    color: white;
> +  background-color: rgb(90,193,165);

At least on OS X, all toolbarbuttons get text-shadow for free (well, from toolbarbutton.css in toolkit). You need to override that here, you can't just remove the rule.

Comment 10

[Jared Wein [:jaws] (please needinfo? me)]

Thanks!

https://hg.mozilla.org/integration/fx-team/rev/c1375930e0e6

Filed bug 967739 about the classic/aero jar.mn duplication.

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/c1375930e0e6

Comment 12

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8369881 [details] [diff] [review]
Patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 

Australis


User impact if declined: 

An "Exit Customize" mode button that looks awkward, and hard to distinguish from its background.


Testing completed (on m-c, etc.): 

This has been on Nightly for quite a few days now, and it looks good.


Risk to taking this patch (and alternatives if risky): 

Very, very low.


String or IDL/UUID changes made by this patch:

None.

Comment 13

[:Gijs (out for now; he/him)]

remote:   https://hg.mozilla.org/releases/mozilla-aurora/rev/2b66d15a6218

Comment 14

[[:Aleksej]]

Verified fixed (green background as opposed to blue background, while the other background is also blue):
* with 2014-02-18-03-02-02-mozilla-central-firefox-30.0a1.en-US.linux-x86_64 compared to 2014-02-04-03-02-01-mozilla-central-firefox-30.0a1.en-US.linux-x86_64.
* with 2014-02-18-00-40-01-mozilla-aurora-firefox-29.0a2.ru.linux-x86_64 compared to 2014-02-07-00-40-02-mozilla-aurora-firefox-29.0a2.en-US.linux-x86_64.