Tags: transcript



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.


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:


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.

  <img src="..." alt="...">
  <img src="..." alt="...">
  <img src="..." alt="...">

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.


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.


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.

Wednesday, August 9th, 2017

Patterns Day 2017: Paul Lloyd on Vimeo

Paul pulls no punches in this rousing talk from Patterns Day.

The transcript is on his site.

Monday, July 3rd, 2017

Fantasies of the Future / Paul Robert Lloyd

Paul has published the slides and transcript of his knock-out talk at Patterns Day. This a must-read: superb stuff!

Design systems are an attempt to add a layer of logic and reasoning over a series decisions made by complex, irrational, emotional human beings. As such, they are subject to individual perspectives, biases, and aspirations.

How does the culture in which they are made effect the resulting design?

Monday, June 12th, 2017

Design in the Era of the Algorithm | Big Medium

The transcript of Josh’s fantastic talk on machine learning, voice, data, APIs, and all the other tools of algorithmic design:

The design and presentation of data is just as important as the underlying algorithm. Algorithmic interfaces are a huge part of our future, and getting their design right is critical—and very, very hard to do.

Josh put together ten design principles for conceiving, designing, and managing data-driven products. I’ve added them to my collection.

  1. Favor accuracy over speed
  2. Allow for ambiguity
  3. Add human judgment
  4. Advocate sunshine
  5. Embrace multiple systems
  6. Make it easy to contribute (accurate) data
  7. Root out bias and bad assumptions
  8. Give people control over their data
  9. Be loyal to the user
  10. Take responsibility

Friday, May 19th, 2017

Presentation: Accessibility in a Responsive World, A11Y Days 2017

There are some great hands-on accessibility patterns in this talk transcript from Scott.

Tuesday, April 18th, 2017

Back to the Cave – Frank Chimero

Frank has published the (beautifully designed) text of his closing XOXO keynote.

Saturday, March 18th, 2017

Thursday, February 9th, 2017

Performance Under Pressure - performance, responsive web design - Bocoup

The transcript of a really great—and entertaining—talk on performance by Wilto. I may have laughed out loud at points.

Saturday, October 22nd, 2016

Rockets of India – Medium

The fascinating history of India’s space program is the jumping-off point for a comparison of differing cultural attitudes to space exploration in Anab’s transcript of her Webstock talk, published on Ev’s blog.

From astronauts to afronauts, from cosmonauts to vyomanauts, how can deep space exploration inspire us to create more democratic future visions?

Saturday, October 8th, 2016

Deep-Fried Data

Another typically excellent talk from Maciej, this time to the Library of Congress. Digital preservation, surveillance, machine learning …it’s all in there, and it makes for grim reading, but there’s also optimism:

My dream for the web is for it to feel like big city. A place where you rub elbows with people who are not like you. Somewhere a little bit scary, a little chaotic, full of everything you can imagine and a lot of things that you can’t. A place where there’s room for chain stores, room for entertainment conglomerates, but also room for people to be themselves, to create their own spaces, and to learn from one another.

Tuesday, June 14th, 2016

My talk at Dot York: Learn and Teach | Charlotte Jackson, Front-end developer

Here’s the full text of Charlotte’s fantastic short talk at the Dot York event last week. I’m so, so proud of her.

Friday, January 1st, 2016

The Website Obesity Crisis

As promised, Maciej has posted the transcript of his excellent Web Directions talk on performance.

So, so good.

Sunday, December 13th, 2015

Smaller, Faster Websites - - Bocoup

The transcript of a great talk by Wilto, focusing on responsive images, inlining critical CSS, and webfont loading.

When we present users with a slow website, a loading spinner, laggy webfonts—or tell them outright that they‘re not using a website the right way—we’re breaking the fourth wall. We’ve gone so far as to invent an arbitary line between “webapp” and “website” so we could justify these decisions to ourselves: “well, but, this is a web app. It… it has… JSON. The people that can’t use the thing I built? They don’t get a say.”

We, as an industry, have nearly decided that we’re doing a great job as long as we don’t count the cases where we’re doing a terrible job.

Monday, December 7th, 2015

Old Weather: Whaling

A subset of one of my favourite sites on the web:

Explore the Arctic of the past from the deck of a whaling ship.

Choose your vessel and get transcribing.

Wednesday, December 2nd, 2015

Apollo 17 in Real-time

This is rather nice—a Spacelog-like timeline of Apollo 17, timeshifted by exactly 43 years.

Gene and the crew are on their way to the moon …the last humans to ever make the journey.

Thursday, November 19th, 2015

Understanding the Web with Jeremy Keith

A transcript of an interview on The Web Ahead podcast, episode 110.

Jen This is The Web Ahead, a weekly conversation about changing technologies and the future of the web. I’m your host, Jen Simmons, and this is episode 110. I first want to say thank you so much to today’s sponsor, Media Temple. I’ll talk more about them later in the show.

I don’t know what we’re going to talk about today. You’ll know, because you’ll have read the title to this show. But I do know who my guest today is. My guest is Jeremy Keith. Hi Jeremy.

Jeremy Hi Jen.

Jen You and I are in the hotel room looking at each other. It’s very strange.

Jeremy Face-to-face.

Jen It’s The Web Ahead: On The Road for the third episode in a row. We’re in San Francisco doing An Event Apart.

Jeremy Yeah. Good to be back in San Francisco.

Jen The conference starts…

Jeremy … tomorrow.

Jen What day is it?

Jeremy You’ve been on the road too long.

Jen I was asking you before we started, “What are we going to talk about?” You were like, “I don’t know.”

Jeremy We can talk about anything you like.

Jen It’s been too long since you’ve been on the show.

Jeremy I’m trying to remember the last time I was on. I’ve been on a few times. I feel like I’ve hogged the microphone on The Web Ahead, because I was on way back at the start.

Jen You were episode 3.

Jeremy Pretty early on. Remember we did one with Doug Schepers?

Jen You were on episodes 3, 56, and 73.

Jeremy Ok, there we go.

Jen June 2014. You’re overdue. It’s been a year and a half.

Jeremy Hopefully I won’t repeat myself.

Jen Oh, you will. But that’s fine.

You’ve been talking a lot these days about the web. I feel like you’re always advocating for the web, why it’s important, why we need to value its qualities and make sure it stays what it is. That we don’t turn it into something else. It feels like these days we need to have that conversation from scratch all over again.

Jeremy Nothing against people using the web for purposes other than what it was intended for. It was intended to share data amongst scientists at CERN. That’s a pretty limited use case. There are some fundamental design decisions and philosophical outlooks that were baked into the web. I believe they have been crucial in contributing to its success. I do think there’s a danger that if we try to twist some of those things, we may end up killing the goose that lays the golden egg.

We can look at other media or platforms and say, “That’s so much better than we web. Let’s make the web more like that.” Ten years ago it would have been Flash. “Why can’t the web be more like Flash? Look at all the things Flash can do.” Now it’s native. “Native gets to do all of this stuff. We should be able to do it.” When it comes to technical capabilities, I agree that the web should be able to provide anything that native can: access to device APIs, camera and microphone. Absolutely. The web should have the same access that native apps gets to that kind of stuff.

In this rush to compete and keep up with these more closed platforms, we run the risk of losing the things that make the web open and great. It’s also worth turning that perspective around. Instead of saying what the web can’t do compared to closed platforms like iOS or Android, what is it that only the web can do? What are the great things about the web? Keep those great things in mind as we’re trying to push the web forward and get these technical capabilities. To not lose all of the great stuff that’s part of the web.

At a fundamental level, URLs have been there right from the start and are a key ingredient of the web. Once you know the name of something, you can pass it around, write it down, or send it in an email. Now someone has access to that exact point within an application or document. That’s pretty big. That’s where native platforms are trying to compete with the web. They’re trying to get what the web already has.

I think it’s worth keeping one eye on the past when you’ve got on eye on the future. Keep both perspectives in mind. Not just think about what the web can’t do, but what the only the web can do.

Jen It is funny, this focus on trying to make the web into a native application platform… rather than ranting about how that’s a bad idea — because we could do that —

Jeremy We certainly could.

Jen …let’s articulate more things about the web that nobody else does.

Jeremy For a start, if I want to publish on the web, I don’t have to ask anyone for permission. That’s pretty huge. That seems obvious to us because we’ve been in this game for awhile. There are programmers, developers, and people making software for whom it’s normal to go through a gatekeeper. For example, an app store. It’s completely normal to build a thing and before they can put it out into the world, you have to get approval from somebody.

Jen Also, if you find a bug, something’s wrong, or you want to ship a new feature, you have to do that again. There’s a lag there.

Jeremy Absolutely.

Jen Sometimes it’s a long time. It feels like forever because it’s a week or two. Sometimes it’s a day. Imagine that somehow the app stores were the best they could possibly be, and it was only a few hours or days. It’s still very different from the web. You can realize you have a typo in your blog post and fix it. It takes you five seconds.

Jeremy That delay is something that people don’t consider. When they’re weighing the pros and cons of having an app. I’ve seen it with clients at Clearleft. Initially, they think they definitely need an app. There are some good reasons in there. But if you come back and talk to me a year later, it turns out this accumulation of that delay every time they want to update… it’s so much more painful than the web.

Jen I think people end up making apps that are wrappers around web stuff. That gives them the opportunity to make changes and do those changes on the web and deploy very quickly. When you use the Facebook app on your phone, it’s pulling in web content. The web content could be brand new.

Jeremy It’s a pretty smart strategy. It’s pretty much what Instagram does. There’s some stuff in the interface that’s set, and to change those things, they have to roll out a new version of the app. But most of what you see on the screen is HTML, CSS, and JavaScript. They can change that on their server.

Jen I think it’s funny when people say native is a better technology. We never had this conversation when we were talking about desktop applications. We used the word “application” instead of the word “app”. This debate only became a thing with “mobile”. You could argue whether Photoshop is better as an application on my computer or as a web app on a webpage.

Jeremy Again, with keeping one eye on the past, in my experience – which goes back a fair way now – there’s always been something that’s been better than the web, technically. At the start of the web in the ’90s, there were CD-ROMS. By any technical metric, CD-ROMS were better.

Jen They were faster! They had amazing performance!

Jeremy You could have video and audio.

Jen I think some of the interface patterns we have on the web are based on CDs. You could click a link and load the next page immediately on a CD-ROM. Well, you did listen to the disc spin a little bit. But it happened right away. Whereas on the web, especially in those days, you had to wait for the new photo to download. It would take five seconds for the photo to download.

Jeremy Right. Objectively, CD-ROMs were better. But what they couldn’t do was have the depth of the web. Where you were always one or two clicks away from something completely unrelated. To do that on CD-ROMs, you’d need a gigantic tower of CD-ROMs stretching to the moon and the ability to quickly swap one for another. Then Flash came along. Flash was clearly better when it came to animation and video.

Jen Just creativity.

Jeremy Exactly. There was so much more you could do with Flash. Somehow they never quite managed to compete on that board depth of the web. The web is an imperfect but huge thing.

Jen In Flash, there were things we banged our heads on. It was incredibly hard to change anything. If you wanted to change your content, you had to re-build the entire application and ship it again. You could technically create an API and pull in data — but most of us weren’t realistically able to do that. It felt like a closed box. It wasn’t able to communicate very well with other closed boxes. Even though you could put a link inside a Flash application and click it to go to another page or website, it wasn’t the same. It didn’t feel the same.

Jeremy Right. It felt more like a CD-ROM. Now we’ve got native apps on mobile.

Jen And it’s the same thing. If you’re in one of those apps, you can click and they’ll load the thing you clicked on, but they’re doing that because they’re loading a web browser inside themselves.

Jeremy Exactly. They pull the web in. It could have been done in CD-ROMs and potentially in Flash.

I find it interesting that we beat ourselves up because the web isn’t as good as other technologies. That’s always been the case. Turning that frown upside down, you can look at history and see the existence of those things helped the web in the long term. They pointed to what we wanted and didn’t want the web to be able to do. CD-ROMs, Flash, and native can act as the R&D department for the web. “That’s really cool, I really want to be able to do that!” Whether it’s animation in Flash or access to the camera in native. These proprietary, closed systems are missing a lot of what you get on the web, but they come with all of this surface-level, cool stuff. But that’s ok. We can take what we want, discard what we don’t want, and put that into the web.

The catch is the speed at which that happens. It’s never fast enough for developers. Developers complain that the standards process is too slow. Many times, that’s absolutely true. The standards process can be too slow. But you don’t want to rush a lot of this stuff because there are big implications. Once something ships in a browser, it’s there for good. It’s very hard to remove something. You want to make sure you get it right. A lot of the stuff we want to be able to do to get on the same footing as native involves access to device APIs. You definitely want to be able to get that right, for security reasons. You don’t want to make mistakes there. Yes, it’s going to be slower. There are compatibility issues, too. A native platform only needs to work on one platform. The web needs to be able to work everywhere.

Jen That’s incredibly different. I feel like people don’t quite appreciate it. We focus on our own projects. When you back up and understand what it means to be someone who makes a phone or a web browser or an operating system, it seems amazing an unbelievable. The idea of making something that works on one device, with an operating system that you control – as much as you can control the application you’re building. If you’re Apple, you control the operating system. If you’re Google, you control the operating system. Building something that works in one situation is a completely different than building something that works in all of the situations.

Jeremy I think that’s a key difference in mindset. You should have that mindset when approaching the web compared to approaching pretty much anything else. I see developers who don’t have that mindset. They’re employing the same mindset as if they were building for one platform, like a native app, CD-ROM, or desktop application. I don’t want to say it’s wrong. I don’t like telling anything that they’re doing it wrong. But you’re missing on the very reason why you’d want to put something on the web as opposed to just making it for one platform. It’s to get that reach. If you’re not planning for that reach, I wonder why do it on the web? Why not just do it in a native wrapper and ship it in an app store? That’s a mindset of realizing you’re building for a huge range of devices, browsers, and people. A good web developer has that mindset. You can still be a great developer and employ the mindset of building for a particular browser or platform. But I don’t think you’re necessarily a web developer.

I have this phrase. I talk about things being of the web as opposed to on the web. When Flash was around, we’d put Flash files in our webpages and technically they were on the web. There was a URL and you could play this Flash movie and interact with it. It was on the web. But it wasn’t of the web. You couldn’t link with it in the same way you could with a truly web-ish thing. I draw this comparison between things being on the web versus of the web.

If you’re building with the mindset that it’s ok to only consider one or two browsers — a subset of platforms — then you’re building something that’s on the web but it’s not necessarily going to be of the web. With a mindset of embracing the chaos of the web — untold, browsers, devices, and numbers of users - you’re truly building something that’s of the web.

Jen Sometimes I hear people talking and it sounds like they think the web is bad. “It sucks. The web sucks. It’s crappy.” They feel frustration with the chaos. “I wrote this code. It should work. It works in these browsers. It doesn’t work in this other browser and I don’t really know why.” It can be frightening, honestly, to build something and it’s not working. You want don’t admit: it’s scary. But deep down, the core feeling is, “I don’t know what I’m doing.”

I think people end up lashing out and labeling the web as some sort of lesser situation because it has that challenge to it. I feel like the challenge doesn’t come from the web being badly architected or being some kind of lesser thing. “This operating system is well-made and this other thing is badly made.”

I think it’s the ambition of the project in the first place. This is an environment where all of us get to make stuff. That world works on a tiny piece of glass. There are electronics beaming out of the sky; some kind of radio waves changing what you see on the piece of glass. Then, over here, somebody’s got a fancy computer with a giant screen. They’ve got wires hooked up to that. Wires made out of glass! There are so many different ambitions. We’re making things that work on hardware that was made before some of the people who are working professionally were alive. Simultaneously with hardware that hasn’t been invented yet.

Jeremy I think the frustration when people say, “the web is hard,” when something they’re trying to do doesn’t work, is because of what their expectations are of something working. When people “This doesn’t work on that device,” it works differently. “It doesn’t look exactly the same,” right? “In the latest version of Chrome, this has beautiful CSS styling on it. In this proxy browser on a mobile phone, it doesn’t have any of that styling.” Ok, but that doesn’t mean it’s not working. What you want to work is whatever the task is. Whatever it is that you need to accomplish. Whether it’s access to information or a complete flow. That’s the part you need to make work. You can make that work at a basic level with simple HTML and offload to the server to do the processing. Then you can add on top for fancy browsers. When people get frustrated and say, “This doesn’t work,” what they mean is it doesn’t work to the same degree or it works differently or it works in an unexpected way. If you’re building so the core functionality is available, it still works everywhere.

You’re right. The key is to change that mindset from seeing this as a scary thing. “Oh my god, there are so many devices, so many different kinds of browsers, so many different situations.” To embrace that. “This is awesome.”

Jen It’s so powerful!

Jeremy It’s incredibly powerful.

Jen I get to make one thing and it works on all of these different devices, in different situations.

Jeremy Even if it works differently. Once you can make that switch to accept that it’s ok to work differently, I think that’s when the mindset change starts. It stops being scary and starts being fun. It starts to be more of the web.

Even if you can make that change to think it’s good that things work differently on different devices, quite often there might be other stakeholders involved. Whether it’s a client or a boss. They might think otherwise. “It has to work perfectly on every device.” The problem is no longer a technical one. The problem is convincing them that it’s a good thing for it to be different on different platforms and devices.

Jen I think that comes from a decade of thinking that when you design a website, you’re making a PDF. You’re pre-creating a screenshot of what it should look like. You want to look at the finished product and look at this pre-made screenshot of how it’s supposed to look. We even used to use tools where you’d take that screenshot and line them up. That was a big mistake. It’s like television thinking they should put radio shows on television and characters need to explain to each other what they’re looking at.

Jeremy I think it comes from previous mediums like print. You did have a good understanding of where the final thing would appear. You knew the paper stock it would be on. Crucially, you knew the width and height of the thing you were designing for. That’s something you don’t know on the web.

You’re absolutely right. If we work in a process where upfront work is done that’s not on the web — it’s in a graphics program — we’re giving an impression of what the website will be like. Of course the client is going to be annoyed, disappointed, and frustrated when they look at it in anything other than the latest and greatest browser and device. We should be trying to explain to them upfront that it’s going to look different and that’s ok. There are conflicting messages. On one hand, we’re trying to say, “It’s going to look different on these different devices and that’s cool.” On the other hand, we’re making mockups and saying, “This is what it’s going to look like.”

Jen Right. I think using those tools is fine. But the people who are finding the most success — getting their stakeholders to make this transition — are using other tools. You can use Photoshop or whatever tool you want. But they’re using those tools to figure out ideas. They’re not presenting the one and only idea of what the whole website is going to be. Where people literally sign a piece of paper and say, “Yes, this is what I want.”

Jeremy We’ve had lots of discussions at Clearleft about process and tools. There’s a weekly design review and it always descends into processes and tools and graphics programs.

I’ve come to the conclusion that there are three kinds of mockups. The first one is for sign off; the situation you just described. You’re mocking something up in order to get that signature.

Jen Because it’s important. You don’t want to build the entire thing and show it to them and have them be like, “Oh, I don’t like it.” You want to show them ahead of time where you’re headed and get them to agree.

Jeremy You don’t want the big reveal to be in the browser. That’s true.

Jen Well, after you’ve built the entire CMS. You’ve spent all $4 million.

Jeremy The problem with designing mockups for sign off is you’re going to make it look as good as it can. Everything is going to line up perfectly.

Jen Every piece of content is the same length.

Jeremy Exactly. That’s just unrealistic, right?

Jen It’s a terrible thing to deliver to a developer. Because you’ve delivered to them only the ideal situation. They don’t know what to do for the unideal situations.

Jeremy That was going to be the second type of mockup. You design a mockup to hand off to the developer. Instead of making a mockup for the client for sign off and making a mockup for the developer, that doesn’t happen. You send them the same one. Straight away, we’ve got a problem. We’ve got a mockup created for one use case — sign off — that’s being used for another use case.

Jen Being used for communication.

Jeremy Yup. Having one mockup rather than two is problematic. Should we show the client what we give a developer? Show all of the ugliness? With very little content, with loads of content, with things not lining up perfectly. Maybe that would be a more realistic thing to show the client than getting their hopes up that it’s going to look pristine and perfect. You’re setting them up for disappointment.

I think the third use case for mockups is most valid. It’s for a designer to get ideas out of their head and figure stuff out. They happen to be comfortable with that tool, so they’ll use that tool. To me, that’s the most valid use case for those tools. Whether what they produce is ever shown to another human being, much less a client or developer, is another issue. It’s just for thinking. That’s a very valid reason to do mockups.

