Archive: August, 2023

The 100-Year Plan on WordPress.com

Some really interesting long-term thinking from Matt—it’ll be interesting to see the terms and conditions.

The ideal viewport doesn’t exist

Some lovely scroll-driven animations illustrate this great little microsite.

There’s something very pleasy about the chunky design that harkens back to the Zeldmanesque early web.

How Google made the world go viral - The Verge

On the sad state of Google search today:

How did a site that captured the imagination of the internet and fundamentally changed the way we communicate turn into a burned-out Walmart at the edge of town?

I managed to get out and play in trad sessions for four days straight: Sunday, Monday, Tuesday, and Wednesday.

Today I rest. Or rather, I pack.

There won’t be any Irish music sessions in my calendar for at least the next two weeks. There won’t be much of anything in my calendar. I’m about to be incommunicado as I travel to Amerikay on the wide Atlantic ocean.

You might have seen that video that’s been doing the rounds about how cruise ships got so big. I’m not going on a cruise. I’m going on a crossing. That video ends with:

There are over 320 cruise ships sailing around the world right now. But there’s only one ocean liner left. The Queen Mary 2.

That’s going to be my mode of transportation and my home for the next week.

Then I’ll be in New York for a weekend, followed by most of a week lying on St. Augustine beach in Florida.

All of my sparklines are about to flatline for a while: no blog posts, no links, no notes. I won’t have any internet access on board the ship.

Time for me to switch off my work email. I thought about setting up an autoresponder to let people know that I won’t be replying to their email for a few weeks. But then I thought, how is that any different from how I normally respond to email?

Undersea Cables by Rishi Sunak [PDF]

Years before becoming Prime Minister of the UK, Rishi Sunak wrote this report, Undersea Cables: Indispensable, insecure.

I just described prototype code as code to be thrown away. On that topic…

I’ve been observing how people are programming with large language models and I’ve seen a few trends.

The first thing that just about everyone agrees on is that the code produced by a generative tool is not fit for public consumption. At least not straight away. It definitely needs to be checked and tested. If you enjoy debugging and doing code reviews, this might be right up your street.

The other option is to not use these tools for production code at all. Instead use them for throwaway code. That could be prototyping. But it could also be the code for those annoying admin tasks that you don’t do very often.

Take content migration. Say you need to grab a data dump, do some operations on the data to transform it in some way, and then pipe the results into a new content management system.

That’s almost certainly something you’d want to automate with bespoke code. Once the content migration is done, the code can be thrown away.

Read Matt’s account of coding up his Braggoscope. The code needed to spider a thousand web pages, extract data from those pages, find similarities, and output the newly-structured data in a different format.

I’ve noticed that these are just the kind of tasks that large language models are pretty good at. In effect you’re training the tool on your own very specific data and getting it to do your drudge work for you.

To me, it feels right that the usefulness happens on your own machine. You don’t put the machine-generated code in front of other humans.

Progressively Enhanced Form Validation, Part 1: HTML and CSS – Cloud Four

A great reminder of just how much you can do with modern markup and styles when it comes to form validation. The :user-invalid and :user-valid pseudo-classes are particularly handy!

Mayerle’s Lithographed International Test Chart, 1907 – Circulating Now from the NLM Historical Collections

An impressive piece of internationlisation and inclusive design.

We do quite a bit of prototyping at Clearleft. There’s no better way to reduce risk than to get something in front of users as quickly as possible to test whether you’re on the right track or not.

As Benjamin said in the podcast episode on prototyping:

It’s something to look at, something to prod. And ideally you’re trying to work out what works and what doesn’t.

Sometimes the prototype is mocked up in Figma. Preferably it’s built in code—HTML, CSS, and JavaScript. Having a prototype built in the materials of the medium helps establish a plausible suspension of disbelief during testing.

Also, as Trys said in that same podcast episode:

Prototypical code isn’t production code. It’s quick and it’s often a little bit dirty and it’s not really fit for purpose in that final deliverable. But it’s also there to be inspiring and to gather a team and show that something is possible.

