Tags: btconf

27

sparkline

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.

Thursday, November 21st, 2019

Rams

I’ve made a few trips to Germany recently. I was in Berlin last week for the always-excellent Beyond Tellerrand. Marc did a terrific job of curating an entertaining and thought-provoking line-up of speakers. He also made sure that those speakers—myself included—were very well taken care of.

I was also in Frankfurt last month. It was for an event, but for once, it wasn’t an event that involved me in any way. Jessica was there for the Frankfurt Book Fair. I was tagging along for the ride.

While Jessica was out at the sprawling exhibition hall on the edge of town, I was exploring downtown Frankfurt. One lunch time, I found myself wandering around the town’s charming indoor market hall.

While I was perusing the sausages on display, I noticed an older gentleman also inspecting the meat wares. He looked familiar. That’s when the part of my brain responsible for facial recognition said “That’s Dieter Rams.” A more rational part of my brain said “It can’t be!”, but it seemed that my pattern matching was indeed correct.

As he began to walk away, the more impulsive part of my brain shouted “Say something!”, and before my calmer nature could intervene, I was opening my mouth to speak.

I think I would’ve been tongue-tied enough introducing myself to someone of Dieter Rams’s legendary stature, but it was compounded by having to do it in a second language.

Entschulding Sie!”, I said (“Excuse me”). “Sind Sie Dieter Rams?” (“Are you Dieter Rams?”)

“Ja, bin ich”, he said (“Yes, I am”).

At this point, my brain realised that it had nothing further planned and it left me to my own devices. I stumbled through a sentence saying something about what a pleasure it was to see him. I might have even said something stupid along the lines of “I’m a web designer!”

Anyway, he smiled politely as I made an idiot of myself, and then I said goodbye, reiterating that it was a real treat for me to meet him.

After I walked outside, I began questioning reality. Did that really just happen? It felt utterly surreal.

Of course afterwards I thought of all the things I could’ve said. L’esprit de l’escalier. Or as the Germans put it, Treppenwitz.

I could’ve told him that I collect design principles, of which his are probably the most well-known.

I could’ve told him about the time that Clearleft went on a field trip to the Design Museum in London to see an exhibition of his work, and how annoyed I was by the signs saying “Do Not Touch” …in front of household objects that were literally designed to be touched!

I could’ve told him how much I enjoyed the documentary that Gary Hustwit made about him.

But I didn’t say any of those things. I just spouted some inanity, like the starstruck fanboy I am.

There’ll be a lunchtime showing of the Rams documentary at An Event Apart in San Francisco, where I’ll be speaking in a few weeks. Now I wonder if rewatching it is just going to make me cringe as I’m reminded of my encounter in Frankfurt.

But I’m still glad I said something.

Sunday, November 17th, 2019

2019-11-17 – florian.photo

These are great photos of the speakers at Beyond Tellerrand—great captures of Sharon, Cassie, and Charlotte.

Saturday, November 16th, 2019

The Layers Of The Web

Here are the slides from my opening keynote at Beyond Tellarrand on Thursday. They don’t make much sense out of context.

Web Layers Of Pace

How cool is this!!?

Tom took one of the core ideas from my talk at Beyond Tellerrand and turned it into this animated CodePen!

The Layers Of The Web - Jeremy Keith on Vimeo

Thanks to the quick work of Marc and his team, the talk I gave at Beyond Tellerrand on Thursday was online within hours!

I’m really pleased with how this turned out. I wasn’t sure if anybody was going to be interested in the deep dive into history that I took for the first 15 or 20 minutes, but lots of people told me that they really enjoyed that part, so that makes me happy.

Thursday, July 4th, 2019

Movie Knight

I mentioned how much I enjoyed Mike Hill’s talk at Beyond Tellerrand in Düsseldorf:

Mike gave a talk called The Power of Metaphor and it’s absolutely brilliant. It covers the monomyth (the hero’s journey) and Jungian archetypes, illustrated with the examples Star Wars, The Dark Knight, and Jurassic Park.

At Clearleft, I’m planning to reprise the workshop I did a few years ago about narrative structure—very handy for anyone preparing a conference talk, blog post, case study, or anything really:

Ellen and I have been enjoying some great philosophical discussions about exactly what a story is, and how does it differ from a narrative structure, or a plot. I really love Ellen’s working definition: Narrative. In Space. Over Time.

This led me to think that there’s a lot that we can borrow from the world of storytelling—films, novels, fairy tales—not necessarily about the stories themselves, but the kind of narrative structures we could use to tell those stories. After all, the story itself is often the same one that’s been told time and time again—The Hero’s Journey, or some variation thereof.

I realised that Mike’s monomyth talk aligns nicely with my workshop. So I decided to prep my fellow Clearlefties for the workshop with a movie night.

Popcorn was popped, pizza was ordered, and comfy chairs were suitably arranged. Then we watched Mike’s talk. Everyone loved it. Then it was decision time. Which of three films covered in the talk would we watch? We put it to a vote.

It came out as an equal tie between Jurassic Park and The Dark Knight. How would we resolve this? A coin toss!

The toss went to The Dark Knight. In retrospect, a coin toss was a supremely fitting way to decide to watch that film.

It was fun to watch it again, particularly through the lens of Mike’s analyis of its Jungian archetypes.

But I still think the film is about game theory.

Thursday, May 23rd, 2019

Beyond

After a fun and productive Indie Web Camp, I stuck around Düsseldorf for Beyond Tellerand. I love this event. I’ve spoken at it quite a few times, but this year it was nice to be there as an attendee. It’s simultaneously a chance to reconnect with old friends I haven’t seen in a while, and an opportunity to meet lovely new people. There was plenty of both this year.

I think this might have been the best Beyond Tellerrand yet, and that’s saying something. It’s not just that the talks were really good—there was also a wonderful atmosphere.

Marc somehow manages to curate a line-up that’s equal parts creativity and code; design and development. It shouldn’t work, but it does. I love the fact that he had a legend of the industry like David Carson on the same stage as first-time speaker like Dorobot …and the crowd loved ‘em equally!

During the event, I found out that I had a small part to play in the creation of the line-up…

Three years ago, I linked to a video of a talk by Mike Hill:

A terrific analysis of industrial design in film and games …featuring a scene-setting opening that delineates the difference between pleasure and happiness.

It’s a talk about chairs in Jodie Foster films. Seriously. It’s fantastic!

Marc saw my link, watched the video, and decided he wanted to get Mike Hill to speak at Beyond Tellerrand. After failing to get a response by email, Marc managed to corner Mike at an event in Amsterdam and get him on this year’s line-up.

Mike gave a talk called The Power of Metaphor and it’s absolutely brilliant. It covers the monomyth (the hero’s journey) and Jungian archetypes, illustrated with the examples Star Wars, The Dark Knight, and Jurassic Park:

Under the surface of their most celebrated films lies a hidden architecture that operates on an unconscious level; This talk is designed to illuminate the techniques that great storytellers use to engage a global audience on a deep and meaningful level through psychological metaphor.

The videos from Beyond Tellerrand are already online so you can watch the talk now.

Mike’s talk was back-to-back with a talk from Carolyn Stransky called Humanising Your Documentation:

In this talk, we’ll discuss how the language we use affects our users and the first steps towards writing accessible, approachable and use case-driven documentation.

While the talk was ostensibly about documentation, I found that it was packed full of good advice for writing well in general.

I had a thought. What if you mashed up these two talks? What if you wrote documentation through the lens of the hero’s journey?

Think about it. When somone arrives at your documentation, they’ve crossed the threshold to the underworld. They are in the cave, facing a dragon. You are their guide, their mentor, their Obi-Wan Kenobi. You can help them conquer their demons and return to the familiar world, changed by their journey.

Too much?

Tuesday, May 21st, 2019

Take Back Your Web - Tantek Çelik on Vimeo

Tantek’s barnstorming closing talk from Beyond Tellerrand. This is well worth 30 minutes of your time.

Own your domain. Own your content. Own your social connections. Own your reading experience. IndieWeb services, tools, and standards enable you to take back your web.

Friday, May 17th, 2019

Eintrag “Take back your web – Tantek Çelik @ Beyond Tellerrand Conference, Düsseldorf 2019” beim Webrocker

Tom shares his thoughts on Tantek’s excellent closing talk at Beyond Tellerrand this week:

Yes, the message of this rather sombre closing talk of this year’s Beyond Tellerrand Conference Düsseldorf is important. Watch it. And then go out, take care of yourself and others, away from the screen. And then come back and publish your own stuff on your own site. Still not convinced? ok, then, please read Matthias Ott’s great article (published on his own site btw), and then start using your own site.

Saturday, November 24th, 2018

Conferencing

I just wrapped up my last speaking gig of the year. It came at the end of a streak of attending European conferences without speaking at any of them—quite a nice feeling!

I already mentioned that I was in Berlin for the (excellent) Indie Web Camp. That was immediately followed by a one-day Accessibility Club conference. It was really, really good.

I have to say, I was initially apprehensive when I saw the sheer amount of speakers on the schedule. I was worried that my attention couldn’t handle it all. But the talks were a mixture of shorter 20 minute presentations, and a few longer 40 minute presentations. That worked really well—the day fairly zipped by. And just in case you think it would hard to have an entire day devoted to accessibility, the breadth of talks was remarkably diverse. Hats off to a well-organised and well-executed event!

The next day was Beyond Tellerrand. This has my favourite conference format: two days; one track; curated; a mix of design and development (see also An Event Apart and Smashing Conference). Marc’s love and care shines through every pore of the event. I thoroughly enjoyed the talks, and the hanging out with lovely people.

Alas, I had to miss the final afternoon of Beyond Tellerrand to head home to Brighton. I needed to get back for FF Conf. It was excellent, as always. Remy and Julie really give it their all. Remy even stepped in to give a (great) talk himself this year, when a speaker couldn’t make it.

A week later, I went to Iceland for Material. I really enjoyed last year’s inaugural event, and if anything, this year’s topped it. I just love how eclectic and different the talks are, and yet it all weirdly hangs together in a thoughtfully curated way. (Oh, and Remy, when you start to put together the line-up for next year’s FF Conf, be sure to check out Charlotte Dann—her talk at Material was the perfect mix of code and creativity.)

As well as sharing an organiser with Accessibility Club, Material had a similar format—keynote talks from invited presenters, interspersed with shorter talks by locals. The mix was great. I won’t even try to describe the range of topics. I’m not sure I could explain how a conference podium morphed into a bar at the end of one of the talks. I think the best description of Material would be to say it’s like the inside of Brian’s head. In a good way.

I was supposed to be back in Brighton for one night after Material, but the stormy weather kept myself and Jessica in Reykjavik for an extra night. Thanks to Brian’s hospitality, we had a bed for the night.

There followed a long travel day as we made our way from Reykjavik to Gatwick, and then straight on to Thessaloniki, where we spent five days even though we only had the clothes we packed for the brief trip to Iceland. (Yes, we went shopping.)

I was there to speak at Voxxed Days. These events happen in various locations around the world, and just a few weeks ago, I spoke at the one in Bristol. It was …different.

After experiencing so many lovingly crafted events—Accessibility Club, Beyond Tellerrand, FF Conf, and Material—I’m afraid that Voxxed Days Thessaloniki was quite a comedown. It’s not that it was corporate per se—I believe it’s organised by developers for developers—but it felt like it was for people who worked in corporate environments. There were multiple tracks (I’m really not a fan of that), and some great speakers on the line-up like Stephanie and Simona, but the atmosphere felt kind of grim in a David Brentian sort of way. It probably wasn’t helped by the cheeky chappie of an MC who referred to one of the speakers as “darling.”

Anyway, I spoke first thing on the first day and I didn’t end up sticking around long. Normally I don’t speak and run, but I didn’t fancy the vibe of the exhibitor hall with its booth-babesque sales teams. Voxxed Days doesn’t pay its speakers so I didn’t feel any great obligation to hang around. The magnificent food and rembetika music of Thessaloniki was calling.

I just got back from Greece, and that wraps up my conference attending (and speaking) for 2018. I’ve already got a couple of events lined up for 2019. I’m delighted to be speaking at the return of Colly’s New Adventures conference. I’m less delighted about preparing a brand new talk I promised—I’m really feeling the pressure to deliver the goods at such an auspicious event with an intimidatingly superb line-up of speakers.

I’m also going to be preparing a different all-new talk for An Event Apart Seattle in March. For once, I’m going to try to make it somewhat practical and talk about service workers. If you know of any other events that might want a presentation like that in 2019, drop me a line.

Perhaps I will see you in Nottingham or in Seattle. If you’re planning on going to New Adventures, use the discount code ADACTIO10 to get 10% of the price of the conference or workshop ticket. If you’re planning on going to An Event Apart, use the discount code AEAKEITH for $100 off.

Friday, May 18th, 2018

What History’s Female Internet Pioneers can Teach us about Tomorrow on Vimeo

The terrific talk from Beyond Tellerrand by Claire L. Evans, author of Broad Band.

As we face issues of privacy, identity, and society in a networked world, we have much to learn from these women, who anticipated the Internet’s greatest problems, faced them, and discovered solutions we can still use today.

Tuesday, September 19th, 2017

Evaluating Technology

A presentation from the Beyond Tellerrand conference held in Düsseldorf in May 2017. I also presented a version of this talk at An Event Apart, Smashing Conference, Render, Frontend United, and From The Front.

I’m going to show you some code. Who wants to see some code?

All right, I’ll show you some code. This is code. This is a picture of code.

Photograph 51

The code base in this case is the deoxyribonucleic acid. This is literally a photograph of code. It’s the famous Photograph 51, which was taken by Rosalind Franklin, the X-ray crystallographer. And it was thanks to her work that we were able to decode the very structure of DNA.

Rosalind Franklin

Base-4, unlike the binary base that we work with, with computers, it’s base-4 A-C-G-T: Adenine, Cytosine, Guanine, Thymine. From those four simple ingredients we get DNA, and from DNA we get every single life form on our planet: mammals, birds, fish, plants. Everything is made of DNA. This huge variety from such simple building blocks.

Apollo 11 Mission Image - Earth view over Central and North America

What’s interesting, though, is if you look at this massive variety of life on our planet, you start to see some trends over time as life evolves through the process of natural selection. You see a trend towards specialisation, a species becoming really, really good at something as the environment selects for fitness. A trend towards ubiquity as life attempts to spread as far as possible. And, interestingly, a trend towards cooperation, that a group could be more powerful than an individual.

Now we’re no different to any other life form, and this is how we have evolved over time from simpler beginnings. I mean, we like to think of ourselves as being a more highly evolved species than other species, but the truth is that every species of life on this planet is the most highly evolved species of life on this planet because they’re still here. Every species is fit for its environment. Otherwise they wouldn’t be here.

This is the process, this long, slow process of natural selection. It’s messy. It takes a long time. It relies on errors in the code to get selected for. This is the process that we human beings have gone through, same as every other species on the planet.

But then we figured out a way to hack the process. We figured out a way to get a jumpstart on evolution, and that’s through technology. Through technology we can bypass the process of natural selection and augment ourselves, extend our capabilities like this.

Acheulean hand ax

This is a very early example of technology. It existed for millions of years in this form, ubiquitous, across the planet. This is the Acheulean hand ax. We didn’t need to evolve a sharp cutting tool at the end of our limb because, through technology, we were able to create a sharp cutting tool at the end of our limb. Then through that we were able to extend our capabilities and shape our environment.

We shape our tools and, thereafter, the tools shape us.

And we have other tools. This is a modern tool, the pencil. I’m sure you’ll all familiar with it. You use it all the time. I think it’s a great piece of technology, great affordance on there. Built in progress bar, and it’s got an undo at the end.

I, Pencil

What’s interesting is if you look at the evolution of technology and you compare it to the evolution of biology, you start to see some of the same trends; trends towards specialisation, ubiquity, and cooperation.

The pencil does one thing really, really well. The Acheulean hand ax does one thing really, really well.

All over the world you found Acheulean hand axes, and all over the world you will find the pencil in pretty much the same form.

And, most importantly of all, cooperation. No human being can make a pencil. Not by themselves. It requires cooperation.

There’s a famous book by Leonard Read called I, Pencil, and it’s told from the point of view of a pencil and describing how it requires cooperation. It requires human beings to come together to fell the trees to get the wood, to get the graphite, to put it all together. No single human being can do that by themselves. We have to cooperate to create technology.

You can try to create technology by yourself, but you’re probably going to have a hard time. Like Thomas Thwaites, he’s an artist in the U.K. You might have seen his most recent project. He tried to live as a goat for a year.

The toaster project

This is from a while back where he attempted to make a toaster from scratch. When I say from scratch, I mean from scratch. He wanted to mine his own metals. He wanted to smelt the steel. He wanted to create the plastic, wire it all up, and do it all by himself. It was a very interesting process. It didn’t really work out. I mean it worked for like a second or two when he plugged it in and then completely burned out, and it was prohibitively expensive.

When it comes to technology, cooperation is built in, along with those other trends: specialisation, ubiquity.

It’s easy to think when we compare these trends in biology and technology and we see the overlap, to fall into the trap of thinking they’re basically the same process, but they’re not. Underneath the hood the process is very different.

In biology it’s natural selection, this long, messy, slow process. But kind of like DNA, it’s very simple building blocks that results in amazing complexity. With technology it’s kind of the other way around. Nature doesn’t imagine the end result of a species and then work towards that end result. Nature doesn’t imagine an elephant or an ostrich. It’s just, that’s the end result of evolution. Whereas with technology, we can imagine things, design things, and then build them. Picture something in our mind that we want to exist in the world and then work together to build that.

Now one of my favourite examples of imagining technology and then creating it is a design school called Chindogu created by Kenji Kawakami. He started the International Chindogu Society in 1995. There’s goals, principles behind Chindogu, and the main one is that these things, these pieces of technology must be not exactly useful, but somehow not all together useless.

Noodle cooler

I’ll show you what I mean and you get the idea. You look at these things and you think, uh, that’s crazy. But actually, is it crazy or is it brilliant? Like this, I think, well, that’s ridiculous. Well— actually, not entirely useless, not exactly useful, but, you know, keeping your shoes dry in the rain. That seems sort of useful.

Butter stick Shoe umbrellas

They’re described as being un-useless. These are un-useless objects. But why not? I mean why not harvest the kinetic energy of your child to clean the floors? If you don’t have a child, that’s fine. It works other ways.

Toddler mop Cat mop

These things, I mean they’re fun to imagine and to create, but you couldn’t imagine them actually in the world being used. You couldn’t imagine mass adoption. Like, I found this thing from the book of Chindogu from 1995, and it describes this device where you kind of put a camera on the end of a stick so you can take self portraits, but you couldn’t really imagine anyone actually using something like this out in the world, right?

Selfie stick

These are all examples of what we see in the history of technology. From Acheulean hand axes to pencils to Chindogu, there are bits of hardware. When we think of technology, that’s what we tend to think of: bits of hardware. And the hardware is augmenting the human. The human is using the hardware to gain benefit.

Something interesting happened in the 20th Century when we started to get another layer in between the human and the hardware, and that’s software. Then the human can interact with the software, and the software can interact with the hardware. I would say the best example of this, looking back through the history of technology of the last 100 years or so, would be the Apollo Program, the perfect mixture of human, software, and hardware.

Apollo 11 Mission Image - View of Moon limb and Lunar Module during ascent, Mare Smythii, Earth on horizon

By the way, seeing as we were just talking about selfies and selfie sticks, I just want to point out that this picture is one of the very few examples of an everyone-elsie. This picture was taken by Michael Collins in the Command Module, and Neil Armstrong and Buzz Aldrin are in that spaceship, and every human being alive on planet earth is also in this picture with one exception, Michael Collins, the person taking the picture. It’s an everyone-elsie.

I think the Apollo program is the pinnacle of human achievement so far, I would say, and this perfect example of this mixture of, like, amazing humans required to do this, amazing hardware to get them there, and amazing software. It’s hard to imagine how it would have been possible to send people to the moon without the work of Margaret Hamilton. Writing the onboard flight software and also creating entire schools of thought of software engineering.

Margaret Hamilton

Since then, and looking through the trend of technology from then onwards, what you start to notice is that the hardware becomes less and less important, and the software is what really starts to count with Moore’s law and everything like that, that we can put more and more complexity into the software. Maybe the end goal of technology is eventually that the hardware becomes completely irrelevant, fades away. This idea of design dissolving in behaviour.

WWW

This idea of the hardware becoming irrelevant in a way was kind of what was at the heart of the World Wide web project created by Tim Berners-Lee when he was at CERN because there at CERN — CERN is an amazing place, but everybody just kind of does whatever they want. It’s crazy. There’s almost no hierarchy, which means everybody uses whatever kind of computer they want. You can’t dictate to people at CERN you all must use this operating system. That was at the heart of the World Wide web project, the idea to make the hardware irrelevant. It shouldn’t matter what kind of computer you’ve got. You should still be able to access information.

Tim Berners-Lee

We kind of take that for granted today, but it is quite a revolutionary thought. We don’t worry about it today. You make a website, of course you can look at it on a Windows device or a Mac or a Linux machine or an iPhone, an iOS device, or an Android device. Of course. But it wasn’t clear at the time. You know back at the time you would make software for specific operating systems, so this idea of making hardware irrelevant was kind of revolutionary.

The World Wide web project is a classic example of a piece of technology that didn’t come out of nowhere. It built on what came before. Like every other piece of technology, it built on what was already there. You can’t have Twitter or Facebook without the World Wide Web, and you can’t have the World Wide web without the Internet. You can’t have the Internet without computers. You can’t have computers without electricity. You can’t have electricity without the Industrial Revolution. Building on the shoulders of giants all the way up.

