1369755 - Adjust the wording for the Flash CTA experience

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, enhancement, P1)

Description

[:Felipe Gomes (needinfo for replies!)]

There's new copy to be changed for the CTA doorhanger and infobar:

"This site uses a plugin that may slow Firefox. Use anyway?"

Comment 1

[Benjamin Smedberg]

Or "Would you like to allow [domain] to run a plugin that may slow Firefox?"

Comment 2

[:Felipe Gomes (needinfo for replies!)]

(hopefully you haven't started on this yet)

Comment 3

[:Felipe Gomes (needinfo for replies!)]

Attachment: Bug 1369755 - Adjust the wording for the Flash Click-to-Activate infobar/doorhanger.

Review commit: https://reviewboard.mozilla.org/r/146924/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/146924/

Comment 4

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 8875490 [details]
Bug 1369755 - Adjust the wording for the Flash Click-to-Activate infobar/doorhanger.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/146924/diff/1-2/

Comment 5

[Benjamin Smedberg]

Attachment: Bug 1369755 part A - Add context about browser performance to the in-content UI.Remove the tap-to-activate UI on desktop, because we don't specifically say "click" on desktop anyway, and we don't want/need to customize it from PluginContent.jsm. ui-review

Review commit: https://reviewboard.mozilla.org/r/147256/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/147256/

Comment 6

[Benjamin Smedberg]

Attachment: Bug 1369755 part B - Adjust the wording of the infobar to more closely match the in-content UI, and the doorhanger to more closely match other permissions and be more personal. ui-review=sbarrett

Review commit: https://reviewboard.mozilla.org/r/147258/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/147258/

Comment 7

[Benjamin Smedberg]

Comment on attachment 8875490 [details]
Bug 1369755 - Adjust the wording for the Flash Click-to-Activate infobar/doorhanger.

https://reviewboard.mozilla.org/r/146924/#review151496

I'm going to take this back, since there was some nuance about in-content versus infobar versus notification. I have an alternate patch up for your review, and sbarrett did a final UX review over slack.

Comment 8

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 8875852 [details]
Bug 1369755 part A - Add context about browser performance to the in-content UI.Remove the tap-to-activate UI on desktop, because we don't specifically say "click" on desktop anyway, and we don't want/need to customize it from PluginContent.jsm. ui-review

https://reviewboard.mozilla.org/r/147256/#review151542

Comment 9

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 8875853 [details]
Bug 1369755 part B - Adjust the wording of the infobar to more closely match the in-content UI, and the doorhanger to more closely match other permissions and be more personal. ui-review=sbarrett

https://reviewboard.mozilla.org/r/147258/#review151548

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/6c35cc91b1bb
part A - Add context about browser performance to the in-content UI.Remove the tap-to-activate UI on desktop, because we don't specifically say "click" on desktop anyway, and we don't want/need to customize it from PluginContent.jsm. ui-review=sbarrett r=felipe
https://hg.mozilla.org/integration/mozilla-inbound/rev/4b6b2e9e5492
part B - Adjust the wording of the infobar to more closely match the in-content UI, and the doorhanger to more closely match other permissions and be more personal. ui-review=sbarrett r=felipe

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7a7047b62b51
test followup - the infobar no longer shows plugin-specific data, so this subtest is no longer relevant r=trivial

Comment 12

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/6c35cc91b1bb
https://hg.mozilla.org/mozilla-central/rev/4b6b2e9e5492
https://hg.mozilla.org/mozilla-central/rev/7a7047b62b51

Comment 13

[Ton [:Tonnes]]

Is there a reason to use "slow" as a verb in these new strings as opposed to "slow down" elsewhere?

Comment 14

[Francesco Lodolo [:flod]]

(In reply to Ton from comment #13)
> Is there a reason to use "slow" as a verb in these new strings as opposed to
> "slow down" elsewhere?

Length might be one, message needs to be short to ensure it doesn't wrap in notification bars. I'm not a native speaker, so I don't know if "slow" alone could sound strange compared to "slow down".

Comment 15

[Benjamin Smedberg]

sbarrett and bram were involved in crafting that string, so any question about it should be directed to them. I presume this doesn't affect string freeze though, since the meaning is the same.

Comment 16

[Sam Barrett]

My primary concern was length. Not sure "down" is needed.

Comment 17

[Bram Pitoyo [:bram]]

My primary concern was about making sure that the string contains the word “Allow”, so it directly refers to the button action. So I lean more towards the string in comment 1:

> "Would you like to allow [domain] to run a plugin that may slow Firefox?"

My secondary concern is to make sure that we keep measuring the response to this string. Is it more helpful than before? Does it impact user happiness?

I’m worried that we’ll vilify our users’ habits and make them feel like they’re doing something they’re not supposed to, by wanting to see videos or play games. If the result comes up good, then we should absolutely communicate – or even over-communicate – the performance risk.

Comment 18

[Sam Barrett]

We could fix that by saying: 

"This site uses a plugin that may slow Firefox. Allow anyway?"  

I'm not sure I agree if that would necessarily vilify the user. The emphasis is put on the site, not the user, and we're asking the user to make a decision.

Comment 19

[Francesco Lodolo [:flod]]

(In reply to Sam Barrett from comment #18)
> We could fix that by saying: 
> 
> "This site uses a plugin that may slow Firefox. Allow anyway?"  
> 
> I'm not sure I agree if that would necessarily vilify the user. The emphasis
> is put on the site, not the user, and we're asking the user to make a
> decision.

At this point I wouldn't be thrilled to change the string significantly, unless you're OK with the change only riding the trains with 56 (and having a different string in 55).

Comment 20

[Bram Pitoyo [:bram]]

(In reply to Sam Barrett from comment #18)
> "This site uses a plugin that may slow Firefox. Allow anyway?"  

This string change sounds good. It combines putting an emphasis on the site, and referring to the ‘Allow’ button label.

Comment 21

[Francesco Lodolo [:flod]]

(In reply to Bram Pitoyo [:bram] from comment #20)
> (In reply to Sam Barrett from comment #18)
> > "This site uses a plugin that may slow Firefox. Allow anyway?"  
> 
> This string change sounds good. It combines putting an emphasis on the site,
> and referring to the ‘Allow’ button label.

String is already "This site uses a plugin that may slow %S.". Are you suggesting to add "Allow anyway?"? What happened to the length concerns? 

Note that:
* The warning appearing on blocked content clearly can't have that.
* AFAIK the buttons in the notification bar say Continue Blocking | Allow…

I'm all for discussing these choices, but that should really happen before we land content and expose it to localization. I know there was some urgency around this specific change, but I want to make sure everyone is on the same page, at risk of stating the obvious.

Comment 22

[Benjamin Smedberg]

Too many cooks in the fire now. Executive decision, we're going to stick with the strings as currently landed.