Journal

2922 sparkline

Monday, October 31st, 2022

Do You Like Rock Music?

I spent Friday morning in band practice with Salter Cane. It was productive. We’ve got some new songs that are coming together nicely. We’re still short a drummer though, so if you know anyone in Brighton who might be interested, let me know.

As we were packing up, we could here the band next door. They were really good. Just the kind of alt-country rock that would go nicely with Salter Cane.

On the way out, Jessica asked at the front desk who that band was. They’re called The Roebucks.

When I got home I Ducked, Ducked and Went to find out more information. There’s a Bandcamp page with one song. Good stuff. I also found their Facebook page. That’s where I saw this little tidbit:

Hello, we are supporting @seapowerband at @chalk_venue on the 30th of October. Hope you can make it!

Wait, that’s this very weekend! And I love Sea Power (formerly British Sea Power—they changed their name, which was a move that only annoyed the very people who’s worldviews prompted the name change in the first place). How did I not know about this gig? And how are there tickets still available?

And that’s how I came to spend my Sunday evening rocking out to two great bands.

Sunday, October 30th, 2022

Overloading buttons

It’s been almost two years since I added audio playback on The Session. The interface is quite straightforward. For any tune setting, there’s a button that says “play audio”. When you press that button, audio plays and the button’s text changes to “pause audio.”

By updating the button’s text like this, I’m updating the button’s accessible name. In other situations, where the button text doesn’t change, you can indicate whether a button is active or not by toggling the aria-pressed attribute. I’ve been doing that on the “share” buttons that act as the interface for a progressive disclosure. The label on the button—“share”—doesn’t change when the button is pressed. For that kind of progressive disclosure pattern, the button also has an aria-controls and aria-expanded attribute.

From all the advice I’ve read about button states, you should either update the accessible name or change the aria-pressed attribute, but not both. That would lead to the confusing situation of having a button labelled “pause audio” as having a state of “pressed” when in fact the audio is playing.

That was all fine until I recently added some more functionality to The Session. As well as being able to play back audio, you can now adjust the tempo of the playback speed. The interface element for this is a slider, input type="range".

But this means that the “play audio” button now does two things. It plays the audio, but it also acts as a progressive disclosure control, revealing the tempo slider. The button is simultaneously a push button for playing and pausing music, and a toggle button for showing and hiding another interface element.

So should I be toggling the aria-pressed attribute now, even though the accessible name is changing? Or is it enough to have the relationship defined by aria-controls and the state defined by aria-expanded?

Based on past experience, my gut feeling is that I’m probably using too much ARIA. Maybe it’s an anti-pattern to use both aria-expanded and aria-pressed on a progressive disclosure control.

I’m kind of rubber-ducking here, and now that I’ve written down what I’m thinking, I’m pretty sure I’m going to remove the toggling of aria-pressed in any situation where I’m already toggling aria-expanded.

What I really need to do is enlist the help of actual screen reader users. There are a number of members of The Session who use screen readers. I should get in touch and see if the new functionality makes sense to them.

Tuesday, October 25th, 2022

Prepping

Speaking of in-person gatherings, I’ve got some exciting—if not downright nervewracking—events coming up soon.

Next week I’ll be in London for Leading Design. Looking at the line-up that Rebecca is assembled, I’m kind of blown away—it looks fantastic!

You’ll notice that I’m in that line-up, but don’t worry—I’m not giving a talk. I’ll be there as host. That means I get to introduce the speakers before they speak, and ask them a question or two afterwards.

Then, one week later, I do it all again at Clarity in New Orleans. I’m really honoured that Jina has invited me to MC. Again, it’s a ridiculously fantastic line-up (once you ignore my presence).

I really, really enjoy hosting events. And yet I always get quite anxious in the run-up. I think it’s because there isn’t much I can do to prepare.

During The Situation, I had something of an advantage when I was hosting UX Fest. The talks were pre-recorded, which meant that I could study them ahead of time. At a live event, I won’t have that luxury. Instead, I need to make sure that I pay close attention to each talk and try to come up with good questions.

Based on past experience, my anxiety is unwarranted. Once I’m actually talking to these super-smart people, the problem isn’t a lack of things to discuss, but the opposite—so much to talk about in so little time!

I keep trying to remind myself of that.

See, it’s different if I’m speaking at an event. Sure, I’ll get nervous, but I can do something about it. I can prepare and practice to alleviate any anxiety. I feel like I have more control over the outcome when I’m giving a talk compared with hosting.

In fact, I do have a speaking gig on the horizon. I’ll be giving a brand new talk at An Event Apart in San Francisco in December.

It was just a month ago when Jeffrey invited me to speak. Of course I jumped at the chance—it’s always an honour to be asked—but I had some trepidation about preparing a whole new talk in time.

I’ve mentioned this before but it takes me aaaaaaaages to put a talk together. Don’t get me wrong; I think it’s worth it. I may not be good at much, but I know I can deliver a really good conference talk …once I’ve spent ridiculously long preparing it.

But more recently I’ve noticed that I’ve managed to shorten this time period. Partly that’s because I recklessly agree to prepare the talk in a shorter amount of time—nothing like a deadline to light a fire under my ass. But it’s also because a lot of the work is already done.

When I have a thought or an opinion about something, I write it down here on my own website. They’re brain farts, but their my brain farts. I consider them half-baked, semi-formed ideas.

For a conference talk, I need something fully-baked and well-formed. But I can take a whole bunch of those scrappy blog posts and use them as raw material.

There’s still a lot of work involved. As well as refining the message I want to get across, I have to structure these thoughts into a narrative thread that makes sense. That’s probably the hardest part of preparing a conference talk …and the most rewarding.

So while I’ve been feeling somewhat under the gun as I’ve been preparing this new talk for An Event Apart, I’ve also been feeling that the talk is just the culmination; a way of tying together some stuff I’ve been writing about it here for the past year or two.

It’s still entirely possible that the talk could turn out to be crap, but I think the odds are in my favour. I’ve been able to see how the ideas I’ve been writing about have resonated with people, so I can feel pretty confident that they’ll go down well in a talk.

As for the topic of the talk? All will be revealed.

Monday, October 24th, 2022

In person

I’ve had the opportunity to gather with my peers a few times over the past couple of months.

There was dConstruct, which I hosted. That was just lovely.

Then a few weeks ago, in spite of train strikes and travel snags, I went to Bristol to give a talk at Web Dev Conf, a really nice gathering.

This past weekend I was in London for State Of The Browser, this time as neither host nor speak, but as an attendee. It was really good!

I noticed something rather lovely. There was enough cross-over in the audiences for these events that I got to see some people more than once. That’s something that used to happen all the time but became very rare over the past two years because of The Situation.

None of the organisers of these events were pretending that Covid has gone away. Each event had different processes in place to mitigate risk. I wrote about the steps I took for dConstruct. For some people, those measures might seem to go too far. For other people, they don’t go far enough. This is a challenge that every in-person event is facing and from what I’ve seen, they’re all doing their level best.

None of these events were particularly large. Attendence was maybe somewhere between 100 and 200 people at each one. I know that there’s still a risk in any kind of indoor gathering but these events feel safer than the really big tech gatherings (like the one in Berlin where I got the ’rona—that was literally tens of thousands of people).

Anyway, all three events were thoroughly enjoyable. Partly that’s because the talks were good, but also because the socialising was really, really nice—all the nicer for being in relatively safe environments.

It’s not exactly an earth-shattering observation to point out that the social side of conferences is just as valuable as the content. But now that so many of us are working remotely, I feel like that aspect of in-person events has become even more important.

Or maybe I’m just appreciating that aspect of in-person events after spending such a long time with screen-mediated interactions only.

Wednesday, October 19th, 2022

JavaScript

A recurring theme in my writing and talks is “lay off the JavaScript, people!” But I have to make a conscious effort to specify that I mean client-side JavaScript.

