URL as UI

URLs are part of your user interface.¹

Your web app's user interface has three major components:

1. Your HTML (GUI) — the pages themselves and their behavior.
2. Your API — used by developers (internally and/or externally).
3. Your URLs.

Everyone knows URLs are important and shouldn't change. But there is more to the concept of URL as UI than that.

The perfect URL

To help imagine what the perfect user interface expressed through URL design would look like, imagine that you can't use your HTML UI for navigation. How would you get to the page you are looking for?

An ideal URL is guessable.

Synonyms should ideally redirect. If you have a support page at /support and a user types /help, is that really such a bad request? Don't show them a 404 — send them to the page they're looking for!

An ideal URL uses honest hierarchy.

If your URL's path includes a slash — like example.com/widgets/674 — then truncating everything after any slash in the path² should result in a useful page, not an error.

In this case, example.com/widgets should probably list widgets and/or allow the user to create their own new widget, even if that means redirecting to /widgets/new.

If that's not possible, either explain why on the page or consider removing your false façade of hierarchy. For example, the previously mentioned URL could be re-written as example.com/widget-674.

An ideal URL doesn't include a filetype extension.

This applies only to actual pages, not media like CSS, JavaScript, images, or audio.

Forcing the user to type .html or .php is bad for at least three reasons:

1. It's extra typing and length, which is inherently bad.
2. It requires the user to know what powers your site to use your URL as a user interface.³
3. It makes your URLs more likely to change if your site technology does.

An ideal URL doesn't care if your URL includes a trailing slash.

Pick either /foo or /foo/ and redirect users to the canonical page.⁴

Obviously, omitting the trailing slash means shorter URLs, which is always good.

An ideal URL is similar to URLs on other websites.

Plenty of websites use the URLs /login and /logout, so a URL like /create or /session/destroy is a hell of a lot less guessable — inherently, yes, but also because it's not expected.

Just like you put your site search widget in the top-right of your page and links to your TOS in the page footer because everyone else does, your URLs should be similar to others' as well. One of my favorite Nielsen quotes: "Your visitors spend most of their time on other sites." This should influence all the aspects of your app's UI design, not just its GUI.

An ideal URL is the same on every device.

Jane goes to your website on her iPhone and tweets a link to one of your pages. John clicks her link on his desktop computer. Should he see a mobile version of the website? No.⁵

Gracefully handle 404s.

Since you would never simply delete a URL (right?), you have to anticipate that many, if not most, of your (human-triggered) 404s are failed attempts to navigate your site via that third user interface, your URL. What can you do to help you user out? Consider linking to your home page and/or site map — or showing a directory of major sections. (Apple is great at this.) You can also pre-populate a site search field with terms extracted from the errant URL, an approach I take here at alanhogan.com.

Inspiration

To see what excellent URLs look like in practice, consider these examples.

1. Synonym redirection.

   Visit http://apple.com/finalcut and you're automatically redirected to http://www.apple.com/finalcutstudio/.

2. Subdomain & path interchangeability.

   Google wisely redirects http://google.com/docs to http://docs.google.com. It hasn't always been like this, which is (to me) a fantastic sign because it means someone at Google cared enough about the concept of URL as user interface to eventually set up this redirection.

3. Cross-domain kindness.

   For technical reasons, Simplenote's web editor runs at https://simple-note.appspot.com but the canonical product site is at http://simplenoteapp.com.

   This meant that the "Downloads" link at the bottom of the editor, for example, sends users to the other domain. This works fine in "UI #1," the HTML GUI — but from a URL-as-UI perspective, it stinks because a user who appends "downloads" to the current URL in the web editor would be served a 404 page. Until recently. Now such requests automatically redirected across the editor domain to the product site. And why not? We know exactly what the user wants.

4. Context-aware 404s.

   Apple has a wonderfully specific error page for 404s that occur in their Final Cut section: http://www.apple.com/finalcutstudio/x asks the user, "Looking for something on the Pro Apps site?" and lists products in the suite.

