The address bar is at the top of every user's browser and it's often totally overlooked by developers. We all know we should think a little when choosing a domain name, well mostly, but after we've done that normally let the our toolkit or internal organisation work against the user and clutter up the address bar with crap.

it should make sense to the user

All developers primary motivation, for the address bar as with the rest of the ui, should be something that's useful to a user. It's there on every browser, on top of every page of every visitor to your site. Make them short and simple, easy to see where you are, easy to remember and easy to type.

http://mysite.com/products
http://mysite.com/services
http://mysite.com/services/urls
http://mysite.com/contactus
These are all good URLs, easy to see where you are and easy to remember.

I've seen a number of applications or frameworks that want URLs in the form http://somesite.com/site/PAGES/EN/index.php. It irritates me just seeing it. None of that cruft has anything to do with anything a user cares about. It's inattention to detail, it's endemic on the Internet and there is no excuse for it.

case sensitivity

A URL should not under normal circumstances be case sensitive. Storing something at the same place with the same name only differing in case is very confusing and counter intuitive to users. Don't do it.

http://mysite.com/HOME
http://mysite.com/Home
http://mysite.com/home
These are all the same to most users and you wouldn't actually put different pages at each of them would you? So why not do the sensible thing for the user and make sure that no matter what case they use it just works?

The case to use depends on a variety of factors. For most uses all lowercase is probably the best default choice, however using CamelCase in a wiki, casing for adherence to brand standards or common conventions are all reasonable situations where preserving case may be the prefered option. Preserve the case yes, but don't make the URL case sensitive.

In the 37 signals book Defensive Design for the Web[[posterous-content:AdnwJyzzGmvqpgpgGjub]] [amazon.co.uk[[posterous-content:AdnwJyzzGmvqpgpgGjub]]] they point out a classic from a usability best:

I typed "www.apple.com/iTunes" in my browser's address bar but instead of information on the MP3 application, I received a "Page Not Found" error. Even though the application is called "iTunes" apple's site only accepts "www.apple.com/itunes" (all lowercase).

This is an unfortunate branding situation for Apple. Customers are actually punished for adhering to the brand's naming conventions

At the time of this post on Apple has fixed it, both URLs will now give you the correct page but I think it's a great example. As well as a great excuse to link to the excellent 37 signals book. It's worth pointing out that the apple page currently redirects to the lowercase www.apple.com/itunes url so it's not case preserving or using the correct case to adhere to the brand's naming conventions, but at least it works.

file extentions

Why do so many websites have pages that end in html, asp, php, jsp, .do? Users don't care about what language you're using, telling them is pointless and worse makes it hard for them to figure out URLs from memory or by making an educated guess. Take the time to configure your server to at the very least drop the extensions.

The exception to the rule

There are times when a file extention is important, and developers should know when to apply the above rules and when for everyone's sake not to- when a file extention dictates the mime type, or when you're providing a file for a user to download you obviously want to maintain the extention. There is nothing wrong with having .pdf, .exe, .dmg, .gif, .jpg, .avi, .mov etc. Most of those files are embedded, or downloaded and should maintain their extensions.

Querystrings

I hate them. I really hate them. What the is index.php?ID=123 anyway, what does that mean to me? Keep your database IDs in the database and give me something useful. Blogs get this right a lot of the time, or close anyway. Forums are notorious for getting this wrong.

A querystring is alright, if you're running a query, a search or something similar where various parameters are going to affect the outcome. It's not alright if you're pulling one element out of a database. It's alright if you're using an API. If you're pulling a single item and the only identifier is a numeric id you can still do better than a query string. How about: http://mysite/items/12345/

why should we care?

It seems like a small thing to worry about when you've got a whole application to build. The URL is like a lot of little things, it shows attention to detail. It's easy to make them sensible if you choose to and it will make some users lives easier. The short term pain of making all your URLs sensible will in the long run improve usability- you might even retain a few more users here and there and eventually that will add up.

Take for example something like a property sales application. Let's give it two URLs for the sake of argument.

I hammed it up a bit on the last one to prove a point- they're both a similar number of characters but the second is so much better even though it's longer!

The second is much more user friendly.
The second URL is much more information rich than the fist. You're looking at a property, on a page, on a site written in php in english - or - You're looking at a property, in Malaga, Spain with 2 bedrooms and it's a 'Stunning town house'.
To quickly broaden a search for related two bedroom properties in malaga it's obvious you can just remove the last part of the URL on the second. The first you'll have to use the search function.

No excuse for... regular features on blogs

This might turn into a regular feature, I've got a growing list of things and there is no excuse for them. I think what I'll do is queue them up as I write them then post them for a Friday afternoon read.