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 just doing somersaults of joy because we couldn’t be more excited to speak with Kim Conger, who’s from Radio Free Europe/Radio Liberty, and Dan Mall from SuperFriendly. Dan, Kim, thanks so much for joining us today. We’re really excited you’re here.

Dan:

Me too.

Kim:

Thank you.

Ethan:

Dan, Kim, why don’t you guys introduce yourselves briefly and just tell us a little bit about responsive design at RFE/RL?

Kim:

My name is Kim Conger and I’m the design director and deputy director of Pangea Digital. We are a small design and development team housed within Radio Free Europe. We support all of US international broadcasting entities as far as the back-end CMS, content management system, as well as all the front-end sites. We also develop applications, such as Smart TV, news applications, a live video streaming device, and we’re currently developing a media asset management system. So we do a little bit of everything.

And as far as responsive design goes, it was, in our respect, a no-brainer because not only do we build the CMS and design the front-end sites, we were supporting a desktop codebase, mobile codebase, and then building upon responsive—so, three codebases at once for the past two years. So we’re more than eager to get off our mobile site in February. So right now, we’re just supporting two codebases, the desktop codebase and the responsive mobile codebase, and we hope to get off of desktop in about six months.

Ethan:

That’s great. So, Dan was the one who actually reached out to me about potentially doing this interview because I’d read his initial write-up about starting the project with RFE/RL and hadn’t really sort of been keeping tabs on the project until he mentioned that the mobile-only responsive site had launched at RFERL.mobi, I think. So Dan, maybe you could tell us a little bit about your role in the redesign and sort of how you got involved.

Dan:

Yeah, happy to. So, I’m Dan Mall, I’m the founder and the director of a small design collaborative out of Philadelphia called SuperFriendly, and I got kind of a cold note from Kim a couple years ago, I guess this is early 2014, that said, “We’d love you to help us figure out how to make this move to responsive.” So, I was more than eager to help do that, and meeting with their team, we flew to Prague and had a really great kickoff with the team there, and just was really impressed at how smart everybody is there and all the great work that they’re doing.

Ethan:

That’s fantastic. I’m really excited to hear more about the project.

Karen:

But before we get started, I’d like to say a few words about our sponsor, Harvest. I have to make a confession: I hate, hate, hate tracking my time. It always makes me feel like Fred Flintstone chiseling out his time boulder before he slides down that dinosaur’s back so he can go home. But using Harvest doesn’t feel like punching a time clock. Harvest is a beautifully designed tool that lets you track your time on client projects, start a timer from a web browser or mobile device, and it even lets you send invoices when your time tracking is complete. If you’re a responsible business professional you should be keeping tabs on which clients and projects are making you money—and the way to do that is through careful time management using Harvest. So check out Harvest today. Go to getharvest.com and start tracking your time. They’ll give you a thirty day free trial. When that’s up, enter the code RESPONSIVE at checkout and you’ll save 50% on your first month. Don’t hate tracking your time. Get Harvest.

Ethan:

Maybe tell me a little bit more about those early days, like around the kickoff or maybe some of the initial conversations. Because, specifically, I think Karen and I like to hear if when an organization is deciding to go responsive—Kim, as you said, there’s obviously some real technical benefits in terms of cost and maintenance—but sometimes concerns and questions come up, like about responsive design as a methodology. I’d be interested to hear if there were any sort of murmurings about what it was going to mean to go responsive back in those early days.

Editors have to publish in desktop and mobile, so basically using two publishing platforms. With responsive, you only have to publish once.

Dan:

Kim, you want to take that?

Kim:

Sure. From our point of view, it was an obvious choice. Luckily senior management here, once we explained to them exactly what responsive was. Because editors have to publish in desktop and mobile, so basically using two—still within Pangea—but two publishing platforms. With responsive, you only have to publish once. So, it cut down quite a bit on the cost involved as far as the labor standpoint, and a development standpoint, where we didn’t have to support so many codebases. Luckily we didn’t really have a hard sell here at all. If anything, people were in a mad rush for us to develop it, in addition to all the other things that we’re juggling.

