Make yourself a nice cup of tea and settle in with Julian Gough’s magnum opus:
How early, sustained, supermassive black hole jets carved out cosmic voids, shaped filaments, and generated magnetic fields
A fascinating look at the modern equivalent of the Longitude problem.
About halfway through this talk transcript, Aaron starts dropping a barrage of truth bombs:
I understand the web, whose distinguishing characteristic is asynchronous recall on a global scale, as the technology which makes revisiting possible in a way that has genuinely never existed before the web.
What the web has made possible are the economics of keeping something, something which has not enjoyed “hockey stick growth”, around long enough for people to warm up to it. Or to survive long past the moment when people may have grown tired of it.
If your goal is to build something which is designed to flip inside of ten years, like many things in the private sector, that may not seem like a very compelling argument.
If, however, your goal is to build something to match the longevity of the cultural heritage sector, to meet the goal of fostering revisiting, or for novel ideas to outlast the reluctance of the present and to do so at a global scale, or really any scale larger than shouting distance, then I will challenge you to find a better vehicle for doing so than the internet, and the web in particular.
Strong Deb Chachra vibes in this ongoing series by Charles C. Mann:
he great European cathedrals were built over generations by thousands of people and sustained entire communities. Similarly, the electric grid, the public-water supply, the food-distribution network, and the public-health system took the collective labor of thousands of people over many decades. They are the cathedrals of our secular era. They are high among the great accomplishments of our civilization. But they don’t inspire bestselling novels or blockbuster films. No poets celebrate the sewage treatment plants that prevent them from dying of dysentery. Like almost everyone else, they rarely note the existence of the systems around them, let alone understand how they work.
Pondering pace layers.
- People only understand things relative to things they already understand
- People only understand things in context
- People rely on patterns and consistency
- People seek to minimize cognitive load
- People have varying levels of expertise and familiarity
- People are goal-oriented
- People often don’t know what they’re looking for
- Information is more useful when it’s actionable
A fascinating in-depth look at the maintenance of undersea cables:
The industry responsible for this crucial work traces its origins back far beyond the internet, past even the telephone, to the early days of telegraphy. It’s invisible, underappreciated, analog.
It’s a truism that people don’t think about infrastructure until it breaks, but they tend not to think about the fixing of it, either.
Powerful metaphors in this piece by Maria Farrell and Robin Berjon on the Waldsterben of the internet:
Our online spaces are not ecosystems, though tech firms love that word. They’re plantations; highly concentrated and controlled environments, closer kin to the industrial farming of the cattle feedlot or battery chicken farms that madden the creatures trapped within.
We all know this. We see it each time we reach for our phones. But what most people have missed is how this concentration reaches deep into the internet’s infrastructure — the pipes and protocols, cables and networks, search engines and browsers. These structures determine how we build and use the internet, now and in the future.
Great stuff from Maggie—reminds of the storyforming workshop I did with Ellen years ago.
Mind you, I disagree with Maggie about giving a talk’s outline at the beginning—that’s like showing the trailer of the movie you’re about to watch.
A fascinating look at the connections between hypertext and film editing. I’m a sucker for any article that cites both Ted Nelson and Walter Murch.
This extract from Deb Chachra’s new book confirms that it’s a must-read. The writing fairly sings with infectious enthusiasm!
A terrific interview with Deb Chachra. Her new book, How Infrastructure Works sounds excellent!
Back in 2017 when I was in New York, I went on a self-guided infrastructure tour: 32 Avenue of the Americas, 60 Hudson Street, and the subject of this article, 33 Thomas Street. One of my pictures is used to illustrate its creepiness, both in real life and as an evil lair in fiction:
A windowless telecommunications hub, 33 Thomas Street in New York City embodies an architecture of surveillance and paranoia. That has made it an ideal set for conspiracy thrillers.
The slides and transcript from a great talk by Maggie Appleton, including this perfect description of the vibes we get from large language models:
It feels like they’re either geniuses playing dumb or dumb machines playing genius, but we don’t know which.
Gosh! And I thought I had strong opinions about markup!
It’s often said that it’s easier to make a fast website than it is to keep a website fast. Things slip through. If you’re not vigilant, performance can erode without you noticing.
It’s a similar story for other invisible but important facets of your website: privacy, security, accessibility. Because they’re hidden from view, you won’t be able to see if there’s a regression.
That’s why it’s a good idea to have regular audits for performance, privacy, security, and accessibility.
I wrote about accessibility testing a while back, and how there’s quite a bit that you can do for yourself before calling in an expert to look at the really gnarly stuff:
When you commission an accessibility audit, you want to make sure you’re getting the most out of it. Don’t squander it on issues that you can catch and fix yourself. Make sure that the bulk of the audit is being spent on the specific issues that are unique to your site.
I recently did an internal audit of the Clearleft website. After writing up the report, I also did a lunch’n’learn to share my methodology. I wanted to show that there’s some low-hanging fruit that pretty much anyone can catch.
To start with, there’s keyboard navigation. Put your mouse and trackpad to one side and use the tab key to navigate around.
Caveat: depending on what browser you’re using, you might need to update some preferences for keyboard navigation to work on links. If you’re using Safari, go to “Preferences”, then “Advanced”, and tick “Press Tab to highlight each item on a web page.”
Tab around and find out. You should see some nice chunky :focus-visible styles on links and form fields.
Here’s something else that anyone can do: zoom in. Increase the magnification to 200%. Everything should scale proportionally. How about 500%? You’ll probably see a mobile-friendly layout. That’s fine. As long as nothing is broken or overlapping, you’re good.
At this point, I reach for some tools. I’ve got some bookmarklets that do similar things: tota11y and ANDI. They both examine the source HTML and CSS to generate reports on structure, headings, images, forms, and so on.
These tools are really useful, but you need to be able to interpret the results. For example, a tool can tell you if an image has no alt text. But it can’t tell you if an image has good or bad alt text.
Likewise, these tools are great for catching colour-contrast issues. But there’s a big difference between a colour-contrast issue on the body copy compared to a colour-contrast issue on one unimportant page element.
I think that demonstrates the most important aspect of any audit: prioritisation.
Finding out that you have accessibility issues isn’t that useful if they’re all presented as an undifferentiated list. What you really need to know are which issues are the most important to fix.
By the way, I really like the way that the Gov.uk team prioritises accessibility concerns:
The team puts accessibility concerns in 2 categories:
- Theoretical: A question or statement regarding the accessibility of an implementation within the Design System without evidence of real-world impact.
- Evidenced: Sharing new research, data or evidence showing that an implementation within the Design System could cause barriers for disabled people.
The team will usually prioritise evidenced issues and queries over theoretical ones.
When I wrote up my audit for the Clearleft website, I structured it in order of priority. The most important things to fix are at the start of the audit. I also used a simple scale for classifying the severity of issues: low, medium, and high priority.
Thankfully there were no high-priority issues. There were a couple of medium-priority issues. There were plenty of low-priority issues. That’s okay. That’s a pretty good distribution.
If you’re interested, here’s the report I delivered…
There are a few issues with the pink colour. When it’s used on a grey background, or when it’s used as a background colour for white text, the colour contrast isn’t high enough.
The SVG arrow icon could be improved too.
--red is currently rgb(234, 33, 90). Change it to rgb(210, 20, 73) (thanks, James!)currentColor. Consider hardcoding solid black (or a very, very dark grey) instead.Alt text is improving on the site. There’s reasonable alt text at the top level pages and the first screen’s worth of case studies and blog posts. I made a sweep through these pages a while back to improve the alt text but I haven’t done older blog posts and case studies.
The site is using headings sensibly. Sometimes the nesting of headings isn’t perfect, but this is a low priority issue. For example, on the contact page there’s an h1 followed by two h3s. In theory this isn’t correct. In practice (for screen reader users) it’s not an issue.
h3 instead of h1.h3 headings for the industry sector (“Charities”, “Education” etc.) but these should probably not be headings at all. On the blog index page we use a class “Tags” for a similar purpose. Consider reusing that pattern on the case studies index page.h3 and the subsequent three headings are h2s. Ideally this would be reversed: a single h2 followed by three h3s.Sometimes the same text is used for different links.
The only form on the site is the newsletter sign-up form. It’s marked up pretty well: the input has an associated label, although a visible (clickable) label would be better.
The site doesn’t use JavaScript to mess with tabbing order for keyboard users. The source order of elements in the markup generally makes sense so all is good.
The focus styles are nice and clear too!
The site is using HTML landmark elements sensibly (header, nav, main, footer, etc.).
I’ve always liked the idea that your website can be your API. Like, you’ve already got URLs to identify resources, so why not make that URL structure predictable and those resources parsable?
That’s why the (read-only) API for The Session doesn’t live at a separate subdomain. It uses the same URL structure as the regular site, but you can request the resources in an alternative format: JSON, XML, RSS.
This works out pretty well, mostly because I put a lot of thought into the URL structure of the site. I’m something of a URL fetishist, but I think that taking a URL-first approach to information architecture can be a good exercise.
Most of the resources on The Session involve nouns like tunes, events, discussions, and so on. There’s a consistent and predictable structure to the URLs for those sections:
/things/things/new/things/searchAnd then an idividual item can be found at:
things/IDThat’s all nice and predictable and the naming of the URLs matches what you’d expect to find:
Tunes, events, discussions, sessions. Those are all fine. But there’s one section of the site that has this root URL:
When I was coming up with the URL structure twenty years ago, it was clear what you’d find there: track listings for albums of music. No one would’ve expected to find actual recordings of music available to listen to on-demand. The bandwidth constraints and technical limitations of the time made that clear.
Two decades on, the situation has changed. Now someone new to the site might well expect to hit a link called “recordings” and expect to hear actual recordings of music.
So I should probably change the label on the link. I don’t think “albums” is quite right—what even is an album any more? The word “discography” is probably the most appropriate label.
Here’s my dilemma: if I update the label, should I also update the URL structure?
Right now, the section of the site with /tunes URLs is labelled “tunes”. The section of the site with /events URLs is labelled “events”. Currently the section of the site with /recordings URLs is labelled “recordings”, but may soon be labelled “discography”.
If you click on “tunes”, you end up at /tunes. But if you click on “discography”, you end up at /recordings.
Is that okay? Am I the only one that would be bothered by that?
I could update the URLs to match the labelling (with redirects for the old URLs, of course), but I’m not so keen on this URL structure:
/discography/discography/new/discography/search/discography/IDIt doesn’t seem as tidy as:
/recordings/recordings/new/recordings/search/recordings/IDBut if I don’t update the URLs to match the label, then I’m just going to have to live with the mismatch.
I’m just thinking out loud here. I think I should definitely update the label. I just won’t make any decision on changing URLs for a while yet.
I was talking to someone recently about a forgotten battle in the history of the early web. It was a battle between search engines and directories.
These days, when the history of the web is told, a whole bunch of services get lumped into the category of “competitors who lost to Google search”: Altavista, Lycos, Ask Jeeves, Yahoo.
But Yahoo wasn’t a search engine, at least not in the same way that Google was. Yahoo was a directory with a search interface on top. You could find what you were looking for by typing or you could zero in on what you were looking for by drilling down through a directory structure.
Yahoo wasn’t the only directory. DMOZ was an open-source competitor. You can still experience it at DMOZlive.com:
The official DMOZ.com site was closed by AOL on February 17th 2017. DMOZ Live is committed to continuing to make the DMOZ Internet Directory available on the Internet.
Search engines put their money on computation, or to use today’s parlance, algorithms (or if you’re really shameless, AI). Directories put their money on humans. Good ol’ information architecture.
It turned out that computation scaled faster than humans. Search won out over directories.
Now an entire generation has been raised in the aftermath of this battle. Monica Chin wrote about how this generation views the world of information:
Catherine Garland, an astrophysicist, started seeing the problem in 2017. She was teaching an engineering course, and her students were using simulation software to model turbines for jet engines. She’d laid out the assignment clearly, but student after student was calling her over for help. They were all getting the same error message: The program couldn’t find their files.
Garland thought it would be an easy fix. She asked each student where they’d saved their project. Could they be on the desktop? Perhaps in the shared drive? But over and over, she was met with confusion. “What are you talking about?” multiple students inquired. Not only did they not know where their files were saved — they didn’t understand the question.
Gradually, Garland came to the same realization that many of her fellow educators have reached in the past four years: the concept of file folders and directories, essential to previous generations’ understanding of computers, is gibberish to many modern students.
We are finding a persistent issue with getting (undergrad, new to research) students to understand that a file/directory structure exists, and how it works. After a debrief meeting today we realized it’s at least partly generational.
We live in a world ordered only by search:
While some are quite adept at using labels, tags, and folders to manage their emails, others will claim that there’s no need to do because you can easily search for whatever you happen to need. Save it all and search for what you want to find. This is, roughly speaking, the hot mess approach to information management. And it appears to arise both because search makes it a good-enough approach to take and because the scale of information we’re trying to manage makes it feel impossible to do otherwise. Who’s got the time or patience?
There are still hold-outs. You can prise files from Scott Jenson’s cold dead hands.
More recently, Linus Lee points out what we’ve lost by giving up on directory structures:
Humans are much better at choosing between a few options than conjuring an answer from scratch. We’re also much better at incrementally approaching the right answer by pointing towards the right direction than nailing the right search term from the beginning. When it’s possible to take a “type in a query” kind of interface and make it more incrementally explorable, I think it’s almost always going to produce a more intuitive and powerful interface.
Directory structures still make sense to me (because I’m old) but I don’t have a problem with search. I do have a problem with systems that try to force me to search when I want to drill down into folders.
I have no idea what Google Drive and Dropbox are doing but I don’t like it. They make me feel like the opposite of a power user. Trying to find a file using their interfaces makes me feel like I’m trying to get a printer to work. Randomly press things until something happens.
Anyway. Enough fist-shaking from me. I’m going to ponder Linus’s closing words. Maybe defaulting to a search interface is a cop-out:
Text search boxes are easy to design and easy to add to apps. But I think their ease on developers may be leading us to ignore potential interface ideas that could let us discover better ideas, faster.
I really, really enjoyed this deep dive into practical HTML semantics. Sit back and enjoy!