Transcript: The “When” of Responsive Design

by Tim Wright

This is a transcript for The Dirt episode, “The When of Responsive Design

Tim: I’d like to see us in Claymation. I’m picturing us in Claymation
right now. I can make that happen. Hello and welcome to “The
Dirt.” I’m your host, Tim Wright. And today, I’m here with Mark
Grambau.

Mark: Hey, Tim.

Tim: Hey, Mark. Today, we’re going to address a question that we get a lot
of with potential clients and current clients. And actually,
somebody here asked us to specifically address this thing about
Responsive Design. We get a lot of clients that are coming to us
and specifically saying “I would like a responsive website, I
would like a responsive application.” And this kind of reminds
me of a few years ago when everybody was like “I want mobile, I
want mobile.” And years before that saying “I want flash, I want
flash.” And it’s obviously a different monster because I very
much like Responsive Design. That’s where I am right now.

Mark: Right. But it’s the word being told. “If you’re going to one thing,
you got to be mobile.” I don’t know why I have this crazy voice.
I just want to say “Okay, well, I just want to do this one
thing. I got to do it right.”

Tim: Yeah. It’s not always the answer and that’s what we want to discuss.
We, as pre-built SOW’s sometimes scopes of work; and RFP’s,
which we don’t really deal with that much. But they say that
things like, “These are the things that my website needs.” And
then, we start talking to people and they’re like “Oh, no, I’ve
never spoken to one of my users.” So, one of our goals in the
process is to try and make clients understand that Responsive is
not always the answer. And when it’s not the answer, it’s okay.
I give a talk at Intelligently [SP], I want to say two weeks
ago, now, and I came up with these eight rules of Responsive
Design. And rule number eight is “Know when not to use it.” And
it’s the same thing that I tell people about JavaScript. You
know, it’s really cool and you can do a lot of great things with
it. But if you misuse it, it’s going to cause you a lot of
problems. And the same thing with Responsive Design, there are
great benefits with single-code base, awesome. But if there’s
usability in-house with your developers and there’s usability
outside and you have to separate the demands of your users, what
they actually need and what they want are two very different
things.

Mark: Yeah. And I think it comes down as becoming stripping away any
preconceptions when you come in about, what you want to do when
you come into a project. Especially when you’re going to work
with, our goals are often, we’re trying to solve a problem,
whatever that may be, and the answer if you’re trying to get to
the solution. It’s best if it’s a business goal, a user
experience goal. It’s “We want to make more money, we’re not
converting enough people, we want to make sure our experience is
better,” whatever it may be. Instead of “We’re not using enough
JavaScript.”

Tim: That’s awful.

Mark: Yeah. So, the tool, like anything, it’s about choosing the best tool
for the job. Focus on the job you want to do and we’ll say “All
right, well, let’s think about the tools we’ve got in our tool
belt to make that happen.”

Tim: Yeah. And the cases to go mobile are very different than the case to
go responsive. If you want to target people on phones, that is
not a reason to go mobile or responsive at all. That has nothing
to do with anything, really, because we’re going to be targeting
those people because that’s how we build things. If your mobile
users genuinely need a new experience when they’re on their
phone, they legitimately act differently. Then, maybe, you do
need to craft a mobile experience.

Mark: So, when would someone on their phone act differently from a, let’s
say desktop, or even iPad/tablet type experience, and when would
they act similarly?

Tim: There’s, let’s see. Say we’re building a site for Farmers Insurance;
we’re not, but let’s say we are. And their website, you can file
claims and everything. Maybe if you’re on your phone, you want
to be able to take a picture of the accident and upload it. If
you’re on a desktop, you’re not going to be doing that. So,
that’s a separate mobile behavior.

Mark: Now, we may have people using that app at home, as well, after the
fact to check in on their claim and whatnot.

Tim: They’re still on their phone, though.

Mark: There’s a risk of presuming that mobile or phone means on the go.

Tim: Yeah, that’s another thing we want to dispel. Mobile people are not
face down on their phones walking through Manhattan. It’s just
not true. There was a study and we can look up the studies.

Mark: There’s a common sense article that says that people use their phones
in the bathroom. And on their couch while watching TV.

Tim: Honestly, when my iPad is out of my reach and I’m on my couch, I use
my phone. Or if I’m watching something on my iPad and I’m
sitting on the couch, I will use my phone to look something up.
Or if you’re in the bathroom, you’re probably on your phone. You
might be listening to this podcast on your phone in the
bathroom.

Mark: So, it’s important to think about the context of your site and not
purely assuming that mobile means “on the go.” That said, I
bring it back to something you’ve often talked about, Tim. Your
term of environmental design of using various hardware in
environmental to give different kinds of experiences. And in the
light of the announcement of the new iPhone 5s which has a
dedicated processor–

Tim: You’ve got to circle it back to Apple every episode.

Mark: This is specific, I know. But this is specific in that they’ve got a
dedicated processor on this. Aside from the accelerometer and
gyroscope and everything that’s already in all these devices.
They have a dedicated processor for looking at motion, so that
it doesn’t tax the main processor. It’s lower battery
consumption, but the phone is constantly aware of “Are you
walking, are you sitting, are you running, are you in
transportation”? And it can hand that off to apps in the
background.

Tim: Dude, that’s great.

Mark: So, yeah. And right now, I have an app that does that right now
called “Moves.” And it works as a pedometer and it knows when
I’m walking and running. But what it does is it occasionally
have to kick up location serves. It’s occasionally kicking up
GPS.

Tim: That’s a lot of battery.

Mark: And it works all right, but it’s not a massive battery drain because
there are clever ways of doing it. But they had to do certain
runarounds to get it to work. I bring it up with Apple just
because they’re the ones doing it now. But let’s say in a year
or two years, that’s a standard across the board on all phones.
They have a dedicated processor for recognizing and delivering
information apps about your motion. That we may, in the future,
be able to very easily access to say “Hey, this phone is being
used in a very sedentary way at their home address,” that we can
assume they’re home. This is being used as a sedentary way, but
they’re in the park. The person is walking on a sidewalk. And
you can deliver custom experiences based on those.

Tim: Yeah. And I think when we’re deciding the development path of a
project, we will obviously look at user needs. But we’re looking
at user needs by features. The most basic features are screen
size and touch capabilities. Which can combine to indirectly
target a phone. But there’s also other factors. Lighting or
moving or sitting down.

Mark: Signal strength.

Tim: Yep. Bandwidth, available bandwidth. There’s a lot of stuff. We focus
on the features instead of the device itself, because the device
itself changes way too often. But that being said, Responsive
Design is not always the answer. We do make it the answer a lot,
because, often, honestly, it is the answer most of the time. But
it’s not always the answer. And when people come to us and say
“I want a responsive site” without ever really knowing if they
need a responsive site, that’s where we have to go back and
forth with them. Dig into the discovery process. Which it makes
it really difficult to actually build a proper SOW. But we do
deep dives now to try and get into the clients’ needs.

Mark: Really understand their users’ needs.

Tim: Really understand them so, we can make that recommendation of “You
know what? You can do this in a responsive way.” Or “You know
what? You need a mobile experience.” Or even, what we’re doing
now with the client and I don’t want to say the name. But
they’re going a fully-responsive application. And they also have
a native app that basically pulls features out that you might
want to use in a mobile context. There’s a to-do list and
there’s a whole [inaudible 08:56] of features. But, basically,
they have a full-featured app and they pull some of the stuff
out. And they’re installing it into a native app. But we’re also
using an embedded browser like Twitter. When you open a link on
Twitter to get to the rest of the application, because it’s
responsive. It just fits right in there. And we wouldn’t have
got this approach if someone just came to us and said “We need a
responsive application.” They did, that actually happened. They
came to us and said “We need a responsive app.” And we’re like
“Hold on a second. Let’s actually figure out if that’s what you
need.” And for the most part, we went with a RESS model. We
went hybrid/mobile responsive, which turned out best for them.
And then, we also folded in the native side, because that’s what
their users needed. So, it’s a long process to decide what
people need and what’s best for them.

Mark: It’s worthwhile in the end.

Tim: It’s very worth it.

Mark: You’re going to deliver a better experience across the board for all
your users and all scenarios, hopefully.

Tim: Yeah, it’s for your users, but it’s also for your development team
and your design team, so you’re not blowing them up with work.
And the architecture involved in doing these responsive
applications versus mobile desktop split. Even when you’re doing
a mobile-only site, you have these phones now that are 1024. So,
it’s like, you’ve also got to do media queries for large-screen
mobile devices. So, there’s a lot of work. But if it’s the right
answer and you properly architect it…

Mark: It may be more work up front, but you may have a more sustainable
environment down the road.

Tim: Exactly. It’s far more sustainable.

Mark: I think there’s a preconception that if I’m going to make the best
thing for my users or customize a wonderful thing for my users,
that it’s going to cost me more money, more time, more headache
overall, but it’s not necessarily the case. It’s really just
about how much you’re willing to do up front to make a
sustainable, like you would with a sustainable company in a way.
You’re building a sustainable development environment that’s
sustainable for your users’ experience as well.

Tim: Yeah. Part of the user experience thing that we do that I feel like
others maybe don’t is that we take into consideration, the
employees who have to manage the product. We try and make it a
good experience for them, also. And there is, you can get there
with some conversation. So, have a conversation with us.

Mark: So, that about wraps up for the topic today. We have a few events
coming up. And you can learn all about them at
freshtilledsoil.com/habitat. There’s some really great stuff
there, so check it out. We ask that you review us on iTunes. And
always, if you want to get in touch, tweet at us. We’re on
Twitter @thedirtshow.

Tim: @thedirtshow, indeed. Thank you for listening and we will try and do
better next time. Sometimes, I wake up and I look in the mirror
and I’m like “Whoa! There’s that guy.”

About Fresh Tilled Soil

Fresh Tilled Soil is a Boston-based user interface and experience design firm focused on human centered digital design