Cognition Roundtable

• What are convincing arguments for going responsive? What are the risks?
• At what point should you decide whether to build a responsive or adaptive site?
• Have responsive news sites changed the way we consume their content?
• What are some of the design and development challenges for turning a fixed-width sites with legacy code into a responsive solution?
• Can you just “responsify” any site?

Have you been challenged choosing the right route for your client’s project? Take a listen, and let us know what you think in the comments.

Cognition Roundtable 003 — Full Transcript:

Michael Johnson (MJ): Hello, welcome to another Cognition Roundtable. My name is Michael Johnson. I’m the design director here at Happy Cog. I’m joined by senior designer Yesenia Perez-Cruz, and developers Anthony Colangelo and Sam Hernandez.

Today we are going to tackle the topic of does every site need to be responsive. There’s been a lot of discussion about this for the last year years. We kind of want to tackle it in a 2014 context, and with some of the issues that we’ve been dealing with recently here. Anthony, would you mind giving us a refresher on the differences between responsive, adaptive, and mobile optimized?

Anthony Colangeo (AC): Sure, they’re kind of two different sides of the same coin. Adaptive was the one that kind of came first, and it is a way to kind of tailor your site towards whatever device is viewing your site. But it’s all done from the server side. The server detects what devices are making the requests, and sends down assets, or HTML, or CSS specific to that device.

Responsive is kind of the other way where it’s tackling from a client side, so the client requests the assets and CSS and all of that the same for whatever device it is, and then the device actually figures out what it should do. It uses media queries and things like that to determine what the layout should be on its own view port and all that. But really, the only main difference is whether it’s handled by the server side or the client side.

Adaptive is the server side one, where it sends down what it needs. Responsive is the one where everything gets downloaded to the client and the client figures it out from there.

MJ: When do you feel we would make a decision to go in either direction? Is it something that would happen in a project-definition phase, maybe even sales phase later on down the line, after some research has been done? I wouldn’t mind going around the table and hearing your thoughts on this.

Yesenia Perez-Cruz (YPC): I think the conversation needs to start at the sales phase in most cases, because we really need to understand what type of capabilities the client has on their side to be able to maintain the site. And also, what makes the most sense for the content of their site, and also what kind of work the user is going to be doing on the site.

MJ: As far as utility versus narrative content or anything like that?

YPC: Right, and that would help determine how that information would be best served to the user.

Sam Hernandez (SH): I agree, I think it depends on the type of content, the kind of pate you’re looking at. If it’s a publishing or marketing site, then responsive makes a lot of sense. If you are knee-deep into a web application, whatever that means in your particular situation, the rules change a bit, and it’s really an open question.

AC: I think it’s kind of my similar thoughts, where it’s all a use-case thing. There’s obviously use cases for either, but that really depends on what you’re trying to achieve. There’s people that target every device under the sun and that’s normally where you go for responsive. And there’s people that know specifically what they’re targeting. Sometimes if you’re working with a client who is building something for an internal audience, and they know the devices it’s going to be used on, they can tailor things more effectively towards that.

That’s always my line, anyway, that if you have a lot of control over what you’re going to be viewing on, you might go adaptive because you know exactly what you’re targeting. The other side of that is you don’t really know what you’re targeting, so you go responsive, because like the name applies, you can respond to whatever is requesting your stuff.

MJ: With adaptive, there were a lot of articles a while ago, years ago, when responsive was first becoming a thing. There was adaptive versus responsive and adaptive always kind of came off to me — I don’t know if you guys agree, but kind of like a bad word. Responsive was always considered the superior option. Have you guys had any uses in this more modern era for an adaptive approach?

YPC: Yeah, we worked on a new site recently that’s due to launch in the summer. For this site, performance and really getting people to the news faster was top priority. And that was a discussion that I had really early on when the development phase of the project started. When it was designed, there were some navigation elements and modules that were designed specifically to accommodate the user screen size.

For instance, the ability to take a picture and submit it right from your phone was something that is really important, just on the smallest mobile phone level of navigation, but isn’t something you can do from the desktop. So there were some situations where the navigation was manipulated in ways to respond right to the device.

If we wanted to make all of those changes to the navigation and be fully responsive, that would be a lot of JavaScript to be able to manipulate the page on the fly, to make some of these bigger changes. So the site ended up being fully responsive so that the content is served and it works across any screen size, any device. Then we layered adaptive elements on top of that, so that if you are loading it up on a small screen size, then you get that really specific navigation.

AC: That was a really cool mix of things. It was both adaptive and responsive, so like she was saying, you would get a different navigation structure depending on what you loaded it on, but then responsive kind of took over from there. It would make whatever you got, whether you got that smaller screen layout with the smaller screen navigation, there was responsive that would make that work and usable at least at larger sizes, and vice versa.
So if you got the large desktop sized navigation, as you shrunk the browser, that would change around to be useful on a small screen. So it was a really nice mix of tailoring it upfront but then still using responsive attributes of it to make it work, no matter where you’re going from there.

YPC: I think we’ve talked about some of the reasons why adaptive gets a bad name is because of those awkward in-between phases where the layout kind of looks a little odd if it hasn’t met the breakpoint yet. I think this mixture where it was fully responsive, you don’t get those awkward breakpoints, but you are layering more specific adaptive code on top of it, made it a good balance for what this new site needed.

AC: I think the pitfalls of adaptive are easier to pick out than responsive was when it came around originally. Now we know a few of the shortcomings of it that we’re working to fix, but when responsive was really getting its legs, it was a lot easier to point out places that adaptive didn’t quite work or fell apart or anything like that. Responsive didn’t have any of those visible yet, because we just hadn’t had enough experience with it to find those things that were wrong with it. But they fixed the low-hanging fruit problems of adaptive. I guess, at that time, it seemed to us like responsive is the obvious, easy choice to make.

MJ: It seemed like for a while it was always one or the other. It’s definitely not the case. Everything is — I think you said, Anthony, a crossover. We did the same thing with a hospital website that Yesenia was talking about. We had obvious and legitimate use cases on a mobile device that were very, very different from a desktop experience, and that was backed up by numbers and research.

We needed to deliver potentially location information and emergency information at a small-screen view, and do it quickly. If we had to use responsive approach strictly for that site, we would have had to kind of re-architect and redesign how we did that homepage to elevate that information.

I think there’s definitely an issue where people feel like because of the idea of mobile first, and there’s only ever one kind of context now, just the web context, and it’s definitely not the case. It’s interesting that Yesenia brought up the news example because how news sites have approached responsive has actually changed how I digest news now. There’s certainly many sites I cannot tolerate now, and I can’t look at it. I can’t wait for them to load. Some actually crash Safari on IOS.

When we were looking at some of the challenges for that hospital website, specifically, one of them was basically rebuilding many of the templates so we could responsify essentially the site. Anthony or Sam, have you guys had any experience with going from what’s a fixed system and looking at legacy code, and basically trying to responsify it?

AC: I honestly haven’t had much of that yet, just because I’m younger, and haven’t been doing this as long. Most of the responsive stuff has been responsive from the start, and I haven’t had to go back and do that yet. Not to say I don’t see places where that would be useful or easy or hard to do. But it’s really weird because that kind of all depends on the background of the site. There’s no one answer for how to responsify a legacy site, because they all have different backgrounds. Especially when we’re coming from the era when things were kind of in flux already. There were a lot of different ways that sites were built then, so I’m not sure how exactly that would be best to do.

SH: I haven’t had a change yet, either. My background is more of a backend developer. Since coming to Happy Cog, I’m starting to get more into the front end. I love this discussion because it’s still kind of new to me. I haven’t had a chance to responsify anything yet, but one of the use cases, to back up a bit; one of the use cases for adaptive, for a client we just rolled out an application like a map-heavy application for real estate, much like Trulia and Zillow do.

While I was looking at Trulia and Zillo kind of as a standard, I saw that they do adaptive, and it makes a lot of sense. Especially because I did build a responsive backbone application. It was pretty difficult to pull off and the way they’re implementing it now, they’re actually layering on some adaptive things. Turns out, an application like that, once you have enough JavaScript rolling, you have upwards of 15MB of memory being used. That’s right around where mobile Safari packs up its marbles and goes home.

It just doesn’t want to play anymore. So you do have to do some sort of sniffing. I see that Trulia and Zillo do detect it and change how much information is coming down the network based on what device you’re using. I think I completely changed the subject, didn’t I? Sorry.

MJ: That’s okay, it happens. That’s why it’s a roundtable.

SH: Exactly.

MJ: There’s nobody at the head.

AC: I don’t know. You’re bringing up a really good aspect, which is kind of like how do we use context within — we know we have adaptive and responsive, but how do we layer in context. Can we build a base that is responsive and use adaptive-type principles to layer in context on top of that? Like your example, you could build a responsive site that encapsulates all that but then use whatever you can, which is another story of what you can and can’t use, to layer this in. But use whatever you can to build some sense of context, and what would be useful for the person. Kind of adapt things from there.

MJ: We’re fundamentally talking about progressive enhancement, right?

SH: Yes, for sure.

MJ: One of the criticisms I remember reading, and I’m still not sure that we’ve moved away from it, was from Jacob Nielson. I wouldn’t call it a scathing criticism of responsive design over mobile-specific sites, but I wouldn’t describe it as kind either. I actually agree with a lot of what he said. But he did say that in responsive sites, they were still somewhat primitive, and what he was seeing was just things being moved around a little bit, and not necessarily as responsive as they could be, especially for devices. Is that something you guys feel we’re still struggling with, design and development?

YPC: I think that is you approach responsive design by designing a desktop experience first, and then you try to shrink that down and kind of make it fit in a 350 pixels, then you might run into some issues where you’re not really considering the device or specific use case. Then I can see where he said you’re just moving stuff around because you’re just trying to make something big — small.

MJ: He was critical of editorial workflows as well and how basically taking a full chunk of copy and just moving that to a smaller device, and not changing the amounts of copy. But that impacts cost, and I think that in talking about cost and what comes down to time and development, Anthony, I understand you’re still new in the industry and young, you said; do you feel like in your short amount of time that you’ve made gains in efficiency as so far as implementing responsive?

AC: I think so, for sure. There’s obviously things you can clean up when you’re going responsive because you don’t have to handle that amount of templates or front-end code, as far as HTML goes. But it does bring about different things that are going to take time, that we weren’t doing before, which is not just managing all that CSS within one repo rather than having different things built out for your different views. But JavaScript as well, that was kind of one of the things that annoyed me early on with responsive design, was we were all talking about layout and all that kind of stuff, but we forgot the was the other side, which was responsive behavior.

We could change layout and all that, but what about interactions? We weren’t thinking about that early on. That was something I was kind of trying to find a way to do. There’s a couple JavaScript libraries out there now that are built for handling interactions at different sizes, because the layout and all that is the easy part. That is a lot more efficient, now that we’re doing just one layout or just one source order, then relaying it out with CSS. But now we’re handling not just layout across sizes, we’re handling interactions.

We talk about navigation a lot, how navigation is so hard to do responsively, just because there are so many different patterns. Certain things make sense, and certain things don’t. But a lot of that is interaction. I still feel like we haven’t nailed that yet, and that’s still the biggest pain point for me, is how do we handle interaction across sizes. Do we duplicate JavaScript? Do we break it down to a point where we can get reusable things that we can use across sizes? But then we’re going to be duplicating things at some point, whether it’s just event handlers, or anything like that. There’s all that different code that we write in like four places right now, to handle that responsive behavior.

MJ: What’s the impact on performance?

AC: It’s good and bad in that a lot of that is JavaScript stuff you can load asynchronously so that it doesn’t affect first-page load. So as far as performance, responsive had helped a lot because it is just that HTML, hopefully one CSS file that downloads. Then we can do everything else we need to, to progressively enhance the experience from there. At the end of the day, those JavaScript interactions aren’t necessary to get to your content, which is the most important part.

And that’s why we all love progressive enhancements, so we can use those same kind of principles to layer on that interaction. We can even do with that feature detection, so we know if something is a touchscreen, or something is not a touchscreen. We can change the interactions based on that detection we’re doing, since we’re already in the JavaScript realm. We have a lot more control on what we’re doing there because it is a JavaScript experience already that we can really fine-tune performance, as far as that goes.

MJ: Yesenia, from a design perspective, and efficiency perspective with responsive versus any other approach, how much do you feel your work has changed in the last two years?

YPCIt’s changed pretty significantly. I think because now we work in a way that we’re actually think about a system holistically instead of — before I would create 12 static one-size Photoshop documents and that was sufficient for a while, before we needed to think about smaller sizes.

Something like Anthony was saying, about how we still need work with behavior, something I run into a lot is like a tab set, and creating a tab set that works on desktop, and I still haven’t found an appropriate solution when that is on a smaller screen. Accordions and all those different things. So I agree there’s still work that needs to be done to figure out what really is the best solution for a lot of the patterns that we’re really used to are, and how they work. So that’s something I think we still need to work at.

MJ: Do you think it’s because we get stuck on certain metaphors or paradigms?

YPC: Yeah, I think that because we’ve been used to seeing certain patterns for a long time we’re kind of “Yeah, that’ll work,” when we think that it will make sense on different devices. I think we’re still trying to figure out things like tab sets.

I recently was working on a navigation and I’m like “I know why they use the hamburger menu,” because they probably just said fuck it, let’s just put it in this menu. I think that’s another situation where we probably stick to something that’s known instead of really questioning what these patterns are.

AC: Lately there’s been a lot of studies on how useful the hamburger icons are and all that, and not only the hamburger icon itself but the navigation pattern in general, and whether that’s good or bad I don’t know.

MJ: I hesitate to say it would work itself out. We obviously have to do the work to get it there, but it was fine for a time and now it’s to a point where it was just being implemented thoughtlessly. I don’t know what to do with this navigation. I’ll just put in this thing.

YPCThis is hard. Let me just ignore it.

MJ: Yeah. Then when you have to invent something, that’s a whole other can of worms. Sam, from a backend perspective and your work over the last couple of years, how have you seen it change as responsive gets older?
Sam: From a backend perspective, backend is really about content entry and displaying content. I don’t think that’s really changed much. If anything, it’s made it a little easier. You’re kind of spitting out the same HTML anyway, if it’s purely responsive and not adaptive on the server side.

MJ: Right.

AC: You’re not duplicating fields or anything or content across anything. Now we’re actually using one CMS and one interface to manage everything. The place where you put the blog post is the place where the blog post is. There’s not three places.

SH: That’s a huge benefit to the client. I guess fundamentally the question is should every site be responsive. It comes down to the money. Where we’re talking about efficiencies here, it all comes down to money. How much is this going to cost? Is it worth it to do it? I think it is.

YPC:Speaking to the news site I was mentioning earlier, previously they had a desktop-specific site, a mobile-specific site. And because it was the same teams that needed to push updates up, there was a seven-minute lag behind when the news were posted to the desktop site and when mobile users got to see that news, which is kind of a huge deal when you’re talking about news and breaking news. It could say breaking and it really happened seven minutes ago. I think in that respect, having one place to update all of the content and having that being served to people on all devices was really crucial.

MJ: Just speaking to the hospital example, in emergency situations, if you have content in multiple places and you’ve updated your address for any reason, if your hospital has moved down the street for renovations or something, what if someone forgets to change it in the other place, and push it to the mobile view? I can definitely see why it’s costly from the amount of time it would take somebody to manage all this content.

AC: It’s not just that, though. I think there’s things, like I said earlier how we didn’t uncover the problems with responsive early on and we’re just starting to now. Part of the client CMS issue we’re running into is you really need a client to understand what responsive means in terms of their content. Not necessarily their long-form blog-post content, but images. We’re now getting into the realm where responsive images are becoming a thing, and the picture element is making its way through the spec gauntlet.

That’s going to change a lot of things we do on the CMS side because we’re going to need to teach client and client teams to cut art-directed shots. Images that work at desktop size, and then the art directed one that works at a smaller thumbnail size, and all those different sizes, we’re going to need to be able to swap them out. If you have a larger client team, they have those resources to be able to cut that many images or anything like that. But with a smaller client, I don’t know they’ll have that available to them, and if that’s the way that we’re going, where we’re going to need a lot of images to really not only help performance but layout as well, that’s going to change client workflows. We’re going to need to build really a new way to use a CMS.

None of the CMS’s out there right now really support the fact that we have these different art-directed images. We’re going to need to figure something out not only from the workflow side but from the interface side as well. And be able to train the clients on what that means, why we’re doing it, and what benefits there are from performance, to layout, and all that.

SH: Responsive requires more work for everybody, no doubt. Somebody has to do the work. It’s either the content entry people or automating some things on the backend. I think it’s interesting, this whole thing about responsive design comes back to I think I heard that most people want content parity between mobile and desktop. But right now that translates into network parity as well. There’s just as much data coming down the pipe. We just do things like throw a class of visually hidden — doesn’t mean it didn’t load.

MJ: Going to something Antony mentioned, as far as clients understanding responsive, everybody here deals with clients on a regular basis. Do you feel like they understand what’s required of them in implementing not just responsive design but the responsive workflow?

YPC:I think that we need to teach them about what that means. I don’t think it’s something they would know right off the bat unless they’re really studying responsive design. I’ve mentioned a few times to Anthony that even the term responsive design is not something that makes sense to a lot of clients that aren’t in our industry or aren’t following our industry. They’re still using other terms. So I think that there’s some education that needs to be done all around.

MJ: There’s that. Basically the impetus of this is that clients ask us for responsive without I believe necessarily understanding entirely what it is.

YPC: Or if it’s the best solution for them.

MJ: Right, and I think that ultimately responsive is just becoming an umbrella term for “it looks good on my other devices.”

AC: That happens with all of our terms. For a time, HTML5 became anything that isn’t Flash. That’s how that term was used. We say oh, it’s HTML5, but that doesn’t mean it was one of those elements that came into HTML5 or anything like that. That’s just how it caught on.

I feel like there’s parts of responsive that are catching on as that and others parts that are left out of that definition. It does all come back to really talking to them and educating them on what that means, not only from how it’s used, but from what we do and what they do.

MJ: It’s interesting, it’s almost become kind of a brand name in a way, like Kleenex or Coke — responsify.

SH: In want a Coke. What kind? Dr. Pepper.

MJ: If we could, to close this out because we’re getting close to time, the future of mobile responsive, whatever it is we’re going to end up calling this. We’ll go around the room, and give some last thoughts on that. Sam, where do you feel we’re headed with responsive and this debate over whether a site should always be responsive or not?

SH: I would like to see, like we were talking about brand names, it has this brand name of responsive. I’d like to see that put to rest and see the value — presenting the value to the client of having your content accessible on all the different devices, no matter what that is, if it’s an adaptive approach or responsive approach. I don’t know what the future has, but I think the future has more of this. It’s really worth doing.

A side note, I got to go to the artifact conference and hear the Capital One team talk about their project. They had a hard time selling responsive up the chain so they attached it to a greater accessibility initiative they were working on. They said if we make the website more accessible we’re going to make it responsive too. What they way was a mobile traffic increase of 4% was their original — up to 40%. It had huge financial gains for the company. Everybody sat up and looked at it finally.

What they call RWD is really worth doing. So I don’t know what the future holds. I’m excited to see what happens with the problems of assets, especially images and things like that, like Anthony was talking about. Love to see standards around that.

MJ: I’d love to see that resolved myself.

YPC:I would like to, and I think we are moving away from trying to just overly box in what these labels are and stick to one or the other, and have more flexibility, and really just focus on finding the best solution to problems. Coming up with solutions that work the best for users, and for helping our clients out. Stop trying to label and define exactly what the parameters of responsive design are.

AC: I’m kind of on the other side. I do think that every site should be responsive because I think that responsive is the nature of the web. I think we’ve seen over the last four or five years how diverse everything is getting in terms of devices, and that’s only going to continue. I think responsive is the natural state of the web, that we’re really finding out how to build from our own side. But I also think responsive is not done yet. I think we just saw pictures start become a spec, and things like that. Now we’re going to be talking about things like element queries, which are different than media queries, because it’s focused on the context of an element, instead of the view port.

There’s all these things we know that are wrong with responsive, but we’re actively working to fix them, instead of creating a new thing. Instead of creating a new thing every time, what if we just made the thing we have now better? I think there’s a lot of work that’s still going to be happening on responsive. We’re never going to be able to say responsive design is done, and now we can decide whether it is the best thing or worst thing for anyone. It’s not going to be done. It’s going to continue to evolve and we’re going to keep adding on things like images and element queries.
And things we haven’t even thought of in the future. Hopefully, like I was talking about responsive behavior, hopefully that’s something that will be native in JavaScript. That’s a whole other problem of its own, but we’ll get there one day. I think that what we have to do as a community, both designers and developers is just focus on evolving it to fit what we need because that’s the best part. We build the stuff that we use, so let’s just make that stuff better, and let’s make it more useful to us, and something we can actually build our dream project with.

MJ: We’ll evolve until we have another problem that we have to have a Cognition Roundtable about. That’s it. Thank you for listening. Feel free to leave your comments, agree or disagree, in the fields below.

Alison Harshbarger: This has been Happy Cog’s Cognition Roundtable. Thanks for listening. Be sure to follow us each week here on Cognition and on Twitter, @happycog.

Back to Top