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, on the outside I am a very professional podcaster. On the inside, I am screaming oh my god, Serious Eats is here! I love Serious Eats so much! Tracie, Paul, it’s great that you could join us.

Tracie:

Thanks. We’re really excited to be here.

Paul:

Yeah, thank you.

Karen:

I am, I swear, the world’s biggest fan of Serious Eats. My friends joke that I basically provide an API to any recipe that you have ever published, and if anyone ever has a question about how to make something, I can instantaneously pull up a recipe from Serious Eats. So, I could not be more excited about having you on. I would love to hear, just to get started, just a little bit about you. What’s your role at Serious Eats? Tell us a little bit about what you do at that fantastic publication.

Tracie:

Okay, well this is Tracie. I’m the design director there, and I’ve been with Serious Eats for about two years, but I was freelancing before that, so I’ve been responsible for both the visual design and I do some front-end development, too. Yeah, so that’s my role.

Paul:

And I’m kind of the other half of that. My title is developer, but really, Serious Eats is such a small operation that I handle any development aspects that go beyond Tracie’s skills and work on the infrastructure of the site. So, anything that gets power falls into my domain.

Tracie:

Yeah, so it’s basically the two of us, which has been—it’s been awesome actually, because we’ve developed a really collaborative relationship over the years. And occasionally we get some outside help, but yeah, it’s what you see, it’s been the two of us.

The first thing that we did was implement a separate mobile site way back, I think it was like 2011. And as time went on, we were like: this is getting to be a lot to maintain.

Karen:

I love hearing that, because I think that is one of the things we hear consistently that makes for a really successful responsive redesign. So given that it’s really just the two of you, can you talk a little bit about the decision to redesign and to go responsive? What kind of conversations did you have to have, and did you have to convince anybody else that this was the right way to go?

Tracie:

We actually didn’t need to convince anyone. I think part of it is a lot of other sites have been switching to responsive design, and in terms of our traffic, we were seeing just a huge explosion in terms of mobile traffic. The first thing that we did was implement a separate mobile site way back, I think it was like 2011. And as time went on, we were like: this is getting to be a lot to maintain, two separate templates. So we were like we should really do this, and everyone was on board with it; we didn’t have to tell people, “This is a good thing,” everyone was like, “No, we need to do this.”

Paul:

Yeah, I think it was an instance of being behind the curve, just kind of being late to the party. We didn’t have to sell anyone. Everyone was on their phones using our site and other sites, and it was clear that what we had was not up to par.

We really wanted to make sure that people had the same level of access to information regardless if they were on mobile/tablet/desktop.

Ethan:

Just based on the redesign, it looks like you guys caught up in style. I’d love to hear a little bit more about that transition from a separate mobile website into something a little bit more device-agnostic. Specifically, did you have to have any conversations internally about the needs of the mobile user as distinct from the desktop user? We hear from a lot of publications and companies that maybe these are completely different groups with disparate needs, whereas some people argue that they really just need access to the same stuff. Where did Serious Eats fall on that spectrum?

Tracie:

We definitely felt like people are jumping between devices, that they’re getting to stuff through social media, it’s like they’re on their Twitter app or whatever, but they might come home and they might access stuff like through desktop. So, we really wanted to make sure that people had the same level of access to information regardless if they were on mobile/tablet/desktop.

We really wanted to think about more the modes that people are accessing information on Serious Eats. There are transactional users who are coming through search, through Google, versus people who are maybe looking for inspiration a little bit more. So, thinking about it in that sense rather than being like, “Oh, they’re like mobile users,” I think helped us really make decisions about where the design was going.

We would love to be able to deliver a much smaller site or a much smaller payload of data to users that are on mobile.

Paul:

You know, the other thing we talked about a lot, and it’s a problem that we haven’t solved, is thinking about the users in terms of bandwidth. We would love to be able to deliver a much smaller site or a much smaller payload of data to users that are on mobile. It’s not a problem that we’ve solved yet, but we were conscious of that and still are.

We had these share buttons, for instance, on the old site for Twitter and Facebook, and we started tracking whether or not people were actually clicking on them, and it turns out people didn’t really use them.

