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 my dog is looking at me funny because I am so excited, I’m the one who’s shaking this time. We have David Sleight from ProPublica with us. David, thank you so much for being on the show.

David:

I’m really excited to be here. Thank you for having me.

Ethan:

But before we dive in, I’d like to take a moment to mention our sponsor, Harvest. I’ve actually been using Harvest for years, so I was incredibly excited when they approached us about sponsoring the podcast. Harvest bills itself as a beautiful business tool for tracking time spent on client projects. I’ve worked with a number of teams who love it. They love how easy it is to track hours across projects, how beautiful and well-designed their reporting tools are, and I’ve heard from a lot of folks that I’ve worked with that Harvest really helps them stay on time and keeps their project under budget. Now, personally, just speaking for myself, I love its invoicing and expense management. I can update my projects in Harvest with my web browser, with my mobile device, and regardless of the size of the screen I have closest to me, it’s a real joy to use. So if you’re interested, you can check out Harvest at getharvest.com today. What’s more, after the free thirty-day trial, you can enter coupon code RESPONSIVE at checkout and save fifty percent off your first month.

Karen:

Well David, first, just for the benefit of our listeners, why don’t you introduce yourself and tell us a little bit about what you do at ProPublica.

David:

So, I am the design director at ProPublica. We’re a nonprofit investigative newsroom. We produce journalism in the public interest, have been around for several years now. And I’m sort of a new and unique animal here in that I’m the first design director that ProPublica has had. Been on the job for about fourteen months or so, and I look after the general user experience and editorial design of the site.

Karen:

Well, I have been a fan of ProPublica for a long time; the reporters there, the journalists there do some amazing work and your participation has made it even all the better. You are doing some stunning things with the design of the site.

David:

Oh, thank you.

We’re at a point now, in the last year, where on our large editorial features, the fully fluid responsive ones, that we are now majority mobile.

Karen:

Yeah, no, I’m quite serious about that. And what is most interesting is some of the work that you’ve been doing with new responsive formats, particularly for some of your long-form journalism. Can you talk a little bit about how responsive design fits into your design and development process there?

David:

It’s kind of funny, it’s something that I sort of think of as almost background now. So, as far as how does responsive figure into the work that we do, we sort of think of it as a necessity; or a better way to think of it is if it isn’t responsive to some degree, if it doesn’t work on mobile, if it doesn’t work on tablets, if it doesn’t work on desktops, it’s effectively broken because it’s becoming the majority of our audience. We’re at a point now, in the last year, where on our large editorial features, the fully fluid responsive ones, that we are now majority mobile. It varies a little bit across the site and across apps and general landing pages and things like that, but it’s becoming, with certainty, the majority of the audience. So, it’s kind of like articulating the intuitive. We just sort of take it as a given that pieces need to be responsive because they need to be present in these different mediums.

As far as the pieces and layouts themselves, we think less about changing the content for the context than we do about changing the tools.

Ethan:

If I could just follow up on that really briefly, David. We talk to a lot of organizations, both in our work and for the podcast—how does ProPublica think about the needs of the mobile user versus the desktop user? You mentioned that ProPublica did some adaptive layouts when they first started going multi-device; there were a couple fixed-width designs. As you guys have been going more responsive, have any conversations come up about certain classes of users needing information of one type versus different contextual needs that a different device might have? Or do they, more or less, need the same information?

David:

You know, for us I think we actually side on “the same information,” in a way. I kind of take a counterintuitive notion to that here, which is… We have a joke that our standard unit of measure is 5,000 words or more, so we do very long-format content. And so, what we try to think about here is there is the social promotion of stuff, which is its own set of stuff; we have a great engagement editor here who thinks about how to present that work. But as far as the pieces and layouts themselves, we think less about changing the content for the context than we do about changing the tools.

A really good example would be we did a very large piece called “Firestone and the Warlord” in partnership with FRONTLINE, which was over 20,000 words. It was basically a novella-length story that we presented online. And in that case, we were pretty adamant, like we’re going to show the whole story everywhere.

