Websites/Taskforce/Proposals/Domain Name Strategy: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 37: Line 37:
=="One Mozilla" Strategy==
=="One Mozilla" Strategy==


I (Janet) propose the following principles for structuring URLs for the "one Mozilla" strategy:
We propose the following principles for structuring URLs as part of a "One Mozilla" strategy.


* Use ''subdirectories'' for product-specific sub-sites.  
Short version: Use sub-domains for functional areas and sub-directories for products and programs (programs in the initiative sense and not applications) with some exceptions.
** E.g., product portals: mozilla.org/firefox, mozilla.org/thunderbird, mozilla.org/seamonkey
 
* Use ''subdomains'' for functional areas or efforts that cut across products, or embrace the broader Mozilla mission.  
The following breaks out how this applies to different types of sites.
** E.g., addons.mozilla.org, developer.mozilla.org, drumbeat.mozilla.org
 
* Use subdirectories with subdomains for product-specific sites only as it makes sense based on content.
===Products and Programs===
** E.g., support.mozilla.org/firefox and support.mozilla.org/thunderbird, but developer.mozilla.org (no subdir)
 
* Use protocol-named subdomains only for non-web servers (irc, ftp). I.e., drop 'www'. Protocol names, when used, should be the first element in a domain name.
Sites related to the major activities backed by Mozilla organizations should use sub-directories on mozilla.org to appear to be part of the top-level mozilla.org site.
 
Examples:
 
* www.mozilla.org/firefox
* www.mozilla.org/thunderbird
* www.mozilla.org/drumbeat
 
Note: Other community-backed projects such as seamonkey-project.org can show affiliation with Mozilla on their site in a number of other ways without having to change their URL structure.
 
===Product Services===
 
Sites that exist to host services related to our products and programs should have sub-domains based on site content and sub-directories based on products or program with Firefox content being the default (this is the existing addons.mozilla.org model).
 
Examples:
 
* addons.mozilla.org, addons.mozilla.org/mobile, addons.mozilla.org/thunderbird, etc.
 
* support.mozilla.org, support.mozilla.org/mobile, support.mozilla.org/thunderbird, etc.
 
* nightly.mozilla.org, nightly.mozilla.org/mobile, nightly.mozilla.org/thunderbird, etc.
 
To help with discoverability and consistency each of these sites should have the same 'Other Application' widget in roughly the same location.
 
===Community-wide Sites===
 
Sites that exist to serve Mozilla as a whole and not any particular product or program should simply use a mozilla.org sub-domain.
 
Examples:
 
* air.mozilla.org
* developer.mozilla.org
* feeds.mozilla.org
 
===Campaign Sites===
 
Mini-sites set up for a specific campaign should be able to use whatever URL makes sense.  Because these sites are usually relevant to a specific time, an archiving plan should be put in place so this content isn't abandoned.
 
Examples:
 
* firefoxflicks.com
* opentochoice.org
* operationfirefox.com
 
This also includes URLs that are used for redirects to other sites, such as getfirefox.com, firefox.com or firefoxcup.com.  Note how firefoxcup.com now points to a blog post wrapping up the campaign.
 
===Local Sites===
 
There are two main URL styles being used today by local sites.
 
Examples:
 
* mozilla.country: mozilla.jp, mozilla.ro, etc.
* mozilla-country.org: mozilla-mexico.org, mozilla-russia.org, etc.
 
There are also a variety of other URLs in use such as bgzilla.org and mozilla.org.ua.  It may make sense to make these more consistent, but there is no plan to do that now.


==Proposed URL Changes==
==Proposed URL Changes==

Revision as of 17:47, 2 September 2010

Domain Name Strategy

Working Group

John Slater, Janet Swisher, and David Boswell

Problem

We are currently using our organizational structure as a way to set up domain names and this is presenting irrelevant information to people and diverting our message away from more important things, such as what we do and why we do it.

For example, the following are some of the organizational domains currently in use:

  • mozilla.com
  • mozillamessaging.com
  • mozilla-europe.org

Note that mozilla.org is not an organizational domain -- it is the community's domain that was set up and used long before there was any Mozilla organization. It isn't the Foundation's organizational domain -- that is mozillafoundation.org that was in use briefly but has been retired.

Solution

To be able to stop using organizations as a basis for our domain name strategy, we need to develop an alternate domain name strategy that uses something other than organizations for its structure. There seem to be two main options:

  • Structure a strategy based on product/activity: firefox.com, thunderbird.com, drumbeat.org, etc.
  • Structure a strategy based on the idea that the universe is all one big Mozilla site: mozilla.org/firefox, mozilla.org/thunderbird, mozilla.org/drumbeat, etc.

Both options have advantages and disadvantages, so there should be some discussion. We can also learn by doing. We propose taking some of the sites currently in the Firefox hub and changing them as needed to learn what works and what doesn't. That can then be a model for dealing with other organization-based domains.

"One Mozilla" Strategy

We propose the following principles for structuring URLs as part of a "One Mozilla" strategy.

Short version: Use sub-domains for functional areas and sub-directories for products and programs (programs in the initiative sense and not applications) with some exceptions.

The following breaks out how this applies to different types of sites.

Products and Programs

Sites related to the major activities backed by Mozilla organizations should use sub-directories on mozilla.org to appear to be part of the top-level mozilla.org site.

Examples:

  • www.mozilla.org/firefox
  • www.mozilla.org/thunderbird
  • www.mozilla.org/drumbeat

Note: Other community-backed projects such as seamonkey-project.org can show affiliation with Mozilla on their site in a number of other ways without having to change their URL structure.

Product Services

Sites that exist to host services related to our products and programs should have sub-domains based on site content and sub-directories based on products or program with Firefox content being the default (this is the existing addons.mozilla.org model).

Examples:

  • addons.mozilla.org, addons.mozilla.org/mobile, addons.mozilla.org/thunderbird, etc.
  • support.mozilla.org, support.mozilla.org/mobile, support.mozilla.org/thunderbird, etc.
  • nightly.mozilla.org, nightly.mozilla.org/mobile, nightly.mozilla.org/thunderbird, etc.

To help with discoverability and consistency each of these sites should have the same 'Other Application' widget in roughly the same location.

Community-wide Sites

Sites that exist to serve Mozilla as a whole and not any particular product or program should simply use a mozilla.org sub-domain.

Examples:

  • air.mozilla.org
  • developer.mozilla.org
  • feeds.mozilla.org

Campaign Sites

Mini-sites set up for a specific campaign should be able to use whatever URL makes sense. Because these sites are usually relevant to a specific time, an archiving plan should be put in place so this content isn't abandoned.

Examples:

  • firefoxflicks.com
  • opentochoice.org
  • operationfirefox.com

This also includes URLs that are used for redirects to other sites, such as getfirefox.com, firefox.com or firefoxcup.com. Note how firefoxcup.com now points to a blog post wrapping up the campaign.

Local Sites

There are two main URL styles being used today by local sites.

Examples:

  • mozilla.country: mozilla.jp, mozilla.ro, etc.
  • mozilla-country.org: mozilla-mexico.org, mozilla-russia.org, etc.

There are also a variety of other URLs in use such as bgzilla.org and mozilla.org.ua. It may make sense to make these more consistent, but there is no plan to do that now.

Proposed URL Changes

We propose converting mozilla.com into a Firefox-specific site to be hosted at mozilla.org/firefox. This would mean there is no just one top-level Mozilla site instead of the current two (mozilla.org and mozilla.com). Once this process is done, we can review how things went, make changes to the domain if needed and roll out a plan for dealing with other organization-based domains.

Using the principles of the "One Mozilla" strategy could result in the following new URLs:

Existing URL Proposed URL Comment
mozilla.com mozilla.org/firefox
support.mozilla.com support.mozilla.org/firefox
mobile.support.mozilla.com support.mozilla.org/firefox/mobile or support.mozilla.org/firefoxmobile
addons.mozilla.org addsons.mozilla.org[/firefox]†
spreadfirefox.com spread.mozilla.org/firefox or mozilla.org/firefox/spread Both are awkward because they split up "spread firefox".
nightly.mozilla.org mozilla.org/firefox/nightly or builds.mozilla.org/firefox
firefoxflicks.com mozilla.org/firefox/archive/flicks Inactive since 2006
getfirefox.com mozilla.org/firefox Currently redirects to mozilla.com
rockyourfirefox.com mozilla.org/firefox/rockyourfirefox or rockyourfirefox.com Let microsites violate the rules?
mozilla-europe.com mozilla.eu/firefox for downloads and europe.mozilla.org for the organization ? mozilla.eu contradicts "one mozilla", but with the purpose of emphasizing European presence
input.mozilla.org input.mozilla.org[/firefox]†

† If there are no other product subdirectories, the top level URL could be for Firefox.

Note: This list is not complete. Just an initial batch of URL changes.