Tags: medium

450

sparkline

Thursday, January 23rd, 2020

Web standards, dictionaries, and design systems

Years ago, the world of web standards was split. Two groups—the W3C and the WHATWG—were working on the next iteration of HTML. They had different ideas about the nature of standardisation.

Broadly speaking, the W3C followed a specification-first approach. Figure out what should be implemented first and foremost. From this perspective, specs can be seen as blueprints for browsers to work from.

The WHATWG, by contrast, were implementation led. The way they saw it, there was no point specifying something if browsers weren’t going to implement it. Instead, specs are there to document existing behaviour in browsers.

I’m over-generalising somewhat in my descriptions there, but the point is that there was an ideological difference of opinion around what standards bodies should do.

This always reminded me of a similar ideological conflict when it comes to language usage.

Language prescriptivists attempt to define rules about what’s right or right or wrong in a language. Rules like “never end a sentence with a preposition.” Prescriptivists are generally fighting a losing battle and spend most of their time bemoaning the decline of their language because people aren’t following the rules.

Language descriptivists work the exact opposite way. They see their job as documenting existing language usage instead of defining it. Lexicographers—like Merriam-Webster or the Oxford English Dictionary—receive complaints from angry prescriptivists when dictionaries document usage like “literally” meaning “figuratively”.

Dictionaries are descriptive, not prescriptive.

I’ve seen the prescriptive/descriptive divide somewhere else too. I’ve seen it in the world of design systems.

Jordan Moore talks about intentional and emergent design systems:

There appears to be two competing approaches in designing design systems.

An intentional design system. The flavour and framework may vary, but the approach generally consists of: design system first → design/build solutions.

An emergent design system. This approach is much closer to the user needs end of the scale by beginning with creative solutions before deriving patterns and systems (i.e the system emerges from real, coded scenarios).

An intentional design system is prescriptive. An emergent design system is descriptive.

I think we can learn from the worlds of web standards and dictionaries here. A prescriptive approach might give you a beautiful design system, but if it doesn’t reflect the actual product, it’s fiction. A descriptive approach might give a design system with imperfections and annoying flaws, but at least it will be accurate.

I think it’s more important for a design system to be accurate than beautiful.

As Matthew Ström says, you should start with the design system you already have:

Instead of drawing a whole new set of components, start with the components you already have in production. Document them meticulously. Create a single source of truth for design, warts and all.

Wednesday, January 22nd, 2020

Building

The opening presentation from the New Adventures conference held in Nottingham in January 2019.

Good morning, everybody. It is a real honour to be here. As Simon said, I was here six, seven, eight years ago attending this conference because it’s such a great conference. I’m kind of feeling the pressure now that I’m up here on the stage speaking at this conference. I’m just glad I’m on first so I can get it over with and then listen to all these great talks.

I’m here today to talk to you …which is kind of weird when you think about it. I mean, first, the fact that it’s me up here on the stage through some clerical error.

But also, I’m going to talk to you. I’m going to vibrate air over my vocal cords and move this big meaty piece of flesh inside my jaw up and down vibrating the airwaves and you’re going to listen to me doing that. It seems like a crazy thing to do except for the fact that, of course, I’ll be using language.

Language

Maybe the great distinguishing feature of our species, language. The great leap forward that happened—who knows—50,000, 100,000 years ago when we, as a species, developed language. With language, by moving those vocal cords and that big piece of flesh in my jaw, we can tell stories. I can recount something that happened in the past.

Perhaps more amazingly, we can imagine things that might come to be. I could tell you something that might happen in the future. So language is a kind of time travel.

It’s all possible because we’re speaking the same codebase. The particular language I’m talking now is English. As long as you can decode English then all these noises I’m making will make sense to you even if there isn’t actually any information in the words. I can say Chomsky’s famous one.

Colourless green ideas sleep furiously.

You can parse that. It doesn’t make any sense, but you can parse it.

Most of the time, the sentences we use also convey some kind of information. Language is not just time travel. Language is also communication.

There can be an idea that’s sitting in my head and I’ll, you know, vibrate the air and vocal cords, flap this big fleshy thing in my jaw around, and transfer the idea from my head to your head. Language is almost like a virus. You can’t help but take the idea in.

I can say to you, “Don’t think of an elephant,” right? Now you’ve just thought of an elephant. It’s the language equivalent of the chicken game which, if you haven’t played before, sorry. You’ve just lost.

Chicken game. Don’t look at this chicken. Game over.

This sentence, “Don’t think of an elephant,” is actually the title of a book by George Lakoff. George Lakoff is a linguist. He’s written many books. He wrote Women, Fire, and Dangerous Things. He wrote this, Metaphors We Live By, because he’s kind of obsessed with metaphors.

We use metaphor all the time in language. We use conceptual metaphor, so when we take one idea and we use the language of that idea to talk about a different idea. The classic example being something intangible.

Let’s say time. How do we talk about time when we can’t touch it, we can’t feel it, it’s intangible? Well, we use metaphor.

We talk about time as though it’s a physical object moving through space. We say time flies or time drags or we talk about time as though it’s a resource. We talk about saving time, wasting time.

You can’t do any of those things with time. That’s not how time works. But the metaphor is very helpful.

The other kind of metaphor is the cognitive metaphor. This is what George Lakoff is interested in, particularly in things like political language. How we frame a debate can tip the scales of how that debate would unfold. If we were about to have a debate about tax relief, well, before the debate has even begun, we’ve framed taxation as something you need relief from and the scales have been tipped.

I’m very interested in this idea of metaphor, analogy, and simile and how we talk about the work we do. It’s such a young industry. What we do is we borrow from other industries. We’re not the first to do this. There’s a great book called Understanding Comics by Scott McCloud. Who’s read Understanding Comics? It’s great.

It’s about comics but, really, it’s just a fantastic book. It’s written as a comic. In it, Scott McCloud makes the point of this new medium, comics, had to kind of borrow from the existing mediums that came before. He points out that this isn’t new. He says:

Each new medium begins its life by imitating its predecessors. Many early movies were like filmed stage plays. Much early television was like radio with pictures.

Right? That it takes time.

Now, this idea of a new medium having to borrow the tropes and the language of the medium that came before, this idea pops up again on the web in this article published in the year 2000 by John Allsopp on A List Apart, A Dao of Web Design. Can I get a show of hands of who’s read A Dao of Web Design? Awesome. You are my people. The rest of you, please read it. It’s such a wonderful article.

It’s crazy that I’m standing up here recommending, “Oh, yeah, you should totally read this article from the year 2000,” but it is relevant. It’s amazingly relevant still today. It’s maybe more relevant today than when it was written. 
In the article, John says:

When a new medium borrows from an existing one, some of what it borrows makes sense, but much of the borrowing is thoughtless, it’s ritual, and it often constrains the new medium. Over time, the new medium develops its own conventions, throwing off existing conventions that don’t make sense.

Now, at the time John was writing this, 2000, of course, we were borrowing from what had come before in the previous medium and that was print. We were trying to figure out how do we get the same level of control that we were used to in the world of print on the web. We did that using clever techniques thanks to David Siegel who wrote this book, Creating Killer Websites. David Siegel, if you don’t know the name, you’re certainly familiar with his work because he’s the guy who came up with the idea of using tables for layout or having a one-pixel by one-pixel spacer GIF.

Hey, listen. That was the only way we could do it back then. They were hacks, yes, but they were necessary hacks. He did actually recant. Years later, he wrote a piece that said, the web is ruined and I ruined it. This may be overstating the case, but you know.

He was pointing out we could use these techniques, these hacks to constrain Web and make it work like print. We could get pixel-perfect control. John Allsopp, in his article, he’s kind of pushing against and going, no, no, no:

The web is a new medium. It has emerged from the medium of printing whose skills and design language and convention strongly influence it. It is too often shaped by that from which it sprang. Killer websites are usually those which tame the wildness of the web, constraining pages as if they were made of paper. Desktop publishing for the web.

So, I mean, John totally acknowledges that there is a lot to learn from this rich, rich history of print and, before print, just writing. This is clearly the second great leap of our species. We had language where we could communicate ideas, tell stories, imagine the future—as long as we’re in the same physical space—and then we came up with writing. Now we can communicate, re-viral ideas, talk about the future and the past, and we don’t even have to be in the same physical place. Someone who died centuries ago can put an idea in your head by putting language onto a medium like vellum or, later, paper.

You can see this evolution over centuries from illuminated manuscripts to the printing press, Gutenberg, until we get to the 20th Century and we really start to refine the design. We got the Swiss School of Design, the fonts, typography, and the grid system. There’s a lot to learn here.

The Book of Kells. Gutenberg’s bible. Grid Systems.

What’s interesting to me, though, is what seems to be this battle of extremes. We’ve got David Siegel talking about desktop publishing for the web, effectively, and John Allsopp talking about, “No, the web is its own medium. It needs to have its own conventions.”

They seem to be at opposite ends of a spectrum. Yet, they actually have a commonality because, on both sides, when they’re talking about this, they’re talking about websites — web sites. Now, that in itself is a metaphor. You don’t have physical sites on the web. It’s intangible like time. Yet, we chose this metaphor. The idea of a site, a place where you go to a physical place.

Site actually is pretty good with connotations of a building site, a construction site. That was literally the metaphor in the ’90s. The web is like a construction site. It kind of is constantly under construction. Oh, you want the full nostalgic effect?

Under construction.

There we go. We’re back to Geocities. But I feel like then we decided to grow out of this metaphor and use more grownup metaphors. We got professional. We had to borrow from other industries, other mediums, and here’s one that people are very fond of borrowing: architecture—describing what we do as architecture.

Architects

Whether it’s on the design side or the development side, talking about us as architects. It seems like a very appealing industry to borrow from, which is fascinating. If you ever talk to architects, man, it’s a shitty industry. Spec work, awards, and competition, it’s not a great industry.

But we seem to hold it up as, like, “Oh, yeah, we’re like architects because architects are awesome.” I think of Hollywood because every Hollywood movie that has an architect in it, the architects are always really nice people. They’re always like the protagonist, never the antagonist. The architect is never the villain.

It’s fair enough. It’s fair enough to borrow things from something like architecture. For example, I know plenty of designers who would say that this book is the best book about UX that they’ve ever read, 101 Things I Learned in Architecture School by Matthew Frederick. It was published in 2007. It’s not written for UX designers. It’s not written about the web, but there are lessons in there that are directly applicable.

There are other works from the world of architecture that have definitely influenced the work we are doing today like the classic from Christopher Alexander, A Pattern Language. Now this—I say classic rightly—this is a classic book. A classic book is a book everyone has heard of and nobody has read.

That is certainly the case here. Published in 1977, and it influenced lots of people doing things in the digital space. Ward Cunningham, the inventor of the wiki, he said, yeah, he was really influenced by A Pattern Language.

The idea of a pattern language, it’s architecture, but breaking things down into components that you could change the parameters we used in public spaces, buildings, things like that. It’s a modular approach. Later on, in the software world, a gang of four, they wrote Design Patterns: Elements of Reusable Object-Oriented Software, and they were directly influenced by Christopher Alexander, this idea of a pattern language, components, patterns, modularity.

What’s interesting is there’s another book by Molly Wright Steenson, you may remember was a blogger, Girl Wonder. She worked in the world of architecture and she’s written a book about the influence of architects and designers on the digital space. Richard Saul Wurman, and information architecture. There’s a very direct metaphor there, but also Christopher Alexander.

She points out, actually, the funny thing is, he’s had way more of an influence in the digital space than he ever had in architecture. Most architects don’t like him. They think he’s a bit preachy. But his influence in the digital space is massive. Here I am talking about modularity, components, and patterns. Well, I mean, that is so hot right now. Design systems, we’re breaking things down into patterns. 
In fact, I ended up organizing a conference in 2017, purely about design systems, pattern libraries, styles, all this stuff called Patterns Day. It was great. We had these wonderful speakers. Jina Anne was there, Rachel Andrew, Alla Kholmatova, Alice Bartlett. It was great.

But, by the end of the day, I was kind of half-joking as saying, we should have had a drinking game where, every time someone referenced Christopher Alexander, we had to take a drink because his spirit loomed large over this. Actually, the full rules of the drinking game I came up with afterward where any time someone references Christopher Alexander, you take a drink. Any time someone says Lego, you take a drink. Any time someone says that naming things is hard, take a drink. Any time someone says atomic or atomic design, take a drink. Anytime someone says bootstrap, you puke the drink back up.

A Pattern Language is a work of architecture that directly not just influenced but is still influencing our work today; the idea of breaking things down into components to reuse.

Now, there’s another work from the world of architecture that has a big influence on me. It’s a classic book, again, How Buildings Learn. It’s the best book I’ve never read, published in 1994, by Stewart Brand. There was also a TV series that went with this that’s pretty fascinating.

In this, he talks about the work of a British architect named Frank Duffy and Duffy’s idea of something he called shearing layers. What Duffy said was that a building properly conceived is several layers of longevity. He kind of broke these down. You’ve got the sites that the building is on. We’re talking about geological time scales.

Then above that, the structure you hope will last for centuries. Then you’ve got the infrastructure inside the building that you might have to swap out every few decades. Change the plumbing. Then you’ve got the walls and the doors. You can change them every so often until you get into the room. You’ve got furniture, which you can move on a daily basis.

The time scales get faster as you move inward. He diagrammed it like this. This is shearing layers diagrammed for the building. I find this really interesting, this idea of different time scales.

Shearing layers.

But there’s another factor here I’m kind of fascinated by, which is that each layer depends on the layer below. You can’t have a structure until you’ve got a site to build on. You can’t have furniture inside a room until you’ve got the room. You need to have the walls there. Each layer is building on top of what’s come before. You can’t jump straight ahead to furniture without first having all those other layers.

Now, this reminds me of another idea that the writer Steven Johnson talks about a lot in his work, for example, this book, Where Good Ideas Come From. This is the idea of the adjacent possible, that certain inventions leap forward that can’t happen until other things have happened before them.

There’s a reason why the microwave oven wasn’t invented in medieval France. Too many other things had to be invented first before something like the microwave oven becomes inevitable.

Everything we do is kind of built on this idea of the adjacent possible because businesses and services on the web are on top of a whole bunch of layers of adjacent possibilities. You can’t have Twitter, Facebook, or Wikipedia until the web exists. The web itself is built on all of these layers that have to happen first.

We have to have the Industrial Revolution. We have to have electricity. Then somebody has to create circuitry. We have to get to the idea of having computers and then networked computers, something like the Internet. Then the web becomes possible. Once the web is possible, then all these businesses on top of the web become possible.

This idea of the adjacent possible, the shearing layers, they kind of fascinate me because I’m seeing a parallel there.

Now, Stewart Brand, who wrote about shearing layers and architecture, he revisited this idea of shearing layers and took them out from the world of architecture in a later work called The Clock of the Long Now. Stewart Brand is one of the founders of the Long Now Foundation. If you haven’t heard of it, it’s an organization dedicated to long-term thinking. I’m a card-carrying member. The card is designed to last for a few thousand years as well.

They’re currently building a clock that will tell time for 10,000 years. Brian Eno has written an algorithm for the chimes so that when it chimes once a century, it will never be quite the same chime. It’s encouraging long now thinking.

In this book, the full title of the book being The Clock of the Long Now: Time and Responsibility: The Ideas Behind the World’s Slowest Computer, he extrapolates shearing layers into something he calls pace layers. If you take the shearing layers model and look around you, it’s everywhere. It’s kind of like systems thinking, the Donella Meadows idea that systems are everywhere.

Pace layers.

It’s kind of true. You look around these pace layers; shearing layers applied to the real world are everywhere. The example he gives is our species. If we look at the human race, we have these different time scales. The slowest is our physical nature as in our DNA, our physiological nature. That takes millennia to change. Physiologically, there’s no difference between a caveman and a spaceman.

Above that, you’ve got culture. This takes centuries, maybe longer, to accumulate over time.

Then systems of governance; not governments — governance. How are we going to run the societies?

An infrastructure, you want that to move faster, but not too fast or it could be very disruptive. 
Then you get into commerce, trading. Very fast-moving.

Then, finally, you’ve got fashion, which is super-fast. By fashion, he means things like popular music, anything that’s supposed to move fast. If fashion moved slowly, that wouldn’t be a good thing. It’s meant to move fast. It’s meant to try things out. “What about this? No, what about this? Try this.” Right? You don’t want for the things further down.

He’s mapped this onto these layers. From shearing layers, we go to pace layers. They have different timescales.

I’m talking about the difference between these really fast layers at the top, you know, “What about this? Try this? Today, we’re doing that,” compared to the really slow layers at the bottom that move slowly and are resistant to change.

He says:

Fast learns but slow remembers. Fast proposes and slow disposes. Fast is discontinuous but slow is continuous. Fast and small instructs slow and big by a crude innovation, an occasional revolution, and slow and big controls small and fast by constraint and constancy. Fast gets all our attention, but slow has all the power.

Now, once I was exposed to this idea and this virus had landed in my head, I found that I couldn’t get it out of my head. I started seeing pace layers everywhere. At Clear Left, where I work, it’s a running joke. On every project, we have a kickoff. It’s like, what’s the time to pace layers? How long will it be before someone makes a pace layer analogy? It’s like my brain has now been rewired to see pace layers everywhere.

It’s like, you know, the first time that someone points out the arrow in the FedEx logo. There was your life before that and there’s your life after that.

You’ve all seen the arrow in the FedEx logo. Yeah.

What about Toblerone? You’ve all seen the bear? Ah, yeah! Right? You will never be able to unsee that.

Consider the duck.

It’s a perfectly normal, ordinary duck. Agreed? But then your brain is exposed to the idea that all ducks are actually wearing dog masks.

All ducks are actually wearing dog masks. Now, when I show you the same picture of the same duck—