If you take away those first two use cases, what do we use to get sign off and communicate with developers? That’s where it gets tricky. I think there are some good toolkits out there. Samantha Warren talks about style tiles. Don’t try to establish everything. Just establish the mood. Get agreement with the client on typography and colors. The atmosphere. Then, you can start to work on the components. But maybe don’t jump straight to pages. Dan Mall does element collages.

Jen He usually does them in the browser. I’ve seen you do them in the browser, too.

Jeremy It doesn’t matter, that’s the thing. It’s completely technology-agnostic.

Jen Brad Frost calls it Atomic Design. You’re going to put a bunch of different elements on the page. Look at buttons. Look at forms. But not just one form, like the registration form. Get rid of the header and footer. Let’s look at the purchase form and shopping cart form. We’re put five forms on one piece of paper. Maybe we’ll have three or four different styles and ideas about how the visual treatment might look. Then you can have a conversation and decide which forms you like. Now you’ve got forms figured out. It doesn’t matter if there are more forms added to the system because you already have an idea of what your forms look like.

Jeremy You started with the atmosphere and then you get into the components. At each stage, you’re getting agreement, instead of having this big reveal.

Jen Right. It’s a more collaborative process. Rather than doing it all by yourself.

Jeremy What’s crucial is that the cost of change is low. If the client says, “I hate it,” you can do another one. That was less than a day’s work. When you’re talking about forms or text, cost to change is low, as long as you’ve got fairly constant communication. The longest you’ll waste is a day before your course is corrected. Whereas, if you go off and create a beautiful mockup to show in a big reveal and get sign off, if you don’t get sign off, you’re going to get nothing. You’ve wasted all of that time. Keeping the cost of change low is good.

I think at that time you can start mocking up pages to get sign off. But it’s not a gamble at that point. You know the typography is right. You know the colors are right. You know the form fields are right. You’re putting it together. If they push back on something and it’s fundamental, they’re only going to be pushing back on a particular arrangement.

Dan Mall has a wonderful phrase when it comes to the question of sign off. He talks about deciding in the browser. Not designing in the browser. Deciding in the browser. I was thinking about it and he’s right. With sign off, you’re deciding in Photoshop. You create a mockup and present it to the client. You’re looking for a decision. The decision has been made. Then you start developing. That’s when you run into the issues. You’re going to have to adjust. It’s a bit late now because you already have the decision. They signed off on that and now you’re going to deliver something different. You’ve set yourself up for disappointment. Whereas, if you decide in the browser, you don’t have the sign off stage happen in the graphics program. You wait until there’s something in the browser.

Jen You do a prototype in HTML and CSS.

Jeremy Exactly. Get into a browser. If you get sign off then, it’s much closer to the final thing. This idea of deciding in the browser as opposed to deciding in a graphics tool is crucial. Clearly it’s a better workflow. It will lead to less frustration and disappointment from everybody. Well, ok, you and your colleagues might be convinced. But how do you convince your boss? How do you convince the client? How do you communicate this stuff?

Whether we’re talking about the nuts and bolts of development or design process, it always seems to come back to human beings. Convincing human beings to change. That’s hard. Which is strange because as industries go, this industry has only been around for 25 years. Really only established in the last 10 or 15 years.

Jen We did go through a giant change already. The change from table-based layouts to float-based layouts. The change from the kinds of designs we had. That was a pretty big change.

Jeremy I think that was a big technical change. I’m still a bit disappointed that we never truly changed our thinking. I don’t want to blame tools for everything, but I think a lot of it had to do with the fact that we still designed in a graphics tool.

Jen Did thinking of what a website is, thinking about how a page would be laid out, how links work, or how information architecture works — that stayed the same?

Jeremy Yeah. That of stayed the same. I wrote a blog post a few years after we had switched from tables to CSS. I was kind of disappointed. CSS offered the opportunity to rethink what you could do on the web. Maybe silly stuff. Why can’t your website look different at different times of day? Why can’t your website look different depending on the weather? Instead, we were stuck in this fixed, print-like way of working. Because we were using tools made for print. Our thinking wasn’t changing, only our toolset was changing.

Jen In the early years we used Dreamweaver so much. There was nothing dynamic about Dreamweaver. But it was a prototype. We started out designing webpages by making webpages. Many of us skipped right over Photoshop or Illustrator. We went straight to Dreamweaver. It’s interesting that we were still so focused on print. When I talk to people these days, it feels like everyone thinks print has always been digital. Everyone thinks print has always been InDesign. There was Quark before that, and Pagemaker before that, and we did everything by hand before that. We transitioned from physically printing a piece of paper that had type on it. Then cutting it with the Xerox knife and sending it through a machine that put wax on the back of the text. Taking that paper and pasting it on a board that had the other text and a headline and an ad. Getting a roll of tape to make a line on the page. That ended in the late ’80s or early ’90s. There were people using those tools 30 years ago.

Jeremy There are still print designers who rail against desktop publishing because once the digital tools came along, everyone started using all of the digital tools. “Let’s change the font for every character!” “Let’s use all of the artwork!”

Jen Those debates were raging when the web was born. It’s not like everything was standardized in the print world. There were raging debates.

Jeremy What surprises me is how set in our ways we can be with the web, considering how much more dynamic of a medium it is.

I’ll give you an example with the change from tables to CSS. In my opinion, that was technical and we didn’t change the way we thought about design. Before responsive design, most people were making fixed-width layouts. That was true whether it was tables or CSS. There was nothing inherent in tables that said you had to use pixels. You could have used percentages. I used percentages in table layouts. But the mindset was about making it 800 pixels wide.

Jen I was pretty against fluid websites. For two reasons. One was the line length of the text. I had no theory around that. It’s not like I understood typography. I just didn’t like the way it looked when it got really long. Two, the photos weren’t changing sizes. The visual hierarchy relationship between the photo and the text wasn’t controlled in fluid design. I didn’t like that. I wanted to be able to fix the visual hierarchy. The only way I knew how to do that was to fix the whole page.

Jeremy Right. There were technical reasons why it was hard to be truly fluid on the web in the early days. But people internalized those frustrations. “We’ll just build fixed widths.” They never stopped to look at whether those underlying challenges ever changed. It turns out that they did. When responsive design came along, it wasn’t out of no where. A lot of stuff was building for years to make it possible.

Steven Johnson talks about the adjacent possible. You couldn’t invent a microwave oven in the 15th century is because all of this other stuff needs to happen first. You need to have electricity. Then you can invent the microwave oven. In order for Twitter to exist, you need to have the web. In order for the web to exist, you need to have the Internet.


Jeremy Right. All of these things have to exist before you can have a breakthrough.

When Ethan Marcotte came along with Responsive Web Design, media queries had been coming up for a couple of years. That enabled responsive design. As you pointed out, there were a lot of challenges. And it turns out that people weren’t paying attention as things were getting fixed. Line length was fixed with max-width, which was IE5 or 6. But by the time it was fixed, people had already decided they couldn’t do those layouts because the line lengths were too long. They never revisited that assumption.

The other thing was images. A fixed-size image wasn’t truly fluid. My colleague, Richard Rutter, did tests on this. What happens if you put percentages on images? We’re talking about mid-2000s here. It was a crazy idea at the time.

Jen I remember hearing that was bad. You don’t want to change the size of the image using CSS. You always want to fix it in the HTML because of performance.

Jeremy Exactly. He started investigating it and found out that browsers had gotten a lot better. In fact, you could put this max-width: 100% on the image and the browser was generally ok. Back then, 10 years ago, you would have heard some hard drives spinning to take care of it.

But these things were slowly accumulating over time. We got max-width to stop the line length problem. We got fluid images. Then media queries. It was the combinations of these things in this adjacent possible that made it possible for Ethan to say, “We can put all of those things together.” And, crucially, giving it a name: Responsive Web Design. Boom! We’ve got a whole new way of working. It was a whole new way of working. But the things that enabled it to work had been there for a long time.

I’m fascinated by what we’re missing when we make up our minds. We turn our backs. We move onto something. We establish that we can’t do X, or this is just the way things are. We never revisit those assumptions. With the design process and mockups, we’ve established that’s the way you work. You make a mockup, show it to the client, and get sign off. It’s not that long that we’ve been building websites. It’s not like it’s too late to change the way we work. This is a young industry.

When I was first getting into the web and started messing around with JavaScript, it was horrific. It was the years of DHTML, when you had to do it one way for Netscape and another way for Internet Explorer. Most developers looked at JavaScript and said, “JavaScript is awful. Let’s not touch JavaScript.” And they were right. There was this cool new thing called CSS that was coming out. All of these web standards people were all about CSS. I turned around a few years later and asked, “What’s going on with JavaScript these days?” It was actually really good. We had a standardized DOM with getElementById and getElementsByTagName. You could write it once and it would work in all of the browsers.

Around 2005, I wrote my first book, DOM Scripting, about basic JavaScript. My message was to tell people, “You know that technology that you wrote off five years ago? Revisit it. Things have changed. It’s ok now.” It was actually a very gratifying experience. The very first web conference in the UK was At Media in 2005. It was one of my first speaking engagements. I was the token JavaScript guy. The talks were entirely on CSS and there was one JavaScript talk, which was me. The audience was sitting with crossed arms, like, “Really? You want us to use what now?” I got to open their eyes and say, “Check it out! While we all had our backs turned, looking at CSS, it’s gotten really good. Look at what you can do now!” To see lightbulbs go off. People were going, “Ohh, alright. It’s pretty cool.” It was time to turn around and look at JavaScript again. Which is ironic, because 10 years later I’m like, “Enough with the JavaScript!”

Jen I know! You’re getting a reputation as the guy who hates JavaScript.

Jeremy Nothing could be further from the truth. I’ve been trying to rehabilitate JavaScript. Maybe you went too far with using JavaScript for everything.

Jen Right. Don’t replace HTML and CSS with JavaScript.

Jeremy My point is we can often internalize things and say, “That’s the way things are. That can’t change.” Then we don’t revisit those decisions. But they do change. For such a young and fast-moving industry, it seems weird that we have things so set. Our processes get so set and rigid.

Jen You know, I went to film school. I took a film history course. I keep wanting to dig back into it… maybe it’s not written anywhere… maybe there’s no where to dig… But I wish I could jump into a time machine or something. Go and see what the film industry was like 25 years after film was invented. Before sound in film was invented. There were very specific ideas about how to tell a story or edit a film. There were these moments in the first 50 years of film history where, “Wow! Look what you can do! I just figured out how to edit! What!” A film would come along and blow everybody’s minds and everything would change.

Jeremy Or you have people say, “You can’t do that. You’re wrong. You can’t use film to do that.” In art, it was the same. The Impressionists were wrong. They were doing it wrong. That wasn’t what you were supposed to do.

Jen When we look back, or in a history course in school, you have years of art history compressed into two weeks. In these two decades, everyone did this. Then in these two decades, everyone did this. Then this changed and there was a decade of that. There’s a way in which it’s obvious. “Of course everyone was stupid when they used such-and-such.” But it’s like, no. That was 10 or 20 years.

Jeremy Yeah. Things were mushier, more fluid.

Jen What was it like in real-time for the filmmaker making a film five times a year, to doing it the same every time? It was four years before another big change came. I feel like that’s our reality now. We think we have it all figured out and we just need to keep cranking out sites in the same way. We know what a website is. We know what the page layouts should be. We know what information architecture is. We know where our navigation is going to work. It’s like, you’re making five websites this year and you’re making them the same way you were making them last year. But this medium is such a baby. I think 50 years from now when people look at our work, they’re going to laugh at us: “How did they not know that it should be this other way that it’s become?”

Jeremy The only constant is change, right? I get nervous when I see people promoting tools that are great for solving problems today. That’s locking you into something for tomorrow. The best tool available today may not be the best tool tomorrow.

Jen Especially with people who think they’ve found the ultimate tool.

Jeremy Right. They’ll never have to change.

Jen This magic tool will fix the chaos and craziness of the web. They’re going to replace the web with this awesome, third-party framework. Now you don’t have to deal with any of that chaos. Get rid of all the web-y-ness. We’ve figured out how to put something on the web without having to deal with it being of the web. That’s it. Now we can all use this framework. We don’t ever have to think about this again.

Jeremy The reality is, today’s awesome time-saving tool is tomorrow’s technical debt. You end up writing yourself into a corner by having that reliance.

There was a great article that was like, “Where were you at the start of the project?” When somebody new comes on board somewhere and looks at the existing codebase and says, “This is ridiculous! Why didn’t you use Grunt? Why didn’t you use Sass?” It’s like, those things didn’t exist yet.

Jen Or a certain CMS. We used to fight about CMSes and now we fight about frameworks. But it’s the same fight.

Jeremy It’s like, at the time, that was actually the best one around. You would have been crazy not to use that CMS. I think the issue is that a lot of these tools have assumptions built in. If you’re aware of the assumptions, that’s ok. You can build with the assumptions in mind and hopefully not get too caught up in them. There are very few tools that have an awareness of their own life span. Tools that acknowledge that this is good for today and probably won’t be good for next year. There’s very little that you can take for granted on the web.

A classic example is performance and what counts as a best practice. You want to make as few HTTP requests as possible. We’ll sprite our images, concatenate our CSS and JavaScript. That’s clear. That’s set in stone. Then HTTP/2 comes along. Now because of the way we can do things in parallel, you want as many HTTP requests as possible. It’s a bad practice now to concatenate your CSS and JavaScript if you’re serving over HTTP/2. Even for something that seemed so fundamental…

Jen Right. Like we don’t have to worry about this.

Jeremy Like we knew what was good practice and bad practice. We knew it was good practice to concatenate our files and send as few HTTP requests as possible. Actually, no. Even that is open to change. There is so little that you can rely on.

Jen I think it can overwhelming when you’re trying to get work done. I think it’s fun when you realize how lucky we are to be at the beginning of something so new. Anyone listening can investigate something, write a blog post, and influence the entire industry. They can change the shape of the medium itself. Which is so crazy.

Jeremy I wish people would write more. For that reason that you mentioned. In the future, we would have a better understanding of what people are thinking now. I’m very glad that I’ve been doing my blog for 15 years. I can go back to 2002 and get a feel for what it was like to build websites. Back then we thought X was true or hadn’t even considered Y. You forget these things. Having these written records — not of anything important or groundbreaking — but just the day-to-day. The boring stuff. That’s actually what’s most interesting over time. I wish people would write more boring blog posts. “I went to work. I did this. Nothing groundbreaking. Nothing revolutionary. But that’s how we build websites today.”

Jen We used to write a lot of boring blog posts. Then we stopped when it felt like audience was so important: “I don’t want to say something that’s going to embarrass me later. Everything should be really well-written and polished. I don’t have time to write something that great.”

Jeremy I hate it when people self-censor like that. They feel like it has to meet some standard. Again, it’s the web. The whole point of the web is there isn’t a gatekeeper. There isn’t someone with a red pen saying, “That isn’t good enough to be published. That’s not up to scratch. You’re not allowed to publish it.” There’s no app store keeper for your writing. Yet people impose it on themselves. “I’m not good enough. My writing isn’t good enough.” It’s the web. It could be the worst thing ever and you still have the right to publish it on your website. You should do it. Don’t let anyone tell you otherwise. I feel like a lot of people have this self-censorship thing.

Jen I do. If you look at my website, it’s terrible. Don’t look at my website. There’s nothing on there. I never publish anything. I’m not embarrassed of the writing but I’m embarrassed of the site itself. I don’t want anyone to go to the site because it’s embarrassing. So I don’t write anything because they might accidentally go to the site.

Jeremy Better to be embarrassed by the writing than to be embarrassed by the lack of writing, right?

Jen I’m working on it. I’m trying to fix that.

Jeremy Recently at Clearleft, we realized a lot of people self-censor. We try to encourage them not to. Myself and Ellen, a content strategist at Clearleft, put on a workshop to write. Maybe it’s for a presentation, blog post, proposal, or case study. Whatever it is. You need to communicate and get some words out, in some form. It’s really funny. Someone could be the most awesome designer or developer. Very confident and top-notch. But you ask them to write a few paragraphs and they clam up, like you’ve just asked them to do the hardest thing they’ve ever been asked to do. It’s just a few paragraphs. It’s no big deal. But it is a big deal. A lot of it is due to self-censorship.

We had two mornings of workshops and it went really well. I thought what Ellen did was brilliant. On the first morning, we discussed this idea of the inner critic. The voice that says, “It’s not good enough. I can’t write. I’ve got nothing new to say, everyone’s heard this already. What can I add? It’s already out there.” Everyone can relate to this idea of the inner critic. She got everyone to draw their inner critic and turn it into a little monster figure and give it speech bubbles.

Jen Like the devil on your shoulder?

Jeremy Exactly. It was a fun exercise and some interesting stuff came out. One of the interns, Chloe, did hers and I did mine, and when we compared them, they were freakishly similar. Other people had monsters. We both had a snotty toff in a top hat and monocle, with a stuck-up nose, saying, “This writing is terrible. We’ve heard it all before. Your grammar is awful.” We were both like, “This is so weird. We’ve both got this guy in a top hat and monocle. What are the odds?”

It was interesting to externalize it in that way. It made it ridiculous. Which is good because it is ridiculous. The inner critic is a stupid thing. It reminded me of something that Paul Ford had done awhile back. He’s a writer and he externalized his inner critic with an email bot. It’s called Anxiety Bot. He fed it a Markov chain with the kind of crap that your inner critic says. He’s receive an email saying, “None of your friends think you’re very good.”

Jen So he’s getting all of these emails from this horrible voice.

Jeremy He’d get this email and go, RAWR! He would shout at it. That was kind of healthy. But he would also look at it and go, “This is so ridiculous. No one would actually say these things.”

Jen Because you’re afraid to get those emails.

Jeremy But this email could only be from a bot because no person is actually going to say these things. When it’s internalized, why do I think it’s a reasonable thing that people would say this? Bringing it into the light diminishes the power. That’s why I really like this exercise of sketching out your inner critic.

There were other things that were about getting your ideas out of your head and onto paper. Like mind maps. Really great stuff. It really encouraged people. People started to get into the mood for writing. I want to take an hour or two, literally lock people in a room and say, “We’re not leaving this room until you’ve written this blog post,” “We’re not leaving this room until you’ve written down that technique you’ve been talking about but haven’t written down.” Make them do it, but there’s a time limit. You have to do it now. It was a whole morning about getting over your inner critic, getting the ideas out of your head, and getting them down. But not really shaped. It’s more about getting them out of your head.

I led the second morning, which was more about how you could shape them. That was a lot of fun. I’d never done this before but thought I’d give it a shot.

I did something similar to what you were talking about: looking at other things, like film or theater, and asking, “How do they shape plot to make them more interesting?” If we could separate the plot from the narrative device, you could have a toolkit of narrative devices.

First, I got them to take a story and give the plot in chronological form. For example, Star Wars, Little Red Riding Hood, or Jurassic Park. One point after another on Post-It notes. Then I took out a stack of cards. Each one had different narrative devices. For example: flashback. Find a crucial moment in the chronological plot and put that at the start and build up to it. Because that’s what happens in movies with flashbacks. Or backstory. Take a long zoom and put something into historical context. In 2001: A Space Odyssey, we begin with the dawn of man. In The Fellowship of the Ring, we have this huge thing from the first age before we even get to the hobbits in the Shire. Can you do that with the story you’ve got? It was a lot of fun. There was the distancing effect. What if you were to write a police report? There’s no embellishment or adjectives. Just the facts. That can have a powerful effect on a story. So they got dealt a random card. They didn’t get to choose. They had to take the story they already had — Star Wars or Jurassic Park or Little Red Riding Hood — and they had to use that device on it. Dialogue was another one. How can you tell a story where you don’t describe the action and you only have two characters describe the action to each other? Like The Breakfast Club. It was complete dialogue. They describe things but you don’t see it happening. They do this to their story, then we revisit what they’d done the day before, when it was about getting the stuff out of their head with brain dumps and mind maps. Now they’ve got their plot, the chronological part. Then I dealt them another random card and they had to apply that device to it. It became fun.

Jen I would imagine a lot of those blog posts were about designing or building websites. How do you apply flashback or dialogue to a post about designing a website?

Jeremy It was hard and tricky. Clare, one of our project managers, had a blog post she’s been meaning to write about project management and communication since getting back from a conference. She had the points and got htem out in the first morning. But during the workshop she realized it would be more interesting to apply one of these things. She ended up using dialogue. She published it later that day, which was great. Instead of, “I’m going to do this,” it was like, “Just do it now. Hit publish. Don’t even make it a draft.” So later that day she wrote the blog post. It’s up on the Clearleft blog. It’s about project management but told through dialogue. The narrative framing device isn’t obvious. The message is the same but it’s more interesting.

