Closed Bug 670114 Opened 13 years ago Closed 13 years ago

[One Mozilla] Fix conflicting URLs for mozilla.com/.org merge

Categories

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

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

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jlong, Assigned: jlong)

References

Details

Having built a prototype of the merged mozilla.com/.org, I discovered a few URLs that do different things. We need to decide what should exist at these URLs.

The full list of top-level folder of mozilla.org is at http://etherpad.mozilla.com:9000/mozmerge.

The conflicting folders are:

* /about

mozilla.com and mozilla.org each have a lot under the /about URL, including several subsections.

* /support

mozilla.com/support redirects to sumo, while mozilla.org/support has its own page.
No longer depends on: 630967
Blocks: 670115
No longer blocks: 670115
Blocks: 670118
No longer blocks: 670118
Blocks: 670119
No longer blocks: 670119
(In reply to comment #0)
> The conflicting folders are:
> 
> * /about

IIRC, one option that has been discussed for the short-term is to have mozilla.com/about move to mozilla.org/firefox/about so we can sort out the content overlap without this being a blocker.

> * /support
> 
> mozilla.com/support redirects to sumo, while mozilla.org/support has its own
> page.

CC'ing cilias who owns the /support pages on mozilla.org.

IMO, ideally we wouldn't need the content at mozilla.org/support and people could go to SUMO and find support for other apps as needed.  Just like people can go to AMO today and use the nav there to navigate to add-ons for other apps.  Not sure how feasible that is in the short-term.
Summary: Fix conflicting URLs for mozilla.com/.org merge → [One Mozilla] Fix conflicting URLs for mozilla.com/.org merge
Let me talk to djst and rtanglao about the support pages.
For clarification, is this about where to point mozilla.com/support/ ? Is there something wrong with keeping the current redirect to support.mozilla.com? (short-term)
Hey Chris, the problem is that mozilla.org/support has content already (with lots of subsections). So when we merge mozilla.com and mozilla.org, we need to decide what is served up at the /support URL (is it just the redirect? what happens to the .org content?)
It would nice to have more info, like when a user goes to www.mozilla.org/firefox/ and clicks on a support link in a site menu (I presume that's how it's going to work), do you want to take them to www.mozilla.org/support/ or can that link be customized on the product page? (eg. "Support" on Firefox page can point to support.mozilla.com, and "Support" on Thunderbird page can point to support.mozillamessaging.com)
I haven't seen an answer to comment 5. I don't want my work to be holding up progress.
For the sake of simplicity, let's assume clicking on links takes you wherever it currently takes you. So if there's a link to "/support" anywhere on the site, this is still where it will point. This reduces this question to: "When a user visits mozilla.org/support, what will they see?" Hope this helps.
The other, perhaps obvious, conflicting URL is "/", the front page. What do we serve up there, and how do people reach the other former front page?
(In reply to comment #8)
> The other, perhaps obvious, conflicting URL is "/", the front page. What do
> we serve up there, and how do people reach the other former front page?

The front page isn't a conflict.  The existing www.mozilla.org home page should continue to remain at www.mozilla.org (and it will be redesigned soon to look like part of the rest of the combined site).  Any traffic currently going to mozilla.com should go to mozilla.org/firefox.
That sounds like a good decision, thanks David!
The above thread sounds right to me, but I'll go through this a little more closely with Chrissie tomorrow and will post any further thoughts.

Thanks all!
Hi all. I just had a good chat with James that helped me understand the nuances with all this, so here's my proposal:

- as a baseline, let's proceed with the plan of turning all the mozilla.com URLs into mozila.org ones (as in, mozilla.com/firefox/fx becomes mozilla.org/firefox/fx). This seems to be in line with Fred's comment #7 above (which seems very reasonable to me).

- *but*, in the case of certain conflicting URLs (/support and /about come to mind, although there may be others), we should go an extra step and move mozilla.com/support to mozilla.com/firefox/support to avoid overlap. The key thing here is finding all those conflicting URLs soon (duh).

- also, +1 for what David wrote in comment #9.

Next steps:
- does this make sense to everyone? If not, please let me know and we can discuss.
- are there any other URL conflicts beside the ones in comment #0?
URL Conflicts:

*404.html
*about/index.html
*legal/eula/index.html


Possible URL/Directory/File Conflicts:

http://www.mozilla.org/privacy/#policies v. http://www.mozilla.com/en-US/privacy-policy.html

/security
/script
/style
/support

.htaccess
> Possible URL/Directory/File Conflicts:
> 
> http://www.mozilla.org/privacy/#policies v.
> http://www.mozilla.com/en-US/privacy-policy.html
> 
> /security
> /script
> /style
> /support

/support is definitely a conflict and this is something that cilias or someone on the Support team should make a call about.

Is /security a conflict?  I'm not seeing anything at www.mozilla.com/security.
Thanks Chrissie. My thoughts are inline below...would welcome any questions, comments or feedback.

> *404.html
We launched a pretty awesome 404 page for mozilla.com recently, so I don't want to lose it in the merge. However, it's also pretty specific to mozilla.com (uses the design style of that site, has a Fx download button). I think our two best options are here are:
1) have a separate 404 page for the Firefox pages and the rest of mozilla.org. This would be a temporary solution...when we redesign mozilla.org later this year we could update the 404 page to use the same one across the whole site.
2) bite the bullet and use the mozilla.com 404 page across the whole site right now. Might be a little confusing for some, but it's still a good page.

