Closed Bug 1256241 Opened 9 years ago Closed 9 years ago

Implement /new download page redesign tests

Categories

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

Production
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: agibson, Assigned: agibson)

References

Details

Attachments

(3 files)

Assignee: nobody → agibson
Status: NEW → ASSIGNED
Revised ground-level contour, as per the discussion today: https://www.dropbox.com/s/s8mikyhj95o0mss/firefox-space_download.psd?dl=0
Blocks: 1256386
Attached file browser-chrome_2x.psd
Browser chrome high-res asset
Attached file rocket_2x.psd
Rocket high-res asset
I should also add, probably best to use Chrome to view these URLs ^
Thanks Agibson. Could we change the variation lettering, from a-h to something like 1a, 1b to 4a, 4b where a and b is the scene 2 variation that the user sees. It would make the reporting easier. Here's a screenshot as to how i've set it up so far in Data Studio: cl.ly/2T1h2E0a1P1d
(In reply to Gareth Cull [:garethc] from comment #8) > Thanks Agibson. > > Could we change the variation lettering, from a-h to something like 1a, 1b > to 4a, 4b where a and b is the scene 2 variation that the user sees. It > would make the reporting easier. Here's a screenshot as to how i've set it > up so far in Data Studio: cl.ly/2T1h2E0a1P1d I am fine with letters or numbers as long as we are consistent. Probably numbers for the first scene and letters for the second scene would be easier to figure out since it is more unique. 1a 1b 1c 1d 2a 2b 2c 2d Should we just use no parameters for the controls or should we have a specific variation for the control? We will have to setup the first scene to randomly include the a & b variation URLs for the second scene.
Since we have 4 variations of scene1 and 2 variations of scene2, I think Gareth's suggestion makes sense: 1a, 2a, 3a, 4a 1b, 2b, 3b, 4b The template variations already link through to the appropriate version of scene2, we can do this all in bedrock.
Flags: needinfo?(garethcull.bugs)
Thanks Alex. This looks good.
Flags: needinfo?(garethcull.bugs)
Attached file GitHub pull request
Looks good! Nice job
Alex, Will these get pushed to a demo server so I can test our Analytics?
Flags: needinfo?(agibson)
(In reply to Gareth Cull [:garethc] from comment #15) > Alex, > > Will these get pushed to a demo server so I can test our Analytics? Gareth, it's on one of our new demo server environments, please see comment 11 ^
Flags: needinfo?(agibson)
:agibson: Is there a bug to perform the optimizely test and if not, who has the action to get the bug and test setup? I want to get it rolling asap. Want to validate the new design is on par with the existing design.
Flags: needinfo?(agibson)
:agibson: another question. How much did you compress the graphics on the page (where you didn't use css) knowing that page weight can impact conversion rates on low bandwidth?
(In reply to Chris More [:cmore] from comment #17) > :agibson: Is there a bug to perform the optimizely test and if not, who has > the action to get the bug and test setup? I want to get it rolling asap. > Want to validate the new design is on par with the existing design. Chris, it was my understanding that you had agreed to take on setting up the Optimizely test? (bug 1256762). Not sure where wires have got crossed here, but if this is not the case I'll consult with Jen. The images have been compressed as much as possible without degrading them. There is obviously going to be some differentiation in page weight, since the design is a lot more image heavy. No amount of image-smushing can get around this everywhere. We have used CSS where ever possible. Ideally, we should have really used a performance budget for this page during the design process (something I have been pushing for over the past few years).
Flags: needinfo?(agibson)
Chris, this has been given an r+ in code review - any reason not to merge/push this change?
Flags: needinfo?(chrismore.bugzilla)
(In reply to Alex Gibson [:agibson] from comment #20) > Chris, this has been given an r+ in code review - any reason not to > merge/push this change? I am fine with getting this merged and pushed and we'll get the Optimizely test setup and needinfo you guys to review the test when ready before anything is started. Verdi also want to do some user testing with these URLs, so he'll wait until its on production. Thanks!
Flags: needinfo?(chrismore.bugzilla)
Blocks: 1259625
Commits pushed to master at https://github.com/mozilla/bedrock https://github.com/mozilla/bedrock/commit/bc20f6b190b3652380d96855c6407afe590bc8cc [fix bug 1256241] Implement /new download page redesign tests https://github.com/mozilla/bedrock/commit/3a408810bc1b975a60a5704b8033a4a986888e4c Merge pull request #3992 from alexgibson/bug-1256241-download-pages-redesign-tests [fix bug 1256241] Implement /new download page redesign tests
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Results of tests in test details page: https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=60588271 Conclusion: Page performs as good as the control or original page in primary traffic mediums.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: