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 I am so excited, I am emitting a high-pitched squeal that only dogs can hear. This week, we have NPR joining us and we’re here to talk to Scott Stroud and Patrick Cooper. Welcome.

Patrick:

Thank you.

Scott:

Glad to join you.

Ethan:

But before we dive in, I’d like to take a minute to mention our wonderful sponsor, Campaign Monitor. If you need an email newsletter you should absolutely check them out. Campaign Monitor features Canvas, which is their easy to use builder for creating wonderful email newsletters that look great everywhere, even on mobile devices. We’ve actually found here on the podcast that it’s very easy to create an email newsletter in just minutes. They have a great editor with some really decent drag and drop functionality, as well as some flexible, customizable starter designs that allow you to create these lovely looking emails that match your brand and your content. And the nice thing is, you don’t actually need a Campaign Monitor account to check out Canvas or their other offerings. You can actually just go to their website, campaignmonitor.com and start experimenting today. So thanks again, guys.

Karen:

What would be great is if you guys could just start out and tell us a little bit about what you do at NPR, what you’ve been working on. Patrick, why don’t you start?

Patrick:

Sure. I’m director of web engagement here in our digital media product division. So, I run agile teams redesigning the website, building new parts of our CMS, the various social, podcast, and newsletter projects, and generally work on some web and distributed strategies.

Scott:

And I am an interaction designer in the digital media design group, where I worked on the redesign of NPR.org, as well as our original NPR iPad app and other apps, and I do a lot of user testing.

We had a phone website, and a tablet website, and a desktop website, and we really only maintained the desktop website because we didn’t have enough resources to cover all those fronts. It just wasn’t a tenable situation.

Karen:

Fantastic. What I’d love to talk to you guys about first is just sort of broadly how the responsive redesign of NPR.org fits into your overall digital strategy. NPR, I think, is a fantastic case study of a product line that exists on a variety of different platforms—apps and a variety of different other touchpoints on which you can get NPR. Why did you decide to go to responsive? How do you make that decision?

Patrick:

The decision for us was out of need. We’re a large media organization but we’re a non-profit, and compared to other players in the media scene, we’re actually much smaller. We had done a lot of building in the first decade of the century around different product lines and different websites for different levels of consumption or different platforms. We had a phone website, and a tablet website, and a desktop website, and we really only maintained the desktop website because we didn’t have enough resources to cover all those fronts. It just wasn’t a tenable situation.

We’re always looking to serve as many people as possible and serve the public service that we see our mission as. Going ahead with responsive allowed us to expand from limited resources and hit that broad audience.

We had begun, in 2010—2011, to do various adaptive redesign experiments with our music live video pages, with a bit of the main news pages. Having such a legacy codebase, it really wasn’t efficient for us to work that way. Through a series of hackathon experiments, the whole division quickly got on board with responsive. In July 2012, we began a responsive redesign of the site as a whole.

That was really where the need came out of. We’re always looking to serve as many people as possible and serve the public service that we see our mission as. Going ahead with responsive allowed us to expand from limited resources and hit that broad audience.

We pretty quickly landed on the idea that people want great content wherever they are and they want our best wherever they are. We didn’t see much of a difference, in terms of our audience and how they were engaging with our content on different platforms and what kind of content they wanted. The splits just weren’t there.

Ethan:

One of the things that I know a lot of companies and organizations struggle with when they’re starting with a responsive redesign is that the needs of a mobile user are somehow distinct from traditional desktop users. I’d be curious, as you guys were sitting down to plan this big responsive redesign, was that a conversation you needed to have? Did you see them as distinct audiences with distinct needs? How did that inform things?

Patrick:

There was some discussion around that. I think we pretty quickly landed on the idea that people want great content wherever they are and they want our best wherever they are. We looked at the Google Analytics that we had and we didn’t see much of a difference, in terms of our audience and how they were engaging with our content on different platforms and what kind of content they wanted. The splits just weren’t there. It was more a question of “can we reach them at all?” With our Facebook audience really picking up in 2012, sending people to a mobile site was not an optimal experience, especially when the mobile site wasn’t displaying more than one photo, or it just had a very degraded design. So, just reaching people at all was part of the responsive push for us.

Scott:

We also understand that context is important. So, if you’re on a mobile device, we provide opportunities for reading, we provide opportunities for listening, we provide opportunities for watching video. The question with mobile is “What context is someone in? Are they standing in line at the store or something?” And therefore it may not be the best opportunity for them to listen unless they happen to have headphones with them. How does that impact user motivation and desire to do one of the actions that we make accessible?

So, really understanding, are they coming from social? Are they looking at a story page within an in-app browser, and how does that change what their likely interaction is? Certainly there were things like that that we’ve learned about through both looking at the data in terms of behavior, trying to understand where we see different behaviors, but also in doing user testing and really understanding motivation and context.

Making sure that we had a culture of defining the problem for each part of the site that we were converting and not to assume that it was the same problem that we may have had two years ago or three years ago during another redesign.

Karen:

You all have quite a bit of experience with planning and launching a variety of digital products. As you were planning this large-scale responsive redesign, how did you think differently? How did you scope the project differently? How did you plan for the work that needed to get done? How did it compare to perhaps the launch of a mobile website or some of the apps that you’ve launched?

Patrick:

That’s a good question. Maybe the best comparison might be our previous redesign in 2009. The biggest change from 2009 to 2012 was the introduction of agile and iterative developments within our division. Where in 2009—and Scott can talk more about this because he was here then—it was sort of a big bang release of the whole site at once, and the sponsorship and the data structures and a massive thing. With this, we started with our blog story pages, and gradually worked into the standard story pages on the site, and then to the homepage, and then to the section fronts, and just really took it two weeks at a time. That was one big difference there.

Scott:

I think one thing to recognize is with that more gradual and staged approach, we had to be comfortable with the inconsistencies and comfortable with imperfection, but also we were able to learn and adapt as we went along. I think our process also changed as we went through various stages of the project. So, one thing that I brought to the team was some past experience with Lean UX and really thinking about, given our limited time to accomplish work—for instance, the program pages or the music site, we didn’t have unlimited resources and unlimited time to make those things happen because we have so many other things to get done here—making sure that we had a culture of defining the problem for each part of the site that we were converting and not to assume that it was the same problem that we may have had two years ago or three years ago during another redesign.

Really establishing and articulating the problem and having the whole team involved with that, and then creating a culture of assumption-making and hypothesis generation, where we’re really able to have everyone put all of their assumptions on the table, sort through them, prioritize them, understand the ones that are the most risky and the most unknown, and really focusing our design efforts. Doing collaborative design sessions, having sketching sessions with the entire team, and then creating a cadence of prototyping things and doing user testing as often as possible within each of our design and development cycles.

The redesign is not just a redesign. At each stage, every two week cycle, offers an attempt to connect with the rest of the organization, to take them along in a way that we probably wouldn’t have done in the past.

Patrick:

To build on something Scott said there, he mentioned the entire team—I think we changed the conception of the entire team from maybe how we’ve worked in the past, where in our product group we’ve had a much closer relationship with sponsorship, with the research group around metrics, with editorial. Bringing members of these teams in to be subject matter experts on our teams from the beginning so that the iterative approaches, and all the approaches Scott mentioned, begins to permeate through the broader organization. So the redesign is not just a redesign. At each stage, every two week cycle, offers an attempt to connect with the rest of the organization, to take them along in a way that we probably wouldn’t have done in the past.

The channels between the developers and the designers are very open, where the conversation is really going throughout the day to talk about possibilities and intent, and to find the right balances or tradeoffs there. Those relationships have gotten a lot better where as they go along.

Ethan:

As you guys are developing this more iterative approach to design, designing assumptions and vetting them with more of an emphasis on prototyping, I’d be interested to hear a little bit more about the tools you’re using internally to talk about the design as it’s shaping up. Are you still producing comps? Are you moving right into prototyping? What are some of the tools in your toolbox?

Scott:

We’ve adapted to whatever the particular project is. I will say that we are doing more low fidelity sketching in order to illustrate concepts and get the entire team to contribute, and to provide feedback and critique on those concepts. We’re still doing things in comps occasionally; we’re certainly using tools like Sketch progressively to still have the design techniques.

I think ideally, in certain responsive projects, having designers who are also developers to design in the browser is really important to understand all of the nuances of the breakpoints, to get traction on the development early and to really turn those into prototypes. Those folks sometimes are unicorns, and we have some of them, but I also believe strongly in having folks on projects focused on a single skill, even if they have other skills. So, we’ve been doing a little bit of coding, a little bit of prototyping and code, but we’re still doing some traditional work as far as comps, and then using those comps and tools like InVision to prototype clickable prototypes.

Patrick:

Something that’s maybe happened beneath the visual layer of this is the communication underneath it. Where even in situations where we are doing comps, the channels between the developers and the designers are very open, where the conversation is really going throughout the day to talk about possibilities and intent, and to find the right balances or tradeoffs there. Those relationships have gotten a lot better where as they go along, they can decide whether a comp is the right way. We’re doing some revisions to our story page right now where we’re talking about “CSS redlining” and taking the older concept of working to the comps and redlining, and really have the designer do the CSS and bounce back and forth that way. So, it’s really different, but the communication has been a great boost to whatever the production method has been.

Scott:

Thanks Patrick, for bringing that up. When I talked about how we’re not doing as much coding in the browser, what I also wanted to say is, whereas ideally you might have one person who’s designing in the browser, we have begun to work more closely with the front end developers so that that’s happening; it’s almost like a pair design/programming exercise with more than one person.

Getting the data in front of people really provided some value to that, where they were eager for it. They wanted to know what was working and what wasn’t. The act of redesign provided editorial an opportunity to think on their own, about what was worth it for what numbers.

Karen:

Can you talk about how the content may have changed or evolved as part of this redesign process? For example, sometimes we’ll talk to publishers that will say the actual substance or structure of what they’re publishing also changes, where they change the styles that they have, add different quotes, or different chart types, or really just change the types of things that their editors are working with. Can you talk about if that happened at all?

Patrick:

That actually happened a bunch for us. We are definitely not believers in editorial change being a requirement of product change, that if it’s built in quickly it leads to scope creep, but we have enjoyed viewing each stage here as an opportunity to review what we’re doing content-wise and provide the conversation to change it.

When we began redesigning the story pages, the very first step, it was a really valuable exercise for a number of people in our newsroom, for us to say, “here are the content elements you have right now,” and then draw a phone on a whiteboard and say, “okay, order these elements, stack them vertically, and talk to us about importance.” For as much as people had phones in their pockets and saw them as part of their lives, they had really been thinking of the audience in a desktop manner. As we worked through the things that were necessary to go responsive, they were in on that. They were thinking about what is really important to us.

We really had a wide open publishing system. But it was almost too broad, where it was creating so many configurations that once we multiplied that times breakpoints, things got really tough real fast.

We used it as an opportunity to bring out the metrics. One of the first things we did was put GA [Google Analytics] events really all over our story pages to see who’s clicking where. Because people had been producing pages in ways largely because they’d always produced pages in that way. But getting the data in front of people really provided some value to that, where they were eager for it. They wanted to know what was working and what wasn’t. The act of redesign provided editorial an opportunity to think on their own, about what was worth it for what numbers.

The other thing we did was look at the metrics in the database. We really had a wide open publishing system—which was great, and one of the big wins of the 2009 work. But it was almost too broad, where it was creating so many configurations that once we multiplied that times breakpoints, things got really tough real fast. So we were able to study the database of who had placed what, where throughout these hundreds of thousands of stories, and come up pretty quickly with some numbers on, oh, these are the methods we use all the time. These methods we built in 2009 and we never used. You can bring that back to editorial and say, “which of these methods are valuable? Here’s how often you’ve used them.” We ended up with, on the design level, a much more minimalist design, more focused on the content.

But when you look inside the content, you also find a more minimalist approach there. People really thinking, What photos are valuable? What links are valuable? How do we tell a story? That kind of change came out of this in a way where we didn’t force it, but looked for those opportunities along the way.

This project has also given us the chance to really think about our products in general, and not just thinking about the website, or the mobile site, but also thinking about our overall digital products. The product is companionship. How do we become a better companion to people?

Scott:

This project has also given us the chance to really think about our products in general, and not just thinking about the website, or the mobile site, but also thinking about our overall digital products. The product is companionship. How do we become a better companion to people?

With the music site redesign, we introduced a new concept called “Songs We Love” which came out of really understanding and studying what people value. We had some surveys that were starting to reveal this. We had user interviews. We crafted a new editorial feature that really emerged from the design. The design elements that emerged were showing thumbnails of the contributors, whether they were NPR music staff here making music recommendations, or whether they were folks, DJs at our stations who were recommending songs, and saying why they liked them, and why you should be interested. So like I said, the design emerged, and the feature itself, the editorial feature emerged. Working very closely with NPR Music on the editorial side to define that product, and making sure that that product conveyed the closeness and the intimacy that public radio is all about.

As we streamlined the designs we looked a lot at how we can streamline the tools to make choices much clearer, to push people towards the most valuable choices.

Karen:

What about your content management system? So NPR has sort of a famous case study of using your CMS to do adaptive content. Has that changed at all? Did you make changes to the CMS, or do you still use adaptive techniques even going into the responsive design?

Patrick:

There have been some changes. Not a ton. The separation between content and presentational system, when we came in to this, was so strong, that the biggest changes have been around, like I mentioned, the minimalizing of the design a bit. As we streamlined the designs we looked a lot at how we can streamline the tools to make choices much clearer, to push people towards the most valuable choices. We ripped out our preview tab entirely; we often hear people grappling with “well, how do you do responsive preview inside a CMS?” Our answer to that was “just pop up a browser.”

We’re getting better and better at understanding how to trigger user actions. We’ve reused some elements in the CMS that allow us to do that, so that editors can craft the language. They’re starting to understand how their work needs to influence the design.

You don’t get everything that you’re going to get on a phone when you size it down to the smaller size, but we pop up a window at around tablet size and tell people to drag the window in and out, the usual responsive trick, and just review how it looks. Like I said, this doesn’t give you perfect fidelity, but it certainly takes you a long way towards getting in the editors’ heads and thinking about how this is going to look on their phones. So, that’s been a big difference for us.

Scott:

We’ve also introduced some new design elements. We’re getting better and better at understanding how to trigger user actions, and those opportunities for action have started to come out as things like, call-to-action buttons that say “Watch the video” or “Listen to this piece by so-and-so.” So a more personal approach to language and a visual affordance to click on something.

Any website is a huge part of a news organization’s product line, but if you have a handle on what’s there, it becomes a lot easier to see the other platforms around it and to make decisions for the CMS that help not just the site but the news app, and the music app, NPR One and those sorts of things.

We’ve reused some elements in the CMS that allow us to do that, so that editors can craft the language. They’re also starting to understand the need to reveal what’s available with the story, because sometimes there are multiple things you can do—you can look at a slideshow, you can listen to the audio, or watch the video. They’re starting to understand how their work needs to influence the design.

Patrick :

Karen, to your point around different platforms and CMS being fueled by this “Create Once, Publish Everywhere” mantra, I think the redesign has allowed us to inventory what we have within the site, whether it’s in removing pieces, like I mentioned, or adding pieces, like Scott mentioned, and truly understand what’s there, in a way. Any website is a huge part of a news organization’s product line, but if you have a handle on what’s there, it becomes a lot easier to see the other platforms around it and to make decisions for the CMS that help not just the site but the news app, and the music app, NPR One and those sorts of things.

Through our methods of getting the entire team involved and the assumption-making and the hypothesis generation early, we feel like we’ve had to do less change and we have less uncertainty about whether or not our designs are going to solve the problem.

Ethan:

I’d love to hear a little bit about how design reviews are conducted and managed at NPR. I’m thinking primarily about the other parts of the organization—are people expecting to review comps, are they comfortable looking at mockups or prototypes, and has that changed since you guys have been doing more multi-device work?

Scott:

We have certainly changed our process, meaning that we’ve asked people to look at things on their phone as opposed to reviewing a mobile design on a desktop. It makes a big difference.

We have reviews both internally within the project team, so the project team being made up of a scrum master, designers, sometimes also an interaction designer and a visual designer, sponsorship in some cases, subject matter experts, editorial in some cases, product management, as well as the engineering team. So, there’s sort of a review that happens there at various stages, given that those folks are the ones involved in sketching the initial ideas to solve the problem. Then we have our design group who meets weekly to review designs, and also meets as needed, so they also give feedback in the various forms.

We’ve experimented with using tools like InVision to do commenting inline in the designs. We haven’t used it consistently and we’re still experimenting with how best to gather feedback. Of course user testing sort of provides another layer of feedback to take back and iterate. I think that through our methods of getting the entire team involved and the assumption-making and the hypothesis generation early, we feel like we’ve had to do less change and we have less uncertainty about whether or not our designs are going to solve the problem. In the case, for instance, of when we launched the desktop homepage, we launched that homepage about a month earlier than we expected to because of the coordinated and collaborative design effort.