We lean more towards creating tools that help you get through the experience than we do about adapting the content.

But when we were thinking in particular about responsive and the reading experience online, we built a tool where you could email yourself a bookmark very easily to get back into it. We were explicitly thinking—myself and Mike Tigas, who helped write the tool, who’s on the data apps team here—about what can we do that we know will be accessible and readily available to people in a mobile context. And, like, email—well, it’s sort of funny, it’s a very lo-fi technology but it’s nearly universal the way that we could build the tool and everybody would have access to it. Because we didn’t necessarily think that everybody would finish, we didn’t think that necessarily they would do it in one session, and we also know how likely or not likely it is for people to come back to it. So we were thinking about what’s a tool that helps the reading experience, and specifically, what’s a tool that helps the reading experience in the mobile handheld context, or the amount of time that you would need to set aside to actually get through this piece. So, I think that’s a very roundabout way of answering your question. I think that we lean more towards creating tools that help you get through the experience than we do about adapting the content.

We’re a small group, but we have a very high operating threshold for skills.

Karen:

David, we’ve talked about the planning process that goes into some of these long-form pieces. You’re talking about six, twelve, maybe even eighteen months of research and reporting goes into one of these features. Can you talk about how the scoping and planning process for your design work fits into that process? Like, how do you figure out what it’s going to take to bring these stories to life? Is it like a Snowfall kind of thing where you have a team of eighty people and two years to work on it?

David:

[laughs] Less than that. That would be pretty awesome. I think that we have a little bit more than the average fast-paced newsroom. We still do daily stuff, but we also have a… we sort of have an A-team, basically, here and that’s everybody. You know, we have this awesome news apps team, I have producers that I work with who are all very highly skilled. We’re a small group, but we have a very high operating threshold for skills. And this is totally a question I would love if you came back and asked me six months from now, because we’re still very much building out our process. So, every one of these is kind of like a unique thing.

We take it as a given that there’s going to be a lot of contact with the editor and the reporter as early as possible—the phrase we use is “Participate in the journalism.”

To your point, some of them have been reported out over the course of months, some of them over the course of years. And so, we take it as a given that there’s going to be a lot of contact with the editor and the reporter as early as possible; we’re reading drafts, we’re working on it, and we’re really thinking early on more like reporters and editors than necessarily developers. Everyone here is kind of expected to—the phrase we use is “Participate in the journalism.” So, I’m looking at notes as early as I can and I’m giving feedback to a reporter and editor of like, “Hey, why don’t we think about this aspect of it?” And do you think this is going to be present in the story as it evolves? And maybe we should make a tool that helps people understand that since it’s such a massive, important story.” As far as the nitty gritty of process, I’d say it’s a whole lot of email, a whole lot of sketching, and a whole lot of conversations that happen with people.

Ethan:

Maybe tell me a little bit more about that collaboration and sketching that happens, David. Because specifically what I’m really interested in for some of these more composed pieces that you guys are producing: how do you make decisions about what to keep and what to get rid of, especially when dealing with the constraints of smaller screens? I mean, how do you make decisions about what to prioritize on some of these denser layouts as you’re thinking more responsively?

David:

Feats of strength. [laughs] No, sorry.

Ethan:

[laughs]

I consider myself part of the senior edit group and part of what I have to do is make sometimes ruthless decisions about what has the most impact as a feature in a layout.

David:

Sorry, I’ll be serious. You know, it’s always an ongoing conversation and it changes from piece to piece. It sounds sort of funny to say, because lots of people will say everything is a unique snowflake or everything is bespoke. It’s not so much that. We’re all editors here, and again, it’s a little bit of the difficulty of articulating the intuitive. It’s a newsroom filled with reporters and editors who know the craft of journalism, and inherent to that process is editing. I consider myself part of the senior edit group and part of what I have to do is make sometimes ruthless decisions about what has the most impact as a feature in a layout, and some of that is based on experience, what we feel as editors supports the story the best, what we’ve seen in testing, and what we hear from other newsrooms, as well as our audience. So, it’s also part of that ongoing conversation.

