Episode Transcript

Editor’s Note: Get an in-depth look at our responsive design and content strategy process for The Toast at responsivewebdesign.com/toast.

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… This is it, guys. This is literally actually the most excited I have ever been in the history of this podcast. This week, I genuinely could not be more excited than to welcome Eileen Webb and Jeff Eaton, who are here to talk about The Toast. Welcome!

Jeff:

Hurray!

Eileen:

Yay!

Karen:

We’re going to do a little bit of a different thing today, which is that we have two of our co-conspirators on the call to talk about a redesign of the website, The Toast, that just launched today.

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.

Yeah, this was a really great project to work on. And I guess before we dive in, we should probably give a quick shout out to everyone who can’t be with us today. I mean, the client team at The Toast was incredible, working with Nicole Cliffe and Mallory Ortberg, as well as Maria and Nicole. From the ads publishing side, we had Hashtag Labs, specifically John and Craige. And the folks from our team, who were down there in the trenches with us, like Aaron, Jenny, and Libby. It truly did take a village, and we have Jeff and Eileen here to represent them.

Jeff:

We’re the exceptionally nerdy parts of the village. [laughs]

I had to read a lot of Toast posts for work. I had to read a lot of Toast. It was a hard job. I really powered through, made it through in the end.

Karen:

[laughs] I just have to say again: I’m so excited you’re here! So, perhaps you could both start off by introducing yourselves, tell us a little bit about the work that you did on The Toast, and maybe you could also address a question that I’ve wanted to know for some time, which is: How are you so great? How are you always so great all the time? Eileen, why don’t you start?

Eileen:

Well, the answer to the second question is chickens. I have a lot of them, they are fluffy, and they make me great. And then the answer to the first question is that my role on The Toast, I was the content person, so I did a lot of diving into the content and sort of… Y’know, I had to read a lot of Toast posts for work, I just had to have twenty or thirty posts open at a time and read a lot of funny things and a lot of special things. I just, I had to read a lot of Toast. It was a hard job. I really powered through, made it through in the end.

Jeff:

We all appreciated it. We know you took one for the team. All the giggling coming from that side of the room, y’know…

Eileen:

It’s really true.

It’s pretty rare to find a scenario where all of the different members of the team understood at least enough about what everyone else was doing that a lot of communication hurdles just went away.

Karen:

Eaton, how about you?

Jeff:

So yeah, a lot of the work that I do at Lullabot, the agency that I work for, is digital strategy work, but my background is just in-the-trenches development. And I’ve done Drupal work for probably a decade, and this was an opportunity to get my hands dirty with WordPress, so it was a lot of fun. I was the back-end guy who was sort of muttering darkly and throwing PHP around, and saying, “Oh my gosh, look at this database schema!” and stuff like that.

It was a lot of fun, because I think everyone on the team was really, really good at what they were doing and also aware of the kind of work that everyone else was doing. It’s pretty rare to find a scenario where all of the different members of the team, even if they were specialized in a particular discipline, understood at least enough about what everyone else was doing that a lot of communication hurdles that are often there on projects just went away.

Ethan:

Well, before we get into “muttering at code” and “swearing at browsers,” maybe we could set the stage a little bit and talk about how we actually got here. How did we actually kick off this redesign? How did we actually connect with The Toast? Let’s talk a little bit about the early days. Karen, Eileen, do you want to get us started here?

Karen:

Well, the project started off by Eaton and I having a conversation about how much we would love to redesign The Toast. And we decided that tweeting was the best possible strategy for getting the client’s attention, and about twelve hours later Nicole was like, “Hey lady, why don’t you email me?” So, that’s really how this started off.

I think it was just a nice confluence of them realizing that they would need to do a redesign at some point and us hurling ourselves madly at them until they figured, “Okay, these people are never going to leave us alone, so we might as well work with them.”

Eileen, do you want to start off by talking a little bit about the content? I think we all would agree that we started with the content, right?

We started by just binging on the content and then making a content model and talking about the taxonomy.

Eileen:

