Responsive Web Design - more than just a buzzword
 

Responsive Web Design - more than just a buzzword

on

  • 2,491 views

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

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

Statistics

Views

Total Views
2,491
Views on SlideShare
2,355
Embed Views
136

Actions

Likes
21
Downloads
67
Comments
2

3 Embeds 136

http://uxaustralia.com.au 90
https://twitter.com 31
https://online.cdu.edu.au 15

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Nice review and case studies. I like the toggle/icon/'menu'(text) approach. Thank you.
    Are you sure you want to
    Your message goes here
    Processing…
  • From English to Korean.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Responsive Web Design - more than just a buzzword Responsive Web Design - more than just a buzzword Presentation Transcript

  • 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 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 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.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.” http://blog.easy-designs.net/archives/on-adaptive-vs-responsive-web-design/
  • 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 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 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 2 Real 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 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 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 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.
  • 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 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.
  • 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 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 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.
  • 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.
  • 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.
  • 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://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.
  • 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.
  • 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.
  • 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
  • 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 keyboard access.
  • 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 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.
  • 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.
  • 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
  • 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 keyboard access. Can be confusing for some users.
  • 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 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.
  • 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
  • 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 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 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.
  • 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 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 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 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 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: 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.
  • 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 early Test often