If I’m thinking about elevating some piece of a layout over another or maybe dropping some piece of it, it’s never a surprise—or it should never be a surprise—with the editor or the reporter. It’s part of a discussion and usually has their buy-in as you go through it, of saying, “Hey, I think it’s evolving in this direction besides this and I can totally give you a multilayered version of this when the viewport allows it, or I can condense it down to what is like the ultimate core of its value in a smaller viewport.”

Karen:

David, my ears kind of perked up when you said “bespoke.”

David:

Oh, yes. [laughs]

We have a thing called a reset in there where we just hit a little toggle and all of the default stylesheets and scripts are just not added to the page and you basically get a large text entry field in which you can inject anything.

Karen:

Maybe when you’re making these layout decisions for what elements you’re going to prioritize, those may not come as a surprise to the editors you’re working with. What about your publishing system? How does your CMS feel about this? Is this all completely bespoke? Are you doing these all as hand-built pages, or is this templated on the back-end?

David:

All of the above. It’s a cheeky but true answer. So our CMS is ExpressionEngine, it’s off the shelf. But some time ago somebody had like a little flash of insight; we have a thing called a reset in there where we just hit a little toggle and all of the default stylesheets and scripts are just not added to the page and you basically get a large text entry field in which you can inject anything. And so since I got here, I’ve been trying to take advantage of that more and more in terms of approaching it systematically.

So, Jekyll is an absolutely indispensible tool on the editorial design side of things. We actually have our own Jekyll rig that, as we built out each one of these stories—and I think we’re up to twelve or fourteen now, maybe sixteen or more—we add and fold what we learn into the rig. So, it’s really funny, there was actually a lot of the DNA of the very first custom story I did when I got here, “Ghosts of Greenwood,” for Nikole Hannah-Jones—that’s all the way up and into the patient safety thing we did the other week, which was another huge app and story.

We actually have more flexibility to play around with the layout because we’re not fighting the stuff that’s baked into the system.

But underneath the hood of that, like on the first one I started, we started using Jekyll because it was like, “Hey, this will help organize our life and make it faster. We can write it in Markdown, it’ll crank out flat HTML, which is perfect, because then we’ll just pick that right up and we’ll drop it into that big, empty text field in the CMS, and off we go.” Everything around that rig has been evolving and has been maturing. The joke is that reset button was used for what we called internally “template busters,” but the farther we go, the more template-ized those things are actually becoming and the tools are becoming more robust. And as they do, we actually have more flexibility to play around with the layout because we’re not fighting the stuff that’s baked into the system; we’re actually starting to build like, “Hey, here’s a module that will work two or three different ways.”

It’s an interesting system where things are becoming more template-ized, but by virtue of that, the end result pieces are becoming more and more unique and more custom.

Today we published this beautiful photo and audio essay by Edwin Torres, and we picked up some new ways of doing photo layouts and that gets folded back into the boilerplate part of the rig and will be there on the next one that we go. So, it’s an interesting system where things are becoming more template-ized, but by virtue of that, the end result pieces are becoming more and more unique and more custom. If that makes any sense at all. [laughs]

There’s that weird in-between state where sketches are fantastic—they’re inexpensive, they’re super-fast, and the best part about them is that you can always hand a Sharpie marker to an editor or a reporter.

Ethan:

Yeah, that’s great. It’s funny, because you mentioned that photo feature, which I saw that this morning. My jaw was on the desk. It’s a beautiful piece of work, and I wasn’t expecting the audio component. But I guess it’s features like that that make me want to ask you about some of the applications and tools you use to actually start thinking about the responsive design. Like, what do you and your designers that you’re working with actually use to actually mock up these designs? Or are you doing more prototyping work? Just tell me a little bit more about the process in general for laying these things out.

David:

It’s funny, everything starts as words. So, most things start as an email or a draft from a reporter, an editor, like I mentioned before. So, we really are sort of content-out. And then a whole lot of sketching; there’s time at whiteboards, there’s time in our notebooks. And I think right now we actually jump from there into the browser really, really quickly to the point where actually I’m trying to build out, for my own self, more prototyping tools so that I can actually help people picture stuff. There’s that weird in-between state where sketches are fantastic—they’re inexpensive, they’re super-fast, and the best part about them is that you can always hand a Sharpie marker to an editor or a reporter who will always protest, “Oh, I don’t know how to draw.” It doesn’t matter, I don’t either. It’s a Sharpie, it’s the fidelity; you could never draw fine art with it or get that precise with it.

We don’t want to get lost in prototyping beyond using prototypes to test with users.

But somewhere between there and actually putting things into a browser, I think we probably need to create some more tools so that we can actually help embody an idea in a way that somebody who is less design-savvy can see it and sort of grok it a little bit faster. So to that end, we’re working in Sketch app, we’re building out our templates in Jekyll to a little bit of a greater degree of fidelity, and kind of casting about for better tools in that area. I don’t think we’re going to spend too much time there because we don’t want to get lost in prototyping beyond using prototypes to test with users—that’s my other little hidden agenda there on prototyping—before we get into a browser and actually just get on with the business of building the thing in its native environment.

I really like going to these people and bringing them into the fold because a lot of them are discovering the new turf.

Ethan:

David, just to follow up on that really quickly, I’d like to hear a little bit more about how you collaborate with external partners. If you’re hiring an artist or a photographer to work on a feature, has that changed as you’ve been working more responsively?

David:

A little bit, actually. Some of them are a lot of fun. We have access to a lot of folks I would describe as traditional newspaper or magazine illustrators and photographers who vary all over the map. I’m a kid in a candy store basically as we’ve built up our roster of people that we work with. And it’s the whole spectrum—like any designer would encounter anywhere—in terms of their exposure and knowledge of the online world, and further to that, responsive design. So what you ask of them sort of changes ever so subtly. Like, as we build out more of these pieces, I start pointing to them, to a photographer or an illustrator, and say, “By the way, we want to do this thing where the illustration is fully fluid and you work in a vector native format. I know you’re an illustrator already, you may have never seen this before, but here’s something we’re considering.” And it’s been a lot of fun with the ones who will go with you and be like, “Oh, that’s really cool.”

My illustration now has life breathed into it in a way that I didn’t quite expect. It’s not a video, it’s not a flat layout, but it’s something in between.

So in a minor way, the patient safety piece that I alluded to, I worked with an illustrator in Madrid, Miguel Montaner, and mentioned to him, “Hey, I know you work in Illustrator and we’d really love to have these as SVGs so maybe we could manipulate them a little bit. They’re going to be a lot smaller, it’ll be awesome, they’ll load faster and they’ll look beautiful on retina screens.” And he was so great because he basically wrote back and said, “Well, I’m not really sure. I haven’t really seen this before, but I trust you, so I’ll give you the Illustrator file and we’ll talk it over.” And so he sent it over, I did a demo for it, showed it to him, and he got to see his illustration in this beautiful full bleed kind of way where the two figures that were in foreground actually move with the viewport. And I got a note back from him, he was just delighted. He’s somebody that we want to work with again because he’s sort of discovered this and we’ve discovered it with him and the collaboration is a lot of fun.

So in a way, I really like going to these people and bringing them into the fold because a lot of them are discovering the new turf. And it’s so much better than—I think in some new shops, some places, there’s the idea of the adversarial designer like, “I’m going to come in, I’m going to challenge you.” And to me, this is I’m finding talented people and I’m bringing them into the fold because they see, “Wow, it’s like my illustration now has life breathed into it in a way that I didn’t quite expect. It’s not a video, it’s not a flat layout, but it’s something in between and I hadn’t anticipated that, and I’d really love to do with that some more.”

My guess is that in six to eighteen months we’re going to be at a really awesome place where we’re going to be able to put stuff in front of people very, very early on, like, “Hey, I took your draft and I put it into this layout.”

