One of my favorite parts of my NewBCamp talk last month was something I had never really talked about (either in person or on this blog) but wanted to take the chance to share: The idea of the URL as UI. So, what is URL as UI?
Computer users have gotten so used to the graphical user interface (GUI) that it is easy to forget that computers basically operate via a series of commands. The web has not only brought the command line back to the surface (with the web browser’s address bar), it has exposed the concept to an entire generation of users that has never seen a command line.
When you access a web site, you are generally typing in a URL (unless, of course, you are selecting a bookmark or following a link from an email, IM, other site, etc.). The URL is essentially a command to go fetch that content. We take components of the URL such as “http://”, “www”, and “.com” for granted now, these are rather arcane expressions that would be nonsensical to non-web user. But since most sites we access start with an “http” (perhaps an “https”) and end with a “.com” (or “.net”, “.org”, etc.), we get used to these conventions.
Many developers take the time to learn the command line instead of using the graphical user interface because it can be faster and more efficient. For example, if I wanted to add a graphic called “button.png” to code base for BatchBook (the web-based contact organizer I’m working on for BatchBlue), I’d have two options. I could:
- Open a Finder window.
- Open the folder “svn” in my home folder.
- Open the folder “batchbook”
- Open the folder “public”
- Open the folder “images”
- Find the file “button.png”
- Right click on “button.png” and choose “Add” from the contextual menu (I was using SCPlugin for Subversion)
Or, I could do it via the command line like this:
- Open the Terminal
- Type “svn add svn/batchbook/public/images/button.png”
Once I learned the conventions, it was an easy choice for me.
Similarly, navigating a web site simply by the URL can be much faster and more efficient than relying on the site’s information architecture and navigation menus.
If I visit Amazon.com and search for the album Rock Action by Mogwai, I am directed to a page with this URL (line break mine):
My first question was “how much of this is needed to access the page and how much is session information Amazon is capturing?” Well, turns out that the URL really is:
What’s good about this is that it has the artist and title of the album in the URL. What isn’t so nice is the extra stuff that means nothing to me, the user. I’m sure it means something to Amazon, but that doesn’t mean it needs to be exposed on the front end. If I want to look up a different CD or different artist, I need to rely on the search functions or Amazon’s site architecture, even though I already know exactly what I want.
Is this just Amazon? No. Here’s the URL that Barnes & Noble gives me (again, line break mine):
To me, this is far worse… there is no human readable component here at all.
URL as UI Done Right
So, what’s a good example of URL as UI? Last.fm, of course. Here is the URL for information about Rock Action:
Now, let’s compare the three showing human usable vs. machine usable data:
With Last.fm, if I want to look at the main Mogwai page, I can just delete the “/Rock+Action” part. If I want to look at a different artist page, I simply swap out the “Mogwai” with, say, “Orbit”. If I want to look at a particular Orbit album, I can just add it after the “/Orbit”, such as “/Orbit/Libido+Speedway”.
Notice that everywhere there would be a space, you use a “+”. Once you learn this simple convention, you can keep using it to speed up your interactions with the site.
Another example of a convention you need to learn is the individual track convention. It is possible for an artist to have the same song appear on many albums (such as the standard release, live album, greatest hits, etc.). Last.fm could track these separately but instead chooses to treat these all as one song. So, this is how you would access a single track’s page:
Notice the “/_/” between the band name and the track name. The underscore in the directory where the album name would normally go signifies that we’re no longer looking at an album—we’re looking at individual tracks. If you were on the page for Arcade Fire’s “Intervention” and wanted to look at a different track by them, you’d have to hunt around the page and try to find a link to that track, or more likely go back to the main artist or album page and find it there. Using the URL, you can jump right to “/Ocean+Of+Noise”.
Of course, you can use this technique elsewhere on the site. For example, every artist has a wiki-based bio page, with a URL like
http://www.last.fm/music/Mogwai/+wiki. If you wanted to read a few band bios, you’d have type the artist’s name into the search field, land on the artist’s page, and click the “Bio” tab to see each bio (and repeat the process for each artist). Why not just type the artist’s name and that’s it (via the URL)? Same thing goes with photo pages for each artist, video pages, etc.
Also, Last.fm is not the only site doing this right. Another example is Flickr. To see my photos, you go to this URL:
If you want to go switch to another user’s photos, as long as you know their username you can replace mine with theirs. It works well for tags, too. If you want to see all my photos I have tagged as “redsox”, you can go to:
If you want to see someone else’s photos tagged “redsox”, simply swap in that user’s username. If you’d rather see everyone’s photos tagged “redsox”, just take out the username altogether.
If people use your site enough, they’ll want an even faster way to reach the content they want. They’re not browsing anymore. They are power users. They know what they want. Give them a nicely hackable URL to do this.