Your SlideShare is downloading. ×
0
Adapting to a
Responsive
Design
Matt Gibson / Cyber-Duck
@duckymatt / @cyberduck_uk
#untangletheweb
How do we define
responsive?
To react quickly
and positively.
Responsive web design
is a design approach that
aims to create interfaces
that react quickly and
positively to the user’s
...
Flickr credit: @alui0000
People will access our websites in ways we
perhaps hadn’t even considered yet.
The previous state(s)
of our website
“Desktop” site
(2011)
“Tablet” site
(Later 2011)
*Not to scale :)
“Mobile” site
(2012)
Our separate mobile websites:
A stop-gap strategy
So why go
responsive?
1. Multiple code bases
2. Content management
3. More and more new
devices and form factors
You don't get to decide
which device people use
to access your website.
Karen McGrane
http://bondartscience.com/
Setting goals for
a RWD...
1. Content Parity
Credit: http://wtfmobileweb.com/
The same content and functionality should be on all platforms.
2. Speed
Flickr credit: @myoldpostcards
Performance affects everyone.
3. Future friendly
Credit: http://futurefriend.ly/
Cut down on maintenance and support known unknowns
#ffly
4. Accessibility
Credit: http://futurefriend.ly/
Styles, backgrounds and JavaScript
are progressive enhancements
1. Content Parity
RWD means
assuming less
about our users
Begin by defining the content
people visit your website for.
http://xkcd.com/773/
Researching our content strategy
Speaking to existing customers
Google Analytics
CrazyEgg
Lead Forensics
Defining the content first
Our content defines the
layouts we need.
Not the other way around.
2. Speed
Does responsive =
poor performance?
Credit: Guy Podjarny - Creator of Mobitest: http://www.guypo.com/mobile/what-are-respo...
To react quickly
and positively.
It’s easy to confuse
implementation with
technique.
Making performance a
priority.
We set ourselves a performance budget of 500kb for mobile.
To load the Facebook,Twitter and Google
social media buttons for a total of 19
requests takes 246.7 KB in bandwidth.
http:...
Off the shelf
front-end frameworks
The next big thing TM
Flickr credit: @donshall
They try to do everything.
They make design decisions for you.
Flickr credit: @jamesrbowe
Knowing your code from top to bottom is
essential to have total control over it.
Using frameworks doesn’t help with that.
https://github.com/Cyber-Duck/hoisin.scss
We created a mini-library that
doesn’t include any predefined
styling for layout ...
Did we need CMS
software to manage
our content?
No CMS Software ≠ No CMS
For most projects
the answer would
be yes.
For our own website it was no (apart from our blog).
Only loading
what we need
when we need it.
Javascript
CSS
Images
3. Future friendliness
The web doesn’t
have a fixed width.
We should embrace the fact that
the web doesn’t have the same
constraints [as the printed page]
and design for this flexibi...
Layout & flow
Breakpoints based on content and design, rather than device
Designing for context
The right code for the right task
Leave styling to CSS and
use JS only to change
the “state” of an element.
Animation as an enhancement
Using CSS3 for
animations enhances the
experience for browsers
that support it, while
older br...
4. Accessibility
6 quick wins for
accessibility
1. Make the purpose of all
links as clear and
descriptive as possible
Avoid link anchors that presume the interaction meth...
2. Create a hidden skip
navigation link
3. Make URLs human
readable and permanent
where possible.
Is this human readable?
http://art.com/artgallery/default.asp?
s...
4. Use descriptive alt tags
for when an image
cannot be shown.
5. Don’t use placeholders
as an alternative for
labels on forms.
6. Use appropriate input
types and attributes on
forms.
The results?
Since launch:
200%increase in
mobile traffic
2.07%increase in
conversion rate
-4000%reduction in homepage
exit rate on mobile
Our conclusion
We are still learning.
There is more to do to make
our websites faster, more
future friendly, more
accessib...
Thank you.
Matt Gibson / Cyber-Duck
@duckymatt / @cyberduck_uk
#untangletheweb
Adapting to a Responsive Design at Untangle the Web on 29th July 2013
Adapting to a Responsive Design at Untangle the Web on 29th July 2013
Adapting to a Responsive Design at Untangle the Web on 29th July 2013
Upcoming SlideShare
Loading in...5
×

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

1,004

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: http://mobile.smashingmagazine.com/2013/06/18/adapting-to-a-responsive-design-case-study/ about cyber-duck.co.uk's responsive re-design.

Published in: Design, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,004
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "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 http://bondartscience.com/
  11. 11. Setting goals for a RWD...
  12. 12. 1. Content Parity Credit: http://wtfmobileweb.com/ 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: http://futurefriend.ly/ Cut down on maintenance and support known unknowns #ffly
  15. 15. 4. Accessibility Credit: http://futurefriend.ly/ 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. http://xkcd.com/773/
  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: http://www.guypo.com/mobile/what-are-responsive-websites-made-of/
  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. http://zurb.com/article/883/small-painful-buttons-why-social-media-bu
  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. https://github.com/Cyber-Duck/hoisin.scss 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 http://alistapart.com/article/dao
  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? http://art.com/artgallery/default.asp? 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
  1. A particular slide catching your eye?

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

×