Karen:

David, I love that. I think it’s such a great way to explain the collaborative process and sort of how these new techniques make that possible. Does that extend to how you review work-in-progress with the rest of the team within ProPublica? So, are you bringing prototypes into meetings with editors or other stakeholders? Are you asking them to look at things in the context of devices? How does that happen now?

David:

We’re trying to get there. That’s actually one of the things that I’m working on pretty hard right now. We don’t have as much of that and we absolutely need to have it, and everybody actually wants that, including me. As I said, I’ve been here for about fourteen months, so part of the challenge is I’m building up a practice from scratch. There’s the presence of design and the knowledge of it, there just wasn’t necessarily a dedicated resource on the user experience side. So that’s, again, part of the Jekyll templates, our sketching, our tools. My guess is that in six to eighteen months we’re going to be at a really awesome place where we’re going to be able to put stuff in front of people very, very early on, like, “Hey, I took your draft and I put it into this layout. Pop open this URL.”

Instead of sending around a Word doc or our usual CMS process, I was actually sending around something with a smaller group to vet the copy edits on it in the actual layout.

We sort of got there a little bit with today’s photo essay for Baltimore, where in the last forty-eight hours I was sending around an internal IP address and asking for copy edits on it. So instead of sending around a Word doc or our usual CMS process, I was actually sending around something with a smaller group to vet the copy edits on it in the actual layout, and just said, “Hey, ping me back if you see anything that we should change on this, or what are we massaging?” And sure enough, I got edits back on that. I included a Word doc along with it because for some of them that’s what they’re more familiar with, and so I find it’s a lot more successful to basically put your new process forward but at the same time incorporate acknowledgement to the existing technique so that you don’t alienate somebody by saying, “Hey, here’s this new foreign thing. I’m giving it to you on my terms. Deal with it.” You’re saying, “By the way, here’s the thing that you expected and here’s something that you necessarily didn’t but it’ll give you a better idea of what it’s going to be like when it’s done.”

Ethan:

David, I’d be curious to hear if performance is something that comes up. As you guys are building out this more responsive design process, is the speed of the work something that comes into the conversation at all?

David:

Oh my lord, yes. [laughs] So speed I think could be two things: it’s speed of actually building the piece or the actual performance in the browser of the sites that we’re building.

The perhaps not necessarily obvious thing that needs to be said about that is I want to get stuff into prototypes faster and faster because that will give us more time to iterate on a design.

Ethan:

Both, I guess. I’ll leave it to you to pick one. [laughs]

David:

Well, I would say both are top of mind all the time, because I know that they’re top of mind for me. The speed of the actual building of the piece—that’s where I live. I want to get stuff set up and previewed faster all the time because… that’s sort of like saying, “I’d like to have more good days than bad days.” It’s kind of obvious why in the benefits to production. I think the perhaps not necessarily obvious thing that needs to be said about that is I want to get stuff into prototypes faster and faster because that will give us more time to iterate on a design. That’s the space where the design goes from good to truly great, that we actually have it some place we can put our hands on it, or hit it with a baseball bat repeatedly, which is more what the process is like as far as refining things. I’m of the mind that most of my ideas are bad when they start off. I have to get them into something and sort of hit it with a stick until it starts to look good, and that means you have to get it into a place where you can get your hands on it as fast as possible. So, that’s the prototyping tools we’ve been sort of banging on and mentioning in the interview.

I find that the time that we spend looking at performance also seems to have very positive side benefits for how universal the stuff is, because you’re really starting to think about the mechanics of how it’s going to work in the browser.

The performance side of it, the “How fast do they download, how smooth an experience?” we are in the middle of kind of—it didn’t actually become an explicit project; I think it’s implicitly becoming top of mind for everybody right now. So Scott Klein, who is the head of the data apps team, I talk to him continually about it, I talk to my own team, I talk to Mike Tigas and Al Shaw and Jeff Larson about it. It’s just something that’s become present for us because it’s a competitive advantage, it’s a competitive expectation now for newsrooms that you’re looking at how things perform. And I also do it for selfish reasons, which is I want my stuff to load fast when I look at it, I want it to work fast, I want it to work in a universal way.

