Closed Bug 611692 Opened 14 years ago Closed 14 years ago

Sort Out Mozilla.com Home / Landing Pages

Categories

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

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

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: sgarrity, Unassigned)

References

(
URL
)

Details

(Whiteboard: [redesign]) 

The current structure of mozilla.com home / Firefox-landing pages is:

1. mozilla.com main home page includes download button AND link to Firefox page(s) listed below)

2. mozilla.com/firefox redirects based on browser and version as follows:
   A. Latest version of Firefox -> /firefox/personal.html
   B. Older version of Firefox -> /firefox/upgrade.html
   C. Internet Explorer -> /firefox/ie.html
   D. Everyone else (safari, chrome, etc.) -> /firefox/firefox.html

My understanding of the organization of main Firefox/Home pages on for the new design is as follows - please correct:

• mozilla.com and mozilla.com/firefox become the same thing somehow

• No distinction is made between "Internet Explorer" and "Everyone Else" (C. and D. from the list above merge)

• There is a page for users of the latest version of Firefox (A.), but will there be a separate page for older versions of Firefox that is distinct from the page other browsers will see? So far, there is not, as far as I can tell, so out-of-date Firefox users would end up on the "everyone else" page along with IE, Safari, and everyone else.

• Are we looking to preserve existing URLs, or clean things up? Some might not really make sense anymore (like ie.html), and we can always redirect expired URLs to the new equivalent page.

Once these questions have been answered, we can work on the technical details of how we'll get people to the appropriate page(s).
Thanks for bringing this up. My answers are below, but I'm glad to continue this discussion if you think it needs to be more clear.