Yeah, we did. I think, very first, we started with a bunch of interviews, actually, of the people who we were dealing with, with Nicole and Mallory, and Maria, and Nikki, and John and Craige, just talking about what is it they needed to do on the site that they couldn’t do today. What did they want to be able to do in the future? They were working with a pretty vanilla WordPress install, and so when we started looking at the content, it was just like it was all one content type.

They were, what’s the word, creative, with their use of taxonomy? Mallory’s posts often have hilarious tags attached to them, but there’s only ever one post in the tag, in many of the tags that Mallory makes. (More about the taxonomy.)

A lot of our effort went into making the authoring experience really, really easy and smooth so that they could do the unique special formatting for the different posts.

And so, we started by looking at a lot of the posts. Like I said, I would find a link on Twitter and I’d be like, “Ooh, this is a Toast post,” and I’d be like, “Ooh, this is work that I’m supposed to be doing! I’m not goofing off right now! I am doing an audit and research on my client’s site. It’s perfect!” So yeah, we started by just binging on the content and then making a content model and talking about the taxonomy.

The content model ended up being really simple; it is actually only one post type, but with a lot of different options. Sometimes the posts have lists of images in them, and sometimes they are essays, and sometimes they have sections and sub-headers and things. A lot of our effort, instead of going into making a complex model with lots of interrelated content types, went into making the authoring experience really, really easy and smooth so that they could do the unique special formatting for the different posts really easily.

The work that we did with the underlying content structure and content types was really what fed into the design process.

Karen:

I’ll follow up and say—this is one of my big axes I’m grinding on the industry right now—is that I believe that the work that we did with the underlying content structure and content types was really what fed into the design process. So working with Jenny, who’s a design director I’ve worked with for like a decade now, she was able to take some of the patterns that we came up with and develop a library of styles. And then that underlying set of styles was what Ethan worked with to start developing a responsive prototype. (More about content models and design patterns.)

Ethan, you want to get into that, since that’s what we’re here to talk about?

Getting out of Photoshop as early as possible, so we could actually make it properly responsive was a big part of my job.

Ethan:

Yeah, no, totally. I mean, Jenny did a heck of a job designing a really intuitive system that was really beautiful, first of all. Then working with that, getting out of Photoshop as early as possible, so we could actually make it properly responsive was a big part of my job. When that happens, there’s always going to be things that come up. Like, how do we actually want to not just make this layout squishy? How do we want to figure out how it’s going to work on older browsers and devices? Because there’s more than a couple of them out there. How do we ensure that it looks good but it’s also incredibly fast? (More about design and illustrations.)

We set up a really rough performance budget and used that to guide the prototyping process, and then just ensure that we were always meeting that benchmark.

So performance was also a big part of my domain, as well. On that front, before the prototyping even started, we did a little bit of work with The Toast getting a lay of the land in terms of how quickly their current site loaded, how quickly some of their competitor sites loaded, and trying to get a baseline read of the general health of their website relative to some of the other folks that they were publishing with.

From there, we set up a really rough performance budget and used that to guide the prototyping process, and then just ensure that we were always meeting that benchmark, or beating that benchmark whenever possible, as the prototype was shaping up. The nice thing about doing that, like continuing the design process when you’re actually building in devices and browsers, is there are always these design questions that come up. Like, you might spec a specific module or specific pattern to behave a certain way in Photoshop, but when you actually are testing it in real network conditions, or maybe you get it on a real device that actually has a touch interface, that might spark questions with the client or with the design team about how we might need to think about that pattern a little bit differently. (More about responsive design and performance.)

It’s about foregrounding the idea that a lot of our creative decisions and design decisions actually impact the user experience from a performance standpoint.

There are a whole bunch of tools you can use to really focus on performance. WebPagetest.org is a big one. Another one that we use, especially in the planning stages, was Andy Davies’s WordPress WebPageTest Tracker, which is basically like a Google Docs script you can do a lot of auditing work with. But really, it’s about foregrounding the idea that a lot of our creative decisions and design decisions actually impact the user experience from a performance standpoint. So, that’s really where my work started.

But while I was tinkering away on static prototyping and static templates, I at some point actually hand all of my terrible decisions off to Jeff Eaton to do things with actual real code on the back-end in WordPress. So Jeff, why don’t you set the stage a little bit for us? What did that transition look like, and what was going on on the back-end in general?

What we were trying to do on this project was not just crank out a particular theme for WordPress but rather make sure that the design reflected a lot of the modular concepts.

Jeff:

Well, there was some wailing and there was some gnashing of teeth. It was actually not that bad. My background is primarily heavy duty Drupal stuff and smaller systems, like working with Django and stuff like that. WordPress is interesting because it’s really mature; it’s like, really, really popular. Lots of people know WordPress inside and out and they can make it sit up and sing and dance and make your coffee.

But it’s interesting, because what we were trying to do on this project was not just crank out a particular theme for WordPress but rather make sure that the design reflected a lot of the modular concepts that were driving both the audit that was going on with Eileen, the design work with Jenny, and then the responsive components that you were putting together. And that actually—I think the hardest part was that that didn’t necessarily fit well with the WordPress approach, at least the most obvious paths that you have to customizing those templates and stuff like that. (More about the back end.)

I’m not sure I would’ve stayed sane without the Timber library, it was a really huge help.

One of the tools that ended up being really, really invaluable was the Timber library by Upstatement, a Boston-area web design firm. It’s a free, open source project, but it basically gives you a templating engine inside of WordPress that makes it much, much easier to reuse smaller modular components across all of your different templates, and it helps isolate a lot of the goofy special case logic that you have to do on any real world design from the actual markup that you see in the templates. So, Timber basically helps you keep the actual front-end templates clean and tidy so that the people who are doing pure front-end development work find it a little easier to pop those files open, check out the markup, make sure everything is good, while your back-end developers can be messing around with all of the logic for how your related posts stuff actually gets populated and when certain components should appear and stuff like that. I’m not sure I would’ve stayed sane without the Timber library, it was a really huge help.

Ethan:

Just to chime in briefly, I’ve worked on some WordPress projects, but not in years, and this is the first time where theming a WordPress site was beyond manageable. It was actually a joy to do. So yeah, Timber was a huge part of that.

Jeff, could you talk a little bit briefly about some of the decisions that went into the community aspects of The Toast, specifically the commenting system? There was a healthy amount of discussion there.

What we soon discovered is that it turns out there aren’t really any good commenting platforms, there are just “less bad in certain kinds of ways” commenting platforms.

Jeff:

Yeah. So when we arrived and started talking to The Toast… They’re using a system called IntenseDebate that was rolled out by Automattic, the makers of WordPress, a number of years ago when they were sort of trying to get a standardized commenting platform that everyone could use. It has since been… I won’t say sunsetted, but they are no longer working on it or actively developing it, although it is there and continues to work and hum along.

So our first thought was, “Okay, we’ve got to replace this and we’ve got to get them on a better commenting platform.” But what we soon discovered is that it turns out there aren’t really any good commenting platforms, there are just “less bad in certain kinds of ways” commenting platforms.

The nuances of how their community interacted in the comments and the kinds of back and forth that they had were really, really critical because they have an incredibly active community.

For The Toast, the nuances of how their community interacted in the comments and the kinds of back and forth that they had were really, really critical because they have an incredibly active community. Like, to the point where an open post, where people can just chat, will very quickly accumulate hundreds, even a thousand or so comments as people just chat, talk about everything from art, and philosophy, to what’s going on on the internet, and stuff like that. Really popular articles, not even open threads often accumulate a couple of hundred comments on The Toast. It’s all very, very high quality commenting, too. We were talking—I think MetaFilter is the only other place where we’ve seen consistently high levels of signal versus noise in discussion threads.

A redesign is always a little jarring for everybody involved, even if they’re good changes; it’s like your house has been repainted and all the furniture has been moved.

We really wanted to make sure that nothing we did would alter all of the affordances and the rhythms that that community had developed over time, because a redesign is always a little jarring for everybody involved, even if they’re good changes; it’s like your house has been repainted and all the furniture has been moved. We wanted to make sure that we didn’t alter any more than needed to be.

