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 could not be more excited to be speaking with Tiffany Campbell and Scott Dasse who are going to be telling us a little bit about WBUR. Tiffany, Scott, thanks so much for joining us.

Tiffany:

Happy to be here.

Scott:

Great to be here.

Karen:

But before we get started, I’d like to say a few words about our sponsor, Media Temple. If you’re a web designer or developer, you need solid hosting with great customer support. Media Temple focuses on the needs of the design community, and is constantly improving their products to make hosting simple for you. That’s why they have one of the highest customer loyalty rates in the industry, with the average customer sticking around for years. If you’re looking for WordPress hosting, shared hosting, virtual private server hosting, or just want something better than a crappy $5 a month hosting plan, you want Media Temple. Go to mediatemple.net and learn about their hosting services and award winning support team. Use code RESPONSIVE to save 33% off the first three months of shared or Wordpress hosting.

Ethan:

Maybe before we actually dive in, you both could just introduce yourselves, tell us a little bit about WBUR, and maybe mention a little bit about the new website you’re working on. Tiffany, do you want to go first?

Tiffany:

Sure. I am the executive editor for digital at WBUR. WBUR is the Boston NPR news station, it’s one of the larger stations. We do a lot of original content, a lot of original podcasts, audio, digital verticals, things like that. We’ve been kind of embarking on a long-ish journey to rethink our platforms and rethink how we wanted to do digital audio. We probably started about a year and a half ago or so really exploring these things, and so we’re just a couple weeks away from getting out of beta, so we’re really excited about that.

Scott:

And I’m Scott Dasse and I’m a creative director at Upstatement, but previously actually worked at BU. BU and WBUR are part of the same larger organization, although WBUR is independent, so I had a history of working with WBUR before I came here and was thrilled to join at a time where the redesign was starting.

We had gotten to a point where our platform was pretty unsustainable. We weren’t able to do the kinds of things we wanted to in digital storytelling.

Ethan:

That’s fantastic. We’re both really excited to have you on. Tiffany, you mentioned a long journey to going responsive. Maybe you could tell me a little bit about the beginning of it, how that journey actually started. Specifically, I’d love to hear a little bit about why there was a decision made to go responsive and if your stakeholders had any questions or if there were any difficult discussions around responsive as a methodology, we’d love to hear a little bit about that.

Tiffany:

Sure. I would say it was maybe even longer than a year and a half ago, it was maybe two years ago that we really were realizing that we had outgrown our website. We run WordPress, which is a great, flexible, wonderful platform, and we were on WordPress Multisite, and for many years the digital strategy had really been to spin up new sites as needed. That had worked great for quite some time, but the reality was that we only had two web developers and we had no design resources that work at WBUR. I’ll say that one more time: we have no design resources, no designers who work at WBUR in an official capacity full-time. [laughs]

And so, we had gotten to a point where our platform was pretty unsustainable. We have a audio system that ruins underneath it where we publish all of our audio, it’s all connected with WordPress. And we were just saying we can’t do the things that we want to do; we had a mobile site that worked on portions of the site but not all of them, and we had just really outgrown it; we weren’t able to do the kinds of things we wanted to in digital storytelling.

So we started talking to a lot of different people, we kind of employed what my boss often references as his “kitchen cabinet.” We talked to a lot of smart people who kind of gave us some suggestions and some guidance in the way of really rethinking it. And so, I really tried in the beginning and ongoing to not consider this so much as a redesign—it’s actually a completely new platform that we built, and so that was also challenging to get people to kind of wrap their minds around, of really taking it down to the studs.

Because of all the things we wanted to do around audio, we couldn’t retrofit the site, we really had to take it down to the studs and start over, which is really exciting but also made the project much larger and more complicated.

When we started, we just were thinking that we were going to start kind of in a classic redesign fashion where we might work on article pages, and then we might work on landing pages, and then kind of rollout to the home page. And over time, we really realized that because we had so many sites that we were maintaining and because of all the things we wanted to do around audio, it’s just that we couldn’t retrofit the site, we really had to take it down to the studs and start over, which is really exciting but also made the project much larger and more complicated. So, I think we’ve been able to achieve the things that we wanted to do, but it definitely took us a lot of talking to people in the building about really what our goals were. We really tried to keep it not so much to tactical things but really think about, “What do you want to do? What’s a great audio experience?” and just start from there.

