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, well, I don’t think we could even possibly be more excited than to be joined by a good friend, Jeff Eaton. Welcome!

Jeff:

Hi! It’s a pleasure to be here. I’m a huge fan of the podcast and it’s great to be on it.

Karen:

I’m a huge fan of you!

Jeff:

[laughs]

Ethan:

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

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

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

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

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

Karen:

For the benefit of our listeners, we sometimes do interviews just with individuals who we think are doing interesting stuff, and Jeff Eaton’s always doing interesting stuff. So, to kick it off, maybe just introduce yourself, tell everybody a little bit about who you are and what you do.

Jeff:

So yeah, my name is Jeff Eaton, as you mentioned. I’m senior digital strategist at Lullabot. We’re a sixty-person or so digital agency, and we do a lot of big content projects. Usually design and strategy and CMS implementation often for publishing, or entertainment, or media companies, but also educational institutions and large enterprises that are doing things like knowledge bases or intranets, where they need to wrangle a lot of content and figure out how to make the best use of it. And obviously over the past, I’d say, five years or so, slowly but steadily responsive design has become a much more critical part of any of those processes, to the point now where it’s sort of table stakes for any project.

Karen:

So, I would be curious to have you answer the question, just to sort of add some framing: there’s a trend in the industry these days toward what’s called decoupled content management…

Jeff:

Oh boy…

Karen:

Phew, let’s just get right into it. So, maybe you could give a brief definition of what is decoupled content management and why are organizations moving or thinking about doing it these days. And then especially I’d be curious to have you answer the question of what does decoupled content management have to do with responsive web design?

Jeff:

I am so glad you asked. This feels like the ultimate soft ball question; this is what I rant about even when I’m not on a podcast. So, decoupling is basically the idea that you take the fundamental content management and editorial functionality that’s a part of most major web projects and you try to remove as much as possible the tight linkage between that management and editorial functionality and the front-end presentation functionality that actually directly spits out HTML or implements the details of the front-end design that users see when they visit the site.

Historically, back when we just literally made HTML files and, by hand, threw them into a directory and that was our website, there was just a one-to-one correlation between the content that we were working with and the actual HTML markup and the presentation stuff that people saw when they visited the site. But as CMS systems became a bigger and bigger part of a lot of projects, there’s sort of been a pendulum effect in how tightly coupled the underlying content and the user-facing design stuff is.

I think there’s a real strong trend today, especially as mobile apps and content APIs and other ways of reusing the same underlying content in different contexts become more and more popular and more of a driver for a lot of replatforming projects… As that becomes a bigger issue, the need to make sure that design assumptions about, oh, well we’re going to be displaying this for a particular viewport, or, oh, we’re going to be doing “this year’s design,” that’s how we’re going to be showing things… Teasing those kinds of assumptions apart from the underlying reusable content assets has become more and more of a hot topic, and decoupling is basically the catch-all term that’s become popular for a bunch of different techniques that revolve around that idea of teasing apart the management and creation of the content assets from the design assumptions that govern how it’s presented.

Which brings us to where the responsive design stuff comes in.

Karen:

Boom.

Jeff:

Yeah. I think they’re often discussed together with each other because any project that needs to deal with questions about decoupling… Oh, we need to have a mobile app and we need to send out content feeds to our partners, and we need to have it work on all these different browsers… Anything that is concerned with the issues of decoupling to that extent, any organization that’s healthy that’s thinking about decoupling should already have really grappled with the questions that responsive design brings up, of actually teasing apart a lot of their viewport and device-specific HTML and design assumptions and turning that more of a system for how it responds to different contexts.

So while the responsive web design stuff tends to be more about the presentation aspects and how various scenarios for viewing a website are dealt with, a lot of the basic philosophical questions that you end up having to grapple with on the design side with responsive design are very, very similar to the kinds of structural and content and workflow issues that have to be grappled with on the decoupled side. So oftentimes you’ll see a decoupled content management system, it will be feeding its content into a front-end design that uses responsive design techniques to deal with different browsers and different viewport sizes and stuff like that. But in addition to that, it might also be set up to be able to feed the same content to, say, an iOS app or… The iOS app is always the go-to example of that, but I think we’ve got a client that’s also feeding stuff to like Roku apps and XBOX apps and set-top devices and stuff like that, so they have to deal with a lot of stuff that goes beyond just HTML and browser-specific concerns.

