This is a superb way to deprecate a little JavaScript library. Now that you can just use HTML instead, the website for Pikaday has been turned into a guide to choosing the right design pattern for your needs. Bravo!
Pikaday is no longer a JavaScript date picker. Pikaday is now a friendly guide for front-end developers. I want to push developers away from the classic date picker entirely. Especially fat JavaScript libraries.
Thoughtful analysis from Ben (as always).
Blocking the bots is step one.
See, this is exactly why we need to poison these bots.
In their rush to cram in “AI” “features”, it seems to me that many companies don’t actually understand why people use their products.
Google is acting as though its greatest asset is its search engine. Same with Bing.
Mozilla Developer Network is acting as though its greatest asset is its documentation. Same with Stack Overflow.
But their greatest asset is actually trust.
If I use a search engine I need to be able to trust that the filtering is good. If I look up documentation I need to trust that the information is good. I don’t expect perfection, but I also don’t expect to have to constantly be thinking “was this generated by a large language model, and if so, how can I know it’s not hallucinating?”
“But”, the apologists will respond, “the results are mostly correct! The documentation is mostly true!”
Sure, but as Terence puts it:
The intern who files most things perfectly but has, more than once, tipped an entire cup of coffee into the filing cabinet is going to be remembered as “that klutzy intern we had to fire.”
Trust is a precious commodity. It takes a long time to build trust. It takes a short time to destroy it.
I am honestly astonished that so many companies don’t seem to realise what they’re destroying.
Good advice for documentation—always document steps in the order that they’ll be taken. Seems obvious, but it really matters at the sentence level.
I was chatting to Andy last week and he started ranting about the future of online documentation for web developers. “Write a blog post!” I said. So he did.
I think he’s right. We need a Wikimedia model for web docs. I’m not sure if MDN fits the bill anymore now that they’re deliberately spewing hallucinations back at web developers.
Harry popped ’round to the Clearleft studio yesterday. It’s always nice when a Clearleft alum comes to visit.
It wasn’t just a social call though. Harry wanted to run through the ideas he’s got for his UX London talk.
Wait. I buried the lede. Let me start again.
Harry Brignull is speaking at this year’s UX London!
Yes, the person who literally wrote the book on deceptive design patterns will be on the line-up. And judging from what I heard yesterday, it’s going to be a brilliant talk.
It was fascinating listening to Harry talk about the times he’s been brought in to investigate companies accused of deliberately employing deceptive design tactics. It involves a lot of research and detective work, trawling through internal communications hoping to find a smoking gun like a memo from the boss or an objection from a beleaguered designer.
I thought about this again today reading Nic Chan’s post, Have we forgotten how to build ethical things for the web?. It resonates with what Harry will be talking about at UX London. What can an individual ethical designer do when they’re embedded in a company that doesn’t prioritise user safety?
It’s like a walking into a jets pray of bullshit, so much so that even those with good intentions get easily overwhelmed.
Though I try, my efforts rarely bear fruit, even with the most well-meaning of clients. And look, I get it, no on wants to be the tall poppy. It’s hard enough to squeeze money from the internet-stone these days. Why take a stance on a tiny issue when your users don’t even care? Your competitors certainly don’t. I usually end up quietly acquiescing to whatever bad are made, praying no future discerning user will notice and think badly of me.
It’s pretty clear to me that we can’t rely on individual people to make a difference here.
Still, I take some encouragement from Harry’s detective work. If the very least that an ethical designer (or developer) does is to speak up, on the record, then that can end up counting for a lot when the enshittification hits the fan.
If you see something, say something. Actually, don’t just say it. Write it down. In official communication channels, like email.
I remember when Clearleft crossed an ethical line (for me) by working on a cryptobollocks project, I didn’t just voice my objections, I wrote them down in a memo. It wasn’t fun being the tall poppy, the squeeky wheel, the wet blanket. But I think it would’ve been worse (for me) if I did nothing.
Here’s the transcript of Paul’s excellent talk at this year’s UX London:
How designers can record decisions and cultivate a fun and inclusive culture within their team.
A few months back, I wrote about how Google is breaking its social contract with the web, harvesting our content not in order to send search traffic to relevant results, but to feed a large language model that will spew auto-completed sentences instead.
I still think Chris put it best:
I just think it’s fuckin’ rude.
When it comes to the crawlers that are ingesting our words to feed large language models, Neil Clarke describes the situtation:
It should be strictly opt-in. No one should be required to provide their work for free to any person or organization. The online community is under no responsibility to help them create their products. Some will declare that I am “Anti-AI” for saying such things, but that would be a misrepresentation. I am not declaring that these systems should be torn down, simply that their developers aren’t entitled to our work. They can still build those systems with purchased or donated data.
Alas, the current situation is opt-out. The onus is on us to update our robots.txt file.
Neil handily provides the current list to add to your file. Pass it on:
User-agent: CCBot
Disallow: /
User-agent: ChatGPT-User
Disallow: /
User-agent: GPTBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: Omgilibot
Disallow: /
User-agent: FacebookBot
Disallow: /
In theory you should be able to group those user agents together, but citation needed on whether that’s honoured everywhere:
User-agent: CCBot
User-agent: ChatGPT-User
User-agent: GPTBot
User-agent: Google-Extended
User-agent: Omgilibot
User-agent: FacebookBot
Disallow: /
There’s a bigger issue with robots.txt though. It too is a social contract. And as we’ve seen, when it comes to large language models, social contracts are being ripped up by the companies looking to feed their beasts.
As Jim says:
I realized why I hadn’t yet added any rules to my
robots.txt: I have zero faith in it.
That realisation was prompted in part by Manuel Moreale’s experiment with blocking crawlers:
So, what’s the takeaway here? I guess that the vast majority of crawlers don’t give a shit about your
robots.txt.
Time to up the ante. Neil’s post offers an option if you’re running Apache. Either in .htaccess or in a .conf file, you can block user agents using mod_rewrite:
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (CCBot|ChatGPT|GPTBot|Omgilibot| FacebookBot) [NC]
RewriteRule ^ – [F]
You’ll see that Google-Extended isn’t that list. It isn’t a crawler. Rather it’s the permissions model that Google have implemented for using your site’s content to train large language models: unless you opt out via robots.txt, it’s assumed that you’re totally fine with your content being used to feed their stochastic parrots.
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: /
As part of this pointless push, an “AI explain” button appeared on MDN articles. This terrible idea actually got pushed to production (bypassing the usual deploy steps) where it lasted less than a day.
You can read the havoc it wreaked in the short term. We’ll find out how much long-term damage it has done to trust in Mozilla and MDN.
This may be the worst use of a large language model I’ve seen since synthentic users (if you click that link, no it’s not a joke: “user research without the users” is what they’re actually proposing).
If someone’s been driven to Google something you’ve written, they’re stuck. Being stuck is, to one degree or another, upsetting and annoying. So try not to make them feel worse by telling them how straightforward they should be finding it. It gets in the way of them learning what you want them to learn.
A short documentary that you can dowload or watch online:
The film explores how image banks including Getty gain control over, and then restrict access to, archive images – even when these images are legally in the public domain. It also forms a small act of resistance against this practice: the film includes six legally licensed clips, and is downloadable as an HD ProRes file. In this way, it aims to liberate these few short clips from corporate control, and make them freely available for viewing and artistic use.
Licensed under aCreative Commons 0: “No rights reserved” license.
This is a great step-by-step guide to HTML by Estelle.
Ever get the urge to style a good document?
No? Just me, then.
Well, the urge came over me recently so I started styling this single-page site:
A Few Notes On The Culture by Iain M Banks
I’ve followed this document across multiple locations over the years. It started life as a newsgroup post on rec.arts.sf.written in 1994. Ken McLeod published it there on Iain M Banks’s behalf.
The post complements the epic series of space opera books that Iain M Banks set in the anarcho-utopian society of The Culture. It’s a fascinating piece of world building, as well as an insight into the author’s mind.
I first became aware of it many few years later, after a copy had been posted to the web. That URL died, but Adrian Hon kept a copy on his site. Lots of copies keep stuff safe, so after contemplating linkrot, I made a copy on this site too.
But I recently thought that maybe it deserved a bit of art direction, so I rolled up my sleeves and started messing around, designing in the browser and following happy little accidents.
The finished result is still fairly sparse. It’s still entirely text, except for a background image that shows up if your screen is wide enough. That image of a planet originally started as an infra-red snapshot of Jupiter by the James Webb Space Telescope that I worked over until it was unrecognisable.
The text itself is the main focus of the design though. I knew I wanted to play around with a variable font. Mona Sans from Github was one of the first ones I tried and I found it instantly suitable. I had a lot of fun playing with different weights and widths.
After a bit of messing around, I realised that the heading styles were reminding me of some later reissues of The Culture novels, so I leant into that, deliberately styling the byline to resemble the treatment of the author’s name on those book covers.
There isn’t all that much CSS. I’ve embedded it in the head of the HTML rather than linking to a separate style sheet, so feel free to view source and poke around in there. You’ll see that I’m making liberal use of custom properties, the clamp function, and logical properties.
Originally I had a light mode and dark mode but I found that the dark mode was much more effective so I ditched the lighter option.
I did make sure to include some judicious styles for print, so if you fancy reading on paper, it should print out nicely.
Oh, and of course it’s a progressive web app that works offline.
I didn’t want to mess with the original document other than making some typographic tweaks to punctuation, but I wanted to break up the single wall of text. I wasn’t about to start using pull quotes on the web so in the end I decided to introduce some headings that weren’t in the original document:
If your browser viewport is tall enough, the heading for the current section you’re reading will remain sticky as you scroll. No JavaScript required.
I’m pretty pleased with how this little project turned out. It was certainly fun to experiment with fluid type and a nice variable font.
I can add this to my little collection of single-page websites I’ve whittled over the years:
I can’t wait to see this documentary about Marc and Beyond Tellerrand!
My talk, Building, was about the metaphors we use to talk about the work we do on the web. So I’m interested in this analysis of the metaphors used to talk about markup:
- Data is documents, processing data is clerking
- Data is trees, processing data is forestry
- Data is buildings, processing data is construction
- Data is a place, processing data is a journey
- Data is a fluid, processing data is plumbing
- Data is a textile, processing data is weaving
- Data is music, processing data is performing
A while back I wrote a blog post called Web Audio API weirdness on iOS. I described a bug in Mobile Safari along with a hacky fix. I finished by saying:
If you ever find yourself getting weird but inconsistent behaviour on iOS using the Web Audio API, this nasty little hack could help.
Recently Jonathan Aldrich posted a thread about the same bug. He included a link to my blog post. He also said:
Thanks so much for your post, this was a truly pernicious problem!
That warms the cockles of my heart. It’s very gratifying to know that documenting the bug (and the fix) helped someone out. Or, as I put it:
Yay for bugblogging!
Forgive the Germanic compound word, but in this case I think it fits.
Bugblogging doesn’t need to involve a solution. Just documenting a bug is a good thing to do. Recently I documented a bug with progressive web apps on iOS. Before that I documented a bug in Facebook Container for Firefox. When I documented some weird behaviour with the Web Share API in Safari on iOS, I wasn’t even sure it was a bug but Tess was pretty sure it was and filed a proper bug report.
I’ve benefited from other people bugblogging. Phil Nash wrote Service workers: beware Safari’s range request. That was exactly what I needed to solve a problem I’d been having. And then that post about Phil solving my problem helped Peter Rukavina solve a similar issue so he wrote Phil Nash and Jeremy Keith Save the Safari Video Playback Day.
Again, this warmed the cockles of my heart. Bugblogging is worth doing just for the reward of that feeling.
There’s a similar kind of blog post where, instead of writing about a bug, you write about a particular technique. In one way, this is the opposite of bugblogging because you’re writing about things working exactly as they should. But these posts have a similar feeling to bugblogging because they also result in a warm glow when someone finds them useful.
Here are some recent examples of these kinds of posts—tipblogging?—that I’ve found useful:
All three are very handy tips. Thanks, Eric! Thanks, Rich! Thanks, Stephanie!
I remember Lara telling me a great quote from the Clarity conference a few years back: “A design system needs to be correct before it’s complete.” In other words, it’s better to have one realistic component that’s actually in production than to have a pattern library full of beautiful but unimplemented components. I feel like Robin is getting at much the same point here, but he frames it in terms of correctness and usefulness:
If we want to be correct, okay, let’s have components of everything and an enormous Figma library of stuff we need to maintain. But if we want to be useful to designers who want to get an understanding of the system, let’s be brief.