1225170 - /contribute/signup test: Implement Page with decided tasks, wireframes and design

Status: RESOLVED FIXED

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

Description

[Jennifer Bertsch [:jbertsch]]

Note: test will be en-us only but hopefully bring us closer to a new version of this page that will work better for all locales.

https://www-demo4.allizom.org/en-US/contribute/signup/

Comment 1

[Schalk Neethling [:espressive]]

Issue on Github: https://github.com/mozilla/bedrock/issues/3568

Comment 2

[Jonathan Petto [:jpetto]]

Proposal doc: https://docs.google.com/document/d/1f0IHliLNp9wE8Itqu9TjF98y_7ugIsGrgMW-E0XshbI/edit

Comment 3

[Schalk Neethling [:espressive]]

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

Comment 4

[Schalk Neethling [:espressive]]

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

Initial PR for code review

Comment 5

[Jonathan Petto [:jpetto]]

First pass at Optimizely experiment: https://app.optimizely.com/projects/246059135/experiments/4768980473

Intent is to send 50% of en-US traffic to variation 1, 50% to variation 2.

Didn't apply an audience filter, as en-US is hard-coded in the URL targeting. Is this best practice, or should en-US also be specified in the audience filter?

Production URL target regex will be: ^.*www\.mozilla\.org\/en\-US\/contribute\/signup\/$

:cmore r?

Comment 6

[Jonathan Petto [:jpetto]]

:magopian - We're seeing a somewhat concerning error message when attempting to install Whimsy from demo4 [1] using the static page [2] pushed in PR 947 [3].

The error reads:

addons.cdn.mozilla.net
Firefox prevented this site from asking you to install software on your computer.

I'm worried the recent change putting these kinds of pages on a new domain (addons.cdn.mozilla.net) is throwing a security warning to the browser, which I believe only accepts install requests from addons.mozilla.org.

Can you offer any insight/advice here? If the domain is indeed the problem, can we get this type of static page on addons.mozilla.org without too much wrangling?

[1] https://www-demo4.allizom.org/en-US/contribute/task/whimsy/?v=1
[2] https://addons.cdn.mozilla.net/static/html/mozorg/whimsy.html
[3] https://github.com/mozilla/olympia/pull/947

Comment 7

[Mathieu Agopian [:magopian]]

It seems that if I click on the button from https://addons.cdn.mozilla.net/static/html/mozorg/whimsy.html I do have the warning, but I have the possibility to accept the installation anyway. It's not the case when on the contribute page.

So I'm not sure the issue is because of the CDN, maybe it's because of the iframe? Or because it's not on a *.mozilla.org domain?

I'm afraid I can't help more on this issue, it's out of my knowledge. Maybe ask someone like :mossop or :dveditz?

Comment 8

[Schalk Neethling [:espressive]]

If this is turning into a major headache, perhaps we can just point the user to the download page on AMO? Jen?

Comment 9

[Jonathan Petto [:jpetto]]

We pushed a non-publicized page up to production [1] to test the Whimsy install button [2] and the results are the same as comment 6 ("Firefox prevented this site..."). Conclusion seems to be that to install an add-on, the hosting page must reside on addons.mozilla.org.

:mossop - Thoughts on comment 6? Would it be feasible to place the static page directly on addons.mozilla.org? Or is the strategy of embedding an add-on via an iframe no longer sound?

[1] https://www.mozilla.org/contribute/supersecret-testpage/
[2] https://addons.cdn.mozilla.net/static/html/mozorg/whimsy.html

Comment 10

[Jennifer Bertsch [:jbertsch]]

