Closed Bug 439792 Opened 16 years ago Closed 13 years ago

website needs download warning for users on de-supported o.s.

Categories

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

x86
Other
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mconnor, Assigned: alix)

References

Details

(Whiteboard: [MU+][server side])

Attachments

(2 files)

We need some sort of compat warning for 10.3 users, its becoming a user issue with SUMO...
OS X 10.3.9 users who upgrade to Firefox 3 end up with a Firefox that doesn't start.

There were about (at least) 26 questions about this[1] out of 453 forum threads today. There were also multiple live chat sessions.

[1] http://support.mozilla.com/tiki-searchindex.php?words=firefox%2Freleases+mac&where=forums&advancedfsearch=y&forumId=1&author=&daysBefore=1
What do we want the behavior to be?  If someone comes to the site with OS 9 we just say "not compatible."

Seems like we should offer FF2 for this.  If we do, the page will still have FF3 graphics/labels, only the button would change to say 2.0.0.x.  If you want a warning, what do you want it to say?
I'd suggest we say that the latest version isn't compatible and 10.3, and point them to http://www.mozilla.com/en-US/firefox/all-older.html for Firefox 2.
Offering Fx2 for <10.4 visitors sounds like a good idea, but we also need a notification explaining why we aren't offering Fx3 (because the minimum requirement is Mac OS X 10.4). Maybe something like 

"Firefox 3 requires Mac OS X 10.4 or later. You are running an older version of Mac OS X and cannot install Firefox 3."

Fwiw, we've added this to the front page of SUMO, and also updated the Upgrading to Firefox 3 article to reflect this.
I think Steven and David are on the right track. If I may, I'd suggest combining their comments to make the notification read like this:

"Firefox 3 requires Mac OS X 10.4 or later. Because you are running an older version of Mac OS X, we suggest downloading the latest version of Firefox 2 instead."

If that sounds good, can we go ahead and add this to the site?
Sounds good to me!
After looking into this, at appears that Safari reports the OS X version in the user.agent string, but Firefox 2 doesn't. I was only only able to test on OS X 10.5 and 10.4 though, which isn't too helpful.

CC'ing Stephen Donner in the hopes that he has access to OS X 10.3 to test. Stephen, I'm looking for the results of running this in your location bar:

javascript:alert(navigator.userAgent)
Talked to Steven online who is looking at this.  Thanks Steven!
Assignee: clouserw → steven
reed reports that pre Firefox 3, we have no way of knowing the OS version #. We might be stuck on that. We could check for those running safari, but that won't be any help to Firefox 2 users.
we can detect that they're on OS X though, right?  If so can we just add it to the page when OS X is detected?
Then we should do it for safari in the short term, like, tonight.

Beyond that, we should be able to steal the string from the system-requirements page and modify the frontpage for OS X users.  (Pascal, can you pull the relevant strings from the web locales?)  This is causing a pretty crappy experience for 10.3 users, with no useful warning/feedback, it just looks like its crashing.  The longer we wait to get this, the more users get the shaft...
Sorry if this is a stupid question, but where on the site are we going to put this warning?
right under the download button would be awesome
The only potential problems with that are a) there are multiple download buttons and the placements are a little different on every page and b) the pages weren't really designed with that much extra text in mind.

Obviously the best long term solution would be to detect who has the old OS and only show the warning to those users, but since we need a short term fix, what if we changed the text on the button to read "3.0 for Mac OS X 10.4 and above" and then included a system requirements link next to the small release notes and other languages links below the buttons?

In the short term, at least, that would seem to cover the major bases here without breaking up the page or, more importantly, potentially confusing the Mac users who have the correct OS.

Thoughts?
There's no long term way to detect the OS, Firefox 2 doesn't provide it, if I understand it correctly.

Whatever text is used needs to be a string that's already localized for it to be short term.

"Mac OS X 10.4 and later" is a bullet point on the system requirements page and should be usable.