I thought it would be obvious from the context that I was talking about the copious amounts of JavaScript being shipped to end users to download, parse, and execute. But nothing’s ever really obvious. If I don’t explicitly say JavaScript in the browser, then someone inevitably thinks I’m having a go at JavaScript, the language.

I have absolutely nothing against JavaScript the language. Just like I have nothing against Python or Ruby or any other language that you might write with on your machine or your web server. But as soon as you deliver bytes over the wire, I start having opinions. It just so happens that JavaScript is the universal language for client-side coding so that’s why I call for restraint with JavaScript specifically.

There was a time when JavaScript only existed in web browsers. That changed with Node. Now it’s possible to write code for your web server and code for web browsers using the same language. Very handy!

But just because it’s the same language doesn’t mean you should treat it the same in both circumstance. As Remy puts it:

There are two JavaScripts.

One for the server - where you can go wild.

One for the client - that should be thoughtful and careful.

I was reading something recently that referred to Eleventy as a JavaScript library. It really brought me up short. I mean, on the one hand, yes, it’s a library of code and it’s written in JavaScript. It is absolutely technically correct to call it a JavaScript library.

But in my mind, a JavaScript library is something you ship to web browsers—jQuery, React, Vue, and so on. Whereas Eleventy executes its code in order to generate HTML and that’s what gets sent to end users. Conceptually, it’s like the opposite of a JavaScript library. Eleventy does its work before any user requests a URL—JavaScript libraries do their work after a user requests a URL.

To me it seems obvious that there should an entirely different mindset for writing code intended for a web browser. But nothing’s ever really obvious.

I remember when Node was getting really popular and npm came along as a way to manage all the bundles of code that people were assembling in their Node programmes. Makes total sense. But then I thought I heard about people using npm to do the same thing for client-side code. “That can’t be right!” I thought. I must’ve misunderstood. So I talked to someone from npm and explained how I must be misunderstanding something.

But it turned out that people really were treating client-side JavaScript no different than server-side JavaScript. People really were pulling in megabytes of other people’s code to ship to end users so that they could, I dunno, left pad numbers or something.

Listen, I don’t care what you get up to in the privacy of your own codebase. But don’t poison the well of the web with profligate client-side JavaScript.

Tuesday, October 11th, 2022

Knowing

There’s a repeated catchphrase used throughout Christopher Nolan’s film Tenet: ignorance is our ammunition.

There are certainly situations where knowledge is regrettable. The somewhat-silly thought experiment of Roko’s basilisk is one example. Once you have knowledge of it, you can’t un-know it, and so you become complicit.

Or, to use another example, I think it was Jason who told me that if you want to make someone’s life miserable, just teach them about typography. Then they’ll see all the terrible kerning out there in the world and they won’t be able to un-see it.

I sometimes wish I could un-learn all I’ve learned about cryptobollocks (I realise that the term “cryptocurrency” is the more widely-used phrase, but it’s so inaccurate I’d rather use a clearer term).

I sometimes wish I could go back to having the same understanding of cryptobollocks as most people: some weird new-fangled technology thing that has something to do with “the blockchain.”

But I delved too deep. I wanted to figure out why seemingly-smart people were getting breathlessly excited about something that sounds fairly ludicrous. Yet the more I learned, the more ludicrous it became. Bitcoin and its ilk are even worse than the occassional headlines and horror stories would have you believe.

As Jules says:

The reason I have such a visceral reaction to crypto projects isn’t just that they’re irresponsibly designed and usually don’t achieve what they promise. It’s also that the thing they promise sounds like a fucking nightmare.

Or, as Simon responded to someone wondering why there was so much crypto hate:

We hate it because we understand it.

I have yet to encounter a crypto project that isn’t a Ponzi scheme. I don’t mean like a Ponzi scheme. I mean they’re literally Ponzi schemes: zero-sum racing to the bottom built entirely on the greater fool theory. The only difference between traditional Ponzi schemes and those built on crypto is that crypto isn’t regulated. Yet.

