An Ars Technica history of the Internet, part 1 - Ars Technica
Here’s a fun account of the early days of the ARPANET.
Here’s a fun account of the early days of the ARPANET.
A workshop on resilient CSS layouts
Oh, hell yes!
Do not hesitate—sign yourself up to this series of three online workshops by Miriam. This is the quickest to level up your working knowledge of the most powerful parts of CSS.
By the end of this you’re going to feel like Neo in that bit of The Matrix when he says “I know kung-fu!” …except kung-fu isn’t very useful for building resilient and maintainable websites, whereas modern CSS absolutely is.
For the past couple of years, myself and Jessica have been going to the Belfast Tradfest in the Summer. It’s an excellent event with great workshops, sessions, and concerts. And it helps that Belfast is such a lovely city to spend a week in.
What struck me the first time we were participating in workshops thre was the great mix of age ranges. It always warms my heart to see young people getting really into the music.
Then I found out about their bursary sponsorship scheme:
For many young musicians, financial barriers stand in the way of this invaluable experience. Your support can make a real difference by sponsoring a bursary that covers the cost of tuition for a deserving student.
Last year, I decided to forego one month’s worth of donations to The Session—the contributions that help cover the costs of hosting, newsletters, geocoding, and so on. Instead the money went towards bursary sponsorships for Belfast Tradfest.
It was a great success that managed to cover places for quite a few young musicians.
Normally, I wouldn’t mention the ins-and-outs of TheSession.org over here on adactio.com but I thought you might like to partake in this year’s fund drive:
For the month of April 2025, any donations made to The Session will go towards bursary sponsorships for young musicians to attend workshops at this year’s Belfast Trad Fest:
Maybe you’ve liked something I’ve written here. Maybe you enjoyed Resilient Web Design, the free book I published online. You can also read HTML5 For Web Designers and Going Offline for free now too.
I’ve never asked for any recompense for my online ramblings, but if you’ve ever wanted to drop me some money to thank me for something I’ve put out there, now’s your chance.
Any contribution you make will go towards fostering the next generation of traditional Irish musicians, something that’s very dear to my heart.
Grim reading from the games industry, especially if you work at Shopify where the CEbrO has just mandated that you have to use this shite.
Here’s the main problem I’ve found with generative AI, and with “vibe coding” in general: it completely sucks out the joy of software development for me.
I hate the way they’ve taken over the software industry, I hate how they make me feel while I’m using them, and I hate the human-intelligence-insulting postulation that a glorified Excel spreadsheet can do what I can but better.
We trained people to care deeply and then funnelled them into environments that reward detachment. And the longer you stick around, the more disorienting the gap becomes – especially as you rise in seniority. You start doing less actual design and more yapping: pitching to stakeholders, writing brand strategy decks, performing taste. Less craft, more optics; less idealism, more cynicism.
- Support open source software
- Support open web platform technology
- Distribution on the web should never be throttled
- External links should be encouraged, not de-emphasized
I can’t recommend React to any project or customer anymore.
Using almost any other modern alternative, you will save time, money and nerves, even if you haven’t used them before.
Don’t stick to technology just because you know it.
Dan wrote an interesting post with a somewhat clickbaity title; This Competition Exposed How AI is Reshaping Design:
I watched two designers go head-to-head in a high-speed battle to create the best landing page in 45 minutes. One was a seasoned pro. The other was a non-designer using AI.
If you can ignore the title (and the fact that Dan still actively posts on Twitter; something I find very hard to ignore), then there’s a really thoughtful analysis in there.
It’s less about one platform or tool vs. another more than it is a commentary on how design happens, and whether or not that’s changing in a significant way.
In particular, there’s a very revealing graph that shows the pros and cons of both approaches.
There’s no doubt about it, using a generative large language model helped a non-designer to get past the blank page. But it was less useful in subsequent iterations that rely on decision-making:
I’ve said it before and I’ll say it again: design is deciding. The best designers are the best deciders.
Dan finishes by saying that what he’d really like to see is an experienced designer/decider using these tools to turbo-boost their process:
AI raises the floor for non-designers. But can it raise the ceiling for designers?
Meanwhile, Matt has been writing about Vibe-designing. Matt is an experienced designer, but he’s not experienced with Figma. He’s found that he can work around that using a large language model:
Where in the past 30 years I might have had to cajole a more technically adept colleague into making something through sketches, gesticulating and making sound effects – I open up a Claude window and start what-iffing.
The “vibe” part of the equation often defaults to the mean, which is not a surprise when you think about what you’re asking to help is a staggeringly-massive machine for producing generally-unsurprising satisfactory answers quickly. So, you look at the output as a basis for the next sketch, and the next sketch and quickly, together, you move to something more novel as a result.
Interesting! Just as Dan insisted, the important work is making the decision and moving on to the next stage. If the actual outputs at each stage are mediocre, that seems to be okay, as long as they’re just good enough to inform a go/no-go decision.
This certainly seems more centaur-like than the usual boring uses of large language models to simply do what people are already doing.
Rich gets at something similar when he talks about using large language models for prototyping, where it’s okay if the code is kind of shitty:
If all you need is crappy code to try out a concept or a solution, then an LLM might well enable you (the designer) to do that.
Mind you, even if you do end up finding useful and appropriate ways to use these tools, you’re still using a tool built on exploitation and unfairness:
It’s hard (and reckless) to ignore the heartfelt and cogent perspective laid out by Miriam on the role of AI companies in the current geopolitical crisis:
When eugenics-obsessed billionaires try to sell me a new toy, I don’t ask how many keystrokes it will save me at work. It’s impossible for me to discuss the utility of a thing when I fundamentally disagree with the purpose of it.
So, let’s start with a simple premise: how can we make design less opaque and encourage teams to make small changes more efficiently? Not every product decision needs to be a big, complicated design process.
This checklist, in four parts, is meant to be a simple, lightweight way for the team to get the ‘gist’ of the issue and make a shared decision quickly. It’s a starting point, a way to get the critical information in once place so the entire team can understand and discuss. The four parts are:
- Gather: Bring the right info together into a single place
- Impact: List the size of the problem and possible risks
- Sketch: Create a preliminary sketch of a solution
- Team Huddle: Get the product team to discuss and agree on a solution.
This is a really thoughtful piece by Rich, who’s got conflicted feelings about large language models in the design process. I suspect a lot of people can relate to this.
What I do know is that I find LLMs useful on occasion, but every time I use one I die a little inside.
Practice Progressive Enhancement.
Build first and foremost with forgiving technologies, declarative technologies, and forward and backward compatible coding techniques.
All content should be readable without scripting.
If it’s worth building on the web, it’s worth building it robustly, and building it to last.
I like the look of this proposal that would allow authors to have more control over network priorities for third-party iframes—I’ve already documented how I had to use a third-party library to fix this problem on the Salter Cane site.
Check it out—here’s the line-up for UX London 2025!
This is going to be so good! Grab a ticket if you haven’t got one yet.
UX London takes place over three days, from June 10th to 12th at a fantastic venue in the heart of the city. To get the full experience, you should come for all three days. But you can also get a ticket for individual days. Each day has a focus, and when you put them all together, the whole event mirrors the design process:
Each day features a morning of talks, followed by an afternoon of workshops. The talks are on a single track; four consecutive half-hour presentations to get you inspired. Then after lunch, you choose from one of four workshops. All the workshops are two and half hours long and very hands-on. No laptop required.
On discovery day you’ll have talks in the morning about research, content design, strategy and evaluating technology, followed by workshops on discovery and definition and behavioural design.
On design day there’ll be talks on interface design, a healthcare case study, inclusive design, and typography, followed by workshops in the afternoon on data visualisation and ethics.
Finally on delivery day you’ll get talks on conversion design, cross-team collaboration, convincing stakeholders, and improving design critiques, followed by workshops on facilitating workshops and getting better at public speaking.
Every workshop is repeated on another day so you’ll definitely get the chance to attend the one you want.
Oh, and at the end of every day there’ll be a closing keynote. Those are yet to be revealed, but I can guarantee they’re going to be top-notch!
Right now you can get early-bird tickets for all three days, or individual days. That changes from March 15th, when the regular pricing kicks in—a three-day ticket will cost £200 more. So I’d advise you to get your ticket now.
If you need to convince your boss, show them this list of reasons to attend.
See you there!
This describes how I like to work too.
I’m not a fan of Nicholas Carr and his moral panics, but this is an excellent dive into some historical media theory.
What Innis saw is that some media are particularly good at transporting information across space, while others are particularly good at transporting it through time. Some are space-biased while others are time-biased. Each medium’s temporal or spatial emphasis stems from its material qualities. Time-biased media tend to be heavy and durable. They last a long time, but they are not easy to move around. Think of a gravestone carved out of granite or marble. Its message can remain legible for centuries, but only those who visit the cemetery are able to read it. Space-biased media tend to be lightweight and portable. They’re easy to carry, but they decay or degrade quickly. Think of a newspaper printed on cheap, thin stock. It can be distributed in the morning to a large, widely dispersed readership, but by evening it’s in the trash.
Want to use all those great features that have been in landing in browsers over the past year or two? View transitions! Scroll-driven animations! So much more!
Well, your coding co-pilot is not going to going to be of any help.
Large language models, especially those on the scale of many of the most accessible, popular hosted options, take humongous datasets and long periods to train. By the time everything has been scraped and a dataset has been built, the set is on some level already obsolete. Then, before a model can reach the hands of consumers, time must be taken to train and evaluate it, and then even more to finally deploy it.
Once it has finally released, it usually remains stagnant in terms of having its knowledge updated. This creates an AI knowledge gap. A period between the present and AI’s training cutoff. This gap creates a time between when a new technology emerges and when AI systems can effectively support user needs regarding its adoption, meaning that models will not be able to service users requesting assistance with new technologies, thus disincentivising their use.
So we get this instead:
I’ve anecdotally noticed that many AI tools have a ‘preference’ for React and Tailwind when asked to tackle a web-based task, or even to create any app involving an interface at all.
In which Rich nails Clearleft’s superpower:
“Clearleft is a relatively small team, but we can achieve big results because we are nimble and extremely experienced. As strategic design partners, we have a privileged position where we can work around a large company’s politics,” Rutter said. “We need to understand those politics — and help the client staff navigate them — but we don’t need to be bound by them. We bring a thoroughly user-centered approach to our design partnership, and that can be something novel to companies. By showing them what good design looks like (not so much the interface, as the actual process of getting to really well-designed products and services), we can be disruptive within the organization and leave them in a much better place.”
If I was only able to give one bit of advice to any company: iterate quickly on a slow-moving platform.
Excellent advice from Harry (who first cast his pearls before the swine of LinkedIn but I talked him ‘round to posting this on his own site).
- Opt into web platform features incrementally
- Embrace progressive enhancement to build fast, reliable applications that adapt to your customers’ context
- Write code that leans into the browser, not away from it
I’m not against front-end frameworks, and, believe me, I’m not naive enough to believe that the only thing a front-end framework provides is soft navigations, but if you’re going to use one, I shouldn’t be able to smell it.
Many interactions are not possible without JavaScript, but that doesn’t mean we should look to write more than we have to. The server doing something useful is a requirement for building an interesting business. The client doing something is often a nice-to-have.
There’s also this:
It’s really fast
One of the arguments for a SPA is that it provides a more reactive customer experience. I think that’s mostly debunked at this point, due to the performance creep and complexity that comes in with a more complicated client-server relationship.