1446023 - [Retention] iframeless Fx Account 'form' (single field entry of email)

Status: RESOLVED FIXED

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

Description

[Eric Renaud [:erenaud]]

We need to remove the Fx Account sign up/sign in from the confines of the iframe, opening up far more options for testing and subsequent improvements.

(Jon accomplished this in Snippets, for reference)

Comment 1

[Jonathan Petto [:jpetto]]

:erenaud - Can we get a bit more context/detail here?

Assuming this change is to be applied to all instances of the iframe site-wide. Do we have/need design assets?

Comment 2

[pgerman]

We'll want to consider implementing amplitude any time the form is shown to meet out measurement needs. This will need further investigation.

Comment 3

[Justin Crawford [:hoosteeno] [:jcrawford]]

(In reply to Jon Petto [:jpetto] from comment #1)
> :erenaud - Can we get a bit more context/detail here?
> 
> Assuming this change is to be applied to all instances of the iframe
> site-wide. Do we have/need design assets?

This is from the experiment card:
* Description: We should eliminate the iframe and post directly to FxAccounts servers. Eliminating the iframe will make the HTML cleaner and the document faster to load. Also, we have seen through user research that some virus programs block iframes and thus there is an error on first run that that scares users away from trying Firefox.
* Hypothesis: A faster-loading form with fewer embedded documents will work for more people and therefore boost the conversion rate on firstrun.

In addition to the obvious page weight benefits that may have some direct bearing on conversion rates on /firstrun, the iframe blocks several more impactful avenues for experimentation. In particular, as long as we have an iframe...
* We can't change the FxA signup form itself, which blocks several optimizations we might run wherever the form appears -- for example, we can't change the button color even though many prior experiments have shown that a different button color might perform better, and we can't change the copy in the form or button even though prior experiments have shown that different language in the form might perform better
* We can't put the form in very many new places because its layout is rigid, which blocks several additional optimizations -- for example, it would be impossible to put the form in the header or footer where we currently ask Firefox visitors to download Firefox, and it might be challenging to add the form to the /new page, even though we know from recent experiments that putting the CTA on new channels is the most impactful way to impact FxA signup rates

:mwarther, you have asked for experiments like those mentioned above on several occasions. Would you consider prioritizing this mozorg work in an upcoming sprint?

Comment 4

[Jonathan Petto [:jpetto]]

To prepare for this, we should get the URL requirements nailed down when a user submits their email address. Here's my first take on how the URL would look. Using the form in snippets[1] as a starting point:

https://accounts.firefox.com/?
  action=email&
  context=fx_desktop_v3&
  entrypoint=TODO&
  service=sync&
  utm_content=TODO&
  utm_source=TODO&
  utm_campaign=TODO&
  utm_term=TODO

:stomlinson - What do you think about the above? There are likely rules we'll want to follow to change some of those params based on which page hosts the form.


[1] https://github.com/mozmeao/snippets/blob/master/activity-stream/fxa.html#L254

Comment 5

[Shane Tomlinson [:stomlinson]]

@jpetto - You'll also want to pass an `email` query parameter with the email captured on your page. In addition, utm_medium is propagated.

> There are likely rules we'll want to follow to change some of those params based on which page hosts the form.

entrypoint and the utm_* params need to validate against:

entrypoint: [\w.:-]+
utm_*: /^[\w\/.%-]+/ and have a max length of 128 chars.

We only really have two general rules of thumb. `entrypoint` is used to tag a given "page type" and remains the same across all pages of the class, e.g., no matter URL of the firstrun page, entrypoint is always `firstrun`. The utm_* params vary more often to allow for fine grained metrics, following the semantics provided by Google.


[1] - https://support.google.com/analytics/answer/1033863#parameters

Comment 6

[Hector Zhao [:hectorz]]

Hello, I'm interested in this work because the FxA tweaks for Fx China repack introduced in bug 1264843 could be affected.

Which will happen first, this or bug 1448918?

Comment 7

[Justin Crawford [:hoosteeno] [:jcrawford]]

> Which will happen first, this or bug 1448918?

In bug 1448918 comment 7, the product manager for FxA (adavis) suggests we implement iframeless on firstrun _before_ experimenting with an in-product firstrun page.

In bug 1448918 comment 8, the reporter and product manager for onboarding (cmore) agrees.

I also believe this bug should happen first. (Adding it as a blocker to that bug.)

Comment 8

[Hector Zhao [:hectorz]]

(In reply to Justin Crawford [:hoosteeno] [:jcrawford] from comment #7)
> > Which will happen first, this or bug 1448918?
> 
> In bug 1448918 comment 7, the product manager for FxA (adavis) suggests we
> implement iframeless on firstrun _before_ experimenting with an in-product
> firstrun page.
> 
> In bug 1448918 comment 8, the reporter and product manager for onboarding
> (cmore) agrees.
> 
> I also believe this bug should happen first. (Adding it as a blocker to that
> bug.)

Sorry I didn't notice that while skimming through the bug, thanks for pointing it out.

Comment 9

[Jonathan Petto [:jpetto]]

The WIP form can be seen on my demo:

https://bedrock-demo-jpetto.oregon-b.moz.works/en-US/firefox/60.0/firstrun/

Note that you must test with a profile that is not logged in to FxA, and you must have UITour configured to run on the demo URL (see the docs [1]).

The WIP branch is in my bedrock fork [2].

[1] http://bedrock.readthedocs.io/en/latest/uitour.html#local-development
[2] https://github.com/jpetto/bedrock/tree/bug-1446023-iframeless-fxa-form

Comment 10

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub pull-request: https://github.com/mozilla/bedrock/pull/5713

Comment 11

[Chris More [:cmore]]

Nice progress on removing the iframe on /firstrun/! Since the release channel is moving to about:welcome (in-product experience) on Firefox 62 in September, we need to make sure the about:welcome code is also iframe-less. I've noticed this bug in bug 1448918, which is the bug where the engineering is going on to create about:welcome as initially as a mirror of /firstrun/.

Comment 12

[Chris More [:cmore]]

update: per this bug comment https://bugzilla.mozilla.org/show_bug.cgi?id=1448918#c62 the about:welcome experience is already iframe-less.

Comment 13

[Eric Renaud [:erenaud]]

Lauren - the iframeless fxa form is ready and needs final approval on the copy there, please, to set it out to localization.

This will establish the form or use in any page you choose, as-is and localized beyond just en-US.

It will also enable testing in the copy, layout, etc. which we do not currently have in the iframe.

Please review it on demo and let us know (in this bug) of any changes/your approval, please - https://www-demo5.allizom.org/en-US/fxa-iframeless-test/

Many thanks,

Eric

Comment 14

[Chris More [:cmore]]

(In reply to Eric Renaud [:erenaud] from comment #13)
> Lauren - the iframeless fxa form is ready and needs final approval on the
> copy there, please, to set it out to localization.
> 
> This will establish the form or use in any page you choose, as-is and
> localized beyond just en-US.
> 
> It will also enable testing in the copy, layout, etc. which we do not
> currently have in the iframe.
> 
> Please review it on demo and let us know (in this bug) of any changes/your
> approval, please - https://www-demo5.allizom.org/en-US/fxa-iframeless-test/
> 
> Many thanks,
> 
> Eric

Hey Eric.

A question on the fxa iframeless page. Does this have application beyond /firstrun/? 

Also, about:welcome, which is already iframeless, is already live for the world and localized on beta 62 as of last week. The /firstrun/ page on release will not load from www.mozilla.org in another 5 seeks on 2018-09-05 when Firefox 62 release goes out the door. Only versions older than Firefox 62 will load /firstrun/. I am not sure how long localization will take, but whatever work done on /firsrun/ between now and 2018-09-05, will be deprecated when about:welcome is live on the release channel.

Comment 15

[Chris More [:cmore]]

Edit: I meant 9 weeks and not 5 weeks. sorry about that.

Comment 16

[Lauren Niolet]

Copy approved.

Comment 17

[Eric Renaud [:erenaud]]

cmore - yep, we aware of /firstrun going in-product and have ceased all activity on that. 

This is intended for use 'wherever' and was built as a re-usable component.  It could go in the account benefits page, sync or send-tabs, at first glance.

Comment 18

[Chris More [:cmore]]

(In reply to Eric Renaud [:erenaud] from comment #17)
> cmore - yep, we aware of /firstrun going in-product and have ceased all
> activity on that. 
> 
> This is intended for use 'wherever' and was built as a re-usable component. 
> It could go in the account benefits page, sync or send-tabs, at first glance.

That's awesome and what I hoped to learn. A re-usage widget for any www page that needs a FxA CTA is great. Nice work!

Comment 19

[[github robot]]

Commit pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/5a947ec09c76ed4541e97a06e7fc37d4e3768c92
Bug 1446023 iframeless fxa form (#5713)

* [fix bug 1446023] Add iframeless FxA macro on /firstrun.

* Update distribution check to only switch to China re-pack URL if UITour call is successful.

* Add the following params to the token request:

- utm_source (if available)
- utm_campaign (if available)
- form_type (always 'email')
- entrypoint

* Make utm_source required.

* Update docs/comments to clarify Fx 48+ requirement.