I recently read The Glass Hotel by Emily St. John Mandel, a novel with the collapse of a Ponzi scheme at its heart. In the aftermath of the scheme’s collapse, there are inevitable questions like “How could you not know?” The narrator answers that question:

It’s possible to both know and not know something.

I’ve been thinking about that a lot.

Friday, October 7th, 2022

The audio from dConstruct 2022

dConstruct 2022 was great fun. It was also the last ever dConstruct.

If you were there, and you’d like to re-live the magic, the audio from the talks is now available on the dConstruct Archive. Here they are:

Thanks to some service worker magic, you can select any of those talks for offline listening later.

The audio is also available on Huffduffer on the dConstruct Huffduffer account. Here’s the RSS feed that you can pop into your podcast software of choice.

If you’re more of a visual person, you can watch videos of the slides synced with the audio. They’ve all got captions too (good ones, not just automatically generated).

So have a listen in whichever way you prefer.

Now that I’ve added the audio from the last dConstruct to the dConstruct archive, it feels like the closing scene of Raiders Of The Lost Ark. Roll credits.

Friday, September 30th, 2022

Supporting logical properties

I wrote recently about making the switch to logical properties over on The Session.

Initially I tried ripping the band-aid off and swapping out all the directional properties for logical properties. After all, support for logical properties is green across the board.

But then I got some reports of people seeing formating issues. These people were using Safari on devices that could no longer update their operating system. Because versions of Safari are tied to versions of the operating system, there was nothing they could do other than switch to using a different browser.

I’ve said it before and I’ll say it again, but as long as this situation continues, Safari is not an evergreen browser. (I also understand that problem lies with the OS architecture—it must be incredibly frustrating for the folks working on WebKit and/or Safari.)

So I needed to add fallbacks for older browsers that don’t support logical properties. Or, to put it another way, I needed to add logical properties as a progressive enhancement.

“No problem!” I thought. “The way that CSS works, I can just put the logical version right after the directional version.”

element {
  margin-left: 1em;
  margin-inline-start: 1em;
}

But that’s not true in this case. I’m not over-riding a value, I’m setting two different properties.

In a left-to-right language like English it’s true that margin-inline-start will over-ride margin-left. But in a right-to-left language, I’ve just set margin-left and margin-inline-start (which happens to be on the right).

This is a job for @supports!

element {
  margin-left: 1em;
}
@supports (margin-inline-start: 1em) {
  element {
    margin-left: unset;
    margin-inline-start: 1em;
  }
}

I’m doing two things inside the @supports block. I’m applying the logical property I’ve just tested for. I’m also undoing the previously declared directional property.

A value of unset is perfect for this:

The unset CSS keyword resets a property to its inherited value if the property naturally inherits from its parent, and to its initial value if not. In other words, it behaves like the inherit keyword in the first case, when the property is an inherited property, and like the initial keyword in the second case, when the property is a non-inherited property.

Now I’ve got three CSS features working very nicely together:

  1. @supports (also known as feature queries),
  2. logical properties, and
  3. the unset keyword.

For anyone using an up-to-date browser, none of this will make any difference. But for anyone who can’t update their Safari browser because they can’t update their operating system, because they don’t want to throw out their perfectly functional Apple device, they’ll continue to get the older directional properties:

I discovered that my Mom’s iPad was a 1st generation iPad Air. Apple stopped supporting that device in iOS 12, which means it was stuck with whatever version of Safari last shipped with iOS 12.

Monday, September 26th, 2022

Design systems thinking

As you can probably tell from the stuff I’ve been linking to today and today’s Clearleft newsletter, I’ve got design systems on my mind.

What I like about design systems is they encourage systems thinking …in theory. I mean, it’s right there in the name, right? But in practice I see design sytems focusing on the opposite of systems thinking: analytical thinking.

Okay, I realise that’s a gross oversimplification of both systems and thinking and analytical thinking, but why stop now?