So we decided after a lot of discussion to stick with IntenseDebate. Disqus felt like it might’ve been better supported, but it was much, much harder to customize and didn’t have some of the support features they wanted. Preserving all of the existing comments was just an absolute must-have because there’s such a rich history of all these discussions that are there. Just going to WordPress’s native built-in commenting, it was probably going to be really punishing performance-wise because that’s handled just like, literally on the web server, rather than by a third-party service.

After a lot of discussion, we ended up deciding to stick with IntenseDebate, and I think it was all on Ethan’s plate. He worked some zany magic to actually get that looking good and fitting in with the rest of the design of The Toast. In the future, The Toast team knows that they would like to migrate to a new platform and they’re going to have to figure out what the long-term game plan is, because IntenseDebate won’t be around forever. But at least for now it allowed us to get the redesign out there without making that discussion and commenting component of it too much different for the people who are really, really active, vibrant parts of the community.

Advertisements are, from a performance standpoint, from a responsive design standpoint, they’re always challenging.

Karen:

You know who else is a really active, vibrant contributor to The Toast? Its advertisers. What did we do? Ethan, Jeff, I’d love to hear both of you talk about some of the work that we did to make advertisements better integrated with the reading experience, make them faster, make it a better experience for people who are buying space on The Toast. Ethan, you want to go first?

Ethan:

Yeah, I can start there. Advertisements are, from a performance standpoint, from a responsive design standpoint, they’re always challenging. They’re a vital part of most online publications. But in terms of making them fit in a completely flexible responsive design can be a real challenge. And then ensuring that they don’t negatively impact the user experience is also another big one as well. Thankfully—I mean, I mentioned Hashtag Labs right at the beginning: John and Craige, they were both incredibly accommodating, talking to us about some of our approaches for planning this out, trying to think about a decent delivery mechanism for them.

In terms of pure performance, really one of the best things you can do for advertising is try to keep it out of the way of the core content the user is trying to get to, so they’re not actually blocking page loading.

A couple of the things we tried to do, just from a layout standpoint, was we tried to target certain ad classes just at specific breakpoints. So if you’re on an incredibly small screen, like a wrist-based browser, you’re not necessarily going to see any properties. But as screens get a little wider or they get taller, we can then start layering in and progressively introducing more and more properties, and hopefully in a way that feels like it actually fits a larger viewport, so it feels a little bit more organic.

Just in terms of pure performance, really one of the best things you can do for advertising is try to keep it out of the way of the core content the user is trying to get to, so they’re not actually blocking page loading. The Toast had settled on Google’s DFP product for advertising, which thankfully makes it pretty easy to do just that. You can get basic styles and content into even the slowest connections as quickly as possible, and then in the background, while the page is actually usable, you can introduce the advertising without slowing things down even further.

At least from my standpoint, it was actually fairly easy to get the ads working in a way that wasn’t going to necessarily slow down the site; we were actually able to speed up the site pretty significantly in the redesign. Then from there, it was kind of on Jeff to do a lot of the magic from the back-end standpoint in terms of weaving them into the articles in a way that felt pleasing. Jeff, if you want to talk a little bit about that?

We wanted to make sure that we had full control and that it was possible to weave ads into sensible locations in the design.

Jeff:

One of the challenges too—when we first picked up the site and started working with it, it was in state that’s very, very common for a lot of WordPress blog buildouts. Basically, it was using some standard ad slots that had been placed into the theme and page templates, and it was allowing Google’s scripts to do the rest. But that means that you’re fairly limited, both in terms of your control over the performance, in terms of when things are loaded, and in terms of where things go. You essentially have theme sidebar locations and you’ve got to drop things in there and hope for the best.

One of the things that the custom theme we built out, in part with the help of Timber and then with some custom code that we had put together, we wanted to make sure that we had full control and that it was possible to weave ads into sensible locations in the design, even if it wasn’t necessarily like, “Oh, of course, the sidebar, we will dump the ads there,” or something like that. Wrapping around the content was fairly easy. The front-end markup that Ethan produced handled a lot of that, and there were some cool front-end JavaScript tricks that made it very, very speedy to shuffle certain page elements around and account for the different breakpoints, both with ads and other promotional elements on the page.

