Information Architecture
Yet another dichotomy or dialectic to deal with is the question of what structure matters. The simplest way I can describe it is the discontinuity between URL structure and navigation hierarchy in web design.
URLs are intrinsically modelled on filesystems with the path separator slashes defining levels of hierarchical nesting. Conversely, the experience of navigating hypertext is intrinsically horizontal and rhizomatous. Clicking any link can theoretically take the user anywhere and they can jump around in any order to the extent of what the navigation and inline links allow.
Beyond pure hypertext, hierarchy and other relationships can be suggested and reinforced by common sense graphic design, using standard principles of size, proximity, weight, contrast and the like. URLs are different. Rather than suggest or provide cues, they unambiguously impose hierarchical structure.
This is not much of an issue for pure blog sites or portfolio sites where the author is showcasing one type of thing or focusing on a well-defined set of topics and the containers are obvious and self-evident. It’s more of an issue with typographic magazine sites with large amounts of complex HTML content.
All this stuff needs to live somewhere in URL addressable units. For me, getting it right looks like a content structure with URL patterns robust and simple enough to support whatever weird changing needs I have over the next 5–10 years without constantly having to ask questions about where something new fits or think about redesigning again.
I also feel like a lot of major decisions around navigation and content types flow on quite directly from the decisions around URL structure (and with a good URL structure, it should be possible to change navigation in-place without tearing the whole thing down and starting over).
Cool URIs don’t change
Mentioning this ridiculous document of the early web and the nebulous absolutely non-zeitgeist concept of IA in 2021 has probably already made this redesign feel seriously uncool.
For generations of designers older than me, information architecture is more likely suggestive of mid 20th century innovations in graphic navigational systems, the work of Richard Saul Wurman, Otto Neurath’s ISOTYPE or Massimo Vignelli’s NY subway map. It’s essentially a meaningless term in the fractured and fragmented frontend engineering culture of the web today where jargon terms like UX and DX are not infrequently used as verbs as well as nouns.
I’m having none of it. I’m using information architecture as a binding term because it’s still a broadly relevant shorthand that covers the fundamentals of making websites. In the applied context, it doesn’t really matter exactly what we choose to call it. The important thing is to have language and processes that explicitly acknowledge and seek to tame the unique structural problems and questions of publishing to this shared global address space.
In order for web design like this to effectively cohere, we want to discuss problems at a higher level of abstraction than the specific technologies of the web itself. That means making sense of messes, playing with structure and thinking creatively about containers, nesting, relationships between things, navigational pathways, visual and semantic anchors, focal points and taxonomies.
The pinprick of sun through a magnifying glass
I don’t want to spend a lot of time combing through old archived crap. I want to sketch things quickly to get a clear sense of where this needs to go without needing to do an exhaustive content audit and review of everything (something I’d usually be excited to do, but with my own personal writing it will take a while and is demotivating).
I can probably work through most of the main decisions by drawing up a table representing the mapping between different URL templates and content types. Content structure, I still have no idea what I’m doing so it’s vaguely a free text description at this stage.
| Content type | Content structure | URI template |
|---|---|---|
| essays | Flat list | /essays/ |
| essay | Essay document | /essays/{name}/ |
| talks | Flat list | /talks/ |
| talk | Embedded slideshow | /talks/{name}/ |
| transcript | Presentation document | /talks/{name}/ |
| projects | Single page list | /projects/ |
| about | Single content page | /about/ |
| notebook | Nested list | /notes/{notebook}/ |
| notes | Note document | /notes/{notebook}/{name} |
| reading notes | Note + Book document | /notes/reading/{name} |
Essays and talks seem robust and fine as they are straightforward blog/entry/RSS style collections of entries and are easy to maintain over time. So I probably don’t need to make any big changes there—just deal with the archiving and template polymorphism a bit better.
Projects needs a top-to-bottom redesign. I’m working on completely different things right now, and the site needs to reflect that.
Notebooks and notes. Should they be thrown on a fire and burned, torn to pieces in a frantic restructure, or simply left to bitrot? The lack of clarity is obvious in the list pages being completely mangled in the current state. So I can start there.
Once I address these problems with the resilience and (in)coherence of content types and URL structures and fix impediments to the free flow of writing onto the site, I’ll be in a better place to reasess visual design and typography and finish off any additional decluttering that needs to be done.
It does seem like a lot to ask for but I have learned the hard way that if I don’t set things up to be as robust, automated and stupid-simple as possible, I won’t be motivated to maintain it or keep writing frequently enough to realise my vision for the site.