Saturday, October 9th, 2021
Saturday, September 4th, 2021
An oldie but a goodie. If you think you’re getting statistically significant results from A/B testing, you should probably consider doing some A/A testing.
In an A/A test, you run a test using the exact same options for both “variants” in your test.
Friday, August 27th, 2021
Monday, July 19th, 2021
My talk on sci-fi and me for Beyond Tellerrand’s Stay Curious event was deliberately designed to be broad and expansive. This was in contrast to Steph’s talk which was deliberately narrow and focused on one topic. Specifically, it was all about solarpunk.
I first heard of solarpunk from Justin Pickard back in 2014 at an event I was hosting. He described it as:
individuals and communities harnessing the power of the photovoltaic solar panel to achieve energy-independence.
The sci-fi subgenre of solarpunk, then, is about these communities. The subgenre sets up to be deliberately positive, even utopian, in contrast to most sci-fi.
Most genres ending with the -punk suffix are about aesthetics. You know the way that cyberpunk is laptops, leather and sunglasses, and steampunk is zeppelins and top hats with goggles. Solarpunk is supposedly free of any such “look.” That said, all the examples I’ve seen seem to converge on the motto of “put a tree on it.” If a depiction of the future looks lush, verdant, fecund and green, chances are it’s solarpunk.
At least, it might be solarpunk. It would have to pass the criteria laid down by the gatekeepers. Solarpunk is manifesto-driven sci-fi. I’m not sure how I feel about that. It’s one thing to apply a category to a piece of writing after it’s been written, but it’s another to start with an agenda-driven category and proceed from there. And as with any kind of classification system, the edges are bound to be fuzzy, leading to endless debates about what’s in and what’s out (see also: UX, UI, service design, content design, product design, front-end development, and most ironically of all, information architecture).
When I met up with Steph to discuss our talk topics and she described the various schools of thought that reside under the umbrella of solarpunk, it reminded me of my college days. You wouldn’t have just one Marxist student group, there’d be multiple Marxist student groups each with their own pillars of identity (Leninist, Trotskyist, anarcho-syndicalist, and so on). From the outside they all looked the same, but woe betide you if you mixed them up. It was exactly the kind of situation that was lampooned in Monty Python’s Life of Brian with its People’s Front of Judea and Judean People’s Front. Steph confirmed that those kind of rifts also exist in solarpunk. It’s just like that bit in Gulliver’s Travels where nations go to war over the correct way to crack an egg.
But there’s general agreement about what broadly constitutes solarpunk. It’s a form of cli-fi (climate fiction) but with an upbeat spin: positive but plausible stories of the future that might feature communities, rewilding, gardening, farming, energy independence, or decentralisation. Centralised authority—in the form of governments and corporations—is not to be trusted.
That’s all well and good but it reminds of another community. Libertarian preppers. Heck, even some of the solarpunk examples feature seasteading (but with more trees).
Politically, preppers and solarpunks couldn’t be further apart. Practically, they seem more similar than either of them would be comfortable with.
Both communities distrust centralisation. For the libertarians, this manifests in a hatred of taxation. For solarpunks, it’s all about getting off the electricity grid. But both want to start their own separate self-sustaining communities.
Independence. Decentralisation. Self-sufficiency.
There’s a fine line between Atlas Shrugged and The Whole Earth Catalog.
Sunday, June 13th, 2021
Sunday, May 2nd, 2021
Sunday, January 31st, 2021
Monday, August 10th, 2020
Hidde gave a great talk recently called On the origin of cascades (by means of natural selectors):
It’s been 25 years since the first people proposed a language to style the web. Since the late nineties, CSS lived through years of platform evolution.
It’s a lovely history lesson that reminded me of that great post by Zach Bloom a while back called The Languages Which Almost Became CSS.
The TL;DR timeline of CSS goes something like this:
- June 1993: Rob Raisch proposes some ideas for stylesheets in HTML on the
- October 1993: Pei Wei shares his ideas for a stylesheet language, also on the
- October 1994: Håkon Wium Lie publishes Cascading HTML style sheets — a proposal.
- March 1995: Bert Bos publishes his Stream-based Style sheet Proposal.
Håkon and Bert joined forces and that’s what led to the Cascading Style Sheet language we use today.
Hidde looks at how the concept of the cascade evolved from those early days. But there’s another idea in Håkon’s proposal that fascinates me:
While the author (or publisher) often wants to give the documents a distinct look and feel, the user will set preferences to make all documents appear more similar. Designing a style sheet notation that fill both groups’ needs is a challenge.
The proposed solution is referred to as “influence”.
The user supplies the initial sheet which may request total control of the presentation, but — more likely — hands most of the influence over to the style sheets referenced in the incoming document.
So an author could try demanding that their lovely styles are to be implemented without question by specifying an influence of 100%. The proposed syntax looked like this:
h1.font.size = 24pt 100%
More reasonably, the author could specify, say, 40% influence:
h2.font.size = 20pt 40%
Here, the requested influence is reduced to 40%. If a style sheet later in the cascade also requests influence over h2.font.size, up to 60% can be granted. When the document is rendered, a weighted average of the two requests is calculated, and the final font size is determined.
Okay, that sounds pretty convoluted but then again, so is specificity.
This idea of influence in CSS reminds me of Cap’s post about The Sliding Scale of Giving a Fuck:
Hold on a second. I’m like a two-out-of-ten on this. How strongly do you feel?
I’m probably a six-out-of-ten, I replied after a couple moments of consideration.
Cool, then let’s do it your way.
In the end, the concept of influence in CSS died out, but user style sheets survived …for a while. Now they too are as dead as a dodo. Most people today aren’t aware that browsers used to provide a mechanism for applying your own visual preferences for browsing the web (kind of like Neopets or MySpace but for literally every single web page …just think of how empowering that was!).
Even if you don’t mourn the death of user style sheets—you can dismiss them as a power-user feature—I think it’s such a shame that the concept of shared influence has fallen by the wayside. Web design today is dictatorial. Designers and developers issue their ultimata in the form of CSS, even though technically every line of CSS you write is a suggestion to a web browser—not a demand.
I wish that web design were more of a two-way street, more of a conversation between designer and end user.
There are occassional glimpses of this mindset. Like I said when I added a dark mode to my website:
Y’know, when I first heard about Apple adding dark mode to their OS—and also to CSS—I thought, “Oh, great, Apple are making shit up again!” But then I realised that, like user style sheets, this is one more reminder to designers and developers that they don’t get the last word—users do.
Sunday, July 12th, 2020
Wednesday, May 20th, 2020
Sunday, May 17th, 2020
Do you have a favourite non-personal photograph?
By non-personal, I mean one that isn’t directly related to your life; photographs of family members, friends, travel (remember travel?).
Even discounting those photographs, there’s still a vast pool of candidates. There are all the amazing pictures taken by photojournalists like Lee Miller. There’s all the awe-inspiring wildlife photography out there. Then there are the kind of posters that end up on bedroom walls, like Robert Doisneau’s The Kiss.
One of my favourite photographs of all time has music as its subject matter. No, not Johnny Cash flipping the bird, although I believe this picture to be just as rock’n’roll.
This is a photograph of Séamus Ennis and Jean Ritchie. It was probably taken around 1952 or 1953 by Ritchie’s husband, George Pickow, when Jean Ritchie and Alan Lomax were in Ireland to do field recordings.
I love everything about it.
Séamus Ennis looks genuinely larger than life (which, by all accounts, he was). And just look at the length of those fingers! Meanwhile Jean Ritchie is equally indominatable, just as much as part of the story as the musician she’s there to record.
Both of them have expressions that convey how intent they are on their machines—Ennis’s uilleann pipes and Ritchie’s tape recorder. It’s positively steampunk!
What a perfect snapshot of tradition and technology meeting slap bang in the middle of the twentieth century.
Maybe that’s why I love it so much. One single photograph is filled with so much that’s dear to me—traditional Irish music meets long-term archival preservation.
Monday, March 2nd, 2020
Sunday, March 1st, 2020
Friday, February 14th, 2020
In this interview, Biance Berning says:
Cassie Evans from Clearleft is an interesting person to follow as she combines web animation with variable font technology, essentially exploring the technology’s practicality and expression.
We’re only just scratching the surface of what variable fonts can do within more interactive and immersive spaces. I think we’ll see a lot more progress and experimentation with that as time goes on.
Thursday, January 30th, 2020
Wednesday, January 29th, 2020
Architects, gardeners, and design systems
I compared design systems to dictionaries. My point was that design systems—like language—can be approached in a prescriptivist or descriptivist manner. And I favour descriptivism.
A prescriptive approach might give you a beautiful design system, but if it doesn’t reflect the actual product, it’s fiction. A descriptive approach might give a design system with imperfections and annoying flaws, but at least it will be accurate.
I think it’s more important for a design system to be accurate than beautiful.
Meanwhile, over on Frank’s website, he’s been documenting the process of its (re)design. He made an interesting comparison in his post Redesign: Gardening vs. Architecture. He talks about two styles of writing:
In interviews, Martin has compared himself to a gardener—forgoing detailed outlines and overly planned plot points to favor ideas and opportunities that spring up in the writing process. You see what grows as you write, then tend to it, nurture it. Each tendrilly digression may turn into the next big branch of your story. This feels right: good things grow, and an important quality of growth is that the significant moments are often unanticipated.
On the other side of writing is who I’ll call “the architect”—one who writes detailed outlines for plots and believes in the necessity of overt structure. It puts stock in planning and foresight. Architectural writing favors divisions and subdivisions, then subdivisions of the subdivisions. It depends on people’s ability to move forward by breaking big things down into smaller things with increasing detail.
It’s not just me, right? It all sounds very design systemsy, doesn’t it?
This is a false dichotomy, of course, but everyone favors one mode of working over the other. It’s a matter of personality, from what I can tell.
Replace “personality” with “company culture” and I think you’ve got an interesting analysis of the two different approaches to design systems. Descriptivist gardening and prescriptivist architecture.
Frank also says something that I think resonates with the evergreen debate about whether design systems stifle creativity:
It can be hard to stay interested if it feels like you’re painting by numbers, even if they are your own numbers.
I think Frank’s comparison—gardeners and architects—also speaks to something bigger than design systems…
I gave a talk last year called Building. You can watch it, listen to it, or read the transcript if you like. The talk is about language (sort of). There’s nothing about prescriptivism or descriptivism in there, but there’s lots about metaphors. I dive into the metaphors we use to describe our work and ourselves: builders, engineers, and architects.
It’s rare to find job titles like software gardener, or information librarian (even though they would be just as valid as other terms we’ve made up like software engineer or information architect). Outside of the context of open source projects, we don’t talk much about maintenance. We’re much more likely to talk about making.
When tech culture only celebrates creation, it risks ignoring those who teach, criticize, and take care of others.
Anyone who’s spent any time working on design systems can tell you there’s no shortage of enthusiasm for architecture and making—“let’s build a library of components!”
There’s less enthusiasm for gardening, care, communication and maintenance. But that’s where the really important work happens.
In her book The Real World of Technology, the metallurgist Ursula Franklin contrasts prescriptive technologies, where many individuals produce components of the whole (think about Adam Smith’s pin factory), with holistic technologies, where the creator controls and understands the process from start to finish.
In that light, design systems take their place in a long history of dehumanising approaches to manufacturing like Taylorism. The priorities of “scientific management” are the same as those of design systems—increasing efficiency and enforcing consistency.
Humans aren’t always great at efficiency and consistency, but machines are. Automation increases efficiency and consistency, sacrificing messy humanity along the way:
Machine with the strength of a hundred men
Can’t feed and clothe my children.
Historically, we’ve seen automation in terms of physical labour—dock workers, factory workers, truck drivers. As far as I know, none of those workers participated in the creation of their mechanical successors. But when it comes to our work on the web, we’re positively eager to create the systems to make us redundant.
The usual response to this is the one given to other examples of automation: you’ll be free to spend your time in a more meaningful way. With a design system in place, you’ll be freed from the drudgery of manual labour. Instead, you can spend your time doing more important work …like maintaining the design system.
You’ve heard the joke about the factory of the future, right? The factory of the future will have just two living things in it: one worker and one dog. The worker is there to feed the dog. The dog is there to bite the worker if he touches anything.
Roll on snare drum.
Wednesday, November 27th, 2019
Accessibility on The Session revisited
Earlier this year, I wrote about an accessibility issue I was having on The Session. Specifically, it was an issue with Ajax and pagination. But I managed to sort it out, and the lesson was very clear:
As is so often the case, the issue was with me trying to be too clever with ARIA, and the solution was to ease up on adding so many ARIA attributes.
Wherever the pagination pattern appears, there are “previous” and “next” links, marked up with the appropriate
rel="next" attributes. Well, apparently past me thought it would be clever to add some ARIA attributes in there too. My thinking must’ve been something like this:
- Those links control the area of the page with the search results.
- That area of the page has an ID of “results”.
- I should add
aria-controls="results"to those links.
That was the problem …which is kind of weird, because VoiceOver isn’t supposed to have any support for
aria-controls. Anyway, once I removed that attribute from the links, everything worked just fine.
Just as the solution last time was to remove the
aria-atomic attribute on the updated area, the solution this time was to remove the
aria-controls attribute on the links that trigger the update. Maybe this time I’ll learn my lesson: don’t mess with ARIA attributes you don’t understand.
Thursday, October 3rd, 2019
Wednesday, September 18th, 2019
Tuesday, August 20th, 2019