—you will never be able to unsee that. That’s how my brain feels when it comes to pace layers. I see them everywhere. It’s like the crazy wall part of the serial killer’s lair in the murder mystery. It’s just pace layers.

I couldn’t help but apply pace layers to the work we do mapping our medium to pace layers. Let’s try it with the World Wide Web.

The layers of the web.

Well, we build on top of the Internet. We can’t have the web before having Internet. At the very bottom layer, you’ve got the protocols of the Internet itself, you know, TCP/IP, which have been pretty much unchanged for decades. They were there from the ARPANET before the Internet. It’s a good thing that they’re unchanged. You would not want to be swapping out that low layer very quickly.

Above that, we have all the different protocols we use, protocols for email, protocols for file transfer, and protocols for the World Wide Web, HTTP, the hypertext transfer protocol. Now, this has evolved over time. We now have HTTP2, but it’s been a slow process and that feels right. Again, we shouldn’t be swapping out too quickly, but it’s a bit faster moving than the Internet protocols. 
On top of HTTP, we can put our URLs. Now, I would love it if URLs were right down at the bottom layer and they were permanent and they never changed and they never went away. That is the web I want, but I must acknowledge that, alas, you have to work hard to keep URLs alive. They do change. They do move. They do get destroyed, which is a bit of a shame, but we can work at it, people. We can work on keeping our URLs alive.

What we put at that those URLs, at the simplest level, we’ve got HTML. It was there from the start. From day one of the web, HTML was there and it’s still there today, but it’s evolved. It’s changed over time. Initially, HTML had 21 elements and now it’s got 121 elements, so it’s evolved.

But it feels like you can keep up with the pace of change. The last big evolution of HTML was 2010, later, with HTML5. We do get new editions every now and then, but it’s fine. We can keep up with it.

Then CSS, CSS changes may be more — definitely changes more rapidly than HTML. That feels like a good thing. We kind of want more. Give us some more CSS and now we’ve got Grid and we’ve got Flexbox. We’ve got all these great, new CSS things. Custom properties.

I don’t feel too overwhelmed by that. I still feel like, “Oh, no, this is good. We’ve got new CSS. I’m feeling I can keep on top of this, you know, read the right articles, read the right books, try them out. It’s fine.”

Then there’s the JavaScript ecosystem.

Specifically, the ecosystem, not the language, because the JavaScript language itself doesn’t actually change that often. ES6 or ES2000, whatever we’re talking about the evolution to the language, they’re not so rapid that we’d get overwhelmed. But the language ecosystem, the culture of JavaScript, that feels overwhelming to me. Right? Since I’ve been speaking up here, two new JavaScript frameworks have been released.

The pace, I constantly feel like I’m falling behind like, “Oh, I haven’t even heard of this new thing that apparently everybody is using.”

Does anyone else feel overwhelmed by this pace of change? Okay, good. Keep your hands up for a sec and just look around. All right? You are not alone. This turns out to be normal.

But here’s the thing. By mapping these different rates onto this model of pace layers, I actually start to feel better about this because let’s say the JavaScript ecosystem is fashion: “It’s going to do this. No, no, today we’re doing that. Try this. Try that.”

Whereas, “Oh, okay. It’s supposed to move fast. It would be bad if it moved slow. It’s meant to be trying stuff out. We see what sticks.”

With fashion, the best of pop music will probably last and find its way down the layers into culture, a slower pace layer. With the JavaScript, the patterns that work in JavaScript may find their way down into the slower moving layers.

To give you an example, when JavaScript was first invented—I’m showing my age here—I remember the common use cases were rollovers, image rollovers. And form validation, so mousing over something and changing how it looks, we’d use JavaScript for that. If someone is filling in a form and there’s a required field, we’d use JavaScript to make sure that required field was filled in.

These days, we wouldn’t even use JavaScript for either of those. We’d use CSS to do rollovers. We’d use HTML to add just one required attribute. The pattern, it stuck. The spaghetti stuck to the wall and it moved down the layers into something more stable.

That’s what JavaScript is kind of supposed to do. When we’re trying to responsive images, we had JavaScript solutions until we got to something that was further down the stack in HTML.

I do feel overwhelmed by the pace of change. But I’m starting to feel a little better about feeling overwhelmed, that it’s okay. JavaScript is meant to feel overwhelming. It’s where we try stuff out. It’s where stuff moves fast.

Now, the other thing I realized by mapping our technology stack of the web onto this pace layer model is that this is how I build. When I’m building a website, I pretty much start at the third layer. I don’t worry about, is the Internet on.

I start with URLs. I think URL design is a really good place to start designing. It is a design discipline, a neglected one, but it is design. Then I think about the content and then structure that content using the best available markup of HTML. I think about the presentation may be on a small screen first and then the presentation on larger screens using CSS. Then start thinking about extra behaviors that I can’t get with HTML and CSS, so I reach for JavaScript to add those extra behaviors.

This seems to me to make sense as a way of building on the web because it maps to the structure of the pace layers of the web. But it’s also a testament to the flexibility of the web that you don’t have to build this way. If you don’t want to build in this layered way, you don’t have to.

In fact, you can build like this. You can put something that’s on the Internet, but you just do everything in JavaScript. URL routing, let’s do that in the browser in JavaScript. The Document Object Model, let’s generate that in the browser in JavaScript. CSS, apparently we’re doing it in JS now.

Everything in JavaScript. This is an absolutely legitimate choice. You can choose to build things on the web like this. The web allows this. Again, it’s a testament to the flexibility of the web.

Now, personally, I don’t build like this and this doesn’t feel quite right to me. It doesn’t feel like it maps to the web too well. It kind of turns it into this all or nothing situation where, as long as we’ve got JavaScript, everything is going to be great. But if we don’t, there’s nothing.

You end up with this situation where we’ve turned what we’re building on the web into a binary situation. Either it works great or it just doesn’t work at all. There’s this kind of single point of failure there with the JavaScript.

Now, this model makes complete sense in other mediums. I think other mediums have influenced our thinking on the web. Maybe we’ve borrowed the metaphors of these other mediums.

For example, if you’re building a native app, this makes complete sense. If you’re building an iOS app and I have an iOS device, it works great. I get 100% of what you designed. But if you build an iOS app and I have, say, an Android device, it doesn’t work at all. You can’t install an iOS app onto an Android device. Those are your options: either it works great or it doesn’t work at all. This mental model makes complete sense in that field.

On the web, because we can have this layered approach, that means we can build like this. We can go from something that doesn’t work at all to something that just about works—maybe it’s just text on a screen—to something that works fine—maybe it’s missing a bunch of behaviors, but the user can accomplish what they want to do—to something that works well, but maybe the latest and greatest browser APIs aren’t supported by a particular browser—and then to something that works great like the latest browser running the best device, great network.

Building in layers.

Most people are going to be somewhere on this continuum. Maybe nobody is going to get 100% of what you hope they get, but no one is going to get zero percent either as long as you’re building in this way, as long as you’re building with the grain of the web, building in layers, one thing on top of the other.

I’m going to quote Ethan here. Hi, Ethan. Ethan said:

I like designing in layers. I love looking at the design of a page, a pattern, whatever, and thinking about how it would change if, say, fonts aren’t available or JavaScript doesn’t work or if someone doesn’t see the design as you and I might and is having the page read aloud to them.

In a way, this is a way of busting assumptions, the what-ifs. What if something isn’t supported? By building in a layered way, it’s okay. Everything will fall back to the layer below, the adjacent possible.

Now, Ethan, of course, we all know from this article, Responsive Web Design, published on A List Apart. When was that? 2010. My God, nine years ago. Ten years after, John Allsopp published A Dao of Web Design on A List Apart. One of the first things Ethan does in this article is to reference A Dao of Web Design. You could say that Ethan was building on top of that foundational layer that was set by John Allsopp.

Architecture again. Responsive web design. The reason why Ethan chose that term was because there was this idea in architecture called responsive architecture about buildings that could respond to the conditions of the people in the buildings. That made a really good metaphor for talking about the web on large screens, small screens, and everything in between.

This architecture thing, as a metaphor, it’s not bad. We can learn from it. I think, just be careful not to take it too far.

It’s not the only metaphor we use. Here’s another one. When we don’t talk about ourselves as architects, we’re engineers. Yeah.

Engineers

It sounds good. This one predates the web. We’ve been talking about the idea of software engineering for a long time. I’m very partial to this term: software engineering. Not so much for the term itself. Not that I think it’s a particularly good metaphor, but from where it comes from, which is fricken’ awesome.

Margaret Hamilton.

The term “software engineering” comes from Margaret Hamilton. Margaret Hamilton was in charge of the onboard flight software on the Apollo moon landing. This is engineering. That is the code base she’s standing next to there, which would then literally be woven into the computers onboard Apollo.

But as a metaphor, engineering, well, there’s a whole bunch of different kinds of it. What kind of engineer are we talking about here? Is it material engineering, structural engineering, chemical engineering, aeronautical engineering? They all have commonalities. One being, as an engineer, you’ve got to know two things. There’s the materials you’re going to be working with and the tools you’re going to use to shape those materials.

Now, I think that we can use that metaphor and apply it to the web. I would say the materials on the web are HTML, CSS, and our JavaScript, hopefully in that order. Then we’ve got the tools we use to design for the materials of the web. 
Now, the most obvious tools we could think of are graphic design tools. We started using Photoshop even though that was never intended for Web design. Since then, we’ve evolved and we’ve got tools that are much more focused on the web, things like Sketch, Figma, and all this kind of stuff.

These are obvious tools we use to build the web, but there are less obvious tools. If you were working on a Web project, these tools also get used. You’re going to be talking over email. You’re going to be communicating over Slack, organizing spreadsheets, spreadsheets people.

We talk about these as productivity tools, though sometimes I know it feels like they are reducing productivity rather than increasing it. But it’s kind of a misnomer when you think about productivity tools. All tools are productivity tools. That’s literally what tools are for is to make you more productive.

I think we should acknowledge that these are legitimate design tools. You can’t launch a project without putting in some time and some kind of communication tool.

Then when it comes to the actual welding of these materials, we’ve got a whole bunch of tools that sit in our machines or sit in our Web servers. Now I feel like I’m back up at that top layer of the pace layers and I’m getting overwhelmed with the task runners, the build tools, the chains, the transpilers, and the preprocessors. Apparently, it changes every week. Oh, you’re still using Grunt? No, we’re using Gulp. No, Webpack. That’s what’s so overwhelming.

It also feels like it’s quite complicated. This is complicated stuff, but it’s like we’ve chosen it. We’ve chosen to make our lives complicated, in a way.

I’ll tell you what it reminds me of. Do you remember that startup, Juicero?

Where they sold a big, expensive, complicated machine to make juice, but you had to buy exactly the right juice packets to put in the big, expensive machine to make the juice. It works. It works great. The big, expensive, complicated machine does its job but somebody noticed that you could actually just take the packets and squeeze them by hand and it still produces juice. I’m just saying that squeezing by hand is still an option. You can build websites by squeezing by hand. (I think this metaphor has been stretched just about as far as it can do, so I will leave it there.)

There’s this other kind of spectrum, I guess, between the materials and the tools and then the people that will be exposed to the materials and the tools. They kind of fall into two categories: the engineers themselves and the end-users.

When we’re evaluating our tools and asking, “Is this the right tool to use?” we should evaluate it from our perspective, yes, “Is this going to be a helpful tool to me as an engineer?” if we’re using that metaphor. But I strongly feel we should also ask, “Is this going to be useful for the end-user?”

If those two things come into conflict, what then? Do we privilege our own experience over the user experience? I would hope not. I worry that, in a lot of tool choices, particularly on stuff that gets sent down to the browser. “Oh, I’m going to use a CSS framework.” Great. Good for you. That’s helping you out but now the user has to pay the cost of the benefit that you get from that CSS framework because they have to download the whole CSS framework.

Sometimes, these things come into conflict and I feel like maybe we privileged the developer experience over the user experience and that worries me. The other time they don’t come into conflict. All those tools like preprocessors and task runners that just sit on your own computer, no direct effect on the end-user experience. Frankly, use whatever you like. It doesn’t make a direct effect on the end-user experience.

When we’re evaluating tools, there are all these questions to ask. Who benefits from the tool? If I choose to use this tool, will it benefit the users? Will it benefit the engineers? Neither? Both?

There are other questions we ask like, well, just how good is this tool? To evaluate that we ask; yeah, how well does it work? Does this tool do what it says it will do well?

This, of course, is a completely valid question to ask but there’s a corollary that I think is more valid and that’s to ask not just how well does it work but how well does it fail?

What happens when something goes wrong?

This is exactly why I think this layered approach makes sense because, if you build in this layered way, each one of these layers can fail well. If you build like this, then JavaScript can fail well. What if something goes wrong and you’ve got an error in your JavaScript? You fall back to something that still works. Not as great as it worked before, but it still works. It fails well.

These technologies on the web, they fail well by design. CSS fails well. Use a CSS property the browser doesn’t understand or CSS value. The browser just ignores it. It fails well.

HTML: Make up an HTML element. Throw it into a webpage. The browser doesn’t throw an error. The browser doesn’t stop parsing the webpage. It just ignores it and moves on. It fails well.

It actually makes sense to not jump ahead to the powerful stuff, to the top of the pace layers, but to try and build in layers and stay low for as long as possible. This is actually a principle, a principle that underlies the architecture of the web itself called the Principle of Least Power. You should choose the least powerful language for a given purpose, which seems really counterintuitive.

Why would I choose the least powerful language to do something? Surely, I want more power. The idea here is the power comes at an expense. Power comes at the expense of complexity, fragility. The more powerful technology is maybe more likely to fail badly.

Derek Featherstone put it well. He said:

In the web front-end stack—HTML, CSS, JavaScript, and ARIA—if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof. It just works.

The example there was rollovers. How are you going to do rollovers? Do it in JavaScript? No, do it in CSS. :hover - done. Right? Oh, you need to make an interactive button? Use the button element. Be lazy.

This makes a lot of sense, the Principle of Least Power. It makes a lot of sense to me on the web, especially when you combine it with a universal law that definitely applies on the web, and that’s Murphy’s Law:

Anything that can possibly go wrong will go wrong.

This comes directly from the world of engineering. Edward Aloysius Murphy Jr. was an aerospace engineer. It’s because he had this attitude, he never lost anybody on his watch.

I think we tend to dismiss things going wrong as edge cases. We kind of assume the average output. Other industries, when they’re making cars, they test them. They strap crash test dummies in. They smack them into walls at high speed.

To be fair, a lot of the reason why they have to do that is because of regulation. They didn’t necessarily choose to do it, but still. Can you imagine if they went, well, actually, we realize that most people are going to drive cars on roads and people driving into walls is an edge case, so we’re not going to worry too much about that?

Now, obviously, you want to hope for the best but you should prepare for the worst. Trent Walton said:

Like cars designed to perform in extreme heat or on icy roads, websites should be built to face the reality of the web’s inherent variability.

The web’s inherent variability, that gets to the heart of it.

Dave Siegel was trying to battle with the pixel-perfect labels was the web’s inherent variability. What John Allsopp was calling was for us to embrace the web’s inherent variability. It’s a feature, not a bug.

Are we engineers? Can we call ourselves engineers? Well, let me tell you something from the world of structural engineering.

This is the plan for the Quebec Bridge in Canada, a cantilever bridge. Construction started at the start of the 20th Century. There was a competition to see who get to design and build a bridge because that’s the way the industry works.

The engineer in charge was named Theodore Cooper. Now, originally, the bridge was meant to be 490 meters long but Theodore Cooper changed the specification to make it 550 meters long, mostly because, up in Scotland, the Firth of Forth Bridge, that was the longest bridge in the world at the time, longest cantilever. He wanted this bridge to exceed that, so he made the bridge longer but he did not recalculate the already high stresses being placed on the material of the bridge.

Oh, also, Theodore Cooper refused to work on site. He was down in New York, supposedly overseeing construction from New York. And when it was proposed that somebody should check his calculations, he took that as a personal afront and said, “No, no, no. No, no, that won’t work,” so there was no code reviews happening on this project.

Now, someone was onsite, the young engineer named Norman McLure. By 1907, August 6th, he had started to notice that the steel was bending, getting a lot of stress. Then again, on August 27th, it had got worse.

Cooper was notified down in New York. He did send a telegram back to Quebec. He said, “Place no more load on Quebec bridge until all facts considered - stop.” But he was inferring that the work should stop. He never explicitly said, “Stop the work right now,” so the telegram was ignored and work continued.

On August 29th, 1907, the bridge collapsed. It was shortly before the end of the day. The whistle was just about to blow to signal the end of the working day. There were 86 workers on the bridge and 75 of them died.

Now, something started happening in Canada a few years after this, by 1925. Engineering schools in Canada started holding private ceremonies around graduation time. This was a ceremony that was separate from qualifications. This wasn’t about whether you were qualified to be an engineer. This was called The Ritual of the Calling of the Engineer. You would speak an obligation penned by Rudyard Kipling, which I won’t repeat here because it’s meant to stay within the confines of this ritual.

You would also receive an iron ring. This iron ring would be a symbol of pride of being an engineer, but also a symbol of humility. For the longest time, the myth persisted that the iron itself was made from the steel in the Quebec Bridge. It’s not true, but the Quebec Bridge certainly looms over the idea of the iron ring. You’d wear it on the little finger of your working hand, so it would brush against the paper or the computer keyboard during your working day as a constant reminder of your responsibility as an engineer.

The iron ring.

When we call ourselves engineers, I do have to ask, have we earned it? Do we take our responsibility seriously?

Maybe we don’t call ourselves engineers, but then what do we call ourselves? Does it even matter?

Builders