(In reply to Schalk Neethling [:espressive] from comment #8)
> If this is turning into a major headache, perhaps we can just point the user
> to the download page on AMO? Jen?

Hi Schalk-

Jon and I just discussed.  If this issue is still open this afternoon, let's go ahead and just point to the download page on AMO.

Thanks!

Comment 11

[Schalk Neethling [:espressive]]

(In reply to Jennifer Bertsch [:jbertsch] from comment #10)
> (In reply to Schalk Neethling [:espressive] from comment #8)
> > If this is turning into a major headache, perhaps we can just point the user
> > to the download page on AMO? Jen?
> 
> Hi Schalk-
> 
> Jon and I just discussed.  If this issue is still open this afternoon, let's
> go ahead and just point to the download page on AMO.
> 
> Thanks!

I have changed the Whimsy task to point to the install page on AMO.

Comment 12

[Chris More [:cmore]]

(In reply to Jon Petto [:jpetto] from comment #5)
> First pass at Optimizely experiment:
> https://app.optimizely.com/projects/246059135/experiments/4768980473
> 
> Intent is to send 50% of en-US traffic to variation 1, 50% to variation 2.
> 
> Didn't apply an audience filter, as en-US is hard-coded in the URL
> targeting. Is this best practice, or should en-US also be specified in the
> audience filter?
> 
> Production URL target regex will be:
> ^.*www\.mozilla\.org\/en\-US\/contribute\/signup\/$
> 
> :cmore r?

Feedback for jpetto:

1) Rename variations to be more explicit to what they are instead of just "variation 1"

2) Switch the experiment back to an a/b test instead of a multi-page test. The multi-page test gives you the ability to do a/b tests on multiple pages at the same time. For example, on a multi step funnel. For this test, it's not needed since you are just using optimizely as a traffic cop.

3) Make sure you switch the URL target and the redirect code in the two variations to the production URL before enabling the experiment.

4) Are you measuring the goal of the experiment outside of Optimizely? It looks like it since you only have engagement as the goal. 

5) Your audience is "everyone" and I assume that is fine. You could add an audience to just "English - any" users to ensure there is not a language mismatch when people land on the page. For example, if someone makes it to the en-US version of the page, but speaks German. If you double down the audience target and the URL target you can ensure that browser language = page language.

Everything else looks good since it is a simple experiment from an Optimizely perspective.

Let me know on the items above.

Comment 13

[Jonathan Petto [:jpetto]]

(In reply to Chris More [:cmore] from comment #12)
> Feedback for jpetto:
> 
> 1) Rename variations to be more explicit to what they are instead of just
> "variation 1"

Done.

> 
> 2) Switch the experiment back to an a/b test instead of a multi-page test.
> The multi-page test gives you the ability to do a/b tests on multiple pages
> at the same time. For example, on a multi step funnel. For this test, it's
> not needed since you are just using optimizely as a traffic cop.

Done.

> 
> 3) Make sure you switch the URL target and the redirect code in the two
> variations to the production URL before enabling the experiment.

Noted here and in experiment description. Will update prior to production launch.

> 
> 4) Are you measuring the goal of the experiment outside of Optimizely? It
> looks like it since you only have engagement as the goal. 

Confirmed with :espressive that we are measuring in GA.

> 
> 5) Your audience is "everyone" and I assume that is fine. You could add an
> audience to just "English - any" users to ensure there is not a language
> mismatch when people land on the page. For example, if someone makes it to
> the en-US version of the page, but speaks German. If you double down the
> audience target and the URL target you can ensure that browser language =
> page language.

Added pre-defined "English only" audience.

> 
> Everything else looks good since it is a simple experiment from an
> Optimizely perspective.
> 
> Let me know on the items above.

Thanks :cmore!

Comment 14

[[github robot]]

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

https://github.com/mozilla/bedrock/commit/d8f95ee37e70b2b3a4f27e88591698d92607b6e4
Fix Bug 1225170, implement new signup and task pages for contribute

https://github.com/mozilla/bedrock/commit/a5b354f64ff99294276f83d30921851a0ed254ff
Merge pull request #3815 from schalkneethling/bug1225170-final-implementation-of-participation-hub

Fix Bug 1225170, implement new signup and task pages for contribute