Short Thoughts

The Power of the URL

In the software world, usability is everything. Especially on the Mac, if you’re a developer and your software isn’t easy to use, point blank very few people are going to use it. The same is true on the web, only the implications of usability in web-based services are far more imperative than on the desktop for three reasons:

• There are no unified Human Interface Guidelines for you to follow
• Competition is far more likely to spring up quickly
• Changes can be rolled out quickly, to all users, simultaneously

What that means is that you need not only to develop a consistent and usable user interface for your web app on your own, but you need to work hard to maintain that workflow, because it won’t take long for competitors to evolve and adapt around you.

There is, however, one oft-overlooked aspect of web usability that you very nearly need to decide from the beginning, and that’s your URL structure. Is it a make-or-break aspect of your software? No. But does it have the potential to add that little extra bit of spit polish to your user’s experience? Absolutely.

Say it with me now: the URL does not have to mirror the filesystem. Very good. Repeat that five times every night before you go to bed.

Web servers have evolved substantially over the past decade or so. Oh wait, no they haven’t. They pretty much do the same thing as they did back in the late 90′s. Of course they do it faster and better now, but the pattern is the same: take in a request to a URI, locate the resource identified by said URI, perform any necessary transformations to the resource, then pack it up and ship it off to the user agent. Note carefully the “locate the resource identified by said URI” step, because it’s intentionally very vague.

It’s no coincidence that the common POSIX filesystem path notation (/usr/local/coolstuff) and the syntax of a general HTTP URL (http://host/files/coolstuff) bear extraordinary similarity: they were developed for the same purpose, an easily parsed and generalized way of notating some sort of organizational hierarchy. However, just as a UNIX filesystem path doesn’t necessarily reveal anything about the physical layout of files on disk (in contrast to a Windows filesystem path), neither should a URL. Your users don’t care how you like to organize files on your web server, nor should they. In fact, revealing your filesystem layout to your users can even be a security risk in some situations.

Filesystem paths are not inherently intuitive to browsing the web. Browsing a filesystem, sure, it’s a very simple /directory/directory/file.ext model, and if you know how you organized things, they make perfect sense. The web, however, is increasingly not about browsing files, but rather about browsing content. Because most of your visitors (in general) won’t have a freakin’ clue what a PHP file is, it doesn’t make sense to expect them to understand why it’s a part of your URL.

And that’s why it boggles my mind how many times in a day I see “.php” at the end of the URLs of the sites I visit, and don’t get me started on some of the complex query strings out there. URLs should be human-readable if there’s ever any hope that they’ll be memorable, and it’s not exactly a challenge. Apache, arguably the world’s most popular web server, has had an extension called mod_rewrite (which lets you map arbitrary URL patterns to files on the server) since July 1997, and except when serving certain media resources (images, movies, and certain types of special non-HTML content), there isn’t a web browser in the world that has a problem with not having a file extension in the URL. So why is it that, in 2009, every website doesn’t use some sort of URL rewriting scheme? The only reasons I can come up with are the same ones that apply to usability of applications in general: a combination of ignorance and laziness.

So for those of you just tuning in that aren’t lazy, allow me to elaborate a little bit to cure any of that remaining ignorance. Let’s examine some common examples.

• Real URL: http://www.facebook.com/home.php
• Should be: http://www.facebook.com (or) http://www.facebook.com/home

This one’s relatively easy: we simply don’t need to know that Facebook is using PHP to serve the home page (it’s even partially false, because it’s actually a PHP interface on top of C++), and it unnecessarily clutters the URL. Trim the fat.

• Real URL: http://www.example.com/index.php?p=243
• Should be: http://www.example.com/article/243 (for example)
• Even better: http://www.example.com/article/title-of-article (or) http://www.example.com/2009/10/6/title-of-article (date in URL)

Here we have an unnecessary use of query string. I have absolutely no clue what “p=243″ indicates (not knowing the code), and as a non-technical user, I’d imagine that looks very confusing and frightening. This URL is not “hackable:” there’s slim chance I’m going to be able to figure out how to create my own URLs for this site following that scheme. We can clean up the confusion and ambiguity using the “/article/” root, followed by (what is now clearly) an article ID, or even better, a URL-safe form of the article title.

• Real URL: http://www.example.com/cgi-bin/display.pl?category=posts&username=johndoe&sort=last
• Should be: http://www.example.com/posts-by/johndoe?sort=last (or) http://www.example.com/posts-by/johndoe/sort-by/last

First of all, in this day in age there is no reason to have to use a “cgi-bin” directory, that’s just lazy. At the very least take it out of your URL. Beyond that, though, the query string is unnecessarily complex, and can easily be reduced into a very readable URL, either partially or wholly. Choosing which one makes more sense depends on your particular application.

URLs are by no stretch the most important aspect of your web application, but URLs that are meaningful, consistent, and readable have the added benefit of being hackable and easily understood. It just might make that tiny bit of difference for one of your users.