Well, we could go back to that original metaphor from the ’90s, under construction. Maybe we’re builders. We build things. The web is under construction. We’re the ones constructing it. It’s not so bad, you know, to be the ones literally building the web. It’s kind of awesome when you think about it.

Christopher Alexander, when he was talking about his reason for coming up with A Pattern Language, was because he said:

Most of the wonderful places in the world were not made by architects but by the people.

Maybe we’re at the bottom of the layer stack here as workers just building the web, but maybe we also have all the power — more power than we realize. Our collective power is greater than anything any architect could wield.

Yeah, maybe we’re builders. Maybe we’re bricklayers. I know Simon comes from a long line of bricklayers. It is a noble profession. Think about what our building blocks are, the building blocks of the World Wide Web.

The World Wide Web, I think, is the next great leap forward. We had language, writing, the printing press, and now hypertext in the form of the Word Wide Web. Who gets to build it? We do with this kind of building block: the URL, a link. What an amazing building block that is.

I can make a webpage and put two links on it linking to two different things. That combination of those two links has never existed before in the history of the web. We’ve created something new, link by link, building block by building block, building in layers.

I’m reminded of an apocryphal story may be from medieval times—who knows—a traveler coming across three workers. All three workers are doing the same thing. They’re building. They’re moving stones. They’re putting stones one on top of the other.

The traveler says to the first builder, “What are you doing?”

He says, “Oh, I’m moving stones.”

He says to the second builder, “What are you doing?” 
He says, “I’m building a wall.”

He says to the third builder, “What are you doing?”

He says, “I’m building a cathedral.”

They’re all doing the same task but thinking about it in different ways. Maybe that’s what we need to do. Forget about labels, metaphors, architecture, engineer, building, whatever. Just think about what a privilege it is to be doing this, to embrace the fact that we are the builders. We are the bricklayers.

Today, for example, we’re going to hear from quite an amazing collection of bricklayers that I’m really looking forward to hearing from. I want to hear what they’re building. I want to hear their stories of how they built it, why they built it.

But to do that, I need to stop moving air over these vocal cords and flapping this fleshy piece of meat around in my mouth and just stop talking. Thank you for listening.

Monday, January 20th, 2020

Unity

It’s official. Microsoft’s Edge browser is running on the Blink rendering engine and it’s available now.

Just over a year ago, I wrote about my feelings on this decision:

I’m sure the decision makes sound business sense for Microsoft, but it’s not good for the health of the web.

The importance of browser engine diversity is beautifully illustrated (literally) in Rachel’s The Ecological Impact of Browser Diversity.

But I was chatting to Amber the other day, and I mentioned how I can see the theoretical justification for Microsoft’s decision …even if I don’t quite buy it myself.

Picture, if you will, something I’ll call the bar of unity. It’s a measurement of how much collaboration is happening between browser makers.

In the early days of the web, the bar of unity was very low indeed. The two main browser vendors—Microsoft and Netscape—not only weren’t collaborating, they were actively splintering the languages of the web. One of them would invent a new HTML element, and the other would invent a completely different element to do the same thing (remember abbr and acronym). One of them would come up with one model for interacting with a document through JavaScript, and the other would come up with a completely different model to the same thing (remember document.all and document.layers).

There wasn’t enough collaboration. Our collective anger at this situation led directly to the creation of The Web Standards Project.

Eventually, those companies did start collaborating on standards at the W3C. The bar of unity was raised.

This has been the situation for most of the web’s history. Different browser makers agreed on standards, but went their own separate ways on implementation. That’s where they drew the line.

Now that line is being redrawn. The bar of unity is being raised. Now, a number of separate browser makers—Google, Samsung, Microsoft—not only collaborate on standards but also on implementation, sharing a codebase.

The bar of unity isn’t right at the top. Browsers can still differentiate in their user interfaces. Edge, for example, can—and does—offer very sensible defaults for blocking trackers. That’s much harder for Chrome to do, given that Google are amongst the worst offenders.

So these browsers are still competing, but the competition is no longer happening at the level of the rendering engine.

I can see how this looks like a positive development. In fact, from this point of view, Mozilla are getting in the way of progress by having a separate codebase (yes, this is a genuinely-held opinion by some people).

On the face of it, more unity sounds good. It sounds like more collaboration. More cooperation.

But then I think of situations where complete unity isn’t necessarily a good thing. Take political systems, for example. If you have hundreds of different political parties, that’s not ideal. But if you only have one political party, that’s very bad indeed!

There’s a sweet spot somewhere in between where there’s a base of level of agreement and cooperation, but there’s also plenty of room for disagreement and opposition. Right now, the browser landscape is just about still in that sweet spot. It’s like a two-party system where one party has a crushing majority. Checks and balances exist, but they’re in peril.

Firefox is one of the last remaining representatives offering an alternative. The least we can do is support it.

Thursday, January 16th, 2020

Indie Web Camp London 2020

Do you have plans for the weekend of March 14th and 15th?

If you live anywhere near London, might I suggest that you sign up for Indie Web Camp.

Cheuk and Ana are putting it together with assistance from Calum. As always, there will be one day of Barcamp-style discussions, followed by a fun hands-on day of making.

If you’re wondering whether this is for you, ask yourself if any of this situations apply:

  • You don’t have your own website yet, but you want one.
  • You have your own website, but you need some help with it.
  • You have some ideas about the independent web.
  • You have your own website but you never seem to find the time to update it.
  • You’d like to help other people with their websites.

If you recognise yourself in any one of those scenarios, then you should definitely come along to Indie Web Camp London 2020!

Friday, January 10th, 2020

Install prompt

There’s an interesting thread on Github about the tongue-twistingly named beforeinstallpromt JavaScript event.

Let me back up…

Progressive web apps. You know what they are, right? They’re websites that have taken their vitamins. Specifically, they’re responsive websites that:

  1. are served over HTTPS,
  2. have a web app manifest, and
  3. have a service worker handling the offline scenario.

The web app manifest—a JSON file of metadata—is particularly useful for describing how your site should behave if someone adds it to their home screen. You can specify what icon should be used. You can specify whether the site should launch in a browser or as a standalone app (practically indistinguishable from a native app). You can specify which URL on the site should be used as the starting point when the site is launched from the home screen.

So progressive web apps work just fine when you visit them in a browser, but they really shine when you add them to your home screen. It seems like pretty much everyone is in agreement that adding a progressive web app to your home screen shouldn’t be an onerous task. But how does the browser let the user know that it might be a good idea to “install” the web site they’re looking at?

The Samsung Internet browser does ambient badging—a + symbol shows up to indicate that a website can be installed. This is a great approach!

I hope that Chrome on Android will also use ambient badging at some point. To start with though, Chrome notified users that a site was installable by popping up a notification at the bottom of the screen. I think these might be called “toasts”.

Getting the “add to home screen” prompt for https://huffduffer.com/ on Android Chrome. And there’s the “add to home screen” prompt for https://html5forwebdesigners.com/ HTTPS + manifest.json + Service Worker = “Add to Home Screen” prompt. Add to home screen.

Needless to say, the toast notification wasn’t very effective. That’s because we web designers and developers have spent years teaching people to immediately dismiss those notifications without even reading them. Accept our cookies! Sign up to our newsletter! Install our native app! Just about anything that’s user-hostile gets put in a notification (either a toast or an overlay) and shoved straight in the user’s face before they’ve even had time to start reading the content they came for in the first place. Users will then either:

  1. turn around and leave, or
  2. use muscle memory reach for that X in the corner of the notification.

A tiny fraction of users might actually click on the call to action, possibly by mistake.

Chrome didn’t abandon the toast notification for progressive web apps, but it did change when they would appear. Rather than the browser deciding when to show the prompt—usually when the user has just arrived on the site—a new JavaScript event called beforeinstallprompt can be used.

It’s a bit weird though. You have to “capture” the event that fires when the prompt would have normally been shown, subdue it, hold on to that event, and then re-release it when you think it should be shown (like when the user has completed a transaction, for example, and having your site on the home screen would genuinely be useful). That’s a lot of hoops. Here’s the code I use on The Session to only show the installation prompt to users who are logged in.

The end result is that the user is still shown a toast notification, but at least this time it’s the site owner who has decided when it will be shown. The Chrome team call this notification “the mini-info bar”, and Pete acknowledges that it’s not ideal:

The mini-infobar is an interim experience for Chrome on Android as we work towards creating a consistent experience across all platforms that includes an install button into the omnibox.

I think “an install button in the omnibox” means ambient badging in the browser interface, which would be great!

Anyway, back to that thread on Github. Basically, neither Apple nor Mozilla are going to implement the beforeinstallprompt event (well, technically Mozilla have implemented it but they’re not going to ship it). That’s fair enough. It’s an interim solution that’s not ideal for all reasons I’ve already covered.

But there’s a lot of pushback. Even if the details of beforeinstallprompt are troublesome, surely there should be some way for site owners to let users know that can—or should—install a progressive web app? As a site owner, I have a lot of sympathy for that viewpoint. But I also understand the security and usability issues that can arise from bad actors abusing this mechanism.

Still, I have to hand it to Chrome: even if we put the beforeinstallprompt event to one side, the browser still has a mechanism for letting users know that a progressive web app can be installed—the mini info bar. It’s not a great mechanism, but it’s better than nothing. Nothing is precisely what Firefox and Safari currently offer (though Firefox is experimenting with something).

In the case of Safari, not only do they not provide a mechanism for letting the user know that a site can be installed, but since the last iOS update, they’ve buried the “add to home screen” option even deeper in the “sharing sheet” (the list of options that comes up when you press the incomprehensible rectangle-with-arrow-emerging-from-it icon). You now have to scroll below the fold just to find the “add to home screen” option.

So while I totally get the misgivings about beforeinstallprompt, I feel that a constructive alternative wouldn’t go amiss.

And that’s all I have to say about that.

Except… there’s another interesting angle to that Github thread. There’s talk of allowing sites that are launched from the home screen to have access to more features than a site inside a web browser. Usually permissions on the web are explicitly granted or denied on a case-by-case basis: geolocation; notifications; camera access, etc. I think this is the first time I’ve heard of one action—adding to the home screen—being used as a proxy for implicitly granting more access. Very interesting. Although that idea seems to be roundly rejected here:

A key argument for using installation in this manner is that some APIs are simply so powerful that the drive-by web should not be able to ask for them. However, this document takes the position that installation alone as a restriction is undesirable.

Then again:

I understand that Chromium or Google may hold such a position but Apple’s WebKit team may not necessarily agree with such a position.

Monday, January 6th, 2020

Browser defaults

I’ve been thinking about some of the default behaviours that are built into web browsers.

First off, there’s the decision that a browser makes if you enter a web address without a protocol. Let’s say you type in example.com without specifying whether you’re looking for http://example.com or https://example.com.

Browsers default to HTTP rather than HTTPS. Given that HTTP is older than HTTPS that makes sense. But given that there’s been such a push for TLS on the web, and the huge increase in sites served over HTTPS, I wonder if it’s time to reconsider that default?

Most websites that are served over HTTPS have an automatic redirect from HTTP to HTTPS (enforced with HSTS). There’s an ever so slight performance hit from that, at least for the very first visit. If, when no protocol is specified, browsers were to attempt to reach the HTTPS port first, we’d get a little bit of a speed improvement.

But would that break any existing behaviour? I don’t know. I guess there would be a bit of a performance hit in the other direction. That is, the browser would try HTTPS first, and when that doesn’t exist, go for HTTP. Sites served only over HTTP would suffer that little bit of lag.

Whatever the default behaviour, some sites are going to pay that performance penalty. Right now it’s being paid by sites that are served over HTTPS.

Here’s another browser default that Rob mentioned recently: the viewport meta tag:

I thought I might be able to get away with omitting meta name="viewport". Apparently not! Maybe someday.

This all goes back to the default behaviour of Mobile Safari when the iPhone was first released. Most sites wouldn’t display correctly if one pixel were treated as one pixel. That’s because most sites were built with the assumption that they would be viewed on monitors rather than phones. Only weirdos like me were building sites without that assumption.

So the default behaviour in Mobile Safari is assume a page width of 1024 pixels, and then shrink that down to fit on the screen …unless the developer over-rides that behaviour with a viewport meta tag. That default behaviour was adopted by other mobile browsers. I think it’s a universal default.

But the web has changed since the iPhone was released in 2007. Responsive design has swept the web. What would happen if mobile browsers were to assume width=device-width?

The viewport meta element always felt like a (proprietary) band-aid rather than a long-term solution—for one thing, it’s the kind of presentational information that belongs in CSS rather than HTML. It would be nice if we could bid it farewell.

Thursday, January 2nd, 2020

The Rise Of Skywalker

If you haven’t seen The Rise Of Skywalker, avert your gaze for I shall be revealing spoilers here…

I wrote about what I thought of The Force Awakens. I wrote about what I thought of The Last Jedi. It was inevitable that I was also going to write about what I think of The Rise Of Skywalker. If nothing else, I really enjoy going back and reading those older posts and reminding myself of my feelings at the time.

I went to a midnight screening with Jessica after we had both spent the evening playing Irish music at our local session. I was asking a lot of my bladder.

I have to admit that my first reaction was …ambivalent. I didn’t hate it but I didn’t love it either.

Now, if that sounds familiar, it’s because that’s pretty much what I said about Rogue One and The Last Jedi:

Maybe I just find it hard to really get into the flow when I’m seeing a new Star Wars film for the very first time.

This time there were very specific things that I could point to and say “I don’t like it!” For a start, there’s the return of Palpatine.

I think the Emperor has always been one of the dullest characters in Star Wars. Even in Return Of The Jedi, he just comes across as a paper-thin one-dimensional villain who’s evil just because he’s evil. That works great when he’s behind the scenes manipulating events, but it makes for dull on-screen shenanigans, in my opinion. The pantomime nature of Emperor Palpatine seems more Harry Potter than Star Wars to me.

When I heard the Emperor was returning, my expectations sank. To be fair though, I think it was a very good move not to make the return of Palpatine a surprise. I had months—ever since the release of the first teaser trailer—to come to terms with it. Putting it in the opening crawl and the first scene says, “Look, he’s back. Don’t ask how, just live with it.” That’s fair enough.

So in the end, the thing that I thought would bug me—the return of Palpatine—didn’t trouble me much. But what really bugged me was the unravelling of one of my favourite innovations in The Last Jedi regarding Rey’s provenance. I wrote at the time:

I had resigned myself to the inevitable reveal that would tie her heritage into an existing lineage. What an absolute joy, then, that The Force is finally returned into everyone’s hands!

What bothered me wasn’t so much that The Rise Of Skywalker undoes this, but that the undoing is so uneccessary. The plot would have worked just as well without the revelation that Rey is a Palpatine. If that revelation were crucial to the story, I would go with it, but it just felt like making A Big Reveal for the sake of making A Big Reveal. It felt …cheap.

I have to say, that’s how I responded to a lot of the kitchen sink elements in this film when I first saw it. It was trying really, really hard to please, and yet many of the decisions felt somewhat lazy to me. There were times when it felt like a checklist.

In a way, there was a checklist, or at least a brief. JJ Abrams has spoken about how this film needed to not just wrap up one trilogy, but all nine films. But did it though? I think I would’ve been happier if it had kept its scope within the bounds of these new sequels.

That’s been a recurring theme for me with all three of these films. I think they work best when they’re about the new characters. I’m totally invested in them. Leaning on nostalgia and the cultural memory of the previous films and their characters just isn’t needed. I would’ve been fine if Luke, Han, and Leia never showed up on screen in this trilogy—that’s how much I’m sold on Rey, Finn, and Poe.

But I get it. The brief here is to tie everything together. And as JJ Abrams has said, there was no way he was going to please everyone. But it’s strange that he would attempt to please the most toxic people clamouring for change. I’m talking about the racists and misogynists that were upset by The Last Jedi. The sidelining of Rose Tico in The Rise Of Skywalker sure reads a lot like a victory for them. Frankly, that’s the one aspect of this film that I’m always going to find disappointing.

Because it turns out that a lot of the other things that I was initially disappointed by evaporated upon second viewing.

Now, I totally get that a film needs to work for a first viewing. But if any category of film needs to stand up to repeat viewing, it’s a Star Wars film. In the case of The Rise Of Skywalker, I think that repeat viewing might have been prioritised. And I’m okay with that.

Take the ridiculously frenetic pace of the multiple maguffin-led plotlines. On first viewing, it felt rushed and messy. I got the feeling that the double-time pacing was there to brush over any inconsistencies that would reveal themselves if the film were to pause even for a minute to catch its breath.

But that wasn’t the case. On second viewing, things clicked together much more tightly. It felt much more like a well-oiled—if somewhat frenetic—machine rather than a cobbled-together Heath Robinson contraption that might collapse at any moment.

My personal experience of viewing the film for the second time was a lot of fun. I was with my friend Sammy, who is not yet a teenager. His enjoyment was infectious.

At the end, after we see Rey choose her new family name, Sammy said “I knew she was going to say Skywalker!”

“I guess that explains the title”, I said. “The Rise Of Skywalker.”

“Or”, said Sammy, “it could be talking about Ben Solo.”

I hadn’t thought of that.

When I first saw The Rise Of Skywalker, I was disappointed by all the ways it was walking back the audacious decisions made in The Last Jedi, particularly Rey’s parentage and the genetic component to The Force. But on second viewing, I noticed the ways that this film built on the previous one. Finn’s blossoming sensitivity keeps the democratisation of The Force on the table. And the mind-melding connection between Rey and Kylo Ren that started in The Last Jedi is crucial for the plot of The Rise Of Skywalker.

Once I was able to get over the decisions I didn’t agree with, I was able to judge the film on its own merits. And you know what? It’s really good!