This is just one of the projects that we’re doing and I wish we had more resources focused on it or we would’ve launched the site early. We only have seven people working on responsive, that’s it, within our team. Like I said, we have ninety-five websites, sixty languages, and six front-end brands, so six different CSS styles. It’s a lot to juggle, and it’s right-to-left language and left-to-right, so it’s a lot.

Folks have come around to realize that it’s basically device-agnostic, where people want the same content on any device anywhere. It doesn’t really matter if it’s mobile, tablet, desktop.

Karen:

Can you speak to, from a user perspective, how do you talk about the difference between what a mobile user and what a desktop user might need? Particularly in that you started out with a separate mobile website, is there a sense within the organization that mobile users and desktop users are coming with different goals or they want different things from the website?

Kim:

Originally that was something that was up for discussion within the editorial team. They were thinking along the lines that users want a different experience early on, say two years ago, maybe a year ago even. But now since we’ve launched mobile-responsive and they see how the site responds upon expansion and the whole logic behind it, and plus I think they’ve educated themselves looking at other websites and how people use mobile versus desktop in real life, I think folks have come around to realize that it’s basically device-agnostic, where people want the same content on any device anywhere. It doesn’t really matter if it’s mobile, tablet, desktop, it’s just a matter of what the device supports.

Ethan:

Sounds like a solid approach. Dan, I’d like to hear a little bit more about when you started to get involved, because I know you do a significant amount of responsive work at SuperFriendly. How did you actually work with RFE/RL to actually scope this project? What kind of conversations were you having back then about the size of this given the number of websites they’re maintaining? And if you could just talk a little bit generally about how you actually got your arms around the size of this project, I’d love to hear about it.

The scope of this project is to really help us think about the different types of patterns that we were going to use and the different types of components that we would need.

Dan:

Yeah, absolutely. I think it was a pretty fascinating conversation that I had with Kim initially. From an agency side, it’s always tricky when a client comes to you and says, “Here’s all we need done,” and you’re like, “Well, I’m not sure.” So the initial conversation that Kim and I had, Kim was just saying, “We have a really great team here when it comes to the development side. We just really need some help and some outside perspective thinking about what we could do for a wider audience as we get more responsive.” So, how do we take all these things and bring them together and serve all the different users, regardless of whatever device they’re using?

One of the things that we found out really quickly was she was actually telling the truth about that stuff: they have a really amazing and smart development team at RFE/RL, both front-end and back-end, and they were doing really amazing things when it comes to performance and caching and the things that they were working with, as well as how to actually serve it from a content management standpoint.

Really, the project was—Kim had the scope nailed down from the initial email, which is very rare and I wish more clients had. But she basically said, “The scope of this project is to really help us think about the different types of patterns that we were going to use and the different types of components that we would need to be able to do the type of publishing that we wanted to do, that we haven’t been able to do in doing this mobile/desktop responsive approach.” So, now moving it all to responsive, how could we create a cohesive set of patterns that would apply everywhere, that are really smart and really well-thought through so that they work in every instance?

Kim:

Yeah, that was one thing that Dan really brought to the table, along with Tim Kadlec: the Pattern Lab library. And we were sort of building our own Pattern Lab library, we didn’t know it at the time. But when Dan came on board, he presented this tool to us that was really invaluable. So we basically trashed our in-house Pattern Lab and developed on .NET code, because I believe Pattern Lab was only, what was it Dan?

Where before we were doing PSD, Photoshop mock-ups, PNGs, and now everything is via Pattern Lab, so we can iterate very, very quickly.

Dan:

PHP.

Kim:

PHP, yes. So, that’s been invaluable to us and that’s really changed the way that we design, where before we were doing PSD, Photoshop mock-ups, PNGs, and now everything is via Pattern Lab, so we can iterate very, very quickly, whereas in the past we couldn’t, and it’s really sped up our process and it has done great things for us.

And the other thing that they brought on board was performance. That’s something that is really, really important to our users. But luckily, our mobile site, it was pretty quick as well because it loaded under three seconds, and our mobile-responsive also has great performance thanks to what Dan and Tim brought to the table.

As far as our strategy goes, we wanted to have feature parity with, at the time, the current mobile site.

Karen:

Let me ask about how you planned the rollout of this responsive redesign. I’m always fascinated by how different companies approach this problem. Some of them do one big bang, sometimes they launch a beta, sometimes they do it section by section. And so you’re starting with rolling out the responsive design just to mobile devices and then eventually that will overtake the desktop. Can you talk about how you planned that rollout and how you came to the decision to do it that way?

Kim:

Sure. Well, how we went about doing it is it was basically by language services. We started with RFE and services that the mobile sites really didn’t matter as much, where the numbers really weren’t as crucial, and as well as another website language service where they were very savvy, from a technical point of view. They were great partners with us, so it worked out that way. Then after we rolled out three RFE sites, we rolled out three VOA sites. And then after that, after we got the initial rollout done, then we just kept going with other language services.

As far as our strategy goes, we wanted to have feature parity with, at the time, the current mobile site. We had X amount of features on mobile, we wanted to make sure that the same features were available on mobile-responsive that were on mobile so that the users didn’t lose anything, per se. Once we had feature parity, that’s when we really started to roll out all the websites and we did it over a period of about four months, from February to July.

Now we’re pausing, we’re catching up on the back-end as far as all the services, like API, MRSS feeds that desktop supports, so we can’t get rid of desktop right now. But once we have those back-end services finished, that’s when we’ll, again, roll out with websites that are… And believe it or not, services are lining up, they can’t wait to get on full responsive. They’re like, “Why can’t we? Can’t we just redirect to our responsive site?” If you look at it on a computer, you can see that basically a lot of it is already there, it’s just the back-end support services aren’t there. We’re like, “No, we’re sorry, it’ll take us another two or three months for the back-end functionality to catch up, and then we’ll start rolling out full responsive websites starting, we’re estimating, in January.”

We didn’t decide we were going to do comps or we were going to code in a browser. We just kind of tried to listen as much as we could.

Ethan:

Wow, that’s coming right up. That’s great. Dan, here’s a question for you. One of the reasons I’ve been so excited to hear more about this project is you’ve been somebody who’s been pretty vocal about how you think about the design process for thinking about the web. You had that great phrase a couple years ago, “It’s not about designing in browsers, it’s about deciding in the browsers.” So, I’d love to hear a little bit more about how you structured the design process for RFE/RL. How heavily were you relying on something like Pattern Lab to have some of those initial creative discussions? Tell me a little bit about how you started to talk about the look of the site.

Dan:

Yeah, absolutely. One of the things that I try to do in the start of every project is not be too prescriptive about deliverables until we find out more. I mean, Kim and I had great conversations leading up to figuring out what the scope of work is, signing a contract together, and really getting down to work in earnest, but even that wasn’t enough to inform what the design process was like.

So, we were pretty open until going to the kickoff meeting, and when we went to the kickoff meeting, we spent two days with the RFE/RL team and the Pangea team there and we just learned about everything that they’re doing. It was a series of workshops, conversations, exercises, and presentations. We presented to them just as much as they presented to us. I think, if I remember correctly, one of the presentations that one of their developers presented to our team was called “Smash the Web,” and it was just about all the great things that they were doing from a back-end perspective and front-end perspective and how they’d been treating design. So we were really pretty open as to what we were going to do first. We didn’t decide we were going to do comps or we were going to code in a browser. We just kind of tried to listen as much as we could and then figure out what the right sequence was from there.

I’m looking back at our project hub now, and the two first deliverables that we did when we got back wasn’t design, it was IA, it wasn’t anything sort of traditional. The first deliverable was we actually made a Pattern Lab spreadsheet. So one thing that we took a lot of time to talk about at the kickoff meeting was this pattern-based approach. And we had used Pattern Lab, it was developed by Brad Frost, we’d worked on that on a couple of projects, and RFE/RL’s team had their own version of Pattern Lab, and so we decided to merge those two things together. And we used Pattern Lab as the methodology, as the kind of metaphor for all of this using atoms, molecules, and organisms, and we changed templates to presets. I can talk about that a little bit later as to why we did that. But we used sort of this pattern-based methodology and this metaphor.

