We want a black "Nightly" button and a blue "Aurora" button, as shown here: http://www.stephenhorlander.com/pages/channel-buttons/app-button-channel-colors.html

The mockup shows grey navbar for nightly and aurora , is there a separate bug for that too?

(In reply to comment #2) > The mockup shows grey navbar for nightly and aurora , is there a separate bug > for that too? No, I just happened to do the app button colors in a mockup that was playing around with desaturated toolbar colors.

(In reply to comment #3) > (In reply to comment #2) > > The mockup shows grey navbar for nightly and aurora , is there a separate bug > > for that too? > > No, I just happened to do the app button colors in a mockup that was playing > around with desaturated toolbar colors. oh. also , the mockup spots idk less shadows on toolbar buttons (?) , is it also going to be fixed in some follow-up bug of bug 603790

(In reply to comment #4) > also , the mockup spots idk less shadows on toolbar buttons (?) , is it also > going to be fixed in some follow-up bug of bug 603790 Yes. The plans for the continued refinement and evolution of the theme are underway. Nothing concrete yet though. But this is veering off-topic :)

This implements the channel-dependent appmenu button styling. The values here are mostly wrong, Stephen said he can help fill those in correctly.

Updated with colors from Stephen; I think this is fully functional. I'm starting to think it would be odd for nightly builds (channel=nightly) and self-builds (channel=default) to have different button colors even though they have the same branding, though. It seems like this should be tied to branding, rather than the channel... I could use a different pref whose value is set in the branding prefs file.

Comment on attachment 527156 [details] [diff] [review] patch >+ #appmenu-button[channel=nightly] { >+ -moz-border-left-colors: hsla(0,0%,100%,.5) hsla(210,59%,13%,.9); >+ -moz-border-bottom-colors: hsla(0,0%,100%,.5) hsla(210,59%,13%,.9); >+ -moz-border-right-colors: hsla(0,0%,100%,.5) hsla(210,59%,13%,.9); >+ } >+ >+ #appmenu-button[channel=aurora] { >+ -moz-border-left-colors: hsla(0,0%,100%,.5) hsla(214,89%,21%,.9); >+ -moz-border-bottom-colors: hsla(0,0%,100%,.5) hsla(214,89%,21%,.9); >+ -moz-border-right-colors: hsla(0,0%,100%,.5) hsla(214,89%,21%,.9); >+ } Any reason why this isn't just using label=Nightly/Aurora? The colors for nightly and aurora seem similar enough that you'll mostly only notice the difference in a side-by-side comparison, which may not be worth the extra code. Presumably some color in between could be shared between the two.

I think Stephen picked these colors pretty carefully. Users won't normally have both running (although with a plan to use separate profiles they might). The use case is more about composite screen shots that show all three. It might depend on the calibration of one's monitor, but for me nightly and aurora look very different. So overall, well worth the extra line of code for brand purposes.

(In reply to comment #9) > I think Stephen picked these colors pretty carefully. Users won't normally > have both running (although with a plan to use separate profiles they > might). The use case is more about composite screen shots that show all > three. It might depend on the calibration of one's monitor, but for me > nightly and aurora look very different. Yes, I didn't question that the difference is obvious when shown side by side. I still don't think that's worth caring about. The really interesting question is whether it would hurt the nightly brand if the button was a tad lighter and whether it would hurt the aurora brand if the button was a tad darker. > So overall, well worth the extra line of code for brand purposes. It's not one extra line of code. (I only quoted an excerpt of the patch.)

>The really interesting question is whether it would hurt the nightly brand if >the button was a tad lighter and whether it would hurt the aurora brand if the >button was a tad darker. We could introduce a lighter shade of blue for aurora, but overall I want three different buttons, and I want nightly to be black (because that makes it awesome). I'm hesitant for us to bikeshed this too much, but yeah, I really want special buttons for each version, so either way the code needs to be at this level of complexity, regardless of the colors selected.

I know where you're coming from. At the same time, I can't accept arbitrary levels of complexity, for obvious reasons. The complexity here is particularly troubling because we're reimplementing a good part of the button styling with differently weighted CSS selectors (which are competing e.g. against the styling for the button in private browsing mode) and without nightly testers testing what we're going to ship to end users. Gavin: Can we get a patch using ifdefs? That would avoid the CSS selector mess.

This is going to initially sound really off topic, but one of the usability problems we are having with sync is that we lack a good ambient indicator that an instance of Firefox is associated with a particular person's sync account (so for instance, if you save a password it isn't just saved locally but it is also uploaded to that person's sync account). As a possible solution we are playing around with letting you specify your favorite color as part of the sync/firefox account sign up process. This then gets applied to the Firefox button, and also gets us around the problem that not everyone likes orange. Mockup here: (scroll down to "these aren't my passwords" next to a portal joke) http://people.mozilla.com/~faaborg/files/projects/sync/usabilityProblems/# So the black/blue/orange would just be the starting default value before the user had a chance to modify it (assuming they decided to, they could also just keep the default). Would it be easier for us to insert a pref to hold the button color, and then query that, in preparation for it potentially changing more in the future?

It wouldn't be easier in the sense that the ability to pick up any color would need to be implemented first. But if this were in place, this particular change would be easy, since we can set branding-specific prefs.

Here's another patch using ifdefs. I chose to use the current orange #ifdef MOZ_OFFICIAL_BRANDING, the Aurora color #if MOZ_UPDATE_CHANNEL == aurora, and the Nightly color otherwise. That bakes in assumptions about branding vs. update channels, which is somewhat bothersome, but probably won't be much of a problem in practice?

waiting it to be landed.

Any update on when we'll be landing this?

(In reply to comment #17) > Any update on when we'll be landing this? i'm curious about that too.

This ifdef patch is a little bit annoying, but I don't think I'll be able to come up with a better solution unless the styles are simplified so there are fewer differences between the various stylings. I guess we should just go with this for now.

is UX branch also having separate colour?

yes, i guess. when merge m-c to ux

i meant is UX branch going to have DIFFERENT COLOUR just like nightly , aurora and beta/final branches?

No, UX will be the same as Nightly.

(In reply to comment #21) > http://hg.mozilla.org/mozilla-central/rev/23d62ec418d3 no checkin on Aurora ?

No, I don't think this will be landing on Aurora builds (it will migrate over on the next trunk->aurora transition).

(In reply to comment #1) > Created attachment 525501 [details] > App Button Color Mockup (In reply to comment #28) > No, I don't think this will be landing on Aurora builds (it will migrate > over on the next trunk->aurora transition). OK, then Aurora button color will be changed after Firefox 8a2 ? Firefox 7a2 (on Aurora channel now) button color is not changed ?

That's correct.

Mozilla/5.0 (Windows NT 5.1; rv:8.0a1) Gecko/20110724 Firefox/8.0a1 Verified issue on Windows XP and Windows 7 on the Nightly builds. Appmenu button for the Nightly builds is now black. Waiting for the change to land in Aurora builds also.

For the record, it would be much appreciated if grace and I were cc'ed on bugs like this in the future because this affects the branding of the product. Are there plans for a similar change for Mac or linux in the future?

I don't think mac and Linux have an App button like Windows so I don't know how this could apply there.

(In reply to Asa Dotzler [:asa] from comment #33) > I don't think mac and Linux have an App button like Windows so I don't know > how this could apply there. Linux has an optional button but we don't have any immediate plans to give it the same treatment.

I know they don't have the similar button, but was more asking if there was a similar type of color change in the works--a colored title bar? Something similar?

>it would be much appreciated if grace and I were cc'ed on bugs like this in the >future because this affects the branding of the product. Sorry about that, we did discuss this with Mayumi back when we were working on the branding of the three channels (and landing new icons and about windows). I'll be sure to cc you and grace in the future, although it of course might be awhile before we make any other significant brand changes.

The colors shown on https://wiki.mozilla.org/Releases#Upcoming_Releases for Aurora and Nightly channels are purple and blue respectively. Also the program icons are predominantly purple and blue. But this bug colors the buttons in the opposite way. There should be some consistency.