Tags: change

I did an episode of the Clearleft podcast on innovation a while back:

Everyone wants to be innovative …but no one wants to take risks.

The word innovation is often bandied about in an unquestioned positive way. But if we acknowledge that innovation is—by definition—risky, then the exhortations sound less positive.

“We provide innovative solutions for businesses!” becomes “We provide risky solutions for businesses!”

I was reminded of this when I saw the website for the Podcast Standards Project. The original text on the website described the project as:

…a grassroots coalition working to establish modern, open standards, to enable innovation in the podcast industry.

I pushed back on that wording (partly because I’ve seen the word “innovation” used as a smoke screen for user-hostile practices like tracking and surveillance). The wording has since changed to:

…a grassroots coalition dedicated to creating standards and practices that improve the open podcasting ecosystem for both listeners and creators.

That’s better. It’s more precise.

Am I nitpicking? Only if you think that “innovation” and “improvement” are synonyms. I don’t think they are.

Innovation implies change. Improvement implies positive change.

Not all change is positive. Not all innovation is positive.

Innovation goes hand in hand with disruption. Again, disruption involves change. But not necessarily positive change.

Think about the antonyms of change and disruption: stasis and stability. Those words don’t sound very exciting, but in some arenas they’re exactly what you should be aiming for; arenas like infrastructure or standards.

Not to get all pace layers-y here, but it seems to me that every endeavour has a sweet spot for innovation. For some projects, too little innovation is bad. For others, too much innovation is worse.

The trick is knowing which kind of project you’re working on.

(As a side note, I think some people use the word innovation to describe the generative, divergent phase of a design project: “how might we come up with innovative new approaches?” But we already have a word to describe the practice of generating novel and interesting ideas. That word isn’t innovation. It’s creativity.)

Spring is arriving. It’s just taking its time.

There are little signs. Buds on the trees. The first asparagus of the year. Daffodils. Changing the clocks. A stretch in the evenings. But the weather remains, for the most part, chilly and grim.

Reality is refusing to behave like a fast-forward montage leading up to to a single day when you throw open the curtains and springtime is suddenly there in all its glory.

That’s okay. I can wait. I’ve had a lot of practice over the past three years. We all have. Staying home, biding time, saving lives.

But hunkering down during The Situation isn’t like taking shelter during an air raid. There isn’t a signal that sounds to indicate “all clear!” It’s more like going from Winter to Spring. It’s slow, almost impercetible. But it is happening.

I’ve noticed a subtle change in my risk assessment over the past few months. I still think about COVID-19. I still factor it into my calculations. But it’s no longer the first thing I think of.

That’s a subtle change. It doesn’t seem like that long ago when COVID was at the forefront of my mind, especially if I was weighing up an excursion. Is it worth going to that restaurant? How badly do I want to go to that gig? Should I go to that conference?

Now I find myself thinking of COVID as less of a factor in my decision-making. It’s still there, but it has slowly slipped down the ranking.

I know that other people feel differently. For some people, COVID slipped out of their minds long ago. For others, it’s still very much front and centre. There isn’t a consensus on how to evaluate the risks. Like I said:

It’s like when you’re driving and you think that everyone going faster than you is a maniac, and everyone going slower than you is an idiot.

COVID-19 isn’t going away. But perhaps The Situation is.

The Situation has been gradually fading away. There isn’t a single moment where, from one day to the next, we can say “this marks the point where The Situation ended.” Even if there were, it would be a different moment for everyone.

As of today, the COVID-19 app officially stops working. Perhaps today is as good a day as any to say Spring has arrived. The season of rebirth.

I’ve already written about how much I enjoyed hosting Leading Design San Francisco last week.

All the speakers were terrific. Lola’s talk was particularly …um, interesting:

In this talk, Lola will share her adventures in the world of blockchain, the hostility she experienced in her first go-round in 2018, and why she’s chosen to head back to a technology that is going through its largest reputational and social crisis to date.

Wait …I was supposed to stand on stage and introduce a talk that was (at least partly) about blockchain? I have opinions.

As it turned out, Lola warned me that I’d be making an appearance in her talk. She was going to quote that blog post. Before the talk, I asked her how obnoxious I could be about blockchain in her intro. She told me to bring it.

So in the introduction, I deployed all the sarcasm I had in me and said:

Listen, we designers have a tendency to be over-critical of things sometimes. There are all these ideas that we dismiss: phrenology, homeopathy, flat-earthism …blockchain. Haters gonna hate.

I remember somebody asking online a while back, “Why the hate for web3?” And someone I know responded by saying “We hate it because we understand it.” I think there’s a lot of truth to that.

But look, just because blockchains are powering crypto ponzi schemes and N F fucking Ts, it’s worth remembering that it’s also simply a technology. It’s a technological solution in search of a problem.

To be fair, it’s still early days. After all, it’s only been over a decade now.

It’s like the law of instrument says; when all you have is a hammer, everything looks like a nail. Blockchain is like that. Except the hammer is also made of glass.

Anyway, Lola is going to defend the indefensible and talk about blockchain. One thing to keep in mind is this: remember when everyone was talking about “The Cloud”? And then it turned out that you could substitute the phrase “someone else’s server” for “The Cloud?” Well, every time you hear Lola say the word “blockchain”, I’d like you to mentally substitute the phrase “multiple copies of a spreadsheet.”

Please give an open mind and a warm welcome to Lola Oyelayo Pearson!

I got some laughs. I also got lots of gasps and pearl-clutching, as though I were saying something taboo. Welcome to San Francisco.

Lola gave as good as she got. I got a roasting in her talk.

And just to clarify, Lola and I are friends—this was a consensual smackdown.

There was a very serious point to Lola’s talk. Cryptobollocks and other blockchain-powered schemes have historically been very bro-y, and exploitative of non-bro communities. Lola wants to fight that trend.

I get it. But it reminds me a bit of the justifications you hear from people who go to work at Facebook claiming that they can do more good from the inside. Whatever helps you sleep at night.

The crux of Lola’s belief is this: blockchain technology is inevitable, therefore it is uncumbent on us as ethical designers to ensure that the technology is deployed in a way that empowers people instead of exploiting them.

But I take issue with the premise. Blockchain technology is not inevitable. That’s the worst kind of technological determinism. It’s defeatist. It’s a depressing view of “progress” driven not by people, but by technological forces beyond our control.

I refuse to accept that anti-humanist deterministic view.

In any case, for technological determinism to have any validity, there needs to be something to it. At least virtual reality and machine learning are based on some actual technologies. In the case of cryptobollocks, there is no there there. There is nothing except the hype, which is why you’ll see blockchain enthusiasts trying to ride the coattails of trending technologies in a logical fallacy that goes something like this:

1. There are technologies that will be really big in the future,
2. blockchain is a technology, therefore
3. blockchain will be really big in the future.

Blockchain is bullshit. It isn’t even very clever bullshit. And it certainly isn’t inevitable.

I’ve spent the last few days in San Francisco where I was hosting Leading Design.

It was excellent. Rebecca did an absolutely amazing job with the curation, and the Clearleft delivered a terrific event, as always. I’m continually amazed by the way such a relatively small agency can punch above its weight when it comes to putting on world-class events and delivering client work.

I won’t go into much detail on what was shared at Leading Design. There’s an understanding that it’s a safe space for people to speak freely and share their experiences in an open and honest way. I can tell you that there were some tough topics. Given the recent rounds of layoffs in this neck of the woods, this was bound to happen.

I was chatting with Peter at breakfast on the second day and he was saying that maybe there was too much emphasis on the negative, like we were in danger of wallowing in our own misery. It’s a fair point, but I offered a counterpoint that I also heard other people express: when else do these people get a chance to let their guard down and have a good ol’ moan? These are design leaders who need to project an air of calm reassurance when they’re at work. Leading Design is a welcome opportunity to just let it all out.

When we did Leading Design in New York in March of 2022, it was an intimate gathering and the overwhelming theme was togetherness. After two years of screen-based interactions, it was cathartic to get together in the same location to swap stories and be reminded you are not alone.

Leading Design San Francisco was equally cathartic, but the theme this time was change. Change can be scary. But it can also be energising.

After two days of introducing and listening to fascinating talks on the topic of change, I closed out my duties by quoting the late great Octavia Butler. I spoke the mantra of the secular Earthseed religion founded in Parable Of The Sower:

All that you touch
You Change.

All that you Change
Changes you.

The only lasting truth
Is Change.

God
Is Change.

I think it was Jason who once told me that if you want to make someone’s life a misery, teach them about typography. After that they’ll be doomed to notice all the terrible type choices and kerning out there in the world. They won’t be able to unsee it. It’s like trying to unsee the arrow in the FedEx logo.

I think that Stewart Brand’s pace layers model is a similar kind of mind virus, albeit milder. Once you’ve been exposed to it, you start seeing in it in all kinds of systems.

Each layer is functionally different from the others and operates somewhat independently, but each layer influences and responds to the layers closest to it in a way that makes the whole system resilient.

Last month I sent out an edition of the Clearleft newsletter that was all about pace layers. I gathered together examples of people who have been infected with the pace-layer mindworm who were applying the same layered thinking to other areas:

• Rich applied pace layers to career paths,
• Mark applied pace layers to the design process, and
• Jorge Arango applied pace layers to reading.

My own little mash-up is applying pace layers to the World Wide Web. Tom even brought it to life as an animation.

See the Pen Web Layers Of Pace by Tom (@webrocker) on CodePen.

Recently I had another flare-up of the pace-layer pattern-matching infection.

I was talking to some visiting Austrian students on the weekend about design principles. I explained my mild obsession with design principles stemming from the fact that they sit between “purpose” (or values) and “patterns” (the actual outputs):

Purpose » Principles » Patterns

Your purpose is “why?”

That then influences your principles, “how?”

Those principles inform your patterns, “what?”

Hey, wait a minute! If you put that list in reverse order it looks an awful lot like the pace-layers model with the slowest moving layer at the bottom and the fastest moving layer at the top. Perhaps there’s even room for an additional layer when patterns go into production:

• Production
• Patterns
• Principles
• Purpose

Your purpose should rarely—if ever—change. Your principles can change, but not too frequently. Your patterns need to change quite often. And what you’re actually putting out into production should be constantly updated.

As you travel from the most abstract layer—“purpose”—to the most concrete layer—“production”—the pace of change increases.

I can’t tell if I’m onto something here or if I’m just being apopheniac. Again.

After I jotted down some quick thoughts last week on the disastrous way that Google Chrome rolled out a breaking change, others have posted more measured and incisive takes:

• Chris Ferdinandi wrote Google vs. the web,
• Rich Harris wrote Stay alert,
• Chris Coyier wrote Choice Words about the Upcoming Deprecation of JavaScript Dialogs, and
• Jim Nielsen wrote I Want To Confirm a Prompt That We Stay Alert

In fairness to Google, the Chrome team is receiving the brunt of the criticism because they were the first movers. Mozilla and Apple are on baord with making the same breaking change, but Google is taking the lead on this.

As I said in my piece, my issue was less to do with whether confirm(), prompt(), and alert() should be deprecated but more to do with how it was done, and the woeful lack of communication.

Thinking about it some more, I realised that what bothered me was the lack of an upgrade path. Considering that dialog is nowhere near ready for use, it seems awfully cart-before-horse-putting to first remove a feature and then figure out a replacement.

I was chatting to Amber recently and realised that there was a very different example of a feature being deprecated in web browsers…

We were talking about the KeyboardEvent.keycode property. Did you get the memo that it’s deprecated?

But fear not! You can use the KeyboardEvent.code property instead. It’s much nicer to use too. You don’t need to look up a table of numbers to figure out how to refer to a specific key on the keyboard—you use its actual value instead.

So the way that change was communicated was:

Hey, you really shouldn’t use the keycode property. Here’s a better alternative.

But with the more recently change, the communication was more like:

Hey, you really shouldn’t use confirm(), prompt(), or alert(). So go fuck yourself.