I can’t reiterate that enough: prototype code isn’t production code.

I’ve written about the two different mindsets before:

So these two kinds of work require very different attitudes. For production work, quality is key. For prototyping, making something quickly is what matters.

Addy recently wrote an excellent blog post on the topic of prototyping. The value of a prototype is in the insight it imparts, not the code.

It’s crucial to remember that in a prototype, the code serves merely as a medium—a way to facilitate understanding. It’s a means to an end, not the end itself. The code of a prototype is disposable and mutable. In contrast, the lessons learned from a prototype, the insights gained from user interaction and feedback, are far more durable and impactful.

This!

It can be tempting to re-use code from a prototype. I get it. It seems like a waste to throw away code and build something from scratch. But trust me—and I speak from experience here—it will take more time to wrangle prototype code into something that’s production-ready.

The problem is that quality is often invisible. Think about semantics, performance, security, privacy, and accessibility. Those matter—for production code—but they’re under the surface. For someone who doesn’t understand the importance of those hidden qualities a prototype that looks like it works seems ready to ship. It’s understandable that they’d balk at the idea of just throwing that code away and writing new code. Sometimes the suspension of disbelief that a prototype is aiming for works too well.

As is so often the case, this isn’t a technical problem. It’s a communication issue.

15 Years Ago, Apple’s App Store Changed Everything. Now It Needs a Reboot.

Whereas I used to get excited about a new app on my iPhone, I now often resent being asked to download an app when I know that the website will work just as well and cause fewer disruptions or take up less space on my phone.

Things you forgot (or never knew) because of React - Josh Collinsworth blog

I don’t think most people using React on a regular basis realize quite how much it’s fallen behind.

Following on from Josh’s earlier post where he said “React isn’t great at anything except being popular”, here are the details.

Every decision React’s made since its inception circa 2013 is another layer of tech debt—one that its newer contemporaries aren’t constrained by.

This is particularly damning:

No other modern frontend framework is as stubbornly incompatible with the platform as React is.

The good news:

React is a bit like a git branch that’s fallen well behind main. You might not realize it, if React is the star your galaxy orbits around, but…well, frontend has moved on. The ecosystem has taken those ideas and run with them to make things that are even better.

Documentation for GPTBot - OpenAI API

Now that the horse has bolted—and ransacked the web—you can shut the barn door:

To disallow GPTBot to access your site you can add the GPTBot to your site’s robots.txt:

User-agent: GPTBot
Disallow: /

Lunar Codex

Time capsules on the moon, using NanoFiche as the storage medium.

Last week Phil posted a little update about his excellent site, ooh.directory:

If you’re in the habit of visiting the Recently Updated Blogs page, and leaving it open, the times when each blog was updated will now keep up with the relentless passing of time.

Does that make sense? “3 minutes ago” will change to “4 minutes ago” and so on and on and on, until you refresh the page.

I thought that was a nice little addition, and I immediately thought of The Session. There are time elements all over the site with relative times as the text content: 2 minutes ago, 7 hours ago, 1 year ago, and so on. Those strings of text are generated on the server. But I figured it would be nice enhancement to periodically update them in the browser after the page has loaded.

I viewed source to see how Phil was doing it. The code is nice and short, using a library called Day.js with a plug-in for relative time.

“Hang on”, I thought, “isn’t there some web standard for doing this kind of thing?” I had a vague memory of some JavaScript API for formatting dates and times.

Sure enough, we’ve now got the Intl.RelativeTimeFormat object. It’s got browser support across the board.

Here’s the code I wrote.

I’ve got a function that loops through all the time elements with datetime attributes. It compares the current timestamp to that value to get the elapsed time. Then that’s formatted using the format() method and output as innerText.

You need to tell the format() method which units you want to use: seconds, minutes, hours, days, etc. So there’s a little bit of looping to figure out which unit is most appropriate. If the elapsed time is less than a minute, use seconds. If the elapsed time is less than an hour, use minutes. If the elapsed time is less than a day, use hours. You get the idea.

