Closed Bug 634135 Opened 13 years ago Closed 13 years ago

[Fx4Launch] Prep Homepage for Firefox 4 Launch

Categories

(www.mozilla.org :: General, defect, P1)

Product:
www.mozilla.org
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: lforrest, Assigned: sgarrity)

References

(
URL
)

Details

Need a few tweaks to the homepage before Fx4 launches. Current page design can be seen here: http://www.mozilla.com/en-US/firefox, although URLs may change in the future pending Bug 629407 and a new design may be deployed before this time (Bug 625791). 

**This will be the main Firefox 4 download channel on launch day**

Everyone not yet on Firefox 4 should be redirected to this page. That includes current Fx users on 3.6. 

Graphic Changes:
1. Update screenshot with Fx4 version of the browser. Both Mac and PC screenshots will be needed. 

2. Change button to "Download Firefox 4" button

3. At this time we should have the download counter working right below the screenshot (see the download counter in this version of the homepage: http://www.mozilla.com/en-US/firefox/new/creatures.html). At this time lets implement the daily json feed stream of Fx4 downloads so this page is a accurate reflection of Fx4 downloads. It includes Beta downloads which is fine.

json stream: https://metrics.mozilla.com/stats/firefox_downloads_total.json 

Copy Changes:
4. Repurpose all copy to support Firefox 4 launch. Should be short and exciting and support the overarching fast, fresh, and fun theme. 

5. Also consider changing the 4 promo spots at the bottom. 
a) Possibly change the first spot to a more specific "Meet Firefox 4." Continue linking to the getting started page. 

Depending on input you've heard from PMM consider changing the focus of these three feature blurbs to fit the most exciting features unique to Fx4. 
b) Safe
c) Fast
d) Personalize

John - Assigning this bug to you first for Copy changes.
Target Milestone: 1.3 → 1.4
Target Milestone: 1.4 → 1.3
Target Milestone: 1.3 → 1.4
Additional requirement to this page, per Caitlin:

Add a small blurb (where the
current Beta blurb is) about mobile on the download page
(http://www.mozilla.com/en-US/firefox/)

Change "Try the new Firefox 4 Beta! Free download." to "Get Firefox on your
phone!" with small phone icon, similar to what has been design on
http://www.mozilla.org/

The link should point here:
http://www.mozilla.com/en-US/mobile/?WT.mc_id=ba3614&WT.mc_ev=click
Hey John - I think you're done with the copy here. If so, can we pass this over to a designer?
Priority: -- → P1
(In reply to comment #3)
> Hey John - I think you're done with the copy here. If so, can we pass this over
> to a designer?

Sean will be posting files here tomorrow. Stay tuned!

Also, the design is an evolved version of http://www.mozilla.com/en-US/firefox/new/creatures.html, so if it's easier to build on top of that one rather than start from scratch I'm all for it. Also, the new version should be sure to include the various back-end perf optimizations that went into the version we tested earlier this year.
Awesome, thanks Sean!
Assignee: jslater → steven
One other thing about this page...we're featuring the download counter as a design element. Can we set up a cron job to pull in the download stats on a regular (such as daily) basis? Or perhaps there's another way? Once we figure that out, we'll need to put some sort of initial number there so it doesn't read 000,000,000 for the first 24 hours.

Also, we'll need to make sure that whatever we do doesn't cause a performance hit here after all the optimization work that's been done.

Anthony, Steven...any thoughts as to the best solution?
Here's a json feed that Daniel E. put together: https://metrics.mozilla.com/stats/firefox_downloads_total.json

As of today 4.0 shows 24,835,568 downloads. 

I know there are other data efforts going on. For example, I think Potch is creating a widget based on the global map numbers so we may want to sync up with that feed, to some extent, to maintain consistency.
For the launch, I think the best thing to do is to setup a cron task to fetch the JSON and store it on the mozilla.com servers. And then the page would generate the HTML for that based on the JSON.

We should open a bug with IT to set this cron.
(In reply to comment #9)
> We should open a bug with IT to set this cron.

Anthony, do you mind doing that? I have a feeling you'd be able to describe what's needed a lot better than I could. Just be sure to copy me & Laura.

Also, it still seems like for launch day we need to pick some random number and use that as a starting point so it's not at 000,000,000.
John, perhaps we could work up a static fall-back for cases where the real stats are failing - and this could also serve us during the first few hours of launch when the numbers might still be a bit wonky.

Maybe something like this (I'm making up the numbers):

 "Over 4 million downloads of Firefox 3.6 and 4."
Why not just use the existing 24m number for downloads of 4.0 betas?
(In reply to comment #12)
> Why not just use the existing 24m number for downloads of 4.0 betas?

+1 since that number is impressive and those folks are running 4.0 (though in Beta form).
Not ready yet - but getting there (r84291). Will be ready for QA tomorrow AM.
Finished up the rest of this page in r84379. A few caveats:

1. The 24,000,000 number is just static for now (Bug 639481 is setup to get us a real number)

2. The link for "Watch the Video" is just a generic Video page link for now - we can update when we get the final video.

3. The transparency of the screenshot and the monsters that show through it are a bit weird in the Windows version. Will have to get some updated artwork from Sean on that.

QA can probably happen while we wait for those final pieces.
Keywords: qawanted
Looks great, thanks Steven!

(In reply to comment #15)
> 1. The 24,000,000 number is just static for now (Bug 639481 is setup to get us
> a real number)

That sounds good, but we still need to figure out something to put on the page
for the initial period of time before the auto-updating from bug 639481 kicks
in (the first day, basically). Is it possible to put in an initial number for
that first period and then have it switch over to the feed when it's ready?

That would be my preference, at least. Assuming we can do something like that,
let's do a number that approximately represents our beta downloads thus far:
4,017,240.

> 2. The link for "Watch the Video" is just a generic Video page link for now -
> we can update when we get the final video.

Could you make this a lightbox that hovers over the homepage rather than taking
people to the videos page? Would love to keep people on the homepage rather
than sidetracking them for this one if possible.

> 3. The transparency of the screenshot and the monsters that show through it are
> a bit weird in the Windows version. Will have to get some updated artwork from
> Sean on that.

Have you already talked to Sean about what you need? Is he on it?
I think it might be useful for me to give a quick recap of what exactly the number in the json file means.

The numbers in the firefox_downloads_total.json are only downloads that *are not* the result of an AUS driven update.  We tell this by looking in the logs for downloads that have a product=firefox* not ending in either -complete or -partial-*.  The common consensus is that these downloads are typically driven by a user manually browsing to a webpage and clicking a link to download the installer package for their platform.  Hence, the best source for calculating intent driven downloads.

The number for "4.0" right now is 27m.  That consists of every "manual" download for every beta and nightly that has been considered a part of Firefox 4.0 all aggregated together.

If needed, we can expand this out into sub-versions or have this number and an additional number that is only downloads of the final release product and higher (i.e. discount pre-releases)

The only thing we can't really do is give a reasonable counter for those AUS driven downloads.  That is because Firefox uses a chunking download process for upgrade files and there are multiple requests with a 204 result code for each chunk.  Currently, we have no way of determining how many chunks translate to the successful download of the entire file by a single user.
(In reply to comment #18)
> The number for "4.0" right now is 27m.  That consists of every "manual"
> download for every beta and nightly that has been considered a part of Firefox
> 4.0 all aggregated together.
> 
> If needed, we can expand this out into sub-versions or have this number and an
> additional number that is only downloads of the final release product and
> higher (i.e. discount pre-releases)

Thanks for this. To clarify, we'd like to communicate the number of downloads "Firefox 4" has received. I'd define that to include Firefox Beta 4, Firefox 4 RC and Firefox 4 Final Release (Fx4 Beta + Fx4 RC + Fx4 Final Release). Is that what the 27m number represents/will represent? If not, what would the source of that number be?

Also, if the RC numbers are too complicated to include, that's fine. I don't want to get caught up in too many details. The overall objective is to show the big magic number everyone will be watching on launch day.
Yes, the 27m currently includes all of those plus the prerelease versions i.e. b13pre  Obviously, manual downloads of prerelease versions are very minimal and don't really inflate the number.

If we are good with starting out with 27m on day 0 of the release, we are golden.  If we want to start out with a lower number then we could probably write a new number that would include only rc1 or rc2 and final.  Obviously, my vote is for the number we currently have.
(In reply to comment #20)
> Yes, the 27m currently includes all of those plus the prerelease versions i.e.
> b13pre  Obviously, manual downloads of prerelease versions are very minimal and
> don't really inflate the number.
> 
> If we are good with starting out with 27m on day 0 of the release, we are
> golden.  If we want to start out with a lower number then we could probably
> write a new number that would include only rc1 or rc2 and final.  Obviously, my
> vote is for the number we currently have.

I agree - lets start with the number we currently have.
This runs counter to how we've done it in the past. With past releases (think Download Day, for example) we've started with the counter at 0 and then started when people started downloading the actual GA release, not the betas or RCs. To do it the other way feels a little misleading, like we're inflating our total when we don't really need to.

I'd be interested in what Mayumi thinks, but I think we should start the counter at 0 and count only official Firefox 4 downloads. (But also start with a default number in place on the site for day 1 as noted in comment #17.)
Here's the functionality I propose for the download count:

1. A cron job copies the download count JSON file to the mozilla.com server once a day (Bug 639481 to set this up)
2. Using PHP in the main index.html file, the JSON file is imported and parsed.
3. If the importing/parsing works and the result is numeric and not 0 (a little sanity check), that number will be displayed.
4. If the conditions of step 3. are not met, we display fall-back text (something like "Over X Million"
5. If the number imported in step 3. is less than the magic number we choose as our beta/rc total number that we'll use on launch day (let's say, 24,000,000 - you can give me an exact figure), then we show our magic number instead.

Does this sound sane? I'm not quite sure about #5. Back in 2008, on the launch day of Firefox 3, there were about 8,000,000 downloads on the first day. If it will take more than a day or cross that 24,000,000 threshold, maybe we should figure something else out.
I also wondered if on the first day (or first few days), we should run the cron job to grab the stats file more frequently. Maybe hourly? Is there a way we could update it manually if needed?

Daniel, how often is this file updated? https://metrics.mozilla.com/stats/firefox_downloads_total.json
Currently the file is updated daily.  We have a lot of flexibility there though.  here are some points that I could work on to help you guys out.  Let me know which ones are interesting.  None of them would take more than an hour of work in total.

1. It is extremely unlikely that the file would ever be invalid.  If something goes wrong with the generation, it is possible that it could be stale.  I could do some tests to explore certain failure conditions such as a query execution error and validate that the file is not replaced or invalid in those cases.  That would make the conditional validation logic in the app easier.

2. I can put a new number in that would consist of only RC + Final downloads.  I might be able to do only finals, but I am not quite as sure of that because of the way RCs are labeled so much like the real final release.

3. I can put a minimum number in as a fall-back, e.g. max(real_num, 24000000) so you wouldn't have to put that logic in the app

4. I could increase the frequency of updates for this file to be hourly.  It would still have a 4 hour lag however.  This is because of the time it takes the log files to be collected from the servers and delivered to me.
Updated the screenshots on the home page with Laura and John's recommendations and Sean's photoshoppery (r84698).

I need a sanity check from someone else on the quality of the images. These screenshot/monster image is around 42Kb (varies a few kb between mac/linux/win). This is with a 256-color PNG which results in some visible dithering.

Going with full-color PNGs (look perfect) is probably out of the question as they jump from about 42Kb to 160Kb and JPEG isn't feasible since the creatures overlap with the page background (and so require at least 1-bit transparency).

If people tell me I'm crazy and this is fine, we're done. If people think it looks a bit poor, I'll keep digging for some options (could do a partial PNG/partial JPEG hybrid that could help a bit, but there are tradeoffs).
There was some discussion of the download-counter button on a phone call today, but I'm not sure what the conclusion was. I think we were leaning toward manual updates for the first day or so.

That still begs the question of what we actually display (manually or automagically) in the first few hours after launch.
Re: screenshots, I'm having trouble viewing the page b/c I'm getting redirected to the panda version (even when I try it in a different browser). What's the best way to check those out?

Re: download counter, Morgamic is going to follow up with Daniel and will post more details here when he has them. We should still plan on having a number manually displayed before the updates start kicking in, but let's see what Mike says before deciding what that should be.

Thanks!
(In reply to comment #28)
> Re: screenshots, I'm having trouble viewing the page b/c I'm getting redirected
> to the panda version (even when I try it in a different browser). What's the
> best way to check those out?

While the redirect issues get sorted out, you'll have to view the images directly:
http://www-fx4.stage.mozilla.com/img/covehead/firefox/main-feature.png
http://www-fx4.stage.mozilla.com/img/covehead/firefox/main-feature-mac.png
http://www-fx4.stage.mozilla.com/img/covehead/firefox/main-feature-linux.png
looks good. only thing is curly's hand isn't wrapping around. that might be my fault if I turned off the layer in the PSD.
Yeah, I think these look good. Sean, can you see if it's as simple as turning back on that layer and repost if so?
Curly's hand has been restored in r84732. He should recover full use of it in a few hours.
Steven: If you're using ImageAlpha to create the 256-color PNG from PNG24, it was updated a few days ago (0.6.2) with a better algorithm (see http://pornel.net/pngquant for examples)
Mike, any updates on the download counter? (Thought you were cc'd on this bug already, but see comment #28 for context...I based that on our conversation from earlier.)
Should just be manual updates for first 4 hours until we have enough data to leave it automated.  Someone on the website team can update this and work with daniel or someone in metrics to just update 1 number, right?  Seems easy enough.
(In reply to comment #35)
> Should just be manual updates for first 4 hours until we have enough data to
> leave it automated.  Someone on the website team can update this and work with
> daniel or someone in metrics to just update 1 number, right?  Seems easy
> enough.

Sounds like a plan to me. In that case, let's put the default initial number at 2,091,478. That ought to hold us for a bit until we do the first manual update.

Thanks all.
I'd be honored to type in some digits on launch day. One for all.
Thanks James!
So let me make sure I understand.

We want to create a new number in the JSON file that will be just Firefox 4.0 release downloads, not rc or earlier.

On Monday, I will add this new value to the JSON and also bump up the generation to be hourly.

I hope that if the website could pick up the file more frequently, we wouldn't have to default to a large starting number but could instead have a much smaller number of several hundred or a few thousand which would quickly be overtaken by the real numbers within hours of release.

Note that rather than hardcoding anything in the website, I can put a min value in the generation of the JSON and that way it will be automatically replaced when possible.
How will server-side caching of the home-page affect this download count? How often does the cached get refreshed (or what triggers it)?
Is the JSON format solidified yet? The format in the current file (https://metrics.mozilla.com/stats/firefox_4_final_downloads_total.json) is a bit weird. Something like the following might make more sense:

{
  product:   Firefox,
  version:   4.0,
  downloads: 4356782345
}

Also, I'm not sure it makes sense to manipulate the data before it goes in the JSON file unless the JSON file is only ever going to be used for the main page and everyone knows and respects that.
The format made a bit more sense when there were multiple versions in the file like the old one.
Steve suggested that we skip JSON entirely and just have the number and nothing else in the file.  I'm fine with that too.

I think that putting the minimum in the JSON makes sense because it is a very short term thing.  Within a couple of hours of release, that minimum will be surpassed and will never factor in again.

This new data file especially is custom generated just for you guys.
Ok, works for me. The code to use the JSON on the home page is committed in r85048.
Is Bug 639481 still valid? I don't have access to it.
I see that Michael's code points directly to https://metrics.mozilla.com/stats/firefox_4_final_downloads_total.json, I guess this url will be updated for a server that handles heavy loads ?
Please see bug 639481 comment #16.  We definitely have to figure this out.
(In reply to comment #45)
> Please see bug 639481 comment #16.  We definitely have to figure this out.

I think comments 17 and 18 on bug 639481 address your questions (but let us know if not)...no need to overcomplicate at this point.
Yes. at the moment I am taking the stance that there are no further changes needed from me.  Unless I'm told differently, it will stay JSON generated hourly, and Shyam or someone else in IT is responsible for setting up the sync to copy the file to the webheads.
Sounds good, thanks.
In r85268, cleaned up the download count code to use the locally cached copy of the json file and provide more generic fallback content.
In r85269, Make fallback text only defined in one spot to make it easier for translators.
Depends on: 642135
The fall back text (if the json file is missing or corrupted) is "Millions of".

Filed Bug 642135 to get this setup in production.
Per Comment #2 (and duplicate bug: https://bugzilla.mozilla.org/show_bug.cgi?id=634674) the mobile blurb/link will be listed on both Homepage Non-Fx4	(www.mozilla.com/firefox) and Homepage Using Fx4	www.mozilla.com/firefox/new? Thanks for confirming.
Yep, there will be mobile promos on both versions of the page at launch. You can see the staged pages at http://www-fx4.stage.mozilla.com/en-US/firefox/fx/ and http://www-fx4.stage.mozilla.com/en-US/firefox/new/.
Great, thanks.
Filed Bug 642506 for the video lightbox.

John, can you confirm exactly which video the "What the Video" link should point to? There are a few potential candidates on /firefox/video/ ("Firefox 4 Features", or maybe " What’s New in Firefox 4")
(In reply to comment #55)
> John, can you confirm exactly which video the "What the Video" link should
> point to? There are a few potential candidates on /firefox/video/ ("Firefox 4
> Features", or maybe " What’s New in Firefox 4")

lforrest confirmed this for me on IRC (thanks) - updated in r85431. Autoplay is on now too.
Status: NEW → RESOLVED
Closed: 13 years ago
Keywords: qawanted
Resolution: --- → FIXED
http://validator.nu/?doc=http://www-fx4.stage.mozilla.com/en-US/firefox/new/ fails validation reopening
Status: RESOLVED → REOPENED
Keywords: qawanted
Resolution: FIXED → ---
(In reply to comment #57)
> http://validator.nu/?doc=http://www-fx4.stage.mozilla.com/en-US/firefox/new/
> fails validation reopening

This appears to be validating. Can you confirm?
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Does the Team Firefox promo get switched with mobile here or just a link under the download button?
yes, please file a new bug.  http://www-fx4.stage.mozilla.com/en-US/firefox/fx/
We want to replace "Be Part Of Team Firefox. Help us share Firefox 4 with the world." with a mobile promo. 

Slater - Do you have copy you need? 
Caitlin - I can file the but otherwise assuming you are.
I'll file (actually think I already did, so I'll look now or file again).
verified fixed http://www.mozilla.com/
Status: RESOLVED → VERIFIED
Component: www.mozilla.org/firefox → www.mozilla.org
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.