In terms of responsive, I’m sure that we had a conversation about whether we should have a mobile site vs. going responsive, but I think it was a very quick one and I think it was really clear to us two years ago that with a small team and a small technical team, that responsive made the most sense to go forward on. I would say the stakeholders, once you can describe responsive as saying that this is going to work on any device, we don’t have to worry about a supersized iPhone or a very small one, we can just build a website and it’s going to work across all these different platforms and not have to worry about what kind of devices are going to come out next. Tt was really going to be the best way forward for a smaller team, and it was really going to be best for our users.

We had quickly surpassed a fifty percent mobile audience at the time and we’re higher than that now, I would say that sixty-five percent of our audience is coming to us from mobile devices, so it was really clear that we had to stop thinking about the desktop and start thinking about phones truly first, and tablets.

Karen:

Let me follow up on that and ask, how did you talk about the needs of different people coming in, using different devices? In particular, we’ve talked to other people from the world of public radio that sometimes describe the needs of a mobile user and that might be different from someone coming in from a desktop computer. How did you talk about that, and did you think they were different?

Tiffany:

Well, I think sometimes. [laughs] Honestly, it was helpful to talk about this through the prism of audio. Digital audio is a very modal type of thing. You’re either in a position to listen or you’re not, you either have your headphones on or you don’t. And so, what I tried to do was talk about real people doing real things in real use cases. The example I usually use is someone’s in their kitchen and they have their laptop and they’re cooking, and so they just want to stream us out and they just want to definitely press Play and walk away. And that’s an important use case and we’re certainly keeping that in mind.

But, I also talked a lot about people, when you’re on your phone, when you’re running, when you’re on the T, when you’re in those places, and I think once all of us were able to kind of discuss things as real life examples, it became instantly clear to everyone. Because everyone is already on their phones so much, it just became very clear to them, “Oh, there’s all these things that I want to do on my phone that I can’t.” And there were quite a few other third-party apps that have been coming out over the last couple of years that were doing some interesting things with audio, and it was so clear to us that our site should be able to do some of those as well. I tried to keep it very specific and very “real life” as much as possible.

One of the big efforts was to consolidate all of the content and all of the programs in a design that just worked across devices. Even that is a big win for people who want to cut across different content verticals.

Scott:

And I’d add that if you look at where they were, there were so many different designs for different programs and blogs and sections, many of which did not actually have a mobile version of the site. If you’re a user on the current website that’s not the beta and you wanted to listen to On Point, a program, after the audio is added, it’s actually not easy to do that on a phone at all. One of the big efforts was to consolidate all of the content and all of the programs in a design that just worked across devices. Even that is a big win for people who want to cut across different content verticals.

The idea of a beta site really excited us because it was going to allow us to get this kind of feedback and actually talk to our users in a way and kind of engage them in a conversation that we hadn’t really been able to have.

Karen:

Ethan knows that one of my favorite questions to ask about is rollout strategies, and it sounds like you’ve got a really interesting story here around how you decided to not just retrofit, but instead take it down to the studs and do a whole new replatforming and launching a beta. Can you talk about how those conversations happened and how you made the decision to roll out that way?

Tiffany:

Sure, and Scott should definitely weigh in on this because this was definitely a very big collaboration between Upstatement and WBUR. Like I said, we had talked to a lot of firms and we had chosen Upstatement to go with, and we were just kind of mapping out what we might do and what we might start with and how we might do it. And we did do quite a bit of work; we updated the article pages on WBUR.org responsive, and we did some other work that was great and was working well.

But then as we started talking about audio and particularly the idea of persistent audio, and particularly the idea about some of the goals that we still have for 2016 and beyond around login and user authentication and mobile giving and things like that, was that really we had to be on one single platform. And because—the number always changes, but we were maintaining somewhere between fifteen sites or so, maybe as many as seventeen if you count some of the freestanding ones, and we just were kind of hitting a wall.

Upstatement came to us and said, “We have this idea about why don’t we run the site in a beta?” And that gives us a couple of great things. One, it allows us to really start over and start from scratch and kind of build it the way that we think that it should be built and not worry so much about all the technical—I mean, we still have to worry about our technical debt, no doubt, but not worry as much about the enormous amount of technical debt that we were working with. But most importantly, it allowed us to run it for a certain period of time so that we could take feedback from users. We think that we had made a lot of really smart bets and smart choices, but someone very smart said to me it’s when you launch, that’s the moment where people actually start to tell you what they want and how they’re going to use your site. And so, the idea of a beta site really excited us because it was going to allow us to get this kind of feedback and actually talk to our users in a way and kind of engage them in a conversation that we hadn’t really been able to have, or really hadn’t had the time and the resources to have. But Scott should jump in, too.

Scott:

I think everything that Tiffany said is true. The thing that I’d add is that this was unlike pretty much every other project I’ve worked on in the sense that the developer team, which at that point was two really smart guys, were essentially in-residence at Upstatement, so they moved in with us for almost the full duration of the project and we ran the whole thing using agile scrum. So we were building it from the ground up, piece by piece, feature by feature as a way to kind of get to a testable version of the website sooner. Best laid plans and all, we wanted to roll something out much earlier than we did, but we still ended up getting to a more or less complete experience with audio and channels, and some of these other things that we dreamed up, being rolled out many, many months before the launch would be ready. So, I think getting that out there and collecting feedback has taught us a lot, but also the sort of feature by feature build process was useful in prioritizing what needed to happen early and then what could wait for a later phase.

Certainly there are very important instances where comps are going to be the easiest way to talk to people about things. But there’s nothing better than having something in a browser.

Ethan:

I’d like to hear a little bit more about how that process impacted the design of this responsive site. When you were thinking about a feature by feature, module by module approach for building responsively, how did you actually talk about aesthetics or typography, or how did you actually involve the clients in some of those decisions?

Scott:

That’s a question that I can start with and then maybe ask Tiffany to weigh in on, because probably the hardest thing about this project was having anybody who was outside the room keep up with what was happening. So, when we talk about reviews in decision-making, those were largely not about let’s look from options and pick from color palettes and type. It was almost entirely designed in-browser, which isn’t something that Upstatement always does, but in this case, the idea was we would be building MVPs every sprint and then we would be reviewing them as a group and then building on top of that.

So, the design largely evolved from day 1 to day 365. It didn’t necessarily pause and ask for formative feedback at any specific point, but along the way we would be saying, “You know, those icons don’t feel right in that spot. Can we consider adding a card to make those more readable?” or whatever would be the actual feature add or the enhancement needed, that would then roll back into the next sprint. And I think sprint by sprint, we kind of made refinements and refactored without having to have a big set of comps that dictated the global design of the product.

Tiffany:

Right, and I think the only thing I would add is that was what was great about, again, launching the beta site, is that we were able to see these things and point to them, which was so much more powerful. We still use comps, comps are certainly very helpful and certainly there are very important instances where comps are going to be the easiest way to talk to people about things. But there’s nothing better than having something in a browser, there’s nothing better than having something online or truly on your phone, and just say, “This is what it’s actually going to look like.” Because I think that when you look at website design and things like that, we often look at them on a big huge projector, and there’s like twelve people in the room, and everyone’s pointing at things, but that’s not the experience of the user, right? That’s not a natural experience of how you actually experience web design. The more that we can get it in the browser, the more it’s actually on someone’s phone to look at, the better, and that’s how we’ve surfaced an enormous amount of bugs. Our general manager is a very, very heavy user of the beta and of the other things that we have in development, and so he’s always emailing me, “I was looking at this and I saw that,” and these are things that just would never surface if they weren’t already out there in the world for us to deal with and we could manage them live. So, I think it was very effective. It doesn’t mean that it was always perfect, certainly some work would be done that had to be rolled back or changed, but I think it was all a really really important exercise in getting to where we are.

When we’re developing comps, we’re still using the web-based pattern library and then essentially making a screenshot of that to send for evaluation.

Scott:

Right, and Ethan, you mentioned the idea of modularity and I know you’ve used that as a theme across other discussions. But we have ended up with what we call the pattern library, it’s just a homegrown set of templating that generates all the different layouts and micro-layouts that you see across the site now. When we’re developing comps, as Tiffany put it, we’re still using the web-based pattern library and then essentially making a screenshot of that to send for evaluation, so it’s still essentially code that’s building out those sample screens.

It seemed like ninety percent of the feedback we got from the beta experience was related to finding things.

Ethan:

That’s fantastic. One thing I’d like to hear a little bit more about is with such a public beta site, now that it’s out there and in front of users, what have you learned just in terms of some of the initial design assumptions you had when you were working internally? Were there any elements of the design you’ve had to rework now that it’s in front of actual users? I’d love to hear some examples of that if there’s anything you can share.

Tiffany:

Probably the biggest one for us was, for lack of a better word, signposting. You know, we had done some things in the navigation where we were trying to split out programs… What’s the difference between a program and a podcast, that’s a fun discussion we can get into at some point, from a digital perspective. [laughs] And then we have all these verticals that are uniquely branded and are mostly text stories but also do audio, and so we had a lot of stuff and we had broken them into two different buckets, and one was more audio-based and one was more text-based, and I think that made a lot of sense to us internally because we were very familiar with the content. And of course I know off the top of my head, yes, that’s a blog, or no, that’s a podcast, and all the nuances in between, but to regular people those are the things that trip them up the most, they’re like, “I’m looking for X program and I don’t know where to click,” kind of thing. And so that really was nice to see how it coalesced when people would bring up the same thing over time and to be able to say we’ve really got to rethink how we’ve sorted this content this way. So that was extraordinarily helpful, and even if we didn’t get any other feedback, I think that would have been very, very useful.

The other thing that was nice was that people were really very positive about the changes in audio in terms of the persistent play and being able to kind of cycle through audio, and just have audio be more of a—what we found in our current site was that it was a very much a tech-space site, that you weren’t able to see that we did a lot of audio, and audio is the thing we do, that’s the thing that we’re known for. And so we really feel like that with this site design, we were able to bring the audio forward, and people responded well to that.

Scott:

Yeah, to add to what Tiffany was saying, we expected to hear much more in terms of critical feedback about the audio experience, which was, I would say, about half the focus of the entire project. Making what feels like an audio app inside a browser was technically challenging from a design perspective. But ultimately the lesson we learned was that we were thinking too much as insiders about the way navigation worked, and as Tiffany said, we made divisions that our users don’t necessarily make when they’re trying to find something. So, I feel like—Tiffany, correct me if I’m wrong—but it seemed like ninety percent of the feedback we got from the beta experience was related to finding things.

Tiffany:

Yes, absolutely. And that’s typical especially of a site that’s as mature as ours, that the users that would be coming, “Where’s my stuff? Where’s my usual things?” So yeah, absolutely.

We’re looking at different ways to package audio on the site so that if there are stories that are really just exceptional in audio and are an audio story, that we don’t necessarily have to put together an enormous, long written script along with that as well.

Karen:

How did this replatforming change the editorial direction or content strategy for what you’re publishing? Sometimes we talk to people that say that their fundamental concepts of what’s a blog, and what’s a podcast, and what’s this and what’s that don’t change, really. But other times it’s an opportunity to completely revisit the editorial direction. How did you approach that?

Tiffany:

I think we are still very much in the middle of that and I think there’s a lot still that we’re working out. I think one thing that was a very early, early goal that we’re still kind of determining how the editorial strategy is going to shake out on that is we really wanted to let audio be audio on this site. A lot of what we do today is that we will provide a written story along with—like, if there’s a six-minute news story, let’s say, on Morning Edition, the producers and the reporter will also write a version of that and those two things will be packaged together online. That strategy we feel like was very successful for many years, and I think that as people are moving on to mobile devices in particular, like I said, it’s kind of binary, you’re like, “Oh, I’m in a listening mode right now and I want to cycle through stories, or I want to read something.” It’s kind of hard to skip through audio in the same way that you scroll through headlines or something like that. So, I think that we’re looking at different ways to package audio on the site so that if there are stories that are really just exceptional in audio and are an audio story, that we don’t necessarily have to put together an enormous, long written script along with that as well. So that’s a small thing, but it’s kind of a big deal in terms of a lot of our producers and writers and where we’re spending our time today, and so I think that this site will allow for a lot more of those conversations to happen.

I think there’s also a lot of workarounds that we’ve been doing that we can maybe stop doing so that we can move on to other things, in terms of how we put together rundowns and how we automate systems and things like that, that it won’t need a person to actually create a post to publish a podcast, which is how our system works today. Maybe there are some different things that we can do with that. But it’s very much evolving and I don’t think it’s really, really going to start—we’re just now working with all the producers about getting fully into producing for this new site, so I think we’re just at the start of that conversation, honestly.

Ethan:

One thing I’d like to hear a little bit about is the QA and testing process. It sounds like a lot of the design process was very much in-browser and trying to get things into people’s hands as quickly as possible. How did you actually talk about browser support when you were looking at this? What kinds of devices were able to access the responsive site? How were you actually testing them?

Scott:

I think the first thing I’d say is that when we’re designing in-browser, rather than leaving all the work of QA to the end, we are kind of testing things in a basic matrix as we go. So, for example, the templating library that we’re using has some tasks to use browser sync and we had multiple devices, in terms of hardware, kind of working and synchronized as we were building, so you kind of see how things look every time you make a code change. And then I think beyond that, we had a fuller browser matrix that required us to go back through and actually take a final pass, using BrowserStack in our case, to really test for other combinations of technology that we don’t have in the office. Surprisingly, that revealed very little. I mean, we cut off, for example, some IE support that would’ve been a real pain to shore up, but beyond that, the QA pass only took a half a sprint. We are still finding things that need correction and help, but I would say based on the beta rollout, there’s no huge barriers that we need to shift focus to immediately.

Tiffany:

Yeah, I would say the things that have been surfaced are fairly small. That’s what’s been great about the beta feedback form. We’re certainly asking people, “How are you accessing the site, and where are you encountering problems and where are you not?” and that certainly has escalated a couple of things. We have a lot of people in the building who are using the site in different browsers and on different devices, and so that is helping surface certain things. We’ll also plan to do a sweep when we get closer to actually getting out of beta and making this our full site so we’re not maintaining two sites anymore. I was actually just talking to the development team about this this morning, we’re working out what that might look like and whether we need extra resources. Because we’re trying to stay focused on this idea of, okay, the basic assumption is that the audio needs to be rock solid, and so we kind of are starting from there and moving outwards. So we’re seeing some little things in other browsers, like, “Oh, this logo isn’t sizing in the right way” or something in a version of Safari, let’s say. But it’s mostly things like that, which is great, as opposed to these big, huge things like, “Oh, the livestream doesn’t work in Firefox ever,” things like that.

Karen:

Let me follow up on that and just ask broadly, how do you measure the success of this redesign? Maybe one way to look at that might be what kind of data or analytics do you look at to decide when you’re going to take this out of beta?

Tiffany:

That’s a good question. I think there are a couple of different ways we do that and I would say that some of them are technical and some of them are more editorial or station goals. I think overall I would say—and Scott alluded to a little bit of this—this project I think has really helped us evolve as a digital team and a technical team. We’re up to three developers now, we were able to hire a new developer just in the last couple of months, and in terms of introducing agile development to the team, and really to the newsroom and to the station, has been a very interesting thing for me to watch and participate in. Even though we’re kind of modifying agile to fit us and our quirks, it’s been so helpful to start to introduce these concepts of, “No, we’re going to deploy every two weeks, and this beta is just the beginning, we’re now going to be able to develop things for producers all the time.” As opposed to in the past, where it’s kind of been we’ve built a site and then we’ve said, “Okay, now we’re going to move on to the other site and you guys need to stay in your lane and just work on your site,” and not be able to collaborate with everyone. So, that has been just a huge organizational shift, which has been great and I think it’s been really great for the technical team.

Getting much more organized with Trello… I think when Upstatement first had us start working in Trello I want to say back in the spring, it felt foreign to me, to be perfectly honest with you, and it just felt like, “Oh, how are we ever going to get so organized to manage all this in Trello? It’s crazy!” And now we couldn’t live without it, we couldn’t operate without it. So, staying organized that way, it’s been able to help us capture the imagination of other stakeholders in the building so that they can understand, “We have these cards, they represent hours of time, and look at this cube, look at how big it is, this is why it’s going to take four weeks, or two weeks, or three hours.” So that has been, for me, just a huge measure of success, even if we just said this is the end, so that was huge.

The other thing for us more broadly is audio consumption. One of our big goals is we wanted to increase digital audio consumption. We were finding that people were mostly reading on our site and consuming, which made sense because that was a lot of what we were providing, that was the better experience that we were providing. But so what we really wanted to do was create an ability for people to use this like an app, to be able to stream their podcast, organize their podcasts, find all of their audio, and help with the discovery of audio, which is kind of just a bigger problem across the internet. So that has kind of been how we measure the success. And then, of course, all the usual metrics of time on site… As a station, we have a couple of different ways that we are funded, but the huge one is our members. And so, we want to make an experience that is better for our members, but we had this huge digital audience that was coming to us that we don’t think was very connected to WBUR specifically. Sometimes we call it “drive-by traffic” or something like that, where people are just kind of coming into the site, reading an article, and bouncing out. And so we really wanted to use this platform as a way to say, okay, if we really want to get them to stay, if we really want to turn the site into much more of a conversion site where we’re making digital membership meaningful, how can we do that with design, with audio, and with the content that we’re already working? So those are kind of the metrics that we’re working on, but of course all the regular things are still standard. We want a bigger audience, longer time on site, and just a better experience for people.

I think the key is, frankly, starting a site today pretty much means you’re making a responsive website, I think that’s just what a website is today.

Ethan:

Well, I’ve got a hypothetical for the two of you. Let’s say there’s someone in our audience who is starting a responsive redesign today. What is one or two pieces of advice that you might share with them?

Scott:

I think it obviously depends on what your starting point is, and a redesign presumes you have something already. I think there are lots of cases where people are starting a project, like a new magazine we’re working on with Random House, they didn’t have anything to start with. I think the key is, frankly, starting a site today pretty much means you’re making a responsive website, I think that’s just what a website is today. I haven’t made a site that is not responsive in, I don’t know, five years or something like that.

When people used to say mobile first, I think it spoke to a kind of content strategy and content hierarchy in a way that desktop layouts mask by letting things exist side by side.

First and foremost, all the principles that I’m sure you guys have written about hold true. You probably need to start with the most simple view, and then once you have sort of a basic sense of your priority in a stack, I feel like then you can move on to other things. That’s been my interpretation. When people used to say mobile first, I think it spoke to a kind of content strategy and content hierarchy in a way that desktop layouts mask by letting things exist side by side. So I think the first thing that we ask people to do is prioritize the way content needs to be stacked, and that’s not just on a page, that’s kind of a top and bottom and side to side experience. Which page types, which clusters of content constitutes page types, which page types are the ones that are the most important? And the way that we usually get to this is, of course, through the process that we’ve touched on already, and defining user stories and looking at everything through user-centric goals. I think once you establish content priorities and interaction priorities based on user-centric goals, the work to make it work on different screens becomes much, much clearer.

It wasn’t much of a question about whether we had to go responsive, it was just kind a of thing that’s like, we know that this is a way to build a modern website for our users.

Tiffany:

Yes, absolutely. I think it’s knowing the different groups and the different stakeholders and the different people that are working on the project and knowing how they might work. So for example, making sure that at the top of every conversation we have with the content creators, that we talk about, “This is how much of our audience is already mobile, and you can talk to me about the desktop, I’m not saying that the desktop isn’t still important and it doesn’t still have many other uses, but start with the phone first and then we can work up from there,” I think has really helped capture their imagination. I think the other piece of advice I would have is it kind of depends on the makeup of your technical team. I just want to give a shoutout to our developers who have done work that I think should’ve been probably a team of twelve or fifteen to work on a project of this size, and they have really done extraordinary work over these last couple months to make that happen.

But I think to Scott’s point, it wasn’t much of a question about whether we had to go responsive, it was just kind a of thing that’s like, we know that this is a way to build a modern website for our users. I think my best advice would be just to make sure if you start with that premise and how you’re going to get that done, I think it’s easier than even having that for a question. It’s easy to say if most of our audience is coming to us in this way, I think it’s only important that we spend at least that much of our attention on the way that they’re accessing us and coming to us.

Karen:

Well, I really have to thank both of you for taking the time to speak with us today. I know so many people in the audience would appreciate hearing advice from people who have been through what you’ve been through, so thanks and I look forward to seeing more of what you guys come up with.

Tiffany:

Yeah, absolutely. It was great to talk to you.

Scott:

Yeah, thank you both.

Ethan:

Thanks to everyone for listening to this episode of a responsive web design podcast. 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.