5. Improving unituitive URLs.

   I keep using Google as an example, but URL design is something they both struggle with and seem to improve at, over time. Consider their translation service. It used to be the unintuitive http://google.com/translate_t (don't ask what the _t meant). I don't think http://google.com/translate even worked. Now, however the service lives at the much more memorable and guessable http://translate.google.com. Thankfully, they avoided breaking links by redirecting from the old URL, and they maintained guessability by making /translate redirect to the subdomain as well. Huzzah!

Room for Improvement

Let's take a look at some less than perfect examples:

1. Not anticipating the company.com/major-functionality pattern.

   http://google.com/spreadsheets results in a 404 File Not Found error.⁶

   Is an obnoxious, cute, unhelpful page really the answer here, when a user is clearly requesting the spreadsheet functionality of Google Docs?

   Google Docs' spreadsheet functionality is apparently not considered a product itself but it's not smart to make the URLs reflect this arbitrary and elusive definition. After all, the Big Competitor here — Excel — is not the same product as Microsoft Word, is it? Microsoft handles http://microsoft.com/excel with an appropriate Excel-specific redirection. As an underdog competitor here, Google should expect end users to have the Office family of discrete products (Word, Excel, …) as the basis for their mental model of Google Docs.

2. Not anticipating the company.com/product-nickname pattern.

   http://www.apple.com/osx results in a generic 404.⁷

   It ought to redirect to http://www.apple.com/macosx/.

   (At least a link to that page is provided on the 404 page!)

3. Not getting mobile URLs right.

   In a classic presentation, Rob Manson noted an Australian company whose main website is at http://quantas.com.au, but whose iPhone website was at http://quantas.com/mobile. Note the sudden disappearance of the ".au" from that domain.

   While it's bad enough to segregate URLs into mobile and non-mobile versions (in most cases), doing so in completely counter-intuitive fashion is a tragedy — especially if you aren't doing automatic redirection!

4. Not registering domains & subdomains for your product, or disregarding common use-cases.

   Adobe provides us an interesting case to consider. Imagine someone guessing at a URL from which they could download the latest version of the Flash player. (Hey, it's important — apparently 50% of the Mac's security problems — and a definite majority of browser crashes! — are due to Flash bugs.) How do they fare?

   • http://adobe.flash.com is almost great: It redirects to a software download page with a link to download Flash Player, but it's surrounded by tons of products that have nothing to do with Flash.

   • Interestingly http://flash.com is aimed at developers and attempts to sell the visitor on the "Adobe Flash Platform".

   • http://adobeflash.com is a kind of third-party site. I wonder how Adobe let that happen. I'd guess they haven't made too big a fuss because the site, though it feels kind of spammy, does offer free resources for Flash developers.

   • http://adobe.com/flash redirects to Flash Professional, the Flash-creation product part of Creative Suite. No, this is not the same thing as the Flash Platform at flash.com.

   I was initially impressed with http://adobe.flash.com actually being relevant to the #1 reason people would want to do something having to do with the words "Adobe" and "Flash", but altogether I'm not impressed:

   • Why are all four of the above URLs redirecting to completely different pages?

   • Why aren't any of the above four URLs going to a page whose primary purpose is to let people download Flash Player? (Expecting normal people to call it Flash Player instead of Flash is hopelessly naïve!)

   • Why is there an assumption that it's more common, responsible, and/or profitable for people to need to buy Flash than to download the latest player? After all — someone having a bit of difficulty updating Flash Player is more likely to abandon the process than a professional trying to purchase Flash Professional… and Player releases come out much more often than the newest version of Creative Suite does… and way more people have Flash Player than Flash Professional.

   The harder it is to get a legit Flash player update, the more likely people are to be tricked into downloading a spyware/Trojan "codec" from that porn/warez/squatter site. One could then argue that Adobe's URL failings here are unethical, or at least negligent!

Caveat

Users are trained to navigate primarily through the HTML GUI.

Still, power users, keyboard aficionados, and those with good memories (especially) sometimes navigate via URL.

For me, URL as UI feels important, but taking it as seriously as I try to may not be necessary in many cases. Yet as your site becomes more popular, the potential to turn more 404s into successful uses of our most neglected user interface grows. I encourage you to take advantage of that opportunity.