There’s also this idea of the adjacent possible. It’s when these things become possible. You couldn’t have had the World Wide web right after the Industrial Revolution because these other steps hadn’t yet taken place. It’s something that the author Steven Johnson takes about: the adjacent possible. It was impossible to invent the microwave oven in 16th Century Holland because there were too many other things that needed to be invented in the way.

It’s easy to see this as an inevitable process that, of course electricity follows industrialisation. Of course computers come, and of course the Internet comes. And there is a certain amount of inevitability. This happens all the time in the history of technology where there’s simultaneous inventions and people are beating one another to the patent office by hours to patent, whether it’s radio or the telephone or any of these devices that it seemed inevitable.

I don’t think the specifics are inevitable. Something like the World Wide web was inevitable, but the World Wide web we got was not. Something like the Internet was inevitable, but not the Internet that we got.

The World Wide web project itself has these building blocks: HTTP, the protocol, URLs as identifiers, and HTML was a simple format. Again, these formats are built upon what came before. Because it turns out that making the technology—creating a format or a protocol or spec for identifying things—not to belittle the work, but that’s actually not the hard part. The hard part is convincing people to use the protocol, convincing people to use the format.

Grace Hopper

That’s where you butt up against humans. How do you convince humans? Which always reminds me of Grace Hopper, an amazing computer scientist, rear admiral Grace Hopper, co-inventor of COBOL and the inventor of the compiler, without which we wouldn’t have computing as we know it today. She bumped up against this all the time, that people were reluctant to try new things. She had this phrase. She said, “Humans are allergic to change.” Now, she used to try and fight that. In fact, she used to have a clock on her wall that went backwards to simply demonstrate that it’s an arbitrary convention. You could change the convention.

She said the most dangerous phrase in the English language is, “We’ve always done it that way.” So she was right to notice that humans are allergic to change. I think we could all agree on that.

But her tactic was, “I try to change that,” whereas with Tim Berners-Lee and the World Wide Web, he sort of embraced it. He sort of went with it. He said, “Okay. I’ve got these things I want to convince people to use, but humans are allergic to change,” and that’s why he built on top of what was already there.

He didn’t create these things from scratch. HTTP, the protocol, is built on top of TCP/IP, the work of Bob Kahn and Vint Cerf. The URLs work on top of the Domain Name System and the work of Jon Postel. And HTML, this very simple format, was built on top of a format, a flavour of SGML, that everybody at CERN was already using. So it wasn’t a hard sell to get people to use HTML because it was very familiar.

In fact, if you were to look at SGML back then in use at CERN, you would see these elements.

<body> <title> <p> <h1> <h2> <h3> <ol> <ul> <li> <dl> <dt> <dd>

These are SGML elements used in CERN SGML. You could literally take a CERN SGML document, change the file extension to .htm, and it was an HTML document.

It’s true. Humans are allergic to change, so go with that. Don’t make it hard for them.

Now of course, we got these elements in HTML. This is where they came from. It’s just taking wholesale from SGML. Over time, we got a whole bunch more elements. We got more semantic richness added to HTML, so we can structure our documents more clearly.

<article> <section> <aside> <figure> <main> <header> <footer>

Where it gets really interesting is that we also got more behavioural elements added to HTML, the elements that browsers recognise and do quite advanced things with like video and audio and canvas.

<canvas> <video> <audio> <picture> <datalist>

Now what’s interesting is that I find it fascinating that we can evolve a format like this. We can just keep adding things to the format. The reason why we could do that is because these elements were designed with backwards compatibility built in. If you have an open video tag, closing video tag, you can put content in between there for the browsers that don’t understand the video tag.

The same with canvas. You can put fallback content in there, so you don’t have to wait for every browser to support one of these elements. You can start using it straight away and still provide something for older browsers. That’s very deliberate.

The canvas element was actually a proprietary element created by Apple and other browsers saw it and said, “Oh, yeah, we like that. We’re going to take that,” and they started standardising on it. To begin with, it was a standalone element like img. You put a closing slash there or whatever. But when it got standardised, they deliberately added a closing tag so that people could put fallback content in there. What I’m saying is it wasn’t an accident. It was designed.

Now Chris yesterday mentioned the HTML design principles, and this is one of them—that when you’re creating new elements, new attributes, you should design them in such a way that “the content can degrade gracefully in older or less capable user agents even when making use of these new elements, attributes, APIs, content models.” It is a design decision. There are HTML design principles. They’re very good.

I like design principles. I like design principles a lot. I actually collect them. I’m a bit of a nerd for design principles, and I collect them at this URL:

principles.adactio.com

There you will find design principles for software, for organisations, for people, for schools of thought. There’s Chindogu design principles I’ve collected there.

I guess why I’m fascinated by principles is where they sit. Jina talked about this yesterday in relation to a design system, in that you begin with the goals. This is like the vision, what you’re trying to achieve, and then the principles define how you’re going to achieve that. Then the patterns are the result of the principles. The principles are based on the goals, which result in the patterns.

In the case of the World Wide Web, the goal is to make hardware irrelevant. Access to information regardless of hardware. The principles are encoded in the HTML design principles, and then the patterns are those elements that we get, those elements that are designed with backwards compatibility in mind.

Now when we look at new things added to HMTL, new features, new browser APIs, what we tend to ask, of course, is: how well does it work?

How well does this thing do what it claims it’s going to do? That’s an excellent question to ask whenever you’re evaluating a new technology or tool. But I don’t think it’s the most important question. I think it’s just as important to ask: how well does it fail?

How well does it fail?

If you look at those HTML elements, which have been designed that way, they fail well. They fail well in older browsers. You can have that fallback content. I think this is a good lens to look at technology through because what we tend to do, when there’s a new browser API, we go to Can I Use, and we see, well, what’s the support like? We see some green, and we see some red. But the red doesn’t tell you how well it fails.

Here’s an example: CSS shapes. If you go to caniuse.com and you look at the support, there’s some green, and there’s some red. You might think there’s not enough green, so I’m not going to use it. But what you should really be asking is, how well does it fail?

In the case of CSS shapes, here’s an example of CSS shapes in action. I’ve got a border radius on this image, and on this text here I’ve said, shape-outside: circle on the image, so the text is wrapping around that circle. How well does it fail? Well, let’s look at it in a browser that doesn’t support CSS shapes, and we see the text goes in a straight line.

I’d say it fails pretty well because this is what would have happened anyway, and the text wrapping around the circle was kind of an enhancement on top of what would have happened anyway. Actually, it fails really well, so you might as well go ahead and use it. You might as well go ahead and use it even if it was only supported in one browser or two browsers because it fails well.

Let’s use that lens of asking how well does it work and how well does it fail to look at some of the technologies that you’ve probably been hearing about—some of the buzzwords in the world of front-end development. Let’s start with this. This is a big buzzword these days: service workers.

Service Workers

Who has heard of service workers? Okay. Quite a few.

Who is using service workers? Not so many. Interesting.

The rest of you, you’ve heard of it, and you’re currently probably in the state of evaluating the technology, trying to decide whether you should use this technology.

I’m not going to explain how service workers work. I guess I’ll just describe what it can do. It’s an amazing piece of technology that you kind of install on the user’s machine and then it sits there like a virus intercepting requests, which sounds scary, but actually is really powerful because you can really improve performance. You can serve things from a cache. You get access to the cache API. You can make things work offline, which is kind of amazing, because you’ve got access to those requests.

I was trying to describe it the other day and the best way I could think of describing it was a service worker is like doing a man-in-the-middle attack on your own website, but in a good way—in a good way. There’s endless possibilities of what you can do with this technology. It’s very powerful. And, at the very least, you can make a nice, custom, offline page instead of the dinosaur game or whatever people would normally get when they’re offline. You can have a custom offline page in the same way you could have a custom 404 page.

The Guardian have a service worker on their site, and they do a crossword puzzle. You’re on the train, you’re trying to read that article, but there’s no internet connection. Well, you can play the crossword puzzle. Little things like that, so it can be used for real delight. It’s a great technology.

How well does it work? It does what it says…. You don’t get anything for free with service workers, though. A service worker file is JavaScript, which can actually be quite confusing because you’ll be tempted to treat it like your other JavaScript files and do what you would do to other JavaScript files, but don’t do that. It’s almost like service worker scripts happen to be written in JavaScript, but they require this whole new mindset. So it’s kind of hard to get your head around. It’s a new technology to learn, but it’s powerful.

Well, let’s see what the support is like on Can I Use. Not bad. Not bad at all. Some good green there, but there’s quite a bit of red. If this is the reason why you haven’t used service workers yet because you see the support and you think, “Not enough support. I’m not going to invest my time,” I think you haven’t asked the question, “how well does it fail?” This is where I think the absolute genius of service worker comes in.

Service workers fail superbly because here’s what happens with a service worker. The first time someone visits your site there, of course, is no service worker installed on the client. They must first visit your site, get the downloads, have that service worker installed, which means every browser doesn’t support service workers for the first visit.

Then, on subsequent visits, you can use the service worker for the browsers that support it as this enhancement. Provide the custom offline page. Cache those assets. Do offline first stuff. But you’re not going to harm any of those browsers that are in the red on Can I Use, and that’s deliberate in the design of service workers. It’s been designed that way. I think service workers fail really well.

Let’s look at another hot topic.

Web Components

Who has heard of web components? Who is using web components—the real thing now? Okay. Wow. Brave. Brave person.

Web components actually aren’t a specific technology. web components is an umbrella term. I mean, in a way, service workers is kind of an umbrella term because it’s what you get access to through service workers that counts. You get access to the fetch API and the cache API and even notifications through a service worker.

With web components, it’s this term for a combination of specs, a combination of APIs like custom elements, the very sinister sounding shadow DOM, which is not as scary as it sounds, and there’s other things in there too like HTML imports and template. All of this stuff together is given the label web components. The idea is we’ve already got these very powerful elements in HTML, and it’s great when they get added to HTML, but it takes a long time. The standards process is slow. What if we could just make our own elements? That’s what you get to do with custom elements. You get to make shit up.

<mega-menu> <slippy-map> <image-gallery> <modal-lightbox> <off-canvas>

These common patterns. You keep having to reinvent the wheel. Let’s make an element for that. The only requirement with a custom element is that you have to have a hyphen in there. This is kind of a long-term agreement with the spec makers that they will never make an HTML element with a hyphen in it. Therefore, it’s kind of a safe space to use a hyphen in a made up element.

Okay, but if you just make up an element like this, it’s effectively the same as having a span in your document. It doesn’t do anything. It’s the other specs that make it come to life, like having HTML imports that link off to a file that describes what the browser is supposed to do with this new element that you’ve created.

Then in that file you could have your HTML. You could have your CSS. You could have JavaScript. And, crucially, it is modular. It doesn’t leak through. Those styles won’t leak through to the rest of the page. This is the dream we’ve been chasing: encapsulation. This is kind of the problem that React is solving. This is the reason why we have design systems, to try and be modular and try and encapsulate styles, behaviours, semantics, meaning.

Web components are intended as a solution to this, so it sounds pretty great. How well does it work? Well, let’s see what the browser support is like for some parts of web components. Let’s take custom elements. Yeah, some green, but there’s an awful lot of red. Never mind, as we’ve learned from looking at things like CSS shapes and service workers. But the red doesn’t tell us anything because the lack of support in a browser doesn’t answer the question, how well does it fail? How well do web components fail?

This is where it gets interesting because the answer to the question, “How well do web components fail?” is …it depends.

It depends on how you use the web components. It depends on if you applied the same kind of design principles that the creators of HTML applied when they’re making new elements.

Let’s say you make an image-gallery element, and you make it so that the content of the image gallery is inside the open and closing tag.

<image-gallery>
  <img src="..." alt="...">
  <img src="..." alt="...">
  <img src="..." alt="...">
</image-gallery>

Now in a non-supporting browser this is actually acceptable because they won’t understand what this image-gallery thing is. They won’t throw an error because HTML is very tolerant of stuff it doesn’t understand. They’ll just display the images as images. That’s acceptable.

Now in a browser that supports web components, all those different specs, you can take these images, and you can whiz-bang them up into a swishy carousel with all sorts of cool stuff going on that’s encapsulated; that you can share with other people; that people can just drop into their site. If you do this, web components fail very well. However, what I tend to see when I see web components in use is more like this where it’s literally an opening tag, closing tag, and all of the content and all the behaviour and all the styling is away somewhere else being pulled in through JavaScript, creating a kind of single source of failure.

<image-gallery>
</image-gallery>

In fact, there’s demo sites to demonstrate the power of web components that do this. The Polymer Project, there’s a whole collection of web components, and they created an entire online shop to demonstrate how cool web components are, and this is the HTML of that shop.

<body>
  <shop-app>
  </shop-app>
  <script>...</script>
</body>

The body element simply contains a shop-app custom element and then a script, and all the power is in the script. Here the web component fails really badly because you get absolutely nothing. That’s what I mean when I say it depends. It depends entirely on how we use them.

Now the good news is, as we saw from looking at Can I Use, it’s very early days with web components. We haven’t figured out yet what the best practices are, so we can set the course of the future here. We can decide that there should be design principles for how we collectively use this powerful technology like web components.

See, the exciting thing about web components is that they give us developers the same power that previously only browser makers had. But the scary thing about web components is that they give us developers the same power that previously only browser makers had. With great power, et cetera, et cetera, and we should rise to the challenge of that responsibility.

What’s interesting about both these things we’re looking at is that, like I said, they’re not really a single technology in themselves. They’re kind of these umbrella terms. With service worker it’s an umbrella term for fetch and cache and notifications, background sync — very cool stuff. With web components it’s an umbrella term for custom elements and HTML imports and shadow DOM and all this stuff.

But they’re both coming from the same place, the same sort of point of view, which is this idea that we, web developers, should be given that power and that responsibility to have access to these low-level APIs rather than just waiting for standards bodies to give us access through new APIs. This is all encapsulated in a school of thought called The Extensible Web, that we should have access to these low-level APIs.

The Extensible web is effectively — it’s literally a manifesto. There’s a manifesto for The Extensible Web. It’s just a phrase. It’s not a technology, just words, but words are very powerful when it comes to technology, when it comes to adopting technology. Words can get you very far. Ajax is just a word. It’s just a word for technologies that already existed at the time, but Jesse James Garrett put a word on it, and it made it easier to talk about it, and it helped the adoption of those technologies.

Responsive web Design: what Ethan did was he put a phrase to a collection of technologies: media queries, fluid layouts, fluid images. Wrapped it all up in a very powerful term, Responsive web Design, and the web was never the same.

Progressive Web Apps

Here’s a term you’ve probably heard of over the last couple of days: progressive web apps. Anybody who went to the Microsoft talk yesterday at lunchtime would have heard about progressive web apps. It’s just a term. It’s just an umbrella term for other technologies underneath. Progressive web app is the combination of having your site run over HTTPS, so it’s secure, which by the way is a requirement for running a service worker, and then also having a manifest file, which contains all this metadata. Chris mentioned it yesterday. You point to your icons and metadata about your site. All that adds up to, hey, you’ve got a progressive web app.

It’s a good sounding — I like this term. It’s a good sounding term. It was created by Frances Berriman and her husband, Alex Russell, to describe this. Again, a little bit of a manifesto in that these sites should be responsive and intuitive and they need to fulfil these criteria. But I worry sometimes about the phrasing. I mean, all the technologies are great. And you will actually get rewarded if you use these technologies. If you use HTTPS, you got a service worker, you got a manifest file. On Chrome for Android, if someone visits your site a couple of times, they’ll be prompted to add the site to the home screen just as though it were a native app. It will behave like a native app in the app switcher. You’re getting rewarded for these best practices.

But when I see the poster children for progressive web apps, my heart sinks when I see stuff like this. This is the Washington Post progressive web app, but this is what you get if you visit on the “wrong” device. In this case I’m visiting on a desktop browser, and I’m being told to come back with a mobile browser. Oh, how the tables have turned! It was not that long ago when we were being turned away on our mobile devices, and now we’re turning people away on desktops.

This was a solved problem. We did this with responsive web design. The idea of having a separate site for your progressive web app - no, no, no. We’re going back to the days of m.sites and the “real” website. No. No. I feel this is the wrong direction.

I worry that maybe this progressive web app terminology might be hurting it and the way that Google are pushing this app shell model. Anything can be a progressive web app, anything on the web.

I mean I’ve got things that I’ve turned into progressive web apps, and some of them might be, okay, maybe you consider this site, Huffduffer, as an app. I don’t know what a web app is, but people tell me it might be a web app. But I’ve also got like a community website, and it fulfils all the criteria. I guess it’s a progressive web app. My personal site, it’s a blog, but technically it’s a progressive web app. I put a book online. A book is an app now because it fulfils all the criteria. Even a single page collecting design principles is technically a progressive web app.

I worry about the phrasing, potentially limiting people when they come to evaluate the technology. “Oh, progressive web app, well, that’s not for me because I’m not building apps. I’m building some other kind of site.” I think that would be a real shame because literally every site on the web can benefit from those technologies, which brings me to the next question when we’re evaluating technology. Who benefits from the technology?

Who benefits?

Broadly speaking, I would say there’s kind of two schools of who could benefit from a particular technology on the Web. Does the technology benefit the developer or does the technology benefit the user? Much like what Chris was showing yesterday with the Tetris blocks and kind of going on a scale from technologies that benefit users to technologies that benefit developers.

Now I would say that nine times out of ten there is no conflict. Nine times out of ten a piece of technology is beneficial to the developer and beneficial to the user. You could argue that any technology that benefits the developer is de facto a benefit to the user because the developer is working better, working faster, therefore they can get the website out, and that’s good for the user.

Let’s talk about technologies that directly impact users versus the technologies that directly impact developers. Now personally I’m going to generally fall down on the side of technologies that benefit users over technologies that benefit developers. I mean, you look at something like service workers. There isn’t actually a benefit to developers. If anything, there’s a tax because you’ve got to get your head around service workers. You’ve got a new thing to learn. You’ve got to get your head down, learn how it works, write the code. It’s actually not beneficial for developers, but the end result—offline pages, faster performance—hugely beneficial for users. I’ll fall down on that side.

Going back to when I told you I was a nerd for design principles. Well, I actually have a favourite design principle and it’s from the HTML design principles. It’s the one that Chris mentioned yesterday morning. It’s known as the priority of constituencies:

In case of conflict, consider users over authors over specifiers over theoretical purity.

That’s pretty much the way I evaluate technology too. I think of the users first. And the authors, that’s us, we have quite a strong voice in that list, but it is second to users.

Now when we’re considering the tools and we’re evaluating who benefits from this tool, “Is it developers, or is it users, or is it both?” I think we need to stop and make a distinction about the kinds of tools we work with. I’m trying to work out how to phrase this distinction, and I kind of think of it as inward facing tools and outward facing tools: inward facing tools developers use; outward facing tools that directly touch end users.

I’ll show you what I mean. These are like the inward facing tools in that you put them on your computer. They sit on your computer, but the end output is still going to be HTML, CSS, and JavaScript. These are tools to make you work faster: task runners, version control, build tools—all that kind of stuff.

Now when it comes to evaluating these technologies, my attitude is, whatever works for you. Now we can have arguments and say, “Oh, I prefer this tool over that tool”, but it really doesn’t matter. What matters is: does it work for you? Does it make you work faster? Does it make your team work faster? That’s really the only criteria because none of these directly touch the end user.

That criterion of, “Hey, what works for me”, that’s a good one to apply for these inward facing tools, but I think we need to apply different criteria for the outward facing tools, the tools that directly affect the end user because, yes, we, developers, get benefit from these frameworks and libraries that are written in CSS and JavaScript, but the user pays a tax. The user pays a tax in the download of these things when they’re on the client. It’s actually interesting to see how a lot of these JavaScript frameworks have kind of shifted the pendulum where it used to be the user had to pay a tax if you wanted to use React of Angular or Ember. The pendulum is swinging back that we can get the best of both worlds where you can use these tools as an inward facing tool, use them on the server, and still get the benefit to the user without the user having to pay this tax.

I think we need to evaluate inward facing tools and outward facing tools with different criteria. Now when it comes to evaluating tools, especially tools that directly affect the end user—CSS frameworks, JavaScript libraries, things like that—there’s a whole bunch of questions to ask to evaluate the technology, questions like: what’s the browser support like? What browsers does this tool not work in? What’s the community like? Am I going to get a response to my questions? How big is the file size? How much of a tax is the user going to have to download? All of these are good questions, but they are not the most important question.

The most important question—I’d say this is true of evaluating any technology—is, what are the assumptions?

What are the assumptions?

What are the assumptions that have been baked into the tool you’re about to use, because I guarantee you there are assumptions baked into those tools. I know that because those tools were created by humans. And we humans, we have biases. We have assumptions, and we can’t help but encode those biases and assumptions into what we make. It’s true of anything we make. It’s particularly true of software.

We talk about opinionated software. But in a way, all software is opinionated. You just have to realise where the opinions lie. This is why you can get into this situation where we’re talking about frameworks and libraries, and one person is saying, “Oh, this library rocks”, and the other person is saying, “No, this library sucks!” They’re both right and they’re both wrong because it entirely depends on how well the philosophy of that tool matches your own philosophy.

If you’re using a tool that’s meant to extend your capabilities and that tool matches your own philosophy, you will work with the tool, and you will work faster and better. But if the philosophy of the tool has a mismatch with your own philosophy, you’re going to fight that tool every step of the way. That’s why people can be right and wrong about these frameworks. What works for one person doesn’t work for another. All software is opinionated.

