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)
www.mozilla.org
General
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.
Reporter | ||
Updated•14 years ago
|
Assignee: nobody → jslater
Comment 1•14 years ago
|
||
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
Comment 2•14 years ago
|
||
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.
Assignee | ||
Comment 3•14 years ago
|
||
when is 3.0.19 planned?
Comment 4•14 years ago
|
||
I didn't mean to hijack this bug. If Laura's changes were meant for English only, I can file a separate bug.
Comment 5•14 years ago
|
||
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.
Comment 6•14 years ago
|
||
Pascal: http://wiki.mozilla.org/Releases! :) John: yup!
Comment 7•14 years ago
|
||
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.)
Comment 8•14 years ago
|
||
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.
Comment 9•14 years ago
|
||
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?
Comment 10•14 years ago
|
||
Julie, ping?
Comment 11•14 years ago
|
||
Beltzner's language in comment 8 looks good. No issues from legal.
Reporter | ||
Comment 12•14 years ago
|
||
(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.
Comment 13•14 years ago
|
||
(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.
Reporter | ||
Comment 14•14 years ago
|
||
(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.
Comment 15•14 years ago
|
||
(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.
Comment 16•14 years ago
|
||
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?
Reporter | ||
Comment 17•14 years ago
|
||
Sounds good to me!
Comment 18•14 years ago
|
||
Next step? Over to Silverorange?
Reporter | ||
Updated•14 years ago
|
Assignee: jslater → steven
Comment 19•14 years ago
|
||
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!
Comment 20•14 years ago
|
||
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/ ?
Comment 21•14 years ago
|
||
(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.
Comment 22•14 years ago
|
||
This is set up in trunk (r64064). Do we have a destination for the "No Thanks" link?
Comment 23•14 years ago
|
||
Missed a file in my commit - stand by...
Comment 24•14 years ago
|
||
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?
Comment 25•14 years ago
|
||
(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?
Comment 26•14 years ago
|
||
minor visual tweaks (spacing, font size) in r64081.
Reporter | ||
Comment 27•14 years ago
|
||
Ken is still finalizing the survey. I will post once it's finished.
Reporter | ||
Comment 28•14 years ago
|
||
(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.
Comment 29•14 years ago
|
||
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.)
Reporter | ||
Comment 30•14 years ago
|
||
But then the responses would get mixed up with the older ones.
Reporter | ||
Comment 31•14 years ago
|
||
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.
Comment 32•14 years ago
|
||
Mixing up the data/responses isn't an issue. That's what surveygizmo's reporting interface/tool is for :)
Reporter | ||
Comment 33•14 years ago
|
||
I'm not so sure I agree that it won't be an issue. It's up to you.
Reporter | ||
Comment 34•14 years ago
|
||
(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.
Comment 35•14 years ago
|
||
Link and 3.5/3.6 update on mu-survey page updated in trunk in r64104. I presume the survey is en-US only?
Reporter | ||
Comment 36•14 years ago
|
||
It is en-us only. Also, I still see "3.5" instead of "3.6" in the subheader of the survey page.
Comment 37•14 years ago
|
||
(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/
Reporter | ||
Comment 38•14 years ago
|
||
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
Reporter | ||
Updated•14 years ago
|
Assignee: steven → stephen.donner
Updated•14 years ago
|
Assignee: stephen.donner → mozwebqa
Updated•14 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•14 years ago
|
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
Comment 41•14 years ago
|
||
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
Reporter | ||
Comment 42•14 years ago
|
||
Thanks Steven. When should these files be pushed? Do we wait for release, typically?
Comment 43•14 years ago
|
||
(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.
Reporter | ||
Comment 44•14 years ago
|
||
Beltzner, are you okay with pushing now?
Reporter | ||
Comment 45•14 years ago
|
||
Spoke to Beltzner in person. We can go ahead and push.
Comment 46•14 years ago
|
||
Just pushed 'em.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Comment 47•14 years ago
|
||
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!
Comment 48•14 years ago
|
||
For the record, I merged the release notes to stage and listed them for John, so it's on me.
Comment 49•14 years ago
|
||
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.
Comment 50•14 years ago
|
||
(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 → ---
Comment 51•14 years ago
|
||
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.
Reporter | ||
Comment 52•14 years ago
|
||
Where are we with this bug? Still waiting for Beltzner to confirm?
Comment 53•14 years ago
|
||
(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.
Comment 55•14 years ago
|
||
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 ?
Assignee | ||
Comment 56•14 years ago
|
||
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.
Comment 57•14 years ago
|
||
(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?
Assignee | ||
Comment 58•14 years ago
|
||
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.
Comment 59•14 years ago
|
||
(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
Comment 60•14 years ago
|
||
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
Assignee | ||
Comment 61•14 years ago
|
||
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 :)
Comment 62•14 years ago
|
||
Thanks Pascal. r64749 on tags/stage r64751 on tags/production
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Comment 63•14 years ago
|
||
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 → ---
Comment 64•14 years ago
|
||
r64799 on trunk
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Comment 65•14 years ago
|
||
r64824 on stage and production
Comment 66•14 years ago
|
||
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.
Assignee | ||
Comment 67•14 years ago
|
||
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.
Updated•12 years ago
|
Component: www.mozilla.org/firefox → www.mozilla.org
Updated•12 years ago
|
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.
Description
•