Skip to our site navigation Skip to the content

Responsive Web Design


Episode 149: WHYY

Public radio station WHYY serves the Philadelphia region with local programming and community events—and with a website that works across all devices. Rebecca Smith and Mark Llobrera tell us more.

It doesn’t matter if somebody’s coming because they’re a daily user or if they are going to visit the site twice a year. We want them to be able to access the information that they’re looking for from any device.

If you’d like, you can download this episode’s audio file. Additionally, you can follow us on iTunes, on Google Play Music, or subscribe to our RSS feed.

Buy The Books

Everything you need to go responsive, in four short books. Save 15% on all four!

Subscribe Now

The podcast may have ended in 2018, but you can still subscribe! If you want the latest episodes, fire up your favorite podcasting app and subscribe via RSS, Google Play Music, or on iTunes.



This Week’s Guests

Rebecca Smith

Digital Product Manager

Rebecca Smith is the Digital Product Manager at WHYY, the premiere public media organization in the Philadelphia region. Over the course of her years working in digital agencies and at major national brands, such as Bluecadet and Urban Outfitters Inc., she developed a passion for process refinement and digital strategy. She believes that all challenges should be approached with equal parts empathy and curiosity - and a pinch of skepticism. Rebecca earned her B.A. from Hampshire College in Social Science with a focus on History. She currently lives in South Philly and is a big fan of game nights, karaoke, and candy.

Mark Llobrera

Technology Director, Bluecadet

Mark Llobrera has been creating websites and applications since the days of spacer GIFs, table layouts, and squelchy modem sounds. As a Technology Director for Bluecadet, he leads a team that partners with museums, nonprofits, and universities to build websites, interactive installations, and immersive environments. Mark is a writer whose contributions have been published by A List Apart and net magazine. He regularly speaks at web and technology conferences, focusing on empowering content creators in a multi-channel, multi-device world. You can find him on Twitter @dirtystylus or at dirtystylus.com.


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 so excited you all have tuned in, because we are here speaking with Rebecca Smith and Mark Llobrera, who are here to tell us about the responsive redesign of WHYY. Rebecca, Mark, thank you so much for joining us.

Mark:

Thanks for having me.

Rebecca:

Yeah, happy to be here.

Ethan:

Well, we couldn’t be happier to have you. So before we dive into the interview, maybe we could just take a moment and ask you both to introduce yourselves, tell us a little bit about what you do on a daily basis, and maybe a little bit about WHYY. Rebecca, do you want to go first?

Rebecca:

Sure. I’m Rebecca Smith, I’m the digital product manager at WHYY, formerly of agency life, and then moved into a product role. Well, for the past nine months it’s been a daily basis of redesigning and re-platforming our website, but right now and post-launch hopefully it will be helping people to use tools to create really great user experiences for both our news and organizational platform. We also recently launched an app.

Mark:

I’m Mark Llobrera. I am the technology director for Bluecadet in Philadelphia. We’re an experience design agency with offices here in Philadelphia and in New York, and our work is situated squarely in the non-profit and museum space. So, we do a lot of web work and museum interactives for, again, non-profits and museums. So, this project with WHYY, a local organization that we’re all fans of, was a real dream project for those of us at Bluecadet.

Ethan:

Welcome to both of you. I didn’t realize until we were setting up that the new responsive redesign just launched, so the timing of this recording is pretty timely. But I’d love to hear a little bit more about how this project started, specifically maybe stories about the early days of the redesign and, in particular, if there were any questions about a responsive approach for this redesign. Were there any questions about how best to implement it? Any concerns from any stakeholders?

Rebecca:

The process had already kicked off a little bit before I came on. I know that my boss, before we got deep into the weeds, wanted to get me on board, and so really in January is kind of when the discovery and the work started. I think that one of the things that was really great about folks here is that everybody understands the importance and rise of the mobile user, and even just when we started this, we were kind of looking at the data and over fifty percent of our users were accessing the website from a mobile device. So, that was really cool to be backed up by the data like that.

I think the biggest hurdle that we kind of heard from stakeholders was that the site before this redesign and this launch was technically functional on a phone. So, where we had to shift the conversation was not just, “Okay, just because you can do that on the phone doesn’t mean that users want to jump through those hoops or want to do that on the phone.” So, really trying to create not just a conversation around like is this technically feasible, but is this a mobile-first or is this a kind of skinny-screen-first experience? Do people want to access this information from their phone or from a smaller device? Those were the conversations that we had to have internally and get stakeholders on board with.

Mark:

It’s interesting, as Rebecca mentioned, she came on board early in the year—on our side at Bluecadet, we had had a couple of sort of exploratory conversations with Gabriel Coan, who’s Rebecca’s boss, and at the time there were a lot of things on the table. They were talking about a re-platforming, they were talking about newsworks.org, which is the news wing at WHYY, and bringing that into the fold. But at the time, this was probably I want to say the fall of 2016—at the time there was, like I said, a lot of different things and directions it could have gone in. I think it was really when Rebecca joined the fold at WHYY as their product manager that it really started to turn into something with a very clear direction and clear priorities in terms of how they wanted to proceed and what they wanted to do first.

It was really refreshing because a lot of times especially when we’re working with folks in the non-profit space, sometimes they get one shot at doing something. With Rebecca and her team, it was great to have conversations that were just oriented more around, “Okay, what do you want to do first?” with the understanding being that this was a long-term project and product that they were going to take through multiple phases as time went on. So, that was great.

Ethan:

Let me follow up on something you both said about mobile in general, because with such a large part of WHYY’s audience coming predominantly from mobile, did that change the way you approached thinking about responsive design? Did it change the way that you thought about serving up content to different classes of devices and how you determined what information they got?

Rebecca:

I think that for us, because this new site was a marriage of a newsroom and more of an institutional website, they serve very different people, and the newsroom’s needs is very different than, say, our education department’s needs. But one of the things that we really wanted to stress was that it doesn’t matter if somebody’s coming because they’re a daily user and they just want to get their latest news feed or if they are going to visit the site twice a year to sign up their kids for summer camp. We want them to be able to access the information that they’re looking for from any device. We really were kind of trying to strive to be device agnostic and also content agnostic, if that makes sense. I’m not discrediting our content or the different use cases, but really just striving to serve all end users. So, I think that was new for folks. I think that people here thought of the mobile experience primarily from our news consumer’s perspective and not from, say, an event attendee’s perspective or from a membership donation form perspective.

Mark:

It’s actually really great to hear that background, and it points out one of the great things about working with Rebecca and her team, is that they had just a large number of different internal stakeholders that they had to get on board with the project. From our perspective, by the time it came to us, they had done all that work on their end and we didn’t have to go through… Sometimes when you’re doing a big project like this, you have to almost justify and give a rationale for going responsive, and we didn’t have to do that thanks to the work that Gabe and Rebecca were doing on their side.

So for us, it was kind of easy; by the time they got to us, we were able to just say, “Yep, we’re going responsive, we’re going to do this” and have more substantive conversations about should there be differences in priority in terms of how the content appears moving across different device sizes.

I think in particular ads, that was one specific conversation we had, where the place where the ads were to appear on a skinny screen had to be different from where they might appear when we were in a wider viewport and had more pixels to play with. So, it was good to skip past the, “Should we do this?” and get into the more, like I said, substantive, “How do we do this? What’s the experience going to be for the user?” as well as the many stakeholders and groups within WHYY.

Rebecca:

And I think that one of the things that we really tried to do organizationally was to say, “Look, we have an MVP and then we have a road map for what this website looks like and what this platform looks like.” And for me, as the product manager, it was really important to stress that the MVP is getting an optimized mobile experience, and I understand that there is a need for—using an event example or a summer camp example—sometimes there’s a need for a more brochure, robust experience on desktop because we have to evaluate, is this something that is a selling point? Is this a page where people are coming back to repeatedly and evaluating against other similar websites or options for their child or for themselves?

We had those conversations early on to be like, “Okay, so once this sits for a while and once we get the platform stable, we’re going to revisit how can we enhance the desktop experience.” And I think that was new for the organization; I think thinking about the desktop experience second was a contextual shift for them. I think that one of the things that we did with Bluecadet was we built up a lot of trust with the organization to be like, “Hey, we’re on the same team, we all want the same things, so let’s identify what is there and let’s identify what is there there,” and eventually we’ll get there there, but we really had to stress that the primary goal of this was to get a good experience across all devices and then we would enhance for desktop.

Karen:

Since both of you have experience managing and leading responsive design projects, I’d be curious to know how you planned out this project or, as you’re working with a partner, how did you scope this? Did you have to take into consideration that this would take longer or cost more, or anything that you wanted to plan for that you want to take into account that you might not expect?

Rebecca:

I mean, the scoping process was incredibly thorough. How many hours did we spend going through all of those Post-it Notes and notecards?

Mark:

Oh, yeah… Time well spent, Rebecca. Time well spent.

Rebecca:

[laughs] Yeah, absolutely. We tried to avoid any surprises, but that’s kind of impossible.

Mark:

Maybe it might be helpful to talk a bit about how we broke it up into—because we had done the first phase of research and scoping before we got into production. That might be helpful.

Rebecca:

Yeah. So, the discovery phase and the research phase that we did with Bluecadet—and it also included information architecture and site audits and analytics analysis—was probably three months?

Mark:

Yeah, I would say right around three months.

Rebecca:

And I think that was really helpful for planning the overall implementation process. From there, we knew what our priorities were and what we wanted to budget for. The other very large component of this was the migration of over 10,000 pieces of content from one content management system into the new content management system. It was kind of like we were like, “Okay, all of that content needs to be there and then all of that content needs to work on a phone or skinny screens, and those are our top two priorities.” So, I feel like we were just in a really fortunate position that we were partnering with a place like Bluecadet, where we know that they know that at this point responsive is just assumed, and we were at a point where we were like, “No, this needs to happen.” So, I think for the sake of that, it was easy to let lower priorities fall to the wayside and not make it to MVP or to this launch. And there is a lot of transparency between Bluecadet and us, and that’s also very helpful.

Mark:

From our side, we got to do some really interesting things up front. We got to do a couple of focus groups to talk to different audiences, because the broadcast audience for WHYY is slightly different from the NewsWorks news consumer, and there’s also variations in terms of the different age demographics and how they were using the different sites. So, it was good to do a couple of sessions and get real feedback. It wasn’t super deep, but it was enough that we were able to draw or confirm some conclusions that we had been seeing through analytics and through internal interviews with Rebecca and her team.

The other good thing about taking enough time up front is we got to interview the internal users. I always talk about how content authors are sort of those invisible users that I really pay a lot of attention to, because their ability to use the site, especially in a newsroom context for example, like NewsWorks, that was one of the chief things we heard in those initial internal interviews, is that they really wanted to be in a CMS that removed some of the… They were experiencing a lot of friction with what then was the current CMS system. Yeah, so getting to get that feedback early on gave us enough grounding to then have those good conversations with Rebecca and her team about what those priorities were and what things were still important but that they were going to slot for successive releases after the first launch.

Rebecca:

And I think that even though they were kind of shallow focus groups, I think that they really drove home what was important to have on platform-agnostic experiences. So, we knew that more so than just assuming that, okay, it’s just kind of a cost of doing business that your Live Stream Player is also on mobile devices, we heard that people really wanted that, and I think that was important for us to be able to take back to higher ups and be like, “These aren’t assumptions. We’re testing what we feel and we were right most of the time.” That’s always nice to know, too.

Karen:

Let me just quickly follow up on your comments about the author experience and the CMS. Can you talk a little bit about the changes that you made there and maybe if that was driven presumably from an author experience standpoint, but were you also changing the content type or the content structure from an editorial perspective?

Rebecca:

Yes, our old CMS just kind of lumped everything into one content type, and there was very little structured data. Additionally, the way that taxonomies were driven, they were also driving the site organization. For me, the first time that I got into the back-end, it was mind-boggling. And then Bluecadet was like, “Can we evaluate the content management system, evaluate your current categorization systems?” I was just like, “No, it’s meaningless. We just need to burn it all to the ground and start over again.” [laughs] “We need to schedule a meeting, because if I just let you back in here, you’re not going to know what is going on.” I think we actually had to have an hour-long tour of what the workflow is and kind of what everything was and why it did what it did.

So yes, we now have really clean content types that make sense both for site integrity and data integrity, but also to our content authors. Relationships are a lot easier to tie together. Little things like you can now create a slideshow within an article without having to leave that article, create a new slideshow and then relay it back, like find that article again and attach it that way. Those were just huge wins for our content producers and for our newsroom. They joke that they need to send a funeral pyre out for our old CMS. They’re just so excited about it. I think it’s the first time that anybody really paid attention to their struggles with the CMS, so they’re very excited.

Mark:

I am such a CMS nerd, that just hearing that feedback, I’m fanning myself over here. It’s amazing to hear that stuff. I mean, Rebecca, it’s really hard to overstate how much work she did. Rebecca, in addition to being the product manager, she’s also been, in past lives, a really crackerjack content strategist. So, it was amazing—and she did say up front, “I need to translate this stuff for you. I can’t just let you loose in this CMS and expect that you’re going to find your way back to civilization.” So, she did a lot of the work up front of breaking down the taxonomy and mapping those to what the new organizational vocabularies were going to be. It was a massive spreadsheet, it was color-coded for the things that were appearing in multiple categories, for the things that needed to be cleaned up, for the things that would be sunsetted.

So yeah, it’s really hard to overstate how much work she did on that front, which made it a lot easier for us to think about, okay, if everything from NewsWorks was an article but really we’re talking about articles and segments and episodes contextually, how do we then, as part of the migration, funnel things into the new and different, more discrete content types? We probably ran the migration dozens of times. We did it with small batches at first, and we focused on NewsWorks because, just to give a little bit of context, there were two big CMSes we were bringing under one roof, and one was for NewsWorks.org that was Joomla! based. A lot of the WHYY programs were already under WordPress, and the new CMS is WordPress, so we felt like those programs would be a little bit easier to bring in, we wouldn’t have to do as much data transformation.

So yeah, that was just an additional wrinkle where we took these small batches, a couple hundred at first, and we were trying to do that in conjunction with building out the key types that Rebecca and her team needed up front. The newsroom generates a lot of content every day, so we felt like the article type was going to be the first thing we should lead with. So yeah, we had parallel threads, basically, where the teams were simultaneously pulling in wave after wave of these articles and pumping them into a still-evolving new content type for the articles and segments and episodes. I think you all had Jeff Eaton on the show recently, and one thing he said really stuck with me, where he said, “Once you’ve started the migration, you should accept that it’s probably started too late,” something to that effect. [laughs] And when I heard that, I was like, “Yes, you totally understand!” And anybody who’s done a migration of this size understands that you really have to accept that you’re going to have to do it early and often, and even then you’re still going to have these outliers where little things are going to just need that manual intervention.

Rebecca:

I wish Mark said that we were doing this kind of push and pull at the same time. If I were to go back and change anything about this project and this process, it would have been that while we were doing research, we were also migrating content and that we didn’t have to do that push and pull. I think in an ideal world, I don’t think I would have had my content owners in there while we were doing the migration, because it some respects it caused confusion. But nothing can be perfect. But having people in there while live things were being migrated was challenging on our end, through no fault of Bluecadet’s.

Ethan:

I’m loathe to pull us away from CMS land, but I would love to hear a little bit more about the design process. Specifically, Mark, hearing you talk a little bit about your engineers kind of toiling away on some of the back-end and the author experience, was WHYY looking at fairly traditional design deliverables, like mock-ups? Or was there more prototyping happening? I’d love to hear a little bit about how you started talking about the design with your clients.

Mark:

We did a couple of traditional deliverables. So, Nate Renninger was the design lead on our team, and he very quickly brought some wireframes for the key content types. Variations on the article at first—we did a lot of those because there was just so much of that content. We then moved into things like different key landing pages that they would need for like the news section or the radio and podcast section. So, in some ways it was very traditional. Internally, we were actually doing a lot of work to identify what would be the flexible content blocks that they would need, because one of the key goals was thinking about any of these content types and realizing that they needed different things at different times, and they needed the flexibility to have things like inline audio players, or related content, or sidebar content, and slideshows; even things like sharing a block quote. We quickly started thinking of those things as very discrete elements. So, internally on the Bluecadet side we were doing sketches and we made some initial forays into style guide generation tools to try and get a handle on those things.

But in terms of what we ended up presenting to WHYY, it was largely your more traditional deliverables. I think there was an element of trust there, and we didn’t have to do a lot of prototyping to extrapolate what things might be like on a smaller screen just because Rebecca and Gabe and the rest of the core team there were very, very savvy about like, “Okay, just describe how we’re going to shift things a little bit, and we can imagine that. You don’t have to generate yet another static artifact to show that to us.”

Rebecca:

For us, the biggest thing was legibility for mobile experiences. So, we used InVision in the mobile phone screen comp just to double-check font size for longer read articles and that type of thing. And yeah, Mark’s right, there’s a lot of trust there, that if they said, “This is how this will work on mobile,” we could think about that and wrap our heads around that as opposed to needing to see it. For me during the design phase, what was actually most important and what I advocated for was more wireframing and more information architecture.

Bluecadet and Nate were incredibly talented with the design work, so for me I wanted to understand content hierarchy, and I was like, “Once we see a couple of design comps, we should be able to understand what other pages will look like with the kind of design elements to them.” So, we did do a lot of wireframe comps, and there was a lot of back-and-forth and a lot of conversation about content hierarchy and our information architecture, and it was a really great collaborative experience. I think what was really wonderful about it is that the work that they did prototyping both the CMS and doing those kind of sketches for what was structured data, and what was a discrete element, and what was in the WYSIWYG, by the time that we got the actual beta site or the pre-beta site in a browser, there weren’t very many surprises at all and there weren’t very many surprises with the content management system and with what the back-end looked like. The team there was just so open to getting me in there soon, to be like, “Hey, this doesn’t look right,” or, “Hey, can we shift this or can we shift that?” The design process was just so smooth and delightful.

Mark:

Yeah, it’s really helpful—we had the advantage of working with Rebecca, who’s a former colleague, and so it made a certain number of things very easy, where we could show her things in a state that maybe with another client we wouldn’t have been comfortable, but with her we could say, “Now, you’ve worked alongside us, you know what we’re going to do from this point out. We’re just trying to get you in here immediately because you need information, and you’re going to be able to tell us about…” It was just very practical things, like, “Oh, the naming of these fields isn’t going to be meaningful to my newsroom authors, we need to change that,” or, “This grouping doesn’t really make sense, because when they’re preparing an article, they’re looking at the editor notes first, so maybe that needs to bubble up first. When they’re authoring a program, they’re going to think about the episode asset, but they’re also going to think about the podcast RSS feed that it needs to be sent out to, so maybe we need to group those things together.”

Just knowing that we could get that stuff in front of Rebecca early and in a super rough state while things hadn’t really quite set, and that she would be okay with that and she would actually give us the meaningful feedback that we needed at that time—just the freedom to do that was just a huge, huge thing. It allowed us to skip the uncomfortable things that sometimes trip up clients, where if it’s not pretty, it’s broken, and we could then say, “Okay, that’s just unfinished, but we need to have a conversation about these things so we can keep moving forward.” It was great to be able to do that.

Rebecca:

Yeah, and I’m a sucker for function over form, so. I definitely kept the site under wraps from certain stakeholders and even certain people on the team because I was able to anticipate the confusion over, “This just doesn’t look nice,” vs. what I could evaluate myself.

Karen:

This has been so interesting listening to you talk, and I’m envious of the whole process that you’ve been through, and I think a lot of other people are, too. Before we let you go, maybe both of you could offer a little bit of advice to our listeners. With the depth of experience that you have doing projects like this, what would you tell other people who are embarking on a responsive redesign?

Rebecca:

I would say that over-communication is key. If ever, for a second, you think, Maybe this meeting is too much or Maybe we don’t need to go over this again, you’re wrong. Just do it. I think for organizations of any size, but especially larger ones, it doesn’t matter how many times you put yourself out there or put the information out there, two days before launch someone’s going to say, “I didn’t see this.” So, having that traceability is really important. And communicating, communicating, communicating to get trust with your internal stakeholders is going to be the crux of your success as a product manager or product person.

Mark:

From the agency side, I think some of the things are super practical. When you’ve built things in a particular CMS, whether it’s WordPress, or Drupal, or Craft, you start to know its tendencies and sometimes there’s a temptation to over-engineer things and sort of go against what the framework or the CMS naturally wants to do. But just as a practical example, in WordPress you get RSS for free if you tie it to categories. So, maybe use that to your advantage and don’t go too far off the map. Like things like excerpts and featured media, these are like first class fields. And you can create your own custom fields to hold that information, but sometimes it’s good to have a deep knowledge about what your CMS is going to do without overwhelming intervention on your part, and just sort of work with those to your advantage, even though maybe in the back of your mind you’re like, “I could design this better, I could build this better…”

And the other thing was, and something that we did do on this project, is if you can think about the project in terms of phases and really start to think about priorities—what’s an MVP, what goes into the first release—it really opens up and gives you freedom to get to the things that you’re going to get the most mileage out of. So, I think that was one of the great things about this project, is we were able to collectively, and not without a lot of debate and some anguish, but have some really good conversations about, “Yes, this is a very important thing. Hooking up to this API in the future is going to be a really important thing. But what do you need right now, and what’s going to give you the most traction with your userbase? What’s going to address the internal pressures that you’ve been facing?” and then start to slot things into a priority. So if you’re embarking on a project that’s this big, being able to break it out into discrete phases and then use that as a wedge to prioritize things can be really, really helpful for teams.

Ethan:

Well Mark, Rebecca, I have to say, as a long-time fan of public media, I’ve been really looking forward to this interview and it was really remarkable. So, thank you so much for taking some time for us, especially during your launch week. The new site is really beautiful.

Rebecca:

It was really nice to find a conference room to hide in for an hour. [laughs] Thank you for being a fan of public media and thank you for having me on. This was a lot of fun.

Mark:

Yeah, thank you for having us. It’s nice to come back to the show. We’ve all been on and it’s good to have a good reunion show where we can all just talk about these things that, at times, might be super nerdy, but knowing that there’s other folks who might be helped by that is a big deal.

Ethan:

Couldn’t have said it better. It’s great to hear your voices again and great to nerd out with you for a little bit. So, thanks again.

Karen:

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.


Skip to our site navigation; skip to main content