1249610 - Add new InfoBar to Bedrock

Status: RESOLVED WONTFIX

(www.mozilla.org :: Pages & Content, defect)

Description

[Schalk Neethling [:espressive]]

With the new Tabzilla we no longer have the update and translation bars. This bug is to add the latter back to Bedrock using the new InfoBar

Comment 1

[Schalk Neethling [:espressive]]

Seeing that locale negotiation is handled on the server side on Bedrock, do we actually use the Translation Bar or, just the Update Bar on mozilla.org?

Comment 2

[Pascal Chevrel:pascalc (PTO until April 26)]

The translation bar is useful when you click on a link that has already the locale indicated, it proposes you the page in your locale if it exists. This is particularly useful for all the communication our marketing department does with links to mozilla.org pages on social media because the url shorteners always point to the final destination and since they don't do locale negotiation, it's always the en-US version of the page.

Comment 3

[Schalk Neethling [:espressive]]

(In reply to Pascal Chevrel:pascalc from comment #2)
> The translation bar is useful when you click on a link that has already the
> locale indicated, it proposes you the page in your locale if it exists. This
> is particularly useful for all the communication our marketing department
> does with links to mozilla.org pages on social media because the url
> shorteners always point to the final destination and since they don't do
> locale negotiation, it's always the en-US version of the page.

But of course, completely did not take that into account. Thanks Pascal!

Comment 4

[Schalk Neethling [:espressive]]

Attachment: Screen Shot 2016-02-19 at 16.40.30.png

Hey Holly,

So, this is an example of what the InfoBar will look like on mozilla.org

I reckon the current blue background is not what we want, perhaps another shade of blue from the current styleguide or, perhaps a completely different color altogether?

Let me know your thoughts. Thanks!

Comment 5

[Holly Habstritt Gaal [:Habber]]

We should keep in mind similar notification styles that were implemented across Mozilla.org. The following 2 come to mind:

- Translation bar bug 906943. I believe this is what was mentioned in the first comments in the bug. Is this still active? And if so, how to reproduce? Is this the style it uses still? http://cl.ly/3P1e290G1W19

- Download Firefox (on firefox/products for non-Firefox browsers http://cl.ly/2L2W1N2h2F3a)


It's possible that more than one notification can be displayed at once, in which case they would stack. I notice that the implementation in comment 4 displays the bar below tabzilla. We should consistently display all notifications above tabzilla, instead of some below and some above. We also still have navigation across mozilla.org that is displayed to the left of tabzilla. Keeping the notification bar above tabzilla will avoid any conflict with page content.  

Here are a few quick updates for the style:
- display above tabzilla
- white background like the 2 notification styles noted above
- primary CTA ("Update...") can stay as button (green for now and we can consult with mham later)
- secondary CTA ("Later") can be text link


Questions:
- Has this copy been approved by a copywriter and localized? 
- When a user chooses "Later", besides closing the notification, does it have an impact on when the notification will be seen again?
- On what pages across Mozilla.org do the translation and update notification displayed?


In an upcoming sprint I'd like to work with our visual designer, Mham, to address the styles in this component and document the rules as we are other CTAs across Mozilla.org.

Comment 6

[Schalk Neethling [:espressive]]

(In reply to Holly Habstritt Gaal [:Habber] from comment #5)
> We should keep in mind similar notification styles that were implemented
> 
> Questions:
> - Has this copy been approved by a copywriter and localized?

This uses the existing localized copy from:
https://github.com/mozilla/bedrock/blob/master/bedrock/tabzilla/templates/tabzilla/transbar.jsonp

> - When a user chooses "Later", besides closing the notification, does it
> have an impact on when the notification will be seen again?

The specific bar will not be shown again for the duration of the current user session. Should the user close the tab/window and return to the page, the relevant bar will be shown again.

> - On what pages across Mozilla.org do the translation and update
> notification displayed?

From my understanding this should be on all pages except /new :agibson?

> 
> In an upcoming sprint I'd like to work with our visual designer, Mham, to
> address the styles in this component and document the rules as we are other
> CTAs across Mozilla.org.

Sounds good Holly.

Comment 7

[Alex Gibson [:agibson]]

We used show the translation bar on all bedrock pages except for key areas where we don't want it interfering/distracting with the UI e.g.

- Firefox /tour page
- Hello FTU page

We used to show the update bar on all pages except for:

- /firefox/new

This is all from memory, but you can probably find all the answers in bedrock git history.

Comment 8

[Alex Gibson [:agibson]]

If it helps, all the existing CSS styling for the update bar should also in in tabzilla.less still.

Comment 9

[Alex Gibson [:agibson]]

(In reply to Holly Habstritt Gaal [:Habber] from comment #5)
> - secondary CTA ("Later") can be text link

This is just a terminology nit, but technically this should be a button, not a link. Buttons "do things", links "go places". I think the key here is the "Later" option should be secondary in terms of visual prominence? :)

Comment 10

[Schalk Neethling [:espressive]]

(In reply to Alex Gibson [:agibson] from comment #9)
> (In reply to Holly Habstritt Gaal [:Habber] from comment #5)
> > - secondary CTA ("Later") can be text link
> 
> This is just a terminology nit, but technically this should be a button, not
> a link. Buttons "do things", links "go places". I think the key here is the
> "Later" option should be secondary in terms of visual prominence? :)

Yes, agreed. I left this as a button and only changed the main CTA to a link as it "goes places" :)

Comment 11

[Schalk Neethling [:espressive]]

Thanks for the feedback Alex. So, the way it works currently is that it will show both bars on all pages unless, one explicitly turns of both or specify just one of the two.

With that, I guess the simplest is to identify the ages where we do not want:

1) either show
2) just the translation bar shown
3) just the update bar shown

Comment 12

[Schalk Neethling [:espressive]]

Attachment: Screen Shot 2016-02-22 at 15.20.33.png

Updated style implementation of the InfoBar

Comment 13

[Alex Gibson [:agibson]]

(In reply to Schalk Neethling [:espressive] from comment #11)
> Thanks for the feedback Alex. So, the way it works currently is that it will
> show both bars on all pages unless, one explicitly turns of both or specify
> just one of the two.
> 
> With that, I guess the simplest is to identify the ages where we do not want:
> 
> 1) either show
> 2) just the translation bar shown
> 3) just the update bar shown

I would just follow the same logic that was there before if that helps. I remember we went through this in some detail when it was initially implemented. Unless anything has changed in regard to how it all works, I would just keep the behavior consistent to how it was.

Comment 14

[Alex Gibson [:agibson]]

Sorry i hit enter too early:

to continue:

I'm not entirely clear from the comments here what has changed in terms of behavior. If something has changed then cool - but all we need to ensure is that we have the option to turn off either (or both) bars on an individual page basis. Hope that makes sense.

Comment 15

[Holly Habstritt Gaal [:Habber]]

(In reply to Alex Gibson [:agibson] from comment #9)
> (In reply to Holly Habstritt Gaal [:Habber] from comment #5)
> > - secondary CTA ("Later") can be text link
> 
> This is just a terminology nit, but technically this should be a button, not
> a link. Buttons "do things", links "go places". I think the key here is the
> "Later" option should be secondary in terms of visual prominence? :)

Yep. I was just referring to visual style here, so that the secondary action appears as such.

Comment 16

[Holly Habstritt Gaal [:Habber]]

(In reply to Alex Gibson [:agibson] from comment #13)
> (In reply to Schalk Neethling [:espressive] from comment #11)
> > Thanks for the feedback Alex. So, the way it works currently is that it will
> > show both bars on all pages unless, one explicitly turns of both or specify
> > just one of the two.
> > 
> > With that, I guess the simplest is to identify the ages where we do not want:
> > 
> > 1) either show
> > 2) just the translation bar shown
> > 3) just the update bar shown
> 
> I would just follow the same logic that was there before if that helps. I
> remember we went through this in some detail when it was initially
> implemented. Unless anything has changed in regard to how it all works, I
> would just keep the behavior consistent to how it was.

Schalk, once you check the logic that was initially implemented, could you post an update here with how it currently works? I assumed that there could be a case where both the language and download CTA could be displayed at once. If one is prioritized over the other, do we just show that one notification only... or do we show one at a time. So when it is completed, show the next one in succession?

Comment 17

[Schalk Neethling [:espressive]]

Hey All,

So, here is how it works.

There is a new {% block infobar %} in the base-resp and base templates. This contains some HTML and as part of it, the root element of this code block contains a data attribute, who's value is itself a {% block infobar_bars %}, with a default of "update translate"

This means that all pages will attempt to show both the update and translations bar across the site as appropriate.

If a page wants to not show any of these bars, it can just set the block to empty i.e.
{% block infobar %}{% endblock %}

We do this with the newsletter on multiple pages.

If you want to show only one of these bars, you can do this by specifying the relevant bar as such:
{% block infobar_bars %}update{% endblock %}

or

{% block infobar_bars %}translate{% endblock %}

Comment 18

[Schalk Neethling [:espressive]]

Attachment: Screen Shot 2016-02-23 at 14.31.03.png

On some pages, such as the family page, we might run into situations like the above. The InfoBar is not showing both but, there is a conditional download bar that is being shown.

Is this "ok" or:

1) Should we not have the InfoBar on these pages at all,
2) Add a check in the InfoBar code for the conditional download bar and, if present, not show the InfoBar?

Comment 19

[Schalk Neethling [:espressive]]

Attachment: Screen Shot 2016-02-23 at 14.36.13.png

I am guessing this is overkill :) and we really only need the translation bar here.

Comment 20

[Schalk Neethling [:espressive]]

Attachment: Link to Github pull-request: https://github.com/mozilla/bedrock/pull/3895

Comment 21

[Schalk Neethling [:espressive]]

Hey Holly,

do you foresee string changes being made to the current strings in the near future. We need to move these strings into a new lang file (it currently depends on tabzilla in a way), and just want to know what to expect. Thanks!

Comment 22

[Schalk Neethling [:espressive]]

Quick update:

Demo4 has been updated with the new infobar: http://www-demo4.allizom.org/

Comment 23

[Craig Cook (:craigcook)]

The future of this infobar is uncertain but it may take a different form as part of a new cross-site navbar we're exploring. Closing this bug.