Putting the useful in a uniform

In the beginning the Internet was created. This has made a lot of people very angry and has been widely regarded as a bad move.

That’s a really fluffy title and a stolen line to open what will understandably appear to most to be a spectacularly dull subject. URLs. Uniform Resource Locators. We all know and love hate them. It was a URL that brought you here and it’ll be a URL that takes you away from here (by being more interesting than this one).

Tim came up with these gnarly alphanumeric nuisances way back in 1994 and we’ve been abusing, misusing, and mistyping them ever since. Like all of the early internet, URLs are heavily skeuomorphic, modelled after quite possibly the most boring thing man has yet invented: manilla folders containing vast quantities of wasted paper. This particular nugget of skeuomorphia has done incalculable harm to uncountable minds and held back human progress by at least 15,778,476,000 jiffy’s, but now I’m straying from the point…

YES, URLs SUCK! but we can make them better.

How tho?

First, kick that oh-so-addictive skeuomorphine habit to the curb and get a bit creative. URLs are for people.

Wait but why?

Because hierarchies of discrete folder/subfolder/documents are too rigid a paradigm to accommodate the inherent malleability of hypertext. As a tool for encoding taxonomies, URLs fall short in a number of ways:

Possible issues with this approach:

  • Users/readers can infer very little in terms of adjacent context from the URL. But why should they? URLs are a locator not a vector for content.

Rough notes

URLs are for people. Your computer doesn’t care whether you direct it to fetch a web document from within your LAN or from out on the Internet; nor whether that request is addressed using a bare IP such as 108.162.192.207 or a domain be it nice and short.com or needlessly-long.com/1970/01/01/domain/names-are-annoying; over HTTP://, FTP://, SSH://; nor whether the subsequent response comes via ADSL, WiFi, cellular, fibre-optic cables, or pigeon. A computer will never thank you for your efforts to make useful URLs, but a person might.

A useful URL should be short, memorable, and eschew needless hierarchy.

Why keep them short?
Long URLs are ugly, unwieldy, unhelpful, and uninviting.

https://people.eecs.berkeley.edu/~kubitron/courses/cs162-F06/design.html

Why exclude dates?
Dates are of limited and highly variable utility and don’t belong in the address bar. By explicitly locating a resource in time we give it context yes, but we also constrain it. We should be free to vary the prominence we give to time in our documents. A living document such as this one will grow and evolve, why should it carry the date of it’s birth on its back forever.

Their utility is constrained by their explicit

Dates also devastate a URLs memorability. For someone returning to this site silasjelley.com/design is memorable, silasjelley.com/2021/08/31/design is not. Hell, I could hardly tell you just the year in which I created a given document, let alone the exact date. Including dates in URLs in any case except where the date is the meaningful element is a disservice to readers as it undermines their memorability.

Hierarchy considered user-hostile

Hierarchical URLs are considered skeuomorphic (by the author) and are avoided. Site structure should be established within its composite documents, not in the address bar.

An example of where this proves valuable is in allowing meta flexibility. An earlier version of this site referred to my notes as a codex. Eventually I realised that this was pretentious, ambiguous, and unhelpful – I now simply call them notes. If my taxonomy up to that point had been to establish hierarchies in the address bar (eg. silasjelley.com/codex/anti-fragility) then this realisation would have forced me into one of four unhappy possible paths:

  1. Keep existing documents at their already minted URLs and only make the change to ‘/notes’ for new documents, leaving me with an ugly and confusing split taxonomy that would confuse readers and annoy me.

  2. Change existing ‘/codex’ URLs to ‘/notes’. This fails the Cool URIs don’t change test so was a no go.

  3. As above but also issue 302 Permenant Redirects from previous ‘/codex’ URLs to their new home under ‘/notes’. This alleviates some of the Cool URIs issue and is certainly the best practice if you do find yourself in such a situation.

  4. Do nothing, put up with my pretentious mistake forever.

Thankfully I didn’t need to pick from any of these poor options, having never established hierarchy in the address bar I was free to do a simple find-and-replace (codex > notes); change and redirect the URL of a single page (/codex), the only user-facing change; and get on with my day.

silasjelley.com/anti-fragility remained exactly where it always had been, as did every other document.

Counter argument
A hierarchy can be useful in allowing a user to move up the folder hierarchy.

Lesser ideals

In addition to the above prescription URLs should aim to be:

  • Logical/predictable: some measure of namespace consistency should be pursued.

Schema

More concretely, the schema for URLs is roughly as follows:

  1. One or two words, hyphen-separated
  2. Alphabetical only, no numbers

Of the below URLs that could address this document, only the last of them meets the criteria for brevity, memorability, and anti-hierarchy.

silasjelley.com/2021/08/31/a-draft-design-document-for-this-site
silasjelley.com/a-draft-design-document-for-this-site
silasjelley.com/2021/08/31/draft-design-document
silasjelley.com/draft-design-document
silasjelley.com/2021/08/31/design
silasjelley.com/design