Episode Transcript

Karen:

Hi, this is a responsive web design podcast, where we interview the people who make responsive designs happen. I’m your host, Karen McGrane.

Ethan:

And I’m your other host, Ethan Marcotte.

Karen:

And this week… Well, it’s death and destruction, as we have Shelly Tan and Joey Marburger from The Washington Post here. Welcome.

Joey:

Thanks for having us.

Shelly:

Yeah, thank you. Glad to be here.

Karen:

Well, I’m super excited to have you guys here. I am a huge Game of Thrones fan. I’m hoping we’re not going to kill anybody off on this particular podcast.

But the reason we’ve invited you on in particular today is because of a truly astounding piece of work that you guys did on a Game of Thrones recap of every character that’s been killed off over the past few seasons.

I will say, one of my most favorite conversations that I have with Ethan is I’ll send him a link to something and be like, “Is this responsive?” and he came back and was just like, “Yes, and this is truly, amazingly responsive.” So we’re really excited to have you guys on the show.

Maybe we could start off, you two could introduce yourselves and tell us a little bit about what you do at The Washington Post.

Joey:

I’m Joey Marburger. I’m the director of digital products and design. I oversee all of our product design and development for The Washington Post, and that includes our entire website, the platform, native apps, mobile web, you name it. And the most recent project I’ve been working on is making our entire site responsive through a project we’re call a “refresh,” not quite a redesign, which is leaning to the platform being more flexible to do things, like Game of Thrones.

Shelly:

Yeah, and I’m Shelly Tan. I’m a graphics editor for the Post, a part of our graphics team. So, I design and develop interactive graphics and digital stories for the digital space, and I have a focus on enterprise stories.

Basically we know if it doesn’t work on mobile, then the vast majority of our readers aren’t going to see it.

Karen:

Well, you guys are doing some amazing work and I’m really excited to hear a little bit more about it. Could you maybe just talk broadly about how responsive is perceived at The Washington Post. Like, when you’re thinking about planning a feature like Game of Thrones or even as you’re thinking about doing a refresh of your site, is responsive sort of a given? Or are you having to convince people that this is the right way to go, or it’s the right thing to do from a design and development perspective?

Joey:

We used to have to convince people, but now it is a mobile-first kind of mentality, where basically we know if it doesn’t work on mobile, then the vast majority of our readers aren’t going to see it, and the experience would be poorer, it usually loads really slow, and the story doesn’t really get across to the reader.

There’s a lot to a story or a graphic or whatever besides it just conforming to the size of the browser.

So, people from high-up executives, to editors, reporters, you name it, think about mobile. We don’t necessarily say, “Is it responsive?” We’re saying more like, “It works on mobile.”

Because, to us, there’s a lot to a story or a graphic or whatever besides it just conforming to the size of the browser. Like, our main site is more adaptive, so it handles data loads better, it detects capabilities for Android versus iOS and things like that. So, people are thinking about it. So, all of our reporters, designers, editors, executives, you name it, don’t necessarily say the word “responsive,” we usually just ask the question of “Does it work on mobile?” because there’s a lot more to it than just conforming to the browser dimensions.

That’s been a huge cultural shift in the past year, to really do more mobile, and sometimes only mobile.

The kind of replatforming we’re going through is allowing us to be much more adaptive, to think about speed, data, download time on mobile, but also make sure that the vast majority of what we daily produce does work on mobile really well, and not just appear on mobile, but actually not distort the article so you can’t see half of an embedded video, things like that.

Everyone is thinking about it, and all of our producers, reporters that are publishing, they check whatever they’re doing on their device regularly, so they don’t just pump it out there. That’s been a huge cultural shift in the past year, to really do more mobile, and sometimes only mobile—there are certain things that really only work there.

You know people are going to go on Twitter or Facebook and share something like this just because it’s a very community-oriented fandom.

Ethan:

Let me follow up on that, because we hear a lot of different definitions for what mobile actually means for organizations, and in many cases—especially talking to publishers—there’s often some sort of interesting contrast between the mobile user and the desktop user, with some organizations thinking that they need different things depending on their context, whereas other organizations might feel that they need access to same or similar information.

How does The Washington Post think about mobile and desktop either from a business standpoint or even, Shelly, from a design standpoint, when you’re thinking about designing something really interactive, like the Game of Thrones piece. How are mobile and desktop viewed in your eyes?

Shelly:

Well, on a project-specific level for Game of Thrones, what I think of in terms of the difference between mobile and desktop is really just sort of reorganizing the components of a larger story. So in this case, we knew that there would be a lot of mobile traffic on the Game of Thrones project, just because of the nature of the show, it’s kind of a pop culture phenomenon. So, you know people are going to go on Twitter or Facebook and share something like this just because it’s a very community-oriented fandom.

So from that respect, what we wanted to do with prioritizing different components of the story was thinking “What does our audience want?” and in addition to that, “What do we also want them to know?” In this case, the priority of that project was, of course, letting people know just how many people died in Game of Thrones, but then also knowing that our audience would want an easy way to access that if they were on mobile or a desktop. So, we wanted to really show the spread of the deaths, and the easiest way to do that was leading with our visuals.

Of course, that conversation changes from project to project, especially when you’re dealing with a specific story for each project, and so there’s kind of a lot of debate about how to best prioritize the different components within your story.

Most of our readers read everywhere. There’s a lot of people that read the print edition, look at the desktop site, look at our native mobile apps, look at our mobile website.

Joey:

And then on the business side, it was a big win for me in the past year to have most of the people on the business side saying “user experience,” and on the regular too, because they’re thinking about it and how our content gets in front of readers, and where they are situationally, knowing that most of our readers read everywhere. There’s a lot of people that read the print edition, look at the desktop site, look at our native mobile apps, look at our mobile website.

We’re always looking for good practices we have in place to make things like this project successful.

With something like Game of Thrones, I think what we smartly did, and what Shelly did well, is think about the second screen experience—which I really think we’ve kind of have to flip that, with TV as the second screen and mobile device is the primary screen. So, a lot of people are probably going to watch Game of Thrones and look at this graphic as almost a reference. So, I think that was a little bit of the nerve that it hit that made it be shared a lot and be read by a lot of people.

So, we’re always looking for good practices we have in place to make things like this project successful. So, we prepare to have the platform to be able to deliver content like this so we’re not, at the last minute, saying, “How do we make this work?” because then that starts to detract from the design and the overall presentation, and you’re kind of rushing it because you’ve got bugs. So, we get that all out of the way leading up to certain projects so we can execute quickly.

I like to joke that this project was just kind of my excuse to binge-watch a bunch of TV.

Karen:

I’m interested in how you plan a large-scale feature like this. I don’t want to make it seem like I’m asking “What’s the difference between scoping a responsive project versus a non-responsive project,” because that’s not what I mean. But if you were thinking about how you allocate time, and resources, and how you plan the level of effort that’s required, is there anything different about doing a responsive project from how you might’ve thought about this in the past?

Shelly:

Well, for the Game of Thrones project, it was definitely different in how I approached it just because of the sheer amount of data that I personally compiled for it. [Laughs] I like to joke that this project was just kind of my excuse to binge-watch a bunch of TV.

When we approach stories, really thinking about it being responsive and working well on mobile, is it forces us to make really simple decisions.

But in terms of how we approached that, what I really considered, in terms of how to present the data, was, again, “How do we want to present the scope of the data?” In this case, it was just the vast number of deaths. Then at the same time, building it modularly with different components that would reorganize themselves. And so, of course, the lead on this was the illustrations and visuals, and that gives readers an access point into more in-depth data, and figuring out how they want to dive further into this. We didn’t want to limit the way that users would be able to interact with the data, basically.

In terms of how it compares to other stories, again, it’s very difficult to say just because each story is so different, and therefore what we want the audience to get out of each story is very different, and so it’s hard to say if the scope changes. And it’s not so much the scope I mean, rather than kind of the entry points to the story, if that makes sense.

Putting things in that mobile/responsive frame starts to help us make better desktop decisions, I think.

Joey:

I’ll just add to that really quick. I think what’s great overall when we approach stories, really thinking about it being responsive and working well on mobile, is it forces us to make really simple decisions. So, if you have a vast amount of data and you’re thinking, “What’s the mobile experience,” then you start to make critical decisions so the information comes across well, because you don’t have as much space and the linear aspect of it is different. So, that’s where pacing really comes in, in terms of design. I think that we approach every story differently, but putting things in that mobile/responsive frame starts to help us make better desktop decisions, I think.

The lovely thing about building a project around a story is that the story always pulls you back and makes you look at the entire project as a whole, holistically.

Ethan:

Tell me a little bit more about that process. Shelly, you’ve touched on one of my favorite words, which is thinking about components—these individual parts of a larger, more complex responsive interface. How did you make decisions on how those needed to adapt from widescreen to small, or vice versa? How did you basically make decisions about what to prioritize on different classes of screens, or how people were going to be interacting with them?

Shelly:

Sure. Well, again, it just kind of all goes back to the story. The lovely thing about building a project around a story is that the story always pulls you back and makes you look at the entire project as a whole, holistically. And so the whole kind of informs how I want to look at each individual component, because to a certain extent with the story, when you’re building in a digital space, you have the ability to break it up so it’s not as linear.

With the holistic view from the story in terms of how the overall narrative should go, that informs how I would prioritize a component.

But at the same time, when a reporter writes a story, they’ve likely constructed an arc in narrative. And so in that respect, with the holistic view from the story in terms of how the overall narrative should go, that informs how I would prioritize a component or how I would try to organize pieces when they’re being adapted from desktop to mobile.

For example, in certain cases maybe you do want a component of a story to be more non-linear because the narrative allows for you to be, and it makes sense because you don’t have a previous reference to a character in a story and then not have it in the second part. In that respect, the components are easier to reorganize because of the way the story itself is constructed.

Sometimes we do move directly from that relatively low-fidelity sketch directly to coding it up.

Ethan:

Just the scope of what you guys have designed in this interactive is kind of ridiculous. Starting with a mountain of TV watching, how did you actually start making this thing? What kind of applications and tools were you using? Were you using paper sketching?

Shelly:

In terms of how I personally prototype, I tend to go kind of low-fidelity at first and just really quick iterations. So, there is a lot of paper prototyping at first, a lot of quick, rough sketches to get the general idea of the layout.

And then from there, as we start to narrow down how we want it to look, then we start moving from these kind of low-fidelity sketches to more detailed wireframes. And then we do some high quality comps in Photoshop and Illustrator, but sometimes the timeframe and then also the vision of the project doesn’t allow for that really, really detailed final comp. So, sometimes we do move directly from that relatively low-fidelity sketch directly to coding it up.

Then from there, I use Sublime Text for coding. I always have about twenty tabs open when I’m coding something up. And yeah, we kind of go from there and just keep iterating over and over again.

It’s a separate command line tool that we use to publish our graphics.

Karen:

One of the things that really fascinates me about tracking the media industry, the news industry, is learning a little bit more about the different content management systems and publishing workflows that large news sites have. This may be because I don’t get out enough, but I personally find it really interesting to think about the intersection of how these types of complex interactives work with the overall publishing workflow.

How does something like this integrate with your content management system—or does it even? Or how does creating something like this fit in with the larger editorial workflow?

Shelly:

Well, as for the graphics team, most of our interactive graphics are published using a tool that some of our own team members—Kevin Schaul and Katie Park in this case—they developed a publishing tool for us. So, it’s a separate command line tool that we use to publish our graphics. But in terms of the wider site-wide stuff, Joey, I think you could speak more to that.

We’re building our own CMS at the moment, which is kind of a hybrid render.

Joey:

Yeah, like the Game of Thrones piece is handled in that end of workflow, which can be perceived a little bit as a one-off, but that’s okay to us, because we have consistency and it’s still fairly templated, and it inherits a lot of core styles and everything like that, and all of our analytics packages and everything.

But right now, we’re actually going through a giant replatforming. Right now, we basically have WordPress and another CMS called Méthode, and we’re moving predominantly to WordPress for all of our more basic content publishing.

But we’re building our own CMS at the moment, which is kind of a hybrid render. So, it would be able to take in pages, even like the Game of Thrones piece, and handle large chunks of the page, and keep it structured and make sure it’s consistent. So, if we need to go back and change styles or certain parameters, we can easily. That’s kind of the transition year we’re in right now, really preparing for the elections.

Graphics is one of the hardest things to put into it, so we just realized we can have kind of a separate publishing workflow on the side, and that’s okay with us.

Then we’ll have our own rendering system that can sit on top of any CMS, but we have our own CMS we’re building to the side. For most of our normal graphics templates, they do go through this render, but that looks a lot more like a normal article page, it’s not as custom as the Game of Thrones thing. And that’s really what works for us, and we’re kind of building it as we’re learning from it, and learning from what the needs we have are, without making it too custom. We’re trying to make it really flexible, and graphics is one of the hardest things to put into it, so we just realized we can have kind of a separate publishing workflow on the side, and that’s okay with us.

It wasn’t really so much an interstitial design review process, as so much an ongoing conversation with our editor about how we wanted to present the information.

Ethan:

I’d love to hear about how you guys conducted design reviews, specifically around the Game of Thrones piece. As you’re moving from paper prototyping to in-browser prototyping, Shelly, how did you actually share with some of your co-workers? How did you actually share with other members of the organization? Tell me a little bit about how you structured that.

Shelly:

Well, in this case, the team was basically me and another graphics member, Alberto Cuadra. And our main editor for the project was Samuel Granados, so he was kind of the main point person in terms of the design review process. As we illustrated the characters, and the maps, and the location icons, we would constantly be in a conversation with him about how we could best present those characters. Then as sketches and wireframes started coming out, we would just keep an ongoing conversation about design elements, UX elements. And so, it wasn’t really so much an interstitial design review process, as so much an ongoing conversation with our editor about how we wanted to present the information.

In terms of sharing it with other people on the team, in terms of showing people preview, we kind of just set up a local server and were able to share a preview of the site around the team, and so people could get an idea of it, and also user test it, and make sure that the design that we imagined would work does actually work.

But judging by things like pure pageviews is not necessarily the best metric. With something like the Game of Thrones piece, time spent is a really great metric.

Karen:

How do you evaluate the success of an interactive feature like this? The metrics that you use to know if it worked, if it hit the mark, are they the same? Are they different? How do you even talk about that internally?

Joey:

Well, we share analytics with everyone. I mean, any reporter has access to their analytics, any graphics editor has access to analytics on any graphic, anything on the site. But judging by things like pure pageviews is not necessarily the best metric. For us, it’s the same kind of high-level metrics as I think everyone has—number of unique visitors. With something like the Game of Thrones piece, time spent is a really great metric.

One of the really interesting things we’re looking into right now is diffusion. So, why do things really spread around on social media, and what really resonates with people?

But also, what’s the social conversation? Like, watching it spread. One of the really interesting things we’re looking into right now is diffusion. So, why do things really spread around on social media, and what really resonates with people? And that’s not exactly like a data point that you can point to from months ago, but it’s kind of more inspiring showing that what you did had real impact and that people were talking about it, because then they’re talking about The Washington Post, which is a huge brand win, as well. Because pageviews don’t make that great. People are really talking about what you’re doing, and what you’re doing is innovative and interesting, kind of pushing the boundaries—that’s a great success metrics for us.

It’s really hard to make a bad story good through design. When the story is great and the design is great is when we see the most success.

Then we just look at all the normal analytics and see why something performed better than something else, and the answer usually always is “it was just a great story.” It’s really hard to make a bad story good through design. When the story is great and the design is great is when we see the most success. So, sometimes that can mean traffic on this particular piece was midrange, but it was talked about a lot, and while building it we learned a lot, too. That’s just as good as something that got crazy traffic.

I personally measure the Game of Thrones success by how many angry Reddit posts I got about the accuracy of deaths.

Shelly:

Then on a more lighthearted note, I personally measure the Game of Thrones success by how many angry Reddit posts I got about the accuracy of deaths. [Laughs] So, that was my personal metric.

Our normal article page, we want that load time to be around a second on mobile.

Ethan:

[Laughs] That’s amazing. If I could ask about performance of another kind, which is speed. This has been sort of this evolving thread in the responsive design conversation in the last couple of years, if there is such a thing. I’d be curious to hear, whether or not we’re talking about this graphic or some other project, how does The Washington Post think about performance? How do you actually define what constitutes a fast downloading, snappy UX from the user’s standpoint?

Joey:

Well, performance is actually one of our number one priorities. Our normal article page, we want that load time to be around a second on mobile—and like a decent mobile seller connection, because we don’t have complete control over what device people have. So, we at least want to have a really performant baseline, but we know that with heavy visuals and a lot of them on a page, even with all of your content delivery network setup and lazy load trickery and all of that, it’s still going to get heavy at a certain point.

We actually have this giant dashboard right outside of our CTO’s office that shows load spikes, and if it hits a certain threshold, it sends a ton of email alerts to everybody.

So, we’re okay with it pushing into the two, three, four-second mark if it’s worth the wait. I mean, if we’re just dumping a ton of animated GIFs into an article, that’s, eh, not so great, even though we have the play/pause button on mobile. That’s still a ton of page weight, but that’s maybe not worth the weight.

With something like the Game of Thrones piece too, it’s still very, very performant for the most part, and that’s because we have a phenomenal engineering team that makes sure our servers are glistening and our downward load for users is low. We actually have this giant dashboard right outside of our CTO’s office that shows load spikes, and if it hits a certain threshold, it sends a ton of email alerts to everybody and we have to go look at it.

Don’t get a bunch of mocks and prototypes together and feel like you’ve got it all buttoned up before you write the first line of code.

Karen:

I love hearing that both of you said you learned so much from doing this Game of Thrones feature. Do you have any advice for any other organizations that are embarking on a complex responsive redesign, or are trying to make their processes more iterative to support the kind of work that you guys are doing? What advice do you have for other people?

Joey:

I could say “just go.” Just get going; start, try things. Even if it’s redesigning your whole site to be responsive, don’t get a bunch of mocks and prototypes together and feel like you’ve got it all buttoned up before you write the first line of code, because you’ll wake up and it’ll be the next year, and you’re behind, and what you’ve probably done is already outdated.

We basically just started running, not realizing that we were embarking on a big marathon. It’s really hard to stop once you have momentum; it’s really hard to get started when you don’t have any acceleration.

We embarked on making our site responsive and putting it in our new platform by just one day me and our principal architect, or head of engineering, Greg Franczyk, we just were like, “Well, let’s do a few article pages and start there.” Then we realized they were more performant, people liked them, and we just started launching it on every article page. Then, before you knew it, all of the articles were responsive. We were running into problems and bugs here and there, but they were all very solvable, they weren’t that difficult. Then we took on adoption, we did all of our section fronts, blog fronts, and our homepage is coming in the next month and a half, which is a daunting task.

We basically just started running, not realizing that we were embarking on a big marathon. It’s really hard to stop once you have momentum; it’s really hard to get started when you don’t have any acceleration. So we just start things, and if it’s not going in the right direction, we either move it in the right direction or we stop and learn from it, and we just kind of clean up as we break things along the way.

I’ve always found it incredibly helpful to start the conversation with the reporter, or the writer, the data compiler as early as possible.

Shelly:

And then on a more projects and story-specific level, I have a little bit more leeway just because I’m able to experiment a lot more from story to story as the story allows. In those cases, I’ve always found it incredibly helpful to start the conversation with the reporter, or the writer, the data compiler as early as possible just so you can, as a group, examine the different entry points into that story. Then from those entry points, start figuring out how you can build components or modules around those entry points. So, that’s always been really helpful for me.

Ethan:

Well Shelly, Joey, I’ve got to say, thank you so much for taking a few minutes to chat with us. I know I’ve really appreciated hearing a little bit more—not just about the Game of Thrones piece—but the responsive work that The Washington Post is doing in general.

On a more personal note, having seen maybe only like two episodes of Game of Thrones, I spent probably a couple of hours scrolling through this interactive. So, I’d like to thank you for spoiling the entire show for me in possibly the most beautiful way.

Joey:

[Laughs] My favorite part is the pigeon.

Shelly:

[Laughs] Always the pigeon. The pigeon death count is up to two pigeons now, just so you know.

Ethan:

[Laughs] Man, alright. Well, spoilers guys. But anyway, seriously, thank you so much for chatting with us. Karen and I both really appreciate it.

Joey:

Thank you for having us.

Shelly:

Yeah, thank you very much.

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.