While I’m improving the performance, I find that I’m actually, at the same time, improving its ability to display in as many places as possible.

Interestingly enough, I find that the time that we spend looking at performance also seems to have very positive side benefits for how universal the stuff is, because you’re really starting to think about the mechanics of how it’s going to work in the browser and so you start considering all the browsers that it’s going to be in and the way they actually handle and behave with it. You sort of put your hands in the guts of the thing and you start thinking of all the places that are actually going to receive it. I know that it’s changed my mindset, it’s evolved over time because of that. As I look at performance and I look at Web Inspector, I actually start thinking about things that I might be doing that might hurt Firefox, or might hurt IE, or might hurt this particular context. And so while I’m improving the performance, I find that I’m actually, at the same time, improving its ability to display in as many places as possible.

Ethan:

I had my microphone muted so you couldn’t actually hear me pounding my desk with enthusiasm.

David:

[laughs]

I would typically have a tablet, a phone, and my iMac in the center all on at the same time, all on their pedestals, and using something like Adobe Edge to sync them.

Ethan:

No, that was beautifully said. But it’s also I think a wonderful segue for my next question, which was, in terms of getting stuff as accessible as possible, how does ProPublica think about browser support in a broad sense? And on top of all the other stuff that you’re doing, how do you guys actually perform QA, like browser testing and device testing?

David:

That’s definitely evolving. I think that it’s part of the mindset of becoming, I would say, mobile concurrent. I had a way of designing and developing before I got here, where I would typically have a tablet, a phone, and my iMac in the center all on at the same time, all on their pedestals, and using something like Adobe Edge to sync them. So at all times I was being exposed to the three major viewports, and I would swap in different devices for those classes of things. And we’ve tried to do as much as we can here, we’re actually building that up more and more.

With every pass, you start to look at a device earlier and earlier in the process, and I think that it’s becoming natural now for those things to be there very, very early.

So, QA is basically something that happens towards the end and we’re making it be something that happens more along the way, and that’s also having that mindset of, again, as I said, more mobile concurrent. So a QA process that happens along the way is a QA process that happens with several devices on your table, on your desk from the word go as opposed to addressing a bug that was baked in all the way through and fixing it at the end. I think that we’re pushing towards that and it’s a very organic process, which is we QA, we have devices around, we pick them up, we look at our stuff on them. And with every pass, you start to look at a device earlier and earlier in the process, and I think that it’s becoming natural now for those things to be there very, very early, and I think pretty soon they’re going to be there right from the start for everybody. So, we’re working on that right now.

There’s a funny thing that happens as soon as you start making these responsive designs, like suddenly the mobile share of the traffic grows a lot faster than what the natural growth rate would be.

Karen:

How do you know if these responsive designs or these responsive sites are working for you? How do you look at your analytics data? Do you still break things down by mobile/tablet/desktop? What sort of metrics do you have to evaluate success?

David:

So, we’re like a lot of newsrooms; it’s Google Analytics and Chartbeat, along with a couple of other tools that we throw into the mix. Our engagement editor, who I alluded to earlier, usually keeps a pretty steady eye on analytics and lets us know how stuff is doing. I have access to those tools as well. I mean, there’s just the simple metrics of the page views, time spent, bounce rates. So I look at all of those, and I would say that the fully fluid responsive editorial projects generally do well on all those marks across the board when held up to the previous way of doing things.

The other thing that I kind of think about there is there’s a really odd chicken-and-egg thing that I think people don’t necessarily consider about being mobile friendly, mobile-first, or mobile concurrent, which is that you see your stuff perform better if you design so that it can be shared in that space. That’s probably not the greatest way of phrasing it, but I think most people can see where I’m going with this, which is if you have a desktop site and you try to shove it down a phone, people are a lot less apt to share in that context. Basically what I’m trying to get at is the chicken and the egg point of you can’t share it if you didn’t think of mobile, and if you didn’t…