Analytical thinking is all about breaking a big thing down into its constituent parts. By examining the individual parts you gain an understanding of the whole.

This is a great approach to understanding the world, particularly when it comes to phenonema that work the same everywhere in the universe. But it doesn’t work so well with messy phenonema like, say, people doing things together.

Systems thinking takes the opposite approach. You look at the bigger picture with the understanding that the individual parts are all interconnected somehow and can’t really be viewed in isolation.

To put it very bluntly, analytical thinking is about zooming in whereas systems thinking is about zooming out.

When it comes to design systems—or design in general—you need to have a mix of both.

If you neglect the analytical thinking, you may end up with a design system that has well-documented processes for how it operates, but is lacking the individual components.

If you neglect the systems thinking, you may end up with a design system that’s a collection of components, but with no understanding of how they’re supposed to work together.

Ideally, you want a good mix of both.

But I’ve got to be honest: if I had to err on one side more than the other, I think I’d rather have less analytical thinking and more systems thinking.

Tuesday, September 20th, 2022

Accessibility is systemic

I keep thinking about this blog post I linked to last week by Jacob Kaplan-Moss. It’s called Quality Is Systemic:

Software quality is more the result of a system designed to produce quality, and not so much the result of individual performance. That is: a group of mediocre programmers working with a structure designed to produce quality will produce better software than a group of fantastic programmers working in a system designed with other goals.

I think he’s on to something. I also think this applies to design just as much as development. Maybe more so. In design, there’s maybe too much emphasis placed on the talent and skill of individual designers and not enough emphasis placed on creating and nurturing a healthy environment where anyone can contribute to the design process.

Jacob also ties this into hiring:

Instead of spending tons of time and effort on hiring because you believe that you can “only hire the best”, direct some of that effort towards building a system that produces great results out of a wider spectrum of individual performance.

I couldn’t agree more! It just one of the reasons why the smart long-term strategy can be to concentrate on nurturing junior designers and developers rather than head-hunting rockstars.

As an aside, if you think that the process of nurturing junior designers and developers is trickier now that we’re working remotely, I highly recommend reading Mandy’s post, Official myths:

Supporting junior staff is work. It’s work whether you’re in an office some or all of the time, and it’s work if Slack is the only office you know. Hauling staff back to the office doesn’t make supporting junior staff easier or even more likely.

Hiring highly experienced designers and developers makes total sense, at least in the short term. But I think the better long-term solution—as outlined by Jacob—is to create (and care for) a system where even inexperienced practitioners will be able to do good work by having the support and access to knowledge that they need.

I was thinking about this last week when Irina very kindly agreed to present a lunch’n’learn for Clearleft all about inclusive design.

She answered a question that had been at the front of my mind: what’s the difference between inclusive design and accessibility?

The way Irina put it, accessibility is focused on implementation. To make a website accessible, you need people with the necessary skills, knowledge and experience.

But inclusive design is about the process and the system that leads to that implementation.

To use that cliché of the double diamond, maybe inclusive design is about “building the right thing” and accessibility is about “building the thing right.”

Or to put it another way, maybe accessibility is about outputs, whereas inclusive design is about inputs. You need both, but maybe we put too much emphasis on the outputs and not enough emphasis on the inputs.

This is what made me think of Jacob’s assertion that quality is systemic.

Imagine someone who’s an expert at accessibility: they know all the details of WCAG and ARIA. Now put that person into an organisation that doesn’t prioritise accessibility. They’re going to have a hard time and they probably won’t be able to be very effective despite all their skills.

Now imagine an organisation that priorities inclusivity. Even if their staff don’t (yet) have the skills and knowledge of an accessibility expert, just having the processes and priorities in place from the start will make it easier for everyone to contribute to a more accessible experience.

It’s possible to make something accessible in the absence of a system that prioritises inclusive design but it will be hard work. Whereas making sure inclusive design is prioritised at an organisational level makes it much more likely that the outputs will be accessible.