In Search of Lost Time, by Tom Vanderbilt
Temporal standards bodies.
Temporal standards bodies.
Ethan highlights a classic case of the McNamara Fallacy—measuring adoption of design system components.
So, if progressive enhancement is no more expensive to create, future-proof, provides us with technical credit, and ensures that our users always receive the best possible experience under any conditions, why has it fallen by the wayside?
Because before, when you clicked on a link, the browser would go white for a moment.
This describes how I iterate on The Session:
It comes down to this annoying, upsetting, stupid fact: the only way to build a great product is to use it every day, to stare at it, to hold it in your hands to feel its lumps. The data and customers will lie to you but the product never will.
This whole post reminded of the episode of the Clearleft podcast on measuring design.
The problem underlying all this is that when it comes to building a product, all data is garbage, a lie, or measuring the wrong thing. Folks will be obsessed with clicks and charts and NPS scores—the NFTs of product management—and in this sea of noise they believe they can see the product clearly. There are courses and books and talks all about measuring happiness and growth—surveys! surveys! surveys!—with everyone in the field believing that they’ve built a science when they’ve really built a cult.
Matt made this lovely website for spelunking and hyperlinking through the thousand episodes of Radio 4’s excellent In Our Time programme.
He’s also written a little bit about how he made it using some AI (artificial insemination) for the categorisation code.
The whole article is great, and really charmingly written, with some golden nuggets embedded within, like:
- You’ll find that spending more time getting HTML right reveals or even anticipates and evades accessibility issues. It’s just easier to write accessible code if it’s got semantic foundations.
- In my experience, you will almost always spend more time overriding frameworks or compromising your design to fit the opinions of a framework.
- Always style from the absolute smallest screen your content will be rendered on first, and use
@media (min-width)queries to break to layouts that allow for more real estate as it becomes available.
- Always progressively enhance your apps, especially when you’re fucking with something as browser-critical as page routing.
Strong—and true—words from Alex.
Frontend’s failure to deliver in today’s mostly-mobile, mostly-Android world is shocking, if only for the durability of the myths that sustain the indefensible. We can’t keep doing this.
If you disagree, I encourage you to dive into the data that Alex shares.
It sounds like Remix takes a sensible approach to progressive enhancement.
This extract from Baldur’s new book is particularly timely in light of the twipocalypse.
I’ve seen the pendulum swing back and forth many times over my years building on the web. I too feel like there’s something in the air right now, and people are finally acknowledging that most single page apps are crap.
So now the world of web components has egg on its face because the zeitgeist at the time of its design didn’t have such a strong focus on SSR/HTML-first/ progressive enhancement. Had web components been designed in the current zeitgeist, things would almost certainly be different.
One for the server - where you can go wild.
One for the client - that should be thoughtful and careful.
Yes! This! I’m always astounded to see devs apply the same mindset to backend and frontend development, just because it happens to be in the same language. I don’t care what you use on your own machine or your own web server, but once you’re sending something down the wire to end users, you need to prioritise their needs over your own.
I think that’s the primary benefit to developers. The primary benefit to users is that what you build will faster and more resilient.
Anyway, this is a really good deep dive into different architectural choices for building on the web. Although I was surprised by this assertion in the first paragraph:
The most popular architecture employed by web developers today is the Single Page App (SPA)
Citation needed. Single Page Apps do indeed dominate the discussion, but I don’t think that necessarily matches the day-to-day reality.
A really good explanation of progressive enhancement as an approach to building anything on the web:
A drop-in replacement for Google Fonts without the tracking …but really, you should be self-hosting your font files.
There’s a repeated catchphrase used throughout Christopher Nolan’s film Tenet: ignorance is our ammunition.
There are certainly situations where knowledge is regrettable. The somewhat-silly thought experiment of Roko’s basilisk is one example. Once you have knowledge of it, you can’t un-know it, and so you become complicit.
Or, to use another example, I think it was Jason who told me that if you want to make someone’s life miserable, just teach them about typography. Then they’ll see all the terrible kerning out there in the world and they won’t be able to un-see it.
I sometimes wish I could un-learn all I’ve learned about cryptobollocks (I realise that the term “cryptocurrency” is the more widely-used phrase, but it’s so inaccurate I’d rather use a clearer term).
I sometimes wish I could go back to having the same understanding of cryptobollocks as most people: some weird new-fangled technology thing that has something to do with “the blockchain.”
But I delved too deep. I wanted to figure out why seemingly-smart people were getting breathlessly excited about something that sounds fairly ludicrous. Yet the more I learned, the more ludicrous it became. Bitcoin and its ilk are even worse than the occassional headlines and horror stories would have you believe.
The reason I have such a visceral reaction to crypto projects isn’t just that they’re irresponsibly designed and usually don’t achieve what they promise. It’s also that the thing they promise sounds like a fucking nightmare.
Or, as Simon responded to someone wondering why there was so much crypto hate:
We hate it because we understand it.
I have yet to encounter a crypto project that isn’t a Ponzi scheme. I don’t mean like a Ponzi scheme. I mean they’re literally Ponzi schemes: zero-sum racing to the bottom built entirely on the greater fool theory. The only difference between traditional Ponzi schemes and those built on crypto is that crypto isn’t regulated. Yet.
I recently read The Glass Hotel by Emily St. John Mandel, a novel with the collapse of a Ponzi scheme at its heart. In the aftermath of the scheme’s collapse, there are inevitable questions like “How could you not know?” The narrator answers that question:
It’s possible to both know and not know something.
I’ve been thinking about that a lot.
Spoiler: the answer to the question in the title is a resounding “hell yeah!”
Scott brings receipts.
We often talk about technical debt — the costs we’ll need to pay in the future when we make short-term compromises. Progressive enhancement is the opposite of that — a sort of technical credit that will make things easier for us in the future.
A good explanation of how progressive enhancement works perfectly with the idea of a minimal viable product:
We focus first on a core experience that delivers what your users are looking for, and then we start adding enhancements that will delight them.
If you’re travelling around Ireland, you may come across some odd pieces of 19th century architecture—walls, bridges, buildings and roads that serve no purpose. They date back to The Great Hunger of the 1840s. These “famine follies” were the result of a public works scheme.
The thinking went something like this: people are starving so we should feed them but we can’t just give people food for nothing so let’s make people do pointless work in exchange for feeding them (kind of like an early iteration of proof of work for cryptobollocks on blockchains …except with a blockchain, you don’t even get a wall or a road, just ridiculous amounts of wasted energy).
This kind of thinking seems reprehensible from today’s perspective. But I still see its echo in the work ethic espoused by otherwise smart people.
Here’s the thing: there’s good work and there’s working hard. What matters is doing good work. Often, to do good work you need to work hard. And so people naturally conflate the two, thinking that what matters is working hard. But whether you work hard or not isn’t actually what’s important. What’s important is that you do good work.
If you can do good work without working hard, that’s not a bad thing. In fact, it’s great—you’ve managed to do good work and do it efficiently! But often this very efficiency is treated as laziness.
Sensible managers are rightly appalled by so-called productivity tracking because it measures exactly the wrong thing. Those instruments of workplace surveillance measure inputs, not outputs (and even measuring outputs is misguided when what really matters are outcomes).
They can attempt to measure how hard someone is working, but they don’t even attempt to measure whether someone is producing good work. If anything, they actively discourage good work; there’s plenty of evidence to show that more hours equates to less quality.
I used to think that must be some validity to the belief that hard work has intrinsic value. It was a position that was espoused so often by those around me that it seemed a truism.
But after a few decades of experience, I see no evidence for hard work as an intrinsically valuable activity, much less a useful measurement. If anything, I’ve seen the real harm that can be caused by tying your self-worth to how much you’re working. That way lies burnout.
We no longer make people build famine walls or famine roads. But I wonder how many of us are constructing little monuments in our inboxes and calendars, filling those spaces with work to be done in an attempt to chase the rewards we’ve been told will result from hard graft.
I’d rather spend my time pursuing the opposite: the least work for the most people.
This is kind of brilliant:
Maybe what’s needed for websites and web apps is a kind of Prepper Web Dev?
Though I didn’t make the connection until much later, the philosophy of progressive enhancement in web design, which I’ve been advocating for nearly two decades now, is very much the embodiment of equity. It’s concerned with building interfaces that adapt to a wide range of circumstances, both tied to an individual user’s capabilities as well as those of the devices, networks, and environment in which they are accessing our creations.