It’s a pity there isn’t some kind of magic unit like “auto” to do this, but it’s not much extra code to figure it out.

Anyway, that function runs periodically using setInterval(). I’ve set it to run every 30 seconds in my gist. On The Session I’ve set it to one minute.

You’ll notice that I’m grabbing all the relevant time elements—using document.querySelector('time[datetime]')—every time the function is run. That may seem inefficient. Couldn’t I just grab them once and then keep them stored as an array? But I want this to work even if the page contents have been updated with Ajax. (Do people even say “Ajax” any more? Get off my lawn, you pesky kids!)

I think I’ve written this code in an abstract way so that you should be able to drop it into any web page. For the calculations to work, you’ll need to either make sure that your datetime attributes are using timezones. Or, if there’s no timezone info, UTC is assumed.

This was a fun little piece of functionality to play around with. Now I know a little more about this Intl.RelativeTimeFormat object. The way I’m using it as a classic example of progressive enhancement. If a browser doesn’t support it, or if my code breaks, it’s no big deal. The funtionality is a little bonus that almost nobody will notice anyway. Just a small delighter …if you’re the kind of person who finds it delightful when relative time strings automatically update.

35mm scans — writer/editor/reporter

Clicking through these cold war slides gives an uncomfortable mixture of nostalgic appreciation for the retro aesthetic combined with serious heebie-jeebies for the content.

The slides appear to be 1970s/1980s informational or training images from the United States Air Force, NORAD, Navy, and beyond.

A Blog Post With Every HTML Element by Patrick Weaver

I enjoyed this self-documenting journey of exploration.

“If It Sounds Like Sci-Fi, It Probably Is”

Emily M. Bender:

I dislike the term because “artificial intelligence” suggests that there’s more going on than there is, that these things are autonomous thinking entities rather than tools and simply kinds of automation. If we focus on them as autonomous thinking entities or we spin out that fantasy, it is easier to lose track of the people in the picture, both the people who should be accountable for what the systems are doing and the people whose labor and data are being exploited to create them in the first place.

Alternative terms:

• Stochastic parrots
• Spicy autocomplete
• Mad Libs
• Magic Eight Ball

And this is worth shouting from the rooftops:

The threat is not the generative “AI” itself. It’s the way that management might choose to use it.

Catching up on the weird world of LLMs

This is a really clear, practical, level-headed explanatory talk from Simon. You can read the transcript or watch the video.

Just normal web things.

A plea to let users do web things on websites. In other words, stop over-complicating everything with buckets of JavaScript.

Honestly, this isn’t wishlist isn’t asking for much, and it’s a damning indictment of “modern” frontend development that we’ve come to this:

• Let me copy text so I can paste it.
• If something navigates like a link, let me do link things.
• …

My week at the Belfast TradFest culminated in a cathedral.

Everyone who has been taking classes during the week made their way to Belfast cathedral for a communal finish. Every class played a short piece to round out their week of workshops.

The whole experience was quite lovely. At one point, I was unexepectedly moved to tears by the performance of the cello class (not a common instrument in Irish traditional music).

When I got home, I decided to send a message to Neil Martin who taught that class. It was just a quick line or two to tell him how special it was.

He responded, saying he found the whole experience of the closing concert very moving and powerful.

I was glad I sent that note of thanks.

Then, a day later, I received my own note of thanks. It wasn’t music-related. Someone I had met and chatted with at a conference last year told me that they had just watched the video of my talk, The State Of The Web. They were very moved by it. Then they took the time to send me an email to tell me. As you can imagine, I was really touched to be on the receiving end of that.

I resolved that I would do it more myself. Whether it’s a piece of music, writing, or anything else, I’m going to try to remember to pass on my appreciation more often.

That’s a good place to end, isn’t it? A nice heart-warming reminder that small acts of thoughtfulness can make a big difference to someone else’s well-being.

But there’s a corollary to that lesson. Acts of thoughtlessness will almost certainly make a very big difference to someone else’s well-being.

