Responsive Web Design - more than just a buzzword

MORE THAN JUST A BUZZWORD
RESPONSIVE
WEB DESIGN

While I work in some areas of
User Experience, I am
deﬁnitely not a UX expert!

My main areas of work these
days is creating HTML/CSS
pattern libraries and
architectures for large
websites and web
applications.

However, I also work with a
series of smaller clients where
I do a lot of the UX work
myself.

With that in mind, we’ll start
with some key deﬁnitions and
then discuss some UX case
studies around Responsive
Web Design.

In 2010, Ethan Marcotte
coined the term
Responsive Web
Design

Rather than build separate
mobile & desktop websites...

You could choose to create a
single site that adapts to suit
any device regardless of
screen size or orientation.

Ethan Marcotte
deﬁned Responsive
Web Design with
3 principles

A ﬂexible, grid-
based layout
This allows your
layout to reﬂow to the
screen size of any
device.1

Flexible images and
media (videos etc)
This allows your
images and videos to
reﬂow with the layout
2

CSS3 Media queries
This allows you to
control each layout so
that content is
displayed optimally
3

Almost four years later, RWD
has rapidly expanded. New
techniques and ideas are
appearing almost daily.

“Testing the top 10,000
websites for responsive
indicators showed roughly
12% of these sites were
responsive.”
http://www.guypo.com/mobile/rwd-ratio-in-top-100000-websites-reﬁned/

However, there is also a
growing sense of confusion...

A lot of sites that are now
considered to be “responsive”
do not meet some or any of
Ethan’s three key criteria.

People are beginning to use
the term “responsive” instead
of “Responsive Web Design”.

This term is used to describe a
more broad approach to the
overall problem. “Responsive”
is more than just a technical
solution.

This broader approach can
include all sorts of disciplines
including content, advertising,
UX and more.

Before we look at Adaptive
Web Design, we need to deﬁne
“progressive enhancement”.

In 2003,
Steve Champeon
coined the term
“Progressive
Enhancement”

“Progressive Enhancement is
the principle of starting with a
rock-solid foundation and then
adding enhancements if
you know user-agents can
handle the improved
experience.”
http://coding.smashingmagazine.com/2009/04/22/progressive-enhancement-what-it-is-and-
how-to-use-it/

Now let’s look at Adaptive
Web Design and how it relates
to Progressive Enhancement

In 2011,
Aaron Gustafson
coined the term
“Adaptive
Web Design”

“Adaptive web design is about
creating interfaces that adapt
to the user’s capabilities (in
terms of both form and
function)...
http://blog.easy-designs.net/archives/on-adaptive-vs-responsive-web-design/

“Adaptive web design is just
another term for progressive
enhancement - it takes into
account varying levels of
markup, CSS, JavaScript and
assistive technology support.”
http://blog.easy-designs.net/archives/on-adaptive-vs-responsive-web-design/

Despite Aaron’s deﬁnition, if
you search for “Adaptive web
design” you will get all sorts of
different deﬁnitions.

One of the better deﬁnitions is
by Brad Frost, who described
adaptive as:

“Adaptive is creating a single
Web experience that modifies
based on the capabilities of the
device. It’s a singular
flexible experience built
using sound progressive
enhancement techniques.”
http://bradfrostweb.com/blog/post/the-many-faces-of-adaptive-design/

Adaptive is also used in a very
different context - to describe
“Adaptive layouts”.

Responsive layouts are ﬂuid.
They are designed to adapt to
different screen sizes.

According to some, “Adaptive
layouts” are different. They use
a series of ﬁxed-width layouts
that are designed speciﬁcally
for different screen sizes.

Progressive enhancement
Adaptive web design
Responsive Web design
Responsive layouts
(Fluid grids)
Adaptive layouts
(Fixed-width or semi-ﬁxed
width grids)

RESS is short for
Responsive and Server
Side (RESS)

RESS uses Responsive Web
Design as a base, and then
adds server side
components where needed.

RESS allows us to serve
different user experience &
features to different devices.

Why would we do this? We can
optimise the experience and
content for different devices.

Unlike “full mobile” where the
entire site is tailored to the
device, RESS allows us to
choose speciﬁc aspects of
the site to optimise.

The server side components
are normally controlled with
some sort of device detection
service (Wurﬂ, 51Degrees,
Device Atlas etc).

Example 1
serving different user
experience

Let’s use an example where
you want to use a different
navigation for mobile
devices. You might want it to
be simpler and position it in the
footer, rather than the header
of the site.

With RESS, we can do this by
providing two alternatives...
such as a wide screen and a
narrow screen header and
footer.

<body>
! {{>header}}
!
! [...document content...]
!
! {{>footer}}
</body>

If the server detects a
mobile browser, it can
render the page template
with mobile components.
Otherwise, it falls back to
the "standard" ones.

The page is still a RWD page.
But each of the variables is a
device optimised
component.

“On the new ND.edu we used a
combination of server-side
detection, media queries and
javascript to determine
content.”
http://weedygarden.net/2012/05/a-case-for-ress/

“This allowed us to drastically
reduce the amount of resources
that are initially downloaded
and the result is a very fast
mobile experience.”

Large screens:
136 requests
3.00MB
Mobile phone:
23 requests
291.94KB

As “RWD” and “responsive”
have gained popularity, there
has been a growing trend to
assume that these are the
“best solution” in all cases.

This is not true. Like any other
solution, RWD and
“responsive” have their own
strengths and weaknesses.

RWD sites are technically
much easier to implement
than full mobile or RESS sites.

RWD can be implemented by
any front end developer that
understands media queries.

For this reason, RWD sites are
probably much cheaper to
build and maintain than full
mobile or RESS sites.

With RWD, content and
functionality are delivered in
the same way to every
device.

With full mobile, content and
functionality can be optimised
for any device.

This means that RWD sites can
have much slower page
speed than full mobile or
RESS sites.

With RWD, this also means
that User Experience cannot
be fully tailored to the device.

In the end, it depends on the
site, the audience, the
development team, the budget.
Only you can decide which
solution is best for your site!

In 2011,
Luke Wroblewski
coined the term
“Mobile First”.

“Mobile First” is about
planning and designing the
entire experience for small
screen devices before wide
screen devices.

“Mobile First forces you to
focus and prioritize your
products by embracing the
constraints inherent in mobile
design”.
http://mobilegovwiki.howto.gov/Mobile+First

For many Responsive Web
Design projects, I use a
variation on this approach
which is “all screens ﬁrst”.

I try to get the team to focus
on a product that will work at
any screen size (phone, small
tablet, large tablet, desktop) -
not just wide or narrow.

The aim is to get teams to
move away from “wide screen
only” thinking.

It’s very easy for teams to
accidentally slide back to
“wide screen only” thinking
during a project.

For this reason, “Mobile First”
or “all screens ﬁrst” should be
used through all phases of
the project, from initial
sketches, to wireframes,
prototypes, user-testing,
design and development.

In mid 2011, I worked on two
responsive web projects
back to back.

This gave me an opportunity to
observe and compare different
two RWD processes in action.

The ﬁrst project was to design
and develop a complex
Responsive web application
for a large “Energy company”.

We used the “Mobile ﬁrst”
approach throughout every
phase of the project.

Every decision was made
based on how the web
application would work on
small screens.

Because of restricted screen
real estate, the layout and
functionality was focused and
direct.

When it came time to work on
the wide screen variations
during each phase, it was
incredibly easy as each
screen had already been
optimised.

For the second project, I was
asked to do the front-end
development on a non-proﬁt
Responsive website. When I
came on board, the team were
in the middle of the design
phase.

While the wireframe phase had
used “Mobile ﬁrst”, the design
phase did not. The team spent
weeks focusing on the wide
screen designs only.

Once the wide screen designs
were fully signed-off, the team
then moved on to narrow
screen designs.

As you can imagine, many of
the decisions made for wide
screen did not work at small
screen.

Aspects of the wide screen
layout and functionality had to
either be heavily adjusted for
narrow screen, or revisited at
wide screen.

A lot of this pain could have
been avoided if they had
maintained a rigorous
“Mobile ﬁrst” approach
throughout the design phase.

I’m now going to discuss two
simple RWD UX case
studies.

The ﬁndings will come as no
surprise to many of you, but
hopefully there are some
interesting little discoveries
along the way.

Case study 1
Testing different navigation
paradigms

One of the biggest challenges
of Responsive Web Design
sites is how to deal with site
navigation on small and
medium screen sizes.

With wide screen, there is a lot
of space to play with, so site
navigation can be displayed
in a variety of different ways.

With small screen, there is
extremely limited screen
space, and navigation could
easily take up the entire
screen.

Most RWD sites attempt to
hide away site navigation at
small screen to free up the real
estate.

A lot of different techniques
have been developed over the
last few years, to solve this
problem.

Here are seven emerging
Responsive navigation
design patterns.

This is where you let the
navigation wrap as needed.

home about us services portfolio contact us login
Lorem ipsum dolor sit amet consect etuer adipi scing elit sed diam nonummy nibh euismod tinunt
ut laoreet dolore magna aliquam erat volut. Ut wisi enim ad minim veniam, quis nostrud exerci
tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum
iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla
facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril
delenit augue duis dolore te feugait nulla facilisi.

home about us services
portfolio contact us login
Lorem ipsum dolor sit amet consect
etuer adipi scing elit sed diam
nonummy nibh euismod tinunt ut
laoreet dolore magna aliquam erat
volut. Ut wisi enim ad minim veniam,
quis nostrud exerci tation
ullamcorper suscipit lobortis nisl ut
aliquip ex ea commodo consequat.
Duis autem vel eum iriure dolor in
hendrerit in vulputate velit esse
molestie consequat, vel illum dolore
eu feugiat nulla facilisis at vero eros
et accumsan et iusto odio dignissim
qui blandit praesent luptatum zzril
delenit augue duis dolore te feugait
nulla facilisi.

Example:
http://responsivenavigation.net/
examples/simple-padding/

Pro: Easy to implement. No
special CSS or JS needed.
Con: Can take up space -
especially at the top of the
screen.

At small screen, the header
contains a simple link pointing
to the footer navigation. The
footer contains the
navigation.

home
about us
services
portfolio
contact us
login
Site navigation

Example:
examples/footer-list/

Pro: Easy to implement. No
special CSS or JS needed.
Con: Can be disorientating for
some users.

At small screen, the navigation
is hidden away and replaced
with a link, icon or both.
When users click on the link/
icon, the navigation slides
open, pushing the page
contents down.

Site navigation

Example:
http://codecanyon.net/item/slicenav-
responsive-navigation-menu/
full_screen_preview/4874922

Pro: Keeps the navigation in
place, which is good for users.
Elegant.
Con: JS dependent. Some
options do not support
keyboard access.

Similar to the toggle approach,
but the menu does not push
the page contents down.
Instead, the navigation sits
over the top of page content.

home
about us
services
portfolio
contact us
login
Site navigation

Example:
examples/simple-toggle/

Similar to the toggle approach,
but with additional ability to
open and close multiple levels
of navigation.

home
about us
services
portfolio
contact us
login
Site navigation

home
about us
our history
our staff
contacting us
where to find us
services
portfolio
contact us
login
Site navigation

Example:
examples/multi-toggle/

Pro: Keeps the navigation in
place, which is good for users.
Elegant.
Con: JS dependent. Some
options do not support
keyboard access. Can be
confusing for some users.

is converted into a select
menu.

Site navigation

Example:
examples/select-menu/

Pro: Frees up space.
Con: JS dependent. Can
confuse some users.
Sometimes harder to style.

is hidden away and replaced
with a link, icon or both. When
users click on the link/icon a
tray slides in from the left
and the main content is
pushed to the right.

Users can close the tray and
the content slides back over to
the left.

home
about us
services
portfolio
contact us
login
Close
Lorem ipsum
ut laoreet dolo
tation ullamco
iriure dolor in
facilisis at ver
delenit augue
Site navigation

Example:
examples/off-canvas-slide/

Pro: Frees up space.
Con: Much harder to build,
especially elegantly. Doesn't
scale well.

In early 2013, I worked on a
client site where we wanted to
test three different navigation
methods to see which would
be most intuitive at small
screen.

The method we chose where:
The footer anchor
The toggle
The select menu

Key target audiences were
identiﬁed, and 30 users from
these target audiences were
chosen to take part in the
testing process.

These users did not know that
the primary purpose for the
test was to watch them
interact with the different
navigation methods.

Each user was asked to
perform a range of tasks on
three different sites. Each site
had a different menu pattern.

At the end of the process,
users were asked to rate the
difﬁculty of each navigation
method.

Based on our observations
and user ratings:
1. The footer anchor method
and select menu confused
many users
2. Most users preferred the
toggle menu

Case study 2
Testing navigation icon vs
text

In mid 2013, I worked with a
client who wanted to use an
icon only to show the menu
when it was “hidden away” at
small screen.

The target audience consisted
of all sorts of age groups as
well as users that were “tech
savy” and totally “non-tech
savy”.

We were concerned that this
audience may not understand
such an icon.

Again, a range of target
audience users were chosen
and asked to perform
speciﬁc tasks on small screen
devices only.

10 users were presented with
a site using an “icon only”.
Site navigation

10 users were presented with
a site that used an “icon and
text”.
Site navigation

Of the 10 “icon only” users,
only one user immediately
understood the purpose of the
icon.

Six of the “icon only” users
discovered the purpose of
the icon by trial and error.

Three “icon only” users did not
discover the purpose for the
icon at all. These users were
not able to complete the
relevant tasks.

All ten “icon and text” were
able to understand the
purpose of this function and
complete the relevant tasks.

While this may seem like a
compelling result, a lot would
depend on the types of users
tested, the placement of icon
and other factors.

For example, an icon that is
tucked away in the top left or
right corner may be harder for
users to discover.

During testing, several people
mentioned that they did not
like the word “navigation”
associated with the icon.

We decided to do some
additional testing, this time
focussing on the wording
associated with the icon.

Users were presented with four
choices and asked to decide
which was the most
meaningful.

The choices provided were:
Menu
Navigation
Site menu
Site navigation

Most users preferred either
“Menu” or “Site menu”. We felt
that “Site menu” would be the
safest option as it is most
descriptive.

Despite our recommendations,
the client decided to go with
an icon only because it
“looked neater”, and “lots of
other sites use these icons
now”.

Responsive Web Design is a
great solution for many
websites today.

It allows us to build sites that
work across a wide range of
devices without a lot of the
cost or effort associated with
full mobile or RESS sites.

Just as with any website or
web application, with
Responsive solutions we have
to avoid making assumptions
about our users.

Responsive Web Design - more than just a buzzword

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (10)

Ähnlich wie Responsive Web Design - more than just a buzzword

Ähnlich wie Responsive Web Design - more than just a buzzword (20)

Mehr von Russ Weakley

Mehr von Russ Weakley (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Responsive Web Design - more than just a buzzword