Hi, this is a responsive web design podcast, where we interview the people who make responsive designs happen. I’m your host, Ethan Marcotte.
And I’m your other host, Karen McGrane.
And this week we are positively beside ourselves to speak with Todd Hodgson and TJ Pitre from Outside Magazine. Guys, thanks so much for joining us. Todd, TJ, why don’t you guys introduce yourselves and tell us a little bit about what you’ve been working on lately. Todd, why don’t you go first.
Hi, my name is Todd Hodgson and I am the site director of Outside Magazine’s website, OutsideOnline.com. I oversee the entire website but really focus on design and development, and I was the guy who spearheaded and managed Outside Magazine’s responsive redesign.
And I’m TJ Pitre, I’m a web designer; I run a small little web design studio in New Orleans called Southleft. I do mostly front end design and development work for a wide variety of different types of sites. Before this, I was previously the director of front end development at Martha Stewart Living Omnimedia before I went and did this independent thing last June. Todd brought me on last year to help facilitate the responsive redesign of Outside Online.
But before we dive into our conversation, I want to tell you about some exciting news from our sponsor, Campaign Monitor. Did you know that more than half of emails are opened on a mobile device? Making emails look and work great on all the different devices and email clients is one of the hardest problems in responsive design. And that’s where Campaign Monitor comes in. They have an easy to use email builder called Canvas, that creates emails that look great everywhere. In just minutes, you can drag and drop your way to a beautiful email that just works, with images and typography that will scale correctly on every device. Want to try it out? You can see how it works, and you don’t even need a Campaign Monitor account. Just go to campaignmonitor.com/templates and see for yourself just how easy it is. I know, because I use it myself, and I love it.
One way I was able to quell the financial fears and negotiate approval for a responsive project was I needed to somehow squeeze this responsive redesign into that web maintenance budget.
Fantastic. Todd, I’d like to hear a little bit about how the decision to go responsive came about. How did you start that conversation internally with your stakeholders and were there any questions or difficult discussions that came up around responsive in the early days?
Most of the concerns were around money, as you can imagine. In terms of convincing people that a responsive redesign was the way to go, I was very lucky that management at Outside were already kind of acknowledging the mobile traffic story when I arrived in March of 2012. So, at that point mobile represented twenty percent of all traffic, so there was a general agreement that it couldn’t be ignored but there was no real plan of what to do. In the next few months, that twenty percent kept inching up but the engagement numbers around mobile were steadily getting worse—bounce rate and page views per visit were all going in the wrong direction, which implied our mobile audience wasn’t having a good experience. That made it very easy for me to accelerate the discussion that we had to do something but there was still a lot of convincing to do, especially on the financial end.
I should preface everything and say that we have a pretty small staff at Outside on the digital side. The print magazine I think is a little more typical with what’s in the industry, but in the digital group we’ve always kept things small and we have no staff developers or designers, and certainly no UI/UX team or QA team or project managers or anything like that.
Management and sales weren’t ready for some kind of full-scale redesign or rebranding, and honestly that played into our favor to keep the cost down.
So, all of my development and design is done via freelancers and we’ve budgeted 160 hours per month for this bucket of what we call “website maintenance,” which includes everything from day to day fixes and any kind of web development. One way I was able to quell the financial fears and negotiate approval for a responsive project was I needed to somehow squeeze this responsive redesign into that web maintenance budget, it couldn’t be a standalone project, so that way it would be less financially painful. Ultimately, management really just trusted me when I said I could do this.
Another big fear I had to address was the disruptiveness of a redesign. Outside had been through this really nasty re-platforming back in 2011 to a fixed width site and it was very expensive, but it was also pretty disruptive to the editors and to the users—traffic took a big hit. So, this redesign had to be somewhat invisible in terms of its effect on the Outside staff and in terms of look and feel. In working with TJ and our other developer, Ben, I convinced everyone that this would be very seamless for the digital editors in the CMS and also to our users. Management and sales weren’t ready for some kind of full-scale redesign or rebranding, and honestly that played into our favor to keep the cost down.
I explained that a responsive site might display fewer ads but they’d be fitted to the screen and would co-exist alongside the content better and therefore perform better.
The last thing was from the sales end in terms of buy-in. There was always a great deal of skittishness from the ad sales side over responsive redesign because they were seeing some great revenue strides in 2011 and 2012, and this represented a massive change for them. I was very upfront with our sales director from the beginning, that ad impressions would definitely decrease on mobile devices; some of our pages before this redesign had up to five ads, which you can kind of get away with on desktop but on a phone you can’t, they won’t perform well and they’ll also bog down the page to some degree. So, I had to convince sales that we’d increase raw visits to the site to compensate for the ad impressions we’d technically lose page to page. I also tried to appeal to common sense with the argument that on this fixed width site, even if we were serving people five ads on phones, they were pinching and zooming away from the ads, so they performed poorly and eventually that bad performance would come back to bite us. I explained that a responsive site might display fewer ads but they’d be fitted to the screen and would co-exist alongside the content better and therefore perform better.
Was it more expensive to do a responsive redesign? No, definitely not.
One thing I would like to follow up on really briefly is, I frequently hear that concern upfront about cost increase, that because we’re building a site that’s going to work on mobile, tablet, and desktop for example, it’s going to be 300 percent more expensive to design and build. When you got to the other end of this, how did that perception actually play out? Was it more expensive?
Was it more expensive to do a responsive redesign? No, definitely not.
So the scope more or less matched up to your expectations?
It did, yeah.
We definitely think our mobile users have the same needs in terms of information or editorial. There were never any discussions about hiding content—we hide very little.
Let me ask about the perception of what’s the difference between a mobile user and a desktop user. I, for one, believe that websites only really need to work on desktop computers because I never go outside. But what do you guys think? How did you talk about what a mobile user needs for your brand, your publication?
We had a few discussions early on but we definitely think our mobile users have the same needs in terms of information or editorial. There were never any discussions about hiding content—we hide very little. We definitely had some analytics on mobile users’ engagement behaviors pre-responsive—over page views per visit and bounce rate, things like that which probably everyone notices—but in terms of information, no.
We had scrutinize all of these different templates on mobile devices. In the process of doing this, that really inspired us to clean up our act on our desktop presentation.
But we do believe that mobile users interact with content differently. One of the great byproducts of this responsive redesign was that it forced us to reevaluate our templates and audit every type of template, and we have a fair number of them on our site. Articles definitely make up the bulk of our traffic and the biggest number but we have photo galleries and quizzes and interactive maps. So, we had scrutinize all of these different templates on mobile devices. In the process of doing this, that really inspired us to clean up our act on our desktop presentation, because I think it’s very easy to fall into this mindset that desktop users are, for some reason, willing to put up with more junk thrown at them.
Pagination is annoying enough on desktop, but it’s really, really user-hostile on phones. Trying to tap these tiny little numbers with your fingers, it’s just absurd.
A great example of this is our article pagination. Everyone is familiar with pagination; some sites are worse offenders than others at this, and we were a really bad offender in this category, splitting one long article into eight or ten pages and forcing users to click to make their way through one article. Pagination is annoying enough on desktop, but it’s really, really user-hostile on phones. Trying to tap these tiny little numbers with your fingers, it’s just absurd; it was something we definitely weren’t comfortable forcing our mobile users to put up with. So, TJ developed this progressive reveal as people scroll rather than basing it on a click. The obvious question became “Why not give users the same experience?” It’s just such a better experience than old school pagination.
It’s great seeing on Facebook and Twitter how someone will comment on one of our photo galleries and say “Thank you so much for not requiring me to work to get content!”
Likewise with photo galleries, it’s another neat example in the other direction. On desktops, the user interface is still controlled by clicking to get from slide to slide, but on phones we developed them so they kind of unfurl and appear like an Instagram feed, so users can scroll naturally to see everything and there’s no clicking or horizontal swiping involved. These little things are a huge relief for our users. We see the comments; it’s great seeing on Facebook and Twitter how someone will comment on one of our photo galleries and say “Thank you so much for not requiring me to work to get content!” So, that was a really awesome exercise that we went through and it actually improved our desktop experience too.
There’s so many tools out there for responsive design and it grows exponentially every day. So, I would say no project I’ve ever started was ever done the same way.
TJ, I’d love to hear a little bit from you. We met a number of years ago when you were still with Martha Stewart Living Online. You’ve done a significant amount of multi-device work over the years and I’d be interested to hear more about how, if at all, your design process has changed in recent years as you’ve done more responsive work.
In the beginning, it’s kind of like a trial-and-error process. There’s so much stuff out there and you get excited about trying all these great new things. I’d had a few responsive sites under my belt by the time this project came along. I definitely made a lot of mistakes in the past but fortunately I was able to learn from a lot of those and find better solutions. There’s so many tools out there for responsive design and it grows exponentially every day. So, I would say no project I’ve ever started was ever done the same way. Still to this day, I feel like I don’t even have a specific way that I develop every site—it’s constantly changing. I guess it’s probably the way that you learn best as a developer and a designer, just kind of taking a little bit from the last project you did and applying it to the next project, and then playing with some new cool tools and then moving forward. That’s pretty much how we did it with this site too.
That’s great. The tools and applications you’ve used, how have those changed in recent years and what did you find most helpful when working on Outside Magazine’s redesign?
In the beginning, there were so much responsive images and LESS versus Sass-type stuff, and that was when I was first getting into that in 2011 or so. Right now I guess it’s more of a workflow thing for me; the workflow tools that I’m using are changing but the style of coding usually remains the same. Lately I’ve been getting into more of the Brad Frost-type of pattern development, atomic design, and that seems to be my niche right now. I’m really having a lot of fun developing in that manner.
One big thing we’ve made sure to include is mobile previewing of content before it goes live as a requirement, not as some halfhearted afterthought of scrunching the browser on a live piece of content.
You mentioned a large re-platforming that you went through a few years back. Can you talk about any changes that you might have made to your content, to your content management system? Did the editorial workflow change at all as part of this responsive redesign?
In our digital team’s process after the responsive redesign, one big thing we’ve made sure to include is mobile previewing of content before it goes live as a requirement, not as some halfhearted afterthought of scrunching the browser on a live piece of content. So when the editors and producers create content before it’s published, we look at the content on the actual devices and I break down the traffic now way down to the actual device level in our device lab—which for us is kind of a pile of discarded old devices from coworkers—is now what we should be using to preview our content on to best mirror what our users are experiencing. So, the point was we had to start getting away from these beautiful twenty-seven-inch iMacs that are in our offices and from previewing content on those because our analytics show that literally only one percent of our users are on that device.
We had to start getting away from these beautiful twenty-seven-inch iMacs that are in our offices and from previewing content on those because our analytics show that literally only one percent of our users are on that device.
We didn’t have to tweak much in our CMS as a result of this responsive redesign. The CMS that we were on at the time and that we’re on still now is a proprietary CMS, it’s Java based, and there’s a closed architecture and a very limited developer pool, which was kind of scary at first but we ultimately didn’t have to tweak too much, mostly it involved updating our HTML templates to include the new responsive assets.
We did have to modify our image scaling and cropping methods. We don’t have a team of producers to scale and art direct each crop, so we developed a method where we manually create these three massive source images and then we have a third party company called ResourceiT that takes care of the responsive loading and resizing of these images, and that gives us a mobile optimized size and resolution.
But in general, I was pretty surprised at how little this project was impacted on by being on this proprietary CMS. I went into this, for some reason, thinking it would be a lot more difficult and that this would be a huge speed bump, but it wasn’t.
I don’t know that there’s a great solution yet to the IAB situation on mobile, but I do think that attacking it only from the web design and development end isn’t going to be effective.
One of the biggest problems that I hear from publishers about responsive design is advertising. How did you wrestle with the responsive ad problem?
We started discussing with the ad sales team pretty early on about what the criteria was for each template we were going to be redesigning, how many ads and so on. Then we assess how the mobile templates would work with these ads, then we decide on which ad units were needed and what compromises would have to be made for those ads. So, we decided to have a series of ads per template do some swapping; on templates where a 300x250 might turn into a leaderboard or a 300x600 would get swapped out. Also, ad placements had to be considered too. With the width expanding to a desktop, some ads just don’t shift into the proper spots, so there’s a few spots where once something gets to, say, 500 pixels, we’d remove that ad and then put it in a different spot that was maybe a higher priority for a mobile device or a tablet.
When you have forty or sixty advertisers asking about their placement “above the fold” and they pay for the site, then for them there is a fold and it’s not going to help matters to flat-out ignore it.
It’s really interesting, right now there seems to be these two extremes in the mobile ad world. You have publishers like Quartz and Vox where they actually have these large marketing teams with developers that work specifically to build responsive creative for advertisers, and then you have other publishers that just take the typical IAB units and figure out a way to kind of plop them onto a phone. We’re definitely more akin to the latter camp, we don’t create ads for advertisers yet. But we are trying our best to get creative and we’re lucky that we have a really progressive ad sales team, they’re very small and scrappy as well and they realize that we have to come up with a solution that’s between the other two extremes.
So, like with the example I gave earlier about photo galleries, removing these screen-engulfing interstitial ads was important because our feedback was showing that people on phones were accidentally clicking those. Just rethinking the template and moving the ads more in line with the Instagram-like presentation was better for the user and the advertiser because it filtered out the bogus clicks from fat fingers and helped keep frustration down for the user.
I see what Quartz doing as really trailblazing and I hope they have massive success with these responsive ads, and more importantly I hope they socialize the good news.
I don’t know that there’s a great solution yet to the IAB situation on mobile, but I do think that attacking it only from the web design and development end isn’t going to be effective. It’s a change that’s only going to happen if minds across several different industries are changed. It reminds of how it’s very easy for designers and developers to lambaste carousels or the fold—and I agree with both of those, that there is no fold and carousels aren’t the best way to present content—but when you have forty or sixty advertisers asking about their placement “above the fold” and they pay for the site, then for them there is a fold and it’s not going to help matters to flat-out ignore it.
The same with the ads themselves—advertisers and agencies have this long history with IAB ads and it’s easy for me to say to my ad sales director “These advertisers need to create responsive ads,” but it’s not just about convincing my ad sales director. It’s also about convincing every single advertiser and ad agency we work with. So, I think there’s an evolution. It’s not going to change over night, especially since money is involved, people are going to be more cautious. But I see what Quartz doing as really trailblazing and I hope they have massive success with these responsive ads, and more importantly I hope they socialize the good news because maybe that will help change minds beyond just the design and development world.
You mentioned doing mobile reviews. I’d like to hear more about design reviews of the new responsive site. How did you guys manage those when you started to talk about the look of what this new, more flexible layout needed to be?
In terms of reviews, being on such a small team is great in this regard because it’s really an informal process. It worked the same way during the beginning stages of the responsive redesign as it does now—I send around a link from TJ’s prototype to three or four people, which includes the editor-in-chief of the print magazine and our sales director, and usually within the course of a few days or a week we’re already all the way through feedback and sign-off, and then the prototype can get deployed to the CMS.
If anything, the design process got better and the feedback process got better.
Did anything change in the way that those reviews were handled with the broader organization? You mentioned ad sales earlier, or the editorial team—did they give feedback in a different way or were there problems that you ran into because the responsive redesign required comments on a variety of different breakpoints and content choreography?
Surprisingly no. In fact, I’d say it was simplified because in the past we had these comps, and these gorgeous finished comps would go straight to developers and then we would develop from that. With the responsive redesign, we passed around a link and everyone reviewed the link, and I always reminded them to look on their different devices and they were great about that. The feedback was really great too from the team; it was stuff like “I don’t like yellow.” They would tell me “I’m on a Moto X on Firefox and this is getting cut off.” So, if anything, the design process got better and the feedback process got better.
Performance in terms of page weight and performance in terms of the third party calls, like lots of ad calls and third party content on the page—these are the things that we try to assess with performance budgets.
You guys mentioned a device lab, which is one of those phrases that’s like catnip for me, but I’d be interested to hear about how you measured not just the look of the experience on those different devices but how it felt, specifically around performance. Is that a design factor for you, is that something that you currently measure?
Performance is always something that’s been at the top of the discussion for any time we create a new template, it’s something that we just endlessly tweak. Performance in terms of page weight and performance in terms of the third party calls, like lots of ad calls and third party content on the page—these are the things that we try to assess with performance budgets and making sure that a page loads. Our goal would be to have a page render some content in under a second. It doesn’t necessarily have to be the entire page styled, but as long as the user is able to see something coming, that they actually see that it is loading.
In the beginning, performance wasn’t as big of a concern as it is now. You start light in the beginning, so it’s easy to just put some stuff on and then everything loads fine. But we’re a little bit past a year into this and as you keep building you keep adding stuff, so we find ourselves having to go back to different parts and say “Do we need this anymore? Is this something we can take out?” or “Is this something we can optimize in some kind of way?” We do all of the normal tackle methods of keeping the page weight low—we do a lot of image lazy loading and we do a lot of minifying and concatenating and all that kind of stuff.
Todd mentioned ResourceiT, which is a third party image handler, they do a lot of the great image loading for us, so we’re not letting the browser do the pixel resizing of the images, it’s actually delivering the proper image for that device, for that resolution. So, that helps a lot. But like I said, performance is something that we can always better, no matter what we do.
We’re at sixty-five percent mobile at this point, and in January of 2013 that number was completely flipped, it was sixty-five percent desktop.
How do you measure or evaluate the success of this redesign? How do you know if it’s working? Are the metrics that you use or the analytics data that you look at different now that you’re responsive?
Certainly sheer numbers is what we’ve noticed the most. There are things like mobile users are simply coming to our site now way more. We’re at sixty-five percent mobile at this point, and in January of 2013 that number was completely flipped, it was sixty-five percent desktop. Over the course of twenty-four months things have transposed and luckily smack in the middle of when we made our site responsive.
Bounce rate on phones before this responsive redesign was in the seventy-five percent neighborhood and now it’s at least ten percent lower than that.
But the other thing we’re noticing is engagement. Bounce rate on phones before this responsive redesign was in the seventy-five percent neighborhood and now it’s at least ten percent lower than that. That type of shift in bounce rate can represent a massive amount of traffic, even a few percentage points makes a dent. Bounce rate on the home page dropped by forty percent, so that’s probably the screaming headline.
You’re not forcing people to go through all these weird contortions to get your content, pinching and zooming and scrolling horizontally. They’re going to spend less time on your site because they’re not battling your site, and that’s a good thing.
One thing I noticed, I don’t know if you’d call it surprising but it was definitely a lesson learned for me, was that time on site isn’t necessarily going to increase by a huge amount once you go responsive—at least that wasn’t the case for us, our time on site actually went down. But I don’t think it’s a bad thing. Part of it is definitely caused by the surge in social traffic that we’re getting and that probably everyone is getting now. People are coming from Facebook and Twitter and getting what they want and then going back to those social apps.
The other thing I’d argue is a responsive site is just a faster experience in general. When you’ve optimized the experience, you’re not forcing people to go through all these weird contortions to get your content, pinching and zooming and scrolling horizontally. They’re going to spend less time on your site because they’re not battling your site, and that’s a good thing.
In the past, this kind of “jack of all trades” developer used to be looked at like a journeyman or something that wasn’t desired, and now it’s much more desirable, in my opinion, to have talents in many areas.
Do either of you guys have any advice for other organizations that are about to embark on a responsive redesign? What are some of the things you guys learned working on a responsive redesign for Outside Magazine?
Sometimes it’d be great to have a QA department because it’d be better to hear that our site is breaking on Firefox from a QA analyst rather than from half a million people on Facebook.
When you run a small team, it’s essential that everyone wears a lot of hats and I find it also extends to our editors too. The best online editors aren’t just great editors or interested in long-form journalism, they’re also getting dirty in the code or they’re curious about analytics or they have an eye for design.
Probably the biggest thing that really benefited us at Outside was there’s just a great deal of trust and very little ego in the Outside culture, which is a really huge blessing and what allows us to move so quickly and inexpensively. We don’t have rows and rows of creative directors and VPs and all these people that need to offer feedback and sign-off and rounds and rounds of revision and scope changes and things. That was our key to success—we were all trusted as experts through the whole project and that trust went all the way down to TJ and Ben. That’s not knocking the big teams either. Sometimes it’d be great to have a QA department because it’d be better to hear that our site is breaking on Firefox from a QA analyst rather than from half a million people on Facebook.
The quicker you can get your stuff presentable is the most important stuff. You can always tweak workflow along the way.
From the technical standpoint, don’t be afraid to fail. There’s a lot of great tools and stuff out there to use and a lot of times I find myself getting caught up in the setup of a project—I spent weeks on setting up Gulp or Grunt without actually doing any development work because I’m just questioning myself about whether or not this is the proper way to go in my workflow. But I would say pick something and go with it. That’s kind of what we did with this responsive redesign for Outside, is we needed to figure out a way that we could rapidly put together these prototypes and in the beginning I was just kind of getting caught up, like “Wow, this Grunt thing is really cool,” or “Grunt or Gulp, which one should I go with?” and eventually I just said “I need to figure out my own thing.” So, I put together this little prototype environment that seems to work really well for us even a year out now, it’s just a little environment where we could rapidly design something in the browser and then show it to the stakeholders and then get sign-off from it.
So, the biggest takeaway for me is don’t get too caught up in your head on things. The quicker you can get your stuff presentable is the most important stuff. You can always tweak workflow along the way. That’s where I’m at right now, anyway.
That’s great. Todd, TJ, thank you so much for taking a few minutes to chat with us. Both Karen and I have really enjoyed it.
Thanks to everyone for listening to this episode of a responsive web design podcast.
We’re really excited to announce that we’re offering a public workshop on responsive design, taking place April 2-3 in New York City. If you’re interested in attending, visit responsivewebdesign.com and register for a ticket today!
And 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. If you’re interested in bringing us to your company, please go to responsivewebdesign.com and let us know that you’re 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 to our sponsor, Campaign Monitor. Be sure to visit campaignmonitor.com and check out their email editor, Canvas. Thanks for listening, and we’ll be back next week.