It makes it really hard to try and create un-opinionated software. At Clearleft we’ve got this tool. It’s an open source project now called Fractal for building pattern libraries, working with pattern libraries. The fundamental principle behind it was that it should be as agnostic as possible, completely agnostic to build tools, completely agnostic to templating languages, that it should be able to work just about anywhere. It turns out it’s really, really hard to make agnostic software because you keep having to make decisions that favour one thing over another at every step.

Whether it’s writing the documentation or showing an example, you have to show the example in some templating language. You have to choose a winner in the documentation to demonstrate something. It’s really hard to write agnostic software. Every default you add to a piece of software shows your assumptions because those defaults matter.

But I don’t want to make it sound like these tools have a way of working and there’s no changing it, that the assumptions are baked in and there’s nothing you can do about it; that you can’t fight against those assumptions. Because there are examples of tools being used other than the uses for which they were intended right throughout the history of technology. I mean, when Alexander Graham Bell created the telephone, he thought that people would use it to listen to concerts that were happening far away. When Edison created the gramophone, he thought that people would record their voices so they could have conversations at a distance. Those two technologies ended up being used for the exact opposition purposes than what their inventors intended.

Hedy Lamarr

Here’s an example from the history of technology from Hedy Lamarr, the star of the silver screen the first half of the 20th Century here in Europe. She ended up married to an Austrian industrialist arms manufacturer. After the Anschluss, she would sit in on those meetings taking notes. Nobody paid much attention to her, but she was paying attention to the technical details.

She managed to get out of Nazi occupied Europe, which was a whole adventure in itself. Made her way to America, and she wanted to do something for the war effort, particularly after an incident where a refuge ship was sunk by a torpedo. A whole bunch of children lost their lives, and she wanted to do something to make it easier to get the U-boats. She worked on a system for torpedoes. It was basically a guidance system for radio controlled torpedoes.

The problem is, if you have a radio frequency you’re using to control the torpedo to guide it towards its target, if the enemy figure out what the frequency is, they can jam the signal and now you can no longer control the torpedo. Together with a composer named George Antheil, Hedy Lamarr came up with this system for constantly switching the frequency, so both the torpedo and the person controlling it are constantly switching the radio frequency to the same place, and now it’s much, much harder to jam that transmission.

Okay. But what’s that got to do with us, some technology for guided missiles in World War II? In this room, I’m guessing you’ve got devices that have WiFi and Bluetooth and GPS, and all of those technologies depend on frequency hopping. That wasn’t the use for which it was created, but that’s the use we got out of it.

We can kind of bend technology to our will, and yet there seems to be a lot of times this inevitability to technology. I don’t mean on the front-end where it’s like, “I guess I have to learn this JavaScript framework” because it seems inevitable that everyone must learn this JavaScript framework. Does anyone else feel disempowered by that, that feeling of, “uh, I guess I have to learn that technology because it’s inevitable?”

I get that out in the real world as well: “I guess this technology is coming”, you know, with self-driving cars, machine learning, whatever it happens to be. I guess we’ve just got to accept it. There’s even this idea of technological determinism that technology is the driving force of human history. We’re just along for the ride. It’s the future. Take it.

The ultimate extreme of this attitude of technological determinism is the idea of the technological singularity, kind of like the rapture for the nerds. It’s an idea borrowed from cosmology where you have a singularity at the heart of a black hole. You know a star collapses to as dense as possible. It creates a singularity. Nothing can escape, not even light.

The point is there’s an event horizon around a black hole, and it’s impossible from outside the event horizon to get any information from what’s happening beyond the event horizon. With a technological singularity, the idea is that technology will advance so quickly and so rapidly there will be an event horizon, and it’s literally impossible for us to imagine what’s beyond that event horizon. That’s the technological singularity. It makes me uncomfortable.

But looking back over the history of technology and the history of civilisation, I think we’ve had singularities already. I think the Agricultural Revolution was a singularity because, if you tried to describe to nomadic human beings before the Agricultural Revolution what life would be like when you settle down and work on farms, it would be impossible to imagine. The Industrial Revolution was kind of a singularity because it was such a huge change from agriculture. And we’re probably living through a third singularity now, an information age singularity.

But the interesting thing is, looking back at those previous singularities, they didn’t wipe away what came before. Those things live alongside. We still have agriculture at the same time as having industry. We still have nomadic peoples, so it’s not like everything gets wiped out by what comes before.

In fact, Kevin Kelly, who is a very interesting character, he writes about technology. In one of his books he wrote that no technology has ever gone extinct, which sounds like actually a pretty crazy claim, but try and disprove it. And he doesn’t mean it is a technology sitting in a museum somewhere. He means that somewhere in the world somebody is still using that piece of technology, some ancient piece of farming equipment, some ancient piece of computer equipment.

He writes these very provocational sort of books with titles like What Technology Wants, and The Inevitable, which makes it sound like he’s on the side of technological determinism, but actually his point is a bit more subtle. He’s trying to point out that there is an inevitability to what’s coming down the pipe with these technologies, but we shouldn’t confuse that with not being able to control it and not being able to steer the direction of those technologies.

Like I was saying, something like the World Wide Web was inevitable, but the World Wide Web we got was not. I think it’s true of any technology. We can steer it. We can choose how we use the technologies.

Looking at Kevin Kelly and his impressive facial hair, you might be forgiven for thinking that he’s Amish. He isn’t Amish, but he would describe himself as Amish-ish in that he’s lived with the Amish, and he thinks we can learn a lot from the Amish.

It turns out they get a very bad reputation. People think that the Amish reject technology. It’s not true. What they do is they take their time.

The Amish are steadily adopting technology at their pace. They are slow geeks.

I think we could all be slow geeks. We could all be a bit more Amish-ish. I don’t mean in our dress sense or facial hair. I mean in the way that we are slow geeks and we ask questions of our technology. We ask questions like, “How well does it work?” but also, “How well does it fail?” That we ask, “Who benefits from this technology?” And perhaps most importantly that we ask, “What are the assumptions of those technologies?”

Because when I look back at the history of human civilisation and the history of technology, I don’t see technology as the driving force; that it was inevitable that we got to where we are today. What I see as the driving force are people, remarkable people, it’s true, but people nonetheless.

Rosalind Franklin Margaret Hamilton Grace Hopper Hedy Lamarr

And you know who else is remarkable? You’re remarkable. And your attitude shouldn’t be, “It’s the future. Take it.” It should be, “It’s the future. Make it.” And I’m looking forward to seeing the future you make. Thank you.

Monday, July 10th, 2017

Off the Beaten Track · Matthias Ott – User Experience Designer

I love the way Matthias sums up his experience of the Beyond Tellerrand conference. He focuses on three themes:

  • Rediscovering originality,
  • Storytelling with code, and
  • Adopting new technologies.

I heartily agree with his reasons for attending the conference:

There are many ways to broaden your horizons if you are looking for inspiration: You could do some research, read a book or an article, or visit a new city. But one of the best ways surely is the experience of a conference, because it provides you with many new concepts and ideas. Moreover, ideas that were floating around in your head for a while are affirmed.

Tuesday, May 23rd, 2017

Evaluating Technology – Jeremy Keith – btconfDUS2017 on Vimeo

I wasn’t supposed to speak at this year’s Beyond Tellerrand conference, but alas, Ellen wasn’t able to make it so I stepped in and gave my talk on evaluating technology.

Thursday, November 10th, 2016

From Pages to Patterns – Charlotte Jackson - btconfBER2016 on Vimeo

The video of Charlotte’s excellent pattern library talk that she presented yesterday in Berlin.

Wednesday, May 11th, 2016

Jeremy Keith on Vimeo

Here’s the video of the talk I just gave at the Beyond Tellerrand conference in Düsseldorf: Resilience.

Friday, December 11th, 2015

An Event’s Lifecycle: The Highs, The Lows, The Silence // beyond tellerrand

I can certainly relate to everything Marc describes here. You spend all your time devoted to putting on an event; it’s in the future, coming towards you; you’re excited and nervous …and then the event happens, it’s over before you know it, and the next day there’s nothing—this thing that was dominating your horizon is now behind you. Now what?

I think if you’ve ever put something out there into the world, this is going to resonate with you.

Sunday, September 6th, 2015

Enhance!

A presentation on progressive enhancement from the Beyond Tellerrand conference held in Düsseldorf in May 2015.

Es ist mir eine Freude—und eine Überraschung—wieder hier zu sein. No, really good to be back at Beyond Tellerrand. So I’ve been here in the odd years. I was here year one, year three, and now it’s year five. So it’s like the opposite of Star Trek films. It’s only the odd years that I’m here.

Today, what I’d like to do is I’d like to change your mind. When I say, “Change your mind,” I don’t mean I want you to reverse a previously help position. No, I mean I literally want to change your mind, as in rewire your brains.

That might sound like quite a difficult task: to rewire the brains of another human. But, the truth is, we rewire our brains all the time, right? When you see something, and once you’ve been shown it, you can’t un-see it. Well, that’s because you’ve had your mind changed. Your brain has been rewired.

Like the first time someone shows you the arrow in the FedEx logo, right, between the E and the X, and then every time you see the FedEx logo, all you see is the arrow, right? You can’t un-see that. You’ve all seen the arrow, right? Okay, good. Right?

Or the Toblerone logo, are you guys familiar with this? Who sees the bear in the Toblerone? About half the room. [Laughter]

Right? So now the other half of the room have just had their brains rewired because you’ll always see the bear.

Consider the duck—a perfectly ordinary, everyday duck. But then somebody, usually on the Internet, tells you all ducks are actually wearing dog masks. All ducks are actually wearing dog masks. [Applause]

Wait, wait, wait, wait, wait. When I show you the same picture of the exact same duck …so I have already succeeded in rewiring your brains.

But these are all very trivial examples, right, of having your brain rewired. There are much more important examples we’ve seen throughout history like Copernicus and Galileo with their heliocentric model of the solar system rather than the geocentric model. And it changed our understanding of our place in the universe.

What’s interesting about these kinds of brain rewiring, fundamental shifts is that nothing actually changes in the world itself, right? The earth always orbited around the sun, not the other way around. And yet, after Copernicus and Galileo, everything changed because our understanding of our place in the universe changed.

Or when Charles Darwin finally published his beautiful theory of evolution by natural selection, again, nothing actually changed in the natural world. Natural selection had been going on for millennia. And yet, everything changed because our understanding of our place in the natural world changed with Darwin.

I love this, by the way. This is a page from Darwin’s sketchbook. It’s one of my favorite sketches of all time where you literally see the idea forming in the sketch he made. What it reminds me of is this: This is another paper. This one sits behind a class case in CERN. “Information Management: A Proposal.” This is by Tim Berners-Lee, and this would go on to become the World Wide Web. This was something he had to present to his supervisor, Mike Sendall, and you can see what Mike Sendall wrote at the top. He wrote, “Vague, but exciting.” [Laughter]