Jen We’ll have to link to it. The show notes for this show are at thewebahead.net/110. We’ll have a link to it. Are all of these ending up on the Clearleft blog?

Jeremy I certainly hope so. Some of them were for talks rather than blog posts. Ben was preparing a talk for a conference coming up soon. He’s going to be talking about voice input and output in interfaces. He’s got his points so maybe one of these narrative devices could be a fun way to approach it.

Jen That’s crazy.

Jeremy Yeah, it was really good fun. When you have your own blog and you’re writing, there are the things you can say, and there’s also how you can say it. You can have fun with that and play around.

Jen It feels like there was a time when there was more of a spirit of exploration on the web. It feels like we went through a period for the last decade of shipping Really Important Websites for Lots of Money.

Jeremy Yeah, without the fun. This idea of “web scale” bothers me. It’s a term that I believe would have started here in San Francisco or the Valley. This idea that things have to happen on a certain scale. A lot of it is related to the so-called business model. Where it’s entirely about growth and numbers. You end up in a ridiculous situation where a web service can have millions of users and be considered a failure because the growth rate is stagnate. They’re getting new users every day but not fast enough. That’s the metric they’re measured by, and by that metric, they’re a failure. In my opinion, that’s not a good metric. There are so many other ways to judge the worth of something, other than growth.

I think we got some overwhelming role models over the years. Now it seems obvious that in the world of search, you have one big winner. Because that’s the way things are now. Google is search. It couldn’t possibly be any other way. Well, it could. History could have worked out differently. In the beginning, we had different search engines. Google was the best and got the advantage and squashed the competition. But there was awhile when you had multiple search engines that were equally good or bad. That was fine. This idea that the way things are now is the only way it could possibly be…

Jen I think it could easily change. People could decide they don’t want to be tracked by a company that’s selling their data and they want to use DuckDuckGo. Google could be knocked off its throne. It’s totally possible.

Jeremy It’s similar in the world of social networks. This idea that for a social network to succeed, it has to be the only social network, like Facebook. Our role models are giant, overwhelming things like Google and Facebook.

Jen We’re all trying to be The Next Whatever in our slice of the world.

Jeremy Looking at the disproportionately huge things and thinking that we have to compete on those same metrics.

Jen And that that’s all that counts.

Jeremy Right. And there are plenty of other ways to compete. You see some people not playing the game and it’s great. Take Maciej Ceglowski, who does Pinboard. Pinboard is famously a little business. You pay money to use it. That’s the “crazy” business model. I’m not sure what the growth is like, but I know it’s not year-on-year, millions of people. Or communities like Ravelry. It’s not Facebook. It’s not trying to be Facebook. Things can happen on a smaller scale and be entirely successful, self-sustaining, valuable, and grow. In my opinion, the web is better for that sort of model. For lots and lots of small things. Things like Google for search or Facebook or social networking are exceptions. It’s quite unusual to have one, overwhelming, monopolistic force. The default way of the web is millions of competing voices in a particular area. That’s fine.

Jen That’s what was so exciting about it.

Jeremy Exactly. So people seem to judge what they build on the worst possible metrics. They compare it to something that’s an exception. They find it wanting because it doesn’t compare to the exception.

Jen In the 20th century we saw these massive media companies take over distribution of everything. They took over the distribution of radio, music, television, and films. By the time we were born at the end of the 20th century, what it meant to be a musician or have an album or make a film or make a painting was all judged on this idea of mass market success. Even though for the history of humanity that’s not what it meant.

Jeremy Right. It was a blip in the 20th century.

Jen It feels like the web was a chance to break that up and say, “Yeah! We don’t want that anymore! We don’t care about mass markets and massive companies! We’re going to smash that. You can have your own band and distribute your music online. You can write and have an audience.” But with the way the world works, we disrupted those old businesses and replaced them with businesses that are even bigger and more powerful and sucking all of our attention and time and bleeding our creativity.

Jeremy It may be that things just tend towards monopolies, which would be horrible. What was that book? The Future of the Internet And How To Stop It. He compared his view of previous media and how they started off very open, with many small players. Over time, they tended towards monopolies, with big organizations controlling 80% of the output. He said that if we’re not careful, the web could go that way.

You’re absolutely right. The web was wonderful in the way that nobody needed permission. There was something about that in the early years. It still happens that unexpected successes come out of nowhere. Someone in their bedroom throws something online and they’re a sensation. But, again, you shouldn’t be comparing success to what’s on the charts or who’s on TV. That’s a very 20th century way of thinking. Where you had publishers and record houses; gatekeepers deciding who you get to listen to, read, and watch. The web is great in removing those gatekeepers. Anyone can put their film online. Anyone can put their music online. Anyone can put their music online.

This is kind of related to the self-censorship thing. It really bothers me that people almost crave a gatekeeper. “We’ve got the web and we don’t need to ask anyone for permission, but let’s build an app instead. Where we have to convince the app store owner to let us publish and pay money to let us publish.”

Jen Not only to let you publish — which is usually fairly open — but to highlight us in the new and noteworthy. Or to promote us to a place where we’re able to get some sales.

Jeremy Sometimes it is about what you publish. James Bridle built Dronestagram, which shows drone strikes. But that will never get through the app process. They have rules about what you can and can’t put in an app store. The web has no such rules. You can publish anything you want.

Also, with self-censoring, people feel like it’s not good enough to publish on your own site, because your site is small. You want to be able to publish on a more mainstream place. We see people publishing on Medium instead of publishing on their own website.

Jen Because there’s a feeling of endorsement or like you’ve made it.

Jeremy If you want, they’ll say it’s about reach. But the whole point of the web is that you don’t need a gatekeeper to have reach. You’ve got access to the entire world by publishing on your own site, where you have control. If that business model for that platform doesn’t work out and they end up closing, they don’t take all of your content with them. There’s the idea of owning it yourself and publishing in your own corner of the Internet. But people seem to compare it to the 20th century model of publishers and record deals and distribution deals that don’t make as much sense on the web..

Jen It feels like the stakes are high. Whether you’re working on a big project for a lot of money with a client, you can’t mess around with that. You need to deliver great work. That’s when we do it in the way we know it’s going to work.

Jeremy It’s risk aversion.

Jen Yeah. I also think there’s a way that with my personal site, I want it to be successful or a certain level of quality because I have a reputation. I’m building my reputation. I have a brand. I’m building my brand.

Jeremy This is when the site never gets launched because it’s never quite good enough. The number of designers who haven’t launched because it doesn’t look quite right, or the number of developers because they haven’t finished writing their own CMS.

Jen In a way, it’s easy to be snarky about that. But I think it’s more honest to say that there really is something to that.

Jeremy It’s self-imposed, though. Nobody outside is actually thinking that. Nobody’s going to judge you and say you’re not qualified because your website doesn’t look as good as it could. Ethan Marcotte has a fixed-width website. That’s all I’m saying. Does anyone think he doesn’t know what he’s talking about? No.

Jen Right. I guess it comes out as more about it being an opportunity to impress. There’s an opportunity to show people what I can do. If I’m not doing that, what am I doing? I shouldn’t do anything at all.

Jeremy There’s also an opportunity to show all sides of yourself. To experiment and try something out. To show the failures and the stuff that doesn’t work. To publish the half-finished thoughts.

Jen Anytime I’ve seen people do that, they’ll say: “My website isn’t done, and I feel so afraid, but I just want to publish something, so I’m giving it to you this half-baked thing.” Or, “I’m going to redesign it and I’m doing it in the open.”

Jeremy I love it when people do that. They publish it with no CSS at all.

Jen Right. There’s no theme at all. They’ve got a CMS going but ripped out all the stuff that was there. Now it looks like nothing. Slowly they’ll fix it supposedly… Then it’s a year later and it’s still the same.

Jeremy Whatever it takes to get people doing it.

Jen I agree with you.

Jeremy But you have to accept that all of those reasons not to be doing it are not actually coming from outside. They’re coming from within.

Jen They’re coming from that voice?

Jeremy Exactly. It’s the inner critic. There’s nobody actually there who’s going to judge you. “You can’t have an opinion on CSS layouts because your website doesn’t use the latest CSS layouts.”

Jen It took an extra month or two to launch The Web Ahead website because I felt like the layouts were no where near the ideas I have about layout. How could I stand on stage and talk about layout while having launched a site that was more conventional than I wanted it to be? Or not polished? There are so many bugs on it. But I did launch it. That one got launched.

Jeremy That was a month-long battle with yourself. Not with anybody.

Jen Yeah. And eventually I will make it better.

Thank you so much for being on the show again.

Jeremy My pleasure. That was fun.

Jen People can check out the show notes at thewebahead.net/110. We’ll have some links there. I don’t think there will be a lot, but there will be some. We’re back doing the show more often. Subscribe if you haven’t subscribed! Go over to the (perhaps evil?) iTunes store. See, this is the thing, right? I need people to go to the iTunes store to leave a review or a rating.

Jeremy No you don’t. Word of mouth. Everyone listens to The Web Ahead. I’ve never read a review of The Web Ahead. I know how good it is.

Jen A lot of people don’t follow anybody, they don’t know anybody. They just go to the store and search for “web podcasts” and it needs to show up.

Jeremy But if the iTunes store disappeared tomorrow, you’d still have your podcast.

Jen Absolutely. We’d still have the podcast. Because of the way the technology works, not one person would miss the podcast. They’d all still get it.

That’s it. Thanks for listening.

Monday, July 27th, 2015

Fan Is A Tool-Using Animal—dConstruct Conference Talk

Maciej has published the transcript of his magnificent (and hilarious) talk from dConstruct 2013.

Tuesday, June 30th, 2015

Style Guides with Jeremy Keith

A transcript of an interview I gave on the Style Guides podcast hosted by Brad Frost and Anna Debenham.

Your hosts: Brad and Anna.

Brad Hello everybody! Welcome to another episode of the Style Guides Podcast, a podcast dedicated to all things pattern library and style guide related. My name is Brad Frost.

Anna I’m Anna Debenham.

Brad And today we are absolutely delighted to be talking with the infamous Jeremy Keith. Jeremy: how are you?

Jeremy Hellooo! I’m fine, thank you. How are you, Brad?

Brad I’m doing excellent.

Jeremy Good. How are you, Anna?

Anna I’m good, thanks.

Jeremy Good, good.