It very quickly allowed us to test out what kind of feel we wanted and how many ads we could drop into, say, a long article, without it feeling intrusive but still managing to get a fair number of placements in there.

One of the other things that we built out was something—in a desperate attempt to work more bread and toast-related puns into the project, I called it “Toast Jammer.” Basically when an article is ready to be displayed, it’s a piece of WordPress code that’s just a library that goes through and walks through all of the text of the article, and there’s a couple of different knobs that the site owners can turn. Like, how long should an article be before we start placing ads inside the body of the article? What different kinds of elements in the article shouldn’t we put ads next to? If we’ve placed an image or a pull quote or something in there, we don’t want an ad falling right before or right after that. How much space should we have before we place an ad in there? By adjusting those things, it very quickly allowed us to test out what kind of feel we wanted and how many ads we could drop into, say, a long article, without it feeling intrusive but still managing to get a fair number of placements in there so that they would be able to, you know, support the site.

What this system we’ve built out allows them to do is just sort of sprinkle the ads through those long articles at fairly consistent intervals.

One of the things that this allowed us to do was to completely get rid of paged articles, which I personally consider sort of a plague on the internet. I’m okay with the concept of dividing an article up into sections and you move from one page to another if it makes sense narratively speaking. But so much of that right now is driven entirely by the need for page views, where if you’ve got, say, a 6,000-word article, breaking it up into six 1,000-word pages means you get six times as many ad impressions. For sites on a shoestring budget, that’s a really important part of how they support themselves. Well, what this system we’ve built out allows them to do is just sort of sprinkle the ads through those long articles at fairly consistent intervals, but avoiding elements like block quotes and stuff like that, and not have to break it up into a paged form. I’m a big fan of that.

What we then later determined is there’s even other applications for it that we were able to use, like on long articles it also allows us to drop in things like “More articles that are like this one that you might also be interested in.” We can use that to intersperse elements throughout long pieces without feeling like we’re also going to be overwhelming a shorter article.

Ethan:

Let’s talk a little bit more about those recirculation modules, like the “You might also be interested in…” or popular articles or popular series. I’d like to hear a little bit more about how those were actually built, some of the planning process specifically that got us up to this point. Eileen, why don’t you give us a little bit of a design insight into the content side?

There were 6,000 tags that had only ever been used once.

Eileen:

As I mentioned, The Toast had been using taxonomy kind of creatively. They had been using the single tag field in WordPress to hold real tags, and topical tags, and tags that duplicated the categories, and at some point some plugin that they had installed and then later uninstalled created tags for every author that existed.

We started by doing a SQL dump of all of the tags—I don’t have the exact number in front of me, but it was something like 7,300 tags. When we dumped them out, we also dumped how often they had been used, like how many posts were tagged with each tag, and we sorted those into lists of things that had been used more than ten times, things that had been used between five and ten times. There were 6,000 tags that had only ever been used once.

Jeff:

And 600 that had never been used.

Eileen:

Yes, yes. So that was a great way to start sorting through the tags. We assigned Nicole and Mallory and The Toast team to go through and tell us—like, they basically had to go through the spreadsheet with brute force and say, “Okay, this is a tag that is a topic, this is a tag that is an author.” Who’s like, an author of an article, as opposed to someone who is an author of a book that they were discussing, which then becomes a topical tag. We created essentially paths forward for all the tags. Every tag had to be marked with whether, moving forward, it would become a topic or it was actually supposed to be a category, whether this tag should be merged upwards. There were a whole bunch of different paths. They went through, it took awhile, and there were tweets like partway through where they would screenshot something about how much they hated tags and I’d look at the little screenshot and I’d be like, “Okay, they’re on the Rs; they’re halfway through, they’re on the Rs, that’s great.”