Gave the web its go ahead. And in a way, what Tim Berners-Lee had to do then— it wasn’t enough to just invent, you know, HTTP, HTML, and URLs—he had to convince people that this was a good way of managing information. He had to rewire people’s brains. This idea of this network that has no centre where anybody can add a new node to the network; that requires some fundamental shifts …and the idea that anybody could access it. You didn’t need a particular computer or particular operating system. That this would be for everyone. Right, we had to rewire our brains to get that, to understand this decentralisation.

And then comes the problem of designing, developing for this new medium. How do we get our heads around it? Well, at first, we kind of don’t. At first what we do is we take what we already know from the previous medium and apply it.

Does anyone remember this book? Oh, yeah. Okay. We’re showing our age now. Creating Killer Websites, by David Siegel. It’s an old book. This—this was the guy who came up with the idea of using the one pixel by one pixel spacer gif, right, and giving it different dimensions. Tables for layout, right, all these hacks that we used to do to design for the web.

They were hacks, but they were necessary hacks because we didn’t have any other way of doing it until, you know, Web Standards came along. But, fundamentally, our idea of design was how do we make it look as good as the printed page? How do we make it look as good as what we’re used to from magazines, from designing for print?

And, of course, when you compare the web on that metric, especially 20 years ago, the web seemed woeful, right? 216 colors, 1 font: It seemed pretty hard to create killer websites. But people, even back then, were making the point that this isn’t the way to go around it. That what we should do is truly rewire our brains and accept the web for what it is.

John Allsopp wrote, 15 years ago—15 years ago, he wrote an article A Dao of Web Design. Who’s read A Dao of Web Design by John Allsopp? You are my people. The rest of you, please read A Dao of Web Design by John Allsopp. It’s wonderful.

What makes it wonderful, partly, is the fact that it’s still so relevant. I mean, you can’t say that about many articles about the Web that are 15 years old; that are more relevant today than the day they were written. Essentially what he’s arguing for is that we accept the web as the web. We embrace flexibility and ubiquity. Embrace that unknown nature of the web rather than trying to fight it, rather than trying to treat it like the medium that came before, right? As if it’s a poor, second cousin to print.

John pointed out that this isn’t new. This always happens. What happens is, a new medium comes along, and what we initially do is we take on the tropes of the medium that came before.

When radio came along, people did theatre on the radio. Then when television came along, they did radio, but on television. In each case, it took a while for each new medium to develop its own vocabulary.

Scott McLeod talked about this very same thing in his great book Understanding Comics. A different medium, but he noticed the same trend. We take what we know from the medium before and then apply it to this new medium, before we really get our heads around it, before we change our minds, rewire our brains.

When I look back at the history of design and development on the web, I think the brain rewiring started to happen because of this group, the Web Standards Project. When we think of the Web Standards Project today, we think of their work in convincing browser makers to support the standards, right? Lobbying Internet Explorer and Netscape to support things like CSS, but that was only half their work.

The other half of the work of the Web Standards Project was convincing us, designers and developers, to embrace the web, to use Web Standards. Like people like Jeffrey Zeldman writing books like this. I’ve met people who say that this book changed their minds. It rewired their brains. They weren’t the same person after reading this book as they were before.

I guess the central message that the Web Standards Project, Jeffrey Zeldman, all these standardistas were getting across back then was trying to get away from this idea that your presentation and your structure will be all clumped together in HTML and separated out, and that we could do that using Web Standards like CSS. And so that we could allow HTML to be HTML, and be used for structuring content, and allow CSS to be used for presentation.

Now, it’s all very well to read this or have someone tell you this. But, to truly have your mind changed and to, like, get it, get that lightbulb moment, I think there’s one website that did that. It was Dave’s website, the CSS Zen Garden, right? This was a machine for rewiring brains.

I had heard, yeah, okay, separation of presentation and structure. I get it. But then when you’re looking through, you go, whoa. This is actually the same HTML with different CSS, and the design could change that much. That’s when you really get it.

Remember that “a-ha” moment looking at the Zen Garden? You’re like, okay, now I get it—the separation of presentation and structure.

Of course, there’s the third layer we have on the Web, which is JavaScript, and that’s there for behaviour. Structure, presentation, and behaviour: that’s the broad idea behind progressive enhancement; that we have these three layers of building, one on top of the other. I usually illustrate this with the upper back torso of my friend Lynn because she’s really into Web Standards and this awesome tattoo that we have structure/HTML, presentation/CSS, and behaviour/JavaScript.

What this reminds me of is something I remember reading from the world of architecture. There’s a book called How Buildings Learn by Stewart Brand, a really good book. He talks about this concept of shearing layers or pace layers, that buildings themselves have different layers that they build upon that move at different paces, at different time scales.

The site of a building is on the geological time scale. It shouldn’t really change at all. The structure is also a fairly long-lasting thing. Then we build up. We build the walls. We build the rooms. And, within the rooms, we can move stuff around on a daily basis, but you’re not going to change the underlying structure very often, maybe a century or two, right?

I think this is useful for thinking about the web. On the web, I guess our site would be our URLs, the thing that shouldn’t change. Cool URLs don’t change. Then, on top of that, we get our structure with HTML. That’s what it’s there for.

There’s something in the design of HTML that’s really powerful, and it seems really simple, but actually it’s incredibly powerful. That’s this fault tolerant nature of HTML. It’s designed to be fault tolerant.

To explain what I mean, let’s look at what happens when you give a web browser an HTML element, an element with an opening tag and a closing tag, some text in between. Well, the browser is going to display the text in between the opening and closing tag. It’s standard behaviour.

Where it gets interesting is when you give a browser an element it doesn’t understand, right? It still just displays the text between the opening and closing tag, even though it doesn’t recognise that element. See, why this is interesting is what the browser does not do.

The browser does not throw an error to the end user. The browser does not stop parsing the HTML at this point and refuse to parse any further. It just sees something it doesn’t understand, renders the text between the tags, and carries on.

You all know this. This is a pretty simple facet of HTML. Yet, this is what allows HTML to grow over time. Because of this behaviour, we can start adding extra richness to HTML, introduce new elements, secure in the knowledge that older browsers will display that text in between the opening and closing tags. It won’t throw an error. It won’t stop parsing.

We can use that in the design of new elements to create fallback content. The fact that canvas has an opening and closing tag was a deliberate design decision. It initially came from Apple, and it was a self-closing tag. When it became a standard, they made sure they had an opening and closing tag so that they could provide fallback content for older browsers because of that fault tolerant nature of HTML.

The browser sees something it doesn’t understand. It just renders what’s in between the opening and closing tags. We get it with canvas. We get it with video. We get it with audio. Now we get it with picture.

This fault tolerant nature of HTML has allowed HTML to grow and evolve over time. When you think about it, the age of HTML is crazy. It’s over 20 years old, and it still works. You might say it’s a completely different HTML at this point, but I see it as an unbroken line. That is, it is still the same HTML that we had over 20 years ago.

It’s kind of like the Ships of Theseus paradox, like your grandfather’s axe. This axe has been in the family for generations. The handle has been replaced three times, and the head has been replaced twice. It’s like this philosophical question. Is it still the same axe?

If you’re thinking to yourself, “Of course it’s not the same axe, because the handle has been replaced three times, and the head has been replaced twice,” then I would remind you that no cell in your body is older than seven years, and yet you consider yourself to be the same person you were as a child—something to think on. [Laughter]

And what this allows for, this fault tolerant nature, is that we can grow HTML and, therefore, achieve a kind of structural honesty by using the right element for the job. Again, this is an architectural term, just the idea that you use the correct structure. Other than having a façade of something, you’re actually using the right element to mark something up. So, using tables for layout, that’s not structurally honest because that’s not what tables are for.

An example of structural honesty is if you need a button on a web page, you use the button element, right? It seems pretty straightforward. Yet, and yet, and yet, time and time again, I see stuff like this. Right? Maybe you’ll have class=button, role=button. An event handler, on click, make this behave exactly like a button. Call my lazy. I would just use a button.

Then there’s CSS, which we use for our presentation. CSS is also fault tolerant, which is also extremely powerful and, I think, has added to the robustness of CSS.

Just stop for a minute and think about all the websites out there using CSS, which is pretty much all of them now, right? You think about how different they are, how varied they look, how varied they are in scope, how different their CSS must be.

Yet, all the CSS on all of those websites, it boils down to one simple pattern—I think, a beautiful pattern—and it’s this: You have a selector, you have a property, and you have a value. That’s it. That is all of CSS.

We have some, you know, nice syntactic sugar so that the machines can parse this stuff, but this is it. This is what all of CSS is. Again, that is really powerful. What’s powerful about it is the fault tolerant behaviour.

Here’s what happens if you give a web browser a selector it doesn’t understand. It just doesn’t parse whatever is in between the opening and closing curly braces. Again, what’s interesting here is what the browser doesn’t do. It does not throw an error to the end user. It does not stop parsing the CSS at this point and refuse to parse any further.

Likewise, you give it a property it doesn’t understand; it just ignores that line. The same with the value: Give it a value it doesn’t understand, it ignores that line, moves on to the next one. That’s really powerful. That means, as new features start to arrive, we can start to use them straightaway, even if they aren’t universally supported because, what’s going to happen in the older browsers? Nothing. And that’s absolutely fine.

We get a kind of material honesty of using the right CSS for the job in the same way we get structural honesty with HTML. When we used to want rounded corners, we’d have to slice up a circle and put four background images and an element. Now we can just say border-radius, right? We get this material honestly from the fault tolerant nature of CSS, just as we get a structural honestly from the fault tolerant nature of HTML.

Then there’s JavaScript, not fault tolerant. To be fair, I don’t think it could be because JavaScript isn’t a declarative language in the same way that HTML and CSS is. HTML and CSS can afford to just ignore things that they don’t understand, right? JavaScript is a programming language. It’s a scripting language.

You actually kind of want the scripting language to tell you when you’ve done something wrong. You want it to throw an error. Debugging would be really, really hard if every time you made a mistake in a programming language, your environment just want, “Eh, don’t worry about it. Don’t worry about it,” right?

JavaScript will throw an error. If you give a browser some JavaScript it doesn’t understand, it will throw an error. It will stop parsing the JavaScript at that point and refuse to parse any further. So, it’s far more fragile than HTML or CSS.

Now, that’s okay as long as we use JavaScript the right way. As long as we’re aware of that fragility in comparison to the robustness of HTML and CSS, that’s absolutely fine. It’s just, we need to be aware of having safe defaults when we’re building. The safe defaults will be, well, your HTML, your structure, needs to be in place, right? Your CSS, you can’t rely on it, but if it doesn’t work, it’s not the end of the world.

What I’m saying is use JavaScript to enhance your sites, but don’t rely on JavaScript because of that fragile nature. Again, don’t get me wrong. I’m not saying, “Don’t use JavaScript.” I love JavaScript. I’ve written books on JavaScript.

JavaScript is absolutely awesome. But relying on JavaScript is a really dangerous game because of that fragility. I kind of think of it as like the electricity of the web in the same way as, in product design, you want to use electricity to turbo charge a system, turbo charge a product, turbo charge a building. But you don’t want to rely on electricity.