On the technical level, it was always bound to be good, but I mean on an emotional level too. If I go with it, then I’m rewarded with a rollercoaster ride of emotions. There were moments when I welled up (they mostly involved Chewbacca: Chewie’s reaction to Leia’s death; Chewie getting the medal …the only moment that might have topped those was Han Solo’s “I know”).

So just in case there’s any doubt—given all the criticisms I’ve enumerated—let me clear: I like this film. I very much look forward to seeing it again (and again).

But I do think there’s some truth to what Eric says here:

A friend’s review of “The Rise of Skywalker”, which also serves as a perfect summary of JJ Abrams’ career: “A very well-executed lack of creativity.”

I think I might substitute the word “personality” for “creativity”. However you feel about The Last Jedi, there’s no denying that it embodies the vision of one person:

I think the reason why The Last Jedi works so well is that Rian Johnson makes no concessions to my childhood, or anyone else’s. This is his film. Of all the millions of us who were transported by this universe as children, only he gets to put his story onto the screen and into the saga. There are two ways to react to this. You can quite correctly exclaim “That’s not how I would do it!”, or you can go with it …even if that means letting go of some deeply-held feelings about what could’ve, should’ve, would’ve happened if it were our story.

JJ Abrams, on the other hand, has done his utmost to please us. I admire that, but I feel it comes at a price. The storytelling isn’t safe exactly, but it’s far from personal.

The result is that The Rise Of Skywalker is supremely entertaining—especially on repeat viewing—and it has a big heart. I just wish it had more guts.

Wednesday, January 1st, 2020

2019

So that was 2019. Quite a year.

Looking back, there were some real highlights for me…

Then there were the usual benefits that come with speaking at international conferences like An Event Apart and Beyond Tellerrand. I got to visit interesting places, eat excellent food, and meet good people.

Not everything was rosy. There were some sad life events for friends and family. And of course the whole political situation here in the UK has been just awful in 2019.

So onwards to 2020. I need to remind myself that many things are going well in the world but it can be hard to keep that in mind. At a local—nay, parochial—level, there’s a good chance that 2020 will deliver a hard Brexit. I have no faith in the competence or motivations of the current government to do otherwise (I keep reminding myself that I don’t have to stay in this country if it falls apart). And at the global scale, our attempts to mitigate the climate crisis are proceeding too slowly.

That’s something I need to take more personal responsibility for in 2020: fewer plane journeys, more trains, and more carbon offsetting.

Ultimately, it’s a fairly arbitrary moment in time but I do like to pause for a moment and look back at the year that’s just been. For all its faults, I have happy memories. I’m healthy. I played lots of music. I ate well. I spent time with friends and family.

I look forward to more of that in the third decade of the 21st century.

Tuesday, December 31st, 2019

2019 in numbers

I posted to adactio.com 1,600 times in 2019: sparkline

In amongst those notes were:

If you like, you can watch all that activity plotted on a map.

map

Away from this website in 2019:

Books I read in 2019

I read 26 books in 2019. That’s not as many as I’d like, but it is an increase on 2018.

Once again, I tried to maintain a balance between fiction and non-fiction. It kinda worked.

Here, in order of reading, are the books I read in 2019. For calibration, anything with three stars or more means I enjoyed (and recommend) the book. I can be pretty stingy with my stars. That said…

Kindred by Octavia Butler

★★★★★

Kindred is a truly remarkable work. Technically it’s science fiction—time travel, specifically—but that’s really just the surface detail. This is a study of what makes us human, and an investigation into the uncomfortable reach of circumstance and culture. Superbly written and deeply empathic.

The Soul Of A New Machine by Tracy Kidder

★★☆☆☆

This is a well-regarded book amongst people whose opinion I value. It’s also a Pulitzer prize winner. Strange, then, that I found it so unengaging. The prose is certainly written with gusto, but it all seems so very superficial to me. No matter how you dress it up, it’s a chronicle of a bunch of guys—and oh, boy, are they guys—making a commercial computer. Testosterone and solder—not my cup of tea.

Binti by Nnedi Okorafor

★★★☆☆

A thoroughly entertaining space adventure, although my favourite parts are the descriptions of the inner magic of mathematics. This is a short read too, so go ahead and give it a whirl. Recommended.

The Order Of Time by Carlo Rovelli

★★★☆☆

The writing is entertaining, sometimes arresting, though it definitely spills over into purple prose at times. As a meditation on the nature of time, it’s a thought-provoking read, but I think I prefer the gentler musings of James Gleick’s Time Travel: A History.

Lincoln in the Bardo by George Saunders

★★☆☆☆

Another highly-regarded book that I just couldn’t get into. That’s probably more down to me than the book. I can see how the writing is imaginative and immersive, but the end result—for me, at least—was no more than perfectly fine.

Reading this kind of reminded me of reading David Mitchell’s Cloud Atlas. They’re both perfectly fine books that were lavished with heaps of praise for their levels of imagination …which makes me think that people need to read more sci-fi and fantasy.

A Mind At Play: How Claude Shannon Invented The Information Age by Jimmy Soni and Rob Goodman

★★★★☆

A terrific biography! Admittedly you’ll probably want to be interested in information theory in the first place, but how could you not?

This book could probably have been a little shorter without losing too much, but I thoroughly enjoyed reading it. It’s a great companion to James Gleick’s The Information.

Mr. Penumbra’s 24-Hour Bookstore by Robin Sloan

★★★☆☆

This is like the love child of Craig Mod and Umberto Eco …and I mean that in the nicest possible way. A thoroughly entertaining genre-crossing jaunt that isn’t going to stress you out. Fun!

Inferior: The True Power Of Women and the Science that Shows It by Angela Saini

★★★☆☆

Superbly researched and deftly crafted. This is an eye-opening journey into the cultural influences on experimental science.

Resilient Management by Lara Hogan

★★★★☆

I’m getting kind of cross with Lara now. First she writes the definitive book on web performance. Then she writes the definitive book on public speaking (I’ve loaned it out so many times, I’ve lost track of it). Now she’s gone and written the definitive book on being a manager. It hardly seems fair!

Seriously, this book is remarkably practical, right from the get-go. And the one complaint I have about most management books—that they’re longer than they need to be—definitely doesn’t apply here. If your job involves managing humans in any way, read this book!

The Future Home Of The Living God by Louise Erdrich

★★☆☆☆

There’s nothing wrong with this book, per se. But I think it’s situated too much in the shadow of Margaret Atwood’s The Handmaid’s Tale to stand on its own merits.

Binti Home by Nnedi Okorafor

★★★☆☆

The second novella in the Binti series. Just as much fun as the first. I’m looking forward to reading the third and final book in the series.

Other Minds: The Octopus, the Sea, and the Deep Origins of Consciousness by Peter Godfrey-Smith

★★★☆☆

I really enjoyed this evolutionary tale. It’s equal parts biology and philosophy. I will never look at cephalopods quite the same way again.

Sourdough by Robin Sloan

★★★☆☆

Just as entertaining as Robin’s first book, this has a fun vibe to it.

By pure coincidence, I followed Sourdough with…

I Contain Multitudes: The Microbes Within Us and a Grander View of Life by Ed Yong

★★★★☆

I wrote:

There’s a lovely resonance in reading @RobinSloan’s Sourdough back to back with @EdYong209’s I Contain Multitudes. One’s fiction, one’s non-fiction, but they’re both microbepunk.

To which Robin responded:

OMG I’m so glad these books presented themselves to you together—I think it’s a great pairing, too. And certainly, some of Ed’s writing about microbes was in my head as I was writing the novel!

I Contain Multitudes is a thoroughly engaging and entertaining work. You might not think you want to read a book all about microbes, but trust me, you do.

I stand by this appraisal:

They’re both such wonderful books—apart from the obvious microbial connection, there’s a refreshingly uncynical joy infusing the writing of each of them!

Rosewater by Tade Thompson

★★★☆☆

An first-contact novel with a difference. The setting, the characters, the writing—everything is vivid and immersive. I’m looking forward to reading more in this series.

Skyfaring by Mark Vanhoenacker

★★★☆☆

The sheer joy of the writing is infectious. If you’ve got some long-haul flights ahead of you, this is the perfect reading material.

The Raven Tower by Ann Leckie

★★★★☆

This has stayed with me. This is Ann Leckie’s first foray into more of a fantasy realm, and it’s just as great as her superb science fiction.

Internal consistency is key to world-building in works of fantasy, and this book has a deeply satisfying and believable system that is only gradually and partially revealed. Encore!

The Science of Storytelling by Will Storr

★★★☆☆

This book has an unusual structure. At times, it’s like a masterclass in writing. At other times, it’s deeply personal. I don’t know quite how to classify it, but I like it!

Exhalation by Ted Chiang

★★★★☆

Brilliant, as expected. Some of the stories in here have stayed with me long after I finished reading them. If you haven’t already read this or Stories of Your Life and Others, you’re in for a real treat.

Is Exhalation quite as brilliant as Ted Chiang’s debut book of short stories? Maybe not. But that bar is so high as to be astronomical.

Now we just have to wait a few more decades for his third collection.

Motherfoclóir: Dispatches From A Not So Dead Language by Darach O’Séaghdha

★★★☆☆

I don’t know if this will be of any interest if you don’t already understand some Irish, but I found this to be good fun. There were times when an aside was repeated more than once, which made me wonder if the source material was originally scattered in other publications.

The Calculating Stars by Mary Robinette Kowal

★★★☆☆

An alternative history novel with a thought-provoking premise. The result is like a cross between Mercury 13 and Seveneves. There’s a dollop of wish fulfillment in here that feels like a guilty pleasure, but that’s no bad thing.

1666: Plague, War, and Hellfire by Rebecca Rideal

★★★☆☆

This is how you bring history to life! The style of writing feels much more like a historical novel than a dry academic work, but all of the events are relayed from contempary source material. The plague is suitably grim and disgusting; the sea battles are appropriately thrilling and frightening; the fire is unrelentingly devestating. I know that doesn’t sound like there’s much enjoyment to be had, but this is the best history book I’ve read in a while.

Helliconia Summer by Brian Aldiss

★★★☆☆

I know I joke about seeing pace layers everywhere but seriously, Brian Aldiss’s Heliconia series is all about pace layers. Each book deals with one point in time, where we’re concerned with the dynastic concerns of years and decades, but the really important story is happening on the scale of centuries and millennia as the seasons slowly change.

This one was just as good as Helliconia Spring and I’m looking forward to rounding out the series with Helliconia Winter.

The Canopy Of Time by Brian Aldiss

★★☆☆☆

I decided to stay on a Brian Aldiss kick, and grabbed this pulpy collection of short stories. It’s not his best work, and there’s an unnecessary attempt to tie all the stories together into one narrative, but even a so-so Brian Aldiss book has got a weird and slightly haunting edge to it.

The Fated Sky by Mary Robinette Kowal

★★★☆☆

The sequel to The Calculating Stars and the last in the Lady Astronaut series. Good space-race entertainment.

Raven Stratagem by Yoon Ha Lee

I’ve just picked up this sequel to Ninefox Gambit. So far it’s not as bewildering as the first book—where the bewilderment was part of its charm. I’m into it. But I won’t rate it till I’ve finished it.


Alright, time to pick my favourite fiction and non-fiction books of the year.

Certainly the best fiction book published this year was Ted Chiang’s Exhalation. But when it comes to the best book I’ve read this year, it’s got to be Octavia Butler’s Kindred. Hard to believe it’s forty years old—it’s shockingly relevant today.

As for the best non-fiction …this is really hard this year. So many great books: A Mind At Play, Inferior, 1666, Other Minds; I loved them all. But I think I’m going to have to give it to Ed Yong’s I Contain Multitudes.

Only 10 of the 26 books I read this year were by women. I need to work on redressing the balance in 2020.

Monday, December 30th, 2019

Words I wrote in 2019

I wrote just over one hundred blog posts in 2019. That’s even more than I wrote in 2018, which I’m very happy with.

Here are eight posts from during the year that I think are a good representative sample. I like how these turned out.

I hope that I’ll write as many blog posts in 2020.

I’m pretty sure that I will also continue to refer to them as blog posts, not blogs. I may be the last holdout of this nomenclature in 2020. I never planned to die on this hill, but here we are.

Actually, seeing as this is technically my journal rather than my blog, I’ll just call them journal entries.

Here’s to another year of journal entries.

Sunday, December 22nd, 2019

The modern web is becoming an unusable, user-hostile wasteland

If you add another advertisement to your pages, you generate more revenue. If you track your users better, now you can deliver tailored ads and your conversion rates are higher. If you restrict users from leaving your walled garden ecosystem, now you get all the juice from whatever attention they have.

The question is: At which point do we reach the breaking point?

And I think the answer is: We are very close.

Facebook. Twitter. Medium. All desparate to withhold content they didn’t even create until you cough up your personal details.

Friday, December 20th, 2019

The Layers Of The Web

The opening presentation from the Beyond Tellerrand conference held in Berlin in November 2019.

Guten Morgen. All right. I’m just going to get started because I’ve got a lot to talk about and I’m very, very excited to be here.

I’m excited to talk about the web. I’ve been thinking a lot about the web. You know, I think a lot about the web all the time, but this year, in particular, thinking about where the web came from; asking myself where the web came from, which is kind of a dumb question because it’s pretty obvious where the web came from.

It came from this guy. This is Tim Berners-Lee and he is the creator of the World Wide Web. It was 30 years ago, March 1989, that he wrote a proposal while he was at CERN, a very dull-looking proposal called “Information Management: A Proposal” that had incomprehensible diagrams trying to explain what he had in mind. But a supervisor, Mike Sendall, saw the potential and scrawled across the top, “Vague but exciting.”

Tim Berners-Lee starts working on this idea he has for a global hypertext system and he starts creating the world’s first web browser and the world’s first web server, which is this NeXT machine which is in the Science Museum in London, a lovely machine, the NeXT box.

I was in the neighbourhood so I just had to come by and say hello…

I have a great affection for it because, earlier this year, I was very honored to be invited to CERN, along with this bunch of hackers, to take part in a project related to the 30th anniversary of that proposal. I will show you a video that explains the project.

So, we came to CERN this week in order to create some sort of modern-day interpretation of the very first web browser.

—Kimberly Blessing

Well, the project is to restore the first browser which was developed by the inventor of the Web, and the idea is to create an experience for the people who could not use the web in its early days to have an idea how it felt to use the web at that time.

—Martin Akolo Chiteri

I think the biggest difficulty was to make the browser work in the NeXT machine that we had.

—Angela Ricci

We really needed to work with an original NeXT box in order to really understand what that experience was like in order to be able to write some code and replicate that experience.

—Kimberly Blessing

My role is code, so generating the code to create the interactive aspect of the World Wide web browser, recreated browser. It’s very much writing JavaScript to kind of create all the NeXT operating system UI, making requests to servers to go and get the HTML and massage the HTML back into a format that looks good in the World Wide Web browser; and making sure we end up with a URL that goes into production that someone can visit and see their own webpages. The tangible software is what I’m responsible for, so I have to make sure it all gets done. Otherwise, we have no browser to look at, basically.

—Remy Sharp

We got together a few years back to do a similar sort of hack project here at CERN which was creating the world’s second-ever web browser, which was the Line Mode browser. We had a lot of fun with it and it’s a great bunch of people from all over the world. It’s been really great to get back together and it’s always amazing to be here at CERN, to be at not just the birthplace of the Web, but the most important place on the planet for science.

Yeah, it’s been a lot of fun. I kind of don’t want it to be over because we are in our element, hacking away, having fun, and just soaking up the atmosphere, and we are getting to chat with people who were there 30 years ago, Jean-Francois Groff and Robert Cailliau, these people who were involved in the creation of the World Wide web. To me, that’s amazing to be surrounded by so much World Wide Web history.

The plan is that this will go online and anyone will be able to access it because it’s on the web, and that’s the beautiful thing about the web is that anyone can visit a website, and so everyone will have the opportunity to try using the world’s first web browser and see what modern webpages would look like if they were passed through this first web browser.

—Jeremy Keith

Well, spoiler alert. The project was a success and you can, indeed, look at your websites in a recreation of the first-ever web browser. This is the URL. It’s worldwideweb.cern.ch.

Success, that was good. But as you could probably tell from that video, Remy was the one basically making this all happen. He was the one writing the JavaScript to recreate this in a modern browser. This is the first-ever web page viewed in the first-ever web browser.

As you gathered, again, I was really fascinated by the history of the Web, like, where did it come from, and the people who were there at the time and getting to pick their brains. I spent most of my time working on the accompanying website to go with this project. I was creating this timeline.

Timeline

Because this was to mark the 30th anniversary of this proposal, I thought, well, we could easily look at what has happened in the last 30 years: websites, web servers, formats, standards - all that stuff. But I thought it would be fascinating to look at the previous 30 years as well and try and figure out the things that were happening that influenced Tim Berners-Lee in terms of hypertext, networks, computing, and all this stuff.

But I’d kind of had given myself this arbitrary cut-off point of 30 years to make this nice symmetry of it being the 30th anniversary of the World Wide Web. I could go further back. I could start asking, well, what happened before 30 years ago? What were the biggest influences on Tim Berners-Lee and the World Wide Web?

Now, if you were to ask Tim Berners-Lee himself who his biggest influencers were, he would give you a straight-up answer. He will say his biggest influencers were Conway Berners-Lee and Mary Lee Woods, his father and mother, which is fair enough. Normally, when you ask people who their influences are, they say, “Oh, my parents. They gave me a loving environment. They kindled my curiosity,” and all that stuff. I’m sure that’s true but, in this case, it was also a big influence in a practical sense in that both Mary and Conway worked on the Ferranti Mark 1. That’s where they met. They were programmers. Tim Berners-Lee’s parents were programmers on the Ferranti Mark 1, a very early computer. This is in the 1950s in Britain.

