I can see myself almost certainly needing to use this clever technique at some point so I’m going to squirrel it away now for future me.
Tuesday, April 12th, 2022
Monday, January 17th, 2022
A potted history of communication networks from the pony express and the telegraph to ethernet and wi-fi.
Tuesday, November 16th, 2021
Well, this is just wonderful! Jim has written copious notes after listening to my favourite episode of season three of the Clearleft podcast, measuring design:
I’m going to have to try really, really hard to not just copy/paste the entire transcript of this podcast. It‘s that good. Don’t miss it.
Wednesday, November 3rd, 2021
Publishing The State Of The Web
I put a lot of work into this talk and I think it paid off. I wrote about preparing the talk. I also wrote about recording it. I also published links related to the talk. It was an intense process, but a rewarding one.
I almost called the talk The Overview Effect. My main goal with the talk was to instil a sense of perspective. Hence the references to the famous Earthrise photograph.
On the one hand, I wanted the audience to grasp just how far the web has come. So the first half of the talk is a bit of a trip down memory lane, with a constant return to just how much we can accomplish in browsers today. It’s all very positive and upbeat.
Then I twist the knife. Having shown just how far we’ve progressed technically, I switch gears the moment I say:
The biggest challenges facing the World Wide Web today are not technical challenges.
Then I dive into those challenges, as I see them. It turns out that technical challenges would be preferable to the seemingly intractable problems of today’s web.
I almost wish I could’ve flipped the order: talk about the negative stuff first but then finish with the positive. I worry that the talk could be a bit of a downer. Still, I tried to finish on an optimistic note.
Tuesday, November 2nd, 2021
Hello, my friends. I’d like us to try to collectively achieve something today. What I’d like us to achieve is a sense of perspective.
To do this we need to take a step back and cast an eye on the past.
For example, I can look back and say “Wow, what a terrible year!”
A year of death. A year of polarisation. Of inequality. A corrupt government. Protests in the street as people struggled to fight against systemic racism.
Yes, I am of course talking about the year 1968.
By the end of 1968, the United States of America was a nation in turmoil. Civil rights. The war in Vietnam. It felt like the polarising issues of the day were splitting the country in two.
But in the final week of the year, something happened that offered a sense of perspective.
In an audacious move, NASA decided to bring forward the schedule of its Apollo programme. Apollo 7 was a success but that mission was confined to Earth orbit. For Apollo 8, human beings would leave Earth’s orbit for the first time in history. The bold plan was to fly to and around the moon before returning safely to Earth.
From today’s perspective, you might just see it as a dry run for Apollo 11 when human beings would step foot on the moon. But at the time, it was an unbelievably bold move. A literal moonshot.
On the winter solstice, December 21st 1968, Jim Lovell, Frank Borman, and Bill Anders were launched on their six day mission to the moon and back.
The mission was a success. Everything went according to plan. But the reason why we remember the Apollo 8 mission today is for something that wasn’t planned.
First of all, after the translunar injection when the crew had left Earth orbit and were on their way to the moon (already the furthest distance ever travelled by our species), someone—probably Bill Anders—pointed a camera back at Earth.
This was the first picture ever taken by a human being of the whole earth. It’s quite a perspective-setting sight, seeing the whole Earth. To us today, it’s almost commonplace. But remember that were was a time when no one had ever seen this view.
In fact, throughout the 1960s activist Stewart Brand had a campaign, handing out buttons with the question, “Why haven’t we seen a photograph of the whole Earth yet?”
I like the “yet” at the end of that. It gives it a conspiracy-tinged edge.
Stewart Brand suspected that if people could see their home planet in one image, it could reset their perspectives. They would truly grok the idea of Spaceship Earth, as Buckminster Fuller would say. The idea came to Brand when he was on a rooftop, tripping on acid, experiencing the horizon curve away from him and giving him quite a sense of perspective.
Later, he would start the Whole Earth Catalog. It was like a print version of Wikipedia, with everything you needed to know to run a commune.
Later still, he went on to found the Long Now Foundation, an organisation dedicated to long-term thinking. I’m a proud member.
Their most famous project is the clock of the long now, which will keep time for 10,000 years. This is just a scale model in the Science Museum in London. The full-size clock is being built inside a mountain on geologically stable ground. Just thinking about the engineering challenges involved is bound to give you a certain sense of perspective.
But let’s snap back from 10,000 in the future to that Apollo 8 mission in December of 1968.
This picture of the whole earth wasn’t the most important picture taken by Bill Anders on that flight. By Christmas Eve, the crew had reached the moon and successfully entered lunar orbit.
Oh my God! Look at that picture over there! There’s the Earth coming up. Wow, that’s pretty.
Hey, don’t take that, it’s not scheduled.
You got a color film, Jim? Hand me that roll of color quick, would you…
Oh man, that’s…
This is what Bill Anders captured.
I could try to describe it. But they should’ve sent a poet.
Fifty years later, this poet puts it beautifully. This is Amanda Gorman’s poem Earthrise.
On Christmas Eve, 1968, astronaut Bill Anders
Snapped a photo of the earth
As Apollo 8 orbited the moon.
Those three guys
To see from their eyes
Our planet looked like an earthrise
A blue orb hovering over the moon’s gray horizon,
with deep oceans and silver skies.
It was our world’s first glance at itself
Our first chance to see a shared reality,
A declared stance and a commonality;
A glimpse into our planet’s mirror,
And as threats drew nearer,
Our own urgency became clearer,
As we realize that we hold nothing dearer
than this floating body we all call home.
Astronauts have been known to experience something called the overview effect. It’s a profound change in perspective that comes from seeing the totality of our home planet in all its beauty and fragility.
The Earthrise photograph gave the world a taste of the overview effect, right at a time when it was most needed.
The World Wide Web
I wonder if it’s possible to get an overview effect for the World Wide Web?
There is no photograph of the whole web. We can’t see the web. We can’t travel into space and look back at our online home.
But we can travel back in time. Let’s travel back to 1945.
That was the year that an article was published in The Atlantic Monthly by Vannevar Bush. He was a pop scientist of his day, like Neil de Grasse Tyson or Bill Nye.
The article was called As We May Think. In the article, Bush describes a hypothetical device called a memex.
Imagine a desk filled with reams and reams of microfilm. The operator of this device can find information and also make connections between bits of information, linking them together in whatever way makes sense to them.
This sounds a lot like hypertext. That word would be coined decades later by Ted Nelson to describe “text which is not constrained to be linear.”
Vannevar Bush’s idea of the memex and Ted Nelson’s ideas about hypertext would be a big influence on Tim Berners-Lee, the creator of the World Wide Web.
But his big breakthrough wasn’t just making hypertext into a reality. Other people had already done that.
Douglas Engelbart, who wanted to make the computer equivalent of the memex, had already demonstrated a working hypertext system in 1968 in an astonishing demonstration that came to be known as The Mother Of All Demos.
The idea of hypertext was kind of like a choose-your-own-adventure book. Individual pieces of text in a book are connected with unique identifiers and you can jump from one piece of text to another within the same book.
But what if you could jump between books? That’s the other piece of the puzzle.
The idea of connecting computers together came from the concept of “time sharing” allowing you to remotely access another computer.
With funding from the US Department of Defence’s Advance Research Projects Agency, time sharing was taken to the next level with the creation of a computer network called the ARPANET.
It grew. And it grew. Until it was no longer just a network of computers. It was a network of networks. Or internetwork. Internet, for short.
Tim Berners-Lee took the infrastructure of the internet and mashed it up with the idea of hypertext. Instead of imagining hypertext as a book with interconnected concepts, he imaged a library of books where you could jump from one idea in one book to another idea in a completely different book in a completely different part of the library.
This was the World Wide Web. And Tim Berners-Lee called it the World Wide Web even when it only existed on his computer. You have to admire the chutspah of that!
But the really incredible thing is that it worked! In March of 1989 he proposed a global hypertext system, where anybody could create new pages without asking anyone for permission, and anyone could access those pages no matter what kind of device or operating system they were using.
And that’s what we have today. While the World Wide Web might seem inevitable in hindsight, it was anything but. It is a remarkable achievement.
The World Wide Web was somewhat lacking in colour originally. When I started making websites in the mid nineties, colour had arrived but it was limited.
When I started making websites in the mid nineties, colour had arrived but it was somewhat limited.
We had a palette of 216 web safe colours. You knew if a colour was “web safe” if the hexadecimal notation was three sets of duplicated values. If you altered one of those values even slightly, there was no guarantee that the colour would display consistently on the monitors of the time.
I have a confession to make: I kind of liked this constraint in a weird way. To this day, if I have a colour value that’s almost web-safe, I can’t resist nudging it slightly.
Fortunately, monitors improved. They got flatter for one thing. They were also capable of displaying plenty of colours.
And we also got more and more ways of specifying colours. As well as hexadecimal, we got RGB: Red, Green, Blue. Better yet, we got RGBa …with alpha transparency. That’s opacity to you and me.
Then we got HSL: hue, saturation, lightness. Or should I say HSLa: hue, saturation, lightness, and alpha transparency.
And there are more colour spaces on the way. HWB (hue, whiteness, blackness), LAB, LCH. And there’s work on a color() function so you can specify even more colour spaces.
In the beginning, typography on the World Wide Web was non-existent. Your browser used whatever was available on your operating system.
That situation continued for quite a while. You’d have to guess which fonts were likely to be available on Windows or Mac.
If you wanted to use a sans-serif typeface, there was Arial on Windows and Helvetica on the Mac. Verdana was a pretty safe bet too.
For a while your only safe option for a serif typeface was Times New Roman. When Mathew Carter’s Georgia was released, it was a godsend. Here was a typeface specifically designed for the screen.
Later Microsoft released another four fonts designed for the screen. Four new fonts! It felt like we were being spoiled.
But what if you wanted to use a typeface that didn’t come installed with an operating system? Well, you went into Photoshop and made an image of the text. Now the user had to download additional images. The text wasn’t selectable and it was a fixed width.
We came up with all sorts of clever techniques to do what was called “image replacement” for text. Some of the techniques involved CSS and background images. One of the techniques involved Flash. It was called sIFR: Scalable Inman Flash Replacement. A later technique called Cufón converted the letter shapes into paths in Canvas.
All of these techniques were hacks. Very clever hacks, but hacks nonetheless. They were clever and they worked but they always reminded me of Samuel Johnson’s description of a dog walking on its hind legs:
It is not done well but you are surprised to find it done at all.
What if you wanted to use an actual font file in a web page?
There was only one browser that supported font embedding: Microsoft’s Internet Explorer. The catch was that you had to use a proprietary font format called Embedded Open Type.
Both type foundries and browser makers were nervous about allowing regular font files to be embedded in web pages. They were worried about licensing. Wouldn’t this lead to even more people downloading fonts illegally? How would the licensing be enforced?
The impasse was broken with a two-pronged approach. First of all, we got a new font format called Web Open Font Format or WOFF. It could be used to take a regular font file and wrap it in a light veneer of metadata about licensing. There’s a sequel that’s even better than the original, WOFF2.
The other breakthrough was the creation of intermediary services like Typekit and Fontdeck. They would take care of serving the actual font files, making sure they couldn’t be easily downloaded. They could also keep track of numbers to ensure that type foundries were being compensated fairly.
Over time it became clear to type foundries that most web designers wanted to do the right thing when it came to licensing fonts. And so these days, you can probably license a font straight from a type foundry for use on the web and host it yourself.
You might need to buy a few different weights. Regular. Bold. Maybe italic. What about extra bold? Or a light weight? It all starts to add up, especially for the end user who has to download all those files.
I remember being at the web typography conference Ampersand years ago and hearing a talk from Nick Sherman. He asked us to imagine one single font file that could go from light to regular to bold and everything in between. What he described sounded like science fiction.
It is now science fact, indistinguishable from magic. Variable fonts are here. You can typeset text on the web to be light, or regular, or bold, or anything in between.
When you use CSS to declare the font-weight property, you can use keywords like “normal” or “bold” but you can also use corresponding numbers like 400 or 700. There’s a scale with nine options from 100 to 900. But why isn’t the scale simply one to nine?
Well, even though the idea of variable fonts would have been pure fantasy when this part of CSS was being specced, the authors had some foresight:
One of the reasons we chose to use three-digit numbers was to support intermediate values in the future.
With the creation of variable fonts, Håkon Wium Lee added:
And the future is now.
On today’s web you could have 999 font-weight options.
In the beginning, the World Wide Web was a medium for text only. There were no images and certainly no videos.
In an early mailing list discussion, there was talk of creating a new HTML element for images. Perhaps it should be called “icon”. Or maybe it should be more generic and be called “embed”. Tim Berners-Lee said he imagined using the rel attribute on the A element for embedding images.
While this discussion was happening, Marc Andreessen popped in to say that he had just shipped a new HTML element in the Mosaic browser. It’s called IMG and it takes an attribute called SRC that points to the source of the image.
This was a self-closing tag so there was no way to put fallback content in between the opening and closing tags if the image couldn’t be displayed. So the ALT attribute was introduced instead to provide an alternative description of the image.
For the images themselves, there were really only two choices. JPG for photographic images. GIF for icons or anything that needed basic transparency. GIFs could also do animation and today, that’s pretty much all they’re used for. That’s because there was a concerted campaign to ditch the GIF format on the web. Unisys, who owned the rights to a compression algorithm used by the GIF format, had started to make noises about potentially demanding license fees for its use.
The Portable Network Graphics format—or PNG—was created in response. It was more performant and it allowed you to have proper alpha transparency.
These were all bitmap formats. What if you wanted a vector format for images that would retain crispness at any size or resolution? There was only one option: Flash. You’d have to embed a Flash movie in your web page just to get the benefit of vector graphics.
By the 21st century there were some eggheads working on a text-based vector file format that could be embedded in webpages, but it sounded like a pipe dream. It was called SVG for Scalable Vector Graphics. The format was dreamed up in 2001 but for years, not a single browser supported it. It was like some theoretical graphical Shangri-La.
But by 2011, every major browser supported it. Styleable, scriptable, animatable, vector graphics have gone from fantasy to reality.
There’s more choice in the world of bitmap images too. WebP is well supported. AVIF is is gaining support.
These elements have been designed with more thought than the IMG element. They are not self-closing elements, by design. You can put fallback content between the opening and closing tags.
The audio and video elements arrived long after the IMG element. For a long time, there was no easy way to do video or audio on the web.
That was very frustrating for me. The first websites I ever built were for bands. The only way to stream music was with a proprietary plug-in like Real Audio.
While the web standards were still being worked on, Flash delivered the goods with streaming audio and video. This happened over and over. Flash gave us vector graphics, animation, video, and more. But the price was lock-in. Flash was a proprietary format.
Still, Flash showed the web standards bodies the direction of travel. Flash was the hare. Web standards were the tortoise.
We know how that race ended.
In a way, Flash was like the Research and Development incubator for the World Wide Web. We got CSS animations, SVG, and streaming video because Flash showed that there was an appetite for them.
Until web standards provide a way to do something, designers and developers will reach for whatever tool gets the job done. Take layout, for example.
In the early days of the web, you could have any layout you wanted …as long as it was a single column.
Before long, HTML expanded to provide some rudimentary formatting for that single column of text. Presentational elements and attributes were invented. And even when elements and attributes weren’t meant to be used for formatting, people got creative.
Tables for layout. A single pixel GIF that could be given width and height. These were clever solutions. But they were hacks. And they were in danger of turning HTML into a presentational language instead of a language for structuring content.
CSS came to the rescue. A language specifically for presentation.
But we still didn’t get proper layout tools. There was a lot of debate in the early days about whether CSS should even attempt to provide layout tools or whether that was a job for a separate technology.
We could lay things out using the float property, but really that was just another hack.
Floats were an improvement over tables for layout, but we only swapped one tool for another. Our collective thinking still wasn’t very web-like.
For example, designers and developers insisted on building websites with a fixed width. This started in the era of table layouts and carried over into CSS.
To start with, the fixed width was 640 pixels. Then it was 800 pixels. Then people settled on the magical number of 960 pixels. Designers and developers didn’t seem at all concerned that people had different sized screens.
That was until the iPhone came out. It caused a panic. What fixed width were we supposed to design for now?
The answer was there all along. Even before the web appeared in mobile devices, it was possible to build fluid layouts that would adapt to screen size. It’s just that the majority of designers and developers chose not to build in this way.
I was pleased that mobile came along and shook things up. It exposed the assumptions that people were making. And it forced designers and developers to think in a more fluid, webby way.
Even better, CSS had expanded to include media queries so it was possible to alter layouts at different breakpoints.
Ethan came along and put a nice bow on it with his definition of responsive design: fluid media, fluid layouts, and media queries.
I fell in love with responsive web design instantly becuase it matched how I was already thinking about the web. I was one of the handful of weirdos who insisted on building fluid websites when everyone else was using fixed-width layouts.
But I thought that responsive web design would struggle to take hold.
I’m delighted to say that I was wrong. Responsive web design has become the default!
If I could go back to my past self in the mid 2000s, I’d love to tell them that in the future, everyone would be building with fluid layouts (and also that time travel had been invented apparently).
Not only that, but we finally have proper layout tools for the web. Flexbox. Grid. No more hacks. We’re even getting container queries soon (thanks, Miriam!).
Web browsers now are positively overflowing with fantastic design tools that would have been unimaginable to my past self. Support for these technologies is pretty much universal.
When browsers differ today, it’s only terms of which standards they don’t yet support. There was a time when browsers differed massively in how they handled basic web technologies.
There was a time when being a web developer meant understanding all the different quirks between browsers.
And browser makers spent a ludicrous amount of time reverse-engineering the quirky behaviour of whichever browser was the market leader.
That changed with HTML5. We remember HTML5 for introducing new APIs, new form fields, and new structural elements. But the biggest innovation was completely invisible. For the first time, error-handling was standardised. Browsers had a set of rules they could work from. Once browsers adopted this consistent approach to error-handling, cross-browser differences dried up.
In the beginning, there was no scripting on the web, just like there was no styling. Tim Berners-Lee wasn’t opposed to the idea of executing arbitrary code on the web. But he pointed out that you’d need everyone to agree on which programming language browsers would use.
You need something really powerful, but at the same time ubiquitous. Remember a facet of the web is universal readership. There is no universal interpreted programming language.
The important thing is that multiple browsers implemented it. Then the hype started. We were told about this great new technology called DHTML. The D stood for dynamic! This would allow us to programmatically manipulate elements in a web page.
But… the two major browsers at the time, Netscape Navigator and Internet Explorer, used two completely incompatible syntaxes. For Netscape Navigator you’d use document.layers. For Internet Explorer it was document.all.
This was when developers said enough was enough. We wanted standards. The Web Standards Project was formed and we lobbied browser makers to implement web standards, like CSS and also the Document Object Model. This was a standardised way of manipulating elements in a web page. You could use methods like getElementById and getElementsByTagName.
That worked fine, but it was yet another vocabulary to learn. If you already knew CSS, then you already understood how to get an element by ID and get elements by tag name, but with a different syntax.
Now we no longer need jQuery. We’ve got querySelector and querySelectorAll. But the reason we no longer need jQuery is because of jQuery. Just like Flash, jQuery showed what developers wanted. And just as with Flash, the web standards took more time. But now jQuery is obsolete …precisely because it was so successful.
It’s a similar story with Sass and CSS. There was a time when Sass was the only way to have a feature like variables. But now with custom properties available in CSS, Sass is becoming increasingly obsolete …precisely because it was so successful and showed the direction of travel.
But some capabilities can’t be polyfilled. If a browser doesn’t provide API access to a particular sensor, for example, there’s no way to spackle that gap.
For quite a while, if you wanted access to device APIs, you’d have to build a native app. But over time, that has changed. Now browsers are capable of providing app-like experiences. You can get location data. You can access the camera. You can provide notifications. You can even make websites work offline using service workers.
Native apps had all these capabilities before web browsers. Just as with Flash and jQuery, native apps pointed the way. The gap always looks insurmountable to begin with. But over time, the web always manages to catch up.
At the beginning of 2021, Ire said:
By the end of the year, I would predict that any major native mobile application could be instead built using native web capabilities.
The web has come along way. It has grown and evolved. Browsers have become more and more powerful while maintaining backward compatibility.
In the past we had to hack our way around the technological limitations of the web and we had a long wish list of features we wanted.
I’m not saying we’re done. I’m sure that more features will keep coming. But our wish list has shrunk.
The biggest challenges facing the World Wide Web today are not technical challenges.
Today it is possible to create beautiful websites that make full use of colour, typography, layout, animation, and more. But this isn’t what users experience.
This is what users experience. A tedious frustrating game of whack-a-mole with websites that claim to value our privacy while asking us to relinquish it.
This is not a technical problem. It is a design decision. The decision might not be made by anyone with designer in their job title, but make no mistake, business decisions have a direct effect on user experience.
On the face of it, the problem seems to be with the business model of advertising. But that’s not quite right. To be more precise, the problem is with the business model of behavioural advertising. That relies on intermediaries to amass huge amounts of personal data so that they can supposedly serve up relevant advertising.
But contextual advertising, which serves up ads based on the content you’re looking at doesn’t require the invasive collection of personal data. And it works. Behavioural advertising, despite being a huge industry that depends on people giving up their privacy, doesn’t even work very well. And on the few occasions when it does work, it just feels creepy.
The problem is not advertising. The problem is tracking. The greatest trick the middlemen ever pulled was convincing us that you can’t have effective advertising without tracking. That is false. But they’ve managed to skew our sense of perspective so that invasive advertising seems inevitable.
Advertising was always possible on the web. You could publish anything and an ad is just one more thing you could choose to publish. But tracking was impossible. That’s because the early web was stateless. A browser requests a resource from a server and once that transaction is done, they both promptly forget about it. That made it very hard to do things like online shopping or logging into an account.
Perhaps none of this applies to you anyway. You may be thinking that this is a problem for websites. But you build web apps.
But the phrase “single page app” has a more definite meaning. It refers to an architectural decision. That decision is to reinvent the web browser inside a web browser.
I think there’s a certain mindset being applied to web development here. And that mindset comes from the world of software. Again, it’s a testament to how far the web has come that it can be treated as a software platform on par with operating systems like iOS, Android, or Windows. There’s a lot to be learned from the world of software development, like testing, for example. But the web is different. When a user navigates to a URL, it shouldn’t feel like they’re installing a piece of software.
We should be aiming to keep our payloads as small as possible. And given how powerful browsers have become, we need fewer and fewer dependencies—fewer and fewer polyfills.
When asked to justify the enormous payloads, web developers have responded by saying that user’s expectations have changed. That is correct, but not in the way that I think they mean.
When I talk to people about using the web—especially on mobile—their expectations are that they will have a terrible experience. That websites will be slow to load. And I guarantee you that none of them are saying, “Well I’d be annoyed if this were a website but seeing as this is a web app, I’m absolutely fine with this terrible experience.”
I said that the biggest challenges facing the World Wide Web today are not technical challenges. I think the biggest challenge facing the web today is people’s expectations.
There is no technical reason for websites or web apps to be so frustrating. But we have collectively led people to expect a bad experience on the web.
There’s a great German word, “Verschlimmbessern”: the act of making something worse in the attempt to make it better. Perhaps we verschlimmbessert the web.
Stop solving problems you don’t yet have.
Lean into what web browsers can accomplish today. If you find something missing, that’s the time to reach for a library …but treat it like a polyfill. Whereas web standards stick around, every library and framework comes with a limited lifespan. Treat them as cattle, not pets.
I understand that tools and frameworks can make your life easier. And if we’re talking about server-side frameworks, then I say “Go for it.” Or if you’re using build tools that sit on your computer to do version control, linting, pre-processing, or transpiling, then I say “Go for it.”
But once you make users download tools or frameworks, you’re making them pay a tax for your developer convenience.
We need to value user needs above developer convenience. If I have the choice of making something the user’s problem or making it my problem, I’ll make it my problem every time. That’s my job.
We need to change people’s expectations of the World Wide Web, especially on mobile. Otherwise, the web will be lost.
Two years ago, I had the great honour of being invited to CERN to mark the 30th anniversary of the original proposal for the World Wide Web. One of the other people there was the journalist Zeynep Tüfekçi. She was on a panel along with Tim Berners-Lee and other luminaries of the early web. At the end of the panel discussion, she was asked:
What would you tell the next generation about how to use this wonderful tool?
If you have something wonderful, if you do not defend it, you will lose it. If you do not defend the magic and the things that make it wonderful, it’s just not going to stay magical by itself.
I believe that we can save the web. I believe that we can change people’s expectations. We’ll do that by showing them what the web is capable of.
It sounds like a moonshot. But, y’know, moonshots aren’t made possible by astronauts. They’re made possible by people like Poppy Northcutt in mission control. Katherine Johnson running the numbers. And Margaret Hamilton inventing the field of software engineering to create the software for the lunar lander. Individual people working together on something bigger than any one person.
There’s a story told about the first time President Kennedy visited NASA. While he was a getting a tour of the place, he introduced himself to a janitor. And the president asked the janitor what he did. The janitor answered:
I’m helping put a man on the moon.
It’s the kind of story that’s trotted out by company bosses to make you feel good about having your labour exploited for the team. But that janitor’s loyalty wasn’t to NASA, an organisation. He was working for something bigger.
I encourage you to have that sense of perspective. Whatever company or organisation you happen to be working for right now, remember that you are building something bigger.
The future of the World Wide Web is in good hands. It’s in your hands.
Wednesday, October 27th, 2021
I just filled out this form on the BBC website. Here’s what I wrote, based on this open letter to the BCC Upper Management and Editorial Staff.
What is your complaint about?
BBC website or apps
Which website or app is your complaint about?
BBC News website
Please give the URL, or name of the app
Are you contacting us about a previous complaint?
Select the best category to describe your complaint
Standards of interviewing/presenting
What is the subject of your complaint?
Innacurate reporting and unreliable source
Please enter your complaint
The article is based on a single self selected study of 80 individuals sourced from Get The L Out, a group who, prior to the survey, were already united by anti-trans views.
This study breaks the BBC’s own guidelines about using surveys as sources for claims in coverage, as it is self-selected, with a small sample size and a clear bias held by those self-selected to respond.
The article dangerously frames this as a widespread issue, whilst simultaneously acknowledging that there is no actual evidence to that effect outside of isolated claims and cherry picked individual cases.
The article routinely implies that transgender women are not women, uncritically quoting people who call transgender women men without at any point clarifying that this is ignoring their legal status as women in the UK.
Thursday, October 7th, 2021
This is a terrific and nuanced talk that packs a lot into less than twenty minutes.
(The secret sauce in transitional web apps is progressive enhancement.)
Thursday, August 19th, 2021
The transcript from the latest episode of the HTTP 203 podcast is well worth perusing.
- Internet Explorer halted development, no innovation. Would you say Safari is the new IE?
- There was loads of stuff missing. Is Safari the new IE?
- My early career was built on knowing the bugs in IE6 and how to solve them. Is Safari the new IE?
- Internet Explorer had a fairly cavalier attitude towards web standards. Is Safari the new IE?
- Back in the day that we had almost no communication whatsoever. Is Safari the new IE?
- Slow-release cycle. Is Safari the new IE?
Tuesday, August 17th, 2021
I’m very excited about this proposal for animating transitions between web pages!
I’m less excited about doing it for single page apps, but I get why it’s the simplest place to start.
I was moaning about Safari recently. Specifically I was moaning about the ridiculous way that browser updates are tied to operating system updates.
But I felt bad bashing Safari. It felt like a pile-on. That’s because a lot of people have been venting their frustrations with Safari recently:
- Jorge Arango wrote Back to the Bad Old Days of the Web,
- Dave Rupert wrote One-offs and low-expectations with Safari,
- Perry Sun wrote For developers, Apple’s Safari is crap and outdated, and
- Tim Perry wrote Safari isn’t protecting the web, it’s killing it.
I think it’s good that people share their frustrations with browsers openly, although I agree with Baldur Bjarnason that’s good to avoid Kremlinology and the motivational fallacy when blogging about Apple.
It’s also not helpful to make claims like “Safari is the new Internet Explorer!” Unless, that is, you can back up the claim.
On a recent episode of the HTTP 203 podcast, Jake and Surma set out to test the claim that Safari is the new IE. They did it by examining Safari according to a number of different measurements and comparing it to the olden days of Internet Explorer. The result is a really fascinating trip down memory lane along with a very nuanced and even-handed critique of Safari.
And the verdict? Well, you’ll just to have to listen to the podcast episode.
If you’d rather read the transcript, tough luck. That’s a real shame because, like I said, it’s an excellent and measured assessment. I’d love to add it to the links section of my site, but I can’t do that in good conscience while it’s inaccessible to the Deaf community.
When I started the Clearleft podcast, it was a no-brainer to have transcripts of every episode. Not only does it make the content more widely available, but it also makes it easier for people to copy and paste choice quotes.
Still, I get it. A small plucky little operation like Google isn’t going to have the deep pockets of a massive corporation like Clearleft. But if Jake and Surma were to open up a tip jar, I’d throw some money in to get HTTP 203 transcribed (I recommend getting Tina Pham to do it—she’s great!).
I apologise for my note of sarcasm there. But I share because I care. It really is an excellent discussion; one that everyone should be able to access.
Some folks called us out for lacking transcripts for our podcasts. Fair point! So, here we go (and all future episodes will have transcripts)https://t.co/HmfwBvAicA— Jake Archibald (@jaffathecake) August 18, 2021
Tuesday, July 20th, 2021
An excellent thoughtful piece from Angela Saini (as always):
Popular opinion, “common sense” and the closely related priors of scientific enquiry have never been reliable guides when it comes to decoding human difference. After all, European biologists once thought it was obvious that colour-coded races were different species or breeds that had evolved separately on each continent. It was obvious to taxonomist Carl Linnaeus that monster-like and feral races of humans surely existed somewhere in the world. More recently, neuroscientists were happily insisting that women were innately less intelligent than men because they had smaller brains. A few neuroscientists still do.
History shows that many supposed “facts” about human nature were actually always cultural constructions. Race is one. Gender is another. Now, some researchers believe that sex—generally seen as determined by anatomy, including chromosomes, hormones and genitalia—may to some extent be constructed, too. Binary categories of male and female, they say, certainly don’t fully encompass all the natural variation and complexity that we see in our species.
Saturday, July 3rd, 2021
A terrific piece by Jonathan Zittrain on bitrot and online digital preservation:
Too much has been lost already. The glue that holds humanity’s knowledge together is coming undone.
Sunday, June 27th, 2021
An email to The Guardian
My name is Jeremy and I’ve been a paid subscriber to The Guardian for a few years now. But I’m considering cancelling my account after reading this editorial.
On the face of it, the headline of the article sound reasonable and hard to disagree with. But the substance of the article downplays anti-trans views as simply being “gender critical.” This is akin to describing segregationist views as “integration critical.”
This line is particularly egregious:
As a society, we need to resolve the question of how to protect the privacy, dignity and rights of trans women while also respecting the privacy, dignity and rights of those born female.
Setting up these positions as though one in any way invalidates the other gives oxygen to those who wish to paint someone’s identity as a threat. I’m very disappointed to see this viewpoint expressed in an editorial on The Guardian website.
Monday, June 7th, 2021
Bringing Dark Patterns to Light. Transcript of the speech I gave at the… | by Harry Brignull | Jun, 2021 | Medium
Harry gave a speech at the Federal Trade Commission’s Dark Patterns workshop in April. Here’s the transcript, posted to Ev’s blog.
When I first worked on Dark Patterns in 2010, I was quite naive. I thought that they could be eradicated by shaming the companies that used them, and by encouraging designers to use a code of ethics.
The fact that we’re here today means that approach didn’t work.
Saturday, April 24th, 2021
It would be nice to be able to animate the transition between pages if we want to on the web without resorting to hacks or full-blown architecture choices to achieve it.
Amen, Chris, amen!
The danger here is that you might pick a single-page app just for this ability, which is what I mean by having to buy into a site architecture just to achieve this.
Monday, March 29th, 2021
Ainissa Ramirez recounts the story of the transatlantic telegraph cable, the Apollo project of its day.
Friday, February 26th, 2021
This is a really nice introduction to CSS transitions with interactive demos you can tinker with.
Monday, February 1st, 2021
Monday, January 4th, 2021
I’d like to take you back in time, just over 100 years ago, at the beginning of World War One. It’s 1914. The United States would take another few years to join, but the European powers were already at war in the trenches, as you can see here.
What I want to draw your attention to is what they’re wearing, specifically what they’re wearing on their heads. This is the standard issue for soldiers at the beginning of World War One, a very fetching cloth cap. It looks great. Not very effective at stopping shrapnel from ripping through flesh and bone.
It wasn’t long before these cloth caps were replaced with metal helmets; much sturdier, much more efficient at protection. This is the image we really associate with World War One; soldiers wearing metal helmets fighting in the trenches.
Now, an interesting thing happened after the introduction of these metal helmets. If you were to look at the records from the field hospitals, you would see that there was an increase in the number of patients being admitted with severe head injuries after the introduction of these metal helmets. That seems odd and the only conclusion that we could draw seems to be that cloth helmets are actually better than the metal helmets at stopping these kind of injuries. But that wouldn’t be correct.
You can see the same kind of data today. Any state where they introduce motorcycle helmet laws saying it’s mandatory to wear motorcycle helmets, you will see an increase in the number of emergency room admissions for severe head injuries for motorcyclists.
Now, in both cases, what’s missing is the complete data set because, yes, while in World War One there was an increase in the field hospital admissions for head injuries, there was a decrease in deaths. Just as today, if there’s an increase in emergency room admissions for severe head injuries because of motorcycle helmets, you will see a decrease in the number of people going to the morgue.
I kind of like these stories of analytics where there’s a little twist in the tale where the obvious solution turns out not to be the correct answer and our expectations are somewhat subverted. My favorite example of analytics on the web comes from a little company called YouTube. This is from a few years back.
Chris set about working on making a smaller version of a video page. He called this Project Feather. He worked and worked at it, and he managed to get a page down to just 98 kilobytes, so from 1.2 megabytes to 98 kilobytes. That’s an order of magnitude difference.
Then he set up shipping this to different segments of the audience and watching the analytics to see what rolled in. He was hoping to see a huge increase in the number of people engaging with the content. But here’s what he blogged.
The average aggregate page latency under Feather had actually increased. I had decreased the total page weight and number of requests to a tenth of what they were previously and somehow the numbers were showing that it was taking longer for videos to load on Feather, and this could not be possible. Digging through the numbers more (and after browser testing repeatedly), nothing made sense.
I was just about to give up on the project with my world view completely shattered when my colleague discovered the answer: geography. When we plotted the data geographically and compared it to our total numbers (broken out by region), there was a disproportionate increase in traffic from places like Southeast Asia, South America, Africa, and even remote regions of Siberia.
A further investigation revealed that, in those places, the average page load time under Feather was over two minutes. That means that a regular video page (at over a megabyte) was taking over 20 minutes to load.
Again, what was happening here was that there was a whole new set of data. There were people who literally couldn’t even load the page because it would take 20 minutes who couldn’t access YouTube who now, because of this Project Feather, for the first time were able to access YouTube. What that looked like, according to the analytics, was that page load time had overall gone up. What was missing was the full data set.
I really like these stories that kind of play with our expectations. When the reveal comes, it’s almost like hearing the punchline to a joke, right? Your expectations are set up and then subverted.
Jeff Greenspan is a comedian who talks about this. He talks about expectations in terms of music and comedy. He points out that they both deal with expectations over time.
In music, the pleasure comes from your expectations being met. A song sets up a rhythm. When that rhythm is met, that’s pleasurable. A song is using a particular scale and when those notes on that scale are hit, it’s pleasurable. Music that’s not fun to listen to tends to be arhythmic and atonal where you can’t really get a handle on what’s going to come next.
Comedy works the other way where it sets up expectations and then pulls the rug out from under you — the surprise.
Now, you can use music and you can use comedy in your designs. If you were setting up a lovely grid and a vertical rhythm, that’s like music. It’s a lovely, predictable feeling to that. But you can also introduce a bit of comedy; something that peeks out from the grid. You upset (just occasionally) something with a bit of subverted expectations.
You don’t want something that’s all music. Maybe that’s a little boring. You don’t want something that’s all comedy because then it’s just crazy and hard to get a handle on.
You can see music and comedy in how you consume news. You notice that when you read your news sources, all it does is confirm what you already believe. You read something about someone, and you think, “Yes, they’ve done something bad and I always thought they were bad, so that has confirmed my expectations.” It’s like music.
I read something that somebody has done and I always thought they were a good person. This now confirms that they are a good person. That is music to my ears. If your news feels like that, feels like music, then you may be in a bubble.
The comedy approach to music would be more like the clickbait you see at the bottom of the Internet where it’s like, “Click here. You won’t believe what these child stars look like now.” The promise there is that we will subvert your expectations, and that’s where the pleasure will come.
My favorite story from history about analytics is not from World War One but from the sequel, World War Two, where again the United States were a few years late to this world war. But when they did arrive and started their bombing raids on Germany, they were coming from England. The bombers would come back all shot up, and so there was a whole thinktank dedicated to figuring out how we can reinforce these planes in certain areas.
You can’t reinforce the whole plane. That would make it too heavy, but you could apply some judicious use of metal reinforcement to protect the plane.
They treated this as a data problem, as an analytics problem. They looked at the planes coming back. They plotted where the bullet holes were, and that led them to conclude where they should put the reinforcements. You can see here that the wings were getting all shot up, the middle of the fuselage, so clearly that’s where the reinforcements should go.
There was a statistician, a mathematician named Abraham Wald. He looked at the exact same data and he said, “No, we need to reinforce the front of the plane where there are no bullet holes. We need to reinforce the back of the fuselage where there are no bullet holes.”
What he realized was that all the data they were seeing was actually a subset of the complete data set. They were only seeing the planes that made it back. What was missing were all the planes that got shot down. If all the planes that made it back didn’t have any bullet holes in the front of the plane, then you could probably conclude that if you get a bullet hole in the front of the plane, you’re not going to make it back. This became the canonical example of what we now call survivorship bias, which is this tendency to look at the subset of data — the winners.
You see survivorship bias all the time. You walk into a bookstore and you look at the business section and its books by successful business people; that’s survivorship bias. Really, the whole section should be ten times as big and feature ten times as many books written by people who had unsuccessful businesses because that would be a much more representative sample.
We see survivorship bias. You go onto Instagram and you look at people’s Instagram photos. Generally, they’re posting their best life, right? It’s the perfect selfie. It’s the perfect shot. It’s not a representative sample of what somebody’s life looks like. That’s survivorship bias.
We have a tendency to do it on the web, too, when people publish their design systems. Don’t get me wrong. I love the fact that companies are making their design systems public. It’s something I’ve really lobbied for. I’ve encouraged people to do this. Please, if you have a design system, make it public so we can all learn from it.
I really appreciate that people do that, but they do tend to wait until it’s perfect. They tend to wait until they’ve got the success.
What we’re missing are all the stories of what didn’t work. We’re missing the bigger picture of the things they tried that just failed completely. I feel like we could learn so much from that. I feel like we can learn as much from anti-patterns as we can from patterns, if not more so.
Robin Rendle talked about this in a blog post recently about design systems. He said:
The ugly truth is that design systems work is not easy. What works for one company does not work for another. In most cases, copying the big tech company of the week will not make a design system better at all. Instead, we have to acknowledge how difficult our work is collectively. Then we have to do something that seems impossible today—we must publicly admit to our mistakes. To learn from our community, we must be honest with one another and talk bluntly about how we’ve screwed things up.
I completely agree. I think that would be wonderful if we shared more openly. I do try to encourage people to share their stories, successes, and failures.
I organized a conference a few years back all about design systems called Patterns Day and invited the best and brightest: Alla Kholmatova, Jina Anne, Paul Lloyd, Alice Bartlett – all these wonderful people. It was wonderful to hear people come up and sort of reassure you, “Hey, none of us have got this figured out. We’re all trying to figure out what we’re doing here.” The audience really needed to hear that. They really needed to hear that reassurance that this is hard.
Gaps and overlaps
I did Patterns Day again last year. My favorite talk at Patterns Day last year, I think, was probably from Danielle Huntrods. I’m biased here because I used to work with Danielle. She used to work at Clearleft, and she’s an absolutely brilliant front-end developer.
She had this lens that she used when she was talking about design systems and other things. She talked about gaps and overlaps, which is one of those things that’s lodged in my brain. I kind of see it everywhere.
She said that when you’re categorizing things, you’re putting things into categories, that means some things will fall between those categories. That leaves you with the gaps, the things that aren’t being covered. It’s almost like Donald Rumsfeld, the unknown unknowns and all that.
What can also happen when you put things into categories is you get these overlaps where there’s duplication; two things are responsible for the same task. This duplication of effort, of course, is what we’re trying to avoid with design systems. We’re trying to be efficient. We don’t want multiple versions of the same thing. We want to be able to reuse one component. There’s a danger there.
She’s saying what we do with the design system is we concentrate on cataloging these components. We do our interface inventory, but we miss the connective part. We miss the gaps between the components. Really, what makes something a system is not so much a collection of components but how those components fit together, those gaps between them.
Danielle went further. She didn’t just talk about gaps and overlaps in terms of design systems and components. She talked about it in terms of roles and responsibilities. If you have two people who believe they’re responsible for the same thing, that’s going to lead to a clash.
Worse, you’re working on a project and you find out that there was nobody responsible for doing something. It’s a gap. Everyone assumes that the other person was responsible for getting that thing done.
“Oh, you’re not doing that?” “I thought you were doing that.” “Oh, I thought you were doing that.”
This is the source of so much frustration in projects, either these gaps or these overlaps in roles and responsibilities. Whenever we start a project at Clearleft, we spend quite a bit of time getting this role mapping correct, trying to make sure there aren’t any gaps and there aren’t any overlaps. Really, it’s about surfacing those assumptions.
“Oh, I assumed I was responsible for that.” “No, no. I assumed I was the one who would be doing that.”
We clarify this stuff as early as possible in the design process. We even have a game we play called Fluffy Edges. It’s literally like a card game. We’d ask these questions, “Who is responsible for this? Who is going to do this?” It’s kind of good fun, but really it is about surfacing those assumptions and getting clarity on the roles at the beginning of the design process.
The design process
Now, the design process, I’m talking about the design process like it’s this known thing and it really isn’t. It’s a notoriously difficult thing to talk about the design process.
Here’s one way of thinking about the design process. This is The Design Squiggle by Damien Newman. He used to be at IDEO. I actually think this is a pretty accurate representation of what the design process feels like for an individual designer. You go into the beginning and it’s chaos, it’s a mess, and it’s entropy. Then, over time, you begin to get a handle on things until you get to this almost inevitable result at the end.
I’m not sure it’s an accurate representation of what the collaborative design process feels like. There’s a different diagram that resonates a lot with us at Clearleft, which is the Double Diamond diagram from Chris Vanstone at the Design Council. The way of thinking about the Double Diamond is almost like it’s two design squiggles back-to-back.
It’s a bit of an oversimplification, but the idea is that the design process is split into these triangles. First, it’s the discovery. Then we define. So we’re going out wide with discovery. Then we narrow it down with the definition. Then it’s time to build a thing and we open up wide again to figure out how we’re going to execute this thing. Once we got that figured out, we narrow down into the delivery phase.
The way of thinking about this is the first diamond (discovery and definition), that’s about building the right thing. Make sure you’re building the right thing first. The second diamond (about execution and delivery), that’s about building the thing right. Building the right thing and building the thing right.
The important thing is they follow this pattern of going wide and going narrow. This divergent phase with discovery and then convergent for definition. There’s a divergent phase for execution and then convergent for delivery.
If you take nothing else in the Double Diamond approach, it’s this way of making explicit when you’re in a divergent or convergent phase. Again, it’s kind of about servicing that assumption. “Oh, I assumed we were converging.” “No, no, no. We are diverging here.” That’s super, super useful.
I’ll give you an example. If you are in a meeting, at the beginning of the meeting, state whether it’s a divergent meeting or a convergent meeting. If you were in a meeting where the idea is to generate as many ideas as possible during a meeting, make that clear at the beginning because what you don’t want is somebody in the meeting who thinks the point is to converge on a solution.
You’ve got these people generating ideas and then there’s one person going, “No, that will never work. Here’s why. Oh, that’s technically impossible. Here’s why.” No, if you make it clear at the start, “There are no bad ideas. We’re in a divergent meeting,” everyone is on the same page.
Conversely, if it’s a convergent meeting, you need to make that clear and say, “The point of this meeting is that we come to a decision, one decision,” and you need to make that clear because what you don’t want in a convergent meeting is it’s ten minutes to launch time, converging on something, and then somebody in the meeting goes, “Hey, I just had an idea. How about if we…?” You don’t want that. You don’t want that.
If you take nothing else from this, this idea of making divergence and convergence explicit is really, really, really useful. Again, like I say, this pattern of just assumptions being surfaced is so useful.
This initial diamond of the Double Diamond phase, it’s where we spend a lot of our time at Clearleft. I think, early in the years of Clearleft, we spent more time on the second diamond. We were more about execution and delivery. Now, I feel like we deliver a lot more value in the discovery and definition phase of the design process.
There’s so much we do in this initial discovery phase. I mentioned already we have this fluffy edges game we play for role mapping to figure out the roles and responsibilities. We have things like a project canvas we use to collaborate with the clients to figure out the shape of what’s to come.
We sometimes run an exercise called a pre-mortem. I don’t know if you’ve ever done that. It’s like a post-mortem except you do it at the beginning of the project. It’s kind of a scenario planning.
You say, “Okay, it’s so many months after the launch and it’s been a complete disaster. What went wrong?” You map that out. You talk about it. Then once you’ve got that mapped out, you can then take steps to avoid that disaster happening.
Of course, what we do in the discovery phase, almost more than anything else, is research. You can’t go any further without doing the research.
All of these things, all of these exercises, these ways of working are about dealing with assumptions, either surfacing assumptions that we didn’t know were there or turning assumptions into hypotheses that can be tested. If you think about what an assumption is, it kind of goes back to expectations that I was talking about.
Assumptions are expectations plus internal biases. That gives you an assumption. The things that you don’t even realize you believe; they lead to assumptions. This can obviously be very bad. This is like you’ve got blind spots in your assumptions because of your own biases that you didn’t even realize you had.
They’re not necessarily bad things. Assumptions aren’t necessarily bad. If you think about your expectations plus your biases, that’s another way of thinking about your values. What do you hold to be really dear to you? The things that are self-evident to you, those are your values, your internal expectations and biases.
Now, at Clearleft, we have our company values, our core values, the things we believe. I am not going to share the Clearleft values with you. There are two reasons for that.
One is that they’re Clearleft’s values. They are useful for us. That’s for us to know internally.
Secondly, there’s nothing more boring than a company sharing their values with you. I say nothing more boring. Maybe the only thing more boring than a company sharing their values is when a so-called friend tells you about a dream they had and you have to sit there and smile and nod politely while they tell you about something that is only of interest to them.
These values are essentially what give you purpose, whether it’s at an individual level, your personal moral values give you your purpose, or at a company or organization level, you get your purpose – or any endeavor. You think about the founding of a nation-state like the United States of America. You got the Declaration of Independence. That encodes the values. That has the purpose. It’s literally saying, “We hold these truths to be self-evident.” These are assumptions here. That’s your purpose is something like the Declaration of Independence.
Then you get the principles, how you’re going to act. The Constitution would be an example of a collection of principles. These principles must be influenced by the purpose. Your values must influence the principles you’re going to use to act in the world.
Then those principles have an effect on the final patterns, the outputs that you’ll see. In the case of a nation-state like America, I would say the patterns are the laws that you end up with. Those laws come from the principles encoded in the Constitution. The Constitution, those principles in the Constitution are influenced and encoded from the purpose in the Declaration of Independence.
The purpose influences the principles. The principles influence the pattern. This would be true in the case of software as well. You think about the patterns are the final interface elements, the user interface. Those are the patterns. Those have been influenced by the principles of that company, how they choose to act, and those principles are influenced by the purpose of that company and what they believe.
This is why I find principles, in particular, to be fascinating because they sit in the middle. They are influenced by the purpose and they, in turn, influence the patterns. I’m talking about design principles, something I’m really into. I’m so into design principles, I actually have a website dedicated to design principles at principles.adactio.com.
Now, all I do on this website is collect design principles. I don’t pass judgment. I don’t say whether I think they’re good design principles or bad design principles. I just document them. That’s turned out to be a good thing to do over time because sometimes design principles disappear, go away, or get changed. I’ve got a record of design principles from the past.
For example, Google used to have a set of principles called Ten Things We Know to Be True — we know to be true, right? We hold these truths to be self-evident. That’s no longer available on the Google website, those ten things, those ten principles. One of them was, “You can make money without doing evil.” Like I said, that’s gone now. That’s not available on the Google website.
There was another set of design principles from Google that’s also not available anymore. That was called Ten Principles That Contribute to a Googley User Experience. I think we understand why those are no longer available. The sheer embarrassment of saying the word Googley out loud, I think.
I’ll tell you something I notice when I see design principles. Like I say, I catalog them without judgment, but I do have ideas. I think about what makes for good or bad design principles or sets of design principles.
Whenever I see somebody with a list that’s exactly ten principles, I’m suspicious. Like, “Really? That’s such a convenient round number. You didn’t have nine principles that contribute to a Googley user experience? You didn’t have 11 things that we know to be true? It happened to be exactly ten?” It feels almost like a bad code smell to me that it’s exactly ten principles.
Even some great design principles like Dieter Rams, the brilliant designer. He has a fantastic set of design principles called Ten Principles for Good Design. But even there I have to think, “Hmm. That’s a bit convenient, isn’t it, that it’s exactly ten principles for good design? Isn’t it, Dieter?”
Now, just in case you think I’m being blasphemous by sugging that Dieter Rams’ Ten Principles for Good Design is not a good set of design principles, I am not being blasphemous. I would be blasphemous if I pointed out that in the Old Testament, God supposedly delivers 10 commandments, not 9, not 11, exactly 10 commandments. Really, Moses, ten?
Anyway, what I’m talking about here is, like I say, almost like these code smells for design principles. Can we evaluate design principles? Are there heuristics for saying whether a design principle is a good design principle or a bad design principle?
To get meta about this, what I’m talking about is, are there design principles for design principles? I kind of think there are. I think you can evaluate design principles and say that’s a good one or that’s a bad one. You can evaluate them by how useful they are.
Let’s take an example. Let’s say you’ve got a design principle like this:
Make it usable.
That’s a design principle. I think this is a bad design principle. It’s not because I don’t agree with it. It’s actually a bad design principle because I agree with it and everyone agrees with it. It’s so agreeable that it’s hard to argue with and that’s not what a design principle is for.
Design principles aren’t these things to go, “Rah-rah! Yes! I feel good about this.” They are there to kind of surface stuff and have discussions, have disagreements – get it out in the open. Let’s say we took this design principle, “make it usable”, and it was rephrased to something more contentious. Let’s say somebody had the design principle like:
Usability is more important than profitability.
Ooh! Now we’re talking.
See, I think this is a good design principle. I’m not saying I agree with it. I’m saying it’s a good design principle because what it has now is priority.
We’re saying something is valued more than something else and that’s what you want from design principles is to figure out what the priorities of this organization are. What do they value? How are they going to behave?
I think this is a great phrasing for design principles. If you can phrase a design principle like this:
___, even over ___
Then that’s really going to make it clear what your values are. You can phrase a design principle as:
Usability, even over profitability.
Now you can have that discussion early on about whether everyone is on board with that. If there’s disagreement, you need to hammer that out and figure it out early on in the process.
Here’s another thing about this phrasing that I really like, “blank, even over blank.” It passes another test of a good design principle, which is reversibility. Rather than being a universal thing, a design principle should be reversible for a different organization.
One organization might have a design principle that says “usability, even over profitability,” and another organization, you can equally imagine having a design principle that says, “profitability, even over usability.” The fact that this principle is reversible like that is a good thing. That shows that it’s an effective design principle because it’s about priorities.
In case of conflict, consider users over authors over implementors over theoretical purity.
That’s so good.
First of all, it just starts with, “In case of conflict.” Yes! That is exactly what design principles are for. Again, they’re not there to be like, “Rah-rah! Feel-good design principles.” No, they are there to sort out conflict.
Then, “consider users over authors.” That’s like:
Users, even over authors. Authors, even over implementors. Implementors even over theoretical purity.
Really good stuff.
There are, I think, design principles for design principles, these kind of smell tests that you can run your design principles past and see if they pass or fail.
I talked about how design principles are unique to the organization. The reversibility test kind of helps with that. You can imagine a different organization that has the complete opposite design principles to you.
I do wonder: are there some design principles that are truly universal? Well, there’s kind of a whole category of principles that we treat as universal truths. That’s kind of these laws. They tend to be the eponymous laws. They’re usually named after a person and there’s some kind of universal truth. There are a lot of them out there.
Hofstadter’s law, that’s from Douglas Hofstadter. Hofstadter’s law states:
It always takes longer than you expect, even when you take into account Hofstadter’s law.
That does sound like a universal truth and certainly, my experience matches that. Yeah, I would say Hofstadter’s law feels like a universal design principle.
90% of everything is crap.
Theodore Sturgeon was a science fiction writer and people would poo-poo science fiction and point out that it was crap. He would say, “Yeah, but 90% of science fiction is crap because 90% of everything is crap.” That became Sturgeon’s law.
Yeah, you look at movies, books, and music. It’s hard to argue with Sturgeon’s law. Yeah, 90% of everything is crap. That feels like a universal law.
Here’s one we’ve probably all heard of. Murphy’s law:
Anything that can go wrong will go wrong.
It tends to get treated as this funny thing but, actually, it’s a genuinely useful design principle and one we could use on the web a lot more.
There’s Cole and Cole’s law. You’ve probably heard of that. That’s:
Shredded raw cabbage with a vinaigrette or mayonnaise dressing.
Moving swiftly on, there’s another sort of category of these laws, these universal principles that have a different phrasing, and it’s this idea of a razor. Here it’s being explicit about in case of conflict. Here it’s being explicit saying when you try to choose between two choices, which to choose.
Hanlon’s razor is a famous example that states:
Never attribute to malice that which can be adequately explained by incompetence.
If you’re trying to find a reason for something, don’t go straight to assuming malice. Incompetence tends to be a greater force in the world than malice.
I think it’s generally true, although, there’s also a law by Arthur C. Clarke, Clarke’s third law, which states that, “Any sufficiently advanced technology is indistinguishable from magic.” If you take Clarke’s third law and you mash it up with Hanlon’s razor, then the result is that any sufficiently advanced incompetence is indistinguishable from malice.
Another razor that we hear about a lot is Occam’s razor. This is very old. It goes back to William of Occam. Sometimes it’s misrepresented as being the most obvious solution is the correct solution. We know that that’s not true because we saw in the stories of metal helmets in World War One and motorcycle helmets or the bombers in World War Two or the YouTube videos that it’s not about the most obvious solution.
What Occam’s razor actually states is:
Entities should not be multiplied without necessity.
In other words, if you’re coming up with an explanation for something and your explanation requires that you now have to explain even more things—you’re multiplying the things that need to be explained—it’s probably not the true thing.
If your explanation for something is “aliens did it,” well, now you’ve got to explain the existence of aliens and explain how they got here and all this. You’re multiplying the entities. Most conspiracy theories fail the test of Occam’s razor because they unnecessarily multiply entities.
World Wide Web
These design principles that we can borrow, we’ve got these universal ones we can borrow. I also think maybe we can borrow from specific projects and see things that would apply to us. Certainly, when we’re working on the World Wide Web and we’re building things on the World Wide Web, we could look at the design principles that informed the World Wide Web when it was being built by Tim Berners-Lee, who created the World Wide Web, and Robert Cailliau, who worked with him.
The World Wide Web started at CERN and started life in 1989 as just a proposal. Tim Berners-Lee wrote this really quite boring memo called “Information Management: A Proposal” with indecipherable diagrams on it. This is March 12, 1989. His supervisor Mike Sendall, he later saw this proposal and must have seen the possibility here because he scrawled across the top:
Vague but exciting.
Tim Berners-Lee did get the go-ahead to work on this project, this World Wide Web project, and he created the first web browser. He created the first web server. He created HTML.
You can see the world’s first web server in the Science Museum in London. It’s this NeXTcube. NeXT was the company that Steve Jobs formed after leaving Apple.
I have a real soft spot for this machine because I was very lucky to be invited to CERN last year to take part in this project where we were trying to recreate the experience of using that first web browser that Tim Berners-Lee created on that NeXT machine. You can go to this website worldwideweb.cern.ch and you can see what it feels like to use this web browser. You can use a modern browser with this emulation inside of it. It’s really good fun.
My colleagues were spending their time actually doing the hard work. I spent most of my time working on the website about the project. I built this timeline because I was fascinated about what was influencing Tim Berners-Lee.
It’s kind of easy to look at the 30 years of the web, but I thought it would be more interesting to also look back at the 30 years before the web and see what influenced Tim Berners-Lee when it came to networks, hypertext, and format. Were there design principles that he adhered to?
We don’t have to look far because Tim Berners-Lee himself has published design principles (that he formulated or borrowed from elsewhere) in a document called Axioms of web Architecture. I think he first published this in 1998. These are really useful things that we can take and we can apply when we’re building on the web.
Particularly, now I’m talking about the second diamond of the Double Diamond. When we are choosing how we’re going to execute something or how we’re going to deliver it, building the thing right, that’s when these design principles come in handy.
He was borrowing; Tim Berners-Lee was borrowing from things that had come before, existing creations that the web is built on top of like the Internet and computing. He said:
Principles such as simplicity and modularity are the stuff of software engineering.
So he borrowed those principles about simplicity and modularity.
He also said:
Decentralization and tolerance are the life and breath of the Internet.
Those principles, tolerance and decentralization, they’d proven themselves to work on the Internet. The web is built on top of the Internet. So, it makes sense to carry those principles forward on the World Wide Web.
That principle of tolerance, in particular, is something I think you really see on the web. It comes from the principles underlying the Internet. In particular, this person, Jon Postel, who is responsible for maintaining the Domain Name System, DNS, he has an eponymous law named after him. It’s also called the Robustness Principle or Postel’s law. This law states:
Be conservative in what you send. Be liberal in what you accept.”
Now, he was talking about packet switching on the Internet that if you’re going to send a packet over the Internet, try to make it as well-formed as possible. But on the other hand, when you receive a packet and if it’s got errors or something, try and deal with it. Be liberal in what you can accept.
I see this at work all the time on the web, not just in terms of technical things but in terms of UX and usability. The example I always use is if you’re going to make a form on the web, be conservative in what you send. Send as few form fields as possible down the wire to the end-user. But then when the user is filling out that form, be liberal in what you accept. Don’t make them formulate their telephone number or credit card in a certain format. Be liberal in what you accept.
Be conservative in what you send when it comes from front-end development. This matters. Literally, just in terms of what we’re sending down the wire to the end-user, we should be more conservative in what we send. We don’t think about this enough, just the weight, the sheer weight of things we’re sending.
I was doing some consulting with a client and we did a kind of top four of where the weight was coming from. I think this applies to websites in general.
4: Web fonts
Coming in at number four, we had web fonts. They can get quite weighty, but we have ways of dealing with this now. We’ve got font display in CSS. We can subset our web fonts. Variable fonts can be a way of reducing the size of fonts. So, there are solutions to this. There are ways of handling it.
At number three, images. Images do account for a lot of the sheer weight of the web. But again, we have solutions here. We’ve got responsive images with source set and picture. Using the right format, right? Not using a PNG if you should be using a JPEG, using WebP, using SVGs where possible. We can deal with this. There are solutions out there, as long as we’re aware of it.
We’re seeing that now.
When it comes to choosing a language, there’s a fantastic design principle that Tim Berners-Lee used when he was designing the World Wide Web. It’s the principle of least power. The principle of least power states:
Choose the least powerful language suitable for a given purpose.
That sounds very counterintuitive. Why would you want to choose the least powerful language? Well, in a way, it’s about keeping things simple. There’s another design principle, “Keep it simple, stupid.” KISS.
It’s kind of related to Occam’s razor, not multiplying entities unnecessarily. Choose the simplest language. The simplest language is likely to be more universal and, because it’s simpler, it might not be as powerful but it’ll generally be more robust.
I’ll give you an example. I’ll quote from Derek Featherstone. He said:
He’s absolutely right. This is about robustness here. It’s less fragile.
The classic example with ARIA: the best ARIA attribute is no ARIA attribute. Rather than having
By way of explanation, they say:
Government should only do what only government can do.
Government shouldn’t try to be all things to all people. Government should do the things where private enterprise can’t do these things. The government has to do these things. The government should only do what only government can do.
I thought that this could be extrapolated out and made into a more universal design principle. You could say:
Any particular technology should only do what only that particular technology can do
If that’s too abstract, let’s formulate it into this design principle:
We can call this Keith’s Law or Keith’s Razor or something. I think it’s a good principle.
required attributes or
input type="email". Apply the principle of least power.
Let’s see whether we’re applying the principle of least power on the web. Take an example. Let’s say you’ve got a component that’s a button component. How are you going to go about building this? You could have bare minimal HTML, just a
div or a
Or, alternatively, you could use a
button and you style it however you want using CSS.
Now, in this example, this particular component, I would say it’s a no-brainer. You go with the native
button element. Don’t make your own button component with a
Okay. That seems pretty straightforward and that is a perfect example of the principle of least power. Choose the least powerful language suitable for the purpose.
But then what if you’ve got a drop-down component, selecting an option from a list of options? Well, you could build this using bare minimum HTML. Again,
divs, maybe. You style it however you want it to look and you give it that opening and closing functionality. You give it accessibility using ARIA. Now you’ve got to think about making sure it works with a keyboard — all that stuff, all the edge cases.
Or you just use a
select element — job done. You style it with CSS …Ah, well, yes, you can style it to a certain degree with CSS, but if you ever try to style the open state of a
select element, you’re going to have a hard time.
Now, this is where it gets interesting. What do you care about more? Can you live with that open state not being styled exactly the way you might want it to be styled? If so, yes, choose the least powerful technology. Go with
select. But I can kind of start to see why somebody would maybe roll their own in that case.
input type="date" …and then have fun trying to style that in CSS. You won’t be able to do much, to be honest.
Do you still pick the least powerful technology here?
This would be kind of the under-engineered approach: to just use the native HTML approach:
It feels like there’s this pendulum swing between the over-engineered versus the under-engineered. Like I say, what it comes down is, what do you prioritize?
What you get with the native approach is you get access. You get that universality by using the least powerful language. There’s more universal support.
What you get by rolling your own is you get much more control. You’re going from the spectrum of least power to most power and that’s also a spectrum going from most available (widest access) to least available but with more control.
You have to decide where your priorities lie. This is where I think, again, we can look at the web and we can take principles from the web.
Eric has something he said recently that really resonates with me. He said:
The web does not value consistency. The web values ubiquity.
That’s the purpose of the web. It’s the universal access. That’s the value encoded into it.
To put this in another way, we could formulate it as:
Ubiquity, even over consistency.
That’s the design principle of the web.
This passes the reversibility test. We can picture other projects that would say:
Consistency, even over ubiquity.
Native apps value consistency, even over ubiquity. iOS apps are very consistent on iOS devices, but just don’t work at all on Android devices. They’re consistent; they’re not ubiquitous.
We saw this in action with Flash and the web. Flash valued consistency, but you had to have the Flash plugin installed, so it was not ubiquitous. It was not universal.
The World Wide Web is about ubiquity, even over consistency. I think we should remember that.
When we look here in the world’s first-ever web browser, we are looking at the world’s first-ever webpage, which is still available at its original URL. That’s incredibly robust.
What’s amazing is you can not only look at the world’s first webpage in the world’s first web browser, you can look at the world’s first webpage in a modern web browser and it still works, which is kind of amazing. If you took a word processing document from 30 years ago and tried to open it in a modern word processing document, good luck. It just doesn’t work that way. But the web values this ubiquity over consistency.
Let’s apply those principles, apply the principle of least power, apply the robustness principle. Value ubiquity even over consistency. Value universal access over control. That way, you can make products and services that aren’t just on the web, but of the web.
Wednesday, October 28th, 2020
Portals and giant carousels
I posted something recently that I think might be categorised as a “shitpost”:
Most single page apps are just giant carousels.
Extreme, yes, but perhaps there’s a nugget of truth to it. And it seemed to resonate:
I’ve never actually seen anybody justify SPA transitions with actual business data. They generally don’t seem to increase sales, conversion, or retention.
For some reason, for SPAs, managers are all of a sudden allowed to make purely emotional arguments: “it feels snappier”
If businesses were run rationally, when somebody asks for an order of magnitude increase in project complexity, the onus would be on them to prove that it proportionally improves business results.
But I’ve never actually seen that happen in a software business.
A single page app architecture makes a lot of sense for interaction-heavy sites with lots of state to maintain, like twitter.com. But I’ve seen plenty of sites built as single page apps even though there’s little to no interactivity or state management. For some people, it’s the default way of building anything on the web, even a brochureware site.
It seems like there’s a consensus that single page apps may have long initial loading times, but then they have quick transitions between “pages” …just like a carousel really. But I don’t know if that consensus is based on reality. Whether you’re loading a page of HTML or loading a chunk of JSON, you’re still making a network request that will take time to resolve.
Leaving aside the fact that is literally what the browser cache takes of, I’ve seen some circular reasoning around this:
To be fair, in the past, the experience of going from page to page used to feel a little herky-jerky, even if the response times were quick. You’d get a flash of a white blank page between navigations. But that’s no longer the case. Browsers now perform something called “paint holding” which elimates the herky-jerkiness.
So now if your pages are a reasonable size, there’s no practical difference in user experience between full page refreshes and single page app updates. Navigate around The Session if you want to see paint holding in action. Switching to a single page app architecture wouldn’t improve the user experience one jot.
This is the problem that Jake set out to address in his proposal for navigation transitions a few years back:
Having to reimplement navigation for a simple transition is a bit much, often leading developers to use large frameworks where they could otherwise be avoided. This proposal provides a low-level way to create transitions while maintaining regular browser navigation.
I linked to Jake’s excellent proposal in my shitpost saying:
But then I added—and I almost didn’t—this:
Now you might be asking yourself what Paul said out loud:
Excuse my ignorance but… WTF are portals!?
Portals are a proposal from Google that would help their AMP use case (it would allow a web page to be pre-rendered, kind of like an iframe).
That was based on my reading of the proposal:
…show another page as an inset, and then activate it to perform a seamless transition to a new state, where the formerly-inset page becomes the top-level document.
It sounded like Google’s top stories carousel. And the proposal goes into a lot of detail around managing cross-origin requests. Again, that strikes me as something that would be more useful for a search engine than a single page app.
But Jake was not happy with my description. I didn’t intend to besmirch portals by mentioning Google AMP in the same sentence, but I can see how the transitive property of ickiness would apply. Because Google AMP is a nasty monopolistic project that harms the web and is an embarrassment to many open web advocates within Google, drawing any kind of comparison to AMP is kind of like Godwin’s Law for web stuff. I know that makes it sounds like I’m comparing Google AMP to Hitler, and just to be clear, I’m not (though I have myself been called a fascist by one of the lead engineers on AMP).
Clearly, emotions run high when Google AMP is involved. I regret summoning its demonic presence.
After chatting with Jake some more, I tried to find a better use case to describe portals. Reading the proposal, portals sound a lot like “spicy iframes”. So here’s a different use case that I ran past Jake: say you’re on a website that has an iframe embedded in it—like a YouTube video, for example. With portals, you’d have the ability to transition the iframe to a fully-fledged page smoothly.
But Jake told me that even though the proposal talks a lot about iframes and cross-origin security, portals are conceptually more like using
rel="prerender" …but then having scripting control over how the pre-rendered page becomes the current page.
Put like that, portals sound more like Jake’s original navigation transitions proposal. But I have to say, I never would’ve understood that use case just from reading the portals proposal. I get that the proposal is aimed more at implementators than authors, but in its current form, it doesn’t seem to address the use case of single page apps.
we haven’t seen interest from SPA folks in portals so far.
I’m not surprised! He goes on:
Maybe, they are happy / benefits aren’t clear yet.
From my own reading of the portals proposal, I think the benefits are definitely not clear. It’s almost like the opposite of Jake’s original proposal for navigation transitions. Whereas as that was grounded in user needs and real-world examples, the portals proposal seems to have jumped to the intricacies of implementation without covering the user needs.
I guess the web I want includes giant carousels.