Responsive Web Design - more than just a buzzword

MORE THAN JUST A BUZZWORD

RESPONSIVEWEB 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 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 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 layoutThis 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 layout2

CSS3 Media queriesThis allows you to control each layout so that content is displayed optimally3

“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.guypo.com/mobile/rwd-ratio-in-top-100000-websites-refined/



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.

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 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.”




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 flexible experience built using sound progressive enhancement techniques.”

http://bradfrostweb.com/blog/post/the-many-faces-of-adaptive-design/



Ready to beconfused?

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 for different screen sizes.

Progressive enhancement

Adaptive web design

Responsive Web design

Responsive layouts(Fluid grids)

Adaptive layouts(Fixed-width or semi-fixed

width grids)

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 to optimise.

The server side components are normally controlled with some sort of device detection service (Wurfl, 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.

Example 2Real world example

“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 requests3.00MB

Mobile phone:23 requests291.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 solution” in all cases.

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 best for your site!

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”.

http://mobilegovwiki.howto.gov/Mobile+First



“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) - 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 first” should be used through all phases of the project, from initial sketches, to wireframes, prototypes, user-testing, design and development.

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 already been optimised.

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.

While the wireframe phase had used “Mobile first”, 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 first” approach throughout the design phase.

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 way.

Case study 1Testing 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.

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 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 loginLorem 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.

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

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.

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, the navigation slides open, pushing the page contents down.



Site navigation


home

about us

services

portfolio

contact us

login

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.

4. Toggle overlay

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.



Site navigation



home

about us

services

portfolio

contact us

login

Site navigation

Example:

http://responsivenavigation.net/examples/simple-toggle/

http://responsivenavigation.net/examples/simple-toggle/#





Con: JS dependent. Some options do not support keyboard access.

5. Multi-level toggle

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



Site 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:

http://responsivenavigation.net/examples/multi-toggle/






Con: JS dependent. Some options do not support keyboard access. Can be confusing for some users.

6. The Select Menu

At small screen, the navigation is converted into a select menu.




Site navigation

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 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 dolotation ullamcoiriure dolor in facilisis at verdelenit augue

Site navigation


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 most intuitive at small screen.

The method we chose where:The footer anchorThe toggleThe select menu

Key target audiences were identified, 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 difficulty of each navigation method.

Based on our observations and user ratings:

1. The footer anchor method and select menu confused many users2. Most users preferred the toggle menu

Case study 2Testing 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 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 relevant tasks.

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 other factors.

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:MenuNavigationSite menuSite navigation

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

The decision

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”.

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 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.

Test earlyTest often

Education

Responsive Web Design - more than just a buzzword