Okay, this feels like a good origin story for the web, right? They were working on this early computer.

But it’s an early computer; it’s not the first computer. Maybe I need to go back further. How far back do I go to find the first computer?

Time machine.

Is this the first computer, the Antikythera mechanism? You can see this in a museum in Athens. This was recovered from a shipwreck. It was recovered at the start of the 20th Century, but it dates back thousands of years, a mechanism for predicting the position of stars and planets. It does calculations. It is a calculating device. Not a programmable computer as such, though.

Worshipping the reliquary of Babbage’s brain

If you’re thinking about the origins of the idea of a programmable computer, I think we could start to look at this gentleman, Charles Babbage. This is half of Charles Babbage’s brain, which is in the Science Museum in London along with that original NeXT box that the World Wide web was created on. The other half is in the Computing History Museum in California.

Charles Babbage lived in the 19th Century, and kind of got a lot of seed funding from the U.K. government to build a device, the Difference Engine, which would do calculations. Later on, he scrapped that and started working on the Analytical Engine which would be even better — a 2.0 version. It never got finished, by the way, but it was a really amazing idea because you could see the architecture of like a central processing unit, but it was still fundamentally a calculator, a calculating machine.

The breakthrough in terms of programming maybe came from Charles Babbage’s collaborator. This is Ada Lovelace. She was translating documents by an Italian mathematician about Difference Engines and calculations. She realized that—hang on—if we’re doing operations on numbers, what if those numbers could stand for other concepts, non-numerical like words or thoughts? Then we could do operations on things other than numbers, which is exactly what we do today in modern computing.

If you use a word processor, you’re not processing words; you’re operating on ones and zeros. If you use a graphics program, you’re not actually moving pixels around; you’re operating on ones and zeroes. This idea of how anything could stand in for ones and zeros for numbers kind of started with Ada Lovelace.

But, as I said, the Difference Engine and the Analytical Engine, they never got finished, and this was kind of a dead-end. It turns out, they weren’t an influence.

Later on, for example, this genius who was definitely responsible for the first working computers, Alan Turing, he wasn’t aware of the work of Babbage and Lovelace, which is a shame. He was kind of working in isolation.

He came up with the idea of the universal machine, the Turing Machine. Give it an infinitely long tape and enough state, enough time, you could calculate literally anything, which is pretty much what computers are.

He was working at Bletchley Park breaking the code for the Enigma machines, and that leads to the creation of what I think would be the first programmable computer. This is Colossus at Bletchley Park. This was created by a colleague of Turing, Tommy Flowers.

It is programmable. It’s using valves, but it’s absolutely programmable. It was top secret, so even for years after the war, this was not known about. In the history books, even to this day, you’ll often see ENIAC listed as the first programmable computer, but I think that honor goes to Tommy Flowers and Colossus.

By the way, Alan Turing, after the war, after 1945, he did go on to work and keep on working in the field of computing. In fact, he worked as a consultant at Ferranti. He was working on the Ferranti Mark 1, the same computer where Tim Berners-Lee’s parents met when they were programmers.

As I say, that was after the war ended in 1945. Now, we can’t say that the work at Bletchley Park was responsible for winning the war, but we could probably say that it’s certainly responsible for shortening the war. If it weren’t for the work done by the codebreakers at Bletchley Park, the war might not have finished in 1945.

1945 is the year that this gentleman wrote a piece that was certainly influential on Tim Berners-Lee. This is Vannevar Bush, a scientist, a thinker. In 1945, he published a piece in the Atlantic Monthly under the heading, “A Scientist Looks at Tomorrow,” he publishes, “As We May Think.”

In this piece, he describes an imaginary device. It’s a mechanical device inside a desk, and the operator is allowed to work on reams and reams of microfilm and to connect ideas together, make these associative trails. This is kind of like hypertext before the word hypertext has been coined. Vannevar Bush calls this device the Memex. That’s published in 1945.

Memex

Also, in 1945, this young man has been drafted into the U.S. Navy and he’s shipping out to the Pacific. His name is Douglas Engelbart. Literally as the ship is leaving the harbor to head to the Pacific, word comes through that the war is over.

Now, he still gets shipped out to the Pacific. He’s in the Philippines. But now, instead of fighting against the Japanese, he’s lounging around in a hut on stilts reading magazines and that’s where he reads “As We May Think,” by Vannevar Bush.

Fast-forward years later; he’s trying to decide what to do with his life other than settle down, get married, have a job, you know, that kind of thing. He thinks, “No, no, I want to make the world a better place.” He realizes that computers could be the way to do this if they could implement something very much like the Memex. Instead of a mechanical device, what if computers could create the Memex, this hypertext system? He devotes his life to this and effectively invents the field of Human Computer Interaction.

On December 9th, 1968, he demonstrates what he’s been working at. This is in San Francisco, and he demonstrates bitmap screens. He demonstrates real-time collaboration on documents, working hypertext …and also he invents the mouse for the demo.

We have a pointing device called a mouse, a standard keyboard, and a special key set we have here. And we are going to go for a picture down on our laboratory in Menlo Park and pipe it up. It’ll show you, from another point of view, more about how that mouse works.

Come in, Menlo Park. Okay, there’s Don Anders’ hand in Menlo Park. In a second, we’ll see the screen that he’s working and the way the tracking spot moves in conjunction with movements of that mouse. I don’t know why we call it a mouse sometimes. I apologize; it started that way and we never did change it.

—Douglas Engelbart

This was ground-breaking. The mother of all demos, it came to be known as. This was a big influence on Tim Berners-Lee.

At this point, we’ve entered the time cone of those 30 years before the proposal that Tim Berners-Lee made, which is good because this is the moment where I like to branch off from this timeline and sort of turn it around.

The question I’m sure nobody is asking—because you saw there was a video link-up there; Douglas Engelbart is in San Francisco, and he has a video link-up with Menlo Park to demonstrate real-time collaboration with computers—the question nobody is asking is, who is operating the video camera in Menlo Park?

Well, I’ll tell you the answer to that question that nobody is asking. The man operating the video camera in Menlo Park is this man. His name is Stuart Brand. Now, Stuart Brand has spent most of the ‘60s doing what you would do in the ‘60s; he was dropping acid. This was all kosher. This was before it was illegal.

He was on the Merry Pranksters bus with Ken Kesey and, on one particular acid trip, he literally saw the Earth curving away and realizing that, yeah, we’re all on one planet, man! And he started a campaign with badges called, “Why haven’t we seen a photograph of the whole Earth yet?” I like the “yet” part in there like it’s a conspiracy that we haven’t seen a photograph of the whole Earth.

He was kind of onto something here, realizing that seeing our planet as a whole planet from space could be a consciousness-changing thing much like LSD is a consciousness-changing thing. Sure enough, people did talk about the effect it had when we got photographs like Earthrise from Apollo 8, and he used those pictures when he published the Whole Earth Catalog, which was a series of books.

The Whole Earth Catalog was basically like Wikipedia before the internet. It was this big manual of how to do everything. The idea was, if you were running a commune, living in a commune, you needed to know about technology, and agriculture, and weather, and all the stuff, and you could find that in the Whole Earth Catalog.

He was quite an influential guy, Stuart Brand. You probably heard the Steve Jobs commencement speech where he quotes Stuart Brand, “Stay hungry, stay foolish,” all that stuff.

Stuart Brand also did a lot of writing. After Douglas Engelbart’s demo, he started to see that this computer thing was something else. He literally said computers are the new LSD, so he starts really investigating computing and computers.

He writes this great article in “Rolling Stone” magazine in 1972 about space war, one of the first games you could play on the screen. But he has a wide range of interests. He kind of kicked off the environmental movement in some ways.

At one point, he writes a book about architecture. He writes a book called “How Buildings Learn.” There’s a television series that goes with it as well. This is a classic book (the definition of a classic book being a book that everyone has heard of and nobody has read).

In this book, he starts looking at the work of a British architect called Frank Duffy. Frank Duffy has this idea about architecture he calls shearing layers. The way that Frank Duffy puts it is that a building, properly conceived, consists of several layers of longevity, so kind of different rates of change.

He diagrams this out in terms of a building, and you see that you’ve got the site that the building is on that’s moving at a geological timescale, right? That should be around for thousands of years, we would hope.

Then you’ve got the actual structure that could stand for centuries.

Then you get into the infrastructure inside. You know, the plumbing and all that, you probably want to swap out every few decades.

Basically, until you get down to the stuff inside a room, the furniture that you can move around on a daily basis. You’ve got all these timescales moving from fast to slow as you move inwards into the house.

What I find fascinating about this idea of these different layers as well is the way that each layer depends on the layer below. Like, you can’t have the structure of a building without first having a site to put it on. You can’t move furniture around inside a room until you’ve made the room using the walls and the doors, right? This idea of shearing layers is kind of fascinating, and we’re going to get back to it.

Something else that Stuart Brand went on to do; he was one of the co-founders of the Long Now Foundation. Anybody here part of the Long Now Foundation? Any members of the Long Now Foundation? Ah… It’s a great organization. It’s literally dedicated to long-term thinking. It was founded by Stuart Brand and Danny Hillis, the computer scientist, and Brian Eno, the musician and producer. Like I said, dedicated to long-term thinking. This is my membership card made out of a durable metal because it’s got to last for thousands of years.

If you go on the website of the Long Now Foundation, you’ll notice that the years are made up of five digits, so instead of 2019, it will be 02019. Well, you know, you’ve got to solve the Y10K problem. They’re dedicated to long-term thinking, to trying to think in the longer now.

Admiring the Clock Of The Long Now

One of the most famous projects is the clock of the Long Now. This is a clock that will tell time for 10,000 years. Brian Eno has done the chimes. They’re generative. It’ll never chime the same way twice. It chimes once a century. This is a scale model that’s in the Science Museum in London along with half of Charles Babbage’s brain and the original NeXT machine that Tim Berners-Lee created World Wide Web on.

This is just a scale model. The full-sized clock is going to be inside a mountain in west Texas. You’ll be able to visit it. It’ll be like a pilgrimage. Construction is underway. I hope to visit the clock one day.

Stuart Brand collected his thoughts. It’s a really fascinating project when you think about, how do you design something to last 10,000 years? How do you communicate over 10,000 years? One of those tricky design problems almost like the Voyager Golden Record or the Yucca Mountain waste disposal. How do you communicate to future generations? You can’t rely on language. You can’t rely on semiotics. Anyway, he collected a lot of his thoughts into this book called “The Clock of the Long Now,” subtitled “Time and Responsibility: The Ideas Behind the World’s Slowest Computer.” He’s thinking about time. That’s when he comes back to shearing layers and these different layers of rates of change; different layers of time.

Stuart Brand abstracts the idea of shearing layers into something called “pace layers.” What if it’s not just architecture? What if any kind of system has these different rates of change, these layers?

He diagrams this out in terms of the human species, so think of humans. We have these different layers that we operate at.

At the lowest, slowest level, there is our nature, literally, like what makes us human in terms of our DNA. That doesn’t change for tens of thousands of years. Physiologically, there’s no difference between a caveman and an astronaut, right?

Then you’ve got culture, which cumulates of centuries, and the tribal identities we have around things like nations, language, and things like that.

Governance, models of governance, so not governments but governance, as in the way we choose to run things, whether that’s a feudal society, or a monarchy, or representative democracy, right? Those things do change, but not too fast, hopefully.

Infrastructure: you’ve got to keep up with the times, you know? This needs to move at a faster pace, again.

Commerce: much more fast-moving. Commerce needs to — you’re getting into the faster timescales there.

Then he puts fashion at the top. By fashion, he means anything that is supposed to be new and exciting, so that includes pop music, for example. The whole idea with fashion is that it’s there to try stuff out and discard it very quickly.

“What about this?” “No.” “What about that?” “Try this.” “No, try that.”

The good stuff, the stuff that kind of sticks to the wall, will maybe find its way down to the longer-lasting layers. Maybe a really good pop song from fashion ends up becoming part of culture, over time.

Here’s the way that Stuart Brand describes pace layers. He says:

Fast learns; slow remembers. Fast proposals, and slow disposes. Fast is discontinuous; slow is continuous. Fast and small instructs slow and big by a crude innovation and by occasional revolution, but slow and big controls small and fast by constraint and constancy.

He says:

Fast gets all of our attention but slow has all the power.

Pace layers is one of those ideas that, once you see it, you can’t unsee it. You know when you want to make someone’s life a misery, you just teach them about typography. Now they can’t unsee all the terrible kerning in the world. I can’t unsee pace layers. I see them wherever I look.

Does anyone remember this book, UX designers in the room, “The Elements of User Experience,” by Jesse James Garrett? It’s old now. We’re going back in the way but, in it, he’s got this diagram about the different layers to a user experience. You’ve got the strategy below that finally ends up with an interface at the top.

I look at this, and I go, “Oh, right. It’s pace layers. It’s literally pace layers.” Each layer depending on the layer below, the slower layers at the bottom, the faster-moving things at the top.

With this mindset that pace layers are everywhere, I thought, “Can I map out the web in terms of pace layers, the technology stack of the web?” I’m going to give it a go.

At the lowest stack, the slowest moving, I would say there’s the internet itself, as in TCP/IP, the transmission control protocol, Internet protocol created by Bob Kahn and Vint Cerf in the ‘70s and pretty much unchanged since then, deliberately dumb, deliberately simple. All it does is move packets around. Pretty much unchanged.

On top of that, you get the other protocols that use TCP/IP, like in the case of the web, the hypertext transfer protocol. Now, this has changed over time. We now have HTTP/2. But it hasn’t been rapid change. It’s been gradual. Again, that kind of feels right. It feels good that HTTP isn’t constantly changing underneath us too much.

Then we serve up over HTTP are URLs. I wish that URLs were down here. I wish that URLs were everlasting, never changing. But, unfortunately, I must acknowledge that that’s not true. Links die. We have to really work hard to keep them alive. I think we should work hard to keep them alive.

What do you put at those URLs? At the simplest level, it’s supposed to be plain text. But this is the web, so let’s say structured text. This is going to be HTML, the hypertext markup language, which Tim Berners-Lee came up with when he created the World Wide Web. I say, “Came up with.” He basically stole it from SGML that scientists at CERN were already using and sprinkled in one or two new tags, as they were calling it back then.

There were maybe like 20-something tags in HTML when Tim Berners-Lee created the web. Now we’ve got over 100 elements, as we call them. But I feel like I’ve been able to keep up with the pace of change. I mean, the vast big kind of growth spurt with HTML was probably HTML5. That’s been a while back now. It’s definitely change that I can keep on top of.

Then we have CSS, the presentation layer. That feels like it’s been moving at a nice clip lately. I feel like we’ve been getting a lot of cool stuff in CSS, like Flexbox and Grid, and all this new stuff that browsers are shipping. Still, I feel like, yeah, yeah, this is good. It’s right that we get lots of CSS pretty rapidly. It’s not completely overwhelming.

Then there’s the JavaScript ecosystem. I specifically say the “JavaScript ecosystem” as opposed to the “JavaScript language” because the JavaScript language is being developed at a nice pace. I feel like it’s going at a good speed of standardization. But the ecosystem, the frameworks, the libraries, the build tools, all of that stuff, that feels like, “You know what? Try this. No, try that. What about this? What about that? Oh, you’re still using that framework? No, no, we stopped using that last week. Oh, you’re still using that build tool? No, no, no, that’s so … we’ve moved on.”

I find this very overwhelming. Can I get a show of hands of anybody else who feels overwhelmed by this rate of change? All right. Keep your hands up. Keep your hands up and just look around. I want you to see you are not alone. You are not alone.

But I tell you what; after mapping these layers out into the pace layer diagram, I realized, wait a minute. The JavaScript layer, the fashion layer, if you will, it’s supposed to be like that. It’s supposed to be trying stuff out. Throw this at the wall. No, throw that at the wall. How about this? How about that?

It’s true that the good stuff does stick. Like if I think back to the first uses of JavaScript—okay, I’m showing my age, but—when JavaScript first came along, we’d use it for things like image rollovers or form validation, right? These days, if I wanted to do an image rollover—you mouseover something and it changes its appearance—I wouldn’t use JavaScript. I’d use CSS because we’ve got :hover.

If I was doing a form validation, like, “Oh, has that field actually been filled in?” because it’s required and, “Does that field actually look like an email address?” because it’s supposed to be an email address, I wouldn’t even use JavaScript. I would use HTML; input type="email" required. Again, the good stuff moves down into the sort of slower layers. Fast learns; slow remembers.

The other thing I realized when I diagrammed this out was that, “Huh, this kind of maps to how I approach building on the web.” I pretty much take this for granted that it’s going to be on the Internet. There’s not much I can do about that. Then I start thinking about URLs like URL-first design, the information architecture of a site. I think it’s underrated. I think people should create a URL-first design. URL design, in general, I think it’s a really good place to start if you’re building a product or a service.

Then, about your content in terms of structure. What is the most important thing on this page? That should be an H1. Is this a paragraph? Is it a list? Thinking about the structure first and then going on to think about the appearance which is definitely the way you want to go if you’re making something responsive. Think about the structure first and then the appearance and all these different form factors.

Then finally, add in behavior with JavaScript. Whatever HTML and CSS can’t do, that’s what I will use JavaScript for to kind of enhance it from there.

This maps really nicely to how I personally approach building things on the web. But, it is a testament to the flexibility of the World Wide Web that, if you don’t want to build in this way, you don’t have to.

If you want, you could build like this. JavaScript is a really powerful language. If you wanted to do navigations and routing in JavaScript, you can. If you want to inject all your content into the page using JavaScript, you can. CSS in JS? You can. Right? I mean, this is pretty much the architecture of a single-page app. It’s on the internet and everything is in JavaScript. The internet is a delivery mechanism for a chunk of JavaScript that does everything: the markup, the CSS, the routing.