What do you guys think? My vote would be for #1.

> *about/index.html
We should definitely move the mozilla.com pages to mozilla.com/firefox/about - again, we'll eventually need to consolidate these better as we continue to smooth out the site, but for this first phase we need to keep both the mozilla.org and mozilla.com about pages around, as they each contain very important content.

> *legal/eula/index.html
Let's keep them separate for now (moving the mozilla.com one into mozilla.org/firefox as suggested in comment #12) and then fix during the redesign.
 
> http://www.mozilla.org/privacy/#policies v.
> http://www.mozilla.com/en-US/privacy-policy.html
Same answer as the EULA one.
 
> /security
Ditto what D-Bos said...mozilla.com/security seems to redirect to mozilla.org/security already.

> /script
I get a 404 for this page at .org and .com.

> /style
I get a 404 for this page at .org and .com.

> /support
Definitely an important one. I'd welcome input from SUMO on this. My recommendation would be to optimize for users looking for customer support...we could always move the "get involved with Firefox support" content currently at mozilla.org/support to our http://www.mozilla.org/contribute/areas.html page.

SUMO team, what's your recommendation?
 
> .htaccess
No idea on this one...I think James or Steven needs to make a call here.
/script and /style aren't pages, they're directories that hold JavaScript and CSS, respectively.
(In reply to comment #16)
> /script and /style aren't pages, they're directories that hold JavaScript
> and CSS, respectively.

Ok, then would like input from James or Steven on these as well.
Re 404 pages, it looks like Thunderbird also has their own:

http://www.mozilla.org/en-US/thunderbird/foo

Long-term definitely makes sense to have on for the whole site.  Not sure how feasible it is to keep 3 separate ones short-term.

Re about, definitely agree.

Re script, style and .htaccess, these are all technical and I think James has a way to deal with the conflicts based on comments I've seen elsewhere (although I may be wrong).

Re support, the problem is how to give people pointers to get support for other apps.  I think the best solution is to do what AMO does and give people a way to select other apps from the site, but serve Firefox by default.  So that would just be adding the application picker to the SUMO header since that's all that mozilla.org/support is -- a way to pick support links to other apps.  Adding it to the Areas of Interest isn't quite the right fit, since that's for people who want to get involved in providing support vs. receiving support for a problem.
(In reply to comment #13)
> Possible URL/Directory/File Conflicts:
> http://www.mozilla.org/privacy/#policies v.
> http://www.mozilla.com/en-US/privacy-policy.html

We're also working on a new Privacy home page for mozilla.com that I had been thinking could live at mozilla.com/privacy (pre-merge). I suspect it would serve as a good replacement for what is currently at mozilla.org/privacy. See: https://bugzilla.mozilla.org/show_bug.cgi?id=650430#c52
If I'm reading correctly, it sounds like the key open issue still remaining is what to do with the support pages. I've emailed Tenser (who is out of town until Monday) and the rest of the SUMO team to weigh in here...I'm not comfortable making a call on this without their input.

(In reply to comment #19)
> (In reply to comment #13)
> > Possible URL/Directory/File Conflicts:
> > http://www.mozilla.org/privacy/#policies v.
> > http://www.mozilla.com/en-US/privacy-policy.html
> 
> We're also working on a new Privacy home page for mozilla.com that I had
> been thinking could live at mozilla.com/privacy (pre-merge). I suspect it
> would serve as a good replacement for what is currently at
> mozilla.org/privacy. See:
> https://bugzilla.mozilla.org/show_bug.cgi?id=650430#c52

Good thought - let me check in with Alex on that.
(In reply to comment #14)
> /support is definitely a conflict and this is something that cilias or
> someone on the Support team should make a call about.

I thought I did in comment 5. :-\
In any case, since then support.mozilla.com has changed to a new banner, which includes a link to Thunderbird support.

FWIW, there is no /support/ directory in the www.mozilla.com repository. The htaccess file redirects that URL to support.mozilla.com.

I also had a look at http://www.mozilla.org/thunderbird/ and saw that it has a support link to support.mozillamessaging.com, which is what I was talking about in comment 5.

So...
Point mozilla.org/support/ so support.mozilla.com
Regarding /support

This page (www.mozilla.org/support) sent 2000 visitors to SUMO last month. That represents nothing with the 9M visitors a month.

In the case of Thunderbird is 685 out of 470k.

Looking into the Org page itself. They are 2 versions (http://ww.mozilla.org/support and support/index2) but they seem to be the same so I'm aggregating numbers here:

- 18k pageviews (ergo 15% use it as a gate to Thunderbird and SUMO support)
- 75% bounce rate. So only 1800 users stay at www.mozilla.org after visiting this page.
- 159 page views ended up in "Get involved". This is less than 1% of the visitors. And the "Get involved page" gets 220k visitors a month. So the weight of this page on these visitors is far from being significant. (Less than a 0.1%).

My opinion, kill the page, use SUMO (support.mozilla.com) as it is today and let's work with Roland on increasing Thunderbird's visibility in SUMO itself (something that we are already doing with the new header btw).
On SUMO we already feature links to Firefox, Firefox Mobile and Thunderbird, so there should be no problem to replace /support with the SUMO startpage. 

But on support.mozilla.org/support there are also links to Seamonkey, Camino, Sunbird and Bugzilla. If we put the SUMO startpage in that place, we need to decide whether Seamonkey, Camino, Sunbird and Bugzilla need another place where we link to their support sites or whether we drop those links. That is a decision we from the SUMO team can't make.
Thanks SUMO team for the input. I think Ibai makes some great points about the stats in comment #22, but the central issue is what Kadir mentioned in comment #23:

Right now mozilla.org/support has links to support pages of a number of other products besides Fx and Tb. If we redirect mozilla.org/support to SUMO (which seems like the thing to do based on the numbers), what do we do about those links? It would be bad to lose them altogether.

Also, cilias, the 'support' link in the header of the Fx and Tb sites will definitely continue to point to the relevant SUMO pages. Hope that answers your earlier question.
(In reply to Chris Ilias [:cilias] from comment #21)
> So...
> Point mozilla.org/support/ to support.mozilla.com

That's fine with me.  If we agree on this, I can remove the pages and set up the redirect.
One other thought about comment #25, we should also have support.mozilla.org redirect directly to support.mozilla.com instead of it going to mozilla.org/support and then to support.mozilla.com.
Even if they exists...the traffic they handle is close to none.

You could argue that they create awareness, and that's probably true. But we could also create awareness in other sites with more visibility. (This is just an opinion).

The truth is that as Kadir mentions in comment #23 the ones that should decide about it are the owners of the different landing pages but:

- 190 visits/month for others
- 161 visits/month for Sunbird
- 82 visits/month for Bugzilla
- 17 visits/month for Seamonkey
- 3 visits/month for Camino.

They are 453 visits a month.

Searching for "keyword" + help in Google doesn't show this page in the first 10 results for any of them.

In the case of Sunbird (where the FAQs are hosted in our domains and we can check the total data), 161 are just a drop in the 13800 pageviews (the majority generated from the product page). It's just a 1%.

A basic SEO improvement will help this pages more than using SUMO to promote them. 

A simple solution would be to create an FAQ with the pointers in SUMO.
Thanks guys. Tell me if this solution sounds doable:

- when we merge the sites, we replace mozilla.org/support with mozilla.com/support, effectively meaning that typing in either of those links will redirect you to SUMO.
- the SUMO team can add a FAQ or drop-down (or whatever you guys think is best) somewhere on the site with information about how to get support for Sunbird, Camino, etc. That ought to more than make up the difference for the lost traffic.
- we implement the redirect in the way David suggested in comment #26.

Any objections? Does anyone else need to review this? I want to make sure it's properly socialized, but since the traffic is pretty small (per comment #27) I don't want to over-rotate on it either.
(In reply to John Slater from comment #28)
> Thanks guys. Tell me if this solution sounds doable:
> 
> - when we merge the sites, we replace mozilla.org/support with
> mozilla.com/support, effectively meaning that typing in either of those
> links will redirect you to SUMO.
> - the SUMO team can add a FAQ or drop-down (or whatever you guys think is
> best) somewhere on the site with information about how to get support for
> Sunbird, Camino, etc. That ought to more than make up the difference for the
> lost traffic.
> - we implement the redirect in the way David suggested in comment #26.

That sounds right to me.
(In reply to John Slater from comment #28)
> - when we merge the sites, we replace mozilla.org/support with
> mozilla.com/support, effectively meaning that typing in either of those
> links will redirect you to SUMO.

To avoid any confusion, this would also include making sure that support.mozilla.com and support.mozilla.org go to the same place.  Once all of those URLs point to the same place, that would then remove a blocker for the long-term goal of having SUMO be served from the mozilla.org domain.

I opened bug 676867 to track removing and redirecting the /support pages on www.mozilla.org.
(In reply to John Slater from comment #17)
> (In reply to comment #16)
> > /script and /style aren't pages, they're directories that hold JavaScript
> > and CSS, respectively.
> 
> Ok, then would like input from James or Steven on these as well.

I meant to respond to this earlier. We've already fixed those conflicts, as that was required to get any of the site up and running. So don't worry about any of the static media folders.

Also, about the 404 pages, we can support all 3 of them. The thunderbird 404 page works already (http://www-dev.allizom.org/en-US/thunderbird/404).  I specifically wrote the code which pulls in the mozilla.com 404 page on a mozilla.org 404. But I can change that.
(In reply to John Slater from comment #28)
> Thanks guys. Tell me if this solution sounds doable:
> 
> - when we merge the sites, we replace mozilla.org/support with
> mozilla.com/support, effectively meaning that typing in either of those
> links will redirect you to SUMO.
> - the SUMO team can add a FAQ or drop-down (or whatever you guys think is
> best) somewhere on the site with information about how to get support for
> Sunbird, Camino, etc. That ought to more than make up the difference for the
> lost traffic.
> - we implement the redirect in the way David suggested in comment #26.
> 
> Any objections? Does anyone else need to review this? I want to make sure
> it's properly socialized, but since the traffic is pretty small (per comment
> #27) I don't want to over-rotate on it either.

Cc'ing James Socol, our lead SUMO dev. No objections from me though.
As I understand this, we're taking an "all roads lead to SUMO" approach, right? m.c/support, m.o/support and whichever of support.m.c or support.m.o isn't currently in use will just redirect directly to the site.

That all works for me, none of it is really work for my team at this point.
(In reply to James Socol [:jsocol, :james] from comment #33)
> That all works for me, none of it is really work for my team at this point.

Great, that's what I was hoping you'd say, too. :) Thanks!
Thanks to everyone from SUMO who weighed in. Let's go with the plan outlined in comment #28 then.
Last thing on this James:

This About page http://www.mozilla.com/about/ should become http://www.mozilla.org/firefox/about/

Mozilla.org will continue to use it's About page. 

Then we can close this bug up!
Assignee: nobody → jlong
Target Milestone: --- → 3.7
fixed all of this in r94253

http://www-dev.allizom.com/support/
http://www-dev.allizom.com/firefox/about/
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.