+++ This bug was initially created as a clone of Bug #960672 +++ STR 1. Look at nice new flat design of compose header (thanks to :JosiahOne and :paenglab!), and be impressed :) 2. Look closer Actual Result Notice the odd thing that somehow stands out badly (probably especially on Windows XP): Recipient type selectors (where you can choose between To:, CC:, BCC etc) are now visually over-emphasized because they are the only control in the header that doesn't have the new "flat" design when inactive... :( (see Screenshot 1) Expected Result Do the same css magic on Recipient type selectors that we did on the From: selector, to make them blend in smoothly with our new design :) According to the new design, controls are emphasized only on hover and focus, and they blend back into the header background when not currently active (i.e. after user has made his choices and is done with them). Recipient type selectors should do the same, as they are not substantially different or more important than the rest of the header controls (in fact, they might even be less frequently used). So no reason to let them stand out like that with native non-flat design. Let From: and To: be siblings as they are... Default (blend in with flat look): see Screenshot 2 Hover/Focus: see Screenshot 3

Comment on attachment 8363787 [details] Screenshot 2: Proposed design (when inactive): Recipient type selectors blend in nicely with new flat design So here's the deal here. I definitely agree something needs to be done with the recipient type selectors (thanks for filing the bug!), but the approach shown in this image (which I actually did in the original compose bugs), has some UX issues, which is why it wasn't pursued. 1) The act of hiding the entire background makes it very hard to tell you can change the settings. With the textfields it makes more sense, since one would expect that on a compose window, long lines indicate recipient lines. For these buttons though, it doesn't work as well. 2) Having the arrow at the far left looks a little odd since there is no background. That said, I am going to try to "flatten" the look as you suggested without removing the background. Perhaps similar to the "Restore Defaults" button shown in the new Australis Customize mode.

I'm also okay to make them less stand out. When I created the patch I already tried set the aw-menulist background-color to aw-menulist and let only the border but the I decided to made it like it is now to be in synch with the other platforms. The aw-menulist is already specially styled because it looked weird on Classic with the depressed default appearance. Josiah, when you change this, please also change the Classic style in messengercompose-aero.css.

Comment on attachment 8363787 [details] Screenshot 2: Proposed design (when inactive): Recipient type selectors blend in nicely with new flat design Let's see what Josiah proposes.

So this isn't exactly how it would look when it's done (I might change some of the colors a little bit), but it gives you an idea of what my vision is here. This way the button is still noticeable, but not as distracting. Let me know your thoughts. This mockup is OS X only, but the idea is similar on other platforms as well.

Comment on attachment 8364341 [details] Flat button proposed design (hover & focus) This looks good and this is the way we can go. Have you tried how it looks when the inactive menulist has the same background color like the headers, like only a wireframe?

This makes the change on Linux and Windows. As I don't have a Windows build system set up, Richard, could you please create the Windows one? Thanks.

(In reply to Richard Marti (:Paenglab) from comment #7) > Comment on attachment 8364341 [details] > Flat button proposed design (hover & focus) > > This looks good and this is the way we can go. Have you tried how it looks > when the inactive menulist has the same background color like the headers, > like only a wireframe? Like Richard, I'd suggest that there's no need for the inactive recipient-type menulist to have a different shade of background color. Just the thin grey border is enough to mark this control. Different shade actually hampers with Josiah's main idea of "flat postcard" layout.

Comment on attachment 8373743 [details] [diff] [review] OS X + Linux Change Review of attachment 8373743 [details] [diff] [review]: ----------------------------------------------------------------- Thank you for the patch. Not checked on OS X, but I count on you it looks good. Please can you attach a screenshot for reference? I tried the wireframe proposal and it doesn't look enough like a button, more like a input field. The darker background is different enough to show it's not a input field. ui-r+ I r- it because you should look if the !important are really needed. And also for the other comments. ::: mail/themes/linux/mail/compose/messengercompose.css @@ +371,5 @@ > -moz-border-left-colors: ThreeDShadow ThreeDHighlight !important; > } > > .aw-menulist { > + -moz-appearance: none !important; The !important isn't needed when you remove the -moz-appearance: button; on line 391. Then also the -moz-margin-end: 7px; can be moved to this rules. @@ +375,5 @@ > + -moz-appearance: none !important; > + -moz-margin-start: 5px; > + background-color: rgba(125, 125, 125, .3); > + border: rgba(125, 125, 125, .4) 1px solid; > + transition: background-color .4s ease-in, border .5s ease-in; The border transition isn't needed. There is no border change. @@ +379,5 @@ > + transition: background-color .4s ease-in, border .5s ease-in; > +} > + > +.aw-menulist:-moz-window-inactive { > + opacity: .8; .8 is almost not visible. I used for Windows Classic and XP .7. ::: mail/themes/osx/mail/compose/messengercompose.css @@ +663,5 @@ > border-bottom: 1px solid #C6C6C6 !important; > } > > +.aw-menulist { > + -moz-appearance: none !important; Are the !important here and for background-color and border really needed? @@ +665,5 @@ > > +.aw-menulist { > + -moz-appearance: none !important; > + -moz-margin-start: 5px; > + padding-left: 5px; Please use -moz-padding-start. @@ +669,5 @@ > + padding-left: 5px; > + background-color: rgba(200, 200, 200, .4) !important; > + border: rgba(149, 165, 166, 0.3) 1px solid !important; > + background: url("chrome://global/skin/arrow/arrow-dn.gif") no-repeat left; > + nit: whitespace @@ +670,5 @@ > + background-color: rgba(200, 200, 200, .4) !important; > + border: rgba(149, 165, 166, 0.3) 1px solid !important; > + background: url("chrome://global/skin/arrow/arrow-dn.gif") no-repeat left; > + > + transition: background-color .4s ease-in, border .5s ease-in; Again border transition not needed.

This is the Windows patch. For Aero I made the menulist more transparent and removed the box-shadow. On hover the standard appearance is used. It looks then like the format menulist you can see in screenshot I'll upload next. Win7 Classic and XP are looking similar. I also shifted the aw-menulist to the right to align the labels from "From:", "To:" and "Subject" on Win7.

Screenshot with patch applied. On top Win7 and on bottom Win7 Classic. As wrote in previous comment XP is looking similar to Classic.

(In reply to Richard Marti (:Paenglab) from comment #10) > Comment on attachment 8373743 [details] [diff] [review] > OS X + Linux Change > > Review of attachment 8373743 [details] [diff] [review]: > ----------------------------------------------------------------- > > Thank you for the patch. > > Not checked on OS X, but I count on you it looks good. Please can you attach > a screenshot for reference? > I tried the wireframe proposal and it doesn't look enough like a button, > more like a input field. The darker background is different enough to show > it's not a input field. ui-r+ > > I r- it because you should look if the !important are really needed. And > also for the other comments. I forgot to write, I think .4s transition is a bit to slow. For XP I've set .25s.

The background-color !importants were necessary, but the others weren't. Addressed feedback.

Comment on attachment 8374400 [details] [diff] [review] Patch for Windows Review of attachment 8374400 [details] [diff] [review]: ----------------------------------------------------------------- Looks good. Thanks!

Comment on attachment 8375069 [details] [diff] [review] OS X + Linux Change Review of attachment 8375069 [details] [diff] [review]: ----------------------------------------------------------------- Looks good. Thanks!

https://hg.mozilla.org/comm-central/rev/effd19c7f41b https://hg.mozilla.org/comm-central/rev/763baab54266

Yay for dropdown arrow on the left, going against platform standard widgets :) But better than the old rectangular white shining menu standing out from the new design.

The dropdown arrow is already since a long time on the left.

Just FTR: I do NOT consider this bug fixed, instead the current buttonish design of recipient type selectors is a visual pita (especially as you add more recicpients and that grey block becomes bigger), a complete alien still standing out too much and behaving odd as it is not consistent with any other element of the same type (dropdown input list), neither old nor new design, neither inside nor outside the header (looking at TB31 on Windows XP). But I can't compete with weird arguments like comment 10 that the recipient type dropdown list mustn't look like an input field, but should look like a button instead. To me, the ux concept of a dropdown input list has a lot more in common with an input field (with predefined set of values to choose from) than with a button. This is NOT a button, not even a menu-button (like "Other Actions" button in message reader), as you can easily see from the typical input behaviour where pressing the first letter of a dropdown option will select that option (e.g. press "b" to select "Bcc"). So yes, even keyboard *input* is possible in this element! Menu-buttons come with menus, and menus are grey and come with marked access keys - not seen here! Even the odd and ugly "Other Actions" button has better styling than recipient type selectors, because at least the former does not stand out when not used, so it's not screaming at users with its over-saliency; it just blends in with the background. Under the circumstances of the new flat header (which might be another discussion worth having), I think any of the following would be visually and functionally better than current recipient type selector design (in order of preference, most preferred first): - wireframe (same background color as rest of header, thin grey border all around to connect the dropdown arrow with the caption) - bottom-line (same background color, thin grey border at bottom) - no frame (same background color, no borders) Whichever variant should then have the "normal" hover effect (white background on mouse-over), exactly as seen on "From" dropdown input list which is exactly the same type of control. Imo it looks quite unprofessional and it's completely beyond me why controls of the same type in the same widget should look and behave differently without sufficient necessity or advantage. That's needlessly breaking the core UX concept of the windows platform, whose success was also based on offering standardized controls of the same design and behaviour accross all applications. But alas, somehow the whole new composition header breaks with that idea...