Closed Bug 538486 Opened 15 years ago Closed 12 years ago

First Run pages for old Firefox versions should warn user about being out-of-date

Categories

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

Product:
www.mozilla.org
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: Dolske, Unassigned)

References

Details

Attachments

(1 file)

Initial mockup of out-of-date firstrun page
271.08 KB, image/png
Details 
If a user installs an old version of Firefox, we should show them a First Run page that warn them they're not up-to-date. Currently we don't.

For example, running Firefox 3.0.3 with a new profile opens up http://en-us.www.mozilla.com/en-US/firefox/3.0.3/firstrun/ which just tells me "Thanks for downloading the safest, fastest and most customizable version of Firefox yet."

Bug 390332 covered updating the What's New pages (which users see after receiving an update for an existing profile). That seems to have been fixed at some point... Eg, if you're updated to Firefox 3.0.2, you'll get the URL http://www.mozilla.com/en-US/firefox/3.0.2/whatsnew/ and the message "You’re now running Firefox 3.0.2. For security reasons, we recommend downloading the latest and greatest version." (which links to the download page).

I found a number of old bugs for this problem (bug 378944, bug 378945, bug 378482), but this really needs to be handled automatically (ie, generate dynamic content depending on browser version).

Blake recently blogged about this: http://blog.mozilla.com/metrics/2010/01/05/55-of-new-users-install-old-versions-of-firefox/
Steven, can you look into this? Ideally we could replicate the solution for the outdated versions of What's New.
Assignee: nobody → steven
Let me know if I understand the issue correctly: Is the solution to update the firstrun pages for older releases to warn that a newer version is available? If 3.0.3 will always hit en-US/firefox/3.0.3/firstrun/ when it is first run, even if a newer version is released, correct?

If so, we shouldn't need browser version detection in the page - we can just update the (CurrentRelease - 1) pages when a new release comes out.
That's right, we don't need browser detection.  We should, however, update all previous First Run pages.

Here's a breakdown of the traffic for each version:
http://blog.mozilla.com/metrics/files/2010/01/35.png
http://farm5.static.flickr.com/4011/4249642896_a7e5af6671_o.png
http://farm5.static.flickr.com/4041/4249642870_e2bb098dd5_o.png
How should we modify the page to let users know it's not the newest versions (and why that matters)? I can imagine a few options:

1. Replace the entire page with a notice about the new version.
2. Add a box/notification at the top of the page about the new version.
3. Integrate a note/link about the new version into the existing text/layout.

I'd lean towards #1 or #2. Is there any reason we would want to preserve the content of the firstrun page for out-of-date versions?
I'd also suggest something like #1, so that it's easy to just replace previous pages with a stock "out of date" page.

Would this be an automated thing (eg, based on some server-side variable), or will someone have to update the previous version's page manually? If the latter, is there a formal checklist used when updating the web properties for a release?
Here's a (very) quick mockup of what such a warning page could look like. Wording, style, layout, etc. are all open for criticism.
Also, is there a way for a page to trigger the "Check for Updates" function in Firefox? Wouldn't that be the best way to update (rather than downloading a new installer)?
I like the look Steven.  

Instead of directing users to the download page, we could encourage them to "Check for updates" through the browser.  I'm not sure which is a better experience/more effective.  Thoughts?
There isn't any way for pages to trigger the update check in the browser.

The UX is probably better if they use the browser's update mechanism (vs linking to the download page). The instructions may be a wee bit longer, but there's less risk that we'll leave the user lost and wondering what to do next (like forgetting to actually run the new installer).