This isn’t how I approach building on the web. I kind of ask myself why this doesn’t feel quite right to me. I think it’s because of the way it kind of turns everything into a single point of failure, which is the JavaScript, rather than spreading out those points of failure. We’re on the Internet and, as long as the JavaScript runs okay, the user gets everything. It turns what you’re building into a binary proposition that either it doesn’t work at all or it works great. Those are your own two options.

Now I’ll point out that, in another medium, this would make complete sense. Like if you’re building a native app. If you build an iOS app and I’ve got an iOS device, I get 100% of what you’ve designed and built. But if you’re building an iOS app and I have an Android device, I get zero percent of what you’ve designed and built because you can’t install an iOS app on an Android device. Either it works great or it doesn’t work at all; 100% or zero percent.

The web doesn’t have to be like that. If you build in that layered way on the web, then maybe I don’t get 100% of what you’ve designed and built but I don’t get zero percent, either. I’ll get something somewhere along the way, hopefully, closer to working great. It goes from not working at all to just about working. It works fine and works well; it works great.

You’re building up these layers of experience, the idea being that nobody gets left behind. Everybody gets something regardless of their device, their network, their browser. Everyone is not going to get the same experience, but everybody gets something. That feels very true to the original sort of founding ideas of the web and it maps so nicely to our technical stack on the web, the fact that you can start to think about things like URLs-first and think about the structure, then the presentation, and then the behavior.

I’m not the only one who likes thinking in this layered kind of way when it comes to the web. I’m going to quote my friend Ethan Marcotte. He says:

I like designing in layers. I love looking at the design of a page, a pattern, whatever, and thinking about how it will change if, say, fonts aren’t available, or JavaScript doesn’t work, or someone doesn’t see the design as you or I might and is having the page read allowed to them.

That’s a really good point that when you build in the layered way, you’re building in the resilience that something can fall back to a layer a little further down.

This brings up something I’ve mentioned here before at Beyond Tellerrand, which is that, when we’re evaluating technologies, the question we tend to ask is, how well does it work? That’s an absolutely valid question. You’re about to try a new tool, a new framework, a new standard. You ask yourself; how well does it work?

I think the more important question to ask is:

How well does it fail?

What happens if that piece of technology fails? That’s why I like this layered approach because this fails really well. JavaScript’s no longer a single point of failure. Neither is CSS, frankly. If the CSS never loaded, the user still gets something.

Now, this brings up an idea, a principle that definitely influenced Tim Berners-Lee. It was at the heart of his design principles for the World Wide Web. It’s called the Principle of Least Power that states, “Choose the least powerful language suitable for a given purpose,” which sounds really counterintuitive. Why would I choose the least powerful language to do something?

It’s kind of down to the fact that there’s a trade-off. With power, you get a fragility, right? Maybe something that is really powerful isn’t as universal as something simpler. It makes sense to figure out the simplest technology you can use to achieve a task.

I’ll give an example from my friend Derek Featherstone. He says:

In the web front-end stack—HTML, CSS, JavaScript, and ARIA—if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works.

Again, he’s talking about the resilience you get by building in a layered way and choosing the least powerful technology.

It’s like a classic example being ARIA. The first rule of ARIA is, don’t use ARIA if you don’t have to. Rather than using a div and then adding the event handlers and the ARIA roles to make it look like a button, just use a button. Use the simpler technology lower in the stack.

Now, I get pushback on this because people will tell me, “Well, that’s fine if you’re building something simple, but I’m not building something simple. I’m building something complex.” Everyone likes to think they’re building something complex, right? Everyone is convinced they’re working on really hard things, which makes sense. That’s human nature.

If you’re at a cocktail party and someone says, “What do you do?” and you describe your work and they say, “Oh, okay. That sounds really easy,” you’d be offended, right?

If you’re at a party and someone says, “What do you do?” you describe your work and they go, “Wow, God, that sounds hard,” you’d be like, “Yeah! Yeah, it is hard. What I do is hard.”

I think we gravitate to this, especially when someone markets it as, “This is a serious tool for serious, complex sites.” I’m like, “That’s me. I’m working on a serious, complex site.”

I don’t think the reality is quite like that. Reality is just messier. There’s nothing quite that simple. Very few things are really that complex.

Everything kind of exists on this continuum somewhere along the way. Even the simplest website has some form of interaction, something appy about it.

Those are those other two terms people use when talking about simple and complex is website and web app, as if you can divide the entirety of the whole World Wide Web into two categories: websites and web apps.

Again, that just doesn’t make sense to me. I think the truth is, things are messier and schmooshier between this continuum of websites and web apps. I don’t get why we even need the separate word. It’s all web stuff.

Though, there is this newer term, “Progressive Web App,” that I kind of like.

Who has heard of Progressive Web Apps? All right.

Who thinks they have a good handle on what a Progressive Web App is?

Okay. See, that’s a lot fewer hands, which is totally understandable because, if you start googling, “What is a Progressive Web App?” you get these Zen-like articles. “It’s a state of mind.” “It’s about rich, native-like interactions, man.”

No. No, it’s not. Worse still, you read, “Oh, a Progressive Web App is a Single PageApp.” I was like, no, you’ve lost me there. No, it’s not. Or least it can be, but any website can be a Progressive Web App. You can elevate a website to be a Progressive Web App.

I don’t mean in some sort of Zen-like fashion. I mean using technologies, three particular technologies.

  1. You make sure that website is running HTTPS,
  2. you have a web app manifest that’s a JSON file with metadata, and
  3. you have a service worker that gets installed on the user’s device.

That’s it. These three technologies turn a website into a Progressive Web App — no mystery about it.

The tricky bit is that service worker part. It’s kind of a weird thing because it’s JavaScript but it’s JavaScript that gets installed on the user’s device and acts like a proxy. It intercepts network requests and can do different things like grab things from the cache instead of going to the network.

I’m not going to go into how it works because I’ve written plenty about that in this book “Going Offline,” so if you want to know the code, you can go read the book.

I will say that when I first came across service workers, it totally did my head in because this is my mental model of the web. We’ve got the stack of technologies that we’re building on top of, each layer depending on the layer below. Then service workers come along and say, “Well, actually, you could have a website like this,” where the lowest layer, the network, the Internet goes away and the website still works. Mind is blown!

It took me a while to get my head around that. The service worker file is on the user’s device and, if they’ve got no Internet connect, it can still make decisions and serve up something like a custom offline page.

Here’s a website I run called huffduffer.com. It’s for making your own podcast out of found sounds. If you’re offline or the website is down, which happens, and you visit Huffduffer, you get this offline page saying, “Sorry, you’re offline.” Not very useful, but it’s branded like the site, okay? It’s almost like the way you have a custom 404 page. Now you can have a custom offline page that matches your site. It’s a small thing, but it can be handy.

We ran this conference in Brighton for two years, Ampersand. It’s a web typography conference. That also has a very simple offline page that just says, “Sorry. You’re offline,” but then it has the bare minimum information you need about the conference like where is this conference happening; what time does it start?

You can imagine a restaurant website having this, an offline page that tells you, “Here is the address. Here are the opening hours.” I would like it if restaurant websites had that information when you’re online as well, but…

You can also have fun with this, like Trivago. Their site relies on search, so there’s not much you can do when you’re offline, so they give you a game to play, the offline maze to keep you entertained.

That’s kind of at the simplest level of what you could do, a custom offline page.

Then at the other level, I’ve written this book called “Resilient web Design.” A lot of the ideas I’m talking about here are in this book. The book is a website. You go to the website and you read the book. That’s it. It’s free. You just go to resilientwebdesign.com. I mean free. I don’t ask for your email address and I’m not tracking any information at all.

This is how it looks when you’re online, and then this is how it looks when you’re offline. It is exactly the same. In fact, the moment you visit the website, it basically downloads the whole book.

Now, that’s the extreme example. Most websites, you wouldn’t want to do that because you kind of want the HTML to be fresh. This is never going to get updated. I’m done with this so I’m totally fine with, you go straight to the cache; never even go to the network. It’s absolutely offline first. You’re probably going to want something in between those two extremes.

On my own website, adactio.com, if you’re browsing around the website and you’re reading things, that’s all fine. Then what if you lose your internet connection? You get the custom offline page that says, “Sorry, you’re offline,” but then it also shows you the things you’ve previously visited.

You can revisit any of these pages. These have all been cached, so you can cache things as people are browsing around the site. That’s a nice little pattern that a lot of websites could benefit from. It only suffers from the fact that all I can show you is stuff you’ve already seen. You have to have already visited these pages for them to show up in this list. Another pattern that I think is maybe better from a user experience point is when you put the control in the hands of the user.

This website, archive.dconstruct.org, this is what it sounds like. It’s an archive. It’s conference talks.

We ran a conference called dConstruct for 10 years from 2005 to 2015. Breaking news; we’re bringing it back for a one-off event next year, September 2020.

Anyway, all the talks from ten years are online here as audio files. You can browse around and listen to these talks.

You’ll also see that there’s this option to save for offline, exposed on the interface. What that does it is doesn’t just save the page offline; it also saves the audio offline. Then, when you’re an airplane or at the bottom of the ocean or whatever, you can then listen to the things you explicitly asked to be saved offline. It’s effectively a podcast player in the browser.

You see there’s a lot of things you can do. There are kind of a lot of layers you can build upon once you have a service worker.

At the very least, you can do caching because that’s the stuff we do anyway, like put this file in the cache, your CSS, your JavaScript, your icons, whatever.

Then think about, well, maybe I should have a custom offline page, even if it’s just for the branding reasons of having that nice page, just like we have a custom 404 page.

Then you start thinking, well, I want the adding to home screen experience to be good, so you’ve got the web app manifest.

You implement one of those patterns there allowing the users to save things offline, maybe.

Also, push notifications are now possible thanks to service workers. It used to be, if you wanted to make someone’s life a misery, you had to build a native app to give them push notifications all day long. Now you can make someone’s life a misery on the web too.

There’s even more advanced APIs like background sync where the website can talk to the web server even when that website isn’t open in the browser and sync up information — super powerful stuff.

Now, the support for something like service worker and the cache API is almost universal at this point. The support for stuff like background sync notifications is spottier, not universal, and that’s okay because, as long as you’re adding these things in layers. Then it’s fine if something doesn’t have universal support, right? It’s making something work great but, if someone doesn’t get that, it still works good. It’s all about building in that layered way.

Now you’re probably thinking, “Ah-ha! I’ve hoisted him by his own petard because service workers use JavaScript. That means they rely on JavaScript. You’ve made JavaScript a single point of failure!” Exactly what I was complaining about with Single Page Apps, right?

There’s a difference. With a Single Page App, you’re relying on JavaScript. The user gets absolutely nothing if JavaScript doesn’t work.

In the case of service workers, you literally cannot make a website that relies on a service worker. You have to make a website that works first without a service worker and then add the service worker on top, because, think about it; the first time anybody visits the website, even if their browser supports service workers, the service worker is not installed. So you have to build in layers.

I think this is why it appeals to me so much. The design of service workers is a layered design. You have to have something that works first, and then you elevate it. You improve the user experience using these technologies but you don’t rely on it. It’s not a single point of failure. It’s an enhancement.

That means you can take any website. Somebody’s homepage; a book that’s online; this archived stuff ; something that is more appy, sure, and make it work pretty much like a native app. It can appear full screen, add to the home screen, be indistinguishable from native apps so that the latest and greatest browsers and devices get the best experience. They’re making full use of the newest technologies.

But, as well as these things working in the latest and greatest browsers, they still work in the first web browser ever created. You can still look at these things in that very first web browser that Tim Berners-Lee created at worldwideweb.cern.ch.

WorldWideWeb

It’s like it is an unbroken line over 30 years on the web. We’re not talking about the Long Now when we’re talking about 30 years but, in terms of technology, that does feel special.

You can also look at the world’s first webpage in the first-ever web browser but, almost more amazingly, you can look at the world’s first web page at its original URL in a modern web browser and it still works.

We managed to make the web so much better with new APIs, new technologies, without breaking it, without breaking that backward compatibility. There’s something special about that. There’s something special about the web if you build in layers.

I’m encouraging you to think in terms of layers and use the layers of the web.

Thank you.

Monday, December 16th, 2019

Liveblogging An Event Apart 2019

I was at An Event Apart in San Francisco last week. It was the last one of the year, and also my last conference of the year.

I managed to do a bit of liveblogging during the event. Combined with the liveblogging I did during the other two Events Apart that I attended this year—Seattle and Chicago—that makes a grand total of seventeen liveblogged presentations!

  1. Slow Design for an Anxious World by Jeffrey Zeldman
  2. Designing for Trust in an Uncertain World by Margot Bloomstein
  3. Designing for Personalities by Sarah Parmenter
  4. Generation Style by Eric Meyer
  5. Making Things Better: Redefining the Technical Possibilities of CSS by Rachel Andrew
  6. Designing Intrinsic Layouts by Jen Simmons
  7. How to Think Like a Front-End Developer by Chris Coyier
  8. From Ideation to Iteration: Design Thinking for Work and for Life by Una Kravets
  9. Move Fast and Don’t Break Things by Scott Jehl
  10. Mobile Planet by Luke Wroblewski
  11. Unsolved Problems by Beth Dean
  12. Making Research Count by Cyd Harrell
  13. Voice User Interface Design by Cheryl Platz
  14. Web Forms: Now You See Them, Now You Don’t! by Jason Grigsby
  15. The Weight of the WWWorld is Up to Us by Patty Toland
  16. The Mythology of Design Systems by Mina Markham
  17. The Technical Side of Design Systems by Brad Frost

For my part, I gave my talk on Going Offline. Time to retire that talk now.

Here’s what I wrote when I first gave the talk back in March at An Event Apart Seattle:

I was quite nervous about this talk. It’s very different from my usual fare. Usually I have some big sweeping arc of history, and lots of pretentious ideas joined together into some kind of narrative arc. But this talk needed to be more straightforward and practical. I wasn’t sure how well I would manage that brief.

I’m happy with how it turned out. I had quite a few people come up to me to say how much they appreciated how I was explaining the code. That was very nice to hear—I really wanted this talk to be approachable for everyone, even though it included plenty of JavaScript.

The dates for next year’s Events Apart have been announced, and I’ll be speaking at three of them:

The question is, do I attempt to deliver another practical code-based talk or do I go back to giving a high-level talk about ideas and principles? Or, if I really want to challenge myself, can I combine the two into one talk without making a Frankenstein’s monster?

Come and see me at An Event Apart in 2020 to find out.

Saturday, December 14th, 2019

Building The Web

An interview conducted by Vitaly Friedman ahead of the 2019 View Source conference in Amsterdam.

Do you think, as of today, the Web is in the best shape it will ever be?

Well, to paraphrase Charles Dickens, “It is the best of the times; it is the worst of times,” because, in a sense, things are absolutely great today. Let’s just take it from the point of view of browsers and browser support for standards.

What you can do in a browser today just straight out of the box is amazing compared to the past. There are some little differences between browsers but, honestly, not like it used to be. Back in the day, if you were a Web developer, you spent maybe 50% of your time battling specific browser bugs trying to make one browser work like another browser, all this stuff, trying to make up for lack of standards.

It’s funny. I was listening to panel discussions we did at a conference I think 11 years ago, the AtMedia Conference in London. One of the questions I was asking the panelists was like, “What’s your wish list for CSS or browsers, in general?” They were saying things like, “Oh, if we had multiple background images, everything would be perfect. All my problems would be solved.”

They were all saying things that we have. They were all saying things that we have today, and we’ve got more. We have so much today that you couldn’t even imagine in the past, things like service workers where you can literally control network level stuff, amazing CSS things with Grid now and Flexbox. Amazing, right? One the one hand, yes, things are better than they’ve ever been.

Then, on another hand, not so much because, first of all, in the area of browsers, the fact that making a browser is now so complicated that only very, very, very, very few companies and organizations could do it and we’re kind of down to just two or three browser rendering engines, that’s not very healthy for something like the Web, which has always thrived on diversity. That’s something we’ll see how that plays out, so I’m uncomfortable about that but it remains to be seen.

Then, in terms of things being, in my opinion, worse than they were before, it’s less to do with what we get from browsers and more to do with how we choose to make things on the Web. We seem to have collectively decided to make things really complicated in terms of, I want to put something on the Web that used to be relatively straightforward.

I know there were all sorts of problems with the way we used to do it and maybe it didn’t scale so well, but we seem to have collectively decided that the barrier to entry to putting something on the Web requires loads of technologies, not browser technologies, but technologies that sit on our computers or sit on our servers. It’s great that we’ve got version control, build tools, automatic bundlers, and all this stuff, but the level of complexity is extremely high, it seems to me.

I know I’m slow and maybe that’s the reason I’m just not very good at picking this stuff up, but it seems to be objectively quite complex. That strikes me as strange because, like I was saying, you can do more with less these days in a browser. It’s easier than ever to build something interactive in a browser with quite minimal HTML, a bit of JavaScript, CSS, right? You can do loads with what you get out of the browser. Yet, we’ve decided to almost reinvent everything for ourselves.

Even though the browser will let us do all this really smart stuff, let’s reinvent it in JavaScript for ourselves. Let’s reinvent going from URL to URL. We’ll call it rooting, and we’ll do all that ourselves. We’ll do it all in JavaScript, and that means now we have to manage state, and so we’re keeping track of all this stuff.

It’s weird because it’s a choice to do that stuff. Yet, we’re acting as though it’s the default.

People are constantly saying, “Oh, well, expectations are different now.” I will say that’s true. People’s expectations of the Web are different, but not in the way that people mostly talk about it.

