Tuesday, November 10th, 2020
Monday, June 15th, 2020
Myself and Stuart had a chat with Brian about browser engine diversity.
Here’s the audio file if you’d like to huffduff it.
Thursday, April 16th, 2020
Naomi Kritzer published a short story five years ago called So Much Cooking about a food blogger in lockdown during a pandemic. Prescient.
I left a lot of the details about the disease vague in the story, because what I wanted to talk about was not the science but the individuals struggling to get by as this crisis raged around them. There’s a common assumption that if the shit ever truly hit the fan, people would turn on one another like sharks turning on a wounded shark. In fact, the opposite usually happens: humans in disasters form tight community bonds, help their neighbors, offer what they can to the community.
Monday, January 20th, 2020
It’s official. Microsoft’s Edge browser is running on the Blink rendering engine and it’s available now.
Just over a year ago, I wrote about my feelings on this decision:
I’m sure the decision makes sound business sense for Microsoft, but it’s not good for the health of the web.
The importance of browser engine diversity is beautifully illustrated (literally) in Rachel’s The Ecological Impact of Browser Diversity.
But I was chatting to Amber the other day, and I mentioned how I can see the theoretical justification for Microsoft’s decision …even if I don’t quite buy it myself.
Picture, if you will, something I’ll call the bar of unity. It’s a measurement of how much collaboration is happening between browser makers.
In the early days of the web, the bar of unity was very low indeed. The two main browser vendors—Microsoft and Netscape—not only weren’t collaborating, they were actively splintering the languages of the web. One of them would invent a new HTML element, and the other would invent a completely different element to do the same thing (remember
There wasn’t enough collaboration. Our collective anger at this situation led directly to the creation of The Web Standards Project.
Eventually, those companies did start collaborating on standards at the W3C. The bar of unity was raised.
This has been the situation for most of the web’s history. Different browser makers agreed on standards, but went their own separate ways on implementation. That’s where they drew the line.
Now that line is being redrawn. The bar of unity is being raised. Now, a number of separate browser makers—Google, Samsung, Microsoft—not only collaborate on standards but also on implementation, sharing a codebase.
The bar of unity isn’t right at the top. Browsers can still differentiate in their user interfaces. Edge, for example, can—and does—offer very sensible defaults for blocking trackers. That’s much harder for Chrome to do, given that Google are amongst the worst offenders.
So these browsers are still competing, but the competition is no longer happening at the level of the rendering engine.
I can see how this looks like a positive development. In fact, from this point of view, Mozilla are getting in the way of progress by having a separate codebase (yes, this is a genuinely-held opinion by some people).
On the face of it, more unity sounds good. It sounds like more collaboration. More cooperation.
But then I think of situations where complete unity isn’t necessarily a good thing. Take political systems, for example. If you have hundreds of different political parties, that’s not ideal. But if you only have one political party, that’s very bad indeed!
There’s a sweet spot somewhere in between where there’s a base of level of agreement and cooperation, but there’s also plenty of room for disagreement and opposition. Right now, the browser landscape is just about still in that sweet spot. It’s like a two-party system where one party has a crushing majority. Checks and balances exist, but they’re in peril.
Firefox is one of the last remaining representatives offering an alternative. The least we can do is support it.
Thursday, May 17th, 2018
Robin Sloan smushes the video game Fortnite Battle Royale together with Liu Cixin’s Three Body Problem trilogy and produces a perfect example of game theory, cooperation, and the prisoner’s dilemma.
Based on my experiments in the laboratory of Fortnite, I think Liu Cixin is wrong. Or at least, he’s not entirely right. Fortnite is more Dark Forest theory than not, and maybe that’s true of the universe, too. But sometimes, we have a lever against the vise of game theory, and in this case, it is a single bit of communication. I mean “bit” in the programmer’s sense: a flag with a designated meaning. Nothing more. My heart emote didn’t make Fortnite cuddly and collaborative, but it did allow me to communicate: “Hold up. Let’s do this a different way.”
Thursday, January 25th, 2018
Design ops for design systems
Leading Design was one of the best events I attended last year. To be honest, that surprised me—I wasn’t sure how relevant it would be to me, but it turned out to be the most on-the-nose conference I could’ve wished for.
Seeing as the event was all about design leadership, there was inevitably some talk of design ops. But I noticed that the term was being used in two different ways.
Sometimes a speaker would talk about design ops and mean “operations, specifically for designers.” That means all the usual office practicalities—equipment, furniture, software—that designers might need to do their jobs. For example, one of the speakers recommended having a dedicated design ops person rather than trying to juggle that yourself. That’s good advice, as long as you understand what’s meant by design ops in that context.
There’s another context of use for the phrase “design ops”, and it’s one that we use far more often at Clearleft. It’s related to design systems.
Now, “design system” is itself a term that can be ambiguous. See also “pattern library” and “style guide”. Quite a few people have had a stab at disambiguating those terms, and I think there’s general agreement—a design system is the overall big-picture “thing” that can contain a pattern library, and/or a style guide, and/or much more besides:
- Styleguides, Pattern Libraries and Design Languages
- Design Systems vs. Pattern Libraries vs. Style Guides – What’s the Difference?
- Design Systems, Style Guides, and Pattern Libraries: Oh My!
- What’s the difference between style guides, pattern libraries, and design systems?
None of those great posts attempt to define design ops, and that’s totally fair, because they’re all attempting to define things—style guides, pattern libraries, and design systems—whereas design ops isn’t a thing, it’s a practice. But I do think that design ops follows on nicely from design systems. I think that design ops is the practice of adopting and using a design system.
There are plenty of posts out there about the challenges of getting people to use a design system, and while very few of them use the term design ops, I think that’s what all of them are about:
- Why Design Systems Fail
- Tips for in-house teams in a free market software culture
- Putting your design system into practice
Clearly design systems and design ops are very closely related: you really can’t have one without the other. What I find interesting is that a lot of the challenges relating to design systems (and pattern libraries, and style guides) might be technical, whereas the challenges of design ops are almost entirely cultural.
I realise that tying design ops directly to design systems is somewhat limiting, and the truth is that design ops can encompass much more. I like Andy’s description:
Design Ops is essentially the practice of reducing operational inefficiencies in the design workflow through process and technological advancements.
Now, in theory, that can encompass any operational stuff—equipment, furniture, software—but in practice, when we’re dealing with design ops, 90% of the time it’s related to a design system. I guess I could use a whole new term (design systems ops?) but I think the term design ops works well …as long as everyone involved is clear on the kind of design ops we’re all talking about.
Wednesday, November 1st, 2017
Advice on building design systems:
- If you can avoid being ambiguous, please do.
- Favor common understanding over dictionary correctness.
- Make great operations a priority.
- Don’t get trapped in defining things instead of explaining things.
Monday, July 31st, 2017
Such a great primer on game theory—well worth half an hour of your time.
Friday, May 19th, 2017
Austin Kleon expands on Brian Eno’s neologism “scenius”:
Genius is an egosystem, scenius is an ecosystem.
Sunday, January 15th, 2017
Tuesday, June 14th, 2016
From twenty years ago, a look back at the origins of the internet, written by its creators.
Sunday, June 12th, 2016
Monday, November 1st, 2010
A nifty idea to help you people save on postage by clubbing together to make a single Amazon purchase.
Friday, May 28th, 2010
Matt Ridley's new book sounds like a corker.