Oh, I suppose there's an interesting edge case here (which might be best to deal with later / separately)... Consider a user who installs the last Firefox 2 release, but is on a platform which isn't supported by Firefox 3+. Ideally we'd point such users at a special page for their situation (eg, explaining why we dropped support and recommending they upgrade to an modern release of their OS).
(In reply to comment #5)

> Would this be an automated thing (eg, based on some server-side variable), or
> will someone have to update the previous version's page manually? If the
> latter, is there a formal checklist used when updating the web properties for a
> release?

Beltzner says there doesn't seem to be any such checklist used, so it would be best if we can automate this server-side. Bug 390332 comment 15 implies this was possible at one time...
Dumb question...

If a user is on 3.0.10 and they click on "Help" -> "Check for Updates", what version do they actually get upgraded to?  If the answer is 3.0.latest, then the browser's update mechanism probably isn't the best solution.
Ken: they go from 3.0.10 -> 3.0.17 -> 3.5.7 (manual steps all the way).
We may have to improve the existing firstrun pages given that this is issue is already out in the install base. However, isn't this something that should be ultimately fixed in by having the installer (or app on first-run) check to make sure it is the latest version? Is there a bug for that?
(In reply to comment #6)
> Created an attachment (id=421819) [details]
> Initial mockup of out-of-date firstrun page
> 
> Here's a (very) quick mockup of what such a warning page could look like.
> Wording, style, layout, etc. are all open for criticism.

Thanks Steven. This looks good, although I do have a few suggestions...how about this:

You're almost there!

Thanks for downloading Firefox, but this version is out of date. For the latest security, performance and feature enhancements we strongly recommend that you _get the newest version_ instead.

[then, where the "get the latest version..." text is now I'd put a green download button instead]

Thoughts? Should we make the copy a bit scarier ("this is an unsupported version", etc) for people who download Fx 3.0.x?
I've taken John's changes from comment #14 and setup a page in trunk (r60271):

http://www-trunk.stage.mozilla.com/en-US/firefox/out-of-date/

We could redirect previous firstrun pages to this new page.
Looks good to me. Justin, Blake...what do you guys think?
Looks good.  Maybe (later) we should add a survey to see why users are running old fx versions.
WFM. Nice.
Any thoughts on how best to implement this? A few options:

1. Remove all first-run pages from previous releases and add redirects to this one page
2. Replace all first-run pages from previous releases with a copy of this page

What about l10n versions? Might it make sense to build something into the firstrun pages that checks the product-details library to see if there is a newer version available for that locale?
Let's replace pervious versions with a copy of this page.  This will make our analysis a bit simpler.
I'm all for cutting down the number of duplicate pages in the tree.  Can we use rewrite rules to get the same effect?
Would it be possible to do a redirect that appended URL variables that indicated the version?

For example:

redirect: /en-US/firefox/3.0.1/firstrun/
to:       /en-US/firefox/outofdate/?v=3.0.1
(In reply to comment #22)
> Would it be possible to do a redirect that appended URL variables that
> indicated the version?
> 
> For example:
> 
> redirect: /en-US/firefox/3.0.1/firstrun/
> to:       /en-US/firefox/outofdate/?v=3.0.1

yes
(In reply to comment #23)
> > redirect: /en-US/firefox/3.0.1/firstrun/
> > to:       /en-US/firefox/outofdate/?v=3.0.1
> yes

Blake: would this give you what you need for analysis?
It would, but we'd have to set up a custom campaign for each version. I suppose that's simpler than updating 30+ pages, however.  Let's do the redirect.
(In reply to comment #25)
> It would, but we'd have to set up a custom campaign for each version. I suppose
> that's simpler than updating 30+ pages, however.  Let's do the redirect.

Really?  Is there another parameter we could add that would tie it together?
Yeah, I think there's a way to set this up in Omniture so that we can see the correlation/drill-down reports by whatever comes after the "?" (oremj would know more).
i misspoke--we do not need a parameter for each version.
and how about l10n? (see comment #19)
(In reply to comment #22)

> redirect: /en-US/firefox/3.0.1/firstrun/
> to:       /en-US/firefox/outofdate/?v=3.0.1

Can we instead redirect to outofdate by default, and have exceptions for the current browser version? Judging from previous history (see comment 0), people will forget to add redirects as new versions are released. But QA will quickly notice this when testing an about-to-be-released new version, and get the redirect updated.
Is there a way we can do this redirection in .htaccess and not have to manually update the "latest version" number with each release? The product-details PHP lib can tell us the latest version number, but that's not accessible in .htaccess, is it?
(In reply to comment #30)
> (In reply to comment #22)
> 
> > redirect: /en-US/firefox/3.0.1/firstrun/
> > to:       /en-US/firefox/outofdate/?v=3.0.1
> 
> Can we instead redirect to outofdate by default, and have exceptions for the
> current browser version? Judging from previous history (see comment 0), people
> will forget to add redirects as new versions are released. But QA will quickly
> notice this when testing an about-to-be-released new version, and get the
> redirect updated.

What about redirecting all firstrun requests to a central firstrun page that is smart about whether the redirect came from a current version or not?

Something like this:

redirect: /en-US/firefox/*/firstrun/
to:       /en-US/firefox/firstrun/?v=*

Then, in the central en-US/firefox/firstrun/ file, we can check the version number in the URL var against the current version in the product-details lib and either show the current firstrun page contents, or a "your out of date" version.

The main drawback I see to this option is that the visible URL for the current firstrun page will end up changing from /en-US/firefox/3.6.8/firstrun/ to /en-US/firefox/firstrun/?v=3.6.8 and the additional redirects could be a bit of a performance hit.

Thoughts?
It sounds like user agent changes might be in the works to remove the last digit of the version info so only 3.6 might appear, and/or remove firefox info altogether.  if that is happening we need to figure out how to accommodate.
(In reply to comment #35)
> It sounds like user agent changes might be in the works to remove the last
> digit of the version info so only 3.6 might appear, and/or remove firefox info
> altogether.  if that is happening we need to figure out how to accommodate.

Chris, that shouldn't be an issue as we're not checking the user-agent. The whatsnew/firstrun pages URLs are hard-coded somewhere in the browser (with the full version number in the URL) and we check it against the latest release number in the product-details PHP library on mozilla.com.
Assignee: steven → abuchanan
r71870 on trunk, adds a rewrite rule that shows an out-of-date page for all firstrun versions that are *not* in the list of exceptions.

Some gotchas...

1) it's en-US only right now

2) it doesn't include 3.6* and 4.0*

Beltzner / Slater, should I apply this to old 3.6 versions?  Everything < 3.6.8?  What about 4.0 betas?

3) I created a rewrite rule that shows the out-of-date page only if the version doesn't match (?:3.6.*|4.*).  That means if you're creating a new firstrun page that doesn't match those exceptions, you might be scratching your head wondering why you're getting an out-of-date page.  I don't like creating a hidden line in .htaccess like that, but we'll see how it goes.

4) firstrun pages only.  old whatsnew pages already do something similar, but with a different page.  can we use the same out-of-date page for whatsnew too?


Example links:
http://www-trunk.stage.mozilla.com/en-US/firefox/2.0.0.11/firstrun/
http://www-trunk.stage.mozilla.com/en-US/firefox/3.0.19/firstrun/
http://www-trunk.stage.mozilla.com/en-US/firefox/3.5.5/firstrun/
http://www-trunk.stage.mozilla.com/en-US/firefox/3.6/firstrun/
(In reply to comment #38)
> John, can we use this page for old whatsnew pages too?

Definitely! Good call.
This is on trunk as of r74545 and r74546

Includes firstrun and whatsnew.

Doesn't include 3.6* and 4.0*

Wrote a testcase, it's here,
http://svn.mozilla.org/projects/mozilla.com/trunk/tests/testRewrites.py

def testOutOfDate
Keywords: qawanted
r75795 on production
Status: NEW → RESOLVED
Closed: 14 years ago
Keywords: push-needed
Resolution: --- → FIXED
FYI, the whatsnew and firstrun pages bypassed by this re-write have been removed in the nova branch (r77401, r77402).
Reopening, we are still shipping 3.5.x releases. Firstrun and Whatsnew pages for en-US and locales were removed on the nova branch along with 2.0 and 3.0 pages, but not on trunk/production yet for locales.

Is it ok to tell people that will install/update to 3.5.16 this month that their version is out of date?

Beltzner or LegNeato could decide maybe?
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Assignee: abuchanan → nobody
Yeah, this is wrong. I'm pushing the pages for the beta updates now and they redirect to unsupported...I'll try to clean it up with a bandaid
Ok, I made a special exception for 3.5.19 to unblock the beta push
Component: www.mozilla.org/firefox → www.mozilla.org
Status: REOPENED → RESOLVED
Closed: 14 years ago → 12 years ago
Resolution: --- → WONTFIX
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.

Attachment

General

Creator:
Created:
Updated:
Size: