Episode Transcript

Ethan:

Hi. 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 vibrating with giddiness. We are incredibly excited to have Trei Brundrett from Vox Media with us. Trei, thanks so much for taking a few minutes to chat.

Trei:

Oh, I’m super excited to be here with you all.

Karen:

But before we get started, let me say a few words about our sponsor, Campaign Monitor. If you’re like most people, you open your email on your mobile device. If you know anything about responsive design, you know that making emails look great on all of the different devices and screen sizes that people might want to use, is really hard. Fortunately, there’s Campaign Monitor. They have a great new email builder called Canvas, that lets you make responsive emails in a snap. There’s an easy to use, drag-and-drop email crearotr, and so everything just works! Your images are sized correctly, your typography is the right size. Now, you can even try out the Campaign Monitor Canvas without having a Campaign Monitor account. Just go to campaignmonitor.com/templates and try out their fantastic tool that enables you to create emails that work right, for everyone.

Ethan:

So, Trei, would you mind just introducing yourself and tell us a little bit more about what you do on a day-to-day basis?

Trei:

Absolutely. My job is at Vox Media. I’m the Chief Product Officer, which is a really fancy title for, I think, meaning that I lead this team—lead is a strong word, probably, too—of about sixty-five cross-functional team members: Developers, designers, product managers, support, even DevOps is part of our team. We are building what the products of Vox Media are, that’s everything from the actual user experience of the sites themselves. We’re in these seven categories.

We started as SB Nation, which is sports. That’s actually over 300 separate sites that are part of that family. And then the Verge, which is technology at the intersection of art/science/culture. Polygon, which is video games. We launched Vox.com, which is really all about exploratory journalism and just covering the news and culture.

Then we also, last year, acquired an awesome company called Curbed, which was also in three categories, which were Eater, which was all restaurants and nightlife. Racked, which was fashion. And then Curbed, which was where they started and is sort of like community and real estate and your home. Each of those are their own categories.

We built a platform called Chorus that we launched those sites on and that we continue to iterate on each of those sites and build them and work really closely with our editorial and advertising team. So across all those different categories, that’s what our team works on.

We saw an opportunity to empower what we were seeing as really this amazing trend around how sports fans were interacting with their communities. So we decided to start to explore responsive and think about what that could be and what that could mean for us.

Ethan:

So Trei, could you tell us a little bit about Vox’s history with responsive design? Because you guys have been on my radar for a while.

Trei:

Yeah. I feel like we’ve been doing it for a long time in internet years. So back in the beginning of 2012, we were at this place with SB Nation where we really had some—we were starting to think about how we were going to evolve what SB Nation was going to be. We had just launched the Verge and we were kind of looking, what is the big next step for SB Nation? We had a really ambitious plan around doing a lot of different things, and keep in mind this is, like I said, over 300 separate sites. We did a rebranding, we did a redesign, and we were really looking at what we were doing in mobile and what we wanted to be able to do in mobile. And we saw an opportunity to empower what we were seeing as really this amazing trend around how sports fans were interacting with their communities.

So we decided to start to explore responsive and think about what that could be and what that could mean for us. And we stirred that into the pot of everything else that we were going to try to do, and we undertook this process in over six months to completely redesign all of those sites, completely—we also refactored under the hood, and take that entire network responsive. So that’s really where we started.

We’ve had all sorts of projects since then that have been responsive. It’s interesting for us. We’ve had sites of different stages. We’ve had these media brands in different places along the way, and so we’ve had a really interesting range of responsive approach for us across all of that. SB Nation was a big redesign of an existing site. Very large audience. A big large editorial team. Big advertising components.

Right after that we did Polygon. Which was a fresh start and we got to learn a lot from what we had done in SB Nation, rolling that in to that process. The Verge, we just last month launched that responsively. The interesting thing there is that we didn’t redesign in that process. We just refactored the site to be responsive. We also approached it in a more phased way. Vox.com was a fresh launch but it’s very different type of project. We launched quickly, in nine weeks. We focused on reusing a lot of what we had, a lot of our work that we had done on SB Nation about how to approach the site. Both the features, but also the markup, and how we were going to make it responsive. We’ve had this wide range of experiences with responsive now that it makes for a really interesting perspective on that approach, overall.

We’re thinking a little bit more about that total experience of where they’re coming from and even where they would go beyond that and what their next thing that they would want to do would be.

Karen:

One of the things that I think is most interesting, especially talking to publishers, is how organizations conceive of the difference between a mobile user and a desktop user. Organizations that go in whole-heartedly with responsive seem to argue that all users want basically the same thing. I’ve talked to other publishers though, that somebody wants to make a strong case for delivering different content or targeting content, say day-parting, by time of day, to better meet the needs of mobile users and desktop users, which they conceive of as being different. Can you talk a little bit about how you see that at Vox?

Trei:

Absolutely. I think what we’re thinking about designing this experience that is really about before they come to our site. I think that in media there is still preoccupation with direct traffic, with people that are showing up and coming to your home page. I think that’s where you start to get in to day-parting. You have this notion that the user experience starts and ends at your site.

For us, we come from a different place. We’re a company that was founded by bloggers and we don’t have any of the legacy of traditional media and a lot of those notions of even the editorial pressure around thinking through that as much. We really are designing more for where people are coming from and what the total experience is. So, what we’re thinking about a lot more is that they’re coming from a social experience, right? Or folks search. They have us bookmarked, that’s a possibility as well. We do have a lot of direct traffic because we have built strong community into what we do. We’ve taken that fixed experience, that perspective into account.

In particular, for search and for social, I don’t think we think about it as much as specifically mobile. We think about social now is driving a lot of mobile. What we see is people coming from Facebook and from Twitter. They’re opening it up and it’s in the little in-app browser or if they’re lucky, kicking it out to a native browser. But, what we want to do is deliver a really awesome experience there. What they saw before they arrived and what they receive beyond that click is really important to us. How we deliver a really great experience there but keep them engaged with awesome things beyond that is also part of it. We’re thinking a little bit more about that total experience of where they’re coming from and even where they would go beyond that and what their next thing that they would want to do would be.

We are always trying to reduce the friction of delivering a great product experience as much as possible, and so aligning our total experience to anywhere that people want to interact with us was a really straightforward proposition.

Ethan:

Trei, looking back at the SB Nation dot com responsive redesign, which was really when you guys popped up on my radar, because it was massive and really well executed. I guess I’d be interested to hear a little bit more about how you convince stakeholders internally that responsive redesign was the way to go? What was that conversation like?

Trei:

I’ll be honest with you that we’re in a different situation where we’re very much a technology-driven media company, and product has always been infused into the total culture. And so what we’re looking at is, what is the best user experience that we can create? What’s the best solution? What is going to help us grow? What’s going to help us build really great media brands? We don’t have the luxury of having these brands that have been built up for, in some cases, hundreds of years.

So it’s pretty easy to get behind those things. I’ll be honest with you that the conversation went something like this. I kind of laid out some… basically it was, look, mobile is growing. It turns out sports fans always are thinking about sports and if they can get that on their phone they’ll be interacting with it. So it was aligned with the way that our audience behaved. I think we were maybe in sports a little more accelerated on that trend than others. We said, you know, let’s get behind that. Let’s empower those users. Let’s accelerate that trend. That’s a really exciting and interesting one.

We are always trying to reduce the friction of delivering a great product experience as much as possible, and so aligning our total experience to anywhere that people want to interact with us was a really straightforward proposition. It was really like, just lay this out, and they said yes.

That wasn’t the hard part for us. It was really the next step, which was realizing that a responsive design approach really wasn’t a design approach, it was an organizational approach to thinking and really aligning everything else about how we worked and how we built things together. We have a very collaborative culture across product and editorial and advertising, and how did we start to align that idea. That’s really what we started to dig into.

Our guiding principle is that advertising is part of the total user experience. It turns out that a great user experience with your advertising integrated with what you’re building, your advertising performs better. It performs better for everybody.

Karen:

Let me follow up on that and ask specifically about ad sales. So I think a lot of people agree that responsive is a great thing for your editorial team and a great thing for your readers, but how do you make the case to advertisers, or how do you deal with the fixed-width ad problem?

Trei:

So there’s a couple different slices of that. First of all, I’ll just say that we have from early on, tried to change the culture of how we collaborate with our advertising team and how closely we work with them. And the first thing that we… kind of our guiding principle is that advertising is part of the total user experience. I think that our team takes some responsibility for it. I think we, over the years, as we made things, fell into the trap of putting the gray box on the mock and being like, ad goes there, okay, now let’s figure out all the rest of the stuff.

I think a lot of folks, once we started doing responsive, realized, like, oh man, this is a little bit harder. But I think it goes even deeper than that, which is thinking about if you make it part of the user experience, how you not just “fit it in” but how that’s actually a great experience.

Also, to be honest, we’re building a business. We’re in a different situation where, again, we don’t have any legacy print revenue that is driving our business, so we need to make this work for advertisers as well. It turns out that a great user experience with your advertising integrated with what you’re building, your advertising performs better. It performs better for everybody. So the approach that we took was, I think, twofold. One was really helping our advertising team understand what we were talking about and what we were trying to do, and also for us to understand what the mobile sales market was, and in tablet and what the opportunity was, and could we deliver something really interesting there?

We developed some new responsive ad products. We equipped our sales team with those things and they took it out to market and they totally kicked ass. It became a differentiator for us in the ad sales world. We all won in that case.

Together we collaborated, and I think we came up with—we could have started even earlier on this in SB Nation (that project, we called it SB Nation United) we could have started a lot earlier. We’ve gotten better and better and better at that. But it’s still something that, I think, we want to really get where it’s just a completely native experience to what we’re building.

We did two things. One is that we took this idea of, instead of selling these—not instead of, I guess. In addition to selling mobile-specific advertising, which is, I think, still necessary, there’s still ad dollars that are targeted specifically to that, and so you have to deliver a product there. But what we also did is say, let’s create something new, a new idea here, which is that we developed some new ad products that could be really interesting and exciting for the advertisers but also work really well in the user experience. And this is a product that we would sell across all screen sizes and all capabilities of the device. Instead of selling against that particular device or screen size or whatever, let’s sell our audience. Let’s sell the experience and the people that are coming to our site. It sounds bad, selling our audience, but what I mean there is, what the proposition is, is that we have really great engaged sports fans, and you want to reach those people and you want to reach them in the context of a really well-designed experience and great content, this is something that can work across it.

So we developed some new responsive ad products. We took some of our ad products like re-skins and figured out really clever ways to make them work responsively. We equipped our sales team with those things and they took it out to market and they totally kicked ass and sold those things. It became a differentiator for us in the ad sales world. We all won in that case. And we’ve continued down that path. We even built a platform that makes it really easy for us to build new ad products and serve them into our responsive sites.

The responsive design magnified all of the other problems, all of the other challenges that we had, because we had taken this kitchen-sink approach to this big redesign. We had to learn a lot about how we were going to work together.

Ethan:

Trei, I wanted to touch on something you mentioned earlier which is, I guess some of the organizational changes that needed to come about when you start doing more multi-device, more responsive work. Can you tell me a little bit more about how the product team collaborates on some of your different properties and how that’s influenced their design process?

Trei:

Yeah. Like I said, we’ve gone through all these different projects and we’ve learned a lot. What I’ll say is that we’ve taken something, an approach, we’re inspired by people who have gone before us and had shared how they had done that. That was really important for us just to, you know, “we can do this.”

On SB Nation, one of the things that we learned is that the responsive design was not—what I would say is that it didn’t—by itself it would have been difficult, but it magnified all of the other problems, all of the other challenges that we had, because we had taken this kitchen-sink approach to this big redesign. We had to learn a lot about how we were going to work together. We were doing re-branding, we were introducing new editorial tools. I think one of the lessons we learned was, you exponentially complicate it if you’re adding these different layers of ambition to all these other things you’re doing. So try to keep that simple, try to keep that focused as much as possible.

My goal was, I basically spun down the mobile team, just said: all projects now are going to take into account all of the devices, and everywhere that we need to reach our audience, and we’re going to design from that.

I think what’s happened that’s evolved over time is… So the first thing we did, by the way, is that we used to have a mobile team, and I think this is a team that other teams have, other organizations have or have had. And part of that was because we had built a native app for SB Nation. But as we started to get into this stuff, I think what we realized is… My goal was, I basically spun down the mobile team, just said: all projects now are going to take into account all of the devices, and everywhere that we need to reach our audience, and we’re going to design from that.

That sounds good, you can say that, and then now you have to actually figure out how to go about doing that. And we’ve always… I think we were well-equipped, because we had always been organized with small cross-functional teams that collaborate together. And take a more iterative approach to what we build, and how we design things. It even tested that, right? Because we had, even with that level, we had come into norms of how we would work with each other. So the teams were sharing knowledge as we were going along. Polygon actually overlapped the end of SB Nation, so we did some knowledge-share between the teams. The teams started developing new tools, new ways of working together.

I think this has been one of the great benefits. Again, it’s aligning our product experience as much as possible, even the process of creating that. We needed to communicate a lot more. We needed to find ways to be able to communicate earlier. And it sort of forces the issue of how you… You can’t throw things over the wall, you have to really sit side by side—not necessarily literally. And create what this is gonna be, iterate through it, and develop those ideas. So our cross-functional team approach I think really set that up well, but we still had to make that happen.

The other thing, by the way, I just think is critical, we’re very brutally honest with ourselves at the end of projects and when we do our retrospectives. And try to take those notes and really apply them, take those lessons, and be honest with ourselves about how we work together to create really great stuff.

All of our prototypes being responsive out of the gate is really killer, right? When we start developing new products, we prototype responsively. We focus really on what that feels like.

Ethan:

I just wanna follow up on that quickly Trei. You mentioned, starting the Polygon redesign, that there were some tooling and some new processes that came out of previous redesign. Can you talk about some of the applications and tools you guys have started to adopt internally?

Trei:

Yeah. So we started doing, we started some interesting tools that, this has kind of evolved over time. But one of the tools that we’ve developed that I think is great is, we do these… Part of our design process is to put together type boards to explore the different type treatments. And the team put together—and has evolved this over time—they put together these responsive type boards that were really cool. Because what they would do is, you could switch out different combinations of typography. But also you could switch out different headlines in the different content. And we were starting to get a real feel for things. And we could, the boards themselves, we could test them on different devices. We could test them across different operating systems, which is critical, depending on who you’re using for your website. We started playing with—even that early in the design process—we started to putting that together.

Now they’re working on some ideas around responsive mood boards. Really trying to get as much, as early into the process, native to the way that we work and think about what we’re going to make, can we build some of those tools?

And I think there is also different templates that they started using. Different ways of sharing ideas, where we could quickly be in markup, and be working together and be evolving. Not just the design necessarily, but also our solution design and what the product was going to be, and play with that. And really get into, all of our prototypes being responsive out of the gate is really killer, right? When we start developing new products, we prototype responsively. We focus really on what that feels like.

A good example is that we built a product called SB Nation Live, which is a real-time conversation tool for our sports sites to talk about the game, sort of like a live blog but with more of the community engaged with it. We prototyped that and were able to very quickly play with it. Phone was obviously a big use case, so we’re able to do that, but also we wanted to understand how that worked across all devices and what that would feel like. And I think that’s really critical. I think if you wait to apply responsive ideas or start trying to… now how’s this going to shove up and down the line, you’re just making it a lot more difficult on yourself, and I think the product suffers, the experience suffers as a result. There’s clunky bits that you end up with. It’s important to start early.

We didn’t really come at it as, we need to build a CMS. We came at it from just a pure design perspective of, what do they need here? What’s a user experience for our editorial team, for our users, and what would be the right platform to build for that?

Karen:

I’d like to ask about your editorial process and how that syncs up with the of responsive redesign. So I’m a fan of the content management industry and I kind of track what people are doing, and Chorus has this perception, I think, externally that it’s less of a content management system and more of an integrated wish-fulfillment platform that makes all of your dreams come true. I’d just love to hear how—when you’re doing a responsive redesign like this, what changes do you make to your editorial tools? How do you communicate to your staff what’s going to be different in how they publish?

Trei:

This is another place where we’ve learned a lot and made mistakes and learned from them. The idea behind Chorus is that—just to talk about that for a second and how that plays into this, because I think it’s really important—when we started out as SB Nation we had this network at the time of, I think, seventy sites. They were all on separate software, separate installs. They didn’t have a common user database, they didn’t have a common content database, and there wasn’t an easy way to update code across all these different sites. So when we came into it… And they had really strong community, and it was sort of this tightly-coupled network. When we came into it, we had come out of—this was a team of Michael Lovitt and Pablo Mercado and Ryan Gantz and I—and it was a small group.

We didn’t really come at it as, we need to build a CMS. We came at it from just a pure design perspective of, what do they need here? What is the experience that we want to create? What’s a user experience for our editorial team, for our users, and what would be the right platform to build for that? We didn’t really start with the CMS idea per se. We knew that there was editorial workflow stuff, but we were just as preoccupied with community and we were just as preoccupied with—not as much like workflow as, you know, these are bloggers and there was removing the layer of abstraction and making thing more organized. So that’s the seeds of Chorus.

What it really is, is this platform that we can build these media brands on and create, take an editorial vision, and collaborate with that to create these sites. The tools, CMS, to me—first of all, I just love “content management system,” just as this acronym that totally sounds like it was created by the IT department, and it’s just this very tools-y way of thinking about it. We were kind of building this end-to-end experience. So I think what has been… Chorus is this platform on which our team can create really great things in collaboration with our editorial teams, and even with our users.

What we’ve tried to do is help people understand how the story formats relate to what they’re making on the other side. And even that “other side” notion, trying to tear that down as much as possible so that they have a real feel of exactly what they’re creating for the people who are going to be interacting with it.

As that plays into responsive design, what that has meant is that we’ve had to think about, how does Chorus support that thinking. As an example, we’re able to do really creative advertising pieces because we had built a custom-advertising layer in Chorus that allowed us to do custom things without hacking our tools too much. We’re lazy programmers, so we wanted it to be easier to do custom advertising and make that a repeatable thing that our ad ops team could execute. So that’s one example in the advertising realm.

With our editorial teams, a lot of it was just starting to think about the way that, across all these devices, what is the user experience going to be? When you’re creating something, what are the things that you need to think about for that? Our tools are not—they’re in the process of constantly evolving and we’re underway on evolving them even more, which is super exciting. But what we’ve tried to do is help people understand how the story formats relate to what they’re making on the other side.

And even that “other side” notion, trying to tear that down as much as possible so that they have a real feel of exactly what they’re creating for the people who are going to be interacting with it. I’d give us, from a responsive perspective, I think a B on that right now. We’re working towards an A on how Chorus really fully embraces that notion, not only on how you experience it but how you create as well.

QA is really interesting because obviously that role has become more important than ever. What we’re finding now is that the more complex that gets, the more we need to focus on that.

Ethan:

Trei, one of the things I liked about your process story before was trying to get things into the browser as quickly as possible, trying to interact with the design as it’s evolving. Can you tell me a little bit more about the other end of that process? How QA gets involved during design, how you actually vet these pretty complex design frameworks in various browsers and devices.

Trei:

You start to look across the organization and look at your process. QA is really interesting because obviously that role has become more important than ever. Not only in how you can automate that as much as possible and make that efficient, but just be thinking holistically about what is your checklist, and when you’re QAing. Not just that it works but that that experience fits. What are the things that you missed in the cracks there? So that process has become a lot more complex and I think what it’s done for us is really made us realize that we need to…

The most interesting part of QA and responsive is actually around advertising, and I think is where there’s a lot of complexity. Because those systems are often third-party systems. They may be fragile.

QA, on these small collaborative teams, it had always been kind of a shared responsibility. We would have people who that was their primary role, but we also would kind of take responsibility for what the test plans would be and what we thought we needed to do. We’re trying to never—as we have these collaborative teams—throw something completely over the fence to anybody. So we shared that. But what we’re finding now is that the more complex that gets, the more we need to focus on that.

I think the most interesting part of QA and responsive is actually around advertising, and I think is where there’s a lot of complexity. Because those systems are often third-party systems. They may be fragile. You have to get the actual creative that’s going to run on the sites. One of the things I think we’ve done really well lately and gotten a lot better at—we just launched Eater, relaunched Eater, redesign and new advertising, and it is getting a lot better earlier in the process of how we QA, how that fits into the experience as well. We got better about designing advertising into the experience and building that into our system, but in terms of QAing it, I think even that piece is catching up to be well ahead and be thinking about it.

Working with our ad ops, with that team, so that they understand how they need to be thinking about QAing it, because there’s all these different ways that you need to set that up to be able to test it across different devices and make sure that experience is great.

It’s hard to overstate the scale of SB Nation. We were seventy million unique visitors back then, I think. At the time, roughly about thirty-five percent of our traffic was non-desktop.

Ethan:

Kind of related to that, I know that one of the things that’s kind of entering the responsive conversation, whatever that means, right now is this idea of performance, which is becoming more of a priority for a lot of publishers. Is that something that Vox has been focusing on? Is that something that you guys have had any discussions about?

Trei:

Yeah. So performance, it was the big “ah-ha!” after we launched SB Nation. Just for some context, we had—it’s funny I remember this—but back in 2008 we spent a weekend where we were like, we should make the mobile version of the site! And it literally was like a weekend. Okay sweet, now there’s a mobile version of the site! It was just our M-dot redirected to it and we did some clever things in Chorus to make it easy to set up and it was really successful. It was a paradigm version of the site. It was also super fast, so we didn’t think about it. We were like, great, it works!

When we relaunched with United on SB Nation, that was the immediate issue. We were dealing with—it’s hard to overstate the scale of SB Nation. We were seventy million unique visitors back then, I think. At the time, roughly about thirty-five percent of our traffic was non-desktop. They had had a certain expectation and experience about how that felt, how that worked, and immediately it was a challenge. Our load times were way higher than they had been. There was also just the jankiness that was introduced in terms of how you were experiencing the site and how you’d scroll through it. It made it more complex because we had made some pretty radical product design changes and even editorial approach changes. Some of that was fed into it and sort of magnified it.

But from an objective perspective, the first thing that we did—we learned like, hey, we have to do this earlier—is instrument everything that we could. Really understand where the load time, what was happening and where. Even immediately it was like, well, it’s got to be the ads, which is easy to pin blame, but it was much more complex than that. We had to really break it down and start to slowly work our way through it. We learned a lot of lessons about how to measure, how to refactor, how to iterate through that, and what our baselines were.

We ended up developing our own tool called Tempo to be able to—we’ve written about this on our blog—about how we monitor and measure load time on our sites and how we set some baselines and try to achieve those.

We’re going to be obsessed with lowering load time and really thinking about this across all devices and all connectivity, and be very serious about it, because it’s meaningful for our business. If we lower load times, more people will come back.

And then the other thing that we’ve done is taken all of our lessons and actually started refactoring across all of our sites, our front end code to be, here’s what our best practice consistent way of doing front end is going to be. That’s been really helpful for us to stay sane, since we have all these different sites and we allow ourselves to develop unique visual identities for them, so we were developing different front end code over time. So we’ve done those things, and then actually, just last month the team that had come out of The Verge responsive project, they had—in that project they started thinking about performance a lot earlier. We had kind of learned our lessons over time. They were measuring things and thinking about it. They were doing this kind of iterative approach to how they were releasing the redesign.

Our lead front end developer Dan Chilton, who had come out of that project, we actually said, you know what, your full-time job now, it’s going to be front end performance and you’re going to take complete ownership of this across all of our sites. We’re going to be obsessed with lowering load time and really thinking about this across all devices and all connectivity, and be very serious about it, because it’s meaningful for our business. If we lower load times, more people will come back.

And again, I’ll just come back to something that’s really important is that thinking about that total experience, right? Which is testing like, what it feels like to click. You see a tweet to one of our stories and you click it and you open it up and it’s in that, the little Twitter browser, and how that loads and what that experience is. If people start to learn that it takes awhile for that to load, they’re maybe not clicking as much. And I think that’s been pretty well understood across the industry now. We’ve done really well with that in terms of making improvements, but we’ve kind of become obsessed with just being super focused, having dedicated people working on it, and learning as much as we can and then sharing as much as we can about what works and what doesn’t work in terms of improving that.

Karen:

Well, Trei, I can’t thank you enough for taking the time to share all of your perspective across all of these different questions and I’m really grateful that you have taken the time to let our audience know what you’ve been up to. I would, I wish I could talk to you all day. This was fantastic.

Trei:

Well, thank you. This has been, it’s awesome and I really appreciate you all putting this whole series together. I think what’s key these days right now is that we’re learning from each other. There’s a lot of lessons and there’s a lot of really great things that are happening. I think what’s been awesome about you all’s series is just the breadth of people that you all are talking to who are doing this work and really realizing that we can all learn from each other on this. So I appreciate you all putting this whole thing together and I loved talking to you all about it.

Ethan:

Likewise, Trei. The feeling is more than mutual.

Karen:

Thanks to everyone for listening to this episode of a responsive web design podcast.

Ethan:

If your company wants to go responsive but you need help getting started, we offer a two-day onsite workshop to help you make it happen. We’re also planning to offer these workshops to the public, so please go to responsivewebdesign.com and let us know that you’re interested.

Karen:

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every podcast episode at responsivewebdesign.com.

Ethan:

Thanks again to our sponsor, Campaign Monitor, and we’ll be back next week.