Jake Archibald, who is riffing on the Mitch Headberg joke, put it nicely when he said that, “When an elevator fails, it’s useless. When an escalator fails, it becomes stairs.” So, on the web, “We should be building escalators, not elevators.”

It makes a lot of sense to me. It’s a robust way of building. Yet, and yet, and yet, I see stuff like this. This is Instagram.com if the JavaScript fails. It has finished loading at this point. Nothing more will come into the page. There are many, many sites out there like that. Effectively, what’s happened here is that JavaScript has become a SPOF, a Single Point Of Failure in the way that HTML or CSS are very unlikely to do because of their fault-tolerant nature.

It seems very strange to me when confronted with these three layers of the web—HTML, CSS, JavaScript—that we would put all our eggs into the most fragile layer, right? That we’d turn the one with the fragile parsing into our Single Point Of Failure.

It’s all fun and games to point at sites like this where, if you switch off JavaScript, you get no content, but that’s not what this is about. That’s not what progressive enhancement is about. It’s not about people who switch off JavaScript. Who switches off JavaScript, right? Browsers are making it very, very difficult for people to choose to switch off JavaScript.

It’s about JavaScript failing for reasons you don’t even know. Maybe it happens on the server. Maybe it happens on the browser. Maybe it happens on the network in between. Just circumstances that are out of your control. That’s why you want to be building in a robust way.

This is Andy Hume. He puts it this way. He said, look, “Progressive enhancement is much more about dealing with technology failing than technology being supported,” right?

It isn’t, “Oh, we need to think about making it work in browsers that don’t have JavaScript.” No. Every browser doesn’t have JavaScript until the JavaScript loads. Things happen, and you need to embrace that you’re going to lose some of those packets. If it’s HTML or CSS, that’s going to be okay. If it’s JavaScript, that’s not going to be okay if you’re relying on the JavaScript.

What Andy is saying here, I think, was nicely paraphrased or summed up in a different way by my friend David who said, “Look, it’s simple. Build your apps so they aren’t a twirling shitshow of clown horns when JavaScript breaks.” Right? Seems pretty straightforward.

Perhaps more eloquently, Derek Featherstone said, “In the web front-end stack—HTML, CSS, JavaScript, and ARIA—if you can solve the problem with a simpler solution lower in the stack, you should,” right? “It’s less fragile, more foolproof, and it just works.”

Again, Derek is an accessibility guy, and he’s not making the argument here that it’s about access, that it’s about reach, about providing the service to everyone. No, no, he’s pointing out that, from an engineering point of view, this makes more sense. Foolproof, less fragile, it just works: that’s the reason to work this way.

What all these people are saying, effectively, is a reformulation of an existing principle, a principle by this man, John Postel. This is Postel’s Law, or The Robustness Principle:

Be conservative in what you send; be liberal in what you accept.

I see Postel’s Law in action all the time. Browsers: the way that browsers handle HTML and CSS, that fault-tolerant error-handling, that’s Postel’s Law in action. They have to be liberal in what they accept because there’s a lot of crap HTML out there, so they can’t throw an error every time they see something they don’t understand.

I see the robustness principle in action all the time, not just in web development, but in design as well. In the world of UX, let’s say you’re making a form on the web. Well, you want to be conservative in what you send. Don’t send the really long form with lots of form fields. Send as few form fields as possible down the wire. But then, when the user is inputting into that form, be liberal in what you accept. Don’t make the user format their credit card number or their telephone number with spaces or without spaces. Be liberal in what you accept. That’s just another example of Postel’s Law in action.

I love stuff like this because I’m kind of obsessed with design principles, this idea that these things are there. You might as well make them visible, make them public, write them down, put them on the wall because design principles are inherent in anything that humans build. We can’t help but imbue what we build with our own beliefs, with our own biases. That’s certainly true of software.

Software, like all technologies, is inherently political. Code inevitably reflects the choices, biases, and desires of its creators.

We talk about opinionated software. The truth is, to a certain degree, all software is opinionated. That’s okay as long as you recognise it, as long as you realise when you’re taking on the philosophy of the piece of software. Then you can decide whether you want to go along with it.

A simple example: If you’re using a graphics design tool like Photoshop to create a website. To be fair, Photoshop was never intended for creating web pages. It’s for manipulating photographs.

Let’s say you’re trying to design a web page in Photoshop. Well, you fire up Photoshop. You hit Command+N for a new document. The first thing it asks you for is a width and a height, a very fundamental design decision that maybe you’re not even conscious of making so early on in the process.

At the other end of the spectrum, if you have a Content Management System and that Content Management System has been made with certain assumptions about where the content will be viewed or what kind of devices will be viewing that content. If, in further years down the line, those assumptions turn out not to be true, you’re basically butting heads with the people who created that software. With any piece of software, you need to evaluate it on that basis.

If you’re choosing a framework, a front-end library or something, there are all these different things to evaluate. What’s the file size? What’s the browser support? What’s the community like? All really important questions, but actually the most important question is: Does the philosophy of this piece of software match my own philosophy? That way, if it does, you’ll work with it, right? It’s a tool that’ll make you work faster, and that’s the whole idea.

If it doesn’t match your philosophy, you’re going to be fighting it the whole way. This is why it’s possible for one group of developers to say, “This framework rocks,” and another group to say, “This framework sucks,” right? They’re both right and they’re both wrong at the same time. It’s entirely subjective.

We have a whole bunch of different tools we use in web development, and I kind of put them into different buckets, but these ones have become particularly popular in recent years, sort of bigger JavaScript libraries. Worryingly, people are putting more of the core content and functionality into the most fragile layer of the stack. I’ve sort of arranged them here in increasing order of opinionatedness.

If I’m trying to work in a progressive enhancement kind of way, and I take a look at Backbone, yeah, I could probably make it work. It does URL routing with a fairly light touch. I can probably work with it.

Then we get to Angular. It’s like, yeah, not so much. I mean maybe I could use a subset of Angular and still build in this progressive enhancement kind of way, thinking in this layered way. But, Angular actually has a way of thinking, right? There’s an Angular way of doing things. And, to get the most use out of Angular, you kind of need to accept its philosophy.

Then there’s Ember, which is like, no, no, no, very opinionated, like: JavaScript is everything. Forget HTML. Open body. Close body. That’s all you need, everything done in JavaScript.

If you’re going to choose to use one of these, make sure that you understand what you’re taking onboard. Make sure that you agree with its philosophy. If you do, that’s great. These are excellent tools that’ll help you work faster. But, if you don’t agree with them, don’t use them, because you’re going to be fighting the whole way.

You know, I was listening to an episode of Shop Talk Show, the great podcast that Chris Coyier and Dave Rupert do. They had John Resig on the show. They were asking him about these libraries and why he thought they were getting so popular. He, you know, would have a good opinion on this having created jQuery all those years ago.

He said something interesting about these big sort of monolithic libraries. He said, you know, “No one wants to think that what they’re doing is trivial.” I think there’s really something to that.

The way that these things are marketed is like these are for complex apps, right? You’re working on hard things. You need a really powerful framework like Angular or Ember. And it’s true; no one likes to think that they’re problems they’re working on just aren’t that difficult.

If you were at a cocktail party and someone asks you what you do, you describe your daily work, and then they said, “Yeah, that sounds pretty easy,” you’d be offended, right? That’s an insult that someone would say your work sounds easy. But if you describe what you do and someone says, “Wow, that sounds hard,” you’re like, “Yeah.” [Laughter] “Yeah, it is hard.”

You know, these libraries are like, “Oh, the stuff you work on is so hard. You need this library.” You’re like, “Yeah, I am working on really tough programs.” But these are frameworks for building elevators, not escalators.

Tom Dale is one of the creators of Ember. He said something a while back. He, by the way, is changing his tune. He’s coming around to the progressive enhancement thing, which is wonderful to see. But a while back he said, look, “JavaScript is part of the web platform. You don’t get to take it away and expect the web to work.”

Now, I disagree with this, but maybe not for the obvious reasons that you might think, which is that second clause. But actually, I take issue with the first clause, “JavaScript is part of the web platform.” What I take issue with is this framing of the web as a platform. I don’t think it is.

Again, language can be so important. Simon talked about this this morning, the importance of language. There’s this idea of political language where our words can subtly affect how we talk about things. This happens in English a lot, you know, political debates. You talk about collateral damage or friendly fire, right, weasel words that obfuscate their meaning.

But also, political language like if you were about to have a debate on tax relief. Well, before the debate has even begun, you’ve framed tax as something you need relief from, right? The same way if we’re talking about the web platform. Don’t get me wrong. There are great people using this phrase: webplatform.org, Web Platform Daily - wonderful, wonderful resources. But, the web platform …the web isn’t a platform.

If you think about what a platform is, you know, it’s an all or nothing system. I get it from a marketing point of view when you put the web on the same level of something like, you know, Flash, which is a platform, or iOS or Android, which is a platform. It’s kind of cool that the web can sort of put itself on that same level. It’s kind of amazing. I could wake up and go: I’m going to build an application. Now, should I build it in iOS, Android, or the web?

The fact that that’s even a question is kind of awesome, but it’s a bit misleading because the way that a platform works is, okay, I build something using the Flash platform and, if you have the Flash plugin, you get 100% of what I’ve built. But, if you don’t have the Flash plugin, you get nothing. 100% or nothing: those are your options.

The same if I build for an iOS device, an iOS app, and you’ve got an iOS device. You get what I’ve built, 100% of what I’ve built. But if I build an iOS app and you’ve got an Android device, you get zero of what I’ve built.

If I build something on the web, maybe you’ll get 100% of what I’ve built. Maybe close to it, 90%, 80%. But the important thing is that you don’t necessarily get zero, that you get something. And, if I’m building it the right way using progressive enhancement, you’re at least going to get the content. You’re at least going to get the HTML. Maybe you’ll get CSS. Maybe not all the CSS, but you’ll get some of the JavaScript, maybe not all the JavaScript.

The web is not a platform. The web is a continuum. To treat the web as a platform is a category error.

Just as we made the mistake of trying to get our heads around the web and thought of it as print design, now we’re making the same mistake as thinking that the web is software, just like any other software. We can’t treat building for the web the same way we treat building for any other platform. The web is fundamentally different.

I see sentiments like this. Joe Hewitt, an incredibly smart guy, frustrated by the web. He said, “It’s hard not to be disappointed by the HTML if you’ve developed for iOS, Windows, or other mature platforms as I have.” Yeah, if you’re going to judge it on that level, as if the web were a platform, I totally understand where your frustration is coming from. But the web isn’t a platform. The whole point of the web is that it’s cross-platform, that it doesn’t matter whether you’ve got iOS or Android, or what plugin you do or don’t have installed, that you get something on the web.

