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, we are beside ourselves with excitement. We are joined by DJ Brinkerhoff and Jeremy Green, who are here to talk about The Atlantic. Welcome.

DJ:

Thanks. Happy to be here.

Jeremy:

Hello.

Karen:

We are really thrilled to have you here.

Ethan:

But before we dive in, I’d like to say a few brief words about our sponsor.

Now, Karen and I use FreshBooks extensively here at our little podcasting media empire, and we’re thrilled to have them as a sponsor. And we’re even more thrilled because they’ve launched an all-new version of their popular cloud accounting software! It’s really easy to use, and is a simple way to be more productive, organized, and—most importantly—get paid quickly.

This new Freshbooks has a ton of great, intuitive features. A few favorites: it lets you create and send professional-looking invoices in less than 30 seconds; you can use Freshbooks to set up online payments, which can get you paid faster; and many more.

Sound tempting to you? Well, FreshBooks is offering a 30-day, unrestricted free trial to listeners of the Responsive Web Design Podcast. To claim that trial, just go to freshbooks.com/RWD and enter RESPONSIVE WEB DESIGN in the “How Did You Hear About Us?” section.

Once again, thanks so much to Freshbooks for sponsoring our little podcast.

Karen:

For those of you who have not seen it yet, The Atlantic has launched a really stunning new responsive redesign, and I know Ethan and I are both really excited to talk about it. Before we dive in, maybe you might both just introduce yourselves and let us know a little bit about your role at The Atlantic. DJ, do you want to go first?

DJ:

Sure. So, I am the product design lead at The Atlantic. That means that I lead design for the website, the app, any of our digital products—that could be editorial or e-commerce or otherwise. And I’ve been here for about a year and a half, and this was the sort of first big product that we shipped under my leadership on the design team.

Jeremy:

And I’m Jeremy Green. I am senior front-end developer, and also lead front-end developer for The Atlantic. To piggyback on what DJ said, yeah, this is like the first major redesign since I’ve been here as well, and it was a lot of fun doing it.

Karen:

Well, without any disrespect to any previous redesigns—I know we talked to Libby Bawcombe on a previous call about the last redesign of The Atlantic, and certainly not any criticism of a former redesign that I, myself, personally worked on—I think I’d like to say that this redesign looks really, really spectacular. It is a fantastic example of responsive design in action.

DJ:

Thank you very much. We’re happy with it.

Karen:

I’m especially interested, given that you all probably have some experience with this now, how did responsive design as a concept fit into your conversations about the redesign as a whole? Given that you now know how it works and have seen it in action for a while, is there anything that you knew to be problematic that you wanted to change or anything that you felt had to be handled differently with this next version, next iteration?

DJ:

There’s a couple vectors to that. One of them is, as a media site, we deal with ads, and standard IAB ads are not responsive. So, constructing a layout and system that deals with that—you have to deal with that from the beginning, and it proves to be challenging when you’re trying to accommodate changing stories and that kind of stuff. And then the other aspect, as you mentioned, is this is not our first one. We didn’t have to convince anybody that this is what we needed to do, but there was still the occasional, “Why is all this white space there?” or, “There’s a widow on this head,” or something like that, just reminding that this is the state of the web these days. But overall, it was a very smooth process as far as this is responsive and this is how it’s going to be.

Jeremy:

Right, and I think from the beginning we’ve kind of articulated that we were going to do mobile-first; we got to see what the mobile-first designs were going to look like. One of the key things that I think we did early on was we prototyped early. So, I took what was the concept at the time, did boxes and used Flexbox to make sure that all viewports worked at all the various sizes to make sure the layout was working properly.

Ethan:

Well, as mobile-first is one of my favorite phrases, maybe this would be a good time to note that I just love the small screen view of this responsive redesign. I’ve spent a significant amount of time on the website on my phone and I found it a real joy to read. So, maybe we could talk a little bit about how you actually took on a mobile-first design process. Did you have to actually think about the needs of mobile users versus desktop users? And if you did, were they looking for different kinds of information, or were they more or less looking for the same content on different-sized screens? Tell me how you talked about that.

DJ:

Our previous design, you did lose some content on the smaller screens, and we wanted to make sure to avoid that on this newer approach. So, we did some user testing and had people come into the office and asked them questions and observed them using the site, and we got feedback about how people wanted to just see the latest stuff but that they also value the editorial voice and specialty of The Atlantic.

The other aspect of it is that, according to our analytics, we have a lot of desktop users on the home page, it’s majority desktop versus majority mobile on article pages. So it’s a different use case, but we wanted to make sure that the same content was accessible everywhere. So we tried not to treat them separately in terms of content, but we did treat them separately in terms of how you access it. So on a smaller screen, getting to the information is a little harder because of limited screen real estate, so we tried some newer approaches by having some horizontal scrolling modules and making things a little more compact. That was a new approach, and so we’ll see how that works out in the real world. But so far, people seem to be engaging with those new modules.

Jeremy?

Jeremy:

One of the best things about working with DJ is he says it all for you. So, I can just sit quietly and stare at him. [laughs]

DJ:

[laughs] I think the other thing I would say is that we worked hard to make sure that design and dev were collaborating on the mobile-first perspective and that everything we did scaled up and down properly.

Jeremy:

Right, we had a back and forth as to what was going to work and what wasn’t. And yeah, the horizontal scrolling thing is like my favorite feature on mobile, so I just love seeing more and more of that come into play. And then how I built it out for the video page in the middle of the latest was really awesome.

DJ:

And the interesting thing there on the video is that there’s actually more content available on mobile than on desktop because we had more horizontal real estate, so you actually had a couple more videos on the smaller screen size than you do on bigger screen sizes, which is sort of the inverse of what you would expect. But we had the room, so we figured we should add a couple more in.

Karen:

I love it. I might follow up a little bit on that and just ask sort of broadly, how do you scope a design process like this? How do you know what all the pieces are that you have to design, and maybe how long it’s going to take or what the process is going to be for designing and reviewing them? And I might ask specifically, having done a lot of publication redesigns in my life, it tends to be very template-focused, so you’ve got your home page, your section top, and your article template… Were you still thinking of it as being a very template-driven approach? Or did you get down to designing more modular components and then clicking those together like LEGOs?

DJ:

The latter. So, we approached it as a component system that we could then propagate to other parts of the site as needed. That part hasn’t started to happen yet, but we designed it with that in mind. So, there’s promo modules for our newsletter sign-up and that kind of stuff, those should be able to be used elsewhere. The media object in the river, the intention is for that to be propagated everywhere. So, thinking about it at the component level was definitely an operating idea for us.

And then to go to the beginning of your question, the whole process, a big part for us is working with the editorial team, and so we do internal stakeholder research to talk to them about their strategy, pain points, where they hope to go with the site, what they hope to convey. So, something we discovered was that the old home page was completely curated and that was operationally taxing for them, and the value that that actually gave the editors or readers didn’t necessarily pay off. So, one of the goals of this design was to reduce the curation but also retain the voice and maintain a section that is curated. So in our case, the top of the page is curated and then everything below is dynamic and programmatic.

Jeremy do you want to talk about the scoping?

Jeremy:

Sure. So, the way the scoping happened is we currently are using Confluence, so when I got the working final designs from DJ, basically I broke out the home page into three different sections, inside of each section I wrote out the epics in JIRA that will pretty much drive each component, and then from there I broke out the tickets that make up the epics so that we can build each component. And we also had small chunks that any developer on the team could go and do any section of the home page at any particular time. I think that scoping was one of the reasons that we were able to deliver the project on time and in scope.

Ethan:

I’d love to hear a little bit more about the design process itself. How did you actually start talking about the look of this new responsive design? Was it very component-focused even from the very beginning? What kind of applications and tools were you using? I’d just love a little bit more detail on how this layout came to be.

DJ:

Yeah, so this page was a collaboration between myself and our now creative director, David Somerville. When we started this project, he was my boss, and he’s now the creative director for the company. So we were collaborating on the page, and he was very interested in taking advantage of screen space across browsers. So, we now take advantage of the big screens up to 1400 pixels and fill that area with content. Getting that layout to work across those screens was one of the most challenging aspects, and there’s still work to be done there, but that was one of the operating principles. And then we approached it as trying to provide a little clarity around sections of the page and clean up the typography and sort of set us up to apply a little bit more of The Atlantic brand to it in the future, because we’re sort of in the middle of figuring that out and we needed to do this redesign now. So, we tried to set it up to where it was good and thoughtful but not overwhelming or too voice-y or anything like that. We retained the typography we were using before but just used it in new ways.

We took advantage of the new nav that we had shipped a couple months prior. We took a lot of our cues from the editorial team insofar as what modules we wanted to use. Like, the writer module was completely driven by our editor-in-chief, Jeffrey Goldberg, who wanted to expose our writers more to our readers. So, we came up with this writers module that is dynamically driven by published time, and it has certain rules around it. We wouldn’t have done that if it wasn’t for Jeff Goldberg. I think that there’s a couple redesigns that have shipped from other companies recently that have this approach of reverse chron river anchoring the second half of the page, and I think there’s a reason for that, because people who use the home page are generally power users and visit often. So, the home page creation team only updates the top so often so it needs to be easy for the readers to get the newest content as fast as possible. So by exposing simply reverse chron river at the top, it allows them to access the stories that have arrived since they were last here. So, thinking about the way people use the page as well as the strategy of the editorial team is really what drove the layout and design of the page.

Ethan:

I love that. Just to follow up on that for a second, and this might be a little deep in the weeds, but I’d love to hear just a little bit more about how design and front-end actually collaborated on this responsive design. Jeremy, you mentioned prototyping earlier, so I guess I’d love to hear a little bit more about, day-to-day, what applications and tools do you find that you’re using to talk about responsive design in general?

DJ:

I’ll start and then Jeremy can add on. I think that right now the industry is in the middle of trying to figure out why we’re still drawing interfaces that then get coded, and my team is dealing with that as well. For day-to-day we use Sketch to do UI design, and we just started using Zeppelin actually to hand off designs, which seems to have gone pretty well—we didn’t use that for this particular project. So, we use Sketch, and from the beginning when we had sort of a layout idea that we thought was pretty complicated, that’s when we brought in Jeremy to prototype it with HTML and CSS. Do you want to speak to that, Jeremy?

Jeremy:

Right, so I guess the crux of the entire front-end for the home page is Flexbox. So, what we did was I used flex-basis to basically build our grid system with it, using static margins and things like that. Some of the build tools we used were just your goal process, your compilation of CSS, we used Sass… So yeah, looking at the layout and then going through each individual breakpoint and kind of aligning things was critical for us, and me and DJ were talking day to day as to what was working and what wasn’t. There were a couple parts in the top of the home page that needed a separate breakpoint because it got too big at one point and too crammed at another. So, we set another breakpoint, it was no problem. We collaborated back and forth, basically daily, as to where we were, what we were doing, what we liked, what we didn’t like. And then as we got more code complete on the curation and the overall general home page, we had what we call design reviews. So, we had three iterations of a design review where DJ would sit down with one of us and go over, “Hey, let’s update this, let’s change that a little bit,” and we just went back and forth like that the entire time.

DJ:

And I think the other thing that I would call a tool now is that we’ve been trying to get a design system set up for the team for the past year, to be honest, and it’s harder than you might think. And so we’ve sort of stepped back and, for this project, sort of implemented just the primitives. So, we established an eight-pixel grid, so all of our spacing is in variables of eight, established a strict type scale, and I think those tools were really powerful for being able to have a developer go in and build a component and have it end up pretty close to the intended design or the ultimate endpoint. So, that was a powerful tool that we established.

Jeremy:

Right, and it gives us the ability, as developers, to kind of keep the designers at bay. When they want to change something to fifteen pixels, we go, “You either have eight or sixteen. You have to choose between one of them.” And with this new front-end, one of the things that we’ve been working on for the past year has been trying to identify what our component system looks like, what our build system looks like, and a lot of the tools that we use going into this may not be a part of our current style guide, but they could be backported into it. They’re using the same document style that we’re going to be using to generate our Sass documentation and our style guides and things like that, we just don’t have the tooling in place yet to render those out.

Karen:

That’s fantastic. I’d love to circle back to a point that you made earlier about working with the editorial team. Could you just say a little bit more about how the voices from editorial fit into a redesign like this? And I ask because I think there was a point in time in the industry where a responsive redesign was thought of as just “let’s get this to work on different sizes of devices, on different sizes of screens.” But when you all are going through a redesign like this, it sometimes turns into let’s make this site more aligned with the vision of the editorial direction of the site and let’s add in new content or new features or new ways of presenting the information. How did that fit into a “responsive redesign”?

DJ:

Yeah, I mean the primary way that affected it was in the curated portion at the top of the page. So, the coverage of The Atlantic has expanded rapidly and broadly over the past couple years. We have a powerhouse politics team and a very large science/technology/health section, and so we wanted to, as a company, convey our breadth while also not forgetting the bigger evergreen features that we do that dig deep on issues and that we’re known for. So, we established sort of a couple different spots in the curated section that helped execute on that strategy. So, we have almost like a news ticker that lets people know that The Atlantic is keeping up to date with stuff and is publishing news at it comes in. We don’t break news but we certainly distribute it as it comes in. And then we have our traditional lead story as well, so that will likely either be an “of the moment” news story or a big feature that we’ve done that we just published.

The other spot that’s interesting is what we’re calling the off-lead, which is if you’re on a desktop screen, it’s the sort of smaller story off to the right, and if you’re on a smaller screen, it’ll just be down the screen a little bit. That is a place where editorial wanted to sort of serve up evergreen content that maybe got pushed out because of a big news story or that was relevant to a situation. So when there was that Manchester attack a couple weeks ago, we were able to surface What ISIS Really Wants, which was a big feature we had about ISIS, and that was both timely and relevant even though it had been published a year or two before.

So, trying to execute on that strategy with giving them different tools as well as adding a couple related links or the ability to have related links so that we can provide more context, which is what The Atlantic does best, and giving them the ability to sort of showcase the breadth of our work. Again, that whole strategy was driven by editorial and it took us interviewing them and talking to different people and synthesizing everybody’s perspectives to come up with that direction. So, I think design in a media company is understanding editorial strategy and synthesizing it into a product. I think it’s to be determined if we were successful or not, but that’s what we try to do.

Karen:

I love it. And can you talk about how then that work is reflected in changes or even maybe a replatforming of your CMS? What CMS are you on and how did you have to work on the back-end to make this possible?

Jeremy:

So, currently The Atlantic is on Django. So, I guess the elimination of a lot of the curation of the entire home page was kind of a benefit to the platform team and the way they were developing. So, currently the way it happened is the platform team has—they curate the home page, the first top section is what they do, and they have a drag-and-drop WYSIWYG where they can add and remove articles and they can just kind of curate the entire top portion of the home page, top third.

DJ:

Our CMS is completely custom, and so that curation interface was rewritten and updated for this new design. We didn’t necessarily replatform or anything like that, but we took some things we’ve learned and updated that interface to be a little easier to use, and made the whole thing much faster. That was the biggest improvement, was between reducing the number of stories that are curated and then updating the code, the process is a whole lot faster, so we can update that area much faster.

Jeremy:

Right, and we also worked on an interoperability layer for the curation, and the templates that drive it are the same templates that power the front-end, too. So, that was a big tech push for us this year.

Ethan:

Well, since you mentioned “faster” a few times, I would love to hear if performance and site speed were things that came up in the discussion around this latest redesign, and if so, how did you measure that? I’d be specifically curious, since you mentioned advertising before, how you actually worked ads into the mix, since those tend to be a a bit of a bugbear.

Jeremy:

Custom ads was basically our main push for the new home page. We’ve been working internally with speeding up our ads, trying to sell custom ads as a platform—basically, “We can sell the fastest ads because we can build the fastest ads, because we know how our site works and we know how to integrate with our site faster.” So, I think that was a part of the beginning of the design process as well, is understanding, What can we do with advertising? How can we sell full-bleed ads, what can we do there?

