Tags: transcript

41

sparkline

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.

Jen TCP/IP.

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.

Wednesday, February 1st, 2012

Publishing Paranormal Interactivity

I’ve published the transcript of a talk I gave at An Event Apart in 2010. It’s mostly about interaction design, with a couple of diversions into progressive enhancement and personality in products. It’s called Paranormal Interactivity.

I had a lot of fun with this talk. It’s interspersed with videos from The Hitchhiker’s Guide To The Galaxy, Alan Partridge, and Super Mario, with special guest appearances from the existentialist chalkboard and Poshy’s upper back torso.

If you don’t feel like reading it, you can always watch the video or listen to the audio.

Adactio: Articles—Paranormal Interactivity on Huffduffer

You could even look at the slides but, as I always say, they won’t make much sense without the context of the presentation.