Episode Transcript

Ethan:

Hey, this is a responsive web design podcast, where we interview the people who make responsive designs happen. I’m your host, Ethan Marcotte.

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week, we are incredibly excited to announce that we’re going to be speaking with… Oh, hang on.

Karen:

Ethan, was it your turn to book the guest?

Ethan:

Uh, Karen, I think if you direct your attention to the whiteboard in our shared podcasting offices—that I just made up… No, it looks like this is just sort of an end of the year holiday wrap-up, so it’s just going to be you and me speaking for about thirty minutes or so.

Karen:

Let’s talk to each other. That’s my favorite part of the podcast!

Ethan:

That’s new and terrifying territory. We’re going to have an actual conversation? This is weird. So, how do you want to get this thing started?

Karen:

Well first, I’d like to thank our sponsor, Champagne Monitor.

Ethan:

Uh… Karen, it’s Campaign Monitor. You know, like with a “k” sound?

Karen:

Oh… Well, that’s an easy mistake to make. I think a lot of people that mistake.

Ethan:

Yeah, yeah.

Karen:

I would love to say thanks to Campaign Monitor. I know that the ad sponsorship placement is everybody’s least favorite part of the podcast, but I just wanted to say thank you to them because they’re really what makes it possible for us to have the transcriptions done. It’s what makes it possible to have Aaron Schroeder, who is our fantastic podcast editor, clean up the audio for the podcast.

Ethan, I hate to break it to you, but this podcast operation is not exactly a big money-maker.

Ethan:

My landlord is incredibly excited about that, by the way.

Karen:

But Campaign Monitor is what really makes it possible for us to have whatever production values we have for this thing. They’ve been fantastic to work with, they’re just really great people. I just wanted to say thank you to them because working with them has been a real pleasure and we look forward to working with them again in 2015.

Ethan:

Yeah, absolutely. Thanks so much to Campaign Monitor. And seriously, if you guys want to check out campaignmonitor.com, it’s a wonderful service run by some wonderful people. Thanks so much guys.

So Karen, since it’s just you and me for the next half hour or so, maybe we could just trade off a couple of questions to sort of see what’s new and exciting in responsive design.

Karen:

Yeah, what’s on your mind as we wrap up this year of talking about responsive design?

Ethan:

Well, with a lot of our interviews, I like how we’re sort of setting the stage for how people have gotten these major responsive projects off the ground, so maybe I’ll put this question to you first: what have you learned specifically about how these organizations are making the decision to go responsive? What’s appealing to them about that strategy?

Karen:

I think one of the things that I’ve been really struck by is how many organizations come back and say “Responsive design was absolutely a no-brainer for us. It wasn’t even a question.” I think that reflects an understanding from a wide variety of different types of organizations that they simply cannot manage and maintain multiple web properties. That they will get the most value, the biggest bang for their buck, in thinking through and making decisions framed by a responsive design. That’s not to say that organizations don’t also have other components of their digital strategy.

The web is sort of like the baseline foundation, and then they can look for opportunities to enhance the experience when it makes sense.

I think the other thing I’ve been struck by is how many organizations can frame what they do on the web and what they do with responsive design working in concert with other strategies that they might have—like why they have an app or how they are publishing to other platforms. It’s not that responsive design is in competition with their app strategy, or any other strategy that they might have. I have really observed that for most organizations, in adapting to the massive changes in the landscape that mobile has brought, that we need every tool in our arsenal, we’re going to have to attack this problem on a variety of different fronts. It’s great to see that responsive design is such a core component of people saying “We need to do this. This is what’s going to keep us sane.”

Ethan:

I totally agree with that. I think it’s been nice to hear that these organizations don’t really see web versus native—it’s not a binary proposition, right? Talking with folks in the travel industry, for example—Marriott, Celebrity Cruises—they’ve got these native touch points, everything to in-lobby kiosks to TV experiences in their rooms. Those supplement what I think they’re seeing as the common through-line for all of those UX contexts, which is basically like the web is sort of like the baseline foundation, and then they can look for opportunities to enhance the experience when it makes sense. It’s been nice to see that responsive design is kind of like a really great way of allowing them to broadcast this as broadly as possible, and then they can sort of supplement it as need be.

Most of their mobile users are multi-platform users, they’re not mobile-only users, and they’re looking for opportunities to interact with their sites and services on pretty much any device that they happen to have close at hand.

Karen:

That leads to sort of a related question that I think both you and I are kind of fascinated by the answers to: how do people see the difference between a mobile user and a desktop user? How do people talk about those needs, and are they different?

Ethan:

It’s really kind of a moot point, I think, broadly. A lot of the organizations we’ve interviewed on the podcast, they’re basically realizing that the distinction is not a very helpful one, really broadly speaking again. The folks at Capital One, they had that separate M-dot experience, but it was actually actively harmful to their mobile audience. They had something like ninety-five or ninety-six percent of their mobile users who were actively leaving the website because they couldn’t actually complete the transactions or find the information that they actually wanted from the experience. Then when they adopted that more device-agnostic approach, mobile consumption just sort of shot up five hundred percent or something like that.

So, I think moving away from this assumption by default, that device class somehow dictates the user’s needs and context is actually kind of beneficial. There was that great line in the Fidelity interview, I think it was Brian who said that most of their mobile users are multi-platform users, they’re not mobile-only users, and they’re looking for opportunities to interact with their sites and services on pretty much any device that they happen to have close at hand.

Most activities are universal, there aren’t mobile-specific tasks or tablet-specific tasks. Well, there might be around the edges, but if you just sort of assume that by default all users, regardless of device or browser type, they effectively want to do the same things.

Karen:

I had a great conversation with Stephen Turbek, I saw him in December, and he said that one of the things that they’re starting to observe is that basically, consistently, users of whatever native platforms they have are also users of the web. They are observing a fascinating trend toward—for example, somebody on their iPad will have both their native app and mobile Safari open, and they will be conducting different tasks on the Fidelity experience using the app or using the website based on whichever one they think is easier to do on that platform, is what they’re imagining. But they said there really isn’t any significant difference across platforms.

Ethan:

I love that, that’s really great. I like hearing about those emergent behaviors that pop up. Livia Labate at Marriott, she was basically saying that, for them organizationally, it was really critical for them to acknowledge across Marriott that most activities are universal, there aren’t mobile-specific tasks or tablet-specific tasks. Well, there might be around the edges, but if you just sort of assume that by default all users, regardless of device or browser type, they effectively want to do the same things. That kind of frees you to sort of look for those interesting opportunities where you might want to enhance the experience with maybe a more refined experience in a native application or a separate device-specific workflow.

All of the arguments for mobile versus desktop being different are entirely organizational change problems. They are organizations that want mobile and desktop to be different so each team can have their own little patch of turf to play on.

I think that’s been really exciting to me, to see that we’re kind of getting past this debate about “small screen means less information.” It’s not about that; it’s really about “let’s design something smartly for the web and then use our resources more interestingly from there.”

Karen:

I would venture to say that I have not seen an organization come back with really credible arguments that mobile users genuinely need something different. I haven’t seen anybody come back and say “Oh, we have actual data that proves that we need to serve up completely different information or completely different features in a completely different way.” What I would argue is that all of the arguments for mobile versus desktop being different are entirely organizational change problems. They are organizations that have org structures or incentive structures or team structures that want mobile and desktop to be different so each team can have their own little patch of turf to play on. I think that is enormously inefficient, I think it gets less value for the organization, and I think it’s a worse experience for users.

Ethan:

I would totally agree with that. The BBC’s been writing about this for a long time because it basically solved what they called a traffic problem internally. They had separate mobile and web digital teams, and then native-specific teams for mobile. They basically had to linear-ize their deployments across all of them, they couldn’t dedicate people to working on one unified platform. Gathering around the table of responsive design helped them solve that issue. It wasn’t about when they were going to be scheduling rollouts for these separate products, it was really kind of focusing everyone around this one shared publishing platform, which I thought was interesting.

Karen:

I’ll give a little tout for the NPR interview that we’ve already recorded but won’t go live until next year sometime. They’ve also talked about their inability to maintain a variety of different device-specific platforms, and how they’ve implemented responsive design out of sheer necessity, because it simply wasn’t maintainable.

If I were thinking long term, I genuinely believe that responsive design is just going to be web design, that it’s not going to be this sense that there’s this either/or choice of you do it responsively or you do it the normal way, the fixed width way.

Ethan:

While we’re talking about what’s maintainable and what’s not, what have you learned specifically about how companies are scoping responsive design and how they’re thinking of rolling it out to their audiences?

Karen:

I think the scope question is one that I would love more organizations to talk more frankly about, in that there is a perception that responsive design is more difficult and more costly to implement compared with separate experiences. I have set up a Google alert for “responsive design” and for “responsive web design”—which I can’t say I recommend doing that—but it does give me a fair amount of perspective on what people are writing. Everybody’s argument about responsive design is that it costs more to build. And I don’t know that that’s true exactly. It may be true in the sense that no one has a lot of experience doing it and that it takes longer to make bigger picture decisions about cleaning up the content, about evaluating the content management system. There’s a lot that goes into implementing responsive design well.

But if I were thinking long term, like two to three years out, I genuinely believe that responsive design is just going to be web design, that it’s not going to be this sense that there’s this either/or choice of you do it responsively or you do it the normal way, the fixed width way. It’s not going to cost more because that’s just how it is.

But I don’t I think I could give a rule-of-thumb metric right now of “You should budget twenty-five percent more time and fifty percent more budget for your first big responsive rollout compared to your other previous projects.” I’m not sure what that is.

I honestly believe that most of these problems are not design and development problems, they are organizational and operational problems.

Ethan:

Yeah, I don’t know either. It was interesting, after I first published the article there was a whole bunch of technical criticism, some design criticism, but also, from a product management perspective, there was a lot of talk about how “Well, this is going to be 300 percent more expensive, in general, because we’re not talking about a single desktop website anymore, we’re talking about a mobile website, and a tablet website, and a desktop website, so obviously it’s three times as expensive.” Just in my practice, that’s been nowhere near the case. It’s been closer, I think, to that “twenty-five to thirty percent more expensive” number that you sort of floated. But, again, I think that’s not a problem with technique, that’s just really a process-related issue about how we talk about managing a multi-device experience in general and how we start thinking about the design process. I totally agree, I think we’re still trying to get the vocabulary to talk about this and I would love to see more organizations doing that.

Karen:

I honestly believe that most of these problems are not design and development problems, they are organizational and operational problems. What does it take to roll something like this out across the organization? How do organizations frame the problem to say, for example, “We’re going to do a responsive retrofit, where we’re going to basically take everything that we have on the old site, shovel it into shiny new responsive clothes and then sort out the problems later.” That’s one of those options that, to me, on the face of it, doesn’t sound that great. But I think we’ve seen plenty of organizations—Marriott, Capital One—come back and say “Well, we did that and we did it successfully. It may not have been perfect but it bought us the organizational buy-in to then go on and make the changes that we needed to make to the content or the CMS, and we couldn’t do everything all at once.”

What are the process issues internally? How do we need to think about the ways in which our design and development teams collaborate? What are the content issues we’re uncovering if we do a responsive retrofit? What are the things we want to refine as we iterate on this experience?

Ethan:

I agree with that. I think the thing that has been interesting generally is this old idea of the redesign, like there’s this curtain unveiling and lots of great fanfare, and “Here’s our new website!” That seems, generally speaking, like a lot of organizations are moving away from that.

I can’t remember if it’s Dan Mall or Brad Frost who talks about “planting the seed of responsive design.” Whether it’s doing a responsive retrofit, or if you’re Microsoft, who we’re going to be interviewing here shortly, doing a responsive homepage, or the BBC or the Guardian, and they’ve got a separate mobile site that’s completely responsive but it’s only served up to a section of their audience—it’s really about being a little bit more targeted, maybe a little quarantine of the responsive experience in a more limited way to get some data on that. But also to just see, not just how it’s performing for your audience, but also to see “What are the process issues internally? How do we need to think about the ways in which our design and development teams collaborate? What are the content issues we’re uncovering if we do a responsive retrofit? What are the things we want to refine as we iterate on this experience?”

Whether you’re doing one page or the entire website, how are you going to demonstrate to the organization that it was successful? What that’s going to be will be different for every company because every company is different.

Karen:

I’m really struck that there are easily a half dozen different ways to approach rolling it out, and there really isn’t one right way to do it. I wish I could come back and be like “Here, you pick this section and you start with it.” But every organization is different. The real challenge is figuring out your organizational decision-making processes and what you are going to get out of that responsive redesign. Whether you’re doing one page or the entire website, how are you going to demonstrate to the organization that it was successful? What that’s going to be will be different for every company because every company is different.

So, there’s a lot of changes that come from implementing a responsive design and I think one of the most interesting ones to me is how the design process changes. People work together differently, they’re even using different tools. So, what have you learned this year about how responsive design changes more than just the design of the website, how it changes the way you work?

We’re seeing a lot of organizations that really the understand that the value of flat, non-interactive comps is less important than it used to be, and prototypes are much more valuable design tools.

Ethan:

The thing I’ve learned—both in doing the podcast but also in my own practices—a lot of the tools we’re using haven’t really changed all that much. We’ve been speaking to organizations that still favor the Adobe suite; Photoshop and Illustrator are pretty dominant, big surprise there. There were some new names that sort of popped up: After Effects, if we’re talking about some interesting prototyping behaviors; Sketch is kind of an up-and-comer.

But beyond the applications themselves, I think we’re seeing a lot of organizations that really the understand that the value of flat, non-interactive comps is less important than it used to be, and prototypes are much more valuable design tools. It’s so much more valuable to get a living design in a browser and hand it to a stakeholder, on any class of device—mobile, desktop, whatever—and let them actually start interacting with it. Even if it’s not completely refined, talking about content hierarchy, how the design is actually working on different breakpoints—that’s so much more valuable than actually just projecting flat designs up on a wall and talking about aesthetics and layouts only.

Privileging in-device experiences I think is incredibly powerful.

I was kind of struck by the Virgin America interview that we did a couple of months ago, they were working under some fairly aggressive timelines. But basically the client—we had their design partner on the podcast, and their client, Virgin America, never actually saw comps; the very first meeting with them was a prototype. So, they could start talking about the look-and-feel but also start talking about some of the workflows that they needed to support and how those actually performed across different device classes. So, privileging in-device experiences I think is incredibly powerful.

We’ve all been saying “We would make better products if we worked more iteratively.” One of the things that I like seeing is that responsive design really makes that happen.

Karen:

I’ve been really interested in how that shift to prototyping actually changes the way the organization is structured, it changes the type of people that the company might need to recruit or hire. It’s like the people who can prototype now have more power and the people whose skills are really still focused on building flat comps, they either need to partner differently with other people in the organization or… So, I have heard so many companies come back and say “We either need to move the developers so they sit within UX or we need to move UX so it sits within development, but we cannot treat those as two completely different groups anymore.” It means that you have to staff projects differently, you have to ensure that those people can collaborate more tightly.

There’s a lot of, let’s stop working in a waterfall fashion, let’s work in a more lean, iterative—I don’t want to call it agile—but it’s less about having these distinct phases of “Here’s design” and “Here’s development” and more about treating them like they’re much tighter circles. I think those are things that a lot of people in the design and development community have wanted for years. We’ve all been saying “We would make better products if we worked more iteratively.” One of the things that I like seeing is that responsive design really makes that happen, or it makes the “light bulb moment” happen, where the organization goes “Oh, okay, we really do have to do this now.”

They start digging into the problem and then they realize that the responsive magic wand that just makes the front-end of the website squishy doesn’t actually solve their problem.

Ethan:

Right, I totally agree. Moving from design and development, what kind of changes have you seen on either the CMS or the editorial fronts? Have you seen similar changes there?

Karen:

What I find, talking to companies, is that it’s like with responsive design, you really have three problems.

Ethan:

Just three? That’s comforting.

Karen:

It’s easy to say “We need a mobile website, or we need a website that works across all these different devices. Okay, let’s go responsive. Hurray!” Then they start digging into the problem and then they realize that the responsive magic wand that just makes the front-end of the website squishy doesn’t actually solve their problem. That they really need to go in there and clean up their content; they need to fix pages that are too long that don’t get to the point; they’ve got five levels of nav and they’ve got to get that down to something more manageable. Then they look under the hood and realize that a lot of the changes that they need to see happen actually start in the content management system.

I would love it if organizations could fix their content, edit their content, fix their CMS, re-platform their CMS, and implement a responsive design all at once. But the truth is that’s not going to happen.

So, one of the things that I’m struck by is how many organizations talk about needing a modular framework for the design system. Whether that’s Virgin America describing the lego pieces that they built or Capital One talking about their component-based content management system, I really believe that the organizations that have modularized and componentized, not just on the front-end but in the CMS as well, are the ones that can implement a responsive design more quickly and more easily. That’s not to say that organizations that just treat it as a front-end retrofit or migration can’t do it—it’s totally possible.

It’s like as soon as you scratch the surface, you’re like, oh, right, we need a different format in our CMS underneath the hood to make this happen in a really scalable, modular way. I would love it if organizations could fix their content, edit their content, fix their CMS, re-platform their CMS, and implement a responsive design all at once. But the truth is that’s not going to happen. I think it’s like, pick one of those things, maybe two of those things if you’re lucky, and roll out the rest of them over time.

Ethan:

I like that. And I think I’ve found, at least on the design side, is the more modular approach on the content end gives you so much more flexibility in thinking about some design solutions. The Guardian is a perfect example of this. They have all of these wonderful patterns about revealing content as screens get wider, bringing in extra supplementary pieces of information at certain points in the responsive design, and that’s all informed by less “blobular” content in the database. So, I think that it’s been interesting to see how that kind of flexibility on the CMS side can really support a pretty nimble responsive design system.

Karen:

Speaking of nimble…

Ethan:

Did you like that? That was a nice little segue.

Karen:

A nice handoff there. I heard a rumor that responsive design is bad for performance.

Ethan:

Huh, okay.

Karen:

That you ruined the internet by making all of our pages super-heavy and slow, and there’s no way to fix that. Is that true?

Ethan:

Yeah, it’s totally true. Next question.

Performance is really not just a technical issue, it has to be an organizational-wide priority. It’s everyone’s responsibility.

No, it’s been interesting because I think in the last couple of years responsive design has gotten a bit of a bad rap for it being just heavy, it’s slow. If you’re going responsive, your site is going to be twelve times heavier and mobile users are going to be incredibly upset. And that’s just not the case. I think that everyone from The Guardian, to the BBC, to the British government, to you name it, they’ve shown that you can have beautiful responsive sites that are incredibly lightweight.

But I think it’s come around by the organization sort of admitting that performance is a feature that they need to incorporate and plan for, it’s a design consideration. What’s more, performance is really not just a technical issue, it has to be an organizational-wide priority. It’s everyone’s responsibility.

By doing more prototyping at the beginning of a project, that helps people across the product team just understand that every decision they make, whether it’s visual, technical, or content related, impacts the user experience.

Karen:

I’m fond of saying it’s a content strategy problem. I think there’s heroic developers doing everything they can to squeeze every last K of code out of these websites, and the truth is, get rid of some of the crap on those pages that nobody wants.

Ethan:

Yeah, exactly. I mean, if a design comes to a developer and it’s got a carousel right at the top of the page that’s going to have 58 high-res graphics right at the top—because everyone loves a carousel—there’s really only so much that can be done to make that experience as lightweight as possible.

By doing more prototyping at the beginning of a project, before the design is even finished, to get people talking about planning for and building a performance budget—again, before design even begins—that helps people across the product team just understand that every decision they make, whether it’s visual, technical, or content related, impacts the user experience.

Responsive design isn’t bad for performance. With proper planning and strategy, you can build these incredibly wonderful, nimble, lightweight things.

The great thing about all of these mobile devices is that they’ve driven people to expect more from websites. They expect websites to load faster on these smaller screens than they do on the desktop. So, seeing folks like Virgin America actually kind of acknowledge this and actually use performance to inform design. They basically have this beautiful responsive site that is kind of clutter-free. It’s incredibly powerful and it’s very content-rich, but it’s kind of low-density by default, and that was a performance decision for them. They basically decided that the less stuff that they pushed into the browser, the faster the page would load and the better it would perform. Same thing for The Guardian, same for the BBC.

Basically, if you can sort of design for that low-bandwidth experience, like plan for the 3G user who’s on a spotty connection on a small screen, that makes your design resilient, and it’s going to perform better for your audiences. Then you can staff for that internally. Vox actually identified a performance lead, identified a front-end engineer to make sure that the products they were shipping were going to be as lightweight and as nimble as possible.

Responsive design isn’t bad for performance. With proper planning and strategy, you can build these incredibly wonderful, nimble, lightweight things.

Karen:

I saw a study come out yesterday that, true to form, tried to make the case that responsive design was bad for performance. But the fastest news sites that they cited, The Guardian and Time, are both responsive sites, and the site with the absolute worst performance was Sports Illustrated, which just relaunched with a shiny new fixed-width design.

Ethan:

That’s fantastic. Yeah, the web has a weight problem in general, this isn’t about responsive design specifically. You could look at any number of fixed-width sites on the internet and they’re going to be heavier than they probably need to be.

Karen:

I think it’s great that everybody is talking about performance. I think you did a good thing here, Ethan, by getting the whole internet to be worried about this.

Ethan:

Everyone loves a soapbox. Yeah, no, I’m glad it is too because ultimately I think our users are going to thank us for it.

As we’re talking about shipping some of these products, how do organizations start thinking about the review and approval process internally? How do they actually start circulating and thinking about sharing these responsive designs internally?

That just changes the way that people talk to each other, it changes the way they give feedback. They’re not marking up a PDF with comments anymore. They have to have new tools and new ways to communicate.

Karen:

I’m so fascinated by how the design process changes that you described earlier—how that affects the way that the rest of the organization works. For example, how do you go to your stakeholders and communicate what things look like, where their “thing” is going to live across all of these different device types and breakpoints. I think it’s very common for stakeholders to come into meetings and say “Okay, well, what’s our smartphone website?” or “What does our tablet site look like?” Getting them to understand that this is truly flexible, fluid—that their “thing” doesn’t get to “live” in one place anymore—I think that takes some work. You have to really socialize that concept.

One of the things that I’ve heard everybody say is, that in the same way that you’re moving away from building fixed comps and doing prototypes, you also have to move away from the big meeting where you’re projecting something up on the wall, and toward showing all of those prototypes actually on the device. To get people excited about what this is going to look like, you have to show it to them on a smartphone or on an iPad and let them play with it. So that means you have to have those devices available. You might want to make that prototype available inside your network to anybody who wants to go look at it. That just changes the way that people talk to each other, it changes the way they give feedback. They’re not marking up a PDF with comments anymore. They have to have new tools and new ways to communicate “Oh, wait, at this breakpoint this thing should be higher on the page.”

In the same way that people who work in web design and development might want a more collaborative working environment between designers and developers, what I see is that we just need a more collaborative working environment across the entire company.

One of the things I love to talk about is how the legal review process changes. So, some organizations don’t have this problem at all; it’s basically like either you don’t have this problem or it is your biggest problem. For financial sites in particular, there’s very specific rules around things that have to appear on the screen at the same time; how large things have to be; how far away they can be from each other; and all of those rules were designed for a desktop world—or frankly, all of those rules were designed for a print world—and we’ve just been kind of band-aiding along, trying to make them work on different screen sizes.

Talking to organizations, they say that they have gotten their legal teams involved much sooner. You get them involved really early in the process so that they’re part of coming up with the solution as opposed to being the ones who come in at the last minute and say “no.” That’s a big change for how some organizations work. I think that in the same way that people who work in web design and development might want a more collaborative working environment between designers and developers, what I see is that we just need a more collaborative working environment across the entire company. People have to be brought into the process earlier rather than waiting until the last minute and having them say ”Oh, I hate this.”

Ethan:

I had to mute my microphone for a second because I was just pounding the table in agreement. So, yeah, well said Karen.

Karen:

So Ethan, what happens in 2015? What’s next for you? What’s next for responsive design?

Ethan:

I don’t know what’s next for responsive design in general. Broadly speaking, like I said before, people are talking about performance.There are some great books out there right now for building faster, more flexible websites that I’ve been really enjoying. I’ve got Scott Jehl’s book and Laura Hogan’s book on designing for performance right next to me, so I’m excited to crack into those.

Speaking more personally, I’m really excited about next year because you and I are going to be doing some public workshops.

Karen:

We are. We’re going to be doing them for sure in New York and Boston, which we’ve picked because they’re convenient.

Ethan:

Yeah, I hear good things about them in general, so.

Karen:

We are working with Erik Westra from Westra & Co. He’s going to help produce and organize those events. Super excited to be working with him.

Ethan:

Definitely. So, we’ve been doing these in-house corporate workshops about responsive design for the better part of this year. Those have been going great, and I’m just kind of excited to open them up to the public.

Karen:

Yeah, we’ve had the chance to work with companies like Expedia, and CIBC, and the Associated Press, and spend a couple of days talking to their staff about how they’re implementing responsive design. I have to say, I love doing those workshops with you, and I also feel like I learn so much every time I go and talk to these companies. I’m excited to be able to launch this workshop series to the public. I’ve heard from a lot of people that they’d love to take one of these workshops, but we haven’t offered them publicly. So now we’re going to.

Ethan:

Yeah, I can’t wait for this. It’s going to be a lot of fun. The other thing I’m really excited about is I’ve started work on a new book.

Karen:

Yay!

Ethan:

Yeah, I can’t wait. I just came out with a second edition of Responsive Web Design, so that felt good.

Karen:

Which people should buy. Go buy that book right now.

Ethan:

If you guys can’t see, I’m actually sliding five dollars across the table to Karen right now, so thanks for that Karen. But yeah, I don’t know, I guess because I’m a glutton for punishment, I figured I would start work on another one.

Because over the last couple of years I think most of the questions that I get—outside of the organizational ones—are really about how to handle specific design challenges, like “How do you manage that five-levels-deep navigation system that everyone is really in love with on the desktop site?” So, taking a look at some of those specific design challenges and trying to identify specific patterns for them is something I’m just generally interested in, but also taking it up a level and also talking about a vocabulary that we can use for talking about how different parts of our responsive designs need to adapt.

Karen:

I’m so excited that you’re doing that. I think that is so greatly needed in this industry, and I can’t obviously think of anyone better to write about that particular topic.

Ethan:

You’re damn kind. I’m very excited about it. What about you, Karen? What’s next for you in 2015?

Karen:

I also have some exciting news.

Ethan:

Really?

Karen:

I, too, am working on another book.

Ethan:

Wow. Tell me more about this.

Karen:

Glutton for punishment. So, this next book is going to be called Going Responsive, and I’m going to talk about the organizational and operational challenges that companies face in implementing a large scale, or medium scale, or even small scale responsive design. There’s not going to be one line of code in the book, I’m not going to be talking at all about specific design or development challenges. I’m going to be talking about all of the other problems that companies will discover they have and then need to solve if they want to do responsive design right.

Ethan:

I am incredibly excited about that, not just because it has a fantastic title, but because I think those are actually some of the biggest challenges out there right now. We’ve got a whole host of resources out there for layout, for interaction problems. But the actual collaborative and process-related stuff, I think we’re realizing that there needs to be a lot more literature out there and I’m so glad you’re going to be doing some of that.

Karen:

I feel like I’ve been so lucky this year to work with you, to talk to the companies that we’ve done workshops with, to talk to all these companies on the podcast, about where they’ve been successful and where their challenges have come up. I know I feel confident that in the years to come, ever more organizations are going to be out there implementing responsive designs, and I am delighted to be able to help them a little bit with that process.

Ethan:

Yeah, and me too. On a more personal note, I just want to thank everyone who’s been listening to the podcast over the last couple of months. This has, as Karen said, been an incredible amount of fun to work on and it’s been really nice to hear things on Twitter about people that have actually learned a few things from it, because I’ve been learning a lot as well. So, thanks to everyone who’s been listening.

Karen:

Yeah, I’ve got to say, I love doing this podcast. I hope you guys can tell how much Ethan and I enjoy talking to these companies, I hope that you enjoy listening to it, and it’s been a great year. I’m looking forward to the next one. Let me also say another word of thanks to our sponsor, Campaign Monitor.

Ethan:

Nailed it.

Karen:

All right, are we done?

Ethan:

Oh, yeah, sure. That sounds good. Let’s close it out. I think we need to leave this particular part in there.

Karen:

We’re very professional podcasters.

Ethan:

We’re the professionalest of podcasters, yeah.

Karen:

All right, looking forward to 2015 everybody. Thank you.

Ethan:

Thank you.