Brad Excellent! We’re all doing good. It is a wonderful… well, I don’t know how the weather is there but whatever.

Anna It’s excellent!

Jeremy Beautiful, it’s gorgeous!

Brad We’re on different continents! Jeremy; do you want to kick us off and just give us a little bit of a background? I know you like to have some fun with what you’re exact job title is, but could you just give a little overview about who you are and what you do?

Jeremy Sure. I just updated my job title yesterday, as a matter of fact.

Brad What are you now?

Jeremy I was… I’m currently Shepherd of Unknown Futures.

Anna Nice.

Jeremy Yeah, I thought that sounded good. Andy Dennis gave me that one. Before that, I was, I don’t know, Commander of the Armies of the Seven Kingdoms, something like that. So generally, I don’t take much stock in job titles. I don’t find them that useful.

But in terms of describing what I do, my stock answer is really glib and I’m like, I make websites. Although these days, there’s so much involved in making a website that that doesn’t really tell you anything at all.

Historically, I guess I’ve been involved more in the front end side of things; HTML, CSS, JavaScript, all that good stuff, but also I’ve done web design, I’ve called myself a web designer at times; a bit of everything really. Generally at Clearleft, I guess my role is, yes, on the front end development side of things, but more in a kind of strategic over-arching way, as opposed to not necessarily having my hands down in the code, coding stuff for deliverables. Partly that’s because I’m just not very fast at doing that stuff, I take way too long to do anything and so it wouldn’t be a very good use of my time. The other people at Clearleft are much quicker at doing that, so it’s better to have them do that.

Also, I get bored so easily I just find myself flitting from thing to thing, as a way I guess of turning that to an advantage, my job is kind of flitting from thing to thing on a daily basis; checking out stuff, letting the other people in the company know about stuff I’ve stumbled across, feeding that into the work.

Anna Code reviews.

Jeremy Code reviews, that kind of stuff. We have a Front-end pow-wow every Thursday where we talk through stuff on the front end development side of things, but I honestly don’t know what my job is.

I’m doing client work as well but I’m not exactly clear what I do. I guess a lot of people would talk about their work in terms of their output, so a UX person might talk about wireframes or visual design; they might talk about Photoshop or Sketch and a front end developer would talk about HTML and CSS but I generally don’t have many outputs. It’s a lot of talking and yakking and thinking.

Brad So, as part of this more strategic over-arching birds-eye view look of what your agency is working on and what the relationship of the clients is, you’ve had a lot of experience working with style guides and developing pattern libraries for your clients and things like that. How, at a strategic level, have you seen that evolve into what it is that your company offers the clients and how that all fits in?

Jeremy Yeah. On the one level it’s purely an implementation detail, it’s like whether we hand over a pattern library or whether we’re handing over something else. At another level it’s kind of fundamental to how you approach thinking about deliverables, how you approach thinking about the interface. Depends how you come at it.

For the most part, people don’t hire Clearleft for pattern libraries or for any particular deliverable: they’re hiring Clearleft for design work. Not necessarily even visual design, UX and more like thinky-thinky stuff, I guess. But when it comes to the front end, if we do end up doing front end code for the client, then time has taught us that handing over a pattern library or style guide type thing is definitely more valuable than handing over a set of pages, for example.

So a lot of it’s kind of systems thinking, which has been evolving for many, many years at Clearleft. I know Anna’s mentioned Natalie Downe, who used to work at Clearleft and now she’s at Lanyrd, bought by Eventbrite. She’s an amazing front end developer and she started talking and thinking about this very systems-thinking approach to CSS and HTML many years ago and we started putting it into practice in our deliverables; if we were handing over something, how can we hand over a system instead of just handing over a finite set of pages and expecting the client to extract what they need from those pages? How can we give them the extracted bits that they actually need to put together all the pages that we couldn’t possibly consider.

So a lot of that really started with Natalie. Because Clearleft doesn’t ever do a full site build. For example, we don’t do back end development at Clearleft, so we do UX, we do visual design and sometimes we do front end: not every project; sometimes. But we’d never do actual build, the actual back end PHP, Ruby, Python, whatever, and so over the years we’ve had to get very, very good at delivering our deliverables to the client, whether it’s design stuff or whether it’s front end stuff, because we’re never the last people to touch this stuff: there’s always somebody after us.

That was definitely tricky to do at first, but we’ve been around for ten years now so we’ve gotten better and better at doing it and this idea of a pattern library has definitely been, I’d say, the most important development when it comes to front end deliverables. Not entirely sure whether it works, when it comes to visual design and UX and that kind of stuff, but certainly for front end deliverables, the pattern library idea has been really, really strong and it’s worked really, really well.

Anna And how has that evolved over the years?

Jeremy I’m trying to think back to when we would have first started to do it. I think it would have kind of snuck in the back door. Initially yes, we would have still been delivering pages and we’d kind of throw in this collection of pieces as well: so it’d be more like the pages, the deliverables, but here’s also this collection of the pieces cut out into their individual bits. And then over time, that’s flipped to the extent where we make it very clear that this pattern library is the deliverable now.

We’ll also give you some pages, but these pages, they’re not the deliverable; these pages are just examples of the pattern library in action, and that switch has been a gradual thing over the years, I think, going from, we deliver pages and oh, here’s a style guide to: we deliver a style guide and oh, here’s some pages that use this style guide. That second approach is definitely, definitely more valuable, certainly for other developers taking over who have to build this thing and have to actually put it into action, that’s definitely more valuable.

Now, it can be trickier if it comes to other stakeholders like the boss, the client, the guy who signs the cheques. Maybe they need to see more page-like things; maybe they prefer to have a shiny comp or whatever, and we might have to throw them a bone with something a bit shinier, but in our experience, developers really, really like getting a pattern library as a deliverable.

Brad Right. Do you guys sell this idea up-front and again, is there ever… obviously developers and designers to some extent, at least in my experience, are sort of on board with this, they’re like: yeah, yeah, we get it, we see the value in it, but again, even at that sales process, whenever you’re negotiating the scope of work and what’s going to be done and what you’re actually on the hook for.

Do people ever push back or are they scared or just confused at this concept, or how does that work?

Jeremy Each project’s different, so we don’t like to have a set process or even a set set of deliverables for every project: it’ll change on a project by project basis.

But, that said, broadly I think you could characterise most projects that involve some kind of deliverable as falling into one of two categories and the first category is that pattern library category of, we’re going to do design work and we’re going to hand over this set of components that you then take and you can put together into an infinite variety of pages of patterns and components.

But that’s not the right solution for every project and broadly speaking, the other kind of project is much more where a prototype is going to be a better deliverable. And they’re actually very, very different in how you deliver that stuff, because for a pattern library, we’re saying, this is quality code; we’ve really thought about the HTML here and we’ve really thought about the CSS and we think this is the best little widget and component and you can just take this and you can drop it into your live site and it’s going to be great, and the way you approach prototyping is the complete opposite which is, this is not production code; don’t you dare drop this into an actual public website! This happens to be written in HTML and CSS and JavaScript, but it could just as easily have been written in KeyNote or some other tool.

What we’re providing is a way of demonstrating interaction, of demonstrating visual design, of demonstrating animation, something like that. But we are not saying, this is code for you to use. So in a very, very broad way, when we’re doing work that involves front end development, it’ll tend to fall into one of those two camps: either this is code that’s been delivered to the client for them to use in a live site, or this happens to be code, but the code is only there to illustrate the design and the actual final code needs to be written from scratch in a very different mind-set. So, going back to your question about the initial pitching on projects and discussing deliverables, we tend to get a feel pretty early on of which direction the project would be going, like, oh, this sounds like a job for delivering a pattern library; oh, OK, no, a pattern library is not what they need here, this is about some other kind of problem solving and we need to deliver a working prototype, to demonstrate the design but not to be used in production. So we tend to get an idea pretty early on and then I guess sell them on whichever one we think is the right solution there.

Anna And do you tend to work straight in code, or do you come up with mock-ups first and then get them built?

Jeremy There’s nearly always mock-ups first. I guess the question is, how long you spend refining those mock-ups or how quickly you decide, OK, this is good enough to get going, right? And again, that will depend on the client.

On some projects, clients absolutely get it and they’re like yeah, yeah, it’s fine that we’re not deciding in the mock-up.

There’s that wonderful phrase from Dan Mall about deciding in the browser, which I really like.

Backing up a bit, the whole question of mock-ups, or why do mock-ups exist is, I guess, a philosophical question that we’ve been tackling a long time. I mentioned that we had front-end pow-wows every Thursday. There’s also a Design Review, Design Crit that happens once a week. And then inevitably devolves into this discussion of process and workflow and all of this. And it’s a question of what’s a mock-up for? Why does it exist?

(Brad and Anna laughing)

This comes up.

Brad It’s a crisis!

Jeremy Yeah, this existential… here’s my take, is that there’s just three reasons a mock-up could exist:

One is that it’s for buy-in, it’s basically for sign-off. You’re mocking something up to present it to a decision-maker who then says thumbs up or thumbs down, so that’s this decision-making thing, I guess what Dan could be talking about, deciding in the mock-up. That’s use number one.

Use number two is it’s a deliverable for a front end developer, so in other words they’re something a visual designer gives to a front end developer to get turned into code, so that’s a separate use-case.

Now here’s problem number one, is that mock-ups made for the first use-case end up getting used for the second. So, if you’re designing for sign-off, everything’s perfect: everything lines up at the top and the bottom, it’s exactly the right amount… everything looks beautiful. It’s not a real test of the edge cases of content. And unless you then make further mock-ups that are more accurate and reflect the real situation with content and you just hand over this perfect situation to developers, well, everyone’s just going to get disappointed: the developers are going to be frustrated because it’s not accurate, the designer’s frustrated because, hey, that doesn’t look like my mock-up, and the client is frustrated because that doesn’t look like what they were presented with.

Oh, and then there’s a third use of a mock-up, which is for a visual designer to think. They have a tool that they’re comfortable with, like Photoshop, Sketch, Illustrator, whatever and it’s the fastest way for them to get ideas down is to create a mock-up.

Anna Like element collages?

Jeremy Yeah, or even a full interface; even making a page. But the difference is that the reason for its existence is that third use case and not those first two. So, for a designer to go away and create, here’s a page in Photoshop, or here’s a page in Sketch, that’s absolutely fine, I think, as long as the reason for doing that is to get ideas out. It’s not then fine to then present that to a client and say, what do you think? Give us sign-off, and it’s not fine to present that to a developer and say: there you go. Now go and build that. They’re three very different use cases. The getting the designs out of your head, getting sign-off and a template for build. Those are three different use-cases. And yet what happens is, a single mock-up will end up kind of doing all three.

