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.
There’s a time for linguistics, and there’s a time for grabbing the general public by the shoulders and shouting “It lies! The computer lies to you! Don’t trust anything it says!”
Imagine a collaboratively developed, universal content style guide, based on usability evidence.
A hall of shame for ludicrously convoluted password rules that actually reduce security.
A very astute framing by Ted Chiang—large language models as a form of lossy compression for text.
When we’re dealing with sequences of words, lossy compression looks smarter than lossless compression.
A lot of uses have been proposed for large language models. Thinking about them as blurry JPEGs offers a way to evaluate what they might or might not be well suited for.
This resonates with me.
This piece by Giles is a spot-on description of what I do in my role as content buddy at Clearleft. Especially this bit:
Your editor will explain why things need changing
As a writer, it’s really helpful to understand the why of each edit. It’s easier to re-write if you know precisely what the problem is. And often, it’s less bruising to the ego. It’s not that you’re a bad writer, but just that one particular thing could be expressed more simply, or more clearly, than your first effort.
Whatever the merit of the scientific aspirations originally encompassed by the term “artificial intelligence,” it’s a phrase that now functions in the vernacular primarily to obfuscate, alienate, and glamorize.
Do “cloud” next!
This is a great deep dive into a single component, a password toggle in this case. It shows how assumptions are challenged and different circumstances are considered in order to make it truly resilient.
A personal website ain’t got no wrong words.
This old article from Chris is evergreen. There’s been some recent discussion of calling these words “downplayers”, which I kind of like. Whatever they are, try not to use them in documentation.
A good tutorial on making password fields accessible when you’ve got the option to show and hide the input.
A slot machine for speculation. Enter a topic and get a near-future scenario on that topic generated automatically.
This is easily my favourite use of a machine learning algorithm.
A fascinating crowdsourced project. You can read the backstory in this article in Wired magazine.
This explains rubber ducking.
Speaking out loud is not only a medium of communication, but a technology of thinking: it encourages the formation and processing of thoughts.
The use of React complicates front-end build. We have very talented front-end developers, however, they are not React experts - nor should they need to be. I believe front-end should be built as standards-compliant HTML/CSS with JavaScript used to enrich functionality where necessary and appropriate.
Well, this is impressive (and brave)—competing a 100 words for 100 days during lockdown …with a baby.
And remember, this isn’t writing and publishing at least 100 words every day; it’s writing and publishing exactly 100 words (that’s the hard part).
This is a great walkthough of making a common form pattern accessible. No complex code here: some HTML is all that’s needed.
I was chatting with Monique after her Paris Web talk on doing 100 days of code. I told her about my 100 days project and now she’s doing it too!