users on <10.4 are basically having their Firefox DoS'ed by *us*. There's no indication at any point in the install that it won't work for them, until Firefox 3 refuses to open. Obviously I think it's more important to head that off in the short term than to worry about the site design in the short term.  Long term we can figure out a solution that looks best.
I'm not just worried about the site design here...I think there's also the issue of being sensitive to the fact that this warning won't be relevant to a large number of people who visit the page and could wind up confusing them or erroneously convincing them not to download if we don't do it right.

I totally agree that this is important and should be fixed asap...I just want to do it in the the way that works the best for the most possible people.

Anyway, I don't really think we're disagreeing here in any substantial fashion. So...next steps? Steven, what do you think?
It sounds to me like there is agreement here, except for changing John's suggestion from "3.0 for Mac OS X 10.4 and above" to "3.0 for Mac Os X 10.4 and later" (which basically means "3.0 for %alreadyLocalizedBulletPoint").

My recommendation is that we go ahead with that change now.
I'm not sure if this is what people are already suggesting or not, but we already say "3.0 for Mac OS X" on the download button. We can change that to "3.0 for Mac OS X 10.4 and later" and it still fits fine. Screenshot attached.

This works ok for the other format download buttons as well.

The only complication I can see is that the everywhere but the en-US Firefox and Home pages, this "Mac OS X" string is shared between Firefox and Thunderbird - so we might have to update the product-details scripts. Wil?
Yep, that's what we were suggesting. Let's do it! (pending Wil's response to comment #18, that is)
We could stick a picture into the DMG so that once it's downloaded people see a note that it requires 10.4/10.5.

That'd hopefully prevent people who skip our download pages from trashing FF2.
Changing it on en-US involves changing each of the pages the download exists on.  There is no localization here; let's do it.

Changing it on not-en-US involves changing the product-details library or individual pages.  It's a slightly different format though:
 
   Mac OS X (3.0, Português (do Brasil), 17MB)
Perhaps we should also add a note on the "download/thank-you" page. We're already doing browser sniffing there.
(In reply to comment #18)
> Created an attachment (id=325751) [details]
> Screenshot of download button with Mac OS version
> 
> I'm not sure if this is what people are already suggesting or not, but we
> already say "3.0 for Mac OS X" on the download button. We can change that to
> "3.0 for Mac OS X 10.4 and later" and it still fits fine. Screenshot attached.
> 
> This works ok for the other format download buttons as well.
> 
> The only complication I can see is that the everywhere but the en-US Firefox
> and Home pages, this "Mac OS X" string is shared between Firefox and
> Thunderbird - so we might have to update the product-details scripts. Wil?
> 

I'm concerned this won't be visible enough.  Anywhere else we can put the warning in larger terms would be great (like the download page).  I can report back if we're still getting too many people with this problem hitting support after the change is live.
r16063 adds the "Mac OS X 10.4 and above" to the download button on the en-US home page and Firefox pages. It's a start...
This is great, thanks Steven. Let's see what happens with this and then we can continue to make further refinements and/or additions depending on what happens.
I'm not sure about the state of getting stuff to production right now. Wil, is Kubla safe to use yet?
(In reply to comment #26)
> I'm not sure about the state of getting stuff to production right now. Wil, is
> Kubla safe to use yet?
> 

You can merge between branches with it but the sites aren't going to update automatically.  Also it seems to be substantially slower with all the new FF3 files in the tree so that annoying red box at the top of the queues takes longer to go away.
(In reply to comment #26)
> I'm not sure about the state of getting stuff to production right now. Wil, is
> Kubla safe to use yet?

Kubla was never down. The auto-update was turned off, but it's working now.
(In reply to comment #28)
> (In reply to comment #26)
> > I'm not sure about the state of getting stuff to production right now. Wil, is
> > Kubla safe to use yet?
> 
> Kubla was never down. The auto-update was turned off, but it's working now.
> 

When was this turned back on?

I'm pretty sure the timings of the cron jobs will need to be adjusted because updates are taking longer with the additional files and it's going to trip over itself.
In that case, John, this change is now on stage and ready for you to push to production (two files: en-US/index.html and en-US/firefox/index.html)
Ok, this is live on the site now.
(In reply to comment #20)
> We could stick a picture into the DMG so that once it's downloaded people see a
> note that it requires 10.4/10.5.
> 
> That'd hopefully prevent people who skip our download pages from trashing FF2.

Good idea, this would require another bug, though, and could only be made part of a 3.0.1 release.

We should also add a link on the download page to all-older.html for OSX users *only*.
(In reply to comment #32)
> We should also add a link on the download page to all-older.html for OSX users
> *only*.

Mike, do you mean the download-thank-you page, the one with the instructions, or pages with a download link/button? If you can clarify and provide the text, I'll add this note/link.
Thanks to bkrausz I have some stats for the number of people who clicked on the link we have on the start page of sumo for people ("click paths" in urchin) having this problem:

6/18: 1731
6/19: 1011
6/20:  167
6/21:  173

There's a huge drop the day after the change was made, but of course the timing probably coincides with a drop in the downloads. Someone should compare the mac downloads for those dates so we can see how big the drop is relatively.
(In reply to comment #34)
> Thanks to bkrausz I have some stats for the number of people who clicked on the
> link we have on the start page of sumo for people

Do you mean the "Firefox 3 will not start on Mac OS X 10.3.9" link?

> ("click paths" in urchin)
> having this problem:
> 
> 6/18: 1731
> 6/19: 1011
> 6/20:  167
> 6/21:  173

How was this calculated? I don't see the same stats.
I took the "click paths" from urchin and pulled out anything that went from some homepage directly to the "firefox will not start" page (since the only link to that page is that link, we can assume that most, if not all, of the users clicked that link).  I only did this for paths with >= 10 sessions since it was a lot of data to parse through (/, /en-US/kb/, /en-US/kb/Firefox+Support+Home+Page, etc, are all valid home page URLs).
updated whiteboard during triage meeting.
Summary: need warning for 10.3. users → need warning for OSX10.3 users
Whiteboard: [MU+]
Summary: need warning for OSX10.3 users → need warning for OS X 10.3 users
summary adjusted to avoid confusion with bug#442408.
Summary: need warning for OS X 10.3 users → website needs download warning for OS X 10.3 users
Steven, any update here?
(In reply to comment #39)
> Steven, any update here?
I'm not really sure what the next step is. I didn't realize it was waiting on me. Anyone?
Do we have any updated stats from SUMO on this? If the trend from comment #33 is continuing maybe this one is already fixed.
Whiteboard: [MU+] → [MU+][server side]
Can a SUMO person chime in here? We need to know if there's more we should do asap.
Brian or Lucy, can you run some stats again on this?
Should we also do website warnings for other o.s. that have been de-supported, like win95, win98, winME?
(In reply to comment #42)
> Can a SUMO person chime in here? We need to know if there's more we should do
> asap.
> 

Back from vacation.. I re-ran Brian's stats on click paths to the "Firefox will not start" article from the start page to verify that the trend from comment 34 is continuing. To save some time, I only looked at the click path from /en-US/kb/Firefox+Support+Home+Page -> /en-US/kb/Firefox+will+not+start, but the numbers should still give a pretty accurate picture, as en-US is the majority of our traffic. I also included the total sessions for these sample days, to show that the click path ratio is in fact declining:

6/18: 263 (372k sessions)
6/19: 160 (289k)
6/20: 51 (190k)
6/21: 47 (170k)
6/22: 55 (199k)
6/23: 55 (221k)
7/7: 26 (212k)
7/21: 24 (228k)
8/4: 15 (228k)
8/17: 18 (209k)

So, assuming Urchin is accurate, the trend is continuing and the problem seems to have been solved. 

John raises a good point about the other unsupported OSes, although I think the low traffic from such OSes wouldn't warrant the effort unless it's a really quick fix.
(In reply to comment #44)
> Should we also do website warnings for other o.s. that have been de-supported,
> like win95, win98, winME?

Mac was the most important because you would end up trashing your old Firefox by installing the new one. On Windows, the installer stops you, so all the user ends up doing is wasting time and bandwidth.
That doesn't mean we shouldn't try to reduce that type of user frustration.  Just because one is worse doesn't mean we shouldn't work on the other cases.  Especially since we have a lot more users on old Windows versions than on old Mac versions.

We want that anyway for when we start promoting the major update, which is _soon_
Summary updated.

Do we have a list of what o.s. were supported in FF2, but desupported in FF3? 
Summary: website needs download warning for OS X 10.3 users → website needs download warning for users on de-supported o.s.
off the top of my head, for officially supported OSes:

Windows 95
Windows 98
Windows ME
Windows NT 4.0
(In reply to comment #45)

>  I also included the total sessions for these sample
> days, to show that the click path ratio is in fact declining:
> 
> 6/18: 263 (372k sessions)
> 6/19: 160 (289k)
> 6/20: 51 (190k)
> 6/21: 47 (170k)
> 6/22: 55 (199k)
> 6/23: 55 (221k)
> 7/7: 26 (212k)
> 7/21: 24 (228k)
> 8/4: 15 (228k)
> 8/17: 18 (209k)
> 
> So, assuming Urchin is accurate, the trend is continuing and the problem seems
> to have been solved. 
> 

We need to compare these stats against the download trend to know if we've been solving the problem or not and how well.  If these numbers are tapering off in close relation to the downloads tapering off since release then we haven't solved much.  We also don't know what percentage of users who have this problem actually find us.
It may not be the best solution, but this patch uses java.lang.System.getProperty('os.version') to determine the OS version and then displays the 'fxold' version number if the OS version is not compatible with Firefox 3. This patch takes into account both Mac OS X (< 10.4; before Tiger) and Windows (< 5; before Windows 2000). If Java happens to not be installed, it falls back to the temporary hack already in place.

These URLs provide some background:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System.html#getProperties%28%29
http://lopica.sourceforge.net/os.html
Attachment #361139 - Flags: review?
I don't think we can use Java here. If it has to initialize, that's a long time for you to assume the user is on the page (or for you to keep the user on the page)... at least on Mac.
Perhaps. The problem with testing it is that once it initializes the first time, it doesn't take as long for the subsequent requests (including refreshing the page and whatnot), at least in my experience.
We're now addressing the unsupported systems AFTER the download button is clicked (see bug 482230).

I suppose we can assume that this bug addresses the experience BEFORE the button is clicked.

Really, if we're detecting Win98 on the page AFTER the button is clicked, it begs the question, should we give them a button to click in the first place? Probably not.

That said, we must always provide a manual over-ride to download anyhow, even if the client is identified as unsupported (maybe our detection has failed, maybe they want to download to disk for another system, etc.).

Re-assigning to Alix to help determine what this behaviour should be.
Assignee: steven → afranquet
How about checking the WebKit version to detect the Mac OS X version?
http://en.wikipedia.org/wiki/Safari_(web_browser)#Mac

if (preg_match("/AppleWebKit\/([\d\.]+)/", $_SERVER["HTTP_USER_AGENT"], $matches) && intval($matches[1]) < 100) {
  // Safari 1.0.x (Mac OS X v10.2.x) and below
}
I meant to say:

if (preg_match("/AppleWebKit\/([\d\.]+)/", $_SERVER["HTTP_USER_AGENT"], $matches) && intval($matches[1]) < 412) {
  // Safari 1.x (Mac OS X v10.3.x) and below
}
(In reply to comment #57)
> I meant to say:
> 
> if (preg_match("/AppleWebKit\/([\d\.]+)/", $_SERVER["HTTP_USER_AGENT"],
> $matches) && intval($matches[1]) < 412) {
>   // Safari 1.x (Mac OS X v10.3.x) and below
> }

But that doesn't catch anyone using Firefox on 10.3.x and earlier.
(In reply to comment #58)
> But that doesn't catch anyone using Firefox on 10.3.x and earlier.

No, but this doesn't have to be an all-or-nothing catch. If we *can* identify the system as un-supported, we can follow one path, and if we can't identify it, we can follow another.

Kohei, I presume this means that version "412" is the version that shipped with 10.4? There were no updates to this version for 10.3, where there?
This was fixed with Bug 643872.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
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.

Attachment

General

Created:
Updated:
Size: