Journal

2710 sparkline

Thursday, August 13th, 2020

Season one of the Clearleft podcast

The Clearleft Podcast has finished its inaugural season.

I have to say, I’m pretty darned pleased with the results. It was equal parts fun and hard work.

Episode One

Design Systems. This was a deliberately brief episode that just skims the surface of all that design systems have to offer. It is almost certainly a theme that I’ll revisit in a later episode, or even a whole season.

The main goal of this episode was to get some answers to the questions:

  1. What is a design system exactly? and
  2. What’s a design system good for?

I’m not sure if I got answers or just more questions, but that’s no bad thing.

Episode Two

Service Design. This is the classic topic for this season—an investigation into a phrase that you’ve almost certainly heard of, but might not understand completely. Or maybe that’s just me. In any case, I think that coming at this topic from a viewpoint of relative ignorance is quite a benefit: I have no fear of looking stupid for asking basic questions.

Episode Three

Wildlife Photographer Of The Year. A case study. This one was a lot of fun to put together.

It also really drove home to just how talented and hard-working my colleagues at Clearleft are. I just kept thinking, “Damn! This is some great work!

Episode Four

Design Ops. Again, a classic example of me asking the dumb questions. What is this “design ops” thing I’ve heard of? Where’d it come from?

My favourite bit of feedback was “Thanks to the podcast, I now know what DesignOps is. I now also hate DesignOps”

I couldn’t resist upping the ante into a bit of a meta-discussion about whether we benefit or not from the introduction of new phrases like this into our work.

Episode Five

Design Maturity. This could’ve been quite a dry topic but I think that Aarron made it really engaging. Maybe the samples from Bladerunner and Thunderbirds helped too.

This episode finished with a call to action …with the wrong URL. Doh! It should’ve been surveymonkey.co.uk/r/designmaturity

Episode Six

Design Sprints. I like how the structure of this one turned out. I felt like we tackled quite a few angles in less than 25 minutes.

That’s a good one to wrap up this season, I reckon.

If you’re interested in the behind-the-scenes work that went into each episode, I’ve been blogging about each one:

  1. Design Systems
  2. Service Design
  3. Wildlife Photographer Of The Year
  4. Design Ops
  5. Design Maturity
  6. Design Sprints

I’m already excited about doing a second season …though I’m going to enjoy a little break from podcasting for a little bit.

As I say at the end of most episodes, if you’ve got any feedback to offer on the podcast, send me an email at jeremy@clearleft.com

And if you’ve enjoyed the Clearleft podcast—or a particular episode—please share it far and wide.

BetrayURL

Back in February, I wrote about an excellent proposal by Jake for how browsers could display URLs in a safer way. Crucially, this involved highlighting the important part of the URL, but didn’t involve hiding any part. It’s a really elegant solution.

Turns out it was a Trojan horse. Chrome are now running an experiment where they will do the exact opposite: they will hide parts of the URL instead of highlighting the important part.

You can change this behaviour if you’re in the less than 1% of people who ever change default settings in browsers.

I’m really disappointed to see that Jake’s proposal isn’t going to be implemented. It was a much, much better solution.

No doubt I will hear rejoinders that the “solution” that Chrome is experimenting with is pretty similar to what Jake proposed. Nothing could be further from the truth. Jake’s solution empowered users with knowledge without taking anything away. What Chrome will be doing is the opposite of that, infantalising users and making decisions for them “for their own good.”

Seeing a complete URL is going to become a power-user feature, like View Source or user style sheets.

I’m really sad about that because, as Jake’s proposal demonstrates, it doesn’t have to be that way.

Wednesday, August 12th, 2020

Design sprints on the Clearleft podcast

The sixth episode of the Clearleft podcast is now live: design sprints!

It comes in at just under 24 minutes, which feels just about right to me. Once again, it’s a dive into one topic that asks “What is this?”, “What does this mean?”, and “Where did this come from?”

I could’ve invited just about any of the practitioners at Clearleft to join me on this one, but I setttled on Chris, who’s always erudite and sharp.

I also asked ex-Clearleftie Jerlyn to have a chat. You’ll notice that’s been a bit of theme on the Clearleft podcast; asking people who used to work at Clearleft to share their thoughts. I’d quite like to do at least an episode—maybe even a whole season—featuring ex-Clearlefties exclusively. So many great people have worked at the agency of the years, Jerlyn being a prime example.

I’d also like to do an episode some time with the regular contractors we’ve worked with at Clearleft. On this episode, I asked the super-smart Tom Prior to join me.

I recorded those three chats over the past couple of weeks. And it was kind of funny how there was, of course, a looming presence over the topic of design sprints: Jake Knapp. I had sent him an email too but I got an auto-responder saying that he was super busy and would take a while to respond. So I kind of mentally wrote it off.

I spent last week assembling and editing the podcast with the excellent contributions from Jerlyn, Chris, and Tom. But it did feel a bit like Waiting For Godot the way that Jake’s book was being constantly referenced.

Then, on the weekend, Godot showed up.

Jake said he’d have time for a chat on Wednesday. Aargh! That’s the release date for the podcast! I don’t suppose Monday would work?

Very graciously, Jake agreed to a Monday chat (at an ungodly early hour in his time zone). I got an excellent half hour of material straight from the horse’s mouth—a very excitable and fast-talking horse, too.

That left me with just a day to work the material into the episode! I felt like a journalist banging on the keyboard at midnight, ready to run into the printing room shouting “Stop the press!” …although I’m sure the truth is that nobody but me would notice if an episode were released a little late.

Anyway, it all got done in the end and I think it turned out pretty great!

Have a listen for yourself and see what you make of it.

This was the final episode of the first season. I’ll now take a little break from podcasting as I plot and plan for the next season. Watch this space! …and, y’know, subscribe to the podcast.

Monday, August 10th, 2020

Influence

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:

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, August 9th, 2020

Dream speak

I had a double-whammy of a stress dream during the week.

I dreamt I was at a conference where I was supposed to be speaking, but I wasn’t prepared, and I wasn’t where I was supposed to be when I was supposed to be there. Worse, my band were supposed to be playing a gig on the other side of town at the same time. Not only was I panicking about getting myself and my musical equipment to the venue on time, I was also freaking out because I couldn’t remember any of the songs.

You don’t have to be Sigmund freaking Freud to figure out the meanings behind these kinds of dreams. But usually these kind of stress dreams are triggered by some upcoming event like, say, oh, I don’t know, speaking at a conference or playing a gig.

I felt really resentful when I woke up from this dream in a panic in the middle of the night. Instead of being a topical nightmare, I basically had the equivalent of one of those dreams where you’re back at school and it’s the day of the exam and you haven’t prepared. But! When, as an adult, you awake from that dream, you have that glorious moment of remembering “Wait! I’m not in school anymore! Hallelujah!” Whereas with my double-booked stress dream, I got all the stress of the nightmare, plus the waking realisation that “Ah, shit. There are no more conferences. Or gigs.”

I miss them.

Mind you, there is talk of re-entering the practice room at some point in the near future. Playing gigs is still a long way off, but at least I could play music with other people.

Actually, I got to play music with other people this weekend. The music wasn’t Salter Cane, it was traditional Irish music. We gathered in a park, and played together while still keeping our distance. Jessica has written about it in her latest journal entry:

It wasn’t quite a session, but it was the next best thing, and it was certainly the best we’re going to get for some time. And next week, weather permitting, we’ll go back and do it again. The cautious return of something vaguely resembling “normality”, buoying us through the hot days of a very strange summer.

No chance of travelling to speak at a conference though. On the plus side, my carbon footprint has never been lighter.

Online conferences continue. They’re not the same, but they can still be really worthwhile in their own way.

I’ll be speaking at An Event Apart: Front-end Focus on Monday, August 17th (and I’m very excited to see Ire’s talk). I’ll be banging on about design principles for the web:

Designing and developing on the web can feel like a never-ending crusade against the unknown. Design principles are one way of unifying your team to better fight this battle. But as well as the design principles specific to your product or service, there are core principles underpinning the very fabric of the World Wide Web itself. Together, we’ll dive into applying these design principles to build websites that are resilient, performant, accessible, and beautiful.

Tickets are $350 but I can get you a discount. Use the code AEAJER to get $50 off.

I wonder if I’ll have online-appropriate stress dreams in the next week? “My internet is down!”, “I got the date and time wrong!”, “I’m not wearing any trousers!”

Actually, that’s pretty much just my waking life these days.

Connections

Fourteen years ago, I gave a talk at the Reboot conference in Copenhagen. It was called In Praise of the Hyperlink. For the most part, it was a gushing love letter to hypertext, but it also included this observation:

For a conspiracy theorist, there can be no better tool than a piece of technology that allows you to arbitrarily connect information. That tool now exists. It’s called the World Wide Web and it was invented by Sir Tim Berners-Lee.

You know those “crazy walls” that are such a common trope in TV shows and movies? The detectives enter the lair of the unhinged villain and discover an overwhelming wall that’s like looking at the inside of that person’s head. It’s not the stuff itself that’s unnerving; it’s the red thread that connects the stuff.

Red thread. Blue hyperlinks.

When I spoke about the World Wide Web, hypertext, apophenia, and conspiracy theorists back in 2006, conspiracy theories could still be considered mostly harmless. It was the domain of Dan Brown potboilers and UFO enthusiasts with posters on their walls declaring “I Want To Believe”. But even back then, 911 truthers were demonstrating a darker side to the fun and games.

There’s always been a gamification angle to conspiracy theories. Players are rewarded with the same dopamine hits for “doing the research” and connecting unrelated topics. Now that’s been weaponised into QAnon.

In his newsletter, Dan Hon wrote QAnon looks like an alternate reality game. You remember ARGs? The kind of designed experience where people had to cooperate in order to solve the puzzle.

Being a part of QAnon involves doing a lot of independent research. You can imagine the onboarding experience in terms of being exposed to some new phrases, Googling those phrases (which are specifically coded enough to lead to certain websites, and certain information). Finding something out, doing that independent research will give you a dopamine hit. You’ve discovered something, all by yourself. You’ve achieved something. You get to tell your friends about what you’ve discovered because now you know a secret that other people don’t. You’ve done something smart.

We saw this in the games we designed. Players love to be the first person to do something. They love even more to tell everyone else about it. It’s like Crossfit. 

Dan’s brother Adrian also wrote about this connection: What ARGs Can Teach Us About QAnon:

There is a vast amount of information online, and sometimes it is possible to solve “mysteries”, which makes it hard to criticise people for trying, especially when it comes to stopping perceived injustices. But it’s the sheer volume of information online that makes it so easy and so tempting and so fun to draw spurious connections.

This is something that Molly Sauter has been studying for years now, like in her essay The Apophenic Machine:

Humans are storytellers, pattern-spotters, metaphor-makers. When these instincts run away with us, when we impose patterns or relationships on otherwise unrelated things, we call it apophenia. When we create these connections online, we call it the internet, the web circling back to itself again and again. The internet is an apophenic machine.

I remember interviewing Lauren Beukes back in 2012 about her forthcoming book about a time-travelling serial killer:

Me: And you’ve written a time-travel book that’s set entirely in the past.

Lauren: Yes. The book ends in 1993 and that’s because I did not want to have to deal with Kirby the heroine getting some access to CCTV cameras and uploading the footage to 4chan and having them solve the mystery in four minutes flat.

By the way, I noticed something interesting about the methodology behind conspiracy theories—particularly the open-ended never-ending miasma of something like QAnon. It’s no surprise that the methodology is basically an inversion of the scientific method. It’s the Texas sharpshooter fallacy writ large. Well, you know the way that I’m always going on about design principles and they way that good design principles should be reversible? Conspiracy theories take universal principles and invert them. Take Occam’s razor:

Do not multiply entities without necessity.

That’s what they want you to think! Wake up, sheeple! The success of something like QAnon—or a well-designed ARG—depends on a mindset that rigorously inverts Occam’s razor:

Multiply entities without necessity!

That’s always been the logic of conspiracy theories from faked moon landings to crop circles. I remember well when the circlemakers came clean and showed exactly how they had been making their beautiful art. Conspiracy theorists—just like cultists—don’t pack up and go home in the face of evidence. They double down. There was something almost pitiable about the way the crop circle UFO crowd were bending over backwards to reject proof and instead apply the inversion of Occam’s razor to come up with even more outlandish explanations to encompass the circlemakers’ confession.

Anyway, I recommend reading what Dan and Adrian have written about the shared psychology of QAnon and Alternate Reality Games, not least because they also suggest some potential course corrections.

I think the best way to fight QAnon, at its roots, is with a robust social safety net program. This not-a-game is being played out of fear, out of a lack of safety, and it’s meeting peoples’ needs in a collectively, societally destructive way.

I want to add one more red thread to this crazy wall. There’s a book about conspiracy theories that has become more and more relevant over time. It’s also wonderfully entertaining. Here’s my recommendation from that Reboot presentation in 2006:

For a real hot-tub of conspiracy theory pleasure, nothing beats Foucault’s Pendulum by Umberto Eco.

…luck rewarded us, because, wanting connections, we found connections — always, everywhere, and between everything. The world exploded into a whirling network of kinships, where everything pointed to everything else, everything explained everything else…

Wednesday, August 5th, 2020

Design maturity on the Clearleft podcast

The latest episode of the Clearleft podcast is zipping through the RSS tubes towards your podcast-playing software of choice. This is episode five, the penultimate episode of this first season.

This time the topic is design maturity. Like the episode on design ops, this feels like a hefty topic where the word “scale” will inevitably come up.

I talked to my fellow Clearlefties Maite and Andy about their work on last year’s design effectiveness report. But to get the big-scale picture, I called up Aarron over at Invision.

What a great guest! I already had plans to get Aarron on the podcast to talk about his book, Designing For Emotion—possibly a topic for next season. But for the current episode, we didn’t even mention it. It was design maturity all the way.

I had a lot of fun editing the episode together. I decided to intersperse some samples. If you’re familiar with Bladerunner and Thunderbirds, you’ll recognise the audio.

The whole thing comes out at a nice 24 minutes in length.

Have a listen and see what you make of it.

Wednesday, July 29th, 2020

Design ops on the Clearleft podcast

The latest episode of the Clearleft podcast is out. If you’re a subscriber, it will magically appear in your podcast software of choice using the power of RSS. If you’re not a subscriber, it isn’t too late to change that.

This week’s episode is all about design ops. I began contructing the episode by gathering raw material from talks at Leading Design. There’s good stuff from Kim Fellman, Jacqui Frey, Courtney Kaplan, and Meredith Black.

But as I was putting the snippets together, I felt like the episode was missing something. It needed a bit of oomph. So I harangued Andy for some of his time. I wasn’t just fishing for spicy hot takes—something that Andy is known for. Andy is also the right person to explain design ops. If you search for that term, one of the first results you’ll get is a post he wrote on the Clearleft blog a few years back called Design Ops — A New Discipline.

I remember helping Andy edit that post and I distinctly recall my feedback. The initial post didn’t have a definition of the term, and I felt that a definition was necessary (and Andy added one to the post).

My cluenessness about the meaning of terms like “design ops” or “service design” isn’t some schtick I’m putting on for the benefit of the podcast. I’m genuinely trying to understand these terms better. I don’t like the feeling of hearing a term being used a lot without a clear understanding of what that term means. All too often my understanding feels more like “I think I know it means, but I’m not sure I could describe it.” I’m not comfortable with that.

Making podcast episodes on these topics—which are outside my comfort zone—has been really helpful. I now feel like I have a much better understanding of service design, design ops and other topical terms. I hope that the podcast will be just as helpful for listeners who feel as bamboozled as I do.

Ben Holliday recently said:

The secret of design being useful in many places is not talking about design too much and just getting on with it. I sometimes think we create significant language barriers with job titles, design theory and making people learn a new language for the privilege of working with us.

I think there’s some truth to that. Andy disagrees. Strongly.

In our chat, Andy and I had what politicians would describe as “a robust discussion.” I certainly got some great material for the podcast (though some of the more contentious bits remain on the cutting room floor).

Calling on Andy for this episode was definitely the right call. I definitely got the added oomph I was looking for. In fact, this ended up being one of my favourite episodes.

There’s a lot of snappy editing, all in service of crafting a compelling narrative. First, there’s the origin story of design ops. Then there’s an explanation of what it entails. From around the 13 minute mark, there’s a pivot—via design systems—into asking whether introducing a new term is exclusionary. That’s when the sparks start to fly. Finally, I pull it back to talking about how Clearleft can help in providing design ops as a service.

The whole episode comes out at 21 minutes, which feels just right to me.

I’m really pleased with how this episode turned out, and I hope you’ll like it too. Have a listen and decide for yourself.

Wednesday, July 22nd, 2020

Wildlife Photographer Of The Year on the Clearleft podcast

Episode three of the Clearleft podcast is here!

This one is a bit different. Whereas previous episodes focused on specific topics—design systems, service design—this one is a case study. And, wow, what a case study! The whole time I was putting the episode together, I kept thinking “The team really did some excellent work here.”

I’m not sure what makes more sense: listen to the podcast episode first and then visit the site in question …or the other way around? Maybe the other way around. In which case, be sure to visit the website for Wildlife Photographer Of The Year.

That’s right—Clearleft got to work with London’s Natural History Museum! A real treat.

Myself and @dhuntrods really enjoyed our visit to the digitisation department in the Natural History Museum. Thanks, Jen, Josh, Robin, Phaedra, and @scuff_el!

This episode of the podcast ended up being half an hour long. It should probably be shorter but I just couldn’t bring myself to cut any of the insights that Helen, James, Chris, and Trys were sharing. I’m probably too close to the subject matter to be objective about it. I’m hoping that others will find it equally fascinating to hear about the process of the project. Research! Design! Dev! This has got it all.

I had a lot of fun with the opening of the episode. I wanted to create a montage effect like the scene-setting opening of a film that has overlapping news reports. I probably spent far too long doing it but I’m really happy with the final result.

And with this episode, we’re halfway through the first season of the podcast already! I figured a nice short run of six episodes is enough to cover a fair bit of ground and give a taste of what the podcast is aiming for, without it turning into an overwhelming number of episodes in a backlog for you to catch up with. Three down and three to go. Seems manageable, right?

Anyway, enough of the backstory. If you haven’t already subscribed to the Clearleft podcast, you should do that. Then do these three things in whichever order you think works best:

Thursday, July 16th, 2020

Hey now

Progressive enhancement is at the heart of everything I do on the web. It’s the bedrock of my speaking and writing too. Whether I’m writing about JavaScript, Ajax, HTML, or service workers, it’s always through the lens of progressive enhancement. Sometimes I explicitly bang the drum, like with Resilient Web Design. Other times I don’t mention it by name at all, and instead talk only about its benefits.

I sometimes get asked to name some examples of sites that still offer their core functionality even when JavaScript fails. I usually mention Amazon.com, although that has other issues. But quite often I find that a lot of the examples I might mention are dismissed as not being “web apps” (whatever that means).

The pushback I get usually takes the form of “Well, that approach is fine for websites, but it wouldn’t work something like Gmail.”

It’s always Gmail. Which is odd. Because if you really wanted to flummox me with a product or service that defies progressive enhancement, I’d have a hard time with something like, say, a game (although it would be pretty cool to build a text adventure that’s progressively enhanced into a first-person shooter). But an email client? That would work.

Identify core functionality.

Read emails. Write emails.

Make that functionality available using the simplest possible technology.

HTML for showing a list of emails, HTML for displaying the contents of the HTML, HTML for the form you write the response in.

Enhance!

Now add all the enhancements that improve the experience—keyboard shortcuts; Ajax instead of full-page refreshes; local storage, all that stuff.

Can you build something that works just like Gmail without using any JavaScript? No. But that’s not what progressive enhancement is about. It’s about providing the core functionality (reading and writing emails) with the simplest possible technology (HTML) and then enhancing using more powerful technologies (like JavaScript).

Progressive enhancement isn’t about making a choice between using simpler more robust technologies or using more advanced features; it’s about using simpler more robust technologies and then using more advanced features. Have your cake and eat it.

Fortunately I no longer need to run this thought experiment to imagine what it would be like if something like Gmail were built with a progressive enhancement approach. That’s what HEY is.

Sam Stephenson describes the approach they took:

HEY’s UI is 100% HTML over the wire. We render plain-old HTML pages on the server and send them to your browser encoded as text/html. No JSON APIs, no GraphQL, no React—just form submissions and links.

If you think that sounds like the web of 25 years ago, you’re right! Except the HEY front-end stack progressively enhances the “classic web” to work like the “2020 web,” with all the fidelity you’d expect from a well-built SPA.

See? It’s not either resilient or modern—it’s resilient and modern. Have your cake and eat it.

And yet this supremely sensible approach is not considered “modern” web development:

The architecture astronauts who, for the past decade, have been selling us on the necessity of React, Redux, and megabytes of JS, cannot comprehend the possibility of building an email app in 2020 with server-rendered HTML.

HEY isn’t perfect by any means—they’ve got a lot of work to do on their accessibility. But it’s good to have a nice short answer to the question “But what about something like Gmail?”

It reminds me of responsive web design:

When Ethan Marcotte demonstrated the power of responsive design, it was met with resistance. “Sure, a responsive design might work for a simple personal site but there’s no way it could scale to a large complex project.”

Then the Boston Globe launched its responsive site. Microsoft made their homepage responsive. The floodgates opened again.

It’s a similar story today. “Sure, progressive enhancement might work for a simple personal site, but there’s no way it could scale to a large complex project.”

The floodgates are ready to open. We just need you to create the poster child for resilient web design.

It looks like HEY might be that poster child.

I have to wonder if its coincidence or connected that this is a service that’s also tackling ethical issues like tracking? Their focus is very much on people above technology. They’ve taken a human-centric approach to their product and a human-centric approach to web development …because ultimately, that’s what progressive enhancement is.