When people use that phrase, “Oh, people’s expectations of the Web are different now,” what they usually mean is, “Oh, people expect more from the Web. People expect the Web to be fast and interactive like native apps and stuff. I think that would be great if that were true, but my observation from talking to people is that people’s expectations of the Web have changed.

People expect the Web to be terrible. I talk to people and they’ve simply given up on the Web. Certainly, on mobile, they just try to avoid going on the Web.

Yes, people’s expectations of the Web have changed but not for the better. They’re associating the Web with bad experiences, with things being slow, with constantly being bombarded with, you know, sign up to my newsletter, accept cookies, dark patterns, all this stuff.

The solution to that is not, well, let’s throw more complicated toolchains, JavaScript libraries, and frameworks at it. The solution is to pull things back. How about if we didn’t have terrible user experiences that bombard people with stuff? How about if we just made websites using the bare minimum technology so that they’re fast and respond quickly?

Yet, weirdly, we’ve gotten into this cycle where people say, “Oh, people’s expectations of the Web are so high now that we must use all this complex technology,” which just ends up making the Web feel, frankly, even worse. From that perspective, things are in a pretty terrible state for the Web. Yet, like I said in terms of what you can do out of the box in a browser, just get a text editor and write some HTML, a bit of CSS, a bit of JavaScript; you can make amazing things straight out of the box that 10, 15 years ago we literally couldn’t have imagined.

What are the most important things for people coming into the industry to understand? Thinking about how to ensure the things they are building will be reliable and maintainable in the future?

I think the first thing to establish is that people learn in different ways. The answer to this question kind of depends on the person. I’ve experienced this myself, talking to students in, say, Codebar and stuff, is that some people really want to know why something is working, first. Give me the fundamentals. Give me almost a bit of theory but build things up from the fundamentals upwards until we’ve got a thing that works.

Other people, they don’t work that way. They say, “I want to build something as quickly as possible.” Okay, let’s start with a framework. Let’s create React App or something, something that gets you something straight away and then work backward from there.

I say, “Okay, but what’s actually going on here? Why does this work? What’s happening under the hood?”

There are two different ways of learning there. Neither is right and neither is wrong. There are just different ways.

I think the important thing is that, at some point, you end up with this kind of layered level of knowledge that you’ve got the fundaments in the grounding and then you can add things on top like a framework at the tippy top of that stack. Whether you start with the framework and work down to the fundamentals or start with the fundamentals and work up to the framework, I don’t think that matters as long as what you end up with is a nice rounded kind of stack of technologies.

Then, I think, what you learn over time, and I feel is something you could be told but you kind of have to just learn it yourself and experience it, is that the stuff further down, the fundamentals will change at a much slower pace and the stuff higher up, the abstractions, the frameworks, the tools, they will change at a faster pace. Once you know that, then it’s okay. Then that feeling of being overwhelmed, like, “Oh, there’s so much to learn,” you can start to filter it and figure out, “Well, where do I want to concentrate? Do I want to learn stuff that I know I will have to swap out in another year, two years, three years, or will I concentrate my time on this lower level fundamental stuff that will last for maybe decades, or do I split it? Do I dedicate some of my time to fundamentals and some of my time to the abstractions?”

I think the key thing is that you go in with your eyes open about the nature of the thing you’re learning. If I’m going to learn about HTML and, to a certain extent, CSS and stuff, then I will know this is knowledge that will last for quite a while. It’s not going to change too quickly. But if I’m learning about a framework, a build tool, or something like that, then I will say, “Okay. It’s fine that I’m learning this,” but I shouldn’t be under any illusions that this is going to be forever and not be surprised when, further down the line, people say, “Oh, you’re still using that framework? We don’t use that anymore. We use this other framework now,” right?

I think that’s the key thing is going in with your eyes open. It’s totally fine to study all the stuff, learn all the stuff, as long as you’re not disappointed, like, “Oh, I invested all my time in that framework and now nobody is using that framework anymore. We’ve all moved on to this other framework.”

There’s a phrase from DevOps where you talk about your servers. They say, treat your servers like cattle, not pets. Don’t get too attached to them.

I feel like that’s the case with a lot of the tools we use. I would consider frameworks and libraries to be tools. They’re tools. You use them to help you work faster, but don’t get too attached to them because they will change whereas, the more fundamental stuff, you can rely on.

Now, when I say fundamental stuff, to a certain extent I’m talking about the technology stuff like HTML. That moves at a slow pace. HTTP and how the Internet works, that’s not going to change very fast.

When I say fundamentals, I think you can go deeper than that even, and you can talk about philosophies, attitudes, and ways of approaching how to build something on the Web that’s completely agnostic to technologies. In other words, it’s like what your mindset is when you approach building something, what your priorities are, what you value. Those kinds of things can last for a very, very long time, longer than any technologies.

For example, over time, on the Web, I’ve come to realize that progressive enhancement, which is completely technology agnostic—it’s just a way of thinking—is a good long-term investment. Even as technologies come and go, this approach of thinking in a sort of layered way and building up from the most supported thing to least supported thing works really well no matter what the technology is that comes along.

When Ajax came along in 2005, I could take the progressive enhancement approach and apply it to Ajax. When responsive design came along in 2010, I could take progressive enhancement and apply it to responsive design. When progressive Web apps come along, whatever it happens to be, I can take this approach, this fundamental approach and apply it to whatever the new technology is. Those things tend to be really long-lasting. Those kinds of approaches, almost strategies I guess, are things that can last a long time.

You should always be questioning them. You should always be saying, “Is this still relevant? Does this still work in this situation? Does it still apply?” Over a long time period, you start to get an answer to that. It’s like, “Yeah, actually, it’s funny. Even over 20 years, this particular strategy works really well,” whereas some other strategy that worked well 15 years ago, it turns out, just doesn’t even apply today because some technology has made it obsolete.

Yeah, fundamental things aren’t necessarily technologies. I think a Web developer is well versed in getting to grips with those fundamental things but, at the same time, I’m not sure if you could learn those first. I’m not sure if you could be like, “Okay, we’re going to learn about these fundamental things without touching a line of code.” You kind of have to learn them for yourself by doing it and learning over time, I think.

Do you think frameworks, for example, will be replaced by the establishment of long-lasting Web components with CSS routines where we can adjust everything? Is this the world we’re moving toward or is it going to stay simple after all?

Yes, absolutely, the things that people are pushing the envelope with, in terms of frameworks today, will become the standards of tomorrow. I think I would put good money on that because I’ve seen it happen. I’ve seen it happen in the past, generally.

It’s usually in JavaScript that we figure something out, we figure out what we want, and we make it work in JavaScript first. If it’s a really powerful idea that solves a common problem, it will find its way further down.

The classic example, early on, I’m talking in the ’90s now, the first pieces of JavaScript were things like doing image rollovers. Now we don’t need JavaScript for that because we use hover in CSS. It’s such a common use case, it moved down into the declarative layer.

The same with form validation. You have to write your own form validation. Now you can just do required in HTML and stuff like that. This pattern plays out over and over again. With responsive images, we figured out what we wanted in JavaScript and then we got it in HTML with pictures.

Yes, I think the goal of any good framework or library should be to make itself redundant. A classic example of this would be jQuery. You don’t need jQuery today because all the stuff that jQuery did for you like using CSS selectors to find DOM nodes, you can do that now in the browser using querySelector, querySelectorAll. But of course, the only reason why querySelector exists is because jQuery proved it was powerful and people wanted it.

I think, absolutely, a lot of the things that people are currently using frameworks and libraries for will become part of the standard, whether that has to do with the idea of a virtual DOM, state management, managing page transitions, giving us control over that. Yes, absolutely, that will find its way.

Now, whether the specific implementations will be these things like Web components, Houdini, and stuff like that, that’s interesting. We’ll see how that plays out. That’s all part of this bigger idea of the extensible Web where, in the past, we would get specific things like, here is the picture element, here is this new JavaScript API or whatever, here is querySelector. Whereas now, we’ve sort of been given, okay, here are the nuts and bolts of how a browser works. You build a solution and then we’ll see what happens. That’s an interesting idea.

I guess the theory is then that, okay, let’s say we get Web components, we get Houdini. Now we all start building our own widgets and we all start building our own CSS functions. The theory is that the ones that are really popular and really goodwill then get standardized and end up in the standards.

I’m not sure if that’s actually going to happen because I wonder what a standards body or browser maker would actually say is, “Oh, well, we don’t need to make it part of the standard because everyone can just use the Web component, everyone can just use this Houdini thing,” right? We’ll see whether that works out.

I wonder if it’ll end up maybe like the situation with jQuery plugins. I mentioned that jQuery was great, it showed this is what people want, and it ended up as a standard. As well as jQuery the library, you also had jQuery plugins, the ecosystem where everybody built a thousand different carousels, a thousand different widgets. There was no quality control and you couldn’t figure out which was the right one to use. I worry that might be where we end up with things like Web components, Houdini, and stuff like that. But it’s an interesting idea, this extensible Web thing.

How will we build? How will the workflow or the tooling change and evolve as we move forward?

Well, that’s up to us. These things are created by people, so that’s something to be aware of. When people come to the Web think, “Oh, what should I learn? What’s the tool? What’s the methodology? How will we be building websites?” It’s almost like, what horse should I be backing here? What’s a safe bet?

You’ve got to step back and realize these things aren’t handed down from heaven as some kind of decision has been made and then passed on to us. We make those decisions. We decide how the Web gets built. There’s no central authority on this stuff. We collectively decide it.

You can choose how the future of Web development is going to look. You could choose what a workflow is going to look like that works for you and works for other people.

The Web is super flexible. You can choose to build in this layered way that I’ve talked about, progressive enhancement, very resilient way of working, but you don’t have to. The Web doesn’t mandate that you work that way. You could choose to build in a way that you just do everything in JavaScript and make JavaScript do the rooting, the DOM, and everything in JavaScript.

It’s a choice. It’s not something that, oh, in the future, we will all do this; in the future, we will all do that. In the future, you will make a choice about how you want to build.

I think, too often, though, when we’re making those decisions of how should I build or what’s the best way to build something on the Web, I worry that sometimes we think about it a bit too much from our perspective. What’s the best way for me to build on the Web? What’s going to make things easiest for me as a developer?

I don’t want to make things hard for us. I don’t want life to be difficult, but I do think our priorities should actually be what’s going to make things better for the user, even if that means more work from us.

If you’re getting paid, if you’re getting a paycheck to make things on the Web—then again, kind of going back to responsibility—it’s not about you now. You have a duty of care to the people who will be using the thing you’re building. Decisions about how to build on the Web shouldn’t just be made according to what you like, what you think is nice for you, what makes your life easy, what saves you typing, but should be more informed by what’s going to be better for users, what’s going to be more resilient, what’s going to leave nobody behind, you know, something that’s available to everyone.

I know I’m talking a lot in abstractions and vagaries, but the talk at View Source will go into a little more detail.

People are often disappointed in the state of the Web today. How do you see the Web evolving over the years? Do you think that privacy and ethics will become a standard?

I think the first thing to establish is that I don’t want to paint too rosy a picture of how things were in the past. There have always been problems. It’s just that we might have different problems today.

I remember the days of literal pop-up windows or pop-under windows, things like that, really annoying things that eventually browsers had to come in and kind of stamp down on that stuff. That’s sort of happening today as well with some of the egregious tracking and surveillance you see Safari and Firefox taking steps to limit that.

In the past, I would have said, “Oh, we need to figure this out. We need to almost self-regulate,” you know, before it’s too late. At this point, I think, “No, it is too late,” and regulation is coming. GDPR is a first step in that and there will be more.

We deserve it. We had our chance to figure this stuff out for ourselves and do the right thing. We blew it, and things are really bad when it comes to surveillance and tracking.

A lot of the business models seem to be predicated on tracking. I’m saying tracking here, not advertising. Advertising isn’t the issue here. It’s specifically tracking.

It’s a bit of a shame that we talk about ad blockers as a software. Most people are not blocking ads. What they’re blocking is tracking. Again, the same way that browsers had to kind of step in and stop popups and pop-under windows, now we see ad blockers, tracking blockers stepping in to solve this.

We get this kind of battle, right? It’s almost like an arms race that’s been going on. I think regulation is going to come in on top of that. Guaranteed it’s going to happen.

You’re right; the fundamental business models in use today are kind of at odds with privacy and surveillance, so they might need to change. Although, I don’t think advertising requires tracking. I know a lot of people talk as though it does. People talk about, “Oh, you can’t have advertising without a tracking link.” You absolutely can. Sponsorship, other kinds of advertising absolutely work.

The other thing is that tracking is not very good. If I’m advertised to with something that absolutely suits my needs then it kind of ceases to be advertising. It just becomes useful, right? That’s not what I experience. What I experience is just really badly targeted things. It’s not even like the tracking works. Yet, people claim tracking is essential.

Anyway, when I say business models need to change, I don’t mean advertising. I think advertising is actually a reasonable business model for some kinds of services. That connection between advertising and tracking, that needs to be severed.

Some people think that’s impossible. They say, “No, it’s just a law of nature that those two things go together.” That’s not true. We choose that. 
The other thing to remember is that we sometimes look around to see how things are today and we can’t imagine it could be any different. We see one dominant search engine and so we think there could only ever be one dominant search engine, but that’s not true. That’s just the way things have turned out. We see a big social network like Facebook and we think, “Oh, there could ever be one big social network.” Again, that’s just the way things have turned out in our situation.

I think the worst thing we can do is assume things are inevitable and it’s inevitable that things end up that way. That’s particularly true when it comes to surveillance and tracking and things that are antiprivacy to say, “Well, that’s just the way it is. It’s inevitable and it couldn’t be any other way.” I think the first step is that we have to have the imagination to think about how things could be different, how things could have turned out differently, and then work towards making that a reality.

Also, this is a huge opportunity. People are clearly fed up with the tracking. They’re fed up with the surveillance. They don’t mind the advertising. There is a separation there. There is an opportunity here to take on these big organizations who literally can’t change their business model.

Someone like Google, the idea of tracking and surveillance is kind of intrinsically linked to their core business model. That gives a huge opportunity. You can see Apple already starting to exploit this opportunity, but other people, too, where you can make privacy and lack of tracking your selling point. It’s a way for a small player to suddenly maybe disrupt the incumbents because the incumbents are so reliant on tracking.

You can’t take on Facebook by trying to be another Facebook, but you can take on Facebook by being what Facebook can’t do. Not what Facebook won’t do, what Facebook literally can’t do. There’s actually a big opportunity there.

Yeah, when we talk about the good old days of keeping track of things, blogs, I kind of share that because I remember the good old days as well. But I’ll say I see a bit of a resurgence as well. Enough people are getting fed up with just posting on silos like Twitter, Facebook, and stuff that I see more and more people launching their own websites again and publishing there. I hope we’ll see more of that.

What are you most excited about on the Web these days?

Yeah, this is an interesting question because it’s happened over and over again over the course of my career, about 20 years now, where I’ll think, like, “Oh, there’s nothing really exciting me,” and then something comes along and I get, ooh, really excited. Almost kind of puttering along when CSS came along, “Oh, this is really interesting.” Then, years later, Ajax, like, “Ah, this is really interesting.”

I think currently service workers are the things that get me excited, get me thinking about, oh, the potential for what the Web could be. The potential for the user experience on the Web is huge. I don’t even think the challenges are technological because it’s pretty straightforward using service workers.

It’s more changing people’s expectations of the Web, the idea that, oh, you should be able to open a browser or hit a bookmark and have something happen even if you don’t have an Internet connection or even if you are on a crappy network that things could still be quite reliable. That’s such a fundamental change and that gets me very, very excited. It’s also, obviously, a huge challenge to change that.

I have to say, over a long enough time period, the things that I start to think about start to be less and less about specific technologies and more and more about just the Web, in general, and the people making the Web.

I certainly have fears for the Web. They aren’t so much around technologies, like, “Oh, will one particular browser make or dominate,” or, “Will one particular framework be the only technology around?” Those things are concerning. It’s more about, “Will the idea of being able to make for the Web start to get reduced down to an elite kind of priesthood of a certain kind of person?” Frankly, the kind of person who looks like me, right? White, male, privileged, European. If we’re the only people who get to make for the Web, that will be terrible.

I think the real potential of the Web and the promise of the Web from the early days was that it’s for anyone. Anybody should be able to not just use the Web and consume it, but anyone should be able to add to it and build for it.

The thing that actually motivates me now is less about a specific technology and more about how can I try and get a more diverse range of people making the Web, making their own careers out of making for the Web rather than it being reduced, reduced, reduced to a certain kind of person. When I’m done with all this, if I look around and all the other people making websites look just like me, then I think we’ll have failed.

Wednesday, December 11th, 2019

The Technical Side of Design Systems by Brad Frost

Day two of An Event Apart San Francisco is finishing with a talk from Brad on design systems (so hot right now!):

You can have a killer style guide website, a great-looking Sketch library, and robust documentation, but if your design system isn’t actually powering real software products, all that effort is for naught. At the heart of a successful design system is a collection of sturdy, robust front-end components that powers other applications’ user interfaces. In this talk, Brad will cover all that’s involved in establishing a technical architecture for your design system. He’ll discuss front-end workshop environments, CSS architecture, implementing design tokens, popular libraries like React and Vue.js, deploying design systems, managing updates, and more. You’ll come away knowing how to establish a rock-solid technical foundation for your design system.

I will attempt to liveblog the Frostmeister…

“Design system” is an unfortunate name …like “athlete’s foot.” You say it to someone and they think they know what you mean, but nothing could be further from the truth.

As Mina said:

A design system is a set of rules enforced by culture, process and tooling that govern how your organization creates products.

A design system the story of how an organisation gets things done.

When Brad talks to companies, he asks “Have you got a design system?” They invariably say they do …and then point to a Sketch library. When the focus goes on the design side of the process, the production side can suffer. There’s a gap between the comp and the live site. The heart and soul of a design system is a code library of reusable UI components.

Brad’s going to talk through the life cycle of a project.

Sell

He begins with selling in a design system. That can start with an interface inventory. This surfaces visual differences. But even if you have, say, buttons that look the same, the underlying code might not be consistent. Each one of those buttons represents time and effort. A design system gives you a number of technical benefits:

  • Reduce technical debt—less frontend spaghetti code.
  • Faster production—less time coding common UI components and more time building real features.
  • Higher-quality production—bake in and enforce best practices.
  • Reduce QA efforts—centralise some QA tasks.
  • Potentially adopt new technologies faster—a design system can help make additional frameworks more managable.
  • Useful reference—an essential resource hub for development best practices.
  • Future-friendly foundation—modify, extend, and improve over time.

Once you’ve explained the benefits, it’s time to kick off.

Kick off

Brad asks “What’s yer tech stack?” There are often a lot of tech stacks. And you know what? Users don’t care. What they see is one brand. That’s the promise of a design system: a unified interface.

How do you make a design system deal with all the different tech stacks? You don’t (at least, not yet). Start with a high priority project. Use that as a pilot project for the design system. Dan talks about these projects as being like television pilots that could blossom into a full season.

Plan

Where to build the design system? The tech stack under the surface is often an order of magnitude greater than the UI code—think of node modules, for example. That’s why Brad advocates locking off that area and focusing on what he calls a frontend workshop environment. Think of the components as interactive comps. There are many tools for this frontend workshop environment: Pattern Lab, Storybook, Fractal, Basalt.

How are you going to code this? Brad gets frontend teams in a room together and they fight. Have you noticed that developers have opinions about things? Brad asks questions. What are your design principles? Do you use a CSS methodology? What tools do you use? Spaces or tabs? Then Brad gets them to create one component using the answers to those questions.

Guidelines are great but you need to enforce them. There are lots of tools to automate coding style.

Then there’s CSS architecture. Apparently we write our styles in React now. Do you really want to tie your CSS to one environment like that?

You know what’s really nice? A good ol’ sturdy cacheable CSS file. It can come in like a fairy applying all the right styles regardless of tech stack.

Design and build

Brad likes to break things down using his atomic design vocabulary. He echoes what Mina said earlier:

Embrace the snowflakes.

The idea of a design system is not to build 100% of your UI entirely from components in the code library. The majority, sure. But it’s unrealistic to expect everything to come from the design system.

When Brad puts pages together, he pulls in components from the code library but he also pulls in one-off snowflake components where needed.

The design system informs our product design. Our product design informs the design system.

—Jina

Brad has seen graveyards of design systems. But if you make a virtuous circle between the live code and the design system, the design system has a much better chance of not just surviving, but thriving.

So you go through those pilot projects, each one feeding more and more into the design system. Lather, rinse, repeat. The first one will be time consuming, but each subsequent project gets quicker and quicker as you start to get the return on investment. Velocity increases over time.

It’s like tools for a home improvement project. The first thing you do is look at your current toolkit. If you don’t have the tool you need, you invest in buying that new tool. Now that tool is part of your toolkit. Next time you need that tool, you don’t have to go out and buy one. Your toolkit grows over time.

The design system code must be intuitive for developers using it. This gets into the whole world of API design. It’s really important to get this right—naming things consistently and having predictable behaviour.

Mina talked about loose vs. strict design systems. Open vs. locked down. Make your components composable so they can adapt to future requirements.

You can bake best practices into your design system. You can make accessibility a requirement in the code.

Launch

What does it mean to “launch” a design system?

A design system isn’t a project with an end, it’s the origin story of a living and evolving product that’ll serve other products.

—Nathan Curtis

There’s a spectrum of integration—how integrated the design system is with the final output. The levels go from:

  1. Least integrated: static.
  2. Front-end reference code.
  3. Most integrated: consumable compents.

Chris Coyier in The Great Divide talked about how wide the spectrum of front-end development is. Brad, for example, is very much at the front of the front end. Consumable UI components can create a bridge between the back of the front end and the front of the front end.

Consumable UI components need to be bundled, packaged, and published.

Maintain

Now we’ve entered a new mental space. We’ve gone from “Let’s build a website” to “Let’s maintain a product which other products use as a dependency.” You need to start thinking about things like semantic versioning. A version number is a promise.

A 1.0.0 designation comes with commitment. Freewheeling days of unstable early foundations are behind you.

—Nathan Curtis

What do you do when a new tech stack comes along? How does your design system serve the new hotness. It gets worse: you get products that aren’t even web based—iOS, Android, etc.

That’s where design tokens come in. You can define your design language in a platform-agnostic way.

Summary

This is hard.

  • Your design system must live in the technologies your products use.
  • Look at your product roadmaps for design system pilot project opportunities.
  • Establish code conventions and use tooling and process to enforce them.
  • Build your design system and pilot project UI screens in a frontend workshop environment.
  • Bake best practices into reusable components & make them as rigid or flexible as you need them to be.
  • Use semantic versioning to manage ongoing design system product work.
  • Use design tokens to feed common design properties into different platforms.

You won’t do it all at once. That’s okay. Baby steps.

Tuesday, December 10th, 2019

The Mythology of Design Systems by Mina Markham

It’s day two of An Event Apart San Francisco. The brilliant Mina Markham is here to talk to us about design systems (so hot right now!). I’m going to attempt to liveblog it:

Design systems have dominated web design conversations for a few years. Just as there’s no one way to make a website, there is no one way to make a design system. Unfortunately this has led to a lot of misconceptions around the creation and impact of this increasingly important tool.

Drawing on her experiences building design systems at two highly visible and vastly different organizations, Mina will debunk some common myths surrounding design systems.

Mina is a designer who codes. Or an engineer who designs. She makes websites. She works at Slack, but she doesn’t work on the product; she works on slack.com and the Slack blog. Mina also makes design systems. She loves design systems!

There are some myths she’s heard about design systems that she wants to dispel. She will introduce us to some mythological creatures along the way.

Myth 1: Designers “own” the design system

Mina was once talking to a product designer about design systems and was getting excited. The product designer said, nonplussed, “Aren’t you an engineer? Why do you care?” Mina explained that she loved design systems. The product designer said “Y’know, design systems should really be run by designers” and walked away.

Mina wondered if she had caused offense. Was she stepping on someone’s toes? The encounter left her feeling sad.

Thinking about it later, she realised that the conversation about design systems is dominated by product designers. There was a recent Twitter thread where some engineers were talking about this: they felt sidelined.

The reality is that design systems should be multi-disciplinary. That means engineers but it also means other kinds of designers other than product designers too: brand designers, content designers, and so on.

What you need is a hybrid, or unicorn: someone with complimentary skills. As Jina has said, design systems themselves are hybrids. Design systems give hybrids (people) a home. Hybrids help bring unity to an organization.

Myth 2: design systems kill creativity

Mina hears this one a lot. It’s intertwined with some other myths: that design systems don’t work for editorial content, and that design systems are just a collection of components.

Components are like mermaids. Everyone knows what one is supposed to look like, and they can take many shapes.

But if you focus purely on components, then yes, you’re going to get frustrated by a feeling of lacking creativity. Mina quotes @brijanp saying “Great job scrapbookers”.

Design systems encompass more than components:

  • High level principles.
  • Brand guidelines.
  • Coding standards.
  • Accessibility compliance.
  • Governance.

A design system is a set of rules enforced by culture, process and tooling that govern how your organization creates products.

—Mina

Rules and creativity are not mutually exclusive. Rules can be broken.

For a long time, Mina battled against one-off components. But then she realised that if they kept coming up, there must be a reason for them. There is a time and place for diverging from the system.

It’s like Alice Lee says about illustrations at Slack:

There’s a time and place for both—illustrations as stock components, and illustrations as intentional complex extensions of your specific brand.

Yesenia says:

Your design system is your pantry, not your cookbook.

If you keep combining your ingredients in the same way, then yes, you’ll keep getting the same cake. But if you combine them in different ways, there’s a lot of room for creativity. Find the key moments of brand expression.

There are strict and loose systems.

Strict design systems are what we usually think of. AirBnB’s design system is a good example. It’s detailed and tightly controlled.

A loose design system will leave more space for experimentation. TED’s design system consists of brand colours and wireframes. Everything else is left to you:

Consistency is good only insofar as it doesn’t prevent you from trying new things or breaking out of your box when the context justifies it.

Yesenia again:

A good design sytem helps you improvise.

Thinking about strict vs. loose reminds Mina of product vs. marketing. A design system for a product might need to be pixel perfect, whereas editorial design might need more breathing room.

Mina has learned to stop fighting the one-off snowflake components in a system. You want to enable the snowflakes without abandoning the system entirely.

A loose system is key for maintaining consistency while allowing for exploration and creativity.

Myth 3: a design system is a side project

Brad guffaws at this one.

Okay, maybe no one has said this out loud, but you definitely see a company’s priorities focused on customer-facing features. A design system is seen as something for internal use only. “We’ll get to this later” is a common refrain.

“Later” is a mythical creature—a phoenix that will supposedly rise from the ashes of completed projects. Mina has never seen a phoenix. You never see “later” on a roadmap.

Don’t treat your design system as a second-class system. If you do, it will not mature. It won’t get enough time and resources. Design systems require real investment.

Mina has heard from people trying to start design systems getting the advice, “Just do it!” It seems like good advice, but it could be dangerous. It sets you up for failure (and burnout). “Just doing it” without support is setting people up for a bad experience.

The alternative is to put it on the roadmap. But…

Myth 4: a design system should be on the product roadmap

At a previous company, Mina once put a design system on the product roadmap because she saw it wasn’t getting the attention it needed. The answer came back: nah. Mina was annoyed. She had tried to “just do it” and now when she tried to do it through the right channels, she’s told she can’t.

But Mina realised that it’s not that simple. There are important metrics she might not have been aware of.

A roadmap is multi-faceted thing, like Cerebus, the three-headed dog of the underworld.

Okay, so you can’t put the design sytem on the roadmap, but you can tie it to something with a high priority. You could refactor your way to a design system. Or you could allocate room in your timeline to slip in design systems work (pad your estimates a little). This is like a compromise between “Just do it!” and “Put it on the roadmap.”

A system’s value is realized when products ship features that use a system’s parts.

—Nathan Curtis

The other problem with putting a design system on the roadmap is that it implies there’s an end date. But a design system is never finished (unless you abandon it).

Myth 5: our system should do what XYZ’s system did

It’s great that there are so many public design systems out there to look to and get inspired by. We can learn from them. “Let’s do that!”

But those inspiring public systems can be like a succubus. They’re powerful and seductive and might seem fun at first but ultimately leave you feeling intimidated and exhausted.

Your design system should be build for your company’s specific needs, not Google’s or Github’s or anyone’s.

Slack has multiple systems. There’s one for the product called Slack Kit. It’s got great documentation. But if you go on Slack’s marketing website, it doesn’t look like the product. It doesn’t use the same typography or even colour scheme. So it can’t use the existing the design system. Mina created the Spacesuit design system specifically for the marketing site. The two systems are quite different but they have some common goals:

  • Establish common language.
  • Reduce technical debt.
  • Allow for modularity.

But there are many different needs between the Slack client and the marketing site. Also the marketing site doesn’t have the same resources as the Slack client.

Be inspired by other design systems, but don’t expect the same resutls.

Myth 6: everything is awesome!

When you think about design systems, everything is nice and neat and orderly. So you make one. Then you look at someone else’s design system. Your expectations don’t match the reality. Looking at these fully-fledged design systems is like comparing Instagram to real life.

The perfect design system is an angel. It’s a benevolent creature acting as an intermediary between worlds. Perhaps you think you’ve seen one once, but you can’t be sure.

The truth is that design system work is like laying down the railway tracks while the train is moving.

For a developer, it is a rare gift to be able to implement a project with a clean slate and no obligations to refactor an existing codebase.

Mina got to do a complete redesign in 2017, accompanied by a design system. The design system would power the redesign. Everything was looking good. Then slowly as the rest of the team started building more components for the website, unconnected things seemed to be breaking. This is what design systems are supposed to solve. But people were creating multiple components that did the same thing. Work was happening on a deadline.

Even on the Hillary For America design system (Pantsuit), which seemed lovely and awesome on the outside, there were multiple components that did the same thing. The CSS got out of hand with some very convoluted selectors trying to make things flexible.

Mina wants to share those stories because it sometimes seems that we only share the success stories.

Share work in progress. Learn out in the open. Be more vulnerable, authentic, and real.

Sunday, December 8th, 2019

On this day

I’m in San Francisco to speak at An Event Apart, which kicks off tomorrow. But I arrived a few days early so that I could attend Indie Web Camp SF.

Yesterday was the discussion day. Most of the attendees were seasoned indie web campers, so quite a few of the discussions went deep on some of the building blocks. It was a good opportunity to step back and reappraise technology decisions.

Today is the day for making, tinkering, fiddling, and hacking. I had a few different ideas of what to do, mostly around showing additional context on my blog posts. I could, for instance, show related posts—other blog posts (or links) that have similar tags attached to them.

But I decided that a nice straightforward addition would be to show a kind of “on this day” context. After all, I’ve been writing blog posts here for eighteen years now; chances are that if I write a blog post on any given day, there will be something in the archives from that same day in previous years.

So that’s what I’ve done. I’ll be demoing it shortly here at Indie Web Camp, but you can see it in action now. If you look at the page for this blog post, you should see a section at the end with the heading “Previously on this day”. There you’ll see links to other posts I’ve written on December 8th in years gone by.

It’s quite a mixed bag. There’s a post about when I used to have a webcam from sixteen years ago. There’s a report from the Flash On The Beach conference from thirteen years ago (I wrote that post while I was in Berlin). And five years ago, I was writing about markup patterns for web components.

I don’t know if anyone other than me will find this feature interesting (but as it’s my website, I don’t really care). Personally, I find it fascinating to see how my writing has changed, both in terms of subject matter and tone.

Needless to say, the further back in time you go, the more chance there is that the links in my blog posts will no longer work. That’s a real shame. But then it’s a pleasant surprise when I find something that I linked to that is still online after all this time. And I can take comfort from the fact that if anyone has ever linked to anything I’ve written on my website, then those links still work.

Wednesday, November 27th, 2019

Oh, Vienna!

Earlier this year I was in Düsseldorf for a triple bill of events:

  1. Indie Web Camp
  2. Beyond Tellerrand
  3. Accessibility Club

At Accessibility Club, I had the pleasure of seeing a great presentation from Manuel Matuzovic. Afterwards, a gaggle of us geeks went out for currywurst and beer. I got chatting with Manuel, who mentioned that he’s based in Vienna, where he organises a web meetup. I told him I’d love to come and speak at it sometime. He seemed very keen on the idea!

A few weeks later, I dropped him a line so he knew I was serious with my offer:

Hi Manuel,

Just wanted to drop a quick line to say how nice it was to hang out in Düsseldorf—albeit briefly.

I’d definitely be up for coming over to Vienna sometime for a meet up. Hope we can make that work sometime!

Cheers,

Jeremy

Manuel responded:

thank you for reaching out to me. Your timing couldn’t be better. :)

I was so excited that you showed interest in visiting Vienna that I thought about organising something that’s a little bit bigger than a meetup but smaller than a conference. 

I’m meeting today with my friend Max Böck to tell him about the idea and to ask him if he would want to help me organise a event.

Well, they did it. I just got back from the inaugural Web Clerks Community Conf in Vienna. It was a day full of excellent talks given to a very warm and appreciate audience.

The whole thing was livestreamed so you can catch up on the talks. I highly recommend watching Max’s talk on the indie web.

I had a really nice time hanging out with friends like Charlie, Rachel, Heydon, and my travelling companion, Remy. But it was equally great to meet new people, like the students who were volunteering and attending. I love having the chance to meet the next generation of people working on the web.

Accessibility on The Session revisited

Earlier this year, I wrote about an accessibility issue I was having on The Session. Specifically, it was an issue with Ajax and pagination. But I managed to sort it out, and the lesson was very clear:

As is so often the case, the issue was with me trying to be too clever with ARIA, and the solution was to ease up on adding so many ARIA attributes.

Well, fast forward to the past few weeks, when I was contacted by one of the screen-reader users on The Session. There was, once again, a problem with the Ajax pagination, specifically with VoiceOver on iOS. The first page of results were read out just fine, but subsequent pages were not only never announced, the content was completely unavailable. The first page of results would’ve been included in the initial HTML, but the subsequent pages of results are injected with JavaScript (if JavaScript is available—otherwise it’s regular full-page refreshes all the way).

This pagination pattern shows up all over the site: lists of what’s new, search results, and more. I turned on VoiceOver and I was able to reproduce the problem straight away.

I started pulling apart my JavaScript looking for the problem. Was it something to do with how I was handling focus? I just couldn’t figure it out. And other parts of the site that used Ajax didn’t seem to be having the same problem. I was mystified.

Finally, I tracked down the problem, and it wasn’t in the JavaScript at all.

Wherever the pagination pattern appears, there are “previous” and “next” links, marked up with the appropriate rel="prev" and rel="next" attributes. Well, apparently past me thought it would be clever to add some ARIA attributes in there too. My thinking must’ve been something like this:

  • Those links control the area of the page with the search results.
  • That area of the page has an ID of “results”.
  • I should add aria-controls="results" to those links.

That was the problem …which is kind of weird, because VoiceOver isn’t supposed to have any support for aria-controls. Anyway, once I removed that attribute from the links, everything worked just fine.

Just as the solution last time was to remove the aria-atomic attribute on the updated area, the solution this time was to remove the aria-controls attribute on the links that trigger the update. Maybe this time I’ll learn my lesson: don’t mess with ARIA attributes you don’t understand.