Technically, I’ve already started working on the information architecture (IA). Otherwise, you wouldn’t be able to read this.
What I haven’t done, is document it so that needs to happen now—even if it changes along the way.
Quick recap:
Between 2008-2014 my blog was hosted on Blogger, built using Blogspot and beholden to Google’s whims.
Between 2014-2020 it was hosted on Github Pages, built using Jekyll and beholden to Github’s whims—and the sometimes fickle Jekyll.
Moving forward, this site will be—it already is—hosted on DigitalOcean, built using Laravel and more beholden to my whims than ever before because unlike before, I’m now paying for services.
I can now implement redirects and fix hosting restrictions which used to cause weird URLs that I would never have chosen, had a choice been something I had been able to do.
Information architecture is the stuff on pages sure, but it’s also the pages themselves, and their relationship to other pages.
If it has a URL, it’s a page.
This isn’t the technical definition of a URL but because the protocol for my domain is already present, then anything here will already be within the scope of the definition for URLs.
Built to withstand trends and bullshit, I will make my URLs short, memorable, hackable and people-centred.
But I’m also trying to be wary of what I’d like to call irrelevant precision. Let’s take this imaginary URL as an example: https://carloseriksson.com/blog/2020/02/12/the-boy-who-didnt-fall-far-from-the-tree.
Imaginary because it currently isn’t visitable but useful as an example because it illustrates the problem I’m wrestling with at the moment.
On the surface, it looks like a pretty decent but a closer inspection reveals some flaws with it.
Is it short? No.
Is it memorable? No-ish. The date makes it hard to remember if I asked someone to produce the full URL from memory.
Is it hackable? Well, yes, that I suppose it is. It’s structure suggesting a breadcrumb of sorts but here’s where it gets a bit shit.
See, if it’s hackable then removing the title, leaving the date as the smallest unit of precision: https://carloseriksson.com/blog/2020/02/12/ should reveal, well what?
All blog entries which was published on the 12th February 2020, right?
Except, the only content on that day, is the one whose titles we just removed. Hackable, sure, but it doesn’t reveal any new content, so the precision is irrelevant.
Of course, that’s just one entry and I’m not making any decisions based on one. Thankfully I don’t have to because I have an archive of 10+ years of inconsistent—thanks Past Carlos—writing.
The most entries in any single day were in August 2009, and that was three entries.
But most days don’t have entries at all. Let’s verify this by diving the total number of days since I first started writing with the total number of entries.
4,310 / 351 (including this one) = 12.27
So, for any given date, the odds of “discovering” an entry is 1-in-12.
That’s a lot of URLs with no content on them, or a 404 page. Neither is particularly useful.
Removing the date leaves us with the month as the smallest unit of precision but even that’s not very useful as an average month only contain two entries.
Which leaves me with the year, which is the one to become useful.
2008 has one entry and 2013 has 66 entries so that’s the range I have to deal with.
So that settles it, titles will exist below years and nothing else, which in turn will exist below blog, so we get this:
-
/blog/ -
/blog/{year}/ -
/blog/{year}/{title}
Now, that presents one issue, if Year is a narrower view of the same hierarchical data then what should /blog/ show?
Everything, or at least every year because it’s the “least” precise group of stuff.
But I’m not convinced that I want to show everything on this one page—as I’m doing currently—because most people will want to see the latest entries, not a catalogue of all entries.
So, I think it should the nine latest entries, and links to each year. This makes the URL structure make sense and meets all four criteria of being: short, memorable, hackable and people-centred.
Without any irrelevant precision.
Let me know on Twitter if any of my redirects aren’t working.
An additional benefit from this structure is that every section can have its own RSS feed, like this: /blog/feed/.
I’ve focusing on the /blog section of my website now but this same logic—how useful is this precision?—will be applied to all sections as they evolve.