Closed Bug 814203 Opened 12 years ago Closed 11 years ago

implement & test redesigned /new page

Categories

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

Product:
www.mozilla.org
Component:
Pages & Content
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jslater, Assigned: jpetto)

References

(
URL
)

Details

(Whiteboard: [u=user c=bedrock p=1])

Attachments

(4 files)

Android /new download page 320px
137.09 KB, image/png
Details
Wireframes for IxD studies and page states
357.03 KB, application/pdf
Details
firefox new - 01a
639.94 KB, image/png
Details
firefox new - 02a
777.91 KB, image/png
Details 
Filing this as an implementation bug for the designs in bug 814202. Jennifer, please share any details about timing or testing methods that you think would be relevant.

Design work will start next week, so more to come on that.

Thanks!
Hi Team-

Our proposed timeline for this project is as follows:
1.  November 26-December 4:  finalize design (Lee, Holly, Laura, Jen)
2.  December 5-11:  code the page (Jon P)
3.  December 12-14:  QA
4.  December 17-21:  test redesigned /new page against existing /new page on the live/production servers to ensure that the rate of browser downloads per visitor remains the same or increases (Holly, Jen, Jon, Craig, Chris)
5.  January 

Please let me know if you want to suggest any changes to this timeline and if I can help with any blockers etc.

Thx,
Jen
Assignee: chrismore.bugzilla → jon
Whiteboard: [u=user c=bedrock p=1]
Priority: -- → P1
Jon: When we first launch this page, it will be en-US only and if all goes well, it will be need to be localized. We need to make sure we use L10N blocks so that strings can be extracted.

More info on how: http://readthedocs.org/docs/bedrock/en/latest/l10n.html

Example: https://github.com/mozilla/bedrock/blob/master/apps/mozorg/templates/mozorg/contribute.html
Timeline looks fine on my end, with one note. I'll be teaching class on 12/11, meaning no availability. Unless something unforeseen comes up, December 5, 6, 7, and 10 should be enough time to get us to QA. I'll be available during QA to make any necessary changes.

Making sure the new page is ready for localization shouldn't be an issue.

