988480 - Implement Mac OSX styling of Translation Infobar

Status: VERIFIED FIXED

(Firefox :: Theme, defect)

Description

[Marco Mucci [:MarcoM]]

Implement Mac OSX styling of translation infobar

Comment 1

[Asaf Romano (gone)]

I cannot find the UX spec for this. I could only find bugs for Windows and Linux.

Comment 2

[Sevaan Franks [:sevaan]]

v(In reply to Mano from comment #1)
> I cannot find the UX spec for this. I could only find bugs for Windows and
> Linux.

Hi Mano, here you go!

http://cl.ly/image/231i3n1H1T2H

Comment 3

[Asaf Romano (gone)]

@Sevaan: So this is all pretty trivial to implement, but I have a question: is it intended that this bar would appear notably different from other info-bars (popup blocking for instance), or is this design (more or less) going to find its way elsewhere? If it's the later, it'd be good to evaluate the other info-bars at this point.

My question probably applies to the other themes as well.

Comment 4

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Mano from comment #3)
> @Sevaan: So this is all pretty trivial to implement, but I have a question:
> is it intended that this bar would appear notably different from other
> info-bars (popup blocking for instance), or is this design (more or less)
> going to find its way elsewhere? If it's the later, it'd be good to evaluate
> the other info-bars at this point.
> 
> My question probably applies to the other themes as well.

Comment 5

[Marco Bonardo [:mak]]

(In reply to Mano from comment #3)
> My question probably applies to the other themes as well.

Yep, I had basically the same question for Windows and Linux.
In addition, how is this supposed to react to the presence of the Bookmarks Toolbar, I assume it should just cover it, or should it stick to content top and not have an arrow?

Comment 6

[Sevaan Franks [:sevaan]]

Hi all,

Yep, this is it's own infobar now. It is different than the other infobars due to the fact that it is not just alerting the user to something, but rather it is a persistent toolbar that requires frequent interactions with the user. This means it needs a larger target area than the other infobars provide in order to a) make it more obvious when it appears, and b) make it easier for users to click on items.

This applies to Windows and Linux as well.

When the bookmark bar is present, the translation infobar appears underneath it. However, there is no "arrow" pointing to the translation icon in the URL bar as the bookmark's bar is in the way.

Comment 7

[Florian Quèze [:florian]]

(In reply to Marco Bonardo [:mak] from comment #5)

> In addition, how is this supposed to react to the presence of the Bookmarks
> Toolbar, I assume it should just cover it, or should it stick to content top
> and not have an arrow?

(In reply to Sevaan Franks from comment #6)

> When the bookmark bar is present, the translation infobar appears underneath
> it. However, there is no "arrow" pointing to the translation icon in the URL
> bar as the bookmark's bar is in the way.

Implementing the arrow is bug 990633.

Comment 8

[Asaf Romano (gone)]

This is blocked by the shared-theme changes, which Marco is working on in bug 988481 (which, in turn, are blocked by UX-feedback). Once that's all done, it's just a matter of setting the colors in the OS X theme.

Comment 9

[Asaf Romano (gone)]

So, looking at the final styling for windows and linux, and considering that the OS X styling should be updated accordingly, I'm not sure how to proceed here. Those huge buttons are going to look out of place *especially* alongside the small native dropdowns.  Sevaan, could you please update the mockup with respect to the final windows design?

Comment 10

[Sevaan Franks [:sevaan]]

(In reply to Mano from comment #9)
> So, looking at the final styling for windows and linux, and considering that
> the OS X styling should be updated accordingly, I'm not sure how to proceed
> here. Those huge buttons are going to look out of place *especially*
> alongside the small native dropdowns.  Sevaan, could you please update the
> mockup with respect to the final windows design?

Hi Mano,

To clarify, Windows and Linux can share their styling, but OSX, being a different beast all together, requires it's own look and feel, hence the different design attached above. So there is not one unified translation infobar look between all systems...Mac is separate.

Does that clear things up a bit?

Comment 11

[Asaf Romano (gone)]

Thanks for the prompt reply, Sevaan!

Two more things: 1) what's the border details (color, size, radius) for the blue button? 2) any height specifications, or should I go with the native proportions?

Comment 12

[Sevaan Franks [:sevaan]]

(In reply to Mano from comment #11)
> Thanks for the prompt reply, Sevaan!
> 
> Two more things: 1) what's the border details (color, size, radius) for the
> blue button? 2) any height specifications, or should I go with the native
> proportions?

Hey Mano,

1) I attempted to make some CSS for the button as a starting point. Hopefully this helps some! https://people.mozilla.org/~sfranks/Translation/buttons.html

2) The bar should be 33px, including the borders. At least that's how I measured it in Photoshop. Maybe use native proportions and see how it looks first.

Comment 13

[Asaf Romano (gone)]

Thanks again Seavann

Last questions, I think: I noticed that in in-content preferences the drop-down are not native even on OS X. Should I adopt that styling or go with the native dropdown? This may also be related to the proportions issue, because in in-content prefs the menulist and buttons sizes have nothing to do with "native" proportions. It's all hardcoded.

Comment 14

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

Attachment: Prompts.png

An example of the OSX styling on the bottom.

Comment 15

[Sevaan Franks [:sevaan]]

Hey Mano, hold off a moment. Mmaslaney and I were reviewing this bug together, and we think the Project Chameleon work has come far enough since this bug was submitted that we can actually use that styling.

Comment 16

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

Chameleon Documentation (work in progress)

http://people.mozilla.org/~jgruen/chameleon/#nav0

Comment 17

[Sevaan Franks [:sevaan]]

(In reply to Mano from comment #13)
> Thanks again Seavann
> 
> Last questions, I think: I noticed that in in-content preferences the
> drop-down are not native even on OS X. Should I adopt that styling or go
> with the native dropdown? This may also be related to the proportions issue,
> because in in-content prefs the menulist and buttons sizes have nothing to
> do with "native" proportions. It's all hardcoded.


So I guess this question is answered now...Chameleon :-)

Comment 18

[Asaf Romano (gone)]

Attachment: bearable

Comment 19

[Asaf Romano (gone)]

Attachment: screenshot

Comment 20

[Asaf Romano (gone)]

Attachment: bearable #2

Fix label & background colors.

Comment 21

[Asaf Romano (gone)]

Attachment: screenshot

Comment 22

[Asaf Romano (gone)]

Ignore -moz-margin-start: -1. No idea what was the goal there.

Comment 23

[Marco Bonardo [:mak]]

in the screenshot the text in the form elements looks a little bit too high (off-hand by 1 or 2 px), is it just me?

Comment 24

[Asaf Romano (gone)]

Attachment: along the lines of "bearable"

Comment 25

[Asaf Romano (gone)]

Attachment: screenshot

Comment 26

[Asaf Romano (gone)]

Attachment: improve the menulist a little bit

Comment 27

[Asaf Romano (gone)]

Attachment: screenshot

Comment 28

[Asaf Romano (gone)]

Sevaan, I must ask: did you intend to set a pointer cursor for the buttons?

Comment 29

[Sevaan Franks [:sevaan]]

(In reply to Mano from comment #28)
> Sevaan, I must ask: did you intend to set a pointer cursor for the buttons?

cursor:default please!

Comment 30

[Sevaan Franks [:sevaan]]

Comment on attachment 8428828 [details]
screenshot

Hi Mano,

I don't think we should use Fixed widths for the buttons. It's looking too blocky. Also the down arrow in the "Options" button is not positioned in the same place as the double-arrow in the Language drop-down.

Going to ping Michael Maslaney to look at this too.

Comment 31

[Asaf Romano (gone)]

1) I copied cursor: pointer from
https://people.mozilla.org/~sfranks/Translation/buttons.html

2) I think, but I'm not sure, that on other platforms we use fixed-width buttons in this infobar.

Comment 32

[Asaf Romano (gone)]

...at least that's what I see in
https://bug988481.bugzilla.mozilla.org/attachment.cgi?id=8420452

But the code suggests this was undone.

Is any extra padding desired for the Translate button?

Comment 33

[Sevaan Franks [:sevaan]]

(In reply to Mano from comment #31)
> 1) I copied cursor: pointer from
> https://people.mozilla.org/~sfranks/Translation/buttons.html
> 
> 2) I think, but I'm not sure, that on other platforms we use fixed-width
> buttons in this infobar.

1) Let's switch it back to cursor:default and ignore my buttons.

Don't forget we are not using my button styles anymore. We'll be using the buttons from the Chameleon project, so please copy the CSS from there: http://people.mozilla.org/~jgruen/chameleon/#nav0

See mmaslaney's screenshot above (https://bug988480.bugzilla.mozilla.org/attachment.cgi?id=8427797) for a better idea of how the infobar should look (Note: the option menu should remain on the right-side, not the left like in the attachment)

The Chameleon stuff is still a work-in-progress and was done after the initial styling for the Mac toolbar was made, but we should switch to it as as it will be the path forward, and we will have to change it in the future.

2) They're not fixed width in mmaslaney's screenshot, and since he is one of the Chameleon designers, we should defer to his interpretation of the toolbar!

Comment 34

[Asaf Romano (gone)]

What css rules? I see none at http://people.mozilla.org/~jgruen/chameleon/#nav0

Comment 35

[Asaf Romano (gone)]

So, if by "rules" you referred to the colors and glyphs mentioned there, I just cannot stress enough my frustration here. In comment 9 I asked if the Windows and Linux design is going to apply on OS X. That design is obviously based on the Chameleon stuff, and it landed before I posted my question about it. Your reply in comment 10 made it clear that I should ignore the Window and Linux design. So I went ahead and spent quite a while with implementing the design proposed here... just to figure out that the Windows & Linux design (the shared theme) is the way to go after all.

Comment 36

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

(In reply to Sevaan Franks [:sevaan] from comment #30)
> Comment on attachment 8428828 [details]
> screenshot
> 
> Hi Mano,
> 
> I don't think we should use Fixed widths for the buttons. It's looking too
> blocky. Also the down arrow in the "Options" button is not positioned in the
> same place as the double-arrow in the Language drop-down.
> 
> Going to ping Michael Maslaney to look at this too.

I added 10px of right and left padding for each button with a minimum set-width of 64px. The button radius should be set to 2px for all buttons. Is there a reason we use two different arrows for the dropdown?

Comment 37

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

Attachment: Dropdown-glyph.png

Comment 38

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

Attachment: [e-mail]

Comment 39

[Asaf Romano (gone)]

The obvious difference is that the first one is a menulist, in which the double-arrow dropmarker is the standard on OS X (and that's how it used in any other in-content ui as well, by the way) and the second one is a menu button, which is usually themed either with a single arrow dropmarker or with no dropmarker at all.

Comment 40

[Asaf Romano (gone)]

min-width of 64px would result in practically fixed width buttons, which Sevaan don't like.

I'm un-taking this bug until there's a clear spec. It's clearly not ready for work. In the spec, please also take care of the focus state, because I don't see how this flat blue boxes play with OS X's blue focus ring (we cannot simply ignore accessibility).

Comment 41

[Sevaan Franks [:sevaan]]

(In reply to Mano (needinfo? for any questions; not reading general bugmail) from comment #35)
> So, if by "rules" you referred to the colors and glyphs mentioned there, I
> just cannot stress enough my frustration here. In comment 9 I asked if the
> Windows and Linux design is going to apply on OS X. That design is obviously
> based on the Chameleon stuff, and it landed before I posted my question
> about it. Your reply in comment 10 made it clear that I should ignore the
> Window and Linux design. So I went ahead and spent quite a while with
> implementing the design proposed here... just to figure out that the Windows
> & Linux design (the shared theme) is the way to go after all.

Hi Mano, I understand your frustration.

There are a lot of related projects going on at once. The Chameleon stuff was not ready when this bug was posted, and prior to your asking about what styling to use, the direction that was decided by UX was to have Windows and Linux as one style, and Mac as the next.

You began work, but while that was happening, designers were also working on Project Chameleon and reached a point where they now had a style that could apply to all OSs. So that is why there was a change. If we didn't intercept and make this change now, all your work would be written over in a later bug when we would have to change things over to the Chameleon style.

A more detailed spec will be posted shortly.

Comment 42

[Sevaan Franks [:sevaan]]

(In reply to Mano (needinfo? for any questions; not reading general bugmail) from comment #34)
> What css rules? I see none at
> http://people.mozilla.org/~jgruen/chameleon/#nav0

You would have to view the source, like you did with my buttons HTML. I'll copy the CSS out for you.

Comment 43

[Marco Mucci [:MarcoM]]

Removed from Iteration 32.3

Comment 44

[Asaf Romano (gone)]

Seavaan, with all due respect, "View Source" is not a spec. You don't need to copy the rules, you need the specify the precise look & feel for all states (normal, hover, pressed *and focused*). The size properties are persistent across all states, obviously, but anything else should be well specified for each state. Without native appearance set, we do need to set everything in css.

Comment 45

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

Attachment: dialog_prompt_spec_buttonMargins.png

Specs from another prompt. Ignore the button to the right which is a combo not a dropdown.

Comment 46

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

Attachment: dialog_prompt_spec_margins

Margins

Comment 47

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

Attachment: forms1.png

Buttons

Comment 48

[Sevaan Franks [:sevaan]]

Alright folks! A decision has been made. We will not be proceeding with Chameleon skin, and will instead continue with the work Mano has done above with his Mac styling.

Comment 49

[Sevaan Franks [:sevaan]]

Attachment: Suggested revisions to current state.

Hi Mano, I have some some suggested changes to the Infobar design you have implemented so far.

Please note the buttons are a little smaller, and the Translation and Close icons have been moved slightly too.

Comment 50

[Sevaan Franks [:sevaan]]

The buttons should have left and right padding of 25px, and a 10px space between them.

Comment 51

[Marco Bonardo [:mak]]

I'm not sure it's very wise to use absolute px values when the user can change the system fonts (and their size) and then the buttons will look totally unbalanced. That's why I used em and ch in the first place for Win/Lin.

Comment 52

[Asaf Romano (gone)]

I agree.

Comment 53

[Sevaan Franks [:sevaan]]

I provided px because I am just working off a screenshot and that's how I can interact with it in Photoshop. Could you provide me with the font size used for the text in the infobar and buttons so I can give you the appropriate EM measurements?

Comment 54

[Sevaan Franks [:sevaan]]

Can be converted using http://pxtoem.com/

Comment 55

[Tim Taubert [:ttaubert] (inactive)]

Marco, can you please add this back to the current iteration? Thank you!

Comment 56

[Marco Mucci [:MarcoM]]

Added to Iteration 32.3

Comment 57

[Asaf Romano (gone)]

Attachment: patch

Comment 58

[Asaf Romano (gone)]

Attachment: screenshot

Comment 59

[Asaf Romano (gone)]

Attachment: theme.diff

Comment 60

[Asaf Romano (gone)]

Attachment: patch!

Comment 61

[Asaf Romano (gone)]

Attachment: screenshot!

Comment 62

[Asaf Romano (gone)]

Comment on attachment 8431042 [details] [diff] [review]
patch!

False alarm.

Comment 63

[Asaf Romano (gone)]

Attachment: patch

Comment 64

[Asaf Romano (gone)]

Attachment: screenshot

Comment 65

[Sevaan Franks [:sevaan]]

That looks great, Mano. Thanks for putting it together!

Comment 66

[Marco Bonardo [:mak]]

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

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

::: browser/components/translation/translation-infobar.xml
@@ +22,5 @@
>        <xul:hbox class="notification-inner outset" flex="1" xbl:inherits="type">
>          <xul:hbox anonid="details" align="center" flex="1">
> +          <xul:image class="translate-infobar-element messageImage"
> +                     anonid="messageImage"/>
> +          <xul:deck class="translationStates" anonid="translationStates" selectedIndex="0">

doesn't look like you are using this translationStates class, I'd say to avoid adding stuff we don't have an immediate use for

@@ +32,4 @@
>                  <xul:menupopup/>
>                </xul:menulist>
> +              <xul:label class="translate-infobar-element" value="&translation.translateThisPage.label;"/>
> +              <xul:button class="translate-infobar-element translate-button"

you may avoid the translate-button class by using [anonid="translate"] in the only remaining rule.

@@ +32,5 @@
>                  <xul:menupopup/>
>                </xul:menulist>
> +              <xul:label class="translate-infobar-element" value="&translation.translateThisPage.label;"/>
> +              <xul:button class="translate-infobar-element translate-button"
> +                          label="&translation.translate.button;" anonid="translate"

please move anonid to its own line

@@ +41,5 @@
>              </xul:hbox>
>  
>              <!-- translating -->
> +            <xul:hbox class="translating-box" pack="center">
> +              <xul:label class="translate-infobar-element" 

trailing space

@@ +49,5 @@
>              <!-- translated -->
>              <xul:hbox class="translated-box" align="center">
> +              <xul:label class="translate-infobar-element" 
> +                         value="&translation.translatedFrom.label;"/>
> +              <xul:menulist class="translate-infobar-element" 

trailing spaces here and in the label...

There are other trailing spaces below, not going to comment further, but please fix them.

@@ +76,5 @@
>              <xul:hbox class="translation-error" align="center">
> +              <xul:label class="translate-infobar-element" 
> +                         value="&translation.errorTranslating.label;"/>
> +              <xul:button class="translate-infobar-element" 
> +                          label="&translation.tryAgain.button;" anonid="tryAgain"

please move anonid to its own line

@@ +85,5 @@
>            <xul:spacer flex="1"/>
>  
> +          <xul:button type="menu"
> +                      class="translate-infobar-element options-menu-button"
> +                      anonid="translate-infobar-element" label="&translation.options.menu;">

please move label to its own line

::: browser/themes/osx/browser.css
@@ +4437,5 @@
>    padding-left: 0;
>    padding-right: 0;
>  }
> +
> +/* Translation infobar */

please do not append to browser.css, there are already some rules for translation above, we should try to keep them together.
Other themes added this code just before ".translate-notification-icon," selector, I think it's wise to keep this consistent across themes.

@@ +4450,5 @@
> +  border-bottom: 1px solid #c4c4c4;
> +  padding-top: 1px;
> +  padding-bottom: 1px;
> +  -moz-padding-start: 11px;
> +  -moz-padding-end: 9px;

I think we should do this (aligning left/right padding) globally for all infobars, see https://bugzilla.mozilla.org/show_bug.cgi?id=1009501
I'd remove these 2 rules for now to get a more proper global fix.

@@ +4460,5 @@
> +}
> +
> +button.translate-infobar-element,
> +menulist.translate-infobar-element {
> +  font-size: 12px;

srsly, please do not use fixed sizes. I'd remove this rule and trust the system font. it still looks good.

@@ +4468,5 @@
> +button.translate-infobar-element {
> +  background: linear-gradient(rgba(255, 255, 255, 0.8), rgba(255, 255, 255, 0.1)) repeat scroll 0% 0% padding-box transparent;
> +  border: 1px solid;
> +  border-color: rgba(23, 51, 78, 0.15) rgba(23, 51, 78, 0.17) rgba(23, 51, 78, 0.2);
> +  border-radius: 2.5px 2.5px 2.5px 2.5px;

please remove this radius rule, the shared stye is fine here, indeed I can't see any distinguishable difference removing this on my Retina.

@@ +4508,5 @@
> +}
> +
> +button.translate-infobar-element.translate-button:hover {
> +  background-image: linear-gradient(#66bdff, #0d9eff);
> +  box-shadow: 0 1px 0 hsla(0,0%,100%,.2) inset,  0 0 0 1px hsla(0,0%,100%,.1) inset,  0 1px 0 hsla(210,54%,20%,.03),  0 0 4px hsla(206,100%,20%,.2);

could we please reuse the box-shadow that is already defined for button.translate-infobar-element:hover and button.translate-infobar-element:active? the difference is so minimal that doesn't seem to make sense to differentiate them...

Just remove box-shadow and keep the background image.

@@ +4514,5 @@
> +
> +button.translate-infobar-element.translate-button:active {
> +  box-shadow: 0 1px 1px hsla(211,79%,6%,.1) inset,  0 0 1px hsla(211,79%,6%,.2) inset;
> +  transition-duration: 0ms;
> +}

all of this can be removed, it's the same as button.translate-infobar-element:active, no reason to repeat it

@@ +4532,5 @@
> +@media (min-resolution: 1.25dppx) {
> +  button.translate-infobar-element.options-menu-button > .button-box > .button-menu-dropmarker {
> +    list-style-image: url("chrome://browser/skin/[e-mail]");
> +  }
> +  

trailing spaces

@@ +4542,5 @@
> +menulist.translate-infobar-element {
> +  text-shadow: 0 1px 1px #FEFFFE;
> +  border: 1px solid;
> +  border-color: rgba(23, 51, 78, 0.15) rgba(23, 51, 78, 0.17) rgba(23, 51, 78, 0.2);
> +  border-radius: 5px;

I don't understand this, it should be consistent with the other controls (so 2px), it doesn't seem to make a difference fwiw. I'd just remove it.

@@ +4545,5 @@
> +  border-color: rgba(23, 51, 78, 0.15) rgba(23, 51, 78, 0.17) rgba(23, 51, 78, 0.2);
> +  border-radius: 5px;
> +  box-shadow: 0 1px 1px 0 #FFFFFF, inset 0 2px 2px 0 #FFFFFF;
> +  background-color: #F1F1F1;
> +  background-image: linear-gradient(#FFFFFF, rgba(255,255,255,0.1));

please always define color when defining a background.

::: browser/themes/shared/translation/infobar.inc.css
@@ +26,5 @@
>    }
>  }
>  
> +notification[value="translation"] menulist,
> +notification[value="translation"] button {

the inversion of menulist and button here seems pointsless and it's polluting blame without a gain, please revert

Comment 67

[Asaf Romano (gone)]

Attachment: landed

Sevann, note that the left and right alignment of the inforbar were not fixed after all. That's to be done in bug 1009501.

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

Comment 68

[Ryan VanderMeulen [:RyanVM]]

Backed out for mochitest-bc failures.
https://hg.mozilla.org/integration/fx-team/rev/2565dba570f2

https://tbpl.mozilla.org/php/getParsedLog.php?id=40748597&tree=Fx-Team

Comment 69

[Asaf Romano (gone)]

Attachment: patch.diff

Just a typo fix after all.

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

Comment 70

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/027e50b0286e

Comment 71

[Florian Quèze [:florian]]

Mano, are you taking care of the regressions caused by landing the patch here? (bug 1018976 and bug 1018981)

Comment 72

[Tim Taubert [:ttaubert] (inactive)]

Yes, we were talking about this earlier. Assigned the two bugs to Mano and we'll put them into the current iteration.

Comment 73

[Asaf Romano (gone)]

Yep.