Brad You’d better believe it!

Jeremy So this is the problem I’ve found with mock-ups, we’ve found in general, is this mis-match, I guess, of expectations. And this is why I love Dan’s idea of deciding in the browser, so for that first use-case, you’re talking about deciding in the mock-up; you show the client to give you sign-off. The decision has been made. Then you move on to use-case number two where you’re handing it over to a developer to turn into real code and that’s when reality hits and differences crop up; questions come up that you hadn’t anticipated, but now it’s too late to make the decision to say, oh well, look, that’s been agreed, that’s been decided, that’s what the client signed off on, so I really like Dan’s idea of deciding in the browser where you say, yeah, you do stuff in Photoshop or Sketch or whatever you’re comfortable with; it’s more about that third use case, use whatever tool is comfortable with you. But you don’t go to the client and say, approval or not approval, until you’ve got it in web browsers, until you’ve got it in code, because that’s just so much more accurate to reality. So much more realistic, and makes much more sense to decide in that point, but going back to the original question, would there be mock-ups preceding the mark-up, I guess, the CSS? Yeah, almost always, there’s almost always some kind of mock-up. Now, in an extreme case, that mock-up could be literally paper; could be pencil on paper. More often than not, it is usually a tool like Photoshop or Sketch, something. But like I said, there’s definitely diminishing returns in polishing that mock-up too much, making it perfect because what’s the point? The actual place to do that and make it perfect is in the code, when it’s in web browsers, so the right level of fidelity I guess is the big question and that changes from person to person, from project to project, from client to client. I don’t think there’s a right answer. The right answer is to figure out what’s the right level of fidelity for the mock-up for this project, for this client.

Brad Yep, and do the designers working at Clearleft, bringing this all back to what this all means for, if indeed it is a project where you’re delivering a pattern library, in my experience working with more visual designers, working in static tools, there’s this tendency in a lot of us due to the tools themselves just aren’t actually as sophisticated as HTML, CSS and JavaScript as far as actually developing more of a pattern-based workflow, so what we’ll have is I’ll have designers, historically, making bespoke home page designs and then we’ll get into an interior page and then that will have its own look and feel, so I guess how does Clearleft’s designers work with, how are they aware of this whole pattern library approach, this systems thinking? How do you instil that into your culture and how do they execute it in a pattern-based way, even if they are working in a static tool?

Jeremy Yeah, it’s interesting. I think that the systems approach that came from the front end with people like Natalie thinking this way has definitely infected the visual design part as well: it tends to happen sooner. Even if it’s almost retro-active: the designer maybe finds it easier to just go away and just design screens, interfaces, but that’s retro-actively…

Brad Use-case three, right?

Jeremy Yeah, use-case three, exactly. But then retro-actively, OK, now I’ll extract the patterns and put them together, and that’s when they might notice inconsistencies in their own designs; oh, I thought this button was meant to be the same in all five screens but actually it’s slightly different here and I’ll need to adjust that and make it consistent. Because doing good design, it should be consistent, there should be a logic behind it. Yeah, there’s definitely been more systems thinking happening on the visual design side and we’ve tried things like Style Tiles, Element Collages, these kind of things.

Anna There was a really good blogpost, I think Paul Lloyd wrote it, about how Jon had been doing style tiles and he used to do them vertically, but now he does them horizontally because they were looking too much like a mock-up.

Jeremy Right, again, every client’s different, every project’s different and I was on some project where in showing them a document which is meant to show, here’s a bunch of elements collaged together, the client was mistaking it for an actual page, which you could kind of see, it kind of makes sense that that’s what our brains would interpret that file as, but as soon as Jon flipped it and made it horizontal rather than vertical, then straight away it was clear: oh no, I’m just looking at a collection of components one after the other, but they don’t form a cohesive whole, it’s just separate components.

So that was really interesting and that’s something that Dan, because we got the element collage thing from Dan Mall, and he’s taken that back on board himself: oh yeah, that’s actually really smart and now he does that too.

So again, lots of experimentation, I would say on both the front-end and visual design side, we haven’t got everything figured out and we’re still figuring this out; there’s definitely issues with the tools, some tools seem to lend themselves more than others. Even in small ways like with Photoshop, as soon as you go to create a new document, it asks you what’s the width and the height of the document. That’s a small thing, but straight away you start to think in terms of well, is it a mobile or a tablet or desktop screen, whereas something like Sketch is an infinite canvas. So it has a slightly different take on it, you can just throw things onto this infinite canvas, so it maybe lends itself a bit more to this componentised element collage or style tile way of thinking.

But like I said, the tools don’t really matter, it’s how you approach it. As for designers thinking the systemic way, I think good design tends to do that anyway because you start with a type system, is usually at the root of everything, and a grid system will come out of that but it’s a system; it’s systems built on systems, there’s rules behind that and so good designs will have rules anyway.

I guess the difference is, making those rules clear and bringing them out and showing them. Like sometimes it’s retro-active; well, let’s slap on some translucent pink columns to show what the grid looks like. Nobody yet has decided to slap on a golden ratio Fibonacci swirl onto their design, so that’s good, right?

Brad That’s very good!

Jeremy You know what I mean about the retro-active… oh look, it’s a system; it’s totally a system here! But you know, we’re still figuring this stuff out.

Brad That’s better that you’re pre-emptively getting the designers to think in that way because again, historically, comps have been thrown in my face and I’m like, well, what about this or what if you add this in here, and they’re just no system whatsoever and instead of, oh yeah, I guess that should be more consistent it’s Brad, you’re being difficult!

Jeremy Why can’t you just build it? Why can’t you just do what I…

Brad Can’t you just make the thing? And it’s like well, technically I can but that doesn’t mean it’s going to be good.

Jeremy So, what tends to happen on projects is that there’ll be some lead in with visual design and the visual design would probably begin a bit before front end dev, although it’s always good to have a front end dev around to just look over your shoulder and check stuff.

Then you have a period of both visual design and front end dev happening together, kind of back and forth where, get it into web browsers, look at it and maybe adjust the visual designs, but then there comes a point where it’s like, it’s not worth going back into Photoshop, Sketch, Illustrator, whatever your tool is, at this point; we just need to be doing this in browsers and there’s no point, it’s just wasted effort, to reflect those decisions and those changes in the visual design files because those visual design files aren’t the deliverable: those are tools to get you to the deliverable, which is the final website.

So, it’s different from project to project where that point is, the point at which you don’t need to go back to the visual design files at this point; let’s just sit together and make changes in CSS Web Inspector.

Brad Yeah, working with Dan it will fantastic because we’d do everything in the browser and then it’d be like, at this point in time, things are just looking really awkward and so we’d actually just go in and screenshot things and fiddle with things, move them around in Photoshop and then say, how about this? And what we found is that the vast majority of what he was producing was mostly meant for me; it wasn’t that sort of client deliverable.

Jeremy Yeah, it’s not for sign-off.

Brad That sort of client deliverable sort of thing, yeah, which is great.

Jeremy Exactly.

Brad So, you’ve been involved with quite a few of, actually a lot of our guests; you’ve touched or influenced in some way a lot of the thinking about style guides and pattern libraries and all of this stuff. We had Lincoln on, formerly of Starbucks. Do you want to share that story real quick about how that came to be?

Jeremy Like I said, at Clearleft I’d been thinking about the system thinking for quite a while and I mentioned Natalie, and when Natalie left we had Andy Hume working at Clearleft, a great front end developer. And he was giving a talk at South by Southwest a few years ago, about CSS systems; now this wasn’t necessarily pattern libraries; things like OOCSS and SMACSS and BEM and all this stuff, just a way of approaching CSS in a more engineering kind of way, I guess.

But he did talk about style guides, the concept of style guides. Specifically he mentioned that the BBC had this GEL, this Global Experience Language, which the whole organisation uses. But he pointed out that one of the problems with GEL is that it’s in a PDF and it would make much more sense for it to be in HTML, to be in the final medium.

It was quite fascinating: when it got to the Q&A, somebody stood up and said, “I’m from the BBC and I’m from the GEL team” and I was kind of thinking, oh shit, Andy’s in for it now, but the guy was like, no, you’re absolutely right, it makes no sense that it’s in a PDF, it should be in HTML. Oh, thank goodness!

Brad That’s great.

Jeremy After this great talk, all these people were coming up to chat to Andy about this, and I was hanging out because I wanted to congratulate Andy and say, great job with the talk, and so this guy starts chatting to me, says he’s from Starbucks; it’s Lincoln and we’re having a chat and he says, you know we actually have a sort of style guide like the BBC thing except it is actually in HTML and CSS and my first question was, “Is it public?” And he was kind of like, no, he hadn’t thought about it, so I was like, “Why don’t you make it public?” and that’s kind of my default reaction when people get in touch with me or come over and say, hey, we’ve got a style guide or pattern library or whatever, because I’ve been blogging about it and talking about it, my first question is, “Is it public, and can you make it public?”

And they did, the Starbucks guys made it public and I don’t think they thought that much about making it public but boy, did that ever get press: it was like, wow, this huge coup for them, it was great, so I think they’re very, very happy they did make it public.

And in general I just love to see people sharing things. Style guide, but in general I like when people blog, I like when people say, hey, I solved this problem and here’s how I did it; this worked for me, maybe it won’t work for you but I’m going to document what worked for me.

Anna It’s kind of how the whole web works.

Jeremy Exactly. When I was first learning to make websites I was viewing source, I was on mailing lists, I was reading Ask Dr Web on zeldman.com; these people were just sharing their knowledge and I want to make sure we keep that and whatever new thing comes along in front end development or visual design or whatever, I like it that our default position should be, let’s share this, let’s just put it out there. Even if it’s something that’s clearly just for you; I link to style guides all the time. Just last week there was, let’s see, Heroku put one live

Brad Yeah, it’s beautiful.

Jeremy GitHub updated theirs, they put theirs out there, and I say in the link, this is really only useful for the people at Heroku and GitHub but check out how they’re doing it, to see how other people are doing it.

It’s not that you’re going to take that actual code, you’re not going to take their mark-up or their CSS and use it in your own side, but to see how they’ve approached it and what the thinking was behind it and go, oh, I see, and that can influence your own way and what works for you is going to be completely different to what works for Starbucks or MailChimp or Heroku or GitHub, but the fact that you can look at these other examples is fantastic.

Brad Yep, and it’s not all idealistic, although I’m fully supporting that obviously, but guest after guest, one of the reasons why we even have them on is because their style guides are live so that we could look at them but especially with people like Jina Bolton at SalesForce, she specifically joined their team because she was in love with their style guide and I get really frustrated, because I talk a lot about sharing and being open and all of that stuff and it’s always, oh my boss won’t let me or oh, whatever, and it’s like, whenever you think about how you actually reach people and get people on board and everyone is always struggling to hire talented folks, it’s like, you need to show them the goods, you need to show them what you can do, and I think that these style guides are a great way to show, look, we’re working using modern techniques, modern technologies, we can show off how we do things and that becomes a massive recruitment tool, which is awesome.

Jeremy Yep, and my general attitude with a lot of this is, it’s easier to ask for forgiveness than for permission.

Brad Totally.

Jeremy Just go and do it and if you get flack from the boss, even though you’re getting all this great, positive press say, oh sorry, do you want me to take it down now? And then you should say no, well now you’ve done it… that was kind of my attitude with stuff like the Open Device Lab, I basically just threw the doors open and said hey, anyone can use these devices, without stopping to think or check whether that was OK or what’s the worst that could happen? It’s more like, I’ll just do it and see what happens and it’s fine; everything’s fine.

Anna So, something that I’m quite interested in is, as an agency, how do you, ensure that these style guides are maintained by the client?

Jeremy So, that’s a good question. In a way it’s begging the question, because I’m not sure that the…well, first of all, let’s step back a bit. The terminology here, I’m going to talk specifics about pattern libraries.

Brad Oh, here we go! We were just talking about this!

Jeremy Right. What’s a style guide? What’s a pattern library?

Brad It’s worth discussing for sure.

Jeremy OK, my take is, what we tend to be talking about at Clearleft because as I said, the audience for this deliverable we’re building is other developers; it’s not decision-makers, it’s not designers. It’s developers who have to actually put the site live. And for that reason, the best way I think to describe what we’re providing is a pattern library; it is literally a library of front end patterns.

Now, a pattern library I think can be part of a style guide, and a style guide could contain other things. It could contain tone of voice; it could contain here are the colours, here are the font choices, here are… the classic style guide stuff around where the logo is positioned relative to corners…

Brad Brand style guide.

Jeremy Right, brand style guides. So I guess a pattern library would be a sub-set, a specific sub-set of style guides, so just having cleared that up, what I’m talking about here is pattern libraries.

In the case of Clearleft, an agency handing over a pattern library as a deliverable, I don’t think what we hand over is necessarily what should be maintained. In a way, what we’re handing over’s kind of a one-time thing saying OK, as part of our engagement, we did the design work, we created a pattern library: here you go, we think this is what you need to go on from here.

Now, we might highly recommend that that company have their own pattern library, have their own style guide, pattern library and more, but whether they choose to use our deliverable as the starting point for that or not is up to them. It would make sense in a lot of cases that OK, we’ll take what Clearleft has given us as a starting point and going forward we’ll be maintaining it, we’ll be adding to it, we’ll be changing it, but it might also be that for to really be owned by an organisation, the organisation kind of has to make it themselves, that it isn’t something they’ve inherited, it’s something that comes from within.

I think it’s really interesting that most of the examples out there are from companies and products rather than agencies: the examples of style guides, a lot of your guests on the show, they’ve made this internally, they own it, they’ve put their blood, sweat and tears into it; I’m not so sure whether you can be as invested in something that you get given, something that’s handed over to you, so that might be a bit controversial, but the way I see the pattern libraries that Clearleft are building is not necessarily as things in of themselves to be maintained, but maybe only as starting points.

Anna So kind of blueprints for building the site?

Jeremy Yeah, these are deliverables, we think they’re superior than to delivering pages; we think they’re definitely superior to delivering comps but there’s a whole step again I think into having this kind of living, maintained style guide, and I kind of feel that that needs to come from inside the company.

Brad Yeah, it absolutely does and I think it’s interesting talking to Dan on an earlier episode, Dan Mall, he was talking about his own work and it is, because you don’t work for them so you can’t change their culture to make this a priority for them; it has to come from within, but I think that the opportunity for people working on a contract or agency relationship, what Dan was saying is he’s sort of built it into his contracts now, wherever he is.

The idea typically is, what we’re handing off is something that should take root and you should develop further and what he’s been baking into his contracts has been, I’m going to check in, in a few months and we’re going to see how this thing is working out for you. I thought that that’s just the freaking smartest crap because one, that’s more money and more opportunity for the contractor; it’s not just like, oh well, they just threw it in the trash can so shrug your shoulders and move on to the next gig; he’s building it in as an opportunity to help them through.

Jeremy Yeah, we try wherever possible to have that built into contracts to say, we hand over a pattern library and in a way, that marks the end of our work together, but we want these extra few days, one in a week’s time, another in maybe three weeks’ time, another in six weeks’ time, these regular intervals, to check back in because that’s the only way you’ll ever find out: how clear was this library? How good was the documentation that a company did? How self-explanatory were those class names that we thought were so great?

Brad Didn’t you guys just go through that with Clearleft or with Code for America with the project?

Jeremy That was an interesting one because that was to do with the audience. As I said, usually the audience as in for the pattern library will be developers, other developers either front end or back end developers who are taking this and implementing it, and it was really interesting with Code for America, so we had Anna working with us, which was great, and in the first round we made sure that the CSS was really robust, putting in a lot of the current thinking about really maintainable, robust CSS, which means there’s a trade-off in the HTML where maybe you’ve got a lot of class names.

But if the developers are the ones doing the HTML and CSS that’s absolutely fine. Now, as it turned out with Code for America, the developers weren’t necessarily the ones doing the HTML, because lots of different people were creating new sites or new pages, copying and pasting this stuff, and while it’s perfectly reasonable to expect those people to understand, say, basic HTML, what a paragraph tag is, what an H1 is, it’s not really fair to expect these people who aren’t developers to now have to learn a whole another vocabulary which has these great class names we’ve come up with, right?

Brad Right.

Jeremy And so the second phase of work was really interesting where we started to take some of this complexity that we offloaded the HTML and put it back into the CSS, and we made it clear in the second look, we think this CSS is now actually a bit less maintainable, a bit more brittle, it isn’t as robust as what we first delivered, but it is the right thing to do for this audience because the people making the pages aren’t necessarily developers, so that was really interesting in a kind of every project is different and there’s no right answers and there’s no one true way of doing this stuff: it was a great experience.

It was also frankly great to have a client where we got to re-visit stuff, because so often, you do your work for them and then it goes live or it goes out and then you see all the stuff that you could’ve done better or could’ve been fixed but now that it’s actually live, you want to iterate. And that is one of the downsides of agency work as opposed to product work, is maybe you miss out on the chance of iteration, of being able to re-visit stuff, so the Code for America project was great for a number of reasons, but one of them was the fact that we had a second round that we got to iterate, re-visit the stuff and check our assumptions and re-visit the things we’d decided in the first round.

Anna That was a real eye-opener; I really enjoyed doing that.

Jeremy Yeah, it was good; it was good to see how something we thought was fairly fundamental was maybe not necessarily true and so we need to re-visit it, but that’s OK; it was all out in the open, it was all clear what the problem was and it was a great project.

Brad I’m not speaking because Anna hasn’t talked for a while!

Anna Oh, sorry!

Jeremy Awkward pause!

Brad Awkward pause! That’s right!

Anna Just sometimes when I do this I think that I’m actually listening to the podcast rather than…

Brad This is great!

Anna Yeah, keep talking!

Brad Are you on a treadmill right now? Just running along.

Anna I’ve gone so red!

Jeremy That reminds me; apparently there’s a story of Peter O’Toole being at the theatre, he was taking some friends to the theatre and they’re sitting in the audience and he goes… oh this next bit is great, this is the bit where I come on. Oh shit!

Brad That’s excellent! OK, well all right. Looking at the time, I actually think that we need to wrap up anyway, so maybe it is good that we don’t continue on, although I’m sure we could talk all day.

Anna I really want to but I also know Jeremy probably needs to eat his dinner.

Jeremy You know me; you know once you wind me up and get me going, it’s hard to shut me up. I can talk about this stuff all day but yeah, we should probably be merciful upon the ears of the listeners!

Brad Well thank you, dear listeners, for hanging in there! We covered a lot of meaty bits; I feel like it’s all right to end on a light-hearted note, I think.

But seriously, thank you so much for coming on the show and thank you so much again for your advocacy. It definitely has had a snowball effect; this podcast wouldn’t have existed if the Starbucks style guide weren’t released and so it is as a testament to the openness and sharing nature of the web that this all compounds on itself and thankfully we have people like you that instigate and prod and get people to open up. So, thank you so much for all of that.

Jeremy Well, thank you guys for doing this podcast for the same reason: getting people to share what they know.

Brad Awesome. Well, that’s it for this episode of the Style Guides Podcast. Thanks again for listening and thanks Jeremy for being on and we will see you again. Bye!

Anna Bye!

Saturday, September 13th, 2014

Hypertext as an agent of change | A Working Library

The text of Mandy’s astounding dConstruct talk.

Marvellous stuff!

Saturday, September 15th, 2012

Listen to Brighton SF

Brighton SF really was a wonderful event: Brian Aldiss, Jeff Noon, and Lauren Beukes all gathered together for an evening of chat and readings, hosted by yours truly.

Brian Aldiss, Jeff Noon, and Lauren Beukes on the Brighton SF panel, chaired by Jeremy Keith

But you don’t have to take my word for it. Thanks to Drew’s tireless efforts, the audio is now available for your listening pleasure on Huffduffer. I’ve also published a transcript.

Brighton SF with Brian Aldiss, Lauren Beukes, and Jeff Noon on Huffduffer

I highly recommend giving it a listen: readings from Jeff and Lauren, together with wonderful tales from the life of Brian Aldiss …superb stuff!

#BrightonSF It's Brian Aldiss, Jeff Noon, Jeremy Keith, and Lauren Beukes on stage for Brighton SF.

If that whets your appetite, there’s more audio goodness from each of the authors to be found on Huffduffer:

In the meantime, enjoy Brighton SF with Brian Aldiss, Lauren Beukes, and Jeff Noon.