Then Eaton was able to take those and do—because WordPress’s database schemas are relatively simple, he was able to take a whole bunch of those future paths and write scripts to merge things automatically and to rename things and to move things into multiple different taxonomies.

We separated out tags and categories. We separated out something that had never been separated before, which was a series.

We separated out tags and categories. We separated out something that had never been separated before, which was a series. The Toast has a number of recurring series, and so we separated those into their own taxonomy, because a series isn’t a category, but in many places in the UI it supercedes category, like, it’s more important that it’s in a series than it’s in a category. Once they were all separated, which was, you know, a big brute force kind of task, then we were able to do really cool logic with them.

Karen and I basically, like, one day we had a meeting with Jeff and we just spent an hour being like, “Can you do this? Can you do this? Can you do THIS?” and he would alternately tell us like, “Yes. No, there’s too much of a performance hit.” But mostly it was yes, which was like kid in a candy story for us, man. It was pretty exciting.

Karen:

You might think that forcing Nicole and Mallory to sort all of their tags was my best client trolling of all time, or perhaps a preventive measure so that next time they want to go nuts with their tags, they’ll realize the pain that’s in store for them. But actually that work was really needed. It was necessary because otherwise I don’t think we would have been able to truly live out our vision of thinking through how we wanted all this logic to work and having somebody as amazing as Jeff Eaton there to make it a reality.

We wanted there to be some serendipity around people being exposed to things that they might not previously have seen.

We spent a fair amount of time working through the logic for how all of those different recirculation modules would populate. We wanted to make sure that interesting and relevant content would be surfaced, we wanted to make sure that there wouldn’t be collisions between blocks that would be showing the same article, so we didn’t want the same thing to show up multiple times on the page, and we wanted there to be some serendipity around people being exposed to things that they might not previously have seen.

From my perspective some of the real benefits of that work was that now you would be able to get to other articles in a series much more easily. I think that’s one of the strengths of The Toast, is that they have some long-running, frequently published series, like Mallory’s Western Art History, or If Someone were your Something—like if somebody was your boyfriend or girlfriend. On the previous site, I don’t know that those got surfaced as well, or it wasn’t as easy to find past articles in a series. I also think that The Toast has some fantastic authors writing for them, and you may not have been able to see all of the posts written by Roxane Gay or Jess Zimmerman as easily as you can now that the taxonomy is there to support it.

If you’re thinking of an iterative prototyping model, those are the kinds of things that you don’t need to decide up front, you can decide them when you actually have your hands in the code.

I will say that as much as I believe that this was a content-first project, I will also say that the logic around what actually went in each of those modules was something that we did very late in the process. We came up with the concept of having recirculation modules and we knew what they were going to contain; we knew that they were going to contain a headline and an image. But it wasn’t necessarily clear until we got deep into the logic in WordPress, when we tweaked which ones were going to appear on which page and where they were going to appear. I think it’s perfectly appropriate to leave some of those decisions until later in the process. I guess if you’re thinking of an iterative prototyping model, those are the kinds of things that you don’t need to decide up front, you can decide them when you actually have your hands in the code. Eaton, you might disagree with me there.

Jeff:

No, I think that’s absolutely right. I think the most important thing is that we had figured out what the design treatments of those recirc modules were going to be very early. We had the visual language and the front-end markup patterns and stuff like that, so we weren’t just ad-libbing our way through that stuff, throwing the design into chaos. We also knew what the recirc modules were supposed to accomplish, so it wasn’t like we had a big blob in the design where we said, “Something fancy should go here!” We understood why it was going to be there, what job it was going to be doing. But we knew that, say, some of the work that Mallory and Nicole were doing in sorting through the tags and getting all those relationships ironed out was going to be necessary before we knew exactly how we were going to populate one of those recirculation modules.

Timber made some of the development work simpler by allowing us to have reusable markup templates that we could drop in as sub-page components without necessarily having to use WordPress’s full widget implementation.

