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:

And this week, well, we have the special-est of most very special episodes for you. Ethan and I are delighted to tell you that we’ve been doing this podcast for a year and we’re going to spend this one just talking to each other about what we think is going on in the world of responsive design. So, welcome, Ethan.

Ethan:

Why, thank you, Karen. And welcome to you, as well.

Karen:

Well, I can’t believe that this is our fifty-second episode of this podcast series.

Ethan:

I know, 365 days… I just… Yeah. I remember when this podcast was just a sparkle in your eye.

Karen:

I remember when I was nervous about recording on the internet. But I got over that.

Ethan:

[laugh] Yep, yep, Skype will just do that to you; drums the fear right out of you. Yeah, so tell me a little bit about where your head’s at these days. What’s new and exciting in your world/responsive design?

Karen:

Well, I think the first thing that I’d like to say is exciting is that Harvest is going to be sponsoring this podcast. Harvest is the best time-tracking system that I have used. I will say in all sincerity, back in my Razorfish days, I think I must have used every time-tracking system on the planet and each one of them was a bigger flaming pile of garbage than the last. It was genuinely spectacular how terrible these products were. And when Harvest came along, it was like the heavens opened and the angels started to sing because finally somebody figured out “How do you design a time-tracking system that actually works for people?”

I want to say they are sponsoring the podcast. I know you guys think I’m contractually obligated to say that this is an amazing product. But this is with all sincerity: I really believe that this is the best designed time-tracker out there, and if you need a time-tracking system, you should be using this one.

Ethan:

Yeah, I’ve got to say, it was amazing when they kind of dropped us a line a couple of weeks ago, because frankly I use Harvest daily in my practice, so it was kind of amazing to have the opportunity to talk about something that I genuinely enjoy using on a daily basis.

Karen:

You genuinely track your time on a daily basis?

Ethan:

I send invoices with some regularity. I don’t know about stopping and starting my timers and such. But yeah, it’s a wonderful piece of software; it’s great for expenses and accounting purposes. It’s been huge for me.

Karen:

Yeah, I think it is a really well-designed piece of software. I also think they are a lovely company and I’m thrilled that they’re going to be sponsoring the podcast, because much like Campaign Monitor was, they were a product that I felt I could enthusiastically endorse.

Ethan:

Right, exactly. So with that out of the way, what else is going on with your world, Karen?

Karen:

Well Ethan, as you may know from my literally dozens of Slack messages to you, I have been working on the editing process for my latest book, which is called, Going Responsive.

Ethan:

I love that title.

Karen:

It’s a good title, right? I think it’s a good title.

We need a way to convince the rest of the organization that this isn’t about just taking the website and beating it with a media query stick.

Ethan:

Super-good title.

Karen:

And so this book is not really about the responsive design and development process. It’s about all of the other broader process/organizational/operational changes that companies need to make as they’re implementing a responsive design. I think that you and I have probably both heard from a lot of the companies that we’ve done workshops with, that the specific design and development issues of the fluid grids and the media queries—they can wrap their heads around that. Or the design and development team often comes to us and says, “Yeah, yeah, yeah, we get how this works and we want to do it, but we need a way to convince the rest of the organization that this isn’t about just taking the website and beating it with a media query stick, it’s about how do we all work together differently and how do we make decisions differently.”

This book, my intention with it is that everyone would say, “Oh, I need to buy ten, fifty, a hundred copies of this book for my team.”

And so this book, my intention with it is that everyone would say, “Oh, I need to buy ten, fifty, a hundred copies of this book for my team.” That’s how I would like to approach it.

Ethan:

[laughs] I want that for you as well. But you gave us the pitch when we did our “Christmas episode” a few months ago. Can you tell me a little bit more, like how it’s structured? How did you set this up so you’re going to start answering some of these questions?

It’s important that people have a shared understanding of why responsive is the right solution and also to have a shared vocabulary around some of the other techniques or other options out there.

Karen:

So, I start out by making the case for responsive. I think a lot of companies that we talk to say that the decision to go responsive was basically a no-brainer. But even organizations that are convinced that they want to go responsive still need to understand what are some of the alternatives, like why is responsive the right approach, and what are other alternatives out there, like an m-dot website or adaptive solutions. I think it’s important that people have a shared understanding of why responsive is the right solution and also to have a shared vocabulary around some of the other techniques or other options out there. I mean, I would say I’ve never met a company that has decided to go responsive that doesn’t almost immediately start debating adaptive solutions and when they’re required. Or also, what’s the role of a responsive website vs. having a native app, and how do those things work together? So I think having that as some grounding really helps.

Then I move into talking about the planning process. So, how do you scope, how do you orient people, like what do you have to do to get the project set up right? And I think, to me, one of the more interesting parts of that section is how do people plan a rollout process. So, there’s lots of different ways to stagger the approach to your redesign, and for many large-scale organizations they can’t do it all at once. So, how do they plan that so that they get the most value from their rollout? Then I talk about performance.

Ethan:

Really?

Karen:

Yes, I do. I know, I may be the only one talking about it… Well, that’s not true.

Ethan:

[laughs]

If there’s one benefit to a responsive process, it may be getting the organization all focused on the costs of different choices that they make, like the costs in terms of page weight and download speed.

Karen:

[laughs] Frankly, when things get to the point where I’m talking about it, where it’s like, “Oh, this is something that previously has been treated as a totally technical problem.” Like, go get your heroic developers to, I don’t know, bundle some files together or something. That’s not something that people—executives, designers, marketers—have to think about. But it is. It’s something that affects everybody on the team, and honestly, I think if there’s one benefit to a responsive process, it may be getting the organization all focused on the costs of different choices that they make, like the costs in terms of page weight and download speed. It’s not that you can’t have things that you want on your website, but you can’t have everything you want. So, how do you make those tradeoffs; how do you get the rest of the organization to recognize that just because it’s digital, it doesn’t mean that you can have everything you want and it’s free.

Ethan:

I love that.

Karen:

Yeah, I think it’s a really, really healthy thing for the web.

Ethan:

Yeah, I totally agree, and the way you’re describing the performance problem, that it’s not just the purview of the development team. I mean, I’ve read a draft of your book, I have to say for our listeners, and that’s what I love about everything that you’ve written so far. Because you’re not just talking about this from a management standpoint. You’re writing a book that I think is going to be accessible to pretty much anybody at any level of an organization.

Karen:

That’s my goal. So then I talk about content, which is another one of those things—I will say, I thought that was going to be the easiest chapter to write and it was actually the hardest chapter because it was like, “I could write a whole book on this subject! Oh right, I did write a whole book on that subject!” So, boiling down some of the most specific goals for content was the next problem I tried to outline for my readers.

Then I talk a little bit about the collaboration process. So, sort of a broad framing of the design and development process as something that is more collaborative, more iterative, based on prototypes, and something that the entire organization has to participate in in different ways.

How do you think about your QA processes, which I’m sad to say turns out to be a huge honkin’ mess and a real pain in the ass.

Then I wrap it up with a discussion of how organizations test and measure the success of their responsive designs. So, what’s different in how we think about the browsers or the devices that you “support,” how do you get your stakeholders to move away from thinking that websites have to look identical in every single browser and instead embrace the sort of flexible, fluid nature of what the web should be. How do you think about your QA processes, which I’m sad to say turns out to be a huge honkin’ mess and a real pain in the ass.

And then how do organizations think about measurement. I think that chapter is interesting just because even if you embrace the notion that responsive design serves all devices equally, when you think about testing and measuring, you really are back to the device level. Organizations really are going to need to test on different devices, obviously. They’re going to measure success on different devices. They probably will still be using words like “mobile,” “tablet,” and “desktop” when they look at their analytics data. And while I wouldn’t encourage anybody to do that as part of their design process, it does sort of make sense when you’re thinking about how you evaluate and measure what people are seeing.

Even the most device-agnostic folks, they’re still looking at their metrics across different device segments.

Ethan:

Yeah, I love that. It’s interesting because I think the measurement question is something that we tend to ask most of our guests on the podcast. And even the most device-agnostic folks, like the BBC interview for example, one of my favorites, they’re trying to be all things to all people no matter the class of device, but at the end of the day, they’re still looking at their metrics across different device segments.

Karen:

So, I think that responsive design is just the right thing to do for the web and my goal is to communicate that to an audience of people who’ve probably heard the term “responsive design” and they know they want to do it, but they don’t understand what it means for them.

Ethan:

Yeah, well I think you’re definitely going to be helping them out a long way to answering that question. It’s a great book, Karen. I can’t wait to see it.

Karen:

I’m excited, too. How about you, Ethan? What have you been up to these days?

Ethan:

Ah, well, I am also in the throes of finishing up a book, as you may well know.

Karen:

No! No!

Ethan:

Yeah, put away your shocked face. [laughs]

Karen:

It is a spectacular book. I will not give away the ending, but I will say I have read a draft and I’m excited.

Ethan:

Oh, thanks Karen. I appreciate that. Thanks for slogging through it. I am really excited about it. I mean, the title is Responsive Design: Patterns and Principles. Very, very, very direct—not a lot of poetry in the title. But, you know, I think it’s something that I’m really excited about. Where the first book, Responsive Web Design, for A Book Apart, that was really talking about page-level layout. Like, “Here’s how you can take flexible grids, fluid images, and media queries and create this sort of squishy layout that just kind of reflows itself and can be more broadly accessible.”

Karen:

I literally have that book open on my desk right now. It is a treasure of a resource. Also, I will say: it is hilarious. Like every time I pick that book up, I’m like “This is so well-written,” and your latest book, also, beautifully written.

I’m really excited about this book. It’s trying to basically move a level below the page.

Ethan:

Thanks, man. Yeah, I’m really excited about this book. It’s trying to basically move a level below the page. So, most of the emails and conversations that I have about design problems over the last couple of years, they’re not really about, “Okay, well here’s how I think about the grid at the top level and sort of reformat it for different devices.” It’s really about, “How do I manage multi-tier navigation systems in a responsive design? I have a photo catalogue from my publisher. How do I actually start thinking about this more responsively?”

Or this whole advertising thing—this is a massive challenge for digital publishers and organizations. “How do you actually start bringing these ad properties into the web?”

So, it’s really looking at individual challenges like that and talking about different ways that sites and organizations have tried to tackle those problems, and then hopefully sort of stitching them all together to look at some broader design principles that you, as a designer, or you and your team can actually sort of use to think more holistically about other challenges you might encounter in a responsive design system.

Karen:

This topic of design patterns is… I mean, your book is perfectly timed because it seems like something that so many of the organizations that we’ve spoken to have said, like, “Oh right, this process of thinking responsively has actually forced us into thinking in a more granular way or thinking about these smaller reusable patterns.” Is that something that you see as well?

This was a way for them to start thinking about building these “networks of content,” into something that’s more responsive, more flexible, and ultimately more nimble.

Ethan:

Yeah, absolutely. It was funny because I was just going over the transcripts of everything we did since our holiday episode and, I mean, we had folks like MTV, like Ushahidi, the City of Surrey, the BBC obviously, and then Shopify—I mean, folks like that, basically saying for them a pattern library, some sort of catalog of all these individual reusable components was a massive design tool. It wasn’t just a deliverable that they just looked back and referenced. This was a way for them to start thinking about building these “networks of content,” as Trent Walton calls them, sort of stitching them together up from those small little LEGO blocks into something that’s more responsive, more flexible, and ultimately more nimble.

Thinking about the design system and the patterns first, it actually gives them a shared language that they can use to inform their future decision-making.

Karen:

I’m really struck by how many smaller organizations have said that they started with a pattern library. I think that sometimes people think like, “Oh, well if I’m Starbucks or the BBC, sure… But what about me, City of Surrey?” But I think even smaller organizations that have a limited budget or a less complex website will say that they benefit from thinking about the design system and the patterns first, that it actually gives them a shared language that they can use to inform their future decision-making. I think that’s very powerful.

It’s a wonderful QA tool. I think the best position an organization could get to is where their pattern library is actually drawing from the same style sheet.

Ethan:

Yeah, I couldn’t agree more. I think that a pattern library just offers an organization so many different benefits. I mean, it’s a wonderful onboarding tool for new members; it’s a great at-a-glance view into the visual language that sort of goes into actually building a website.

Even at the far-end of the spectrum, it’s a wonderful QA tool. I think the best position an organization could get to is where their pattern library is actually drawing from the same style sheet, the same front-end assets that are actually powering their live website. If something manages to make it onto the website that happens to break a large part of your pattern library, that’s a really great way to spot those regressions at a glance.

Moving past specific abstract grids and really focusing on the individual components is more future-friendly in general.

So yeah, it’s been a huge tool for me in my practice, just actually thinking about those individual pieces of your site architecture and then using them to build these more complex responsive layouts out from there rather than the old way of building these abstract grids and filling them with stuff. We’re designing things that are viewed on massive screens, on car dashboards, on watches now. I mean, I think moving past specific abstract grids and really focusing on the individual components is more future-friendly in general.

The thing that’s most interesting to me are the organizations that are implementing their pattern library actually as components in their CMS.

Karen:

I’ve been struck by how many of the conversations about design systems and pattern libraries are constrained to the front-end. So, it’s like, let’s think about these things as a reusable kit of front-end code snippets where we’ve built out some of these most commonly used patterns, and then when our designers need to have a calendar widget or whatever, they can go and grab that code and not have to reinvent the wheel.

The world that I come from, or the kind of space that I play in, there’s a concept called “Component Content Management,” which is essentially when I talk about having more structured content on the back-end, that space is looking at using XML-based tools like DITA to store truly manageable, reusable bits of content. So rather than having all of that stuff attached to one particular page, they’re stored at a much more granular level so that they can be dynamically published to different pages, so that transition costs can be lower because you don’t have to send everything out for translation, you can just manage one little bit of content.

When you wanted to make an update to one of those components, you could just do it in one place and have it roll out dynamically sitewide, think how much easier things would be the manage and maintain.

When I look at the space, the thing that’s most interesting to me are the organizations that are implementing their pattern library actually as components in their CMS and where they have that componentized content, a structured content model on the back-end. Eileen Webb has a quote where she says that “Design Systems and pattern libraries are BFFs, they go hand-in-hand.” I think that’s one of the most powerful things that organizations could be thinking about.

It’s something that isn’t strictly a responsive design challenge. But if you were to think, “Hey, how could I get the most value for my organization long term in the massive web redesign that I’m going to have to undertake to go responsive?” if you came out of it with a well-designed pattern library that was componentized on the back-end so that when you wanted to make an update to one of those components, you could just do it in one place and have it roll out dynamically sitewide, think how much easier things would be the manage and maintain. Think how much simpler it would be to run a website.

Structured content sets you up for so much more flexibility too from a design standpoint, as well.

Ethan:

Yeah, absolutely. We’ve talked about this either offline or in our workshop, but I think the words “structured content” sets you up for so much more flexibility too from a design standpoint, as well. All those examples that we tend to look at from publishers like The Guardian or the BBC, where they can make these decisions across different device classes or different breakpoints, when they can actually pull in supplementary pieces of content into individual modules, when they actually want to make better use of the space that’s available to them as a screen gets wider or smaller… They’re doing that because they’ve actually made some strong editorial decisions about “Here’s how the content model should be laid out for these particular kinds of information,” and I think that stuff ultimately needs to feed into the design system. So moving past the layout in front of you, like you said, sets you up for so much more success.

Talking to clients, it’s like they have Stockholm Syndrome for their desktop website and they’ve started to identify with their captor.

Karen:

Yeah. I think that we’ve talked a lot about conditional loading, and to me that’s one of those techniques that seems so powerful. If you have structured content on the back-end that is stored in a more granular way, then you have more flexibility—even on the front-end, even client-side using responsive techniques to show more or less content at different breakpoints.

I get the sense sometimes, talking to clients, that it’s like they have Stockholm Syndrome for their desktop website and they’ve started to identify with their captor. I can remember having one conversation where somebody was like, “Well, how do we use adaptive techniques so that we can keep the desktop website exactly the way it is and then just serve less content for mobile devices?” And I think they went on to say, “But if we serve the right amount for mobile devices, won’t the desktop look empty?” I’m like, “Okay, of all of the problems you have in life, your desktop website looking too spartan is not one of them. You have endless quantities of dreck that you’ve shoved onto those pages…”

There’s a huge potential to really focus on what the minimum viable content you need to serve for the least-capable devices is and then think about progressively enhancing that.

So while my primary goal, my fundamental ambition in life is to get organizations to clean up all of that dreck, when I think beyond that, when I think, “Oh, what if you really did have a well-structured, well-organized system of content that could be conditionally loaded?” I think there’s a huge potential to really focus on what the minimum viable content you need to serve for the least-capable devices is and then think about progressively enhancing that. Like, how do you layer that up for larger screen sizes that maybe have the capacity to take more? That doesn’t necessarily have to involve the CMS, even. That’s not something where the server has to be like, “Okay, I’m going to do some UA detection and figure out what you want.” You can do that all conditionally.

Asking yourself those hard questions and then building up from that least generous scenario is always going to set you up for success.

Ethan:

Yep, beautifully said. That’s always, for me at least, been the benefit or the appeal of thinking about designing for mobile-first. You’re trying to take a design system or a set of content, view it through the most adverse circumstance as possible, like this incredibly small screen, and then you sort of build up from there. I think that when you’re thinking about conditional loading or whatever interesting design pattern you’re working through, taking it from that small screen, taking it from a spotty network condition or in browsers where they may not necessarily load JavaScript or if they don’t understand touch, asking yourself those hard questions and then building up from that least generous scenario is always going to set you up for success.

There was actually a word in there that I wanted to pick up on, that you said Karen, which was this word “adaptive.”

Karen:

Oh yes, yes, a popular word. Responsive design isn’t good enough, Ethan, and you should use adaptive.

When adaptive comes up in a meeting, it usually means we don’t know what we want and we’re going to pretend that adaptive is some magical solution that will solve all our problems.

Ethan:

I’ve heard a couple definitions of the word. I guess I’d like to hear you break it down for me. What does adaptive mean for you, exactly?

Karen:

One of the problems we have in this space right now is that people use adaptive to mean lots of different things. I actually had someone mention to me, “Yeah, when adaptive comes up in a meeting, it usually means we don’t know what we want and we’re going to pretend that adaptive is some magical solution that will solve all our problems.”

I think of adaptive design as essentially being device-specific design in some sense.

So, I like to break it down into two big buckets: adaptive layouts and adaptive content. When I talk about design solutions, there’s the sense that people still cling to this notion of still having device-specific layouts or designs. They say, “Sure, responsive is great for ninety-five percent of our pages, but what about the homepage? Like, that is a tricky problem, we’re not sure we can solve it responsively.” Or, “What about this super complex transaction flow? We don’t think we can actually handle that entirely on the front-end.”

Or I’ve heard people say, “We want mobile-specific landing pages for campaigns. We genuinely want to serve a different landing page for a campaign to mobile devices.” Or even at a more granular level, like “I’ve got a particular table on a page that I just don’t see how I can handle that responsively. Either the smartphone view or the desktop view is going to be compromised. So, what if I just got a little bit of server involvement and did some negotiation to say let’s serve something slightly different based on the device, according to those adaptive characteristics.”

I also think, unfortunately, we use adaptive to mean “not fully responsive designs.”

Ethan:

I’m definitely guilty of this.

Karen:

It makes sense, right? Because in my mind, it’s like you are aiming those adaptive designs at a specific device type or a specific screen size, and they’re snapping into place at those particular layouts rather than being completely fluid. So, I think of adaptive design as essentially being device-specific design in some sense.

Adaptive content, on the other hand, is where you are targeting different content based on some criteria.

Adaptive content, on the other hand, is where you are targeting different content based on some criteria. That may be device-specific criteria, like “I want to serve a short form of a headline to a mobile device and a long form of a headline to a desktop device.” But I think—maybe even more productively—it’s serving different content based on some characteristics that you know about the user. So, context is a big one—so what can I know about the time of the day or the location, or other things that I could know from the sensors, like perhaps the velocity that the device is going.

If I could fiat one thing into place, it would be that responsive solutions are client-side and adaptive solutions are server-side.

Then I might even extend adaptive content to include personalization. If I’m a banking site, for example, I want to target different content to you based on your lifestage. So if you’re a college student, you’re going to see different offers or different marketing messages based on that versus if you’re near retirement. If I could fiat one thing into place, it would be that responsive solutions are client-side and adaptive solutions are server-side. I like simple rules.

Ethan:

Yeah, no—hey, black and white, man. Let’s keep it simple. Totally.

Karen:

[laughs] And there’s some overlap on both sides, like the conditional loading problem that we were talking about earlier. Like, I might consider that to be an adaptive content solution, but it’s handled client-side. The example of not fully responsive adaptive designs, adaptive layouts that snap into place at particular sizes—well, that’s obviously totally client-side. But as a general rule, if you’re getting the server involved, let’s call it adaptive.

Ethan:

Interesting. Okay, yeah, that makes sense. So something that’s truly platform-specific, like help content, or something that’s user-specific, like something tied to your profile—those would be more server-side driven solutions, that would be more adaptive.

Karen:

Yeah, it’s like you need the server to get involved to be like, “Hey, what device is this?” or get the device to tell you something, like what location are they at, how fast is this device moving, for example. Other device sensors, like I would imagine things like humidity or temperature, if you were thinking about devices that had those types of sensors on them. Or genuine user personalization—so I want to query this device and find out what do I know about this person. Are they a new customer or are they an existing customer? That’s all stuff that can’t be handled client-side.

Ethan:

Now the interesting thing to me is that when I hear the term “adaptive,” it is usually in terms of it being opposed to responsive in some way, like “I can’t go responsive. That’s just ridiculous. There’s no business case for that.”

Karen:

“Look at this borked responsive site! Obviously the technique is a failure. You should use adaptive.”

I would like to get a tattoo perhaps that says “Responsive and adaptive solutions work together, period.”

Ethan:

Right. “Here’s this one URL that I found. This is a terrible responsive website. P.S., it is apparently possible to make a bad responsive design.” Are those two things just mutually incompatible? Is it really either/or? Am I asking a leading question? Possibly.

Karen:

[laughs] “So, Karen…” No, I think that, to me—like, I would like to get a tattoo perhaps that says “Responsive and adaptive solutions work together, period.” They are not opposites, they are not in competition. The fact that you might run into problems that responsive design doesn’t completely solve for does not mean that responsive is a failure. It just means that, oh right, this whole crazy landscape that we’re working in with all of these new devices and platforms—it’s hard. You might need multiple techniques to solve your problems.

I genuinely believe that responsive design will solve for ninety-five percent of the problems you have.

I see a lot of articles out there that are advocating for adaptive solutions without fully understanding the additional complexity that comes from working in that way. For somebody to say, “Oh, this borked responsive site… You should use adaptive.” That’s not a solution, that’s just a different set of problems. And frankly, they’re worse problems.

I genuinely believe that responsive design will solve for ninety-five percent of the problems you have. If you can solve your problem responsively, like if you can serve the same stuff to everybody, handle device-specific, screen size-specific problems fluidly on the client-side, then start there. That’s going to be the easiest, most flexible, most future-friendly way to solve your problem.

And then if you get all that done and you’re like, “Yay, we solved ninety-eight percent of our problems! But oh, shoot, we still have two percent of our problems.” Well, good, then start thinking about adaptive solutions. But don’t start there.

Start responsive by default and optimize for specific devices or use cases.

Ethan:

I love that. It almost seems like an updated version of the native app vs. website discussion we were having three years ago. It’s like, they’re not mutually incompatible. It’s really a question of resources, I think. For me at least, I’m always going to start with that broadest level of access as possible and then look for those interesting opportunities for those specific challenges that you need to solve in maybe a more targeted context. That seems to be like what you’re saying, more or less. Like, “Start responsive by default and optimize for specific devices or use cases.”

Sure, people may spend most of their time in native apps. Guess what? You’re still going to need a website, and that website is still going to have to be responsive.

Karen:

Honestly, to me, that just seems like the most sensible way to approach it. I get frustrated when I see people proposing—I mean, I’m sure you get frustrated in the same way when you see people talking about “Well, the web must be dead! People are using apps!” No, that’s exactly the wrong way to think about it. All of these things are complementary and it’s not a question of you not having a website. Like, sure, people may spend most of their time in native apps. Guess what? You’re still going to need a website, and that website is still going to have to be responsive. Quit debating them as if they’re in some kind of competition. They’re not.

Ethan:

We’re recording a podcast right now, or I’d be pounding my table emphatically in agreement. But yeah, beautifully said, man.

Karen:

Well, I think we’re about out of time. I feel like I could talk to you about this all day, but…

Ethan:

I mean, we’re probably going to end up talking about it all day anyway, but yeah, we could probably stop recording. Let’s spare posterity. Yeah, but I think we should probably wrap up by just saying thank you to everybody for listening. We’ve been doing this for a year and, honestly, our audience has been growing over those last couple fifty weeks and it’s been a real honor being here, so thanks so much for tuning in.

Karen:

I look forward to another year of hearing interesting stories about big, hairy responsive redesign projects. I love doing it. So thanks, everybody.