Developing iteratively in little bits at a time it can make it easy to miss the big picture. One of the important -- and often underrated -- aspects of the big picture for websites is the URLs they use.

FanConcert has evolved into using some less than ideal URLs. This has been largely due to the fact that I was new to Ruby on Rails and Rails' default structure has a big impact on URLs.

For example, FanConcert URLs are grouped by object class. In Ruby on Rails, this is first grouping is known as the controller. All of the Artist operations are in the same controller (artist). Some of the URLs look like:

http://www.fanconcert.com/artist/new
http://www.fanconcert.com/artist/details/101
http://www.fanconcert.com/artist/edit/101

Doesn't exactly roll of the tongue. I'd like to change FanConcert to use a more readable format, like:

http://www.fanconcert.com/add/artist
http://www.fanconcert.com/view/artist/101
http://www.fanconcert.com/edit/artist/101
http://www.fanconcert.com/moderate/artist/101

That looks a lot better. The significant bonus is having all of the operations for each object grouped together by Rails controller. All of the add pages for every object will be in the add controller, like:

http://www.fanconcert.com/add/artist
http://www.fanconcert.com/add/venue
http://www.fanconcert.com/add/concert
http://www.fanconcert.com/add/release

It makes it a lot easier to share common controller and view code for common operations like add. This grouping and sharing also makes things easier to test.

Why am I so concerned about URLs now, you might ask? Thinking into the future isn't very agile, right? Maybe, but agile processes aren't hard and fast rules for me: sometimes I feel I need to think ahead. Sometimes I need to use common sense, not rules or processes.

People don't like it when you change URLs, especially if you don't gracefully redirect. I won't put in redirection code in this case because there aren't enough people impacted by this change and it adds complexity. If you're just using FanConcert, you probably won't even notice the different URLs.

As well, search engines are very unforgiving about changing URLs. It will take a while before FanConcert is properly re-indexed by the search engines after I do this switch. During that transition time people will get a lot of 404 errors from search engine links to FanConcert. I'll just make sure FanConcert's 404 page is more helpful than it is now, so people can find the new page location.

For the above reasons, the earlier the URLs are decided on the better. I need to do a little bit of forward thinking here and try to come up with future possible features that will have an impact on URLs. Maybe I can leave a hole for them to gracefully slip into? That's the idea.

A feature that will have a large impact in the future is translation for locales. When FanConcert is translated into different languages, you should be able to see the same page (and information) in any language that FanConcert has been translated into. What could the URLs for the different languages look like? Let's take the Add an Artist page as an example:

http://fanconcert.com/add/artist

I don't have to worry about, because it's an HTTP redirect to:

http://www.fanconcert.com/add/artist

which is the page in the default language (probably British English).

http://en.fanconcert.com/add/artist

is the page in the default English (British).

http://en-ca.fanconcert.com/add/artist
http://en-CA.fanconcert.com/add/artist

The page in a specific localization of Canadian English. Others would be:

http://en-us.fanconcert.com/add/artist
http://en-gb.fanconcert.com/add/artist

The convention is to have the localization part of the language in upper case, but URLs are typically not case sensitive. Some servers support that (ie. Apache) but it doesn't make sense for URLs to be case-sensitive on FanConcert. Case-sensitivity is unnecessary here and becomes a usability issue.

Why have different English translations for each locale? I think we take for granted how different the English nations actually are. We all have local customs, jargon, units of measure, date formatting, etc. I'd like to facilitate all of this and allow FanConcert to be a unique experience for each locale. Then people will feel more at home, instead of having to compromise or concede to larger nations that speak the same language. As a Canadian I think I speak from some experience in this area. :)

An obvious downside to this approach is that URLs for non-English users will not be as readable for those languages, for example:

http://fr.fanconcert.com/add/artist
http://fr-ca.fanconcert.com/add/artist

This doesn't read well to a French person but is somewhat of a necessity from a few standpoints. First, it would be overly complicated to translate/alias all of the Rails controllers and actions used on FanConcert (the first and second words after the /).

Secondly, even though URLs are supporting more internationational characters, like those that are accented, if I'm not mistaken all languages cannot be represented in URLs, so there is a technical limitation there.

Thirdly, it would make it harder to switch between languages on the URL. If I want to switch between English and Japanese for the same page, all I'd need to do is change:

http://en.fanconcert.com/add/artist

to

http://jp.fanconcert.com/add/artist

This is becoming more common on sites that support different languages simultaneously, like Wikipedia, Google and imdb.com. It's a good compromise and I think people are getting used to it.

Translation and localization is definitely an area where I'd like/need to take a lot of feedback. It's hard to serve the minority well when you are living (mostly) in a larger group (English) that has, up to this point, dominated the Internet (hint: that is changing, my friend).

It's hard to relate and I'm going to need to do my best to sympathize with people that speak other languages because I want them to feel at home on FanConcert. I'd like every language and every locale in those languages to be able to be first-class citizens as much as possible. It would be up to the people in that locale to do the translation work, again I'd just facilitate it.

While I'm on the topic of languages: you'll be able to change localization preferences for your user. If you select you're from Canada, it would use the en-CA translation/localization and metric units by default but you could override it. That's the idea: FanConcert makes an assumption and in most cases it Just Works. The assumption can then be overriden by users that are exceptions.

A sensitive URL area is searching. I won't write too much about this area right now, but I will say this: search URLs should not only be readable but also generally hackable in the location text box -- people should be able to replace words in search URLs to make different searches. This is pretty standard on search engines and popular websites.

This not only makes the URL prettier but it also makes it easier to create third-party tools that point to FanConcert. A simple example is FireFox's flexible search box, which can be programmed to search most sites. If it's easy to connect tools like that to FanConcert, more people will search and use FanConcert. It's that simple.

Another area is output variations on the same data as a webpage in a different form like syndication feeds such as RSS, Atom and OPML. I'd like the URL to show that the information comes from the same source as much as possible. Right now that looks like:

http://www.fanconcert.com/concert/upcoming
http://www.fanconcert.com/concert/upcoming_rss

which is a bit ugly, especially when you condsider that every new output format is a new Rails action, like upcoming_rss.

Remember how earlier I talked about wanting to be flexible on output formats and templates? That also factors into this. Maybe something like:

http://www.fanconcert.com/upcoming/concerts
http://www.fanconcert.com/upcoming/concerts?format=rss2
http://www.fanconcert.com/upcoming/concerts?format=atom

Where the parameter format is the name of a common template available to everyone for concerts. The URL without the template specified is just the regular web page. This cuts down on the number of actions but makes each action somewhat more complex since they have to deal with rendering different templates.

For personalized output, a user's custom template could start with the user's unique username:

http://www.fanconcert.com/upcoming/concerts?format=ryanlowe_custom1

When you blend syndication and languages with URLs, you get something that looks like:

http://www.fanconcert.com/upcoming/concerts?format=rss2
http://en.fanconcert.com/upcoming/concerts?format=rss2
http://fr-ca.fanconcert.com/upcoming/concerts?format=rss2

The data, language and template could all be independent of each other. On the other hand, a custom template could just use one language for simplicity.

It's all up in the air, these are just ideas. What do you think? Can you think of other areas of FanConcert that need consideration with respect to URLs?