(In reply to comment #0)
> • mozilla.com and mozilla.com/firefox become the same thing somehow
Yes. I'm open to suggestions for the best way to do this. I can think of a few options, but we want to avoid anything that would slow down page load (like unnecessary redirects).

> • No distinction is made between "Internet Explorer" and "Everyone Else" (C.
> and D. from the list above merge)
True.
 
> • There is a page for users of the latest version of Firefox (A.), but will
> there be a separate page for older versions of Firefox that is distinct from
> the page other browsers will see? So far, there is not, as far as I can tell,
> so out-of-date Firefox users would end up on the "everyone else" page along
> with IE, Safari, and everyone else.
For the initial launch, there will be two pages only: one for people on the latest version of Firefox (whatever the most current 3.6 at the time is, plus the betas) and another for everyone else (this includes people on older Fx versions). 

After the launch, we'll segment it a little more finely to create a third page that will be for users of older Fx versions, but I think we're ok with what we have for now.
 
> • Are we looking to preserve existing URLs, or clean things up? Some might not
> really make sense anymore (like ie.html), and we can always redirect expired
> URLs to the new equivalent page.
I'd like to clean things up. Redirecting old URLs (like ie.html) to the new page(s) seems like a good plan. Again, am open to thoughts on the specifics here.
 
> Once these questions have been answered, we can work on the technical details
> of how we'll get people to the appropriate page(s).
Thanks!
I would propose the following then, 

1. mozilla.com rewrites to mozilla.com/firefox (which will eventually be mozilla.org/firefox)

2. mozilla.com/firefox becomes the default Firefox landing page (the "everyone else" version from Bug 598431)

3. Those with the latest version of Firefox (3.6.x+ for now, 4.x+ after release) that hit mozilla.com/firefox will get pushed to mozilla.com/firefox/something (suggestions welcome for the "something" part of the URL.. "thanks", "welcome", "intheknow"...).

4. /firefox/personal.html will be retired and redirect to /firefox/something (see above)

5. /firefox/upgrade.html will be retired and redirect to /firefox (for now)

6. /firefox/ie.html will be retired and redirect to /firefox

Before we get into the implementation details and any performance issues, does this make sense? Anything I'm missing?
(In reply to comment #2)
> 1. mozilla.com rewrites to mozilla.com/firefox (which will eventually be
> mozilla.org/firefox)
Agreed.

It's worth noting that firefox.com will continue routing to mozilla.com/firefox as always.
 
> 2. mozilla.com/firefox becomes the default Firefox landing page (the "everyone
> else" version from Bug 598431)
Sounds good.
 
> 3. Those with the latest version of Firefox (3.6.x+ for now, 4.x+ after
> release) that hit mozilla.com/firefox will get pushed to
> mozilla.com/firefox/something (suggestions welcome for the "something" part of
> the URL.. "thanks", "welcome", "intheknow"...).
What about mozilla.com/firefox/fx?

More thoughts on these first 3 below...
 
> 4. /firefox/personal.html will be retired and redirect to /firefox/something
> (see above)
With you all the way. 

> 5. /firefox/upgrade.html will be retired and redirect to /firefox (for now)
Yep. And, as noted in an earlier (non-bugzilla) discussion, we'll create a new /upgrade page for people running older versions of Firefox before Fx4 comes out.

> 6. /firefox/ie.html will be retired and redirect to /firefox
Right on.

> Before we get into the implementation details and any performance issues, does
> this make sense? Anything I'm missing?

This all sounds right to me, but I want to call out that we need to be keeping performance in mind here. I think this all checks out, but I'm no expert...does anyone else see any unnecessary roadblocks or redirects that might slow the normal flow of traffic to this page? The only thing I can think of is mozilla.com redirecting to mozilla.com/firefox, but that seems right to me and kind of unavoidable.

Alex, what do you think?
Some of the basics of this change are done in the nova branch in r77554.
cc'ing alex :)
> mozilla.com redirecting to mozilla.com/firefox, but that seems right to me and
> kind of unavoidable.
> 
> Alex, what do you think?

I don't like this.  You hit the front page and always get redirected.  That seems unnecessary.  Also, it adds a small performance hit, which seems avoidable.

Could we get rid of /firefox/?  Since the whole site is supposed to be about Firefox, having that in the URL seems superfluous.  And, I think (not positive) we'll have to do that anyway, when we merge with mozilla.org.

Doing so would merge the /index.html and /firefox/index.html pages, so the home page would be the main landing page.  We could make /fx/index.html the landing page for users of the latest version.


If that sounds too hairy, we could use an Apache rewrite and pass-through the /firefox/ content to the home page.  Benefit there is that there is no actual redirect, so no perf. hit and no URL change.  Disadvantage is that a search engine spider probably sees that as duplicate content under different URLs, which I hear is bad for SEO.
A few other related notes: we already do a redirect from "mozilla.com" to "www.mozilla.com" if you don't include the "www." - this is quite common as you need to have one canonical URL, but want to allow the shortcut as well.

We also push you from www.mozilla.com/ to www.mozilla.com/en-US/ - however, this switch doesn't seem to show-up in Firebug. I'm trying to figure out how it's different than the "www." redirect, as it doesn't seem to have the performance hit.

It seems the /en-US/ URL change happens in /includes/prefetch.php (see line #165: http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/includes/prefetch.php?view=markup#165 ).

Alex, know why the "www." redirect shows up with it's performance hit in the Firebug timeline, but the /en-US/ change doesn't seem to?

Also, note that the sans-"www." version of the urls is almost always used when people type it in manually. Since you automatically (and almost instantly) get the "www." added, anyone (or a search engine) looking for a URL to link to will always get the "www." version.
(In reply to comment #7)

> Alex, know why the "www." redirect shows up with it's performance hit in the
> Firebug timeline, but the /en-US/ change doesn't seem to?

Maybe your browser has it cached (although it shouldn't since it's a 302), it works for me.  I've made some webpagetest.org tests, these have waterfalls:

URL - mozilla.com (2 redirects)
http://www.webpagetest.org/result/101118_CVRR/

www.mozilla.com (1 redirect)
http://www.webpagetest.org/result/101118_CVRT/

www.mozilla.com/en-US/ (no redirects)
http://www.webpagetest.org/result/101118_CVRV/

firefox.com (4 redirects, burns over 1.5 seconds)
http://www.webpagetest.org/result/101118_CVRX/

www.firefox.com (3 redirects)
http://www.webpagetest.org/result/101118_CVSM/

www.mozilla.com/firefox/  (2 redirects)
http://www.webpagetest.org/result/101118_CVSB/

On average, looks like a redirect takes a little less than half a second (~480 ms)

I'm not sure we can (or should) do anything about the mozilla.com -> www.mozilla.com redirects.  As you mentioned, the canonical URL is good.  Also, I think this is necessary for SSL certs (I could be wrong, but I remember reading that in a bug somewhere)

We might be able to improve firefox.com and www.firefox.com, maybe even eliminate them.

The www.mozilla.com -> www.mozilla.com/en-US/ redirect is unavoidable and necessary for l10n logic.


Performance aside, redirecting every person hitting the home page to a sub-page URL (which is really just a home page under a different URL) seems messy.
FWIW: I've noticed more and more new website aren't using www in www.site.com. 

www.site.com redirects to just https://site.com. Example: Twitter. Not sure of the benefits but thought I'd mention it.
(In reply to comment #6)
> Could we get rid of /firefox/?  Since the whole site is supposed to be about
> Firefox, having that in the URL seems superfluous.  And, I think (not positive)
> we'll have to do that anyway, when we merge with mozilla.org.
> 
> Doing so would merge the /index.html and /firefox/index.html pages, so the home
> page would be the main landing page.  We could make /fx/index.html the landing
> page for users of the latest version.

That all makes sense, but there are a couple of other factors that change the equation:
1. This is clearly an issue we should talk through more, but when we merge the site over to mozilla.org, the current mozilla.org homepage isn't going to go away. We'll eventually redesign it, but that content and need to have a more broadly-focused mozilla homepage still exists. So, under that scenario, the mozilla.com/firefox content will need to live on mozilla.org/firefox, not just mozilla.org. 
2. for people coming in through firefox.com, aren't they subject to a redirect no matter what?

Would be interested to hear what Blake has to say about this, too (particularly re: comment #8).
For the record, after a phone discussion with John, Alex, Laura, and myself today, we determined that we will indeed go ahead with the mozilla.com -> mozilla.com/firefox redirect.
I think we resolved all this, so I'm closing this bug.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Keywords: qawanted
Resolution: FIXED → ---
r79330 on trunk fixed /firefox/upgrade.html redirect (it was missing)
qa-verified-trunk http://nova.stage.mozilla.com/ in IE/Chrome/Safari/Opera/Firefox
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
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.