Episode Transcript

Karen:

Hi, this is a Responsive Web Design Podcast, where we interview the people who make responsive designs happen. I’m your host, Karen McGrane.

Ethan:

And I’m your other host, Ethan Marcotte.

Karen:

…Ethan, where’s the guest?

Ethan:

Oh, man… I think I might have left them back in the nog during the holiday week. I don’t know, I’m not exactly sure what happened… Well, this is a bit awkward.

Karen:

Well, it’s a fresh start for 2017. It’s just you and me.

Ethan:

Super, super. We’re definitely starting things off on the right note, then. [laughs]

Karen:

We are. We’ll see our podcast statistics dramatically take a nosedive here in 2017 when people realize it’s just going to be us wingin’ it for the next forty-five minutes.

Ethan:

I’m pretty sure it’s just my mom who listens to this anyways, so I’m sure it’s fine.

Karen:

[laughs] Well if anyone’s out there or reading the transcript, welcome to 2017. We’re happy to be here talking about responsive web design and other things.

Ethan:

Yeah, yeah. I mean, there’s nothing else going on in the world right now that’s worthy of discussing other than responsive design, so let’s focus on that.

Karen:

My laser-like focus on web design, a near obsession that can’t be swayed by anything else going on in the world.

Ethan:

Nope, that’s right. 2016 was a singularly uneventful year, leaving the stage clear for all talk of RWD. So, that’s a beautiful thing.

But yeah, what’s new and hot on your mind right now? Things you’re especially proud of from last year? Things you’re looking forward to? What’s new and exciting responsive-wise in your mind, Karen McGrane?

Karen:

Well, I thought maybe it might be a nice moment to look back on some of our favorite episodes from 2016, because I think there are some out there that I always have a lot of excitement around, and I hope other people will, too. One of my favorites that we did last year was with the team from Casper, the mattress company, they send you a mattress in a box. That was just a fantastic episode, it went live on November 14th, and you know, I just don’t think it got the attention that it deserved, so I’d love to call that one out as I think a really great analysis of how a brand and how a particular company’s value system can get reflected in a redesign, and particularly a responsive redesign.

Ethan:

Yeah, exactly. Speaking with Claudina and Becki was a real highlight for me. I’ve been admiring Claudina’s work for some time now, she’s very big in the Sass community, she’s a front-end developer and a very design-focused developer who’s very thoughtful about pattern-driven design work. It was really exciting for me to hear their perspective, because Casper I think had been responsive since day one, and so we basically had them on to talk about their second responsive redesign, if I’m remembering correctly. So, it was really interesting to hear their perspective.

Karen:

Another one that I really liked was the team from KLM, the Dutch airline. Kind of on a different take, I think that was a very process-focused conversation. The team there was pulling off, as many organizations are, a large-scale enterprise responsive redesign, and trying to manage something as complex as an airline and all of the various stakeholders and groups across the airline, and how all that works together. I thought it was just a really extremely interesting and packed-with-information episode.

Ethan:

Yeah, I couldn’t agree more. I think what really struck me is they were very frank about the fact that—you know, when you think of a big travel brand, you tend to think of it’s just one website, right? But in reality, that website’s probably multiple different products or applications pulled from different lines of business. KLM was basically saying that they had to migrate about I think something like two dozen different applications over to this new responsive framework, and I think a big part of why they said they were able to do that was because they invested a lot of time in creating this component library that they could use to update the responsive interface across the board.

Karen:

Yeah, that was fascinating.

Ethan:

Yeah, absolutely. Actually, since we’ve talked about Casper and KLM, a bit of a sidebar here, but last night I was reading Anna Debenham’s new book on front-end style guides.

Karen:

I love Anna.

Ethan:

Yeah, Anna Debenham is amazing.

Karen:

She also has the best cat.

Ethan:

She does have the best cat. Shout-out to Beemo, whose photos thereof are basically one of my highlights of Twitter.

Karen:

[laughs] She’s genuinely one of the bright spots in my life, and she sends me a lot of pictures of her cat, and I would like to give a shout-out to how much that has meant to me.

Ethan:

[laughs] Now I’m just mildly upset I’m not getting as many Beemo photos as you are. But that’s fine, that’s fine. But for any listeners who might not be familiar with Anna, she’s an incredibly talented front-end developer in the UK. She was actually the tech editor of my last book.

Karen:

Lucky…

Ethan:

Yeah, yeah, she made it much, much better. She’s a fantastic person. But anyway, if you get a second, check out her new book because it’s the second edition of Front-end Style Guides, a wonderful walk through how to create a style guide for your web design project, how to basically break up pages into individual components, and different processes you can use, different tooling and instrumentation you can use to automate that process. It’s a really short but incredibly educational read. If you want to pick it up, I would totally recommend it.

Karen:

I would second that recommendation. I hope everyone goes out and gets a copy. It’s available now, and I think you’ll learn a lot about front-end style guides and how to think about the world in this structured, component-based way.

Ethan:

Absolutely, because I think that was a big theme definitely in my work last year in terms of being a little bit more component-focused with responsive design. It’s been interesting to hear more and more of our guests on the podcast just independently mention that, from Casper to KLM. Another favorite of mine was when we sat down with Rob Giampietro from Google Fonts.

Karen:

That was such a fun interview.

Ethan:

Yeah, yeah. It was one of those interviews where I felt bad stopping the recording. [laughs] Rob is a designer I’ve admired for years and he’s just a genuine delight to listen to. But I was really excited about it because I think Google is one of the first companies to really put a solid first step forward in coming up with a cross-platform responsive design system. And Material Design is kind of impressive in the scope of what it’s actually trying to do. Talking to how Rob’s team was able to apply Material Design to the Google Fonts product was really fascinating. It was a lovely example not just of applying a framework to a new product but actually trying to think about how it needed to be modified to make it feel like it actually belonged in this new product that they were working on. So, I thought it was really lovely.

Karen:

I’ve really enjoyed a number of interviews we’ve done around typefaces on the responsive web. We just spoke to Typekit quite recently, and if you all are interested in responsive typography, I think we’ve got another couple of great episodes coming up in 2017, so stay tuned for those.

Ethan:

No spoilers. [laughs]

Karen:

[laughs] “Here on the Responsive Web Design Typography Podcast…”

Ethan:

[laughs] Oh, man… Yeah, well we’re coming up on—we just had our hundredth episode last year, so we’ve got to rebrand ourselves at some point, I suppose.

Karen:

How did that happen?

Ethan:

Yeah, it’s continually amazing to me.

Karen:

An endless source of somewhat fascinated confusion.

Ethan:

Every time we sit down to record a new podcast, I remember the moment you approached me about doing a podcast. It was almost like somebody asked me to drive my Model T around the corner or something like that. Like, I didn’t realize people still did podcasting in web design circles, and I’ve got to say, this is continually the most fun part of my day. So yeah, I can’t believe we’ve done over a hundred episodes and I’m excited for the next hundred.

Karen:

Well, thank you for humoring my dumb idea. If at some point you want to tell me it was a bad idea, we can… Well, it’s gone on too long now.

Ethan:

[laughs] Yeah, we just have to see it through to the end. No, this is entirely too much fun to stop.

Yeah, but any other podcast episodes that really jump out at you? Typekit was a good one.

Karen:

You know who I really enjoyed talking to was Lisa and Ringo from Merriam-Webster. That was a great episode.

Ethan:

That really was.

Karen:

If anybody follows Merriam-Webster on Twitter, I think it’s pretty rare to think of hashtag brands as having a decent social media presence, and even more striking that the dictionary would manage to nail it. But I think their overarching digital strategy as executed on the web or in social or even in apps and things is really solid, and that came through from Lisa, who is their chief digital product officer talking about how they approached their responsive redesign.

Ethan:

Yeah, absolutely. I’m remembering now when we were talking with Ringo, she’s the digital design director at Merriam-Webster, and one theme that I hear in a lot of the workshops that you and I do with clients, and some of the clients that I work with as well, is the role of traditional design applications in the responsive design process. Ringo was actually using tools like Sketch and Photoshop pretty heavily to talk about the new redesign, and so that was a really nice example of how you can be a little bit more modest with rethinking your design process if you’re going responsive for the first time. So, I really enjoyed that interview, it was really insightful.

Karen:

Just as an aside, as Ethan mentioned, we do workshops with clients, and if anybody’s interested in having Ethan and I come in for a day or two to talk about how to manage a responsive redesign process effectively, that’s something you can contact us about if you go to responsivewebdesign.com.

Ethan:

Absolutely. We would love to hear from you and hopefully meet you in person.

Karen:

Well how about you, Ethan? What’s on your mind? I know you’ve been talking about various component-based design systems and have even been writing about them a little bit lately, which is a bold move…

Ethan:

[laughs] Yeah, you know, I think for no reason whatsoever in November I was finally motivated to focus in on this redesign of my blog that I’ve been sort of struggling through for the last couple years, easily.

Karen:

How are things there in 2006?

Ethan:

Well, you know, it’s great. My Treo Sidekick gets like 2G download speeds. I don’t know, those are words, I guess.

Anyway, yeah, so it was weird, but I’ve been feeling like with everything that’s been happening with the world at large, it’s been kind of nice to have a space for myself to actually do some writing and get some thoughts in a slightly longer format than a tweet. But one of the first posts that I put up, a couple weeks ago now I guess, was talking about design patterns and how we tend to treat them on the web. I think if anybody who’s either listened to our podcast or who’s been on our podcast might know, when we think of a pattern library or a style guide, we tend to think of a whole bunch of web pages that basically list all the individual design patterns in isolation from each other. So you get to go to a page or a section of a page and see the login form, or the search field, or the logo for example, or a bunch of button treatments, and they just tend to be kind of basically like little cut and piece components that you can then move to actual responsive pages.

The one thing that I’ve been hearing from some of the folks that we’ve worked with in workshops and some of my clients is that’s a great first step, but there’s so much more that we could be doing with this. Specifically, actually getting a little bit more context into the pattern library so we can actually explain what the business decisions were that got us to this point, like what needed to be in the masthead, what acceptable cases of use are for these different classes of buttons, even. So rather than thinking about your pattern library just as a deliverable for front-end development and design teams, actually trying to introduce a little bit more context into what these patterns are meant to be in a larger design system is I think the next step that a lot of people are seeing. That’s where I’d like to see the conversation move in the next few months.

Karen:

I think that’s really smart and I think it’s such an intersection of what role that pattern library plays in communication with the rest of the team. I just think that, as with everything on the web, nothing is ever just strictly a design and development problem. Even if the impetus to create a design system or a pattern library is coming out of the web design and development team as a tool that will help them do their jobs better, it’s never something that touches only their work. It’s something that the rest of the organization, the writers, the content team, the marketing team, the back-end development team—everybody is going to wind up having some say or some stake in how those patterns operate. So, really planning that out from the start and understanding that we have to have that context, it can’t just be seen as like, oh, we’ve created these front-end code snippets to make our coding processes more streamlined. It’s got to be we’ve created a system that will help everybody be more effective in making choices.

Ethan:

Yeah, exactly. The one thing I touched on in the post was this discussion around design principles, which was a big theme in my last book. I think ultimately you want to get the pattern library or this design system in a place where it’s going to be clear what acceptable new modules or new patterns are going to be. I think Vox Media, who we’ve had on the show a couple times now, do a really beautiful job of this, where they have some pretty clear design principles that they use when they’re talking about introducing a new design pattern to basically see if it actually measures up to their standards. Some other organizations like Salesforce do this really well, also. Google, again, their Material Design system I think is really clear about what a module or pattern has to be in order to be incorporated effectively. In fact, Karen, the whole time I was writing that post, I was thinking about that one section in your book about the different stages of maturity in design patterns. I’ve always found that really fascinating. I don’t know if you want to break that down for our listeners a little bit.

Karen:

So, I sort of hypothesized that there are three different levels of maturity in how teams think about their modular designs. The first is I think as we’re describing here, teams will put together a library of reusable front-end code snippets. So, it’s something where the team can go in and have kind of a browsable interface of here’s a calendar widget, here’s pagination—and I want to be clear: that’s super valuable. Like, if that’s where teams are at, by all means, go do that because you’re going to get some value from not having to reinvent the wheel every single time you need to put pagination on your pages. But that, to me, is actually only the first level.

So, the second level is teams start integrating some of the work that I do in my own practice around what’s called content modeling. So, understanding how content structures and how guidelines around content types and what those attributes of the content types are, and how big that’s content going to be, and what’s expected to be there, how all of that can intersect with the design patterns. That’s not a one-to-one thing. It’s not like, oh, okay, in this design pattern we’re always going to have this particular type of content, or this particular type of content can only be displayed in this way. It’s sort of a many-to-many relationship between the content and the designs. But to have that understanding of what the expected content structures and sizes will be, to me, is something that I think is often missed by teams that are putting together a design pattern system. I fear sometimes that we are merely replicating the same problems that we’ve had of the past decade, of generating templates, or now components, without any solid understanding of what the expected content will be. Then when the content team is handed these things, they’re like, “Well, how do I fit my goals, how do I fit my communication challenges, my narrative expectations into this box that you designed for me?” And it might just be a smaller box, but we’ve got the same problem there. So, I really do think that the opportunity to integrate the content model and the design patterns is a huge next step for most teams.

And then beyond that, a third level is the idea that those things can actually be built into the back-end, and that we can have tools actually in the content management system itself that help us do that effectively. That is, I think, a hugely complex not entirely well-executed goal for many teams right now. But honestly if I look at where I think content management has to go in the next three to five years, it’s figuring out, in a web publishing environment or even a larger enterprise-decoupled environment, how do we ensure that we understand the content structures and we understand the design patterns and we have tools that help people fit those two things together.

Ethan:

I’ve heard you talk about these three different steps a number of times and I always find it really fascinating every time you do. Do you know if anyone has gotten to that third level quite yet, or any companies that are tackling that problem?

Karen:

I think a lot of teams are tackling I would say all three of these right now at the same time. As I’ve said before, I’m especially fascinated by how this type of problem gets solved in a decoupled environment. So, as we’ve discussed before, the idea that many teams are moving away from having a monolithic web publishing system in which the content and the designs and the publishing layer are all kind of munged together in one big glob of a system, and instead moving to a decoupled architecture in which the content lives in an underlying repository and then APIs are used to get that content out to whatever different display applications needed. So, that might be a website, but it could also be apps or digital signage, or heck, even PDF documents could be considered a client of the content. That kind of approach is not necessary if the organization only maintains a single website. That would be way too much architecture if all you’re doing is publishing one website. But if you have a lot of different channels that your content has to appear in, decoupling the content from the presentation and having an architecture that lets you treat the content likes it’s the content and then lets you create different designs or layouts or patterns on the front-end is actually a much more effective way to think about it. So when you add that in, you need to ensure that you have that information about the content structure that informs how those design patterns work so that as you are creating designs for whatever application or channel or client you need to create them for, you know what the pieces are that you’re working with.

Ethan:

That’s great. While you were talking, it was making me think of a parallel conversation that I think is happening in front-end design and pattern circles right now, which is around integrating pattern libraries into existing applications or products. Because so many style guides and pattern libraries are effectively standalone documents, so it’s a little mini website that sits off on the side, that maybe it references the website’s style sheet but otherwise it’s another silo that needs to be kept up to date as your design language changes, as your website changes, this is another document that needs to be cared for and curated. Some people are tackling that problem right now, like I know Clearleft has this sort of miniature CMS that they’ve built for pattern libraries that they call Fractal. The thing I like about that and tools like it is that it’s trying to engender a kind of design pattern first workflow so that you can create a pattern, you register it in Fractal for example, and then any applications, any digital products, any websites that need to actually consume that pattern can syndicate it through an API and pull it into the website to ensure that they’re up to date. Lonely Planet’s another organization that I know that’s tackling that problem as well. It’s interesting to see these two things happening in parallel. Obviously on the content side this has been happening for a much, much longer time, but I wonder if there’s going to be opportunity for these things to kind of dovetail in the next twelve months.

Karen:

It’s certainly a classic problem in style guides. You see this happen with content all the time. People say, “Oh, we’re inconsistent, we need to set some standards, so we’re going to put together a company-wide enterprise style guide that’s going to discuss preferred terms, tone of voice, and how to say things.” And it gets produced as, what, a PDF? Or maybe if you’re lucky it gets produced as a document that can live on the internet somewhere, a little website. But to use that effectively then requires that the writers or the people creating content know to go over there and find the preferred terms or look up whether they’re saying something correctly. It’s challenging to do that in an environment where people might only need to use that document four times a year. So, the idea that you need to find better ways to get that information where people need it. So, it could be that that information gets integrated into the CMS itself. It could be that the tools themselves help guide people to write better or use preferred terms, or not use terms that are considered inappropriate. I think that everybody’s got to be thinking about what we could do to build these tools and these workflows more effectively so that we’re not just relying on someone remembering to go look up a PDF or remembering to go find that website that’s somewhere on the internet.

Ethan:

Yeah, exactly. How can we bring these tools a little bit more closely to the day-to-day workflow? I think that makes a lot of sense. Well, I’m excited to see where this conversation goes in the next couple months. It’s definitely been front of mind in most of our workshops in the last few months especially, so we’ll see what happens in the next couple.

Karen:

I agree, I bet this is a theme that we will cover again in 2017.

Ethan:

[laughs] Most likely. The other thing we should probably plug is, if anyone’s actually been checking out our website recently and reading the transcripts for example, you might have noticed that we’ve been a little bit more visible with plugging our books in most of our transcripts. The reason we’re doing that is because you can actually buy all four of our books in one responsive web design starter kit directly from our publisher, A Book Apart.

Karen:

So exciting.

Ethan:

It’s so exciting. They look so good together. So yeah, that’s a fun bundle. You get like fifteen percent off all four if you buy them all at once. Yeah, if you’ve read them, we’d love to hear what you think.

Karen:

Well, I think that does it for me. Anything else you’re excited about or want to get off your chest before we send everybody off into 2017?

Ethan:

I think that’s about it. As always, it is an incredible honor doing this podcast with you, Karen, and we just need to say thanks to the other folks that make this happen: our advertiser, GatherContent has been a wonderful supporter over the last few months; we couldn’t do this without Selina, your assistant, who schedules every episode and gets everything lined up so we can actually record these; to Aaron and Seth who produce every single one of these episodes—it’s a real joy working with you.

Karen:

And it is a real joy working with you as well, Ethan. These calls are always the highlight of my week.

Ethan:

[laughs] It can only go downhill from here.

Karen:

[laughs]

Ethan:

And to everyone who’s in the audience today, thank you so much for listening, for writing in with questions, for tweeting at us, for sharing these episodes with others. If you like what you listen to or you enjoy these transcripts, we would love it if you’d rate us on iTunes or maybe just tell other friends about the podcast. We’d love to have more folks listening.

Karen:

Well thanks for everything, and thanks for listening. We’ll see you next week!

Ethan:

See you next week.