In terms of development, I'll create a new branch in my fork of bedrock and issue pull requests when appropriate. Sound good?
(In reply to Jon Petto from comment #3)
> Timeline looks fine on my end, with one note. I'll be teaching class on
> 12/11, meaning no availability. Unless something unforeseen comes up,
> December 5, 6, 7, and 10 should be enough time to get us to QA. I'll be
> available during QA to make any necessary changes.
> 
> Making sure the new page is ready for localization shouldn't be an issue.
> 
> In terms of development, I'll create a new branch in my fork of bedrock and
> issue pull requests when appropriate. Sound good?

Yes, a pull request from your personal account is how we do it. Drop into #webprod and say hi. :)
Lee -- as discussed here are more updates from me. 

Product Nitty-Gritty:
- Show a Twitter app tab
- Show is Windows chrome since that's the majority of our users
- A visitor to this page should be able to understand that Firefox is a browser
- Please include the magic word of marketing "Free" someone on this page. It's currently in our download button. 

Other Copy:
- Refreshing the headline is a option if it's within scope of this project but I'm hesitant since that may induce scope creep. Although "different by design" was created for the brand campaign, it still speaks to our main differentiating factor. I'd want any new headline to do the same.
Thanks, Laura.

Can you explain what you mean by "Show a Twitter app tab"?

We can add the option of sharing once thank-you/confirmation is shown. I think that would be a great thing to test. 


An additional test we have discussed for this page in the future is a more minimal download button that Sean & Ty have been exploring. Of course, this type of test would come only after this page has been up for a while as we don't want too many tests on one page to cause conflicting results.
(In reply to Holly Habstritt [:Habber] from comment #6)
> Thanks, Laura.
> 
> Can you explain what you mean by "Show a Twitter app tab"?
 
App tabs are really useful way to keep your favorite web apps open all day so that they're always available. Here's more info: http://support.mozilla.org/en-US/kb/app-tabs-keep-favorite-websites-open

To do this, go to Twitter.com, double click on the tab, and then select "pin as app tab." 
 
> We can add the option of sharing once thank-you/confirmation is shown. I
> think that would be a great thing to test. 

A test would be interesting! I would love to learn if a more natural place to ask users to share would be on the First Run page once they've actually installed the product, vs. on the download page. I also wonder if it's a better time and place to ask these people to sign up for our newsletter or follow us on Twitter/Facebook vs. share a product that they have not yet used. (I wouldn't want to ask too much from these people before they are ready) 

Of course those are just hypotheses. Let's test! 
 
> An additional test we have discussed for this page in the future is a more
> minimal download button that Sean & Ty have been exploring. Of course, this
> type of test would come only after this page has been up for a while as we
> don't want too many tests on one page to cause conflicting results.
Thanks! I realize now you were describing what should be in the product screenshot. I'm a big fan of showing app tabs. I think it's a feature that a lot of users still don't know exists. 

I assume first-run is a better spot for sharing. It's a little risky to share from this page since we want the user to not be distracted from the main task at hand - installing the browser. However, for those with slower download speeds, it is a task that they could do in the meantime. Just a thought.
Just to add to "Show is Windows chrome since that's the majority of our users" - we'd need to recreate the screenshot for all the OSes here, not just one.

Just a heads up.
I don't use Windows on my Mac - Laura, could you possibly supply a screenshot with all of the preferred app tabs (Twitter, Mozilla?) and send it to me to use in my mock ups? 

In the end it would be preferable to get really clean, pixel-perfect images for the page, but for now it would be helpful to get the Windows chrome + apptabs on the page, so we can cross that off our list of requirements
Note: we shouldn't block on the screenshots, though. We can get to a finalized design with one OS screenshot and then drop in the others a bit later in the process if need be. I agree with everything in comments #9 and 10 but really want to make sure we don't delay the design process while the details are sorted out...we have enough in place now to be able to keep finalizing the look & content.

Laura, are you the right go-to person for that screenshot? If not, who is?
Attempting to fix these flows in this redesign as well:

Current flow for /new on Android:
http://cl.ly/image/0a333a350B0F

Sends user to Play Store. Does anyone have objections to defaulting to Android button in this scenario?



Current flow for /new on iOS:
http://cl.ly/image/0g2l3n1F2a2i

Allows user to download .dmg. Did this flow change? The last time I checked this I recall it going to the tabbed view with the mobile tab selected. Even if you were on iOS, the tab defaulted to show you Android content. Regardless, we should not allow the user to be put into this flow. 

Can anyone else with Dropbox installed on their iPhone recreate what I have in the screenshots? If you don't have Dropbox, what are you seeing?
Hi Holly-

I don't have dropbox on my iphone - I saw the first two screens you showed in your flow and then got a "download failed" system message from my phone.


I guess I'd vote to take iphone users to /mobile, right?

I have no objections to defaulting to an Android button in the Android flow you showed.

Thanks for checking on this,
Jen
(In reply to Holly Habstritt [:Habber] from comment #12)
> Attempting to fix these flows in this redesign as well:
> 
> Current flow for /new on Android:
> http://cl.ly/image/0a333a350B0F
> 
> Sends user to Play Store. Does anyone have objections to defaulting to
> Android button in this scenario?

By "Android button" do you mean Google's default Play button (the black one) or our new version that says "Get it free from Google Play"?

I think we should definitely go with the latter, but not use Google's buttons on our pages.


> Current flow for /new on iOS:
> http://cl.ly/image/0g2l3n1F2a2i
> 
> Allows user to download .dmg. Did this flow change? The last time I checked
> this I recall it going to the tabbed view with the mobile tab selected. Even
> if you were on iOS, the tab defaulted to show you Android content.
> Regardless, we should not allow the user to be put into this flow. 
> 
> Can anyone else with Dropbox installed on their iPhone recreate what I have
> in the screenshots? If you don't have Dropbox, what are you seeing?

I get the second "welcome" screen, then a white screen and nothing happens.
Here's a mockup of the /new page in 320px width for smartphones. I'm using the Android (Google Play) button, which is currently being worked on in another bug. 

Holly, with regard the iOS flow that you attached, I'm seeing the same pages but on the 3rd state, I see an option to download to Evernote instead of Dropbox (I don't have Dropbox installed). It looks exactly the same only with the Evernote icon vs. the Dropbox icon.
Thanks, Lee. 

It's pretty clear that we shouldn't let our iPhones try to handle the flow, but should fix this issue asap. It's interesting to see how iOS tries to handle our mistake. Sending the user to /mobile will work, but information about Android is the first messaging the iPhone user will see, which isn't ideal. 

This project is supposed to be about focusing on the /new redesign and not focusing too much time on fixing the existing flow. We can fix small issues, but because of the tight timeline to get this to testing we may need to direct iPhone users to /mobile for the meantime to solve what is happening now. 



Matej: Definitely agree on not using Google's Play buttons. Lee's mockup has the new download button you mentioned. I know there is a larger conversation about download buttons going on at the moment. After our first round of A/B testing this page, we can also use it to test any new button styles.
Responsive versions (sans final visual assets and footer) are up on demo:
Desktop - https://www-demo2.allizom.org/b/en-US/firefox/new-test/
Android - https://www-demo2.allizom.org/b/en-US/firefox/new-test/?forceandroid=1


Assets still needed:
- Footer design

- transparent png's for both "Firefox for desktop" header and features divider (the gradient between "Proudly non-profit, Innovating..." etc)


- product screen shots for each OS (with a transparent bg) 
* responsive version of screenshot (cropped)

- images & copy for installation instructions for each OS
* prepare images for responsive view as well. Images can stack in smaller viewports.



Comments:
- Android user should not see Fx "For Desktop" copy accompanying logo at top of page.

- We need to be cognizant of page load time, so anything we can do to speed this up for users with slower connections would be great.
Lee/Jon: Can both of you give a status/timeline on your work related to the new /firefox/new page?
Attached image firefox new - 01a — 
I'm working on some design refinements now, and will be providing Jon the assets he needs to implement onto the demo page. 

* Footer
- see attached mockup. navigation links on the current live page will be reused in the footer

* Product screenshots for ea OS (800px wide)
- we will need ea OS screenshot for this product image - FPO in my mockup
John and Jennifer, what do you think of the latest grid treatment in the browser window? 

Laura Forrest, can you confirm the features and webpages you'd like to be shown:
- app tabs (Twitter, mozilla, about:home?) 
- Social API? 

- I believe we are leaving the product/browser out of the responsive version (as in comment 15)

* Installation images
- We will also need images and final copy for the installation images (if they're different from what we currently have)

**I'm only running Mac OS on my machine. We need to find a source for the other OS screenshots**
Attached image firefox new - 02a — 

    
    

    
  
Still tracking down assets for installation instructions for all OSes. Sgarrity, Sean Martell, and John Slater have been contacted. Hope to track these down asap.

    
    

    
  
Jon Petto, 
Here's a link to the latest PSD for implementing assets: http://cl.ly/3c0K2F0S0T2g
Let me know if you have any questions. Thanks!

    
    

    
  
The contrast ratio between the background and foreground is not strong enough, I used the color contrast analyzer http://www.paciellogroup.com/node/18?q=node/20 to get this results.

The Green color:
Foreground: #6FA41A - Background: #DDE4EC

The contrast ratio is: 2.3:1

Text failed at level AA
Text failed at level AAA
Large text failed at level AA
Large text failed at level AAA

The grey color:
Foreground: #888A8B - Background: #DDE4EC

The contrast ratio is: 2.7:1

Text failed at level AA
Text failed at level AAA
Large text failed at level AA
Large text failed at level AAA

The blue link color:
Foreground: #51A3F5 - Background: #DDE4EC

The contrast ratio is: 2.1:1

Text failed at level AA
Text failed at level AAA
Large text failed at level AA
Large text failed at level AAA

1.4.3 Contrast (Minimum):  Text (and images of text) have a contrast ratio of at least 4.5:1, except if the text is pure decoration.  Larger scale text (at least 18 point or 14 point bold) or images of text can have a contrast ratio of 3:1. (Level AA)

1.4.6 Contrast (Enhanced): Text (and images of text) have a contrast ratio of at least 7:1, except if the text is pure decoration.  Larger scale text (at least 18 point or 14 point bold) or images of text can have a contrast ratio of 4.5:1. (Level AAA)

Note: Fonts that are extraordinarily thin or decorative are harder to read at lower contrast levels.

    
    

    
  
(In reply to Lee Tom from comment #20)
> Created attachment 690976 [details]
> firefox new - 01a
> 
> I'm working on some design refinements now, and will be providing Jon the
> assets he needs to implement onto the demo page. 
> 
> * Footer
> - see attached mockup. navigation links on the current live page will be
> reused in the footer
> 
> * Product screenshots for ea OS (800px wide)
> - we will need ea OS screenshot for this product image - FPO in my mockup
> John and Jennifer, what do you think of the latest grid treatment in the
> browser window? 

I'm not sure what the grid is illustrating - it gives the graphic a blank feel. Can we show some sort of generic design that looks like it could be a generic website? I think earlier mockups had this before.   

> Laura Forrest, can you confirm the features and webpages you'd like to be
> shown:
> - app tabs (Twitter, mozilla, about:home?)

Yep!
 
> - Social API? 

Let's not show the Social API on this version - it may confuse folks, since it actually does not come in the product by default. Thanks for thinking of it though!

    
    

    
  
(In reply to Laura Forrest from comment #25)
> I'm not sure what the grid is illustrating - it gives the graphic a blank
> feel. Can we show some sort of generic design that looks like it could be a
> generic website? I think earlier mockups had this before.   

We actually tried several different generic-ish designs for that section and nothing was really working. Our thought that going with a blank feel would actually focus people's attention on the browser image itself (and the download button of course). I don't love love love it, but it's definitely the best of the bunch so far. Am open to other suggestions.

@icaaq - can you elaborate further? Is this an a11y issue? The Open Sans font is standard for us across all our sites, so we can't change it here.

    
    

    
  
(In reply to John Slater from comment #26)
> @icaaq - can you elaborate further? Is this an a11y issue? The Open Sans
> font is standard for us across all our sites, so we can't change it here.

Yes, it's a a11y issue, but the open sans font is not really the issue. it's the background and foreground color that has been used. People with low vision or people that suffers from some kind of color blindness will have problem reading this texts.

Solutions? strengthen the contrast a bit on the grey text and blue links below the images, a white panel underneath the green text and strengthen that contrast as well a bit. There are a lot of ways ;)

If you want to have some more information regarding this, then WCAG 2.0 is the place to go to http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html#visual-audio-contrast-contrast-techniques-head

Also this 24ways color accessibility article is really great and it has lots of good tools in it (and in the comments) http://24ways.org/2012/colour-accessibility/

    
  
Depends on: 820974

    
    

    
  
Jon:

Does your new version of the /firefox/new/ page include:

{% extends "/firefox/base.html" %}

I want to make sure you using the base or base responsive template so that it pulls in the Google Analytics into the <head> of the page.

    
  
Depends on: 821016

    
    

    
  
I've created two new dependent bugs for the sampling redirect and the conversion tracking on the new page.

    
    

    
  
(In reply to Chris More [:cmore] from comment #28)

> Jon:
> 
> Does your new version of the /firefox/new/ page include:
> 
> {% extends "/firefox/base.html" %}

Yep, I'm extending /firefox/base-resp.html. I don't see GA scripts on the dev server (https://www-demo2.allizom.org/b/en-US/firefox/new-test/), though I'm guessing that's by design.

    
    

    
  
(In reply to Jon Petto from comment #30)
> (In reply to Chris More [:cmore] from comment #28)
> 
> > Jon:
> > 
> > Does your new version of the /firefox/new/ page include:
> > 
> > {% extends "/firefox/base.html" %}
> 
> Yep, I'm extending /firefox/base-resp.html. I don't see GA scripts on the
> dev server (https://www-demo2.allizom.org/b/en-US/firefox/new-test/), though
> I'm guessing that's by design.

yup, that's because demo hasn't been updated for a bit. We just released GA last week on mozilla.org.

    
    

    
  
Jon: Please make the URL of the new page on demo2 to be /firefox/new-b/ and get the /b/ redirect out of there for our test. I want to test this on demo2 without the /b/ redirect.

    
    

    
  
One thing I noticed is that parts of the source-order on https://www-demo2.allizom.org/b/en-US/firefox/new-test/ is "reversed", scene2 is before scene1 and that is going to be really confusing for screen-reader users.

    
    

    
  
(In reply to Isac Lagerblad (:icaaq) from comment #33)
> One thing I noticed is that parts of the source-order on
> https://www-demo2.allizom.org/b/en-US/firefox/new-test/ is "reversed",
> scene2 is before scene1 and that is going to be really confusing for
> screen-reader users.

Hmm, good point. The scenes are in reverse order to achieve the downward scrolling slot-machine animation after clicking the download button.

I could put the scenes in sequential order, the flip them with JS at page load. Would that be an acceptable fix?

Might increase load time slightly - scenes would need to be hidden until JS flips the order to prevent seeing a flicker of scene 2 at page load.

    
    

    
  
(In reply to Jon Petto from comment #34)
> (In reply to Isac Lagerblad (:icaaq) from comment #33)
> > One thing I noticed is that parts of the source-order on
> > https://www-demo2.allizom.org/b/en-US/firefox/new-test/ is "reversed",
> > scene2 is before scene1 and that is going to be really confusing for
> > screen-reader users.
> 
> Hmm, good point. The scenes are in reverse order to achieve the downward
> scrolling slot-machine animation after clicking the download button.

Yes, I understand.

> 
> I could put the scenes in sequential order, the flip them with JS at page
> load. Would that be an acceptable fix?

No, screenreaders uses js, so that wouldn't be enough
> 
> Might increase load time slightly - scenes would need to be hidden until JS
> flips the order to prevent seeing a flicker of scene 2 at page load.

You could do like this, some sudo code:
change the sourceorder so it's scene1 then scene2

.stage{
-moz-transition: top .4s ease .1s;
height:800px;
position:absolute;
bottom:0;
}
#scene1{
top:0
}
#scene2{
top:400
}
.stage.scene2{
bottom:-400px;
}

    
    

    
  
sorry, it should have been:

-moz-transition: bottom .4s ease .1s;

Instead of doing all that -moz-transform: translatey(x%) you just animate bottom :)

    
    

    
  
Re: "https://www-demo2.allizom.org/b/en-US/firefox/new-test/"

Would be good to not use words like "test" in the URL bar. It's visible to users who If they see it, may behave differently. 

Perhaps use this instead:

https://www-demo2.allizom.org/b/en-US/firefox/new-1/

    
    

    
  
(In reply to Laura Forrest from comment #37)
> Re: "https://www-demo2.allizom.org/b/en-US/firefox/new-test/"
> 
> Would be good to not use words like "test" in the URL bar. It's visible to
> users who If they see it, may behave differently. 
> 
> Perhaps use this instead:
> 
> https://www-demo2.allizom.org/b/en-US/firefox/new-1/

Laura: as described in previous comments and our IRC conversation, we are going to use /firefox/new-b/. We have most of the coding done and it is coming along well. :)

We are using Google Content Experiments and it is really sweet as it tied into the conversion goal funnels I set up.

    
    

    
  
Scenes are now in sequential order in the markup.

    
  
Depends on: 822374

    
  
Depends on: 823302

    
  
Blocks: 823308

    
    

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

https://github.com/mozilla/bedrock/commit/bf0d34e13779bab8d18193773b79bc165312f7bb
Rough A/B interaction tests for new firefox page. Two new URLs: /firefox/new-a & /firefox/new-b. Download button disabled temporarily to ease testing. Bug 814203

https://github.com/mozilla/bedrock/commit/9cfbe5e3cef2c1bd35491ab178043e60c2c44ec6
added C test - roulette style swap. added auto scroll to B test. bug 814203

https://github.com/mozilla/bedrock/commit/e3500be1938facbc3972e1fa62a54ae689ffdd55
Added D test (similar to C - product image scrolls instead of heading). bug 814203

https://github.com/mozilla/bedrock/commit/3c65f1fcc6b2ab9dd1e84892500d3e6d411d313f
Added E test - scrolling bullets/button/product shot down. little bit of cleanup. bug 814203

https://github.com/mozilla/bedrock/commit/ae261cb615a3b483eb218b87f5e37ee7028fa9cc
Updated E test - made default at /firefox/new-test. Made responsive. Added android platform detection/view. Enabled download of installer. bug 814203

https://github.com/mozilla/bedrock/commit/0198554fe258d5f4beecd9b48132a386cdd243a9
Updated images, added win/osx install text. bug 814203

https://github.com/mozilla/bedrock/commit/77ca184877281ad7e6a41fd6fab6a9e9759bf0cd
updated install images, added GA tracking (needs testing), browser checking for < IE9. bug 814203

https://github.com/mozilla/bedrock/commit/beaf3357bd2d038988aa008b03a72a36ac20ceb2
added alt tags to install images. re-enabled ff installer download. bug 814203

https://github.com/mozilla/bedrock/commit/c925721098c95ff3f7f8a80a2d4fdeebcda0f5b4
updated GA tracking to use location.pathname instead of location.href. bug 814203

https://github.com/mozilla/bedrock/commit/4b4c59dd5e039b96036c9c7728cb515f32fe6d18
changed final test url to /new-b. removed old tests (a,b,c,d). left-aligned install instructions. bug 814203

https://github.com/mozilla/bedrock/commit/0ffe52314ff08b278462a26ee6721c184c4a4f22
Rough A/B interaction tests for new firefox page. Two new URLs: /firefox/new-a & /firefox/new-b. Download button disabled temporarily to ease testing. Bug 814203

https://github.com/mozilla/bedrock/commit/b9422f83b1b0bd1681670ac04f7607af1df5cd87
added C test - roulette style swap. added auto scroll to B test. bug 814203

https://github.com/mozilla/bedrock/commit/dfecbacd313a3b7d41a839ccfc7cc81ec182151e
Added D test (similar to C - product image scrolls instead of heading). bug 814203

https://github.com/mozilla/bedrock/commit/062b8f12e25557efc3a7c07b7fd7403ef5d71a47
Added E test - scrolling bullets/button/product shot down. little bit of cleanup. bug 814203

https://github.com/mozilla/bedrock/commit/9870c321dfa29811e499d2c051954427df628e14
Updated E test - made default at /firefox/new-test. Made responsive. Added android platform detection/view. Enabled download of installer. bug 814203

https://github.com/mozilla/bedrock/commit/e31628ce04ace1f4df414642d55c040559d4b527
Updated images, added win/osx install text. bug 814203

https://github.com/mozilla/bedrock/commit/8b60b1454e422d8c278e635b6c4f8bd1b5d0cee9
updated install images, added GA tracking (needs testing), browser checking for < IE9. bug 814203

https://github.com/mozilla/bedrock/commit/e2cda937c75882a78a16f0b76deb2dc56f7ef644
added alt tags to install images. re-enabled ff installer download. bug 814203

https://github.com/mozilla/bedrock/commit/18f44a08a51f21a4b31355f07405a90001871e18
updated GA tracking to use location.pathname instead of location.href. bug 814203

https://github.com/mozilla/bedrock/commit/6e5fdb2f315927ea8ad9f60e5f50c38bc72fcf1f
changed final test url to /new-b. removed old tests (a,b,c,d). left-aligned install instructions. bug 814203

    
    

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

https://github.com/mozilla/bedrock/commit/a3f5da8c26e3ec2b50ed5e6bccf99c060d0ad7ec
Bug 814203: Add /firefox/new-b page and A/B test for it.

- Adds the /firefox/new-b page.
- Adds the ga_experiments block to the base template for A/B tests.
- Adds an A/B test to /firefox/new that selects between the old
  /firefox/new page and /firefox/new-b.
- Bug 822443: Removes the _setDomainName call from the GA code.

    
    

    
  
Page is live with a 25% sample. Results coming soon.

See new version here: http://www.mozilla.org/en-US/firefox/new-b/

    
    

    
  
We started a new test and we are collecting the data now. We are going to let it run this weekend as Google recommends not turning the test off early as it won't be accurate.

    
  
Depends on: 824370

    
  
Depends on: 824356

    
  
No longer depends on: 824356

    
  
Depends on: 824356

    
    

    
  
Experiment has been disabled in the AM of 2012-12-23. The conversion rate was lower than the current page, but we suspect that it is a Google Analytics tracking issue and not a page problem. We have a few open bugs to put in some additional tracking so we can compare the old and new page in a more precise method.

    
    

    
  
I am running a new experiment for the /firefox/new/ vs /firefox/new-b/ page on production. I am running at 100% sample, which means 50% will go to the control and 50% to the experiment page. The difference between this test and the previous four is that we are doing virtual page view conversions for both /new/ and /new-b/, which should get us more of an apples-to-apples comparison. The previous tests was trying to compare a real page view to a virtual page view and data seemed noisy. This new test will confirm if the noise is part of Google Analytics or the new-b page performing worse. Stay tuned for results!

    
    

    
  
Update: the new-b outperformed the old page by a substantial margin on top visited browsers. We are going to get the new-b page live as the primary download page for Firefox desktop as soon as possible.

    
    

    
  
(In reply to Chris More [:cmore] from comment #49)
> Update: the new-b outperformed the old page by a substantial margin on top
> visited browsers. We are going to get the new-b page live as the primary
> download page for Firefox desktop as soon as possible.

Happy to hear!

+1. Although I do think we wanted to change the graphic slightly (example: remove grid layout) before showing to 100%. Perhaps synch with John on that.

    
    

    
  
At this point, I would say let's go ahead and push it and then we can continue to experiment with the grid (or something else) as needed. I wouldn't call it a blocker toward implementing a successful test.

    
    

    
  
Are you kidding? 

ALL HAIL THE MIGHTY GRID!

    
    

    
  
Lee and his grids...

    
    

    
  
All: I am going to present the new-b page during the Jan 21st Monday all hands. The upcoming all hands is when Gary is going to be talking and thus everything else will be compressed and rushed. I want to make sure I have enough time to present and we are also iterating on new-b a bit more with some additional changes (scene changes and l10n) that I wan to test.
Depends on: 837778

    
    

    
  
Ship it! Let's discuss what need to do to get this page live to place /firefox/new/.
Depends on: 767985

    
  
Depends on: 838249

    
    

    
  
All: The new download page live! https://www.mozilla.org/en-US/firefox/new/

Thanks to everyone involved!

Next steps: get new download buttons live and have L10N localize the page for other locales.

    
    

    
  
Woo hoo!!!! Nice work everyone...great stuff.

    
    

    
  
fixed https://www.mozilla.org/en-US/firefox/new/
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED

    
  
No longer depends on: 767985

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: