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 is a very special Big Round Number Plus One episode. I wish that we had gotten our act together to do a hundredth episode, Ethan, but we didn’t. When we say “we,” I mean me.

Ethan:

[laughs] Well, you know, calendars and airplanes I think were conspiring to make fools of us all. But yeah, one hundred episodes, man. That’s… Geez…

Karen:

How did this happen?!

Ethan:

Uh, I really don’t know. I’m honestly still surprised that I’m a podcaster, as the kids say. It’s weird.

Karen:

I sometimes have to tell people that I have a podcast, and then people get that weird look on their face where they’re like, “Oh shoot, do I have to listen to your podcast?” And my advice to all of our listeners is, no, you don’t have to listen to our podcast unless you want to. Me personally, I really enjoy doing them, and if they provide value to other people, then that’s wonderful, and if not, don’t listen. Read the transcript. Or don’t at all! I don’t care.

Ethan:

[laughs] Yeah, no, totally. Honestly, I rarely listen to them in their entirety other than producing the episodes. I really love the fact that we can go back and just sort of re-read these transcripts; you’ve obviously got the newsletter, which sort of plucks out some key stuff from every episode. Yeah, this has been a lot of fun to work on, so thanks for making it happen, Karen.

Karen:

You know who’s probably sending me a frantic email right now saying, “No, don’t tell people not to listen!” is our wonderful sponsor, GatherContent, who I will say on their behalf, yes, you should listen repeatedly to this podcast. GatherContent has been a fantastic sponsor for us for several quarters now, and continuing into next year. I think they are spectacular as a product, I think they are quite useful for teams that are embarking on, say, a large-scale responsive redesign, and I would like to give my thanks to the whole team over there for being so great to work with and for helping make this show possible. So if you do get value from our program, please, go check out our sponsor, go to GatherContent.com and perhaps try out their product, maybe use it for your next web project, make your content and the world a little bit better of a place at GatherContent.com. Sounds good, right?

Ethan:

Yeah, couldn’t have said it better myself. They’ve been an amazing sponsor, and yeah, it’s been good to have them so involved. So thanks, folks.

Karen:

Well, what should we talk about?

Ethan:

Oh, man. Yeah, for thirty minutes? I don’t know… Um… Ya like GIFs? I could talk about favorite GIFs… No. Well, you and I have been doing a fair bit of work lately together. You know, had a couple workshops, been talking to some interesting clients.

Karen:

We’ve got a lot going on.

Ethan:

We’ve had things going on, and there must be things we could talk about that have been pulled from some of those discussions.

Karen:

I feel like I learn a lot from all of the clients that we go talk to, all the workshops that we do. I’m always kind of intrigued by the questions that come up that I don’t know how to answer. I will freely admit, I am not an oracle who grasps every aspect of the web design and development process intimately. I thought maybe after a hundred episodes we could talk about things we don’t know, or talk about the things where we don’t know what we’re talking about.

Ethan:

[laughs] Not knowing things is basically my brand, so I’m very excited for the next twenty minutes. I think the big thread that has been coming up lately, at least in the conversations I’ve been part of, is testing. When I say testing, I don’t mean just device testing or browser-based QA. A/B testing has actually been a big conversation lately, and that’s something that’s a little bit outside my bailiwick, if I can use the word. Do you have any opinions of A/B testing, Karen? That’s something you’ve spoken pretty eloquently about in a couple of workshops. What’s your take?

Karen:

You know, I think there’s a class of company out there that has really bought into A/B testing as a methodology for everything, and I think they are so focused on being able to evaluate what are small incremental changes, that it can be difficult to make a great leap forward to a full redesign. Like, they get kind of stymied because it’s like, “Well, what if we need to test and evaluate every single decision we make using some kind of split test? How will we pull off a responsive redesign in that environment?”

I have to say, I don’t know what to advise them necessarily, because I think that that is a relatively challenging way to think about the process. I think there are probably some limited and specific scenarios around changes to the navigation or placement of particular calls to actions, or other things that are appropriate for doing that kind of fine-grained testing. But I think to some extent, to pull off a responsive redesign you have to do a much broader look at the site as a whole, and you can’t test everything, and I think that is scary in certain environments.

Ethan:

Yeah, I think that’s beautifully said. I know that, for me at least, where A/B testing has sort of come into the conversation a little bit is around site speed and performance. A lot of companies, when they’re evaluating some of these software frameworks to load up different layouts for different slices of their audience, that question of “Is this going to actually slow down our sites?” doesn’t tend to come up. And I know there’s been some studies that have been circulating recently, taking a look at some of these packages and saying some of them are actually a little more performance-friendly than others, and some of the more popular ones can actually introduce some significant slowdowns to your sites, so how does that impact the user experience or how does that impact the research that you’re trying to do with these software packages? But yeah, it’s really challenging.

Karen:

Yeah, Schrodinger’s A/B test.

Ethan:

[laughs] Exactly.

Karen:

I have also heard from particular naysayers in the world of mobile-specific marketing that responsive design makes it more difficult to A/B test across different platforms. So if you have a campaign where you want to target specific messages or specific offers to people whether they’re on their mobile device or on their laptop, then being able to A/B test for those different audiences becomes more challenging in a responsive environment. So, that leads various people in the industry to suggest that adaptive solutions for actually serving different pages for those sorts of contexts or environments makes sense. I don’t know enough about it to say whether that’s true or not, but it seems like the complexity for many marketers in dealing with a responsive implementation and dealing with A/B testing on top of that might be too much.

Ethan:

Oh, that’s interesting.

Karen:

Maybe even just to define my terms there: I like to use a definition of adaptive that is perhaps a little bit different from one of the more commonly used definitions. So, I think very often people on the design and development side, when they say “adaptive,” what they mean is not completely fluid, flexible designs. So, designs that snap into place at particular sizes rather than being completely fluid, as in a responsive implementation. I hate that definition, I think it’s terrible. Just call it “badly implemented responsive.”

But I like the definition of adaptive that contrasts the client-side solution of responsive design with a server-side solution for delivering different content, or different designs, or entirely different pages based on some set of criteria. That criteria could be device, but it doesn’t have to be. I think that when a lot of people talk about adaptive solutions, they do mean the ability to target something specifically to the device. So, “I’m a marketer, I have a campaign, I want to show a different campaign landing page to someone on a smartphone versus someone on a desktop.” I think there’s some flaws in that approach or that reasoning, but I’ve been in enough meetings with people to understand why they have that as a goal.

Ethan:

Yeah, and for those of you who haven’t had the opportunity to hear Karen’s amazing new talk on adaptive content and context, I would totally recommend trying to track down a video because it really won me over in terms of thinking about adaptive technologies as basically just serving something different to the end-user, whether that’s device-specific information or profile-specific information based on user data you might have collected. I’ve been as guilty, Karen, of talking about adaptive design as primarily like a client-side technique as much as anybody else. Talking about, “Okay, we’re loading up different fixed-width layouts based on certain breakpoints,” and using that to kind of treat this as something other than a properly responsive, properly flexible layout. But I think it’s much more useful, frankly, to talk about adaptive content or adaptive design as basically originating from somewhere other than the browser.

Karen:

I’ve talked a lot about adaptive content over the last five or so years, and I think the most important takeaway that I would have for people is the idea that I don’t think that adaptive and responsive solutions are, in any way, in competition. I think that responsive will solve for the vast majority of your problems—like ninety-five percent of your problems are going to be solved if you just have a well-implemented responsive design. And then maybe in some very limited scenarios—you need to get the server involved, you need to serve up different content or something based on context or, heck, maybe potentially even something different based on device type. But that’s not the core of your problem, that’s just a very small subset of your problems.

Ethan:

Yeah, the thing I like about it is historically when we’ve talked about serving something different based on the device, that was always kind of our default position, right? That we had to fork our experiences or serve up different content because these screens were differently sized, and so the UX had to be dramatically different. The thing I like about your talk and this different model of thinking about adaptive is it’s a much more nuanced approach. It’s like treating things a little bit more surgically. So, establishing a broad consensus about what matters to everybody and then looking for those thoughtful areas where you can provide a little bit more information or something that’s a little bit more targeted around the edges. That seems really pretty appropriate.

Karen:

That might be a good lead-in to another topic of some nuance, which is the topic of accessibility. I think while we all share the goal of making sites that are as accessible as possible, and taking into consideration the varying needs and varying device types that people might be encountering the web with, I know we’ve gotten some pushback in some of our conversations that responsive design isn’t great for accessibility or that it doesn’t necessarily help solve for some of the broader questions around making sure that sites are accessible to screen readers or accessible to people using alternate input devices, for example. Do you have thoughts on that? Like, is responsive terrible for accessibility?

Ethan:

It’s definitely not terrible for accessibility, but it definitely can introduce new challenges. Specifically, when we’re talking about introducing changes to the layout, or the changes of different position of elements on the page at different breakpoints, that’s where things can be a little bit confusing for folks who maybe don’t access the web in the same way that you and I do.

A great example is navigation. Maybe by default on smaller screens, the navigation sits somewhere closer to the bottom of the page, but then when screens get a little bit wider, maybe it gets moved higher up to be a little bit more visibly prominent, or maybe more content gets loaded in as screens get wider. And those are things that need to be announced to the user, and those things could potentially disorient some users. So for example, if somebody is tabbing around the page and the navigation is visually at the top of the page but their keyboard doesn’t actually access the navigation until they’re very far down in the document, that’s a little bit disconcerting.

I think the challenge, at least for me, with accessibility is I’m putting forward, as a sighted designer and developer, a lot of my assumptions about what I think a good, accessible experience needs to be. But those are all just assumptions. I think the best products, from an accessibility standpoint, are very well-researched assumptions, sure, at the beginning, but this at least for me is a really great case for getting things into browsers and devices as quickly as possible and then getting them in front of actual users as quickly as possible. So, talking to not just no-vision users but low-vision users, folks with limited mobility, folks who might lean predominantly on the keyboard for accessing your website, trying to get their feedback on how the experience actually feels for them.

I worked on a fairly complex web application a few years ago that was primarily a writing environment in the browser, and it worked great from a responsive standpoint; from a layout standpoint it was completely flexible, you could open and write these documents on small screens and large. But we made a couple assumptions about how things needed to re-flow and adapt based on the size of the screen, and we got some feedback from non-sighted users that some of our assumptions didn’t necessarily line up with what their expectations of how web documents were going to be structured. So, I think it’s a negotiation. You have to get these ideas down to test them, but don’t just assume that they’re ever going to be finished and perfect.

Karen:

I think this is a theme that has really carried through probably my last fifteen years of working on the web, which is that just as an industry we need to do a better job of being concerned about accessibility. We wouldn’t tolerate this lack of concern for people with disabilities in any other context. Honestly, everyone as a designer needs to get better at understanding what these processes should be and having some basic default analysis of how to make sites more accessible. I don’t think that responsive necessarily harms that; I think you’re right, it does make it more complex, but not in an insurmountable way.

But that even more important is to make sure that we’re testing and researching what the appropriate behavior will be so that we get a sense of how the sites will perform on every type of device in every context, and that may include mobile devices but it may also include screen readers and other ways that people interact. I think there’s so much that underlies a solid approach to mobile and semantic content and device-agnostic content, that if we did that right, we would be doing the right things for accessibility… Probably even a better way to say that is to be thinking about accessibility in the right way makes it so much easier to do responsive design the right way.

Ethan:

Yeah, I couldn’t agree more. I think that this is one of those things, we’re just starting the conversation now, effectively. I mean responsive design has been around for five or six years and we’re still trying to figure out how to build intuitive, accessible experiences for it. So, hopefully it’s going to get a little bit easier.

Well, while we’re talking about other browsing contexts, how do we plan for SEO in a responsive design? I mean if we’re talking about things that I have no concept of how to actually do effectively, this has definitely been a big question that we’ve gotten from some clients and from some workshops lately. Do you have any thoughts on that?

Karen:

I think one of the biggest questions we consistently get is, if we approach the idea of a responsive design through the lens of saying let’s simplify, let’s pare down, let’s get rid of the content clutter, let’s ensure that the site is easier to read and more navigable because we’re doing less and we’re doing it more effectively—won’t that hurt our SEO? What about all these pages that we have that are driving SEO today? Are we going to lose all of that if we take these pages off the website, if we combine and reduce the content on these pages? I will freely admit I don’t know the answer to that.

Ethan:

[laughs] Same.

Karen:

I don’t know how organizations approach this. I go into it with the assumption that making any major changes to the content on your website will have an effect on your SEO. And that in the immediate term you can see your rankings go down because you’ve changed the URL structure or you’re delivering different content, but that over the immediate near-term, within a few months or so, those numbers should stabilize. I know we’ve heard from more than one organization that even that would be considered horrifically unacceptable, that any change to rankings would be grounds for immediate dismissal. And so, that puts a real damper on how they approach a responsive process, because if you’re going into it saying one of our core business metrics that we’re tracking requires us to keep all of the same content from the desktop website even as we implement a responsive design, that strikes me as a difficult challenge to meet, and frankly not a particularly user-centric challenge to meet. If the intention is to make something that’s more browsable and more navigable on a mobile device, it’s hard to see how you do that with a large, dense, complex nav. To some extent, you really do have to go in and try to pare things down.

Ethan:

Yeah, I think we heard similar things from both the BBC and Capital One, that that was effectively kind of a limiting factor, that they had to preserve the desktop experience at all costs.

Karen:

Yeah. A lot of what I read about the negatives of responsive design or the downsides of responsive design often imply that organizations are only doing a retrofit—and by that I mean preserving the desktop experience and essentially just re-coding the front-end to drop in media queries and breakpoints so that it will function on smaller form factors but isn’t necessarily designed for or optimized for smaller form factors. And in all of the things that I read that say, “Well, responsive design is not good enough,” a lot of it seems to be predicated on this idea of responsive design is just about taking your existing desktop website and squishing it down. I don’t think that was your intention or anybody’s intention. [laughs] And I’m hopeful that as more organizations move beyond doing just a retrofit and actually embark on a full redesign, a full reappraisal of their content and reappraisal of the experience, if they accept that there may be some immediate-term trade-offs, I think they’ll see longer-term benefit.

I recall the interview that we did with MIO Culture and Aaron Mentele from Electric Pulp saying that they’re not seeing organizations that don’t get conversation rate increases, like organizations get clear and definable improvements in their metrics as a result of embarking on a full responsive redesign. And while for smaller retailers that might be something where you can execute and see change relatively quickly, for large-scale enterprises that might be something that takes longer to execute and takes longer to measure and track. But my hope would be we don’t have to have this conversation about how do we make sure our SEO stays exactly the same, because we’re having a bigger conversation about how do we ensure that all of our customer-facing metrics improve.

Ethan:

Well, I’m on board. [laughs]

Karen:

[laughs] Let me ask a couple questions about the intersection between a responsive design process and implementing a pattern library or a design system. So, maybe you could even just talk a little bit about how those two things intersect. I’m always intrigued by how quickly the conversations around pattern libraries or style guides get into a conversation about the software that you use to manage and maintain it. How did that problem get mixed up with responsive design?

Ethan:

Yeah, that’s a fantastic question. I’m still working on it, frankly. So for those of you in the audience who might be just getting your hands around designing modular systems, this is something Karen and I have been talking a little bit about lately, both on the podcast we talked about modular design a few episodes back for one of our very special episodes. But as web interfaces and UIs have gotten more complicated, thinking about pattern-driven design practices has been a big time-saver, frankly. Thinking about not designing thousands and thousands of pages but looking for reusable components across all those pages that they share that are effectively responsive themselves, and then understanding how those reusable little bits of responsive design lock together to build these pages we’re so accustomed to looking at.

So as organizations have gotten more comfortable with those things, that’s where we’ve seen the real rise of the style guide or the pattern library, which are basically just web-accessible documents that allow anybody to browse those little pieces of design in isolation from each other. Starbucks was one of the earliest and most visible examples of this for a responsive layout, and we had the great fortune to talk with them very early on in the podcast.

But as other organizations have gone responsive, I think this idea of the pattern library has become kind of the de facto deliverable that comes out of that responsive redesign process. So, effectively as a responsive redesign changes and adapts over time, you’ve got this evergreen document, this pattern library that sort of shows you all of the individual components that go into building that responsive layout. It’s that idea of keeping that pattern library evergreen that’s sort of given rise to this whole host of tools and applications and instrumentation to automate the production and maintenance of pattern libraries. They’re almost like little miniature CMSes for visual snippets of design. So you could quickly browse through this repository of patterns to see all the navigation styles that go into your responsive layout, all the typography, different grids…

And so, yeah, we’re kind of living in this golden age of different applications and software packages to allow you to create these things fairly quickly. One of my favorites is this new one from Clearleft called Fractal, which is really kind of taking a look at how do you create these patterns but also integrate them into other products. So you could basically have this little CMS that then publishes the patterns out to your website or other applications that might just need certain parts of the pattern library.

I think that’s where a lot of folks that we’ve been speaking with lately kind of get stuck, is because there’s so many options out there, how do you actually vet and evaluate all of these different ones? Generally speaking, I try to talk to organizations about where things go after they’ve actually created the pattern library. Is this something that they are planning to keep evergreen, or do other applications and tools need to actually integrate with it? So if that’s the case, does the pattern library generator actually have some sort of API so that other systems can effectively talk to it and request certain patterns? I think it’s basically, again, talking to these organizations about, “Okay, where do these patterns go after you’ve actually created the library?” and sort of working backwards from there.

Karen:

I think this whole conversation is so fascinating because I think it implies that this idea of having a responsive system and this modular, more component-based approach is also changing the way that the back-end works or the way that teams interact with systems on the back-end. I’ve talked a lot over the years about how content management workflows and processes need to change and also become more modularized, and I’m really fascinated by how these conversations are starting to intersect. Like, how does the pattern library talk to the CMS? Where do these things live? Are they in different systems, are they in the same system? How does a structured content approach to creating and managing your underlying content separate from pages—how does that intersect with the page creation task or the design task of choosing these components and figuring out how things will lay out? And I don’t know the answer to any of this either, but I think it’s a fascinating look at how different teams work together, and what do they call things, and how does your piece of the puzzle fit into my piece of the puzzle?

Ethan:

Right, right. Yeah, you and I had an interesting conversation recently where you actually suggested a proper CMS could actually be the home for the pattern library, which is something I never really considered before.

Karen:

Yeah. I have worked with a couple of clients recently that had that conversation. As with everything, there’s pros and cons on both sides, and certainly a design pattern library manager with an API can just as easily talk to the CMS. But for teams that are thinking about developing a decoupled component-based content management system, the idea that you might be able to manage structured content on the back-end and then have a system that would allow you to do what I like to call the “page creation tasks” directly in the CMS, there’s some benefit to that, it’s an interesting solution. But there’s also lots of other interesting solutions where you keep all of those systems separate and just manage them through APIs.

Ethan:

Yeah, I mean the CMS thing definitely blew my mind mildly, so I’m looking forward to seeing some more examples of that.

Karen:

Or maybe we will just look forward to more hand-coded webpages.

Ethan:

But of course software is only half the problem, right? The tricky bit is actually inventorying these patterns and making them accessible to not just an individual designer/developer, but potentially an entire organization.

Karen:

I thought you were gonna say that software was only twenty percent of the problem and people were the other eighty percent.

Ethan:

[laughs] Well, yeah, that is also an option.

Karen:

But I think that you’re right, that the challenge of how you get people across the organization to name and talk about what these patterns are… I think from my perspective that’s one of the biggest debates, biggest challenges that you run into across projects, is how do you ensure that the way that these patterns are described is meaningful enough to people across the organization so that this design system is something that has a life beyond just the design and development team that created it.

Ethan:

Yeah, I was talking to one client recently and it was actually kind of interesting because a lot of different people in the room had sort of assembled their own little vocabulary for categorizing these patterns. So rather than talking about navigation, typography, or form elements, some of them were using things borrowed from atomic design, talking about certain things as molecules or organisms, and actually some people were using those two terms differently; some people were using blocks and modules… And so, actually getting folks in the room to come up with some sort of sensible organization for these things was actually kind of interesting.

Karen:

What would you say the challenges were?

Ethan:

Well, one of the challenges I think was actually putting aside that temptation to come up with the buckets to put the modules in before we actually knew what the modules were themselves. So, rather than focusing on how do we organize these things, really just taking a very low-level look at all the different patterns and modules that we had to support in the design system and then trying to sort them after that fact, and that was actually much more productive. So, putting aside, “Okay, well what are the molecules and the organisms, or the blocks and the modules?” and like “Okay, well we have three different mastheads that we need to support, we have eleven different headline styles.” And then basically working through a number of representative pages and then talking about, “Now that we’ve done this survey, what’s some organization that’s going to be accessible to us but also folks outside of this room that haven’t been taking part in this exercise?”

Karen:

Well, I think that makes a lot of sense.

Ethan:

Well, excellent. [laughs]

Karen:

In conclusion, would you say, many of the articles that I read on various websites or sent to me via email, that responsive design is over and it was so 2013?

Ethan:

Yes—well, I would say that if they’re not right, I hope they are soon so I can get a completely different job. [laughs] But yeah, no, there’s still plenty of exciting work out there and I’m really excited about the next hundred episodes or so, because this podcast has frankly been teaching me a lot about how people do this work.

Karen:

I am looking forward to our 200th episode, when I know the answer to all of these questions and more.

Ethan:

Man, I can’t wait.

Karen:

Well, thanks to everybody for listening to this episode of a Responsive Web Design Podcast.

Ethan:

Yeah, thanks so much to everyone for listening; thanks to GatherContent; and Karen, thanks for being a great podcast co-host.

Karen:

This was the best thing. It’s so great to do this with you! Thank you!