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.
Friday, May 7th, 2021
Friday, April 23rd, 2021
A personal website ain’t got no wrong words.
Tuesday, April 6th, 2021
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.
Saturday, April 3rd, 2021
Principles and the English language
One of my roles at Clearleft is “content buddy.” If anyone is writing a talk, or a blog post, or a proposal and they want an extra pair of eyes on it, I’m there to help.
I think a lot about design principles for the web. The two principles I keep coming back to are the robustness principle and the principle of least power.
When it comes to words, the guide that I return to again and again is George Orwell, specifically his short essay, Politics and the English Language.
Towards the end, he offers some rules for writing.
- Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
- Never use a long word where a short one will do.
- If it is possible to cut a word out, always cut it out.
- Never use the passive where you can use the active.
- Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
- Break any of these rules sooner than say anything outright barbarous.
These look a lot like design principles. Not only that, but some of them look like specific design principles. Take the robustness principle:
Be conservative in what you send, be liberal in what you accept.
That first part applies to Orwell’s third rule:
If it is possible to cut a word out, always cut it out.
Be conservative in what words you send.
Then there’s the principle of least power:
Choose the least powerful language suitable for a given purpose.
Compare that to Orwell’s second rule:
Never use a long word where a short one will do.
That could be rephrased as:
Choose the shortest word suitable for a given purpose.
Or, going in the other direction, the principle of least power could be rephrased in Orwell’s terms as:
Never use a powerful language where a simple language will do.
Oh, I like that! I like that a lot.
Wednesday, March 24th, 2021
A good tutorial on making password fields accessible when you’ve got the option to show and hide the input.
Sunday, March 21st, 2021
A slot machine for speculation. Enter a topic and get a near-future scenario on that topic generated automatically.
Tuesday, March 9th, 2021
One of my roles at Clearleft is “content buddy.” If anyone is writing a talk, or a blog post, or a proposal and they want an extra pair of eyes on it, I’m there to help.
Sometimes a colleague will send a link to a Google Doc where they’ve written an article. I can then go through it and suggest changes. Using the “suggest” mode rather than the “edit” mode in Google Docs means that they can accept or reject each suggestion later.
But what works better—and is far more fun—is if we arrange to have a video call while we both have the Google Doc open in our browsers. That way, instead of just getting the suggestions, we can talk through the reasoning behind each one. It feels more like teaching them to fish instead of giving them a grammatically correct fish.
Some of the suggestions are very minor; punctuation, capitalisation, stuff like that. Where it gets really interesting is trying to figure out and explain why some sentence constructions feel better than others.
A fairly straightforward example is long sentences. Not all long sentences are bad, but the longer a sentence gets, the more it runs the risk of overwhelming the reader. So if there’s an opportunity to split one long sentence into two shorter sentences, I’ll usually recommend that.
Here’s an example from Chris’s post, Delivering training remotely – the same yet different. The original sentence read:
I recently had the privilege of running some training sessions on product design and research techniques with the design team at Duck Duck Go.
There’s nothing wrong with that. But maybe this is a little easier to digest:
I recently had the privilege of running some training sessions with the design team at Duck Duck Go. We covered product design and research techniques.
Perhaps this is kind of like the single responsibility principle in programming. Whereas the initial version was one sentence that conveyed two pieces of information (who the training was with and what the training covered), the final version has a separate sentence for each piece of information.
I wouldn’t take that idea too far though. Otherwise you’d end up with something quite stilted and robotic.
Speaking of sounding robotic, I’ve noticed that people sometimes avoid using contractions when they’re writing online: “there is” instead of “there’s” or “I am” instead of “I’m.” Avoiding contractions seems to be more professional, but actually it makes the writing a bit too formal. There’s a danger of sounding like a legal contract. Or a Vulcan.
Sometimes a long sentence can’t be broken down into shorter sentences. In that case, I watch out for how much cognitive load the sentence is doling out to the reader.
Here’s an example from Maite’s post, How to engage the right people when recruiting in house for research. One sentence initially read:
The relevance of the people you invite to participate in a study and the information they provide have a great impact on the quality of the insights that you get.
The verb comes quite late there. As a reader, until I get to “have a great impact”, I have to keep track of everything up to that point. Here’s a rephrased version:
The quality of the insights that you get depends on the relevance of the people you invite to participate in a study and the information they provide.
Okay, there are two changes there. First of all, the verb is now “depends on” instead of “have a great impact on.” I think that’s a bit clearer. Secondly, the verb comes sooner. Now I only have to keep track of the words up until “depends on”. After that, I can flush my memory buffer.
Here’s another changed sentence from the same article. The initial sentence read:
You will have to communicate at different times and for different reasons with your research participants.
I suggested changing that to:
You will have to communicate with your research participants at different times and for different reasons.
To be honest, I find it hard to explain why that second version flows better. I think it’s related to the idea of reducing dependencies. The subject “your research participants” is dependent on the verb “to communicate with.” So it makes more sense to keep them together instead of putting a subclause between them. The subclause can go afterwards instead: “at different times and for different reasons.”
Here’s one final example from Katie’s post, Service Designers don’t design services, we all do. One sentence initially read:
Understanding the relationships between these moments, digital and non-digital, and designing across and between these moments is key to creating a compelling user experience.
That sentence could be broken into shorter sentences, but it might lose some impact. Still, it can be rephrased so the reader doesn’t have to do as much work. As it stands, until the reader gets to “is key to creating”, they have to keep track of everything before that. It’s like the feeling of copying and pasting. If you copy something to the clipboard, you want to paste it as soon as possible. The longer you have to hold onto it, the more uncomfortable it feels.
So here’s the reworked version:
The key to creating a compelling user experience is understanding the relationships between these moments, digital and non-digital, and designing across and between these moments.
As a reader, I can digest and discard each of these pieces in turn:
- The key to creating a compelling user experience is…
- understanding the relationships between these moments…
- digital and non-digital…
- designing across and between these moments.
Maybe I should’ve suggested “between these digital and non-digital moments” instead of “between these moments, digital and non-digital”. But then I worry that I’m intruding on the author’s style too much. With the finished sentence, it still feels like a rousing rallying cry in Katie’s voice, but slightly adjusted to flow a little easier.
I must say, I really, really enjoy being a content buddy. I know the word “editor” would be the usual descriptor, but I like how unintimidating “content buddy” sounds.
I am almost certainly a terrible content buddy to myself. Just as I ignore my own advice about preparing conference talks, I’m sure I go against my own editorial advice every time I blurt out a blog post here. But there’s one piece I’ve given to others that I try to stick to: write like you speak.
Sunday, March 7th, 2021
This is easily my favourite use of a machine learning algorithm.
Wednesday, February 3rd, 2021
Two-factor authentication is generally considered A Good Thing™️ when you’re logging in to some online service.
The word “factor” here basically means “kind” so you’re doing two kinds of authentication. Typical factors are:
- Something you know (like a password),
- Something you have (like a phone or a USB key),
- Something you are (biometric Black Mirror shit).
Asking for a password and an email address isn’t two-factor authentication. They’re two pieces of identification, but they’re the same kind (something you know). Same goes for supplying your fingerprint and your face: two pieces of information, but of the same kind (something you are).
None of these kinds of authentication are foolproof. All of them can change. All of them can be spoofed. But when you combine factors, it gets a lot harder for an attacker to breach both kinds of authentication.
The most common kind of authentication on the web is password-based (something you know). When a second factor is added, it’s often connected to your phone (something you have).
Every security bod I’ve talked to recommends using an authenticator app for this if that option is available. Otherwise there’s SMS—short message service, or text message to most folks—but SMS has a weakness. Because it’s tied to a phone number, technically you’re only proving that you have access to a SIM (subscriber identity module), not a specific phone. In the US in particular, it’s all too easy for an attacker to use social engineering to get a number transferred to a different SIM card.
Still, authenticating with SMS is an option as a second factor of authentication. When you first sign up to a service, as well as providing the first-factor details (a password and a username or email address), you also verify your phone number. Then when you subsequently attempt to log in, you input your password and on the next screen you’re told to input a string that’s been sent by text message to your phone number (I say “string” but it’s usually a string of numbers).
There’s an inevitable friction for the user here. But then, there’s a fundamental tension between security and user experience.
In the world of security, vigilance is the watchword. Users need to be aware of their surroundings. Is this web page being served from the right domain? Is this email coming from the right address? Friction is an ally.
But in the world of user experience, the opposite is true. “Don’t make me think” is the rallying cry. Friction is an enemy.
With SMS authentication, the user has to manually copy the numbers from the text message (received in a messaging app) into a form on a website (in a different app—a web browser). But if the messaging app and the browser are on the same device, it’s possible to improve the user experience without sacrificing security.
If you’re building a form that accepts a passcode sent via SMS, you can use the
autocomplete attribute with a value of “one-time-code”. For a six-digit passcode, your
input element might look something like this:
<input type="text" maxlength="6" inputmode="numeric" autocomplete="one-time-code">
With one small addition to one HTML element, you’ve saved users some tedious drudgery.
There’s one more thing you can do to improve security, but it’s not something you add to the HTML. It’s something you add to the text message itself.
Let’s say your website is example.com and the text message you send reads:
Your one-time passcode is 123456.
Add this to the end of the text message:
So the full message reads:
Your one-time passcode is 123456. @example.com #123456
The first line is for humans. The second line is for machines. Using the @ symbol, you’re telling the device to only pre-fill the passcode for URLs on the domain example.com. Using the # symbol, you’re telling the device the value of the passcode. Combine this with
autocomplete="one-time-code" in your form and the user shouldn’t have to lift a finger.
I’m fascinated by these kind of emergent conventions in text messages. Remember that the @ symbol and # symbol in Twitter messages weren’t ideas from Twitter—they were conventions that users started and the service then adopted.
You can add a URL for
/.well-known/change-password which redirects to the form a user would use to update their password. Browsers and password managers can then use this information if they need to prompt a user to update their password after a breach. I’ve added this to The Session.
Oh, and on that page where users can update their password, the
autocomplete attribute is your friend again:
<input type="password" autocomplete="new-password">
If you want them to enter their current password first, use this:
<input type="password" autocomplete="current-password">
All of the things I’ve mentioned—the
autocomplete attribute, origin-bound one-time codes in text messages, and a well-known URL for changing passwords—have good browser support. But even if they were only supported in one browser, they’d still be worth adding. These additions do absolutely no harm to browsers that don’t yet support them. That’s progressive enhancement.
Thursday, January 28th, 2021
Thursday, January 21st, 2021
Letters of exclusion
I think my co-workers are getting annoyed with me. Any time they use an acronym or initialism—either in a video call or Slack—I ask them what it stands for. I’m sure they think I’m being contrarian.
The truth is that most of the time I genuinely don’t know what the letters stand for. And I’ve got to that age where I don’t feel any inhibition about asking “stupid” questions.
But it’s also true that I really, really dislike acronyms, initialisms, and other kinds of jargon. They’re manifestations of gatekeeping. They demarcate in-groups from outsiders.
Of course if you’re in a conversation with an in-group that has the same background and context as you, then sure, you can use acronyms and initialisms with the confidence that there’s a shared understanding. But how often can you be that sure? The more likely situation—and this scales exponentially with group size—is that people have differing levels of inside knowledge and experience.
I feel sorry for anyone trying to get into the field of web performance. Not only are there complex browser behaviours to understand, there’s also a veritable alphabet soup of initialisms to memorise. Here’s a really good post on web performance by Harry, but notice how the initialisms multiply like tribbles as the post progresses until we’re talking about using CWV metrics like LCP, FID, and CLS—alongside TTFB and SI—to look at PLPs, PDPs, and SRPs. And fair play to Harry; he expands each initialism the first time he introduces it.
But are we really saving any time by saying FID instead of first input delay? I suspect that the only reason why the word “cumulative” precedes “layout shift” is just to make it into the three-letter initialism CLS.
Still, I get why initialisms run rampant in technical discussions. You can be sure that most discussions of particle physics would be incomprehensible to outsiders, not necessarily because of the concepts, but because of the terminology.
Again, if you’re certain that you’re speaking to peers, that’s fine. But if you’re trying to communicate even a little more widely, then initialisms and abbreviations are obstacles to overcome. And once you’re in the habit of using the short forms, it gets harder and harder to apply context-shifting in your language. So the safest habit to form is to generally avoid using acronyms and initialisms.
Unnecessary initialisms are exclusionary.
Think about on-boarding someone new to your organisation. They’ve already got a lot to wrap their heads around without making them figure out what a TAM is. That’s a real example from Clearleft. We have a regular Thursday afternoon meeting. I call it the Thursday afternoon meeting. Other people …don’t.
I’m trying—as gently as possible—to ensure we’re not being exclusionary in our language. My co-workers indulge me, even it’s just to shut me up.
But here’s the thing. I remember many years back when a job ad went out on the Clearleft website that included the phrase “culture fit”. I winced and explained why I thought that was a really bad phrase to use—one that is used as code for “more people like us”. At the time my concerns were met with eye-rolls and chuckles. Now, as knowledge about diversity and inclusion has become more widespread, everyone understands that using a phrase like “culture fit” can be exclusionary.
But when I ask people to expand their acronyms and initialisms today, I get the same kind of chuckles. My aversion to abbreviations is an eccentric foible to be tolerated.
But this isn’t about me.
Thursday, December 31st, 2020
2020 in numbers
I posted to adactio.com 1442 times in 2020.
March was the busiest month with 184 posts.
This month, December, was the quietest with 68 posts.
Overall I published:
Elsewhere in 2020:
- I huffduffed 187 pieces of audio,
- made 1,139 contributions on Github, and
- published 6 episodes of the Clearleft podcast.
Words I wrote in 2020
Once again I wrote over a hundred blog posts this year. While lots of other activities dropped off significantly while my main focus was to just keep on keepin’ on, I still found solace and reward in writing and publishing. Like I said early on in The Situation, my website is an outlet for me:
While you’re stuck inside, your website is not just a place you can go to, it’s a place you can control, a place you can maintain, a place you can tidy up, a place you can expand. Most of all, it’s a place you can lose yourself in, even if it’s just for a little while.
Here are some blog posts that turned out alright:
- Architects, gardeners, and design systems. Citing Frank Chimero, Debbie Chachra, and Lisa O’Neill.
- Hydration. Progressive enhancement. I do not think it means what you think it means.
- Living Through The Future. William Gibson, Arthur C.Clarke, Daniel Dafoe, Stephen King, Emily St. John Mandel, John Wyndham, Martin Cruz-Smith, Marina Koren and H.G. Wells.
- Principles and priorities. Using design principles to embody your priorities.
- Hard to break. Brittleness is the opposite of resilience. But they both share something in common.
- Intent. Black lives matter.
- Accessibility. Making the moral argument.
- T E N Ǝ T. A spoiler-filled look at the new Christopher Nolan film.
- Portals and giant carousels. Trying to understand why people think they need to make single page apps.
- Clean advertising. The greatest trick the devil ever pulled was convincing the world that behavioural advertising is more effective than contextual advertising.
I find it strangely comforting that even in a year as shitty as 2020, I can look back and see that there were some decent blog posts in there. Whatever 2021 may bring, I hope to keep writing and publishing through it all. I hope you will too.
Saturday, December 26th, 2020
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.
Saturday, September 26th, 2020
Tuesday, September 1st, 2020
Monday, March 23rd, 2020
This is a great walkthough of making a common form pattern accessible. No complex code here: some HTML is all that’s needed.
Tuesday, December 31st, 2019
2019 in numbers
I posted to adactio.com 1,600 times in 2019:
In amongst those notes were:
If you like, you can watch all that activity plotted on a map.
Away from this website in 2019:
Monday, December 30th, 2019
Words I wrote in 2019
Here are eight posts from during the year that I think are a good representative sample. I like how these turned out.
- Timelines of the web. The World Wide Web is a mashup.
- Dev perception. The perceived state of front-end development tools and technologies might be quite different from the reality.
- Split. Materials and tools; client and server; declarative and imperative; inclusion and privilege.
- A song of AIs and fire. Game of Thrones spoilers ahoy.
- Trad time. From the west coast of Clare to the World Wide Web.
- Passenger’s log, Queen Mary 2, August 2019. The inaugural Dance The Atlantic crossing from Southampton to New York.
- Mental models. Back-end development isn’t the same as front-end development.
- Rams. A most unusual encounter in Frankfurt.
I hope that I’ll write as many blog posts in 2020.
I’m pretty sure that I will also continue to refer to them as blog posts, not blogs. I may be the last holdout of this nomenclature in 2020. I never planned to die on this hill, but here we are.
Actually, seeing as this is technically my journal rather than my blog, I’ll just call them journal entries.
Here’s to another year of journal entries.
Sunday, October 13th, 2019