We actually ended up making a group glossary for our project. “This is the definition for an atom, this is the definition for a molecule,” so we all knew how to think about those things.

And so we were all on the same page about that, and the way that we did most of our work on that is we actually did all of the work in a Google spreadsheet. So we did probably maybe a week or two’s worth of work of discussions on each cell. So we’d make four sheets in the spreadsheet—atoms, molecules, organisms, and presets—and then we’d list out, “Here are all the atoms that we envision designing for the site; here are all the molecules, here are all the organisms,” and then we’d have in-line comments in the Google Doc. I mean, it sounds awful but it was actually really, really great to do this. We sorted out all of the problems in the spreadsheet itself. So we would have discussions like, “Well, is this a molecule or is this an organism? And what’s our definition for this, and how are we going to talk about or think about this?” and we actually ended up making a group glossary for our project. “This is the definition for an atom, this is the definition for a molecule,” so we all knew how to think about those things.

Very early on before we did any design, or IA, or any of that stuff, we made a performance budget spreadsheet.

So we did that, that was one of the first deliverables that we sent over just maybe a day or two after we kicked off, after we got back. And the second very close behind was a performance budget. So Tim Kadlec, who was a developer on the project, he made a really thorough performance budget that analyzed RFE/RL’s site, mobile site, and then a couple of other new sites that we were sort of admiring and looking up to, and really benchmarking what performance we wanted to target so that that could inform our design process. Very early on before we did any design, or IA, or any of that stuff, we made a performance budget spreadsheet and a Pattern Lab spreadsheet.

And then once we had that done, we basically moved into working and thinking about the art direction. So we did a couple rounds of element collages, and I think those went over okay. So we showed some of the element collages to Kim and team, and the general feedback was kind of like, “Yeah, this looks like it’s in the ballpark, but we’re not exactly sure what this is or how it works.” So very quickly we moved from element collages into designing just patterns and designing the patterns individually. So we’d take a handful of those atoms and just kind of illustrate those, and we’d take a handful of the molecules and the organisms and we’d illustrate those, and then we did a couple of examples of, “Here’s what they look like put together.” So we did a couple of homepage variations that showed, “Okay, here’s what it looks like if you have this element vs. this element, here’s what it looks like if you move this or move the sequencing on the page,” and we really kind of worked through how these things would be put together because we thought that that would be the best way to simulate what the RFE/RL team would be doing once we were finished with this project.

RFE/RL serves a ton of different sites across a lot of languages and a lot of countries, and in a lot of those countries it’s actually illegal to access some of this news.

Ethan:

One thing both you and Kim have mentioned a couple times is one of my favorite words, which is performance. So I’d love to hear a little bit more about how that performance budget was actually used as a design tool, which is something a lot of organizations struggle with, I think. It’s too often seen of performance as this thing that gets fixed by the implementers or the production team, and it seems like, especially given how broad and internationally-focused RFE/RL’s audience is, you guys really had to start thinking about this from the outset. So, either one of you guys, if you could tell me a little bit more about how you came up with that performance budget, what the process was, and how, if at all, it was referenced during the redesign process, I’d just love to hear a little bit more about that.

Dan:

Kim, can I start that one and then you follow up?

Kim:

Sure.

We knew that we couldn’t have sites loading in ten seconds, twelve seconds, twenty seconds, thirty seconds; performance was literally a matter of life or death for a lot of the users.

Dan:

So, one of the things that we heard at the kickoff—I think in every project that we do that’s web-related, it’s always like, “Yes, performance is important. Yeah, yeah, yeah, it’s important; it’s important to everybody.” But for this project in particular, it was of such dire importance. One of the things that we learned on that first day together was that RFE/RL serves a ton of different sites across a lot of languages and a lot of countries, and in a lot of those countries it’s actually illegal to access some of this news. So they told us stories about people that have been jailed or hanged for just accessing news like this, and so people would illegally cross country borders to be able to get a 2G cellular connection just to pull up a site.

The whole process needed to be rooted in performance and it couldn’t just be an afterthought.

We knew that we couldn’t have sites loading in ten seconds, twelve seconds, twenty seconds, thirty seconds; performance was literally a matter of life or death for a lot of the users, a lot of the readers of this site and sites like it. So we knew that that was one thing that the whole design and development, the whole process needed to be rooted in performance and it couldn’t just be an afterthought. Kim, maybe you could talk a little bit more about how that influenced everything.

That was number one: performance. If a site doesn’t load, it’s worthless.

Kim:

Yeah, that was key for us. That was number one: performance. We focused also on our plain mobile site. If a site doesn’t load, it’s worthless. So, we wanted to make sure, and that was the main reason why we brought Dan and Tim on board, was to consult with us to make sure that we were doing everything possible to shave off every kilobyte off the code. And their input was invaluable, and the site does load under three seconds, it’s quite fast, and we’re happy with it.

Dan:

I can talk a little bit about the implementation of that performance budget, Ethan, if you think that’s helpful.

Ethan:

Oh, I think that’d be very helpful, Dan.

Dan:

[laughs] Okay, cool. So, the way that we went about creating that performance budget is we just made a Google Doc and we use a tool called WebPagetest, which is a free service, it’s awesome, and just about every project I do now I run performance budgets all the time just to make sure that the site that we’re making as we’re building it is as performant as we want it to be. So basically what we did was we recorded a couple different times. We recorded Speed Index that WebPageTest reports, we recorded the start render time, the visually complete time, and the fully loaded time. And we just inventoried I would say about somewhere between fifteen and twenty sites, and we recorded all of the times for each of those sites—the Speed Index, the start render, the visually complete, and the fully loaded.

What could we do to shave off twenty percent off of their current mobile site’s times? That’s what we used as our target times.

Now Tim, who was a developer on the project, he found this really great stat that people perceive things as faster or slower when there’s at least a twenty percent time difference. So, what we actually found in this inventory was of all of the sites that we inventoried, RFE/RL’s mobile site was actually the fastest, it was actually already better than all the other sites. So we could’ve kind of stopped there, but instead we decided that we were just going to try and make it even faster.

What could we do to shave off twenty percent off of their current mobile site’s times? That’s what we used as our target times. We basically got those down to, I think the start render time that we had was something like 2.9 seconds, if we could hit that, and the visually complete time was something like 6.1 seconds. So, something in that range. And basically we could take those things and transfer them to kilobyte weights, and we could say, “Okay, 2.9 seconds for a start render given a certain connection speed is equal to 300kb.” So if we wanted the homepage or a page to load within those amount of seconds, we could say, “Okay, we’ve got 300kb to play with. That means one webfont and two images,” really translating that into design considerations and design requirements before even getting into Photoshop or in the browser so that we could kind of target patterns to that performance budget.

So what Tim did from there is Tim actually created a Grunt task that measured, in Pattern Lab, the performance of each element on an element level. So you could say, “This H1 loads in this many milliseconds,” and then as we put them together, measure the performance of each organism and template and preset and page. And he actually set up—I think he open sourced the Grunt task, it’s called Grunt Performance Budget. You can actually set it up to not even build if you’ve blown your budget. So it’s a really great tool and we used that a lot as we were designing and building this.

Karen:

I’m really interested in how these pattern-driven sites intersect with the underlying content. Can you talk a little bit about the approach that you took to managing the content and publishing the content? Like, did you model the content on the back-end and did that change the way you thought about your CMS?

Kim:

You mean like a preview? Like on the back-end, so our users can see a preview of how the page will render on various devices?

As we have gone through moving sites from mobile to mobile-responsive, we’ve merged and cut some widgets in the back-end.

Karen:

No, I guess I mean a little bit more like did you define an approach to how you were managing the content? Did you define content types and a structure for that content? Did that change how you built your publishing system so that the underlying content structure and the design patterns were integrated?

Kim:

In Pangea we have a whole library of widgets, like content types. Those were replicated in mobile and then redesigned basically in mobile-responsive. And throughout the process, as we have gone through moving sites from mobile to mobile-responsive, we’ve merged and cut some widgets in the back-end because we’ve found over the years that Pangea, the content management system is about ten years old, and over the years we’ve added some content types that are sort of difficult, so we don’t necessarily need them.

Once we launch everything on desktop, we’re going to completely redesign the content management system UI, which is going to be our next huge task, and most likely make that responsive as well.

Karen:

Can I ask about how you might have edited the content? As you were embarking on this responsive redesign and evaluating the content navigation and the prioritization of different pieces of content that you produced, did you have to go through a big editing process to clean it up and pare it down?

Kim:

Not really. We had a lot of tools in the back-end already set. Like a teaser headline—so we have a character count, so if a headline is over a certain amount of characters, then an editor would have to write a shorter headline, per se. So, the CMS is pretty robust. What we have focused on in the past year has been more on the performance and then the front-end look and feel of mobile-responsive. Next year, once we launch everything on desktop, we’re going to completely redesign the content management system UI, which is going to be our next huge task, and most likely make that responsive as well.

We traveled to Moscow, Istanbul, and Bishkek and performed audience research, a responsive design study, and the results were extremely positive.

Ethan:

I’d love to hear a little bit about how, once the mobile-responsive site started to really finalize and gel, was there any review that had to be done with the rest of the organization? And if so, how did you actually circulate the responsive design so you could actually get feedback on it and review it?

Kim:

As I mentioned, we were working with Dan on the initial design, he gave us some great ideas as far as some elements, element collages, basic article page and homepage. And then we sort of took that and ran with it, creating all the pages that are needed on our site.

After that was accomplished, we floated the look and feel of the design, the whole concept, to senior management here at RFE/RL. They were extremely pleased. And then after that was blessed, we traveled to Moscow, Istanbul, and Bishkek and performed audience research, a responsive design study, and using Pattern Lab. And this is something where Pattern Lab really came in handy, where we created a workable testing environment to where you have a list of scenarios for the user to find this element, click here, do this, and it was about a ninety-minute test in three different languages with about forty people, users or RFE/non-users of RFE, men/women, tablet/desktop/mobile, and the results were extremely positive.

So after we got a positive response from our users, it was full steam ahead. Now had that gone badly, I don’t know what would’ve happened. But luckily we did our homework, we knew we only had one chance to do this right, and pairing with Dan and Tim and doing our homework, doing a great mobile site, having these designs ready to go in the various languages and having actual users test them in-country… There was some feedback as far as little things to improve, but overall they were like, “Okay, when is the site going to be live? We like it much better than the current site.” It was obvious that we just needed to keep pounding away and getting the mobile-responsive site and responsive site out as quickly as possible.

Once we have it on one codebase, you just publish once and there you go, it’ll be much simpler for everyone, for them and for us, because we’ll only have to support one codebase.

Karen:

I love hearing about that, the idea that you’re doing actual in-market user testing. I think it must’ve given you some fascinating insights and a sense of confidence that the designs were working. Can you talk about how you measure or evaluate the success of these responsive designs more broadly? What sorts of data or analytics are you looking at, and how does that play into your decision-making process, especially around the rollout?

Kim:

Yeah, analytics are funny. The organization lives and breathes by analytic data. And luckily, we found that the mobile versus mobile-responsive were basically at parity. I was surprised, I thought we would see an uptick, but it’s pretty flat. I think, and it’s just my opinion, that our mobile site was pretty fast, pretty good. The only downside with the mobile site was that the editors had to publish twice; they still do, because we’re not off desktop yet. But it was a solid mobile site—fast, everything was there. So, the feature sets are at parity, so the analytics are at parity. That’s really the measuring stick, as far as whether it’s a success or not.

They’re very eager to go to full responsive; we can’t get it out fast enough.

If the numbers would’ve tanked, I think there’d be panic here and in Washington, D.C. So luckily people are happy with it. Like I said, they’re very eager to go to full responsive; we can’t get it out fast enough. The editors, right now they have to publish twice, and it’s within Pangea, but two different times. Once we have it on one codebase, you just publish once and there you go, it’ll be much simpler for everyone, for them and for us, because we’ll only have to support one codebase.

Ethan:

Kim, Dan, I’ve got to say, this has been an amazing conversation. I’ve learned a lot from you guys and I’m really excited to be speaking with you as you’re approaching the wider rollout of this mobile-only responsive site to all of RFE/RL’s audience. Before we let you go though, I’d love to hear a little bit about any advice you might happen to have for our listeners, anything that you’ve learned over the course of this project that if somebody in our audience was actually starting a responsive redesign today, what’s one or two things that you’d actually suggest that they start thinking about? Kim, do you want to go first maybe?

We were really sort of stuck, before Dan and Tim came on board, with trying to really visualize how these patterns or pieces, molecules/elements, work.

Kim:

Sure. I would say use Pattern Lab. We found the tool invaluable. We were really sort of stuck, before Dan and Tim came on board, with trying to really visualize how these patterns or pieces, molecules/elements, work. Like Dan said, we were trying to build our own but we were sort of getting bogged down. Once they came on board, it was clear that this is a tool that, once we tweaked it for our .NET code, is something that our front-end developers really, really were excited about; our designers as well, because they could iterate quite quickly. That would be the number one recommendation that I would have for responsive design, something that you really need, and to get away from Photoshop mock-ups, as those days are long gone.

And the other thing is just do it; just step in and do it. We would’ve started earlier in the process, but we thought, well, we didn’t want to go too early, we wanted to see how others, like the BBC or The Boston Globe, CNN—they were also working on a responsive design. We wanted to see how, especially the BBC, how they were doing their responsive design; we followed their blog and what they were doing because our audiences are very similar. Once they had the concept proof, we were like, “Okay, let’s just go in and do it.” Don’t hesitate. Especially now, practically everyone has a responsive design it seems, and if you don’t, it’s a sign to me that the company hasn’t really taken the modern approach to web design.

First finding out what the project is about, like what does this project hinge on? Like for Radio Free Europe, it was performance, it was really making that the star of the project.

Ethan:

That’s great. And Dan, what about you? Any advice for our listeners?

Dan:

Yeah, I think for the designers and developers that are listening, or anybody helping an organization, whether you’re part of that organization or consulting with them, I think first finding out what the project is about, like what does this project hinge on? Like for Radio Free Europe, it was performance, it was really making that the star of the project. So really, we knew what the priority was, what the focus needed to be, we knew what sacrifices we needed to make for that priority. So I think knowing that upfront was really helpful and it helped us to structure the project around that thing, around performance, around making that really the hero.

The rollout strategy was really great. What we loved about it is they didn’t wait until everything was perfect.

And then I think the second thing is, one of the things we fell in love with with Kim and her team, is that the rollout strategy was really great. What we loved about it is they didn’t wait until everything was perfect. There was still work to be done, but there’s always going to be work to be done. The fact that they rolled out just to mobile to kind of see how that works and still have got the desktop site around, it gives them some place to compare, some place to be able to find out what’s working and what’s not and be able to tweak that. I think that’s what some of the most successful publications and product companies are doing, is releasing a thing in a small test case, testing against it, making sure that it works well, iterating and improving upon that rather than waiting for a long time to sit on something and perfecting it in your minds before releasing it. So I think that idea of releasing it early, being able to get real feedback on it and being able to kind of see it in the wild I think is a really great thing.

Karen:

Kim, Dan, I want to say thank you for taking time out of your busy schedules to talk to us and our listeners today. I’m really, really impressed by what you’ve been doing at Radio Free Europe/Radio Liberty and I’m looking forward to seeing the mobile-only responsive site overtake the desktop sometime soon. Thanks again.

Kim:

Thank you.

Dan:

Thanks for having us.

Ethan:

Thanks to everyone for listening to this episode of a Responsive Web Design podcast. And thanks also to our sponsor, Harvest. Go to getharvest.com and start tracking your time, painlessly, today.

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 also offer these workshops to the public, so please go to responsivewebdesign.com and see when we’ll be in a city near you.

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 for listening, and we’ll be back next week.