Karen:

Let me ask you how you thought about prioritizing information as it might live on all of these different sized screens. So some organizations that we talk to basically take what they have and just sort of flex it and rearrange it, and other organizations use a responsive redesign to really question and make changes to some of their overall editorial strategy and direction. Can you talk about how you handled those questions of what should be where on which screen?

Tracie:

I think especially for mobile, we wanted to let people use what’s already available through their devices and really give a streamlined experience. We had these share buttons, for instance, on the old site for Twitter and Facebook, and we started tracking whether or not people were actually clicking on them, and it turns out people didn’t really use them. And especially on mobile, we had them on the old site, where you could still tap on those things on mobile, but we decided why is this here if no one’s using them, it’s just visual clutter, let’s just hide that on mobile. But making sure that the recipe is really prominent and that people can see that, and if they need to save it to various recipe boxes or whatever, we wanted to focus on that and making sure that a markup was really great for all the different—like Paprika and those kinds of recipe-saving tools.

We have these different blocks that you can kind of mix and match and then use on different pages, like across our tag pages and category pages.

Ethan:

That’s great. Tracie, I’d love to hear a little bit more about your design process in general, especially as you’ve been doing more multi-device work. Before, you were straddling a desktop-only site and a mobile-only site. Now as you’ve brought these together, how do you start thinking about actually talking about aesthetics and designing a web page?

Tracie:

It was interesting because we wanted to approach this redesign more thinking about it as a system where we can take components and string them together. I think the homepage is a really good example of that, where we have these different blocks that you can kind of mix and match and then use on different pages, like across our tag pages and category pages. And then having those blocks and being able to remix those—like we’re launching a Thanksgiving section very soon, and so just having those, it makes it so much easier to give editors a few choices for how they can lay out a page. Whereas before, it would be like, “Oh, we’re making a new page,” and then we have to create a whole new set of styles for that. So, having a system for thinking about how we can organize the content has been really helpful.

The ability to get feedback from the editors much more quickly, rather than slaving over Photoshop comps or something, has been really great.

And I’ve moved into doing more paper prototyping…the ability to get feedback from the editors much more quickly, rather than slaving over Photoshop comps or something, has been really great. I think sketching something really quickly, putting it in front of the editors, being like, “Is this what you’re thinking?” and they’re like, “Yeah, sort of, or maybe not this,” adjusting it, and then jumping into Sketch and then being able to show, okay, this is how I’m thinking about the interactions on desktop vs. mobile, and being able to show all of that all at once I think has helped the process a lot. Yeah, so it’s just that rapid iteration that I think has been really helpful and a lot quicker. It’s like we can turn around projects much more quickly than we have in the past.

With a lot of the editorial projects that are outside of the CMS and not supported by it, we’re using Google Spreadsheets.

Ethan:

I think that’s fantastic. I’m a big, big believer in bringing paper into the design process as early as possible. I’d love to hear a little bit more about the handoff between you and Paul. How do you actually work together, like that transition from sketch to prototype? Have you guys found that it’s changed significantly now that you’re doing more responsive work?

Tracie:

I mean, in terms of—like, I would show the prototype to Paul and then we would talk about how we would handle the data. I think one of the things that we’ve started doing with a lot of the editorial projects that are outside of the CMS and not supported by it, we’re using Google Spreadsheets to handle saving all the data, so the editors will just put all the information in there. And I think that if there’s something custom that needs to be built, it’s much more obvious showing the paper prototypes and then going into Sketch. Like, I’ll talk to Paul about it and be like, “Oh, do you think this is going to work, do we need something more robust than Google Spreadsheets?” Like, it’s much quicker to be able to see that earlier on in the process.

Paul:

Yeah, I think from my perspective, Tracie can handle enough of the front-end development that she’s able to turn her own prototypes into functional pages, and I would come in more on the data side, figuring out what’s realistic with the data, if we can massage the data we have available into building the page that Tracie is envisioning.

Tracie:

Yeah, and then just throwing that back and forth I think, where it’s like okay, I can get up to this point in the JavaScript and then I’ll be like, “Okay, I need help,” and then Paul will jump in and we’ll throw it back and forth. So that’s something that I think has been really great.

