Adapting to a Responsive Design at Untangle the Web on 29th July 2013


Published on

These are the slides from my talk "Adapting to a Responsive Design" I gave at Untangle The Web on 29th July 2013. The talk was adapted from my case study of the same name on Smashing Magazine: about's responsive re-design.

Published in: Design, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Adapting to a Responsive Design at Untangle the Web on 29th July 2013

  1. 1. Adapting to a Responsive Design Matt Gibson / Cyber-Duck @duckymatt / @cyberduck_uk #untangletheweb
  2. 2. How do we define responsive?
  3. 3. To react quickly and positively.
  4. 4. Responsive web design is a design approach that aims to create interfaces that react quickly and positively to the user’s conditions.
  5. 5. Flickr credit: @alui0000 People will access our websites in ways we perhaps hadn’t even considered yet.
  6. 6. The previous state(s) of our website “Desktop” site (2011) “Tablet” site (Later 2011) *Not to scale :) “Mobile” site (2012)
  7. 7. Our separate mobile websites: A stop-gap strategy
  8. 8. So why go responsive?
  9. 9. 1. Multiple code bases 2. Content management 3. More and more new devices and form factors
  10. 10. You don't get to decide which device people use to access your website. Karen McGrane
  11. 11. Setting goals for a RWD...
  12. 12. 1. Content Parity Credit: The same content and functionality should be on all platforms.
  13. 13. 2. Speed Flickr credit: @myoldpostcards Performance affects everyone.
  14. 14. 3. Future friendly Credit: Cut down on maintenance and support known unknowns #ffly
  15. 15. 4. Accessibility Credit: Styles, backgrounds and JavaScript are progressive enhancements
  16. 16. 1. Content Parity
  17. 17. RWD means assuming less about our users
  18. 18. Begin by defining the content people visit your website for.
  19. 19. Researching our content strategy Speaking to existing customers Google Analytics CrazyEgg Lead Forensics
  20. 20. Defining the content first
  21. 21. Our content defines the layouts we need. Not the other way around.
  22. 22. 2. Speed
  23. 23. Does responsive = poor performance? Credit: Guy Podjarny - Creator of Mobitest:
  24. 24. To react quickly and positively.
  25. 25. It’s easy to confuse implementation with technique.
  26. 26. Making performance a priority. We set ourselves a performance budget of 500kb for mobile.
  27. 27. To load the Facebook,Twitter and Google social media buttons for a total of 19 requests takes 246.7 KB in bandwidth.
  28. 28. Off the shelf front-end frameworks The next big thing TM
  29. 29. Flickr credit: @donshall They try to do everything.
  30. 30. They make design decisions for you. Flickr credit: @jamesrbowe
  31. 31. Knowing your code from top to bottom is essential to have total control over it. Using frameworks doesn’t help with that.
  32. 32. We created a mini-library that doesn’t include any predefined styling for layout / grid, buttons, typography etc.
  33. 33. Did we need CMS software to manage our content? No CMS Software ≠ No CMS
  34. 34. For most projects the answer would be yes. For our own website it was no (apart from our blog).
  35. 35. Only loading what we need when we need it.
  36. 36. Javascript CSS Images
  37. 37. 3. Future friendliness
  38. 38. The web doesn’t have a fixed width.
  39. 39. We should embrace the fact that the web doesn’t have the same constraints [as the printed page] and design for this flexibility. John Allsopp, A Dao of Web Design
  40. 40. Layout & flow Breakpoints based on content and design, rather than device
  41. 41. Designing for context
  42. 42. The right code for the right task Leave styling to CSS and use JS only to change the “state” of an element.
  43. 43. Animation as an enhancement Using CSS3 for animations enhances the experience for browsers that support it, while older browsers still get the functionality if not the eye candy.
  44. 44. 4. Accessibility
  45. 45. 6 quick wins for accessibility
  46. 46. 1. Make the purpose of all links as clear and descriptive as possible Avoid link anchors that presume the interaction method like “click here”
  47. 47. 2. Create a hidden skip navigation link
  48. 48. 3. Make URLs human readable and permanent where possible. Is this human readable? sid=9DF4BC0580DF11D3ACB60090271E26A8 &command=freelist.
  49. 49. 4. Use descriptive alt tags for when an image cannot be shown.
  50. 50. 5. Don’t use placeholders as an alternative for labels on forms.
  51. 51. 6. Use appropriate input types and attributes on forms.
  52. 52. The results?
  53. 53. Since launch: 200%increase in mobile traffic 2.07%increase in conversion rate -4000%reduction in homepage exit rate on mobile
  54. 54. Our conclusion We are still learning. There is more to do to make our websites faster, more future friendly, more accessible. AKA more responsive.
  55. 55. Thank you. Matt Gibson / Cyber-Duck @duckymatt / @cyberduck_uk #untangletheweb