This is a terrific presentation from Paul. He gives a history lesson and then focuses on what makes the indie web such a powerful idea (hint: it’s not about specific technologies).
Exploring the graphic design history of Penguin books:
The covers presented on this site are all from my own collection of about 1400 Penguins, which have been chosen for the beauty or interest of their cover designs. They span the history of the company all the way back to 1935 when Penguin Books was launched.
Web Content Accessibility Guidelines—or WCAG—looks very daunting. It’s a lot to take in. It’s kind of overwhelming. It’s hard to know where to start.
I recommend taking a deep breath and focusing on the four principles of accessibility. Together they spell out the cutesy acronym POUR:
A lot of work has gone into distilling WCAG down to these four guidelines. Here’s how I apply them in my work…
I interpret this as:
Content will be legible, regardless of how it is accessed.
For example:
I interpret this as:
Core functionality will be available, regardless of how it is accessed.
For example:
I interpret this as:
Content will make sense, regardless of how it is accessed.
For example:
This is where it starts to get quite collaboritive. Working at an agency, there will some parts of website creation and maintenance that will require ongoing accessibility knowledge even when our work is finished.
For example:
I interpret this as:
Content and core functionality will still work, regardless of how it is accessed.
For example:
If you’re applying a mindset of progressive enhancement, this part comes for you. If you take a different approach, you’re going to have a bad time.
Taken together, these four guidelines will get you very far without having to dive too deeply into the rest of WCAG.
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.
Another terrific interactive tutorial from Ahmad, this time on container queries.
This isn’t just a great explanation of :has(), it’s an excellent way of understanding selectors in general. I love how the examples are interactive!
I’ve mentioned before that one of my roles at Clearleft is to be a 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.
Ideally this happens in real time over video while we both have the same Google doc open:
That way, instead of just getting the suggestions, we can talk through the reasoning behind each one.
I was doing that recently with Rebecca when she was writing an announcement blog post for the Leading Design on-demand platform.
Talking through the structure, I suggested this narrative flow:
I think that blog post turned out well. And we both had good fun wrangling it into shape.
Today I was working on another great blog post, this time by Luke. Alas, the content buddying couldn’t be in real time so I had to make my suggestions asynchronously.
I still like to provide some reasoning for my changes, so I scattered comments throughout. I was also able to refer to something I put together a little while back…
Here’s the Clearleft tone of voice and style guide document.
I tried to keep it as short as possible. There’s always a danger that the style guide section in particular could grow and grow, so I kept to specific things that have come up in actual usage.
I hadn’t looked at it in a while so I was able to see it with somewhat fresh eyes today. Inevitably I spotted some things that could be better. But overall, I think it’s pretty good.
It’s just for internal use at Clearleft, but rather than have it live in a Google Drive or Dropbox folder, I figured it would be easier to refer to it with a URL. And we’ve always liked sharing our processes openly. So even though it’s probably of no interest to anyone outside of Clearleft, here it is: toneofvoice.clearleft.com
This is a wonderfully in-depth interactive explainer on touch target sizes, with plenty of examples.
This is a terrific interactive explainer!
Michelle has written a detailed practical guide to container queries here.
When you think of heraldry what comes to mind is probably knights in shining armor, damsels in distress, jousting, that sort of thing. Medieval stuff. But I prefer to think of it as one of the earliest design systems.
This totally checks out.
I like Jason’s guidelines—very in keeping with The Session’s house rules.
And I really like his motivation for trying out comments:
The timing feels right. Twitter has imploded and social sites/services like Threads, Bluesky, and Mastodon are jockeying to replace it (for various definitions of “replace”). People are re-thinking what they want out of social media on the internet and I believe there’s an opportunity for sites like kottke.org to provide a different and perhaps even better experience for sharing and discussing information. Shit, maybe I’m wrong but it’s definitely worth a try.
Yes! More experiments like this please! Experiments that aren’t just “let’s clone Twitter”.
No one says “information superhighway” anymore, but whenever anyone explains net neutrality, they do so in terms of fast lanes and tolls. Twitter is a “town square,” a metaphor that was once used for the internet as a whole. These old metaphors had been joined by a few new ones: I have a feeling that “the cloud” will soon feel as dated as “cyberspace.”
Mandy takes a deep dive into the treatment of altruism in Ursula Le Guin’s The Dispossessed.
I didn’t know the Washington Post had a design system or that the system has this good section on accessibility.
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.
Stuart has written this fantastic concise practical guide to privacy for developers and designers. A must-read!
We use metaphors all the time. To quote George Lakoff, we live by them.
We use analogies some of the time. They’re particularly useful when we’re wrapping our heads around something new. By comparing something novel to something familiar, we can make a shortcut to comprehension, or at least, categorisation.
But we need a certain amount of vigilance when it comes to analogies. Just because something is like something else doesn’t mean it’s the same.
With that in mind, here are some ways that people are describing generative machine learning tools. Large language models are like…
A very handy guide to considering privacy at all stages of digital product design:
This guidance is written for technology professionals such as product and UX designers, software engineers, QA testers, and product managers.