Again, not to harp on it, but this is where Timber made some of the development work simpler by allowing us to have reusable markup templates that we could drop in as sub-page components without necessarily having to use WordPress’s full widget implementation. That made it a lot smoother for us because we could put dummy data in there very easily and then start populating it with real data as we needed to, like the algorithm for what constitutes a related article, or when should we have an author’s previous articles versus other things in the category appear in this little blurb? Those kinds of things, we were able to iron out the logic, but we knew that the building blocks that we had structurally were all sound by the time we were ironing that stuff out.

Karen:

As we’re coming to the end of our time here, I would love to hear from all of you. If you have any advice for other people who might be listening who are about to embark on a responsive redesign, what would you recommend? What would you tell them to do? Eaton, you want to go first?

I would say it’s way too easy to review responsive design as a purely front-end concern.

Jeff:

Again, I’m playing the role of the back-end guy here on this project, but I would say it’s way too easy to review responsive design as a purely front-end concern. Although it’s possible to layer it on at the templating level, if you start thinking about the issues involved in responsive design in terms of: what are our core page components, how are we going to be reusing different elements, particular types of things that we’re building out on the back-end, how will they be reused in different ways across the site? Those kinds of component and module-level decisions, if you plan those things out and understand that you want to account for that kind of flexibility, you’ll be able to feed into the responsive front-end way easier than if you treat that as just something that has to be slathered on the top of a much more rigid back-end.

Karen:

Eileen, how about you?

You’ve got to have people who can build your stuff, but select really highly for people who delight in solving puzzles.

Eileen:

I would say that if you are a person who is putting together a team for a responsive project or you have some sort of influence over the makeup of your responsive team—sure, skills are important, I guess, because you’ve got to have people who can build your stuff—but select really highly for people who delight in solving puzzles. Because, not only were we all super nerdy and really excited about solving our own puzzles in this project, but also we would get really, really excited when each other solved puzzles. I would watch conversations happening that I could kind of follow, like I knew enough to follow them, and then when the solution came, it was really exciting and it was really fun for all of us, whether or not we were involved in a particular piece of the project, to be part of the puzzle-solving. To get very jazzed about things like performance and ad placement is not always the most exciting thing, and so it’s really good to be with a group of people who find ways to make that joyous.

Karen:

Hey, what about you Ethan? You must know something about responsive design that you could advise people on.

One of the things that I really like that we did as quickly as possible was moving into a prototype.

Ethan:

Oh, well, this never happens. [laughs] I think just to echo what Eileen said, although I think from my standpoint, one of the things that I really like that we did as quickly as possible was moving into a prototype. Introducing this idea that while we had a pretty firm and a really beautiful creative direction upfront, talking to The Toast and setting the expectation that when things move into the browser and move into devices, we might rethink some of those assumptions a little bit.

Having a team that’s working with you that understands that the web and designing for the web means change from time to time. It means bugs, it means terrible CSS, it means bad browsers. If you can get people that support the fact that some of your creative decisions, some of your technical decisions might change some of those early ideas, it’s going to ultimately result in a much better product.

Karen, what about you? What did you learn on the project?

Karen:

Well, my advice for everyone for embarking on a responsive project is that they should get Ethan Marcotte to do the responsive design. That has worked out extremely well for me on the sites that I’ve done. I would also say that if you have a chance to work with the team from Webmeadow, Aaron and Eileen are absolutely amazing. And, of course, if you need a WordPress site built, I think there’s no one finer than Jeff Eaton to build that for you. He’s pretty excited about his future career in doing WordPress work.

Jeff:

[laughs]

There is no better client out there than the team at The Toast, so let me give extra special thanks to Nicole and Mallory and the team over there.

Karen:

No, if you are looking for Drupal work, Jeff Eaton and the team at Lullabot are among the finest in the industry. I will give a shout out to Jenny, and Libby, who was our illustrator on the project. Both of them have been amazing to work with. And honestly, there is no better client out there than the team at The Toast, so let me give extra special thanks to Nicole and Mallory and the team over there, as well as to you, Eileen and Eaton. Thank you so much for coming on the show today. It’s been a real pleasure having you.

Eileen:

Thanks for having us.

Jeff:

Thank you. It’s been great.

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.