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, well, Karen and I have evolved into our final forms, beings of true joy and light, because we are incredibly excited to have Christian Skotte and Mark Llobrera talking to us today about ScienceFriday.com. Mark, Christian, thanks so much for joining us.

Christian:

Thanks guys, it’s good to be here.

Mark:

Thanks for having us.

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:

If you guys could just both take a minute, just introduce yourselves to our listeners, tell us a little bit about what you do, and tell us a little bit about Science Friday. Christian, do you want to go first?

Christian:

Sure, I will. So, my name is Christian Skotte, my title is director of program strategy for Science Friday, and what I handle is a lot of the—everything that doesn’t take place over the radio airwaves. So I have a finger in a lot of the business-side stuff, definitely our audience growth and engagement, lots of our digital stuff, and a big part of my job is just making sure that Science Friday is in all the places that our audience is and making sure that we deliver as good content as we possibly can to them.

Mark:

Yeah, and I’m Mark Llobrera, and I am the technology director for Bluecadet, and we’re a digital agency based in Philadelphia. We create websites, mobile apps, and also interactive media, like touchscreens and projections and games for primarily museums and cultural institutions and nonprofits. So, the nexus of our work is a lot of museum and non-profit clients.

Christian:

And I realized I only talked about myself and not about Science Friday there, so if you wouldn’t mind me jumping in and telling you a little bit about Science Friday. So Science Friday is a twenty-five-year-old radio show that has about 1.5 million listeners over the radio each week, and at least over the last five years or so we’ve really taken to trying to translate a lot of that stuff outside of radio into the digital realm. A couple of years ago, Ars Technica called us a “multimedia machine,” which was great. But we produce digital videos, we have educational resources, we have original reported web articles, and a big part of why we were looking to work with Bluecadet is our last website really just didn’t do a great job of giving us a good platform for that.

For me personally, I was not necessarily on the responsive bandwagon for a while. I think a lot of those first generation of sites were maybe not as attractive as I thought they could be.

Ethan:

Well, let’s talk a little bit about that new platform. Christian, I loved that little line in your intro about making sure that Science Friday is going wherever its audience is. I’d love to hear a little bit more about some of those early days and why you decided to go responsive, and I’d be specifically interested in some of those early discussions. Did you have any stakeholders or executives at Science Friday who needed to be convinced that this was the right approach? Any questions or concerns that came up in those early days?

Christian:

Yeah, absolutely. And actually, for me personally, I was not necessarily on the responsive bandwagon for a while. I think a lot of those first generation of sites were maybe not as attractive as I thought they could be, and it was actually, Ethan, one of your articles in A List Apart a few years ago, with the Sherlock Holmes, that really convinced me that, wow, you can make something that actually looks good and is responsive at the same time. So, that was influential on my personal thinking.

We had an app for Android and an app for iOS, and worked on those for awhile, and we didn’t have a whole bunch of listeners for them, and they were pretty expensive for us to maintain.

But for the organization…I came to Science Friday three and a half years ago, and that was right after a redesign of the site that was our old site. And while it was much better than what the previous site had been, which looked like something from GeoCities, it was not very user-friendly in a lot of ways. So, there was no mobile experience whatsoever; it was completely fixed-width, and if you scaled down your browser window, at a certain point you just couldn’t see things because there were lots of whizbang animations and things like that that kind of collapsed themselves. So, we knew that it was just not a great experience for mobile users.

Our host and executive producer, Ira Flatow, is a huge fan of technology, he loves technology, he loves gadgets and gizmos, and he had put out a call for a Science Friday app. And so we had an app for Android and an app for iOS, and worked on those for awhile, and we didn’t have a whole bunch of listeners for them, and they were pretty expensive for us to maintain. So probably I spent about a year and a half trying to work with Ira and let him know, presenting analytics and saying this is where our audience is coming from, they’re coming to our website primarily from social and using mobile devices to do that. Their first thought when they want to listen to Science Friday is not “I’m going to go to the Science Friday app,” it’s because they see something new, they see something cool that we’ve done, that we’ve published, and they want to come to our website to see it. So, that was kind of important for us.

We had a lot of traffic when the show is live, pulling out their phones and looking for some of the stuff and really having a pretty terrible experience on our old mobile device.

Also, Science Friday, we’re in an interesting place in that, like I said, we are a radio show with 1.5 million listeners and one of the things that we do pretty frequently is have over-the-airwaves calls to our website. So when we produce a video, or if we have an educational resource or something like that, then Ira will say over the radio, “Go to ScienceFriday.com to take a look at this.” And one of the things that we found is that people would be listening maybe at their desks or something like that, and instead of going at their desk to go for that, they would reach for their phones. So, we had a lot of traffic from two to four Eastern on friday, which is when the show is live on the East Coast, pulling out their phones and looking for some of the stuff and really having a pretty terrible experience on our old mobile device. So, we knew what we wanted to do was to give people a really great experience on mobile, and we thought that the best way to make that happen with the limited resources that we had from a technical perspective—we don’t have any full-time IT staff at Science Friday—was to go for a responsive website, ensure that it’s the best possible experience for the most people no matter what they’re using.

That intermediate group of people, the social media fans, they’re the ones that spend a lot of time coming from mobile devices, and a lot of times it is because at this point Facebook is mostly a mobile app.

Karen:

Let me follow up on that and ask how you, within Science Friday, tackled the question of mobile users and desktop users. I’m always interested when I hear organizations that exist on many different platforms and are trying to wrestle with the audio player and app and website debate. How do you conceive of what a mobile user wants vs. what a desktop user wants? Are they different? Are they the same?

Christian:

Yeah, they’re different, but I think they live within the same universe. So for us, what we know is at Science Friday we have three main user types that we talk about on our website. The first type, I call them “cool video bro people,” and essentially they are people that come to our site because they’ve seen one of our videos or something that’s gone viral a little bit. They’ll come to our website, they look at about 1.4 or 1.5 pages per visit, so they’re not spending too much time on our site, they aren’t deeply engaged, and then they just kind of bounce away.

Then we have this intermediate group of people who are mostly social media fans. So, our homepage for them is Facebook a lot of times; they’ll come to Facebook, and then from Facebook they’ll come to Science Friday and go to an interior page within Science Friday.

And then we have a different group of our loyal listeners, who are people who come to the site, they spend on average twenty minutes on the site, they’re really coming to listen to our audio and spend a lot of time on the site.

What we want them to do is to be able to play audio, watch videos, do just about anything that they can on a desktop and on mobile.

Each of those user types behaves very differently. The first group, the “cool video bro people,” a lot of times they’re actually coming from desktop. It’s about a fifty-fifty split from them, so a lot of desktop users, some mobile users. It’s that intermediate group of people, the social media fans, they’re the ones that spend a lot of time coming from mobile devices, and a lot of times it is because at this point Facebook is mostly a mobile app. We get a lot of people that are coming from Facebook on mobile devices coming to our site, they may be listening to audio, they may just be looking at something that’s cool. So, we do know that there are these different groupings of people and how they use mobile vs. desktop is different. But what we know that we want is for people, no matter what platform they’re coming from, whether they’re coming from a social site, if they’re coming from a referral, if they’re coming from direct traffic, we want them to have a pretty good experience, as good as possible. And what we want them to do is to be able to play audio, watch videos, do just about anything that they can on a desktop and on mobile.

We knew from the start that what we really wanted was audio, we want to get people to listen to audio. That’s kind of our secret sauce, so we knew that that was something that we wanted to be really big in the project.

Ethan:

Following up on some of that research you’ve done, Christian—this actually might be a question for both of you—which is, how did you actually scope this project? And Mark, I’d be really interested in your perspective as well because I know at Bluecadet you do a fair bit of responsive work, and I’d just be curious to hear how you think about approaching engagements like this.

Mark:

Yeah, Christian, do you want to talk about how Science Friday’s team dealt with that and then I’ll jump in and talk about what happened at kickoff with Bluecadet?

Christian:

Sure. So, at Science Friday we spent probably about six months or so going through a process of knowing that we didn’t like where we were on our current site and asking questions of our staff about what we wanted from a new site. We asked from some users what were their frustration points. We knew from the start that what we really wanted was audio, we want to get people to listen to audio. That’s kind of our secret sauce, so we knew that that was something that we wanted to be really big in the project, and that’s particularly one place where I think Bluecadet really hit it out of the ballpark.

In terms of actually just scoping the project, we knew that we wanted it to be responsive and we knew that we wanted to have a new CMS—that was something else that was not germane to this conversation but was a big problem for us, was our CMS was not too great. So when we put together a few RFPs, we had seen that Bluecadet did a great job with the Lapham’s Quarterly website, and so they were one of the people that we reached out to and just had some good conversations with them.

So getting that author experience right—and it’s the kind of thing that folks like Eileen Webb and Jared Ponchot have been talking about for a while now, just “authors are users too.”

Mark:

Yeah, basically when Christian and his team came down to Philly to do the big kickoff with us, we just fed them a ton of cheesesteaks and started listening. And there were a couple of things, and Christian has touched on them a little bit, but there were three really big things that came out of kickoff for me. I still have my notes from that original meeting, and the first was, yeah, the audio player, making sure that the audio, the listening experience for their users was top-notch, was something that people would want to do and come back to on the site. So that was a big thing, and maybe later we can talk about some of the prototypes and how the player as it is on the site emerged.

Getting the CMS to empower the content creators on the Science Friday side was another big takeaway.

The other big thing was getting the authoring experience right. So, Julie Leibach and Chau Tu, who are really key drivers of the content on Christian’s team, we heard a lot from them about how they had all this great content and they had an idea for how they wanted to present it, but they just couldn’t really do it in their current CMS. So getting that author experience right—and it’s the kind of thing that folks like Eileen Webb and Jared Ponchot have been talking about for a while now, just “authors are users too,” they actually spend more time than the actual audience creating content. Getting the CMS to empower the content creators on the Science Friday side was another big takeaway.

And lastly, was just being able to shed light on the other aspects of Science Friday’s content. I was this way too—when I first heard about the project, I was like, “Okay, radio show, I got it. Podcast material, yadda yadda yadda.” But really there’s just so much content there that I hadn’t really encountered, and finding a way to bring that to light for users across the many different audiences that Christian laid out, that was the other big priority that I scribbled down. How do we get folks who maybe come here for the educational resources, activities you can do within a classroom, how do we get that content in front of more people? How do we get some of the series that they run regularly in front of the folks who might just only come there to listen to the audio segments? So, that was another big takeaway from that kickoff.

Karen:

Just so everybody who’s listening doesn’t think that I’ve been abducted by aliens or anything, this is really Karen McGrane speaking and there’s no way I could listen to you say all of those comments about your CMS and the author experience and not follow up on it.

Mark:

[laughs]

It was very rigid; we didn’t have editorial control over our homepage at all, and that was a big problem for us on the editorial side.

Karen:

So, I’d love to hear a little bit more about really how the content part of this process worked. So, one of the things that I’m always interested in is how a responsive project causes you to re-prioritize and restructure your content, and that often means different editorial decisions. And then that often, as I’m sure we all know, falls all the way back into the technical and architectural decisions around the CMS. So, I’d love to hear you just talk more about that.

Christian:

Sure. For us, a big part of our old site was—the word that I would use to describe it, whether it’s the actual site itself or the CMS, is “rigid.” It was a rigid, un-flexible piece of technology. So what that meant on the user side is that we had on the homepage very distinct places where content would go, and we as a staff really couldn’t change those things. So if Ira mentioned something on the radio show and said, “Come to ScienceFriday.com and take a look at it,” we didn’t really have editorial control to place something in a prominent position on the homepage to make it the first thing that somebody would see coming to the site, hearing about the URL on the radio show. So, it was very rigid; we didn’t have editorial control over our homepage at all, and that was a big problem for us on the editorial side.

This current site is much more flexible, and what that means for us from a user perspective is if somebody comes to the site, we can intuit what is going to be probably what lots of people are looking for.

On the CMS side, it was also a very rigid backend, so what that meant was that we had some really interesting restrictions. So for example, on one of our media types are our audio segments, and we actually had a character limit on the audio segment pages. So if we put an audio segment onto the site, we could only have 300 words or something like that on that page, which is just terrible for our editorial staff, who actually may want to tell a story. So what we had to do was put a piece of content there that was audio and then just have a text link within there to a longer written piece that would make much more sense to actually go on that page. So it was very rigid, and I think that from the start in our conversations with Bluecadet what we were really looking for was flexibility.

So this current site is much more flexible, and what that means for us from a user perspective is if somebody comes to the site, they’re looking at the homepage, we can intuit what is going to be probably what lots of people are looking for. So again, from two to four Eastern time, we assume they’re looking for something that’s on the radio show, we throw that up to be one of the most prominent things. If it’s over the weekend, we can assume that somebody is looking for something that was on last week’s radio show, so we can make that one of the most highlighted things. Now from an editorial perspective, what that means is we have to figure out all of that stuff and we have to say, “What is the most prominent thing?” So we did a little bit of work on that when we were in prototyping, and a good amount of work on figuring out what that workflow was like before we had the production site. And now what we’re doing is we’re testing all of that with—we’ve got about two weeks now where we’re going to try and figure out are all of our assumptions that we made accurate? So we’re looking at analytics, we’re looking at user behavior and seeing did this work?

Now that we do have the flexibility, we’re just right now trying to work in the best way to take advantage of it with the resources that we have.

We’re also looking at our workflow, because to be honest with you, we spent a lot more time thinking about how users would use this than thinking about internally how we would do things. So what we found now is that because we are a Friday show, do we make people stay late on Fridays trying to make sure that we’re updating the homepage so that it makes sense for the weekend, or, you know, figuring out our workload. So that’s something we’re, to be honest with you, working out that was a little bit of a surprise after we launched. But that’s a good problem to have as far as we’re concerned, because it was so frustrating with the last site to not be able to have that editorial flexibility. So now that we do have the flexibility, we’re just right now trying to work in the best way to take advantage of it with the resources that we have.

Being able to present the homepage in a different way easily and simply was a very big priority that we heard from them, and that really drove a lot of the technical conversations.

Mark:

Yeah, just to jump in real quick: we just heard that loud and clear, when they were meeting with us and kicking off the project with us, that need for flexibility because, like Christian was describing, Science Friday the site during the week is different from how it is on Fridays. And being able to move things around, being able to present the homepage or major section pages in a different way easily and simply was a very big priority that we heard from them, and that really drove a lot of the technical conversations.

But the site as it is right now is currently in WordPress, and the need for that authoring flexibility was probably the single most important factor in making that decision. At Bluecadet, we do a ton of Drupal and WordPress work, so to us it almost doesn’t really matter one way or the other. But there are certain projects that lend themselves to one of those platforms vs. the other. In this situation, the desire that the Science Friday team expressed for that sort of flexibility, being able to move content blocks around, being able to easily relate things to each other, really moved us in the direction of WordPress, which, for better or worse, has really focused a lot on improving that core writing author experience.

The problem with us is that that CMS was like a glove, but somebody else’s glove, because the site was designed for who we were three years ago.

Christian:

And for us, definitely with our old CMS, it was a custom CMS that was designed for us, but one of the things is that there’s a tradeoff between having an off-the-shelf thing like WordPress versus a custom CMS. The custom CMS really should—the strength is that it should fit like a glove, and even if it’s difficult to update or anything, it should be just completely bespoke and customized for you. The problem with us is that that CMS was like a glove, but somebody else’s glove, because the site was designed for who we were three years ago, probably even five years ago, to be honest with you. And so we’ve grown so much since then that what we found is that all of the decisions that were made five years ago when that site was finally launched were not who we were are now.

We don’t want to get stuck in that position where our CMS is dictating editorial strategy to us.

For us, having a completely new CMS, we’re much more comfortable with having a WordPress or something that we can hire somebody to make adjustments to on the fly because we’ll probably be—just like we’re very different from who we were five years ago—we’ll probably be in a completely different place five years from now and we don’t want to get stuck in that position where our CMS is dictating editorial strategy to us.

We just said, “We want it to be beautiful, we want it to work, and we want it to play audio well,” and they took that completely inchoate idea and turned it into something awesome.

Ethan:

One phrase that both of you used quite a bit was “flexibility,” and I’d like to use that to pivot into talking a little bit about the design process for the new site. You know, this is something that Karen and I hear a lot of organizations struggle with when they’re talking about aesthetics and layout and trying to actually come up with a creative direction for a new responsive site. The problem is that so many applications and tools we’ve historically used to talk about a web page’s design just aren’t flexible in and of themselves—things like Photoshop, for example. So how did you actually come up with a really beautiful design for this new site and then actually start talking about it as a team? I guess it’s an open question for both of you.

Mark:

Go ahead, Christian. Maybe you can talk about the way you envisioned it and then I’ll talk a bit about how that actually played out in the execution.

Christian:

Sure. Yeah, for us, to be honest with you, we knew what we didn’t like. We didn’t know so much what we wanted. So, we gave Bluecadet… some things that we absolutely didn’t want and we opened it up to them to give us what turned out to be a really great site. So I can’t say that we gave them too much design direction or instruction at all. We just said, “We want it to be beautiful, we want it to work, and we want it to play audio well,” and they took that completely inchoate idea and turned it into something awesome.

We set out to listen and then prototype and then repeat that process.

Mark:

[laughs] Yeah, I would say the process here was really—and I’ve written a little bit about this elsewhere—but really we set out to listen and then prototype and then repeat that process. And so, when we were sitting down with the team, we heard, “Okay, we really want the listening experience to be good.” Immediately we said, “Okay, we’ve got to start prototyping the audio player.”

Then they talked about needing to surface content, like the educational resources, being able to filter those things. And so immediately we started saying, “Okay, well let’s look at the content model for their content there.” It looked like we needed to—this is probably one of Karen’s favorite things—de-blob and chunk a lot of that content for it to be filterable. So, we already knew—coming out of that kickoff, like I said, I wrote down three big priorities and they mapped pretty cleanly to prototyping directions that Bluecadet’s team was going to work on.

I should pause here and just briefly mention the team on Bluecadet’s side, just so I don’t forget later on. It was very small; there are about six or seven of us. So the core team was Jeff Wiesner, who is the project manager; Maya Bogdanow did a lot of the project coordination and content strategy, and design was led by Wyatt Glennon on lead design and Kim Quinn on art direction. And on dev you had myself, Putra Bonaccorsi, and Henry Steinberg. And finally Josh Goldblum, our founder, on creative direction. So that’s a pretty small crew, and what we were able to do is basically say, “Look Wyatt, you’re going to have some time to sketch out based on what Christian and his team have said,” and they came with a lot of, like, examples both from their own site and the stuff that they’ve created as well as other sites that they liked and things that they most definitely did not like. So basically Wyatt took off and he started sketching while Putra and Henry and myself, we started hunkering down with Maya on the content model side as well as the prototypes. And when I say “prototypes,” I just want to distinguish: some people in some places use prototypes in different ways, and some use them for working out visual layout. In our case, we mostly used them for the stuff that was going to be under the hood and that was going to derive a lot of the technical prerequisites.

Things that usually come for free, like filtering a list and paginating a list, we had to make sure that that worked once the page was loaded in AJAX.

So the audio player, hearing from Christian and his team that it needed to be this seamless experience, they didn’t want it to be interrupted as the user was browsing different pages on the site, immediately that sent us in one direction and so we basically blocked out time, about half a week, to try that and see what we back with. And what that ended up doing is we were able to then get on the call with Christian and his team the next week and say, “Look, here’s what we found. Here’s the tradeoff.” Their current site had a pop-up, so it solved one problem but traded it for another, and we said, “Well, we can give you a seamless audio player, a persistent one, but it’s going to mean that everything needs to be loaded in dynamically using AJAX, and here’s what that then entails. It means that a lot of the stuff that WordPress does out of the box, we’re going to have to make it work in the confines of that structure.” So things that usually come for free, like filtering a list and paginating a list, we had to make sure that that worked once the page was loaded in AJAX. It was basically like those things can work in AJAX, but if you’ve already loaded the outer page in AJAX then you start getting into this “turtles all the way down” situation. So we definitely had to, like I said, identify those, prototype them, and then we were able to come back to Christian and his team and say, “Okay, here’s what’s on the table, here’s the tradeoffs.” And they were really, really sharp about saying, “Look, here’s our priorities, here’s what our users need, and so this is the direction that we want to go in.”

And all the while, yeah, like I said, Wyatt was working more on the design side and coming back in to meet with the rest of the larger team with both sketches and comps, and those proceeded in a more orderly fashion, where Christian and his team would get a batch of things to look on and sort of trace over and say, “Well this stuff, we wouldn’t really present content in this way, and this order makes a little more sense.” So that side of things was a little bit more traditional in terms of how you would approach visual design.

People who listen to audio on our website are more likely to come back, they’re more likely to be engaged with us, they’re ultimately more likely to be donors.

Christian:

And I will say, from a design perspective, again, the audio player is fantastic. It was a little touch and go there for a little while as to whether or not it was actually going to work, as Mark described. But we knew that this was something that we really wanted for our folks because we know that audio, as we say, it’s our “secret sauce,” and that people who listen to audio on our website are more likely to come back, they’re more likely to be engaged with us, they’re ultimately more likely to be donors. So for us, having people play audio on the site was really critical and we knew that we didn’t want the kind of pop-up player where it goes away and then people can leave the site. We want it to be persistent on the site so that people could, as they’re exploring our educational resources or as they’re looking for an article that is related to what they’re hearing, they could still hear the same audio. That was really key for us and I think that was kind of—it’s subtle if you’re not actually using the site. But once you start using the site, it becomes a pretty key feature to the site.

I was at a conference for public radio folks and the oohs and aahs when I showed this persistent player and then went to page to page to page were audible.

And actually I was at a conference for public radio folks a few months ago and we were showing off the development version of the site, and the oohs and aahs when I showed this persistent player and then went to page to page to page were audible. It’s something that doesn’t exist in a lot of places. The only other—at least in the public radio world—I can think of that has it is the Colorado Public Radio website has it. But other than that, it’s pretty much—it doesn’t really exist in the public radio world.

We want to have people on mobile devices spend more time on the site, we want them to visit more pages on the site, we want them to bounce less.

Karen:

Let me ask you how, broadly, when you’re thinking about the success of this responsive site, how do you measure? Like, you mentioned at the beginning of the call that you were look at how the app was performing for you, and it seems like you’ve got some data on the usage of the player. Like, what other ways do you measure the success of a responsive design?

Christian:

Yeah, so for us right now—and this is something we’re in the process of looking at, and since we’ve just launched the site and it came out, it’s too soon to tell how successful it’s been, partly just because we had a really popular video that just came out, so I’m a little hesitant to attribute all of the changes to it being the new site versus just a couple of key pieces of content.

For us, one of the big problems that we found was that the dropoff for mobile, I don’t have the numbers in front of me, but the average page per visit for a mobile user was like 1.2; the bounce rate for mobile users was in the eighties. It was just people were having a terrible experience on our mobile site. So what we’ve set up is a few indicators that are for improvement, that we want to have people on mobile devices spend more time on the site, we want them to visit more pages on the site, we want them to bounce less. I mean, these are all pretty standard metrics. It’s just that for us, because it was so stark, the divide between desktop and mobile, for our old site, I’d be happy to just get us within—to have our mobile within spitting distance of what our desktop looks like. That’s the goal right now. I’m pretty confident that we’re going to exceed that, but I just want to manage expectations going forward.