But what you have to understand about Joe’s frustration here when he said this, what he was trying to accomplish on the web was, he was trying to get smooth scrolling to work, which, yeah, okay, that is tougher on the web than it is in native. And all of these kinds of interactions—tapping, dragging, swiping—is kind of a pain in the ass to do this stuff on the web. But then you take a step back, and you realise, hang on, hang on. These are all sort of surface level implementation details on an interface. No one wakes up in the morning and thinks about these verbs, right? No one is like: I’m really looking forward to swiping today. [Laughter]

If you look below the implementation surface level to what people are actually trying to do, well, these verbs become more important, that people are trying to find stuff. They’re trying to publish stuff, buy stuff, share stuff. Then if you ask yourself, okay, how can I make this happen? You find you can do that pretty low down in the stack. Usually just HMTL will get you this far. Then you can enhance, and then you can add on the swiping and the tapping and the dragging and all of that stuff as an enhancement on top of the more fundamental semantic verbs lying underneath.

I think something that’s helped us get our head around this idea of what the web is, is responsive web design. Again, Simon talked about language, the importance of language. What Ethan did by coining this phrase and giving it a definition was, he helped rewire our brains to understand the web.

It’s interesting. In Ethan’s article when he first introduced the idea of responsive design, he references A Dao of Web Design by John Allsopp, building on top of that existing work. And, it is another term from architecture: responsive design. I feel like it goes hand-in-hand with progressive enhancement. If you think about what Ethan taught us was that, if you’re doing it right, layout is an enhancement.

Here’s the first website ever, the first website ever made, made by Tim Berners-Lee published on CERN. This is how it would look in a small view port. This is how it would look in a slightly larger view port, slightly larger again, right up to a wide screen view port. It’s responsive.

This may seem like a trivial, silly, little thing. Of course, there’s no CSS, right? Well, exactly. It starts off being responsive. The problem was never that websites weren’t responsive and we had to figure out how to make them responsive. No, no, no. The problem was we screwed it up. The web was responsive all along, and then we put that fixed width on it. We decided that websites were supposed to be 640 pixels wide, and then 800 pixels wide, and then 960—the magic number—wide.

Instead of talking about making a website responsive, we should actually be talking about keeping a website responsive. You get your content. You structure it in HTML. It’s responsive. You start adding CSS; the trick is that, in every step of the way, to make sure you’re not screwing up the inherent flexibility of the web. That rewiring of your brain is a different way of looking at the problem can make all the difference.

But, to think that way, to truly accept it that that’s the way to build, you kind of have to answer a fundamental question, and it’s this question: Do websites need to look exactly the same in every browser? I’m pretty sure at this point we all know the answer. If you don’t know the answer, you can find out by going to the URL dowebsitesneedtolookexactlythesameineverybrowser.com, built by Dan Cederholm, where you can see the answer, which is, “No!”

But, depending on the user agent that you happen to be visiting the site with, that will look slightly different because, hey, websites do not need to look exactly the same in every browser. Just to make sure that we’re all on the same page here, I’m going to ask for just one piece of audience participation if you could help me answer this question, please. Ladies and gentlemen, do websites need to look exactly the same in every browser?

No!

Good. That was pretty resounding, and that’s great because, if you truly believe that, if you accept that, then suddenly all the stuff that we’re afraid of like, “Oh, my God. There are so many devices, so many different browsers, so many different APIs, so many different screen sizes.” All of this stuff that we’re frightened of, if you accept that websites do not need to look the same in every browser, then it stops being something to be frightened of. It becomes something to embrace.

It actually starts to get really fun. I’ll finish with an example of what I mean. I’ll show you a pattern. This is, I’ll admit, a very, very simple pattern. It’s a navigation pattern, but to demonstrate sort of progressive enhancement and responsive design in action.

This is a pattern I first saw in Luke Wroblewski’s old startup, Bagcheck, where, to reveal the navigation, you can see there’s a trigger in the top corner there. If you hit that, you get the navigation. Now, what’s actually happened is that was nothing more than a hyperlink to a fragment identifier at the bottom of the page. You were jumped down to the bottom of the page where the navigation sits.

I really, really like this pattern because that’s going to work everywhere, right? Following links, that’s pretty much what browsers do. So, you know if you start with this, it’s going to work everywhere. I’ve used it on websites, right? You have that trigger. You hit the trigger. It’s going to go down to the navigation. Have something to dismiss the navigation. Actually, all that’s happening under the hood is you’re just jumping to a different part of the same page.

But here’s the great thing about progressive enhancement, about building for the web, is that you don’t have to stop here. Now that you’ve got that working, you’ve got something that works literally everywhere, you can build on top of that. You can enhance that.

A website I was working on with Stephanie, actually, we had some various navigation stuff going on. You’ve got search. You’ve got the “more” link. You’ve got the Menu. To begin with, all of that worked the same way. They were hyperlinks to fragment identifier further down the page, and you just followed those links.

But then I was able to enhance and say, okay, well, what if when you hit search, it slides in from the top? We can do that. JavaScript, CSS: we can do that.

What if that “more” menu is an overlay and sort of progressive disclosure on top of the content? Yeah, we can absolutely do that. Let’s have that menu slide in, in that off-canvas kind of way. Absolutely. Not a problem. If any of that doesn’t work, that’s fine. Websites do not need to look the same or behave the same in every browser.

Now, in order to do this, I would have to make sure that the browser understands the JavaScript I’m using because, remember, JavaScript isn’t fault tolerant. I don’t need to test for HTML. I don’t need to test for CSS. I do need to test for JavaScript.

The BBC had this lovely phrase they used called “Cutting the mustard,” where you’re literally checking to see if the browser understands what you’re about to do. In my situation, I was using querySelector, and I was using addEventListener. So I have an if statement to say, “If you understand these things, great. We’re going to do some JavaScript,” and that’s it.

There are two interesting things to notice about this pseudo code here. One is, I am detecting features. I am not detecting browsers. I am not looking at a browser user agent string. After listening to PPK, I think you understand why, right? [Laughter] It’s a mug’s game. Just don’t.

The other interesting thing here is that there is no else statement, right? If the browser understands these features, it gets these features. If it doesn’t, it doesn’t. Why? Because websites don’t need to look the same in every browser. I’m not going to spend my time making an older browser understand something it doesn’t understand natively, right?

To give you an example, let’s say I’m using media queries, as I am. It’s a responsive design. And I’m building it the right way, so I’ve got my usual styles outside the media queries. Then I put all my layout styles inside media queries. Well, some older browsers like Internet Explorer 8 or 7, they’re not going to understand those styles because they don’t support media queries.

What do I do about those styles inside the media queries? What do I do about Internet Explorer 8 and 7? Nothing. It’s perfectly fine. The content is well structured. It can stand on its own. Layout is an enhancement. I don’t need to make Internet Explorer 8 understand media queries.

Now, let me check just once again. Do websites need to look exactly the same in every browser?

No!

Good.

Marketing.

Marketing. Ah! That’s a good point. So what I’m suggesting here is aggressive enhancement, right? [Laughter] You give the browsers everything they’re capable of, and the other browsers that aren’t capable of it, don’t give it to them: aggressive enhancement.

People say, “I have to support IE8.” Marketing says, “You have to support IE8.” Actually, I agree. You should support IE8 and IE7 and IE6 and IE5. I think you should support Netscape Navigator 3. [Laughter]

Support. You should support those browsers, not optimise for them. There’s a big difference between support and optimisation. There’s a big difference between the marketing department saying, “You need to make sure your content is available to Internet Explorer 8,” and “You need to make sure the website looks exactly the same in Internet Explorer 8,” two very different things. I will absolutely do the first.

I support every browser. I optimise for none.

Look, I know it’s hard. I get it. You’d be like, “Yeah. You haven’t met my boss,” or, “You haven’t met my clients. I think websites don’t need to look the same in every browser, but it’s these people. They think that they do, so I’m doing it because of them.”

That seems like such a waste of your time and your talent. That, confronted with that situation, and you know full well that making something work and look the same in an older browser is just ridiculously hard and not the best use of your time. Yet, you go and do it because the boss, the marketing department, whoever, is telling you to do it. You’re solving the wrong problem.

If you are making a site look the same in Internet Explorer 6 as it does in Chrome 30 jillion or whatever it is now, then you’re solving the wrong problem. The real problem to be solved is changing the mind of the person who thinks the website needs to look the same in both those browsers. That’s the real problem is to rewire someone’s brain, probably someone in the marketing department. And I get it because that’s hard.

Technology—technology is kind of easy, right? Give me a problem. I’m going to solve it with HTML, JavaScript, CSS, and code. Give me enough time; I think I could probably solve it. Human beings? Yeah, they’re hard, a much trickier problem. But you would at least be solving the right problem rather than wasting your time and your talent trying to make something look and work the same in an older browser as it does in a modern browser.

But I do get it because it seems impossible to convince someone like that, right? Yet, things do change. It seemed impossible when the Web Standards Project was trying to convince browsers to support standards and convince us to use standards. Why would we switch from using tables for layout? We knew how to do that. It was never going to happen, and it happened. It is possible. People can change.

There’s a certain irony in this approach of progressive enhancement is that you are making sure that things are going to work further down the line as well in devices that you can’t predict. The irony here is that the best way of being future friendly is to be backwards compatible.

There’s this idea that progressive enhancement was maybe, well, it made sense ten years ago, but it’s an idea of the past. It’s a different web now. We’ve moved on.

No, progressive enhancement is the one idea that has stood the test of time so well, right? It’s a technology of the future. It’s not a technology, but a way of thinking for the future. Today we’re thinking about screens still. What about interfaces that don’t even use screens? That’s when you really have to think about your structured content first, right?

What about if the network isn’t available, this whole idea of offline first? What if we start thinking about the network itself as an enhancement? Again, this way of thinking, progressive enhancement, that will stand you in good stead.

You know what’s funny is I showed you the first website ever made, but I showed it to you in a modern web browser. When you stop and think about that, that’s kind of amazing. I showed you a website that’s over 20 years old and it still worked in a modern browser.

Here’s what it would have looked like at the time, right? This is the kind of browser that was around, something like the Line Mode Browser.

Here’s what’s really amazing. If you’re building your websites the right way, you could take a website that you’ve built today and you could look at it in a browser from 20 years ago. Kind of mind boggling, but that’s exactly the idea behind the web: that anybody could get at that, that this is for everyone.

I saw a tweet go by, and it said:

Wow. You really don’t get the momentous idea of the web until you sit next to a guy with a old Nokia and another with a brand new iPad.

Now that—that is an idea that’s worth rewiring your brains for.

Thank you.

Licence

This presentation is licenced under a Creative Commons attribution licence. You are free to:

Share
Copy, distribute and transmit this presentation.
Remix
Adapt the presentation.

Under the following conditions:

Attribution
You must attribute the presentation to Jeremy Keith.

Monday, August 24th, 2015

Jeremy Keith – Enhance! – Beyond Tellerrand Düsseldorf 2015 on Vimeo

The video of my talk at this year’s Beyond Tellerrand. I was pleased with how this went, except for the bit 16 minutes in when I suddenly lost the ability to speak.