This is something I know in theory but struggle with in practice. I’ve experienced the regret of wishing I hadn’t acted so stupidly in my dealings with work colleagues, for example.

There’ll be some discussion happening on a topic that I might have strong feelings about, and I let those strong feelings take over my behaviour. Quite frankly, I act like a dickhead.

Sure, I can analyse it in hindsight and identify what causes this unintended behaviour, but that sounds an awful lot like excusing it. In the end, it doesn’t matter what my intentions were or what the circumstances were. It’s my actions that matter. More specifically, it’s the effect of my actions on other people that matter.

So, yeah, I am going to try to do more of those small thoughtful acts, like sending thank-you messages to people. But frankly, that’s a stretch goal. The shamefully low bar I first have to pass is to simply treat people with the respect they deserve. To paraphrase the Hypocratic oath: first, don’t be an asshole.

There’s an oft-quoted adage:

They may forget what you said, but they will never forget how you made them feel.

This is usually applied in the inspirational, positive sense: get out there and make people feel good! But it works equally well as a warning.

I’ve been immersing myself in musical activities recently.

Two weeks ago I was in the studio with Salter Cane. In three days, we managed to record eleven(!) songs! Not bad. We recorded everything live, treating the vocals as guide vocals. We’ve still got some overdubbing to do but we’re very happy with the productivity.

Being in a recording studio for days is intense. It’s an all-consuming activity that leaves you drained. And it’s not just the playing that’s exhausting—listening can be surprisingly hard work.

For those three days, I was pretty much offline.

Then the week after that, I was in Belfast all week for the trad festival. I’ve written up a report over on The Session. It was excellent! But again, it was all-consuming. Classes in the morning and sessions for the rest of the day.

I don’t post anything here in my journal for those two weeks. I didn’t read through my RSS subscriptions. I was quite offline.

I say “quite” offline, because the week after next I’m going to be really offline.

Remember when I took an ocean liner across the Atlantic four years ago? Well, to celebrate a milestone birthday for Jessica we’re going to do it again!

I’m really looking forward to it. And I feel like the recent musical immersions have been like training for the main event in the tournament of being completely cut off from the internet.

You can split the web in many ways. Lionel Dricot wrote about one of those ways in a blog post called Splitting the Web. In it, he outlines an ever-increasing divide he sees on the web.

On the one hand you’ve got people experiencing the advertising-driven, tracking-addicted big players who provide a bloated and buggy user experience.

On the hand, you’ve got the more tech-savvy users with tracking blockers (misleadingly called ad blockers) using browsers and search engines that value privacy and performance.

It feels like everyone is now choosing its side. You can’t stay in the middle anymore. You are either dedicating all your CPU cycles to run JavaScript tracking you or walking away from the big monopolies. You are either being paid to build huge advertising billboards on top of yet another framework or you are handcrafting HTML.

Maybe the web is not dying. Maybe the web is only splitting itself in two.

This reminded me of a post by Chris. No, not The Great Divide, although that’s obviously relevant here. Chris wrote a post just yesterday called Other People’s Busted Software is an Opportunity:

One way to look at it is opportunity. If you make software that does work reliably, you’ve got a leg up. Even if your customers don’t tell you “I like your software because it always works”, they’ll feel it and make choices around knowing it.

I like that optimistic take. If the majority seems to be doubling down on more tracking, more JavaScript, and more enshittification, then there’s a potential opportunity there (acknowledging that you’ve still got to battle against inertia and sunk cost).

This reminds of a fantastic talk that Stuart gave a few years ago called Privacy could be the next big thing:

How do you end up shaping the world? By inventing a thing that the current incumbents can’t compete against. By making privacy your core goal. Because companies who have built their whole business model on monetising your personal information cannot compete against that. They’d have to give up on everything that they are, which they can’t do. Facebook altering itself to ensure privacy for its users… wouldn’t exist. Can’t exist. That’s how you win.

Splitting the Web

This rings true to me.