MORE THAN JUST A BUZZWORD
RESPONSIVE
WEB DESIGN
Before we start...
While I work in some areas of
User Experience, I am
definitely not a UX expert!
My main areas of work these
days is creating HTML/CSS
pattern libraries and
architectures for large
websites and web
appli...
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 definitions and
then discuss some UX case
studies around Responsive
Web Design.
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
defined Responsive
Web Design with
3 principles
A flexible, grid-
based layout
This allows your
layout to reflow to the
screen size of any
device.1
Flexible images and
media (videos etc)
This allows your
images and videos to
reflow with the layout
2
CSS3 Media queries
This allows you to
control each layout so
that content is
displayed optimally
3
“responsive” vs
RWD
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....
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
sol...
This broader approach can
include all sorts of disciplines
including content, advertising,
UX and more.
Adaptive Web
Design
Before we look at Adaptive
Web Design, we need to define
“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 kno...
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
functio...
“Adaptive web design is just
another term for progressive
enhancement - it takes into
account varying levels of
markup, CS...
Despite Aaron’s definition, if
you search for “Adaptive web
design” you will get all sorts of
different definitions.
One of the better definitions 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
flexi...
Ready to be
confused?
Adaptive is also used in a very
different context - to describe
“Adaptive layouts”.
Responsive layouts are fluid.
They are designed to adapt to
different screen sizes.
According to some, “Adaptive
layouts” are different. They use
a series of fixed-width layouts
that are designed specifically...
Progressive enhancement
Adaptive web design
Responsive Web design
Responsive layouts
(Fluid grids)
Adaptive layouts
(Fixed...
RESS
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 specific aspects of
the site...
The server side components
are normally controlled with
some sort of device detection
service (Wurfl, 51Degrees,
Device Atl...
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 ...
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 t...
The page is still a RWD page.
But each of the variables is a
device optimised
component.
Example 2
Real world example
“On the new ND.edu we used a
combination of server-side
detection, media queries and
javascript to determine
content.”
htt...
“This allowed us to drastically
reduce the amount of resources
that are initially downloaded
and the result is a very fast...
Large screens:
136 requests
3.00MB
Mobile phone:
23 requests
291.94KB
Is Responsive
the answer?
As “RWD” and “responsive”
have gained popularity, there
has been a growing trend to
assume that these are the
“best soluti...
This is not true. Like any other
solution, RWD and
“responsive” have their own
strengths and weaknesses.
RWD strengths
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.
RWD weaknesses
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.
“It depends”
In the end, it depends on the
site, the audience, the
development team, the budget.
Only you can decide which
solution is ...
Mobile First
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”.
ht...
“All screens first”
For many Responsive Web
Design projects, I use a
variation on this approach
which is “all screens first”.
I try to get the team to focus
on a product that will work at
any screen size (phone, small
tablet, large tablet, desktop)...
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 first” should be
used through all phases of
the project, from initial
sketc...
A cautionary tale
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 first project was to design
and develop a complex
Responsive web application
for a large “Energy company”.
We used the “Mobile first”
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 alrea...
For the second project, I was
asked to do the front-end
development on a non-profit
Responsive website. When I
came on boar...
While the wireframe phase had
used “Mobile first”, the design
phase did not. The team spent
weeks focusing on the wide
scre...
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
w...
A lot of this pain could have
been avoided if they had
maintained a rigorous
“Mobile first” approach
throughout the design ...
Some case
studies
I’m now going to discuss two
simple RWD UX case
studies.
The findings will come as no
surprise to many of you, but
hopefully there are some
interesting little discoveries
along the...
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 scree...
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.
1. Do Nothing
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 nonum...
home about us services
portfolio contact us login
Lorem ipsum dolor sit amet consect
etuer adipi scing elit sed diam
nonum...
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.
2. The Footer Anchor
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
Lorem ipsum dolor sit amet consect etuer adipi scing elit sed diam nonum...
home
about us
services
portfolio
contact us
login
Site navigation
Lorem ipsum dolor sit amet consect
etuer adipi scing eli...
Example:
http://responsivenavigation.net/
examples/footer-list/
Pro: Easy to implement. No
special CSS or JS needed.
Con: Can be disorientating for
some users.
3. The Toggle
At small screen, the navigation
is hidden away and replaced
with a link, icon or both.
When users click on the link/
icon,...
home about us services portfolio contact us login
Lorem ipsum dolor sit amet consect etuer adipi scing elit sed diam nonum...
Site navigation
Lorem ipsum dolor sit amet consect
etuer adipi scing elit sed diam
nonummy nibh euismod tinunt ut
laoreet ...
home
about us
services
portfolio
contact us
login
Site navigation
Lorem ipsum dolor sit amet consect
etuer adipi scing eli...
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
keybo...
4. Toggle overlay
Similar to the toggle approach,
but the menu does not push
the page contents down.
Instead, the navigation sits
over the t...
home about us services portfolio contact us login
Lorem ipsum dolor sit amet consect etuer adipi scing elit sed diam nonum...
Site navigation
Lorem ipsum dolor sit amet consect
etuer adipi scing elit sed diam
nonummy nibh euismod tinunt ut
laoreet ...
Lorem ipsum dolor sit amet consect
etuer adipi scing elit sed diam
nonummy nibh euismod tinunt ut
laoreet dolore magna ali...
Example:
http://responsivenavigation.net/
examples/simple-toggle/
Pro: Keeps the navigation in
place, which is good for users.
Elegant.
Con: JS dependent. Some
options do not support
keybo...
5. Multi-level 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
Lorem ipsum dolor sit amet consect etuer adipi scing elit sed diam nonum...
Site navigation
Lorem ipsum dolor sit amet consect
etuer adipi scing elit sed diam
nonummy nibh euismod tinunt ut
laoreet ...
home
about us
services
portfolio
contact us
login
Lorem ipsum dolor sit amet consect
etuer adipi scing elit sed diam
nonum...
home
about us
our history
our staff
contacting us
where to find us
services
portfolio
contact us
login
Site navigation
Example:
http://responsivenavigation.net/
examples/multi-toggle/
Pro: Keeps the navigation in
place, which is good for users.
Elegant.
Con: JS dependent. Some
options do not support
keybo...
6. The Select Menu
At small screen, the navigation
is converted into a select
menu.
home about us services portfolio contact us login
Lorem ipsum dolor sit amet consect etuer adipi scing elit sed diam nonum...
Lorem ipsum dolor sit amet consect
etuer adipi scing elit sed diam
nonummy nibh euismod tinunt ut
laoreet dolore magna ali...
Example:
http://responsivenavigation.net/
examples/select-menu/
Pro: Frees up space.
Con: JS dependent. Can
confuse some users.
Sometimes harder to style.
7. Off-canvas
At small screen, the navigation
is hidden away and replaced
with a link, icon or both. When
users click on the link/icon a...
Users can close the tray and
the content slides back over to
the left.
home about us services portfolio contact us login
Lorem ipsum dolor sit amet consect etuer adipi scing elit sed diam nonum...
home
about us
services
portfolio
contact us
login
Close
Lorem ipsum
ut laoreet dolo
tation ullamco
iriure dolor in
facilis...
Example:
http://responsivenavigation.net/
examples/off-canvas-slide/
Pro: Frees up space.
Con: Much harder to build,
especially elegantly. Doesn't
scale well.
The case study
In early 2013, I worked on a
client site where we wanted to
test three different navigation
methods to see which would
be ...
The method we chose where:
The footer anchor
The toggle
The select menu
Key target audiences were
identified, and 30 users from
these target audiences were
chosen to take part in the
testing proc...
These users did not know that
the primary purpose for the
test was to watch them
interact with the different
navigation me...
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
difficulty 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 ...
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 scr...
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
specific 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
The findings
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
releva...
All ten “icon and text” were
able to understand the
purpose of this function and
complete the relevant tasks.
Some cautions
While this may seem like a
compelling result, a lot would
depend on the types of users
tested, the placement of icon
and o...
For example, an icon that is
tucked away in the top left or
right corner may be harder for
users to discover.
Wording
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
descr...
The decision
Despite our recommendations,
the client decided to go with
an icon only because it
“looked neater”, and “lots of
other sit...
Conclusions?
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
f...
Just as with any website or
web application, with
Responsive solutions we have
to avoid making assumptions
about our users.
Test early
Test often
Responsive Web Design - more than just a buzzword
Responsive Web Design - more than just a buzzword
Upcoming SlideShare
Loading in...5
×

Responsive Web Design - more than just a buzzword

3,942

Published on

A discussion on Responsive Web Design and UX - covering definitions of responsive web design, adaptive, RESS, mobile first and more,

Published in: Education
2 Comments
26 Likes
Statistics
Notes
No Downloads
Views
Total Views
3,942
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
101
Comments
2
Likes
26
Embeds 0
No embeds

No notes for slide

Responsive Web Design - more than just a buzzword

  1. 1. MORE THAN JUST A BUZZWORD RESPONSIVE WEB DESIGN
  2. 2. Before we start...
  3. 3. While I work in some areas of User Experience, I am definitely not a UX expert!
  4. 4. My main areas of work these days is creating HTML/CSS pattern libraries and architectures for large websites and web applications.
  5. 5. However, I also work with a series of smaller clients where I do a lot of the UX work myself.
  6. 6. With that in mind, we’ll start with some key definitions and then discuss some UX case studies around Responsive Web Design.
  7. 7. Responsive Web Design
  8. 8. In 2010, Ethan Marcotte coined the term Responsive Web Design
  9. 9. Rather than build separate mobile & desktop websites...
  10. 10. You could choose to create a single site that adapts to suit any device regardless of screen size or orientation.
  11. 11. Ethan Marcotte defined Responsive Web Design with 3 principles
  12. 12. A flexible, grid- based layout This allows your layout to reflow to the screen size of any device.1
  13. 13. Flexible images and media (videos etc) This allows your images and videos to reflow with the layout 2
  14. 14. CSS3 Media queries This allows you to control each layout so that content is displayed optimally 3
  15. 15. “responsive” vs RWD
  16. 16. Almost four years later, RWD has rapidly expanded. New techniques and ideas are appearing almost daily.
  17. 17. “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-refined/
  18. 18. However, there is also a growing sense of confusion...
  19. 19. A lot of sites that are now considered to be “responsive” do not meet some or any of Ethan’s three key criteria.
  20. 20. People are beginning to use the term “responsive” instead of “Responsive Web Design”.
  21. 21. This term is used to describe a more broad approach to the overall problem. “Responsive” is more than just a technical solution.
  22. 22. This broader approach can include all sorts of disciplines including content, advertising, UX and more.
  23. 23. Adaptive Web Design
  24. 24. Before we look at Adaptive Web Design, we need to define “progressive enhancement”.
  25. 25. In 2003, Steve Champeon coined the term “Progressive Enhancement”
  26. 26. “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/
  27. 27. Now let’s look at Adaptive Web Design and how it relates to Progressive Enhancement
  28. 28. In 2011, Aaron Gustafson coined the term “Adaptive Web Design”
  29. 29. “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/
  30. 30. “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/
  31. 31. Despite Aaron’s definition, if you search for “Adaptive web design” you will get all sorts of different definitions.
  32. 32. One of the better definitions is by Brad Frost, who described adaptive as:
  33. 33. “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/
  34. 34. Ready to be confused?
  35. 35. Adaptive is also used in a very different context - to describe “Adaptive layouts”.
  36. 36. Responsive layouts are fluid. They are designed to adapt to different screen sizes.
  37. 37. According to some, “Adaptive layouts” are different. They use a series of fixed-width layouts that are designed specifically for different screen sizes.
  38. 38. Progressive enhancement Adaptive web design Responsive Web design Responsive layouts (Fluid grids) Adaptive layouts (Fixed-width or semi-fixed width grids)
  39. 39. RESS
  40. 40. RESS is short for Responsive and Server Side (RESS)
  41. 41. RESS uses Responsive Web Design as a base, and then adds server side components where needed.
  42. 42. RESS allows us to serve different user experience & features to different devices.
  43. 43. Why would we do this? We can optimise the experience and content for different devices.
  44. 44. Unlike “full mobile” where the entire site is tailored to the device, RESS allows us to choose specific aspects of the site to optimise.
  45. 45. The server side components are normally controlled with some sort of device detection service (Wurfl, 51Degrees, Device Atlas etc).
  46. 46. Example 1 serving different user experience
  47. 47. 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.
  48. 48. With RESS, we can do this by providing two alternatives... such as a wide screen and a narrow screen header and footer.
  49. 49. <body> ! {{>header}} ! ! [...document content...] ! ! {{>footer}} </body>
  50. 50. If the server detects a mobile browser, it can render the page template with mobile components. Otherwise, it falls back to the "standard" ones.
  51. 51. The page is still a RWD page. But each of the variables is a device optimised component.
  52. 52. Example 2 Real world example
  53. 53. “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/
  54. 54. “This allowed us to drastically reduce the amount of resources that are initially downloaded and the result is a very fast mobile experience.”
  55. 55. Large screens: 136 requests 3.00MB Mobile phone: 23 requests 291.94KB
  56. 56. Is Responsive the answer?
  57. 57. As “RWD” and “responsive” have gained popularity, there has been a growing trend to assume that these are the “best solution” in all cases.
  58. 58. This is not true. Like any other solution, RWD and “responsive” have their own strengths and weaknesses.
  59. 59. RWD strengths
  60. 60. RWD sites are technically much easier to implement than full mobile or RESS sites.
  61. 61. RWD can be implemented by any front end developer that understands media queries.
  62. 62. For this reason, RWD sites are probably much cheaper to build and maintain than full mobile or RESS sites.
  63. 63. RWD weaknesses
  64. 64. With RWD, content and functionality are delivered in the same way to every device.
  65. 65. With full mobile, content and functionality can be optimised for any device.
  66. 66. This means that RWD sites can have much slower page speed than full mobile or RESS sites.
  67. 67. With RWD, this also means that User Experience cannot be fully tailored to the device.
  68. 68. “It depends”
  69. 69. 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!
  70. 70. Mobile First
  71. 71. In 2011, Luke Wroblewski coined the term “Mobile First”.
  72. 72. “Mobile First” is about planning and designing the entire experience for small screen devices before wide screen devices.
  73. 73. “Mobile First forces you to focus and prioritize your products by embracing the constraints inherent in mobile design”. http://mobilegovwiki.howto.gov/Mobile+First
  74. 74. “All screens first”
  75. 75. For many Responsive Web Design projects, I use a variation on this approach which is “all screens first”.
  76. 76. 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.
  77. 77. The aim is to get teams to move away from “wide screen only” thinking.
  78. 78. It’s very easy for teams to accidentally slide back to “wide screen only” thinking during a project.
  79. 79. For this reason, “Mobile First” or “all screens first” should be used through all phases of the project, from initial sketches, to wireframes, prototypes, user-testing, design and development.
  80. 80. A cautionary tale
  81. 81. In mid 2011, I worked on two responsive web projects back to back.
  82. 82. This gave me an opportunity to observe and compare different two RWD processes in action.
  83. 83. The first project was to design and develop a complex Responsive web application for a large “Energy company”.
  84. 84. We used the “Mobile first” approach throughout every phase of the project.
  85. 85. Every decision was made based on how the web application would work on small screens.
  86. 86. Because of restricted screen real estate, the layout and functionality was focused and direct.
  87. 87. 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.
  88. 88. For the second project, I was asked to do the front-end development on a non-profit Responsive website. When I came on board, the team were in the middle of the design phase.
  89. 89. While the wireframe phase had used “Mobile first”, the design phase did not. The team spent weeks focusing on the wide screen designs only.
  90. 90. Once the wide screen designs were fully signed-off, the team then moved on to narrow screen designs.
  91. 91. As you can imagine, many of the decisions made for wide screen did not work at small screen.
  92. 92. Aspects of the wide screen layout and functionality had to either be heavily adjusted for narrow screen, or revisited at wide screen.
  93. 93. A lot of this pain could have been avoided if they had maintained a rigorous “Mobile first” approach throughout the design phase.
  94. 94. Some case studies
  95. 95. I’m now going to discuss two simple RWD UX case studies.
  96. 96. The findings will come as no surprise to many of you, but hopefully there are some interesting little discoveries along the way.
  97. 97. Case study 1 Testing different navigation paradigms
  98. 98. One of the biggest challenges of Responsive Web Design sites is how to deal with site navigation on small and medium screen sizes.
  99. 99. With wide screen, there is a lot of space to play with, so site navigation can be displayed in a variety of different ways.
  100. 100. With small screen, there is extremely limited screen space, and navigation could easily take up the entire screen.
  101. 101. Most RWD sites attempt to hide away site navigation at small screen to free up the real estate.
  102. 102. A lot of different techniques have been developed over the last few years, to solve this problem.
  103. 103. Here are seven emerging Responsive navigation design patterns.
  104. 104. 1. Do Nothing
  105. 105. This is where you let the navigation wrap as needed.
  106. 106. 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.
  107. 107. 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.
  108. 108. Example: http://responsivenavigation.net/ examples/simple-padding/
  109. 109. Pro: Easy to implement. No special CSS or JS needed. Con: Can take up space - especially at the top of the screen.
  110. 110. 2. The Footer Anchor
  111. 111. At small screen, the header contains a simple link pointing to the footer navigation. The footer contains the navigation.
  112. 112. 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.
  113. 113. home about us services portfolio contact us login Site navigation 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.
  114. 114. Example: http://responsivenavigation.net/ examples/footer-list/
  115. 115. Pro: Easy to implement. No special CSS or JS needed. Con: Can be disorientating for some users.
  116. 116. 3. The Toggle
  117. 117. 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.
  118. 118. 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.
  119. 119. Site navigation 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.
  120. 120. home about us services portfolio contact us login Site navigation 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.
  121. 121. Example: http://codecanyon.net/item/slicenav- responsive-navigation-menu/ full_screen_preview/4874922
  122. 122. Pro: Keeps the navigation in place, which is good for users. Elegant. Con: JS dependent. Some options do not support keyboard access.
  123. 123. 4. Toggle overlay
  124. 124. 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.
  125. 125. 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.
  126. 126. Site navigation 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.
  127. 127. 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. home about us services portfolio contact us login Site navigation
  128. 128. Example: http://responsivenavigation.net/ examples/simple-toggle/
  129. 129. Pro: Keeps the navigation in place, which is good for users. Elegant. Con: JS dependent. Some options do not support keyboard access.
  130. 130. 5. Multi-level toggle
  131. 131. Similar to the toggle approach, but with additional ability to open and close multiple levels of navigation.
  132. 132. 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.
  133. 133. Site navigation 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.
  134. 134. 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. Site navigation
  135. 135. home about us our history our staff contacting us where to find us services portfolio contact us login Site navigation
  136. 136. Example: http://responsivenavigation.net/ examples/multi-toggle/
  137. 137. 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.
  138. 138. 6. The Select Menu
  139. 139. At small screen, the navigation is converted into a select menu.
  140. 140. 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.
  141. 141. 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. Site navigation
  142. 142. Example: http://responsivenavigation.net/ examples/select-menu/
  143. 143. Pro: Frees up space. Con: JS dependent. Can confuse some users. Sometimes harder to style.
  144. 144. 7. Off-canvas
  145. 145. At small screen, the navigation 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.
  146. 146. Users can close the tray and the content slides back over to the left.
  147. 147. 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.
  148. 148. 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 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.
  149. 149. Example: http://responsivenavigation.net/ examples/off-canvas-slide/
  150. 150. Pro: Frees up space. Con: Much harder to build, especially elegantly. Doesn't scale well.
  151. 151. The case study
  152. 152. 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.
  153. 153. The method we chose where: The footer anchor The toggle The select menu
  154. 154. Key target audiences were identified, and 30 users from these target audiences were chosen to take part in the testing process.
  155. 155. These users did not know that the primary purpose for the test was to watch them interact with the different navigation methods.
  156. 156. Each user was asked to perform a range of tasks on three different sites. Each site had a different menu pattern.
  157. 157. At the end of the process, users were asked to rate the difficulty of each navigation method.
  158. 158. 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
  159. 159. Case study 2 Testing navigation icon vs text
  160. 160. 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.
  161. 161. The target audience consisted of all sorts of age groups as well as users that were “tech savy” and totally “non-tech savy”.
  162. 162. We were concerned that this audience may not understand such an icon.
  163. 163. Again, a range of target audience users were chosen and asked to perform specific tasks on small screen devices only.
  164. 164. 10 users were presented with a site using an “icon only”. Site navigation
  165. 165. 10 users were presented with a site that used an “icon and text”. Site navigation
  166. 166. The findings
  167. 167. Of the 10 “icon only” users, only one user immediately understood the purpose of the icon.
  168. 168. Six of the “icon only” users discovered the purpose of the icon by trial and error.
  169. 169. Three “icon only” users did not discover the purpose for the icon at all. These users were not able to complete the relevant tasks.
  170. 170. All ten “icon and text” were able to understand the purpose of this function and complete the relevant tasks.
  171. 171. Some cautions
  172. 172. 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.
  173. 173. For example, an icon that is tucked away in the top left or right corner may be harder for users to discover.
  174. 174. Wording
  175. 175. During testing, several people mentioned that they did not like the word “navigation” associated with the icon.
  176. 176. We decided to do some additional testing, this time focussing on the wording associated with the icon.
  177. 177. Users were presented with four choices and asked to decide which was the most meaningful.
  178. 178. The choices provided were: Menu Navigation Site menu Site navigation
  179. 179. Most users preferred either “Menu” or “Site menu”. We felt that “Site menu” would be the safest option as it is most descriptive.
  180. 180. The decision
  181. 181. 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”.
  182. 182. Conclusions?
  183. 183. Responsive Web Design is a great solution for many websites today.
  184. 184. 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.
  185. 185. Just as with any website or web application, with Responsive solutions we have to avoid making assumptions about our users.
  186. 186. Test early Test often
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×