Karen:

Let’s talk about the idea of a responsive retrofit.

Jeff:

Ooh…

Karen:

I think that many organizations tend to equate responsive design sometimes with doing a retrofit. So, rather than doing the work that you’re describing and doing the difficult prioritization challenges around what’s most important to the user and how do we separate content from presentation, organizations just drop in some media queries and some breakpoints and call it a day. How do you see a responsive retrofit kind of intersecting with some of these questions about decoupled content management?

Jeff:

Badly. Well, that might be a little cheeky for a useful response. I think there’s always room for those kinds of steps when you’re on a transition from an older style of design that makes a lot of assumptions about how a particular set of markup will end up being displayed towards sort of the ideal platonic responsive future where you can throw it at any kind of device that’s capable of displaying HTML and it works nicely. There’s always room for those sort of intermediary steps where you say, hey, we may not have the time or the resources or the ability to really fully tackle starting from scratch and reassessing our site and our content and how we want to approach this thing in different contexts, but we can certainly throw some design resources at it and make sure when you’re on a tablet everything just doesn’t break. We’ll add some additional rules and stuff like that.

The challenges, and we deal with this a lot with clients—Lullabot, the projects that we’re brought in for are often fairly large-scale refits or replatforming, and one of the common threads is, “Well, we’re moving from one CMS to another CMS and it’d be a shame to have to do a complete redesign, too. We pretty much like the way it is, we just want it to be responsive as well.” And theoretically, that can work. There’s nothing inherent in responsive design that says you can’t just layer responsive techniques on top of an existing design. But it’s also really, really easy to sort of paint yourself into corners, where suddenly you’ve got all kinds of techniques you can throw at it to try to sort of massage and squeeze and squish a particular design into a different viewport, but you’re fighting an uphill battle to try to take all of the content that was really meant for a static, non-responsive layout and to try to sort of coerce it into a set of responsive rules.

And especially in large organizations where there’s huge amounts of legacy content, we find that the process of going through and auditing and updating and fixing fundamental content issues ends up being really closely tied to how successful a responsive refit or redesign can be, because oftentimes the idea that editorial users may have been creating content and banging out lots of pages that looked okay and looked good, but once you start putting them into different contexts, like changing, say, breakpoints or actually adjusting things, you suddenly discover all kinds of static tables that they had been placing into body fields and odd tricks that they’d been using because it looked good in the old design and they wanted something to look a particular way, but once you start adjusting the rules that govern the overall layout, all kinds of stuff in your underlying content ends up breaking or looking really goofy. Those are the kinds of things that are tremendously difficult to fix just by layering additional CSS rules on top.

I’m guessing that Ethan probably has even more thoughts and feelings about that. But at least from the implementation side, those are the kinds of things where we run into it a lot.

Ethan:

No, I think that makes sense. But Jeff, this might be a good time for me to jump in, because listening to you talk, I’d be really curious, especially when you’re having some of these initial conversations with a client, what are some things that you look for that might make you inclined or disinclined to recommend a decoupled approach? Are there things that raise red flags or specific opportunities that you see?

Jeff:

Oh, boy… Well, what we’ve found is that as the buzz around decoupled CMSes has increased over the last probably year or two, more and more clients are coming to us right out of the gate and asking, “Hey, should we go decoupled?” So, we’re finding that it’s no longer just a technical tool that we may bring to the table and say, “Hey, in this implementation we’re thinking of using these decoupling techniques.” We’re finding that clients will actually come to us and say, “Hey, should we do this?” and they’re treating it as sort of a strategic choice. Which, I think is good because it’s the kind of thing that should be treated as a strategic move, not just a switch that you flip.

The times that it’s a really good fit are when you legitimately do need to take a single underlying pool of content, like obviously in media and publishing and stuff like that, your articles or your reviews or your recipes, or whatever the fundamental assets that your primary content resource is, when you want to be able to take those and repurpose them on lots of different platforms and lots of different contexts, and you don’t want to have to basically redesign or re-work all of that content every time you decide that there’s some new destination channel or destination endpoint for that content that you want it to be able to go to. So, you end up designing this sort of content repository that holds onto all of that stuff, and your website may be the primary place where people engage with that stuff and find it, but it’s treated as one of many consumers of that underlying content resource.

If thinking about what you do and what you create and what you publish—if that feels like it’s a description that makes sense, then decoupling probably is worth looking into and worth exploring. But if what you’re doing really is We have a website and that’s what we do, and there may be one or two adjunct places where your content is also going in RSS feeds and some classic tool like that… Going fully decoupled, from a technical standpoint, does bring overhead with it. Suddenly you’re building a JavaScript-based front-end application, not just a CMS that can generate HTML. And that’s one of the places where we find a lot of organizations don’t necessarily think through what all of the things that they get from a CMS essentially for free are. If you abandon the CMS for actually managing the front-end of your actual website, you’re giving up a lot of tools. Things like localization of UI text and microcopy and stuff like that, or whatever accessibility provisions that your CMS or the existing templating system you have may provide, you’re sort of taking on the responsibility for handling all of that yourself in whatever you build as the new front-end for your wonderful agnostic content repository.

I think for some organizations, it makes a lot of sense and some of the techniques can be used even without going “whole hog,” fully abandoning your CMS or something like that. But it’s not something that just magically solves problems. It’s a particular response to the challenges of multi-channel publishing and content reuse.

I think in some ways it dovetails with a lot of the conversations about responsive design. The tools and techniques of responsive design aren’t a magic bullet. There’s lots of organizational and underlying content challenges that you still have to grapple with and you still have to solve, and if you’re not willing to chew on those things… You can layer responsive techniques on top of it, but you’ll still be running into a lot of bumps and hurdles.

Karen:

One of the challenges that I see many organizations facing, and I would imagine that you and everybody at Lullabot sees this a lot as well: You have a company that needs to redesign their website, or they realize, *Oh, mobile and all these other platforms, we need to make some changes and invest in some infrastructure,” and so they essentially have three challenges. They want to go responsive, they want to replatform their CMS, and they need to clean up and fix their content—they may not realize that, but I think you and I recognize that that’s probably the main problem they have to solve.

If you were talking to an organization that came to you and said, “Hey, we want to move to Drupal, and we want a new website, and we want it to be responsive,” and you’re staring down the barrel of eleventy bajillion crappy content pages, what would you tell that client? What advice would you give them about how to do that well or how to sequence the work that they have to do, or how to make a project like that not turn into a five year-long death march where everybody’s fired in the end?

Jeff:

Oh boy, yeah, those are the fun ones. You know, there’s a running joke that the first thing you should start working on the minute you have a contract or you’re even thinking about doing any kind of CMS replatforming is, “Well, you should start the migration immediately.” Then once you’ve immediately started the migration, you should accept that you’ve probably started it too late, just because the process of actually taking a close and detailed look at all of the stuff you’re moving into a new system or even just moving into a new design, and assessing how well it fits, where the rough edges are—that’s a process that it’s always easy to underestimate. I’ve seen organizations get tremendously lucky and say, “Hey, after we’ve taken a close look, eighty percent of our stuff just works.” There’s some polishing and sanding out the rough edges, but things just work.

But it’s far more common to suddenly discover that there’s really weird tangly content problems that go back, say, five or six years, maybe even ten or twelve years depending on the organization, that you have to sort through and make hard decisions about. Most of the time, the actual mechanical work of updating the content isn’t the hardest part. It’s making decisions, it’s what should we do with, let’s say, a giant pile of old editorials in which there’s formatting and photo assets that never really made it into our asset management system, so we’ve got a bunch of hard-coded HTML in there that bakes in the way we were handling photo galleries ten years ago, and that’s not going to work with a new design, it’s not going to work with our new CMS. We’ve just got to figure out how we’re going to deal with those situations. The technical side of it is not as complicated as making the actual decisions and figuring out what parties need to be a part of it. It feels like a cliché, but the organizational and people issues are always more complicated than the technical ones. Unless we’re talking about Flexbox issues.

Ethan:

Jeff, hearing you talk a little bit about some of the challenges with publishing in a multi-channel environment… One of the conversations I’ve been having with some clients recently is how that impacts design consistency across some of these different channels. So, design patterns is kind of a big conversation that’s happening right now, and thinking about how you actually get something that feels appropriate on all of these different contexts. Is that a conversation that you see coming up with some of these clients that are taking a decoupled approach to their publishing?

Jeff:

Yeah, that’s actually one of the things that I’ve spent quite a bit of time with a couple of clients on, because they do have a real legitimate need for that decoupled content repository approach, because they’re pushing out their material to so many different kinds of places and so many different kinds of endpoints that they can’t afford to just treat it as pure web content. But they still need design control; they’re not in a position where they can just treat everything as sort of an undifferentiated content slurry that gets poured into templates and layouts depending on where it’s being shown.

They need to be able to do things like, say, this is a promo for an upcoming episode of a television show and we want it to be prioritized, and we want it to use a particular color scheme because we’re using that for a promotional or marketing campaign right now. They need to be able to capture a lot of editorial intent and design decisions that are being made, but they need to have those decisions and those editorial choices ripple out in lots of different ways, depending on where it’s being displayed. The idea that it should be using our fall color scheme as opposed to I’m making the background for this orange. Those are decisions that they really have to be planned for, because you can’t just ad-lib those once you’ve built a system that’s repurposing content in a lot of different contexts. I think that dovetails with the idea of doing the work upfront to build a design pattern library and sort of a design architecture that can deal with a lot of different kinds of situations and scenarios as they come up.

Karen:

Gosh, it’s fun talking to you. I wish we could do this every week. But before we let you go, I would love to know if you have any advice for anybody. Do you have any advice for people working, trying to wrangle with some of these problems of responsive design and content management, or do you have advice for developers or content strategists that need help figuring these things out?

Jeff:

I feel like it’s something that I say all the time in all kinds of different contexts, but doing the hard work upfront of creating a realistic content model that reflects what content your organization actually has, what information is there, what the quality of the information is, and how you’re planning on using the content in the future… Capturing things like what different kinds of stuff do we have, what data is there for each different kind of content type we’re working with, how do they relate to each other, how do they connect to each other—doing that work upfront and making sure that all of the other groups inside of your organization, whether it’s the design team or the communications and marketing team or the technology team, that they’re at least a part of the conversations around that.

It’s an upfront investment, but it makes a huge difference. Because from a design perspective, that content model is basically the menu of tools that you have to work with in terms of populating any kinds of—actually filling a design with real content and having a better grasp of not just the broad strokes idea of we have articles and reviews and bios, but what kinds of information we really have for each one of those. The idea that a bio is a headshot, links, social media links, interests, areas of expertise, depending on what you consider a bio to be… Knowing what those different things are and how they relate to each other really gives the design team more to work with as they’re actually working on the design; it gives the technology team better tools to go forward on implementation. It makes a huge difference.

So, that upfront work of actually understanding the details of the content and not just the broad strokes… You can’t overstate the importance of that.

Ethan:

Well Jeff, that was beautifully said. And I have to say that, as somebody who was looking forward to this podcast chat all day, it did not disappoint. So, thank you so much for coming on the show and spending a few minutes with Karen and me.

Jeff:

Thanks a lot. It’s been great to be here.

Karen:

Thanks to everyone for listening to this episode of a responsive web design podcast. Thanks also to our sponsor, FreshBooks. Go to FreshBooks.com/RWD and enter RESPONSIVE WEB DESIGN in the “How Did You Hear About Us?” section for a 30 day free trial.

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

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

Thanks for listening, and we’ll be back next week.