Closed Bug 549410 Opened 14 years ago Closed 14 years ago

Create new "What's New" page for 3.0.19

Categories

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

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: lmesa, Assigned: pascalc)

References

()

Details

Like to create a new page to address the fact that this is the last version of Firefox 3 we will be supporting. 

We'd like to:
-Add a Yellow warning sign at the top of the page to warn users that this is the last supported version of Firefox 3
-Add new copy to urge users to upgrade to 3.6
-Add a survey link to try and understand why people choose not to upgrade from Firefox 3.
Assignee: nobody → jslater
Is this something that could replace all 3.0.x whatsnew pages?  
I'd love to collapse these older pages into one version, in the name of sanity, organization and a smaller SVN tree.

Is this change for English only?  
If we localize these changes, we can collapse about 550 pages to 50.

Should we do something similar for 3.0.x firstrun pages?

Thanks
I'm fine with changing redirects so that the firstrun/whatsnew pages for all Firefox 3.0.x pages go to a single location, sure. It will have to be localized, though.
when is 3.0.19 planned?
I didn't mean to hijack this bug.  If Laura's changes were meant for English only, I can file a separate bug.
Mike, just to confirm, we want to go the full "Security warning: unsupported
browser, etc" scary treatment here, right? 

If so, I can write some text for that this week, then we can get it into l10n
(and get the en-US page built).

Comment #1 sounds great to me, too. It's not for English only, so you're definitely not hijacking anything.
Here's a first pass at the text - let me know what you think (note: it's based on the look & format of the Flash warning page shown at http://blog.mozilla.com/metrics/2009/09/16/helping-people-upgrade-flash/).

Headline:
Security warning: This is an outdated version of Firefox.

Subhead:
Using this version of Firefox will leave you vulnerable to online security threats. Please _download the newest version_ (free!) for the latest security, performance and feature updates.


(Also, I'd recommend removing the row of promos from the bottom, as we don't have anything about Fx3 to promote at this point. Probably would be good to keep a "Firefox Help" link that points to SUMO, though.)
Remember that this will be the first time we're telling these users that Firefox 3.0.x isn't supported. While there's nothing factually false about what you're saying, I think that it implies that Firefox 3.0.19 is already insecure, which isn't the case. 

Something more along the lines of:

Headline:
You should _upgrade to Firefox 3.6 for free_ right now.

Subhead:
Thanks for using Firefox. To keep you safe and secure as you browse, you should _upgrade to Firefox 3.6 for free_ since we will no longer be automatically updating this version.

Then, along the bottom, we need to run a survey for people to tell us why they don't want to upgrade. We might actually want a big content block that has something like:

  ,--------------------------.   .-------------,
  |  Get the free upgrade!   |   | No  thanks! |
  '--------------------------'   '-------------'

And if the user clicks "No thanks" we put up a survey asking them why they aren't planning on upgrading using kkovash's standard set of questions.
The text in comment #8 looks good. I'm copying Julie here so she can do a quick legal review on the security message.

Julie, the text in comment #8 will appear on the first run page to anyone who downloads Firefox 3. The idea is to let them know that it's now an outdated version and that they should upgrade to 3.6 so they'll be more secure. Is the proposed wording ok?
Julie, ping?
Beltzner's language in comment 8 looks good.  No issues from legal.
(In reply to comment #8)

> Then, along the bottom, we need to run a survey for people to tell us why they
> don't want to upgrade. We might actually want a big content block that has
> something like:
> 
>   ,--------------------------.   .-------------,
>   |  Get the free upgrade!   |   | No  thanks! |
>   '--------------------------'   '-------------'
> 
> And if the user clicks "No thanks" we put up a survey asking them why they
> aren't planning on upgrading using kkovash's standard set of questions.

It may make sense to have three button options instead of just 2.
1) Get the Free Upgrade 
2) No, thanks.
3) No, thanks- Let me tell you why.

Hooking the survey up to "No, thanks" feels like an overly aggressive user experience. This way, users know they'll probably see a survey link if they hit option 3.  