One of the great things about working at NPR is the upper management really putting their trust in the folks who are building these products and trusting the team nature of that experience to emerge with the right answers.

Patrick:

The one other group I’d throw in there, the folks that Scott mentioned, the product team, the design team, there are a lot of front line people there who are hands-on with this. We also have our stakeholders, the upper managerial slash executive layers.

Like I said, we go agile and we’re iterative and we demo every two weeks, and we take our demos very seriously. It’s usually an hour and a half devoted to this, where the first half hour is maybe presentation and the next half hour or two are questions and discussion.

If there are big curves that we’re taking, we’re just always communicating day-to-day up the chain of what’s going on. But that’s one of the great things about working at NPR is the upper management really putting their trust in the folks who are building these products and trusting the team nature of that experience to emerge with the right answers. There’s certainly adjustments from above and direction given on information sharing that they have, but we’re really not a place where every design needs to go up and be seen by twelve executives. We’re presenting every two weeks, taking the turns and taking the feedback and pushing forward. But it’s nice to have management that trusts the team and trusts the team to emerge with the right answers.

Scott:

Sometimes we expect to go to one of those stakeholder reviews, which happens at or near the end of every cycle, with either comps or a clickable prototype with flat pages. But we’ve involved the developers so closely that I’ve been surprised at times where we actually have on our staging servers a working version of what we had designed. Sometimes we have to go back and change things because it was a little too soon, but it varies depending on the cycle.

Getting down to those micro levels and letting us see the really tight effects of the change has been the most valuable thing for us.

Karen:

How do you know if this responsive redesign is working for you? How do you measure the success of your new responsive design as compared to the old design or compared to any of the other platforms that you’re on?

Patrick:

I mentioned earlier the GA events we put all over our site before we began the redesign. We still have all of those in place. We have members of our research team join the team when there’s huge amounts of data to go through, but it’s something the team looks at on a regular basis.

For each stage of this project, before we launched, we’ve given projections on how we think the numbers will change. Even the situations where we’ve never done something before; we always will put out a number just so it forces that conversation and forces us to learn and research what we don’t know.

We’ve looked a lot at the different types of audiences. At the end of the month, there’s the big rollout numbers that you can send up to the executives, and that’s great—total uniques and page views and sessions. I’d say we pay a lot more attention to the more micro numbers, of pages per visit of people coming through the homepage, in terms of thinking about “what can a homepage redesign actually affect?”

Or for story pages, “what was the average visit duration off of that?” We iterated those pages. If we changed the “You might like more stories from this” feature on the site, what were the click events before and what were the click events after? Getting down to those micro levels and letting us see the really tight effects of the change has been the most valuable thing for us. Where that, combined with the user testing, usually pretty quickly gives us an idea of how things are faring.

When you look at public media and reaching the public at large, you can’t just serve part of the public. You have to go with as big as an audience as possible and reach people.

Ethan:

Just to follow up with that idea of measurement, one of the things that’s been entering into the conversation about responsive design in general over the last year or two is this idea of performance. It’s great if it’s flexible and if it fits on different screens, but there also needs to be that speed behind it as well. Is performance something that has entered into the design process or any part of the conversation at NPR? Is it something you guys are currently focused on or thinking about?

Patrick:

Absolutely, speed is a feature. Especially for us, when you look at public media and reaching the public at large, you can’t just serve part of the public. You have to go with as big as an audience as possible and reach people.

Before each launch, in the mid-to-later cycles, our developers will begin performance testing using a variety of techniques, YSlow, et cetera, and comparing that to performance on the site as a whole for redesigning a piece, and we get various other numbers back from the servers and that sort of thing.

But honestly, one of the things the team has been proudest of is the speed. Around images on the site, we’ve invested a lot and refactored several times how we render images on these pages, so that we’re minimizing the editorial effort but also always loading an image that is the right size for that device, both in terms of the size of the browser and the size of the performance hit. That’s been really big for us.

We’ve seen our speeds up there with Google News, Google Finance, at the top of the news and information speed charts. We had a cake when that happened because it’s something that everyone here cares about. It’s not just a sysadmin or engineer thing. Everybody is thinking about speed.

Scott:

Where are we with the numbers? Do you want to talk a little bit about that?

Patrick:

Yeah. This is something where I’d have to go look up the source but we’ve seen our speeds up there with Google News, Google Finance, at the top of the news and information speed charts—which I believe come out of Gomez, but I’d have to check that. We had a cake when that happened because it’s something that everyone here cares about. It’s not just a sysadmin or engineer thing. Everybody is thinking about speed.

We spent the first month of our project playing with different grid systems. It allowed everybody around the team, whether they’re stakeholders, editorial users, whatever, to understand that you’re not talking about a standard design here, you’re talking about a framework and you’re talking about a flexible structure.

Ethan:

Cake First web design, I’m a big fan. As we wrap this up, I’d love to hear if you guys have any advice for anybody who might be listening about things they should start thinking about as they’re doing more responsive work.

Patrick:

I’ll throw out there the need to experiment early on. We spent the first month of our project playing with different grid systems and showing the undesigned grid systems to our stakeholders. It allowed the team to learn a lot and it allowed everybody around the team, whether they’re stakeholders, editorial users, whatever, to understand that you’re not talking about a standard design here, you’re talking about a framework and you’re talking about a flexible structure.

In our responsive design world, we know that’s the way we live, that’s how things are. But there are so many people at media organizations—whether they’re legacy media organizations with their ideas of how the site works and what it means to them, or they’re startups where they want to create something very different and do something very different in the design—and putting the focus on how this thing has to hold together I think is valuable for everybody involved, and understanding the challenges with either transitioning legacy or building something new and unique.

I think that type of experimentation, having that early and having everyone not arguing about things is really important.

Scott:

I’d say developing a culture of assumptions where it really sets the stage for how the team will work together. So, fewer arguments, more “it’s okay to have an assumption that’s counter to another assumption and the team will work through that.”

Some of those assumptions may come from good competitive analysis, looking at other responsive sites and how they’ve dealt with certain issues, being able to understand how certain patterns apply to your situation and your problem, or don’t. I think that type of experimentation, having that early and having everyone not arguing about things is really important.

The value of involving your advertising people, having them involved from day one of the redesign and thinking about what their needs are, and how you can design to help the users, to help the organization, to help business altogether, that’s been critical.

Patrick:

Building on that, the value of involving your advertising people, for us, we call it underwriting or sponsorship and it acts a little bit differently. Having them involved from day one of the redesign and thinking about what their needs are, and how you can design to help the users, to help the organization, to help business altogether, that’s been critical. Because it’s business and advertising and banner ads and what not, they’re a really complicated area. The way we’ve gone is by getting people in a room and coming up with solutions that are good for us.

One other thing I throw in is the old “perfect is the enemy of good” is never more true with web design than with responsive design. I mentioned the changes to our story page we’re working on this month. Some of these things we wanted to do right after we launched two years ago, but we had to move on to other things, we had to move the ball forward and had to push on with the system as a whole. Developing a culture where you can continue to release and come back to things, and revisit and get away from the “one perfect redesign,” is a lot healthier for the organization and healthier for the people in the organization to build in good, sustainable ways.

Scott:

We’ve had some patterns grow organically and things that have maybe gotten a little too complex or inconsistent, and so being able to go through and groom the patterns and simplify over time is really important. Scheduling that type of iteration into the project—as well as not being a culture of acceptance that those things are naturally going to be there and it’s okay—continue to look out for them and improve and lower the number of disparate patterns that you have along the way. Definitely leave time to go back and, as you’re developing new things and discovering more simplicity, having some flexibility to take that simplicity and apply it to some things that you may have created earlier.

Ethan:

Well, I have to say, Patrick, Scott, this has been a really wonderful half hour and I can’t thank you guys enough for coming online and sharing a couple stories with us.

Patrick:

Thank you for having us.

Scott:

Thank you.

Karen:

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

We’re really excited to announce that we’re offering public workshops on responsive design, taking place on March 06 in Boston, and on April 2-3 in New York City. If you’re interested in attending, visit responsivewebdesign.com and register for a ticket today!

And 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. If you’re interested in bringing us to your company, please go to responsivewebdesign.com and let us know that you’re interested.

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.

Thanks again to our sponsor, Campaign Monitor. Be sure to visit campaignmonitor.com and check out their email editor, Canvas. Thanks for listening, and we’ll be back next week.