Let’s move in the direction of being responsive as opposed to having an app or as opposed to having a site that delivers a completely different mobile experience than our desktop.

Ethan:

Christian, Mark, this has been a fantastic time with you, and I’d just like to hear, as we’re coming to the end of it, if you have any advice for our listeners. Any lessons you’ve learned during the course of this project that you’d like to share with anyone who’s about to start a responsive redesign?

Christian:

Yeah, for me I think the biggest thing is know your users. So for us at Science Friday, our average user is a little bit older, they’re public radio folks. So, even the ones that are on the website are younger than a lot of our listeners. But a lot of our listeners are coming to the site, they’re looking for specific pieces of content, and it was much easier for us to make good decisions about let’s move in the direction of being responsive as opposed to having an app or as opposed to having a site that delivers a completely different mobile experience than our desktop experience, when we knew what our users were doing.

I mean, that’s just the basic of communications, is know your audience, but I feel that a lot of times people forget that and just look for something that seems cool or that they want to do. And from the start, we knew that what we wanted this new site to do was to serve the largest number of our users as best as possible. So my advice is look for your users, look for what they’re looking for, and then find a good partner. If you can find Bluecadet, then you’ve done well. They were great partners.

Spend time really working on the content. So many of the things that pop up later, on maybe on the visual design end of things, can be traced back to unresolved content issues.

Mark:

[laughs] Just to jump in on what Christian was saying, you talked about users—for us, the advice would be spend time really working on the content. What we find—and not so much on this project, because I think Christian’s team was really, really focused and prepared—but so many of the things that pop up later, on maybe on the visual design end of things, can be traced back to unresolved content issues.

If you’re about to embark on a responsive redesign, spending that time up-front to get your content sorted can really help set that design up for success.

If you’re about to embark on a responsive redesign, spending that time up-front to get your content sorted, getting content models right and thinking about priority and hierarchy and how different content is related to other pieces of content, doing that work up-front can really help set that design up for success. Because then when you get to the visual side of things, you’ve got a very clear direction in terms of your user and what they’re trying to accomplish and what content that they’re really looking for, so you’re not driven by more of a shallow aesthetic rationale, you’re grounding it in something that you’ve thought deeply about and are trying to provide for your user.

Keep links alive, because link rot is just a terrible, terrible thing.

Oh, and one last thing: keep links alive. And this is very close to my heart because I was knee-deep in the content migration for this project, but one of the big things that comes through whenever you do a big redesign or re-platforming is a lot of links end up dying. And I think for a site like Science Friday, we spent a lot of time working on things that aren’t necessarily fun, like redirect patterns, but making sure that users who have been coming to their site year in and year out could still make their way to old bookmarks, make their way to old sections and get properly directed to the new sections on the site with minimal disruption. That was a very big deal for us, because link rot is just a terrible, terrible thing, and so we really tried to think of it as, okay, the redesign, you want people to notice it, but you want people to notice it for the right reasons. You don’t want to just move everything around and then have people who say, “Yes, it looks great and it looks pretty, but I can’t find the thing that actually drove me to become a fan of this site in the first place.”

So yeah, getting content right and making sure that you don’t cut off the through line from where the content used to be I think are two very, very big things.

Karen:

Christian, Mark, thank you so much for coming on the show today. This has been an amazing case study. You have just hit all of my marks. So, we’ll send you off unto the rest of your day, but thank you again for taking time to talk with us.

Christian:

Thank you.

Mark:

Thank you, Karen and Ethan. It was a really, really great pleasure to talk to you about the project and it was good to hear Christian’s voice again.

Christian:

[laughs] Good to hear from you too, Mark.

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 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.