The editors are stuck in ancient CMS editing, but when they click save, it actually saves into a very quick API.

Karen:

My ears perked up when you mentioned your CMS and then also things that might happen outside the CMS. What publishing platform are you on, and can you talk a little bit about what you’re doing on the back-end to support this responsive redesign?

Paul:

Sure. We run a very old version of Movable Type, it’s actually Movable Type 4. And what we’ve done in terms of supporting modern things is we work with a company here in New York called 29th Street Publishing, and they helped us decouple the front-end, or now middle layer, from the CMS. So the editors are stuck in ancient CMS editing, but when they click save, it actually saves into a very quick API, and what we did is we built a Python layer on top of that API to build the pages.

Tracie:

That’s from like the CMS templating standpoint. It was actually a long transition for us to even get to the point where we weren’t publishing out of Movable Type and having Movable Type render the templates. I think initially—it’s this templating engine called Cheetah app, and we started very small on a project called Near Me, where we were collecting tips from Foursquare and then connecting it with posts that were about a particular venue. And so that was just getting our feet wet on a project that wasn’t too critical to the rest of the site, and rubbed off. It was a learning curve, you know? I think we were like, okay, how does this work, this templating? And then integrating it, it was like we would turn one blog on to use this other templating engine outside of Movable Type, and that took a few months, I would say.

We essentially ported the site from being generated by Movable Type to being generated in Python. There was no visual impact of that, so it felt like we did a lot of work and there wasn’t really anything to show for it.

Paul:

Yeah. So that was the summer before this past one, so 2014. We essentially ported the site from being generated by Movable Type to being generated in Python. There was no visual impact of that, so it felt like we did a lot of work and there wasn’t really anything to show for it. But in reality, underneath there it was Python churning away instead of some static files that Movable Type was generating.

Tracie:

But now it’s all in one place, like our templates are being rendered through one templating engine. And we also now are using that templating engine to do different features outside of what the CMS is handling. So there was like a Chinese food guide that we did probably about six months ago, and all the data was coming from, like, Google Spreadsheets. I mean, what’s really cool about that is it gave us the opportunity to think through interactions, and thinking about the content and really trying to design something that allowed you to access the content in the most appropriate way, depending on if you were on mobile and desktop, and being freed from the constraints of the story template that most of the content is rendered in. And I think we learned a lot from doing that sort of editorial feature that is outside of the story, and we were able to say, “Okay, these are the things that really work. What can we roll into the rest of the site?” and have it be more of an iterative process rather than just guessing. Because we got a lot of feedback from people on Twitter about that Chinese food guide, and we were like, “This is really cool, this totally works. We should use this sort of interaction,” or whatever. So, it’s freeing to do those kinds of things outside of the normal story template.

As an image-heavy site, I would love to get to a point where we can do responsive images.

Ethan:

Paul, I’d love to pick up on something you mentioned earlier, which is a topic near and dear to Karen’s and my heart, which is performance. Tell me a little bit more about where the site is right now from a speed standpoint, and it sounds like you’ve got some plans for it in the future. How are you having those discussions internally, and where would you like to take the site next?

Paul:

The biggest bottleneck for us is, as an image-heavy site, I would love to get to a point where we can do responsive images. Right now, people are uploading 1500 pixels wide images, and unfortunately that’s what we’re sending down to mobile users. So that’s our biggest pain point, I would say.

We didn’t really set up a performance budget as far as the redesign went. Essentially what we did was took time, both of us, to review best practices around the web, and figured out where we could get the most results for the effort we could put in. There were really simple things, like enabling gZIP in our—the pages are served through Tornado, which is a Python web server, and it turned out enabling gZIP in Tornado was really just changing a flag when it launched. So little things like that made enough of a difference that it was measurable.

Tracie:

Yeah, and I think there are other things that we really wanted to do, like inlining CSS that we didn’t get to. At least now we’re lazy loading those images in the body. [laughs] I think there was a post that had like thirty images and it was taking forever to load. We were like, “Oh, this is really bad. We should lazy load these.” And so, yeah, at least we’re doing that now.

