Transcript

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. [Laughs] 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

[Laughs] 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

[Laughs] What day is it?

Jeremy

You've been on the road too long. [Both laugh]

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. [Both laugh]

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

[00:02:18] 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. [Both laugh]

Jen

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

Jeremy

[00:05:40] 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

[00:08:39] 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 and 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

[00:11:07] 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

[00:13:55] 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

[00:18:22] 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

[00:20:02] 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

[00:21:40] 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

[00:23:17] 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

[00:24:26] 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

[00:24:50] 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

[00:28:14] 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

[00:30:15] 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

[00:31:55] 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. [Both laugh] 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

[00:34:12] 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

[00:35:47] 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.

Jen

TCP/IP.

Jeremy

[00:36:41] 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

[00:37:50] 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!" [Laughs]

Jen

I know! You're getting a reputation as the guy who hates JavaScript. [Both laugh]

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. [Laughs]

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

[00:46:19] 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

[00:46:58] 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. [Jen laughs] 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

[00:48:51] 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. [Both laugh] “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. [Both laugh] 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 laughs]

Jen

I'm working on it. I'm trying to fix that.

Jeremy

[00:51:12] 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?” [Both laugh]

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." [Both laugh]

Jen

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

Jeremy

[00:54:07] 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. [Laughs]

Jeremy

[01:00:18] 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

[01:02:35] 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

[01:05:11] 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

[01:07:32] 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. [Jen laughs] 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. [Laughs]

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.