To go to performance, one of the things that we didn’t do with this project was we didn’t set any kind of performance goals. After we launched, we actually noticed that there are some performance regressions that we need to address and bring up to speed. That said, the way we measure performance is right now we have a system called SiteSpeed.io, it runs nightly on sixteen pages, profiles the site, takes all the critical metrics from WebPageTest and applies them to a Graphite Grafana Database where we can see charts and stuff like that. Another thing I also have running is a custom slack integration that will nightly profile the site and pop in the render times and things like that for certain pages, as well.

DJ:

Yeah, and we’ve found that exposing people to the metrics via something as simple as Slack, and just getting awareness around it helps to drive interest, so that’s been a big win there. And then as far as going forward goes, we have another project we’re working on. We also work on CityLab.com, so a lot of the performance stuff we were interested in we actually are implementing there first, and if it goes well, we intend to implement it on The Atlantic as well.

Jeremy:

Right, and so we’re evaluating those things like service workers for City Lab, and then once we kind of vet City Lab, we can bring those over to The Atlantic.

Karen:

Well, let me also ask about other business metrics or ways to evaluate or measure whether the site is successful. Can you talk about what sorts of analytics or other data you’re looking at to see if the site is performing or if the site is performing better than the previous one?

DJ:

Yeah, so we measure standard click-through rates, scroll depth, time on page, that kind of stuff. A page like this, the time on page we actually want it to be short because we want people to be getting to an article as fast as possible. So, we want that metric to be low, whereas click-through and stuff like that we want to be high. We use Omniture and Optimizely, so we started running tests immediately to see how we could adjust different parts of the page to perform better. The first test we ran was called ad viewability, which is when an ad is in view on the screen for a certain amount of time, and we adjusted the load time for the ads to optimize their viewability, raising the viewability by seventeen percent over the previous design, which is a big deal. And we’re currently tracking click-through rate and that kind of stuff. We haven’t had many changes yet, because as we launched the page we also had a gigantic story that sort of drove an unusual amount of traffic, and so we’re taking a few more weeks to let our traffic normalize to get some clearer metrics on that stuff.

Ethan:

Well, this has been a wonderful chat. But before we let you both go, I would love to hear if you happen to have any advice for our listeners who might be about to start their own responsive redesign; one or two things you’ve learned over the course of redesigning The Atlantic. DJ, do you want to go first?

DJ:

Sure. Man, that’s a good question. I think that the biggest thing that I’ve learned is making sure that you understand the stakeholders’ needs and desires, and that those are communicated throughout the team, and that they’re taken seriously by the design team in a way that both brings them along and also drives the state of the art forward. I think that if designers are not communicating, then they’re not designing. So, a lot of our time was spent simply talking to people, and I think that made a big difference.

Jeremy:

Yeah, for me it was about getting developers into the process earlier. I was in stakeholder meetings to identify any kind of rogue piece of content that wasn’t going to work for developing. Yeah, basically just getting in early and prototyping. I think prototyping was an important aspect of this redesign. It allowed us to not only iterate quicker, but we also got to sample the same work; we got to use the same work over and over again, which was actually a benefit for us getting the project done on time. Another useful planning part was just scoping properly and understanding what the scope was going to be, getting everyone to agree on what the scope was, and then just executing against what the outlying scope of the project was going to be.

Karen:

Well DJ, Jeremy, thank you so much for taking the time to chat with us about this fantastic redesign. I hope everybody in the audience will go out and look at The Atlantic site and maybe subscribe, because I just think it’s wonderful.

DJ:

Yes, thank you.

Jeremy:

Yeah, thank you.

Ethan:

Thanks to everyone for listening to this episode of a Responsive Web Design Podcast. Thanks also to our sponsor, Freshbooks. Go to Freshbooks.com/RWD and enter RESPONSIVE WEB DESIGN in the “How Did You Hear About Us?” section for a 30-day free trial.

If your company wants to go responsive but you need help getting started, Karen and I offer a two-day onsite workshop to help you make it happen. Visit responsivewebdesign.com/workshop to find out more, and let us know if your company is interested.

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every podcast episode at responsivewebdesign.com.

Thanks again for listening, and we’ll see you back here next week.