The Python middle layer can actually take those scraped image tags and move the image into the right format for lazy load.

Paul:

Yeah. So the lazy loading was actually a great example of the freedom when we switched into the Python middle layer. So when a request comes in, instead of hitting a file that’s been generated, it’s actually hitting Python and saying, “Build this page for me.” So, we can take our legacy content that had no idea—you know, when those pages were created or those entries were created, lazy load didn’t exist, as far as I know, in 2006. So the Python middle layer can actually take those scraped image tags and move the image into the right format for lazy load, so it loads as the user scrolls down the page.

It’s more of a qualitative way that we were deciding whether or not it was successful, in terms of feedback that we were getting from users.

Karen:

Let me ask broadly, how do you measure the success of a redesign like this? Like, what sorts of metrics or data do you track to know if this is working?

Tracie:

We don’t necessarily have any metrics set up. We made so many changes I think with this redesign that it was a little bit hard to cut through the noise. For instance, we had slideshows that you had to click on every slide to see the next slide. And in the redesign, we decided to flatten that so all of the images would live at one URL you didn’t have to click through. So this really affected the time spent on page, and it was hard to say—was that effective? Yes, our time on page jumped, but we had this sort of… Before the redesign, obviously that time on page would be really, really low because people are just clicking through on every slide. So, we weren’t able to actually say, “Okay, that was effective; the redesign was effective.”

I think it’s more of a qualitative way that we were deciding whether or not it was successful, in terms of feedback that we were getting from users. That’s how we approached deciding whether or not the redesign was effective.

Paul:

It’s difficult to make sense of the numbers. But I think it’s important to realize that, for us, this happened in a time of transition for the whole company. There were changes in our editorial process and philosophy that were happening at the same time, making it even harder to trust our measurements. And I think in my mind, this was a big part of the site growing up, and I feel pretty confident that what we’re putting out there is a more grown-up product than what was there before.

Ethan:

Well Paul, Tracie, I just have to say, we’re coming to the end of our time, but I have to be honest, Karen’s enthusiasm once we scheduled this interview has been infectious. And talking to you guys for twenty minutes, it’s definitely paid off; it’s been a really wonderful chat. But I’d love to hear if you happen to have any lessons you’ve learned during the course of this responsive redesign? Any advice you might have for our listeners who might be starting a similar project? I’d love to hear from each of you on this about something you’ve learned.

It’s a much longer process than people realize, and it’s okay that it takes that long time.

Tracie:

I think in terms of the timing and the scope, that it really helped to break things down into much smaller pieces and work on smaller projects, and to test those things out. Because I think there was so much that we learned from doing each project and “Oh, did this work? Did this not work?” I don’t think that we would’ve been able to achieve the redesign that just rolled out in August if we hadn’t done all of those smaller projects, and experimenting with things and being really collaborative with the editors to get to where the site is now.

I think it’s hard; even from the outside, it might look like we took this huge leap forward and it’s like, “Oh my god, it all happened at once! You flipped a switch!” It’s a much longer process than people realize, and it’s okay that it takes that long time. Yeah, just because, for us, only having two people, you don’t want to take too many risks by rolling out this huge thing. So doing it on smaller projects has been really, really helpful for us.

At a tiny company like this where people are passionate about what we’re doing, everyone does feel like an owner and no one is going to like surprises.

Paul:

Yeah. The other thing I would say is to communicate. At Serious Eats, I feel like we didn’t necessarily have stakeholders that we were beholden to, but communicating to everyone in the company and getting feedback as quick as possible, at a tiny company like this where people are passionate about what we’re doing, everyone does feel like an owner and no one is going to like surprises or not being a part of the process. So including everyone in the process, whether or not they were going to be able to veto things or not, was important, I think.

Karen:

Well Tracie, Paul, I have to thank you so much for taking the time to talk with us today. I am really, really looking forward to looking at every recipe that you publish and spending significant amounts of my life on your website. So, thanks for being here.

Tracie:

[laughs] Thanks for having us.

Paul:

Yeah, thanks a lot. This was great.

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.