I guess my way of thinking of it is there is a bit of an implicit assumption being made in journalism circles of, “Well, the audience is going majority mobile, therefore all your traffic will become mobile.” But that won’t be the case unless you actually build stuff that can be viewed and shared and used on mobile. So there’s a funny thing that happens as soon as you start making these responsive designs, like suddenly the mobile share of the traffic grows a lot faster than what the natural growth rate would be, or what you would assume it to be, because you’re making stuff that can actually work in that medium. I think there’s this assumption that majority mobile just happens on its own for a new site, and to a degree that happens, but a lot slower than if you actually built stuff that can be used and shared in that context.

Find the places that are safe to experiment in, which I guess that sounds like, “Avoid losing, that way you’ll always win.”

Ethan:

So David, as we’re coming to the end of our time, with everything that you’ve learned over the last year working with ProPublica, do you have any advice for anybody that might be listening today that might be embarking on their first responsive project? What are some of the things that you’ve learned?

David:

Find the places that are safe to experiment in, which I guess that sounds like, “Avoid losing, that way you’ll always win.” [laughs] But the way that I look at my own job here is there’s three tiers of things that I’m responsible for, which is the production of the site, which is at the most tactical end, then there’s the sort of high-value big showcase editorial stuff right in the middle, and then there’s the website itself, which is really the platform—well, that’s over the strategic end. So, I’ve started at tactical, I’ve kind of moved up into the middle, and we’re actually just starting to grapple with that last strategic part. And none of the stuff that we’re doing would work if I started over all the way on the strategic end because it would be like making a very high stakes bet and a lot of time spent convincing people—often including people who don’t really need to be convinced—but when you start attaching an enormous project to it, it becomes a thing that needs a lot of serious consideration.

The thing I always say about Snowfall, it made newsrooms safe for art direction and research and development on the design side.

Whereas I try to look at it as like, “Where can we inject responsive items onto the tactical end and into these larger editorial pieces, which are, in many ways, very self-contained; they are safe spaces to experiment, they deserve experimentation, they beg for it, they almost require it. And it’s a very interesting thing, they’re like our R&D labs. That’s the thing I always say about Snowfall, not that it made the world safe for a particular aesthetic, it made newsrooms safe for art direction and research and development on the design side.

And so if you’re just starting out and you’re starting at a new place, especially if you’re starting at a place that has established stuff, look for the places where it makes sense to do R&D, to treat these that way so that you can take small experiments. Don’t think that you need to, like, bite the whole thing off in one go. There are these very smart places where you can tackle it and you’ll prove to people that, “Hey, that wasn’t that taxing, it was really awesome, it got great results,” and you can apply that, you’ve learned a little bit.

I’ll pause there and change direction a little bit and say that it’s almost like doing the research on what it would be like to do your huge responsive overhaul on your strategic end. It’s like, “Well, we tested this and these things worked really well, and now we’re just going to scale that up.” So I guess it’s a question really of picking your scale in terms of where you want to begin.

Karen:

David, this has been fantastic. Honestly, I knew it was going to be a delight to talk to you today and you have exceeded my expectations. So, I really want to thank you for spending time with us.

David:

Thank you. I hope I have not terrified anyone. [laughs]

Karen:

[laughs] Responsive web terror, that’s what we’re going for here.

David:

Yeah, you can totally cut that part, sorry. [laughs] It’s been my pleasure, and we’ve been having a lot of fun experimenting here in the last fourteen months. I think you’re going to see a lot more of it in the next six, twelve, eighteen months, two years even. We’ve got a long scale with a lot of great content and a lot of turf to cover that we’re all actually really enthusiastic about covering.

Karen:

Well, I’m enthusiastic to see it, too. So, thank you.

Ethan:

Thanks to everyone for listening to this episode of a Responsive Web Design podcast. And thanks also to our sponsor, Harvest. Go to getharvest.com and start tracking your time, painlessly, today.

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.