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 (silasjelley.com/urls
) 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:
- They create a blocking issue where one need not exist (Taxonomies should be emergent and asynchronous) creating rather than reducing friction at the point of creativity.
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:
-
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.
-
Change existing ‘/codex’ URLs to ‘/notes’. This fails the Cool URIs don’t change test so was a no go.
-
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.
-
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:
- One or two words, hyphen-separated
- 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