We also need to make sure that we remove the third option a day or two after the release so that we don't overwhelm surveygimo unnecessarily.
(In reply to comment #12)
> It may make sense to have three button options instead of just 2.
> 1) Get the Free Upgrade 
> 2) No, thanks.
> 3) No, thanks- Let me tell you why.
> 
> Hooking the survey up to "No, thanks" feels like an overly aggressive user
> experience. This way, users know they'll probably see a survey link if they hit
> option 3.  

What would the "No, thanks" button do in that case?  I'm thinking change the "No, thanks" button, not add a third one.  

Imho, I don't think it's overly aggressive.
(In reply to comment #13)
> (In reply to comment #12)
> > It may make sense to have three button options instead of just 2.
> > 1) Get the Free Upgrade 
> > 2) No, thanks.
> > 3) No, thanks- Let me tell you why.
> > 
> > Hooking the survey up to "No, thanks" feels like an overly aggressive user
> > experience. This way, users know they'll probably see a survey link if they hit
> > option 3.  
> 
> What would the "No, thanks" button do in that case?  I'm thinking change the
> "No, thanks" button, not add a third one.  

Yeah, you're totally right. 
> 
> Imho, I don't think it's overly aggressive.

I think changing the wording on the button would make it less aggressive because this way people know what they're getting when clicking the button. Just saying "no thanks" and then having a survey pop up seems very unexpected.
(In reply to comment #14)
> I think changing the wording on the button would make it less aggressive
> because this way people know what they're getting when clicking the button.
> Just saying "no thanks" and then having a survey pop up seems very unexpected.

Cool, makes sense.  wfm.
Given the recent comments, how about this button breakdown:

1. Get the Free Upgrade
2. No Thanks (Let Me Tell You Why)

The parenthetical text in button #2 could be written in a smaller font below the main text.

How does that sound?
Sounds good to me!
Next step?  Over to Silverorange?
Assignee: jslater → steven
Hey Steven. I know you've got a lot on your plate right now, so let me know if you want to talk about project prioritization.

My quick thought on it is that this and bug 549413 (which is related) should probably be the first ones to knock out of the way...they're release-related and have a l10n component.

Thanks!
Should the "Get the Free Upgrade" button be a direct download button, like we have on the home and Firefox pages, or just a link to /firefox/ ?
(In reply to comment #20)
> Should the "Get the Free Upgrade" button be a direct download button, like we
> have on the home and Firefox pages, or just a link to /firefox/ ?
Direct download, please.
This is set up in trunk (r64064). Do we have a destination for the "No Thanks" link?
Missed a file in my commit - stand by...
Fixed in r64078. You can preview here: http://www-trunk.stage.mozilla.com/en-US/firefox/3.0.19/whatsnew/

Is that the right idea?
(In reply to comment #24)
> Fixed in r64078. You can preview here:
> http://www-trunk.stage.mozilla.com/en-US/firefox/3.0.19/whatsnew/
> 
> Is that the right idea?

Looks great to me, yep. Laura, do you have a survey link we could use re: the question in comment #22?
minor visual tweaks (spacing, font size) in r64081.
Ken is still finalizing the survey.  I will post once it's finished.
(In reply to comment #27)
> Ken is still finalizing the survey.  I will post once it's finished.

So, here is the survey link: http://www.surveygizmo.com/s/258563/firefox-major-upgrade-survey.

I am filing another bug to get the survey imbedded in a mozilla.com page so it uses the mozilla.com theme.
Depends on: 551774
Laura -- wouldn't it be easier to just repurpose this survey -- http://www.mozilla.com/en-US/firefox/mu-survey/ -- which is already live?

We just need web dev to change "3.5" to "3.6" in the line "We're sorry you don't want to upgrade to Firefox 3.5."  (You and I can make the same changes within question #1.)
But then the responses would get mixed up with the older ones.
I'm all for easy, I just want to make sure that we don't screw up our data from either survey. If we can do that by re purposing the old survey, then we should do it.
Mixing up the data/responses isn't an issue.  That's what surveygizmo's reporting interface/tool is for :)
I'm not so sure I agree that it won't be an issue. It's up to you.
(In reply to comment #29)
> Laura -- wouldn't it be easier to just repurpose this survey --
> http://www.mozilla.com/en-US/firefox/mu-survey/ -- which is already live?
> 
> We just need web dev to change "3.5" to "3.6" in the line "We're sorry you
> don't want to upgrade to Firefox 3.5."  (You and I can make the same changes
> within question #1.)

Let's go with ken's suggestion. I've changed the copy in the embedded part of the survey which is on that page. Now all we need is for Steven to change the copy in the subhead to 3.6 and link that survey to the gray button on the 3.0.19 page.
Link and 3.5/3.6 update on mu-survey page updated in trunk in r64104. I presume the survey is en-US only?
It is en-us only. Also, I still see "3.5" instead of "3.6" in the subheader of the survey page.
(In reply to comment #36)
> It is en-us only. Also, I still see "3.5" instead of "3.6" in the subheader of
> the survey page.

The survey has only been changed in Trunk so far - should that go to production?

http://www-trunk.stage.mozilla.com/en-US/firefox/mu-survey/
Thanks Steven.  Let's wait on pushing to production until QA has signed off. 

Assigning to Steven.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Assignee: steven → stephen.donner
Assignee: stephen.donner → mozwebqa
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Raymond: please take a look at this; thanks!
(In reply to comment #39)
> Raymond: please take a look at this; thanks!

Raymond's busy on Firefox 3.next testing; looks good to me.  Reassigning to Steven; feel free to push whenever.
Assignee: mozwebqa → steven
All merged to stage in r64218. Following files to push to production: 

 en-US/firefox/3.0.19
 en-US/firefox/3.0.19/firstrun
 en-US/firefox/3.0.19/firstrun/index.html
 en-US/firefox/3.0.19/releasenotes
 en-US/firefox/3.0.19/releasenotes/index.html
 en-US/firefox/3.0.19/whatsnew
 en-US/firefox/3.0.19/whatsnew/index.html
 en-US/firefox/mu-survey/index.html
 img/tignish/whatsnew/no-download-button.png
 includes/headers/3.0/whatsnew.inc.php
 style/tignish/whatsnew-page.css
Thanks Steven.  When should these files be pushed? Do we wait for release, typically?
(In reply to comment #42)
> Thanks Steven.  When should these files be pushed? Do we wait for release,
> typically?

Beltzner would probably be the best person to answer this, but I think it should be fine to push any time.
Beltzner, are you okay with pushing now?
Spoke to Beltzner in person. We can go ahead and push.
Just pushed 'em.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
John: you also pushed the releasenotes by accident, I think, with the 3.0.18 content. We'll fix it when we push the beta content, but I wanted you call it out for next time.

All: when we go to beta today we'll be adding a redirect that takes 3.0.19/whatsnew to 3.0.19rc/whatsnew, meaning that you won't be able to see the live page anymore. Just so you know!
For the record, I merged the release notes to stage and listed them for John, so it's on me.
Apologies for that...I pushed the files Steven had listed, but it's good to be aware of that so I can catch it if it happens again.
(In reply to comment #47)
> John: you also pushed the releasenotes by accident, I think, with the 3.0.18
> content. We'll fix it when we push the beta content, but I wanted you call it
> out for next time.
> 
> All: when we go to beta today we'll be adding a redirect that takes
> 3.0.19/whatsnew to 3.0.19rc/whatsnew, meaning that you won't be able to see the
> live page anymore. Just so you know!


verified fixed on production 
http://www.mozilla.com/en-US/firefox/3.0.19/firstrun/
http://www.mozilla.com/en-US/firefox/3.0.19/releasenotes/

reopening  because  of this

The redirect for http://www.mozilla.com/en-US/firefox/3.0.19/whatsnew  to  
http://www.mozilla.com/en-US/firefox/3.0.19rc/whatsnew is currently not working
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I'm pretty sure the redirect *is* working, it's just the URL doesn't actually change.  The page content is the RC content.  The regular 3.0.19 page looks different.  Beltzner can verify that.
Where are we with this bug? Still waiting for Beltzner to confirm?
(In reply to comment #51)
> I'm pretty sure the redirect *is* working, it's just the URL doesn't actually
> change.  The page content is the RC content.  The regular 3.0.19 page looks
> different.  Beltzner can verify that.

The page content at http://mozilla.com/firefox/3.0.19/whatsnew that I'm seeing is not the rc content, it's the final content, which is wrong. That may have happened with a recent .htaccess push, needs to be fixed.
Ok, thanks Mike.  I'll look into it
Assignee: steven → buchanae
Rewrite rules were commented out by Pascal here:
http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/.htaccess?r1=64403&r2=64511

reason:
remove redirect from all 3.0.19 pages to 3.0.19 beta page because it prevents localizers to see their work on 3.0.19 new in-product page

Pascal, is there a way we can have those rewrites and still allow localizers to work?  maybe a second rewrite that allows them to view the content under some alias like /firefox/3.0.19/whatsnew-preview ?
it seems easier to me to only commit the rules that should be on stage/production (copying to stage only the lines you want with a tool like Meld and not the whole file) or to put another .htaccess with the redirects for en-US only in the en-US folder instead of the root.
(In reply to comment #56)
> it seems easier to me to only commit the rules that should be on
> stage/production (copying to stage only the lines you want with a tool like
> Meld and not the whole file) 

Trying to keep specific changes (especially .htaccess) on stage only (and not trunk) is futile, because the next time someone pushes .htaccess in Kubla, it will be broken again.

> or to put another .htaccess with the redirects for
> en-US only in the en-US folder instead of the root.

That might work, but I think that localized builds will use /{locale}/firefox/3.0.19/whatsnew, they won't get the en-US only .htaccess, so they will get the wrong page.  Is my thinking correct?

Beltzner, why are we rewriting the release URL to the RC content?  Is this standard practice, or one-off?

A rewrite like /firefox/3.0.19/whatsnew-preview would be easy enough to implement.  Would there be a big impact on l10n?
simple, don't use kubla to push .htaccess :)

I am not sure what you mean by l10n impact, the only thing needed on productionb is to redirect the 3.0.19 en-US page to the temporary rc one, there are no 3.0.19 localized pages pushed to production since we will push them at release time, so everything is falling back to the en-us one which at its turn is redirected to the rc one. My 3rd proposal would be to simply replace the 3.0.19 en-US page by a php redirect to the rc one.
(In reply to comment #58)
> simple, don't use kubla to push .htaccess :)

haha


> I am not sure what you mean by l10n impact, the only thing needed on
> productionb is to redirect the 3.0.19 en-US page to the temporary rc one, there
> are no 3.0.19 localized pages pushed to production since we will push them at
> release time, so everything is falling back to the en-us one which at its turn
> is redirected to the rc one. 

ok, this is what I wanted to verify.  I will implement an en-US only htaccess
r64744 made the en-US htaccess on trunk

Pascal, please could you verify things work as you need?  Then I'll push to production.
Assignee: buchanae → pascalc
I just tried and everything works fine:

* en-US 3.0.19 goes to the beta page
* locale pages done on trunk are correctly displayed
* locale pages not done on trunk fall back to the en-US beta page

good for me :)
Thanks Pascal.

r64749 on tags/stage
r64751 on tags/production
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
well, that htaccess file caused bug 554837 :(  

For the record, en-US only rewrite rules is a bad idea.  Not yet sure why it breaks things, something about having "RewriteEngine On" in an htaccess below another that also has rewrites.

Back to the drawing board.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
r64799 on trunk
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
r64824 on stage and production
OK, I'm not sure what happened here, or why this is so difficult.

Comment 55 is ridiculous; localizers should be checking their work against the trunk-www server, not the production server. That's what trunk-www is for.

This was just a screw up. We *always* publish a redirect from 3.x.y to 3.x.yrc until we're ready to launch, and the localizers *always* check their work against the trunk.
Mike, I think you misundderstood comment 55, I commented out the redirect on TRUNK precisely because it prevented localizers to work normally on TRUNK. No localizers are working on production, somebody pushed the updated .htaccess from trunk to stage/production, and *that* was the problem.
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.