Pragmatic responsive design
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Pragmatic responsive design

  • 216,102 views
Uploaded on

Presented by Stephanie Rieger in Nashville for Breaking Development 2011

Presented by Stephanie Rieger in Nashville for Breaking Development 2011

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
216,102
On Slideshare
143,025
From Embeds
73,077
Number of Embeds
187

Actions

Shares
Downloads
4,403
Comments
17
Likes
618

Embeds 73,077

http://www.adinteractive.co 22,237
http://t3n.de 15,051
http://mobizen.pe.kr 8,722
http://www.labnol.org 7,424
http://www.mobizen.pe.kr 4,364
http://axbom.se 3,333
http://xguru.net 2,015
http://techmaster.vn 1,475
http://adactio.com 1,131
http://www.hanrss.com 955
http://paper.li 746
http://www.oemedia.de 339
http://lanyrd.com 304
http://fort3design.blogspot.com 263
http://localhost 249
http://www.usercentered.de 240
https://twitter.com 229
http://feeds.feedburner.com 215
http://mlearnproject.wordpress.com 208
http://www.uxabilidad.com 207
http://toolbox-4-websites.com 171
http://www.rdbooth.com 168
http://logmob.wordpress.com 157
http://christianwierz.tumblr.com 152
http://storify.com 135
http://www.scoop.it 123
http://www.patrickdornbusch.de 113
http://rogerwilco.com.au 107
http://a0.twimg.com 107
http://learningecomputerscience.blogspot.in 102
http://us-w1.rockmelt.com 101
http://oemedia.de 92
http://twitter.com 87
http://www.uxgeek.co 79
http://www.macromedios.net 78
http://www.thietkewebsitecaocap.vn 78
http://abcedu.drupalgardens.com 72
http://twb01.blogspot.com 55
http://glimpsegaze.posterous.com 54
http://www.arnaldoroman.net 54
http://thietkewebsitecaocap.vn 47
http://viscom.flayler.com 43
http://philoye-macpro.local 43
http://rascasse.com 41
http://www.twylah.com 41
http://2105.tumblr.com 40
http://gw.datahouse.co.kr 38
http://blog.websourcing.fr 37
http://www.guideshelf.com 34
http://www.patches-online.de 34

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. pragmaticresponsive design making the best of old and new techniques http://www.flickr.com/photos/dwonderwall/3341419492
  • 2. This presentation is...• part case study• part lessons learned• part future-thinking
  • 3. THE CASE STUDY sadly no longer online as of February 2013 :-( browser.nokia.com A small campaign site introducing three new web browsers for Nokia devices.
  • 4. Chrome Opera Mini Nokia N97iPad
  • 5. THE CASE STUDY Site goals: • Inform end-users and industry • Prompt end-users to update their browser • Experiment with responsive design to support a global audience and wide range of target devices. Call to action: Update your browser!
  • 6. 70+ target Nokia devicesSymbian^3/Anna/MeeGo Series 60 Series 40Touch (+ many w/ keyboards) Touch and non-touch Touch and non-touch2008-present 2006-present (S60 3rd FP 1/2) 2008-present (~S40 6th Edition)WebKit browser WebKit browser WebKit browser or11 devices 45 devices Nokia proxy browser 23 devices new browser being promoted
  • 7. + all the usual suspectsmany Nokia users on S40 featurephones still use Opera Mini v 6.0+ mobile v. 7+ desktop
  • 8. initially no support was planned for legacy and/or XHTML-MP browsers < v 5.0 Obigo Windows Mobile Nokia S40 Lite Browser Internet BrowserUC Web popular Chinese proxy browser
  • 9. Part 1: The design process http://www.flickr.com/photos/jordanfischer/63832583
  • 10. You can’t get there from hereDesigning only pixel perfect mock-ups makes itdifficult near-impossible to then think responsively.
  • 11. an emerging process etc...sketches/IA basic visual “live” more “live” mockups responsive sketches responsive mockup mockup no ok? “live” responsive small visual mockups yes mockup to “reality check” to discuss specific performance and stylistic issues progressive enhancement
  • 12. message/ copy copy content first draft 1 draft 2 brand/ strategy etc...sketches/IA basic visual “live” more “live” mockups responsive sketches responsive mockup mockup no ok? “live” responsive small visual mockups yes mockup to “reality check” to discuss specific performance and stylistic issues progressive enhancement
  • 13. If it’s layout prototype it.(...on real devices to clarify changes in context and theimpact of native capabilities and viewport conditions)If it’s visual design mock it up(...but then prototype to determine performance, impactof native fonts and em values, viewport conditions etc.)
  • 14. PAIN POINT Too many to mention. Mental models in particular are getting in the way. We (our teams, our clients, their marketing departments etc.) still presume and expect we can control too much.
  • 15. We have lots of counterproductivebehaviours we need to unlearn.• Creating elaborate workarounds to suit (what you perceive) as edge case screen sizes or devices.• Agonising over small differences in rendering and alignment (remember...each device you haven’t tested on will have its own quirks.)• Creating elaborate reference lists of screen sizes, pixel densities in the belief that with enough data you can design for each device.etc...
  • 16. Part 2: The CSS strategy http://www.flickr.com/photos/wscullin/3770015203
  • 17. TECHNIQUE Mobile first Design for (the simplest) mobile browser first. the fact that it may be mobile doesn’t really maer...
  • 18. “The absence of a media queryis in fact, the first media query.Bryan Rieger, Rethinking the Mobile Web
  • 19. begin with a lightweight defaultA fully flexible with defaultB styles for navigation, fonts, key word here content and not defined is ‘defined’...seeC slide 26 through media queries
  • 20. TECHNIQUE Embrace the cascade Don’t merely swap style sheets...let it cascade. This results in smaller subsequent style sheets, less duplication in declarations and is more efficient for the browser to parse (as it’s only dealing with deltas).
  • 21. each style sheet augments the others breakpoint breakpoint style sheet 1 augment original A A B style sheet with B C (only) the style C changes that are needed to enhance the layout < xx px wide xx px to xxx px (or unable tounderstand further instructions)
  • 22. each style sheet augments the others breakpoint breakpoint breakpoint style sheet 1 style sheet 2 A C A A B B augment B C once again for C TVs etc. < xx px wide xx px to xxx px >xxx px wide (or unable tounderstand further instructions)
  • 23. TECHNIQUE Use major and minor breakpoints Create media queries inside of media queries.
  • 24. content or component-specific tweaksWhy we call them major and minor breakpoints major layout changes
  • 25. a common approach One style sheet with media queries on the inside. styles.css @media {(min-width: 320px) } 1 css file = 1 hp request, @media { but includes unnecessary(min-width: 480px) style data that all devices } end up downloading @media {(min-width: 640px) } @media {(min-width: 768px) }
  • 26. a more robust option Multiple style sheets with media queries on the inside.MAJORBREAKPOINTS @ @IN DOCUMENT 320px 720pxHEAD basic.css enhanced.css enhanced+.cssMINOR (typically) @media { @media {BREAKPOINTS no media (min-width: 480px) (min-width: 768px)WITHIN EACH queries } }STYLE SHEET @media { but feel free to (min-width: 640px) include some if you } feel they can enhance the experience and are sure (!) they will graciously degrade on older browsers
  • 27. MAJOR BREAKPOINTS IN DOCUMENT HEAD<link rel="stylesheet" type="text/css" href="stylesheets/basis.css"media="screen, handheld" /><link rel="stylesheet" type="text/css" href="stylesheets/enhanced.css"media="only screen and (min-width: 320px)" /><link rel="stylesheet" type="text/css" href="stylesheets/enhanced+.css"media="only screen and (min-width: 720px)" />MINOR BREAKPOINTS AS NEEDED WITHIN EACH STYLE SHEET@media screen and (min-width: 640px) { section ul li { width: 20%; }}
  • 28. don’t multiple style sheetscause multiple http requests? (which will affect performance)
  • 29. Yes!...but (as we will see) we havebigger issues...
  • 30. but it’s just “one line of code” = 84Kb, ~10 http requests (or 1.340 Seconds) I’m wondering if he ran this test on a Facebook Like PC with broadband? ButtonSource: Matthew Ogborne, Facebook Like Button = 84Kb or 1.340 Seconds?More great examples on Steve Souders’ P3PC project site
  • 31. 3rd party requests don’t just include widgets,they can also include:• ads• analytics• utilities (comment utilities, font hosting etc.)• libraries and polyfillsMany of these services are not yet mobile friendly.(And many that claim they are, merely support certain mobile browsers.They may not necessarily be lightweight or conscious of performance).
  • 32. everything has dependencies Otherwise known as everyone has ‘partners’Source: Luma Partners
  • 33. Example: 1 line of code spawns 49 server calls (including 21 redirects) “What happens next is the scary part: You effectively lose all control.” - Web Performance Today, Fourth Party Calls
  • 34. ConclusionEach http request should add value!If a few well chosen http requests enable youto improve the experience-go for it.(then take a long hard look at other requests that may be lurking)
  • 35. TECHNIQUE choosing breakpoints
  • 36. DisclaimerThere is no “perfect set” of breakpoints.Set your breakpoints based on the needs of your layoutand (the legibility, weight and nature of) your content.Cross-check these choices on your key devices.(...80% of traffic in your analytics will often come from 20% of devices...seems ashame not to ensure the site looks and works especially well on these devices).
  • 37. major breakpointsmajor layout changes Major Breakpoint 1 Major Breakpoint 2 (media query in document head) (media query in document head) Major Breakpoint 3 (media query in document head) 1024 320 px to 720 px wide 720 px to 1024 px 320 720 < 320 px wide and/or unable to nothing isunderstand further here...but some tablets instructions that’s ok! most NetBooks iPhone (P) many Desktops many Android (P) many BlackBerry S60 QWERTY Most S60 (L) (P) = Portrait S40 QWERTY (L) = Landscape (L*) = Landscape w/ native viewport adaptation
  • 38. minor breakpointscontent-related tweaks Major Breakpoint 1 Major Breakpoint 2 (media query in document head) (media query in document head) Major Breakpoint 3 (media query in document head) Minor Minor Minor Breakpoint Breakpoint Breakpoint (@media) (@media) (@media) TVs 645 732 1024 320 px to 720 px wide 720 px to 1024 px body copy is 320 720 < 320 px wide too large and/or unable to nothing isunderstand further here...but change in some tablets instructions adjust line that’s ok! image most NetBooks iPhone (P) length alignment many Desktops many Android (P) many BlackBerry S60 QWERTY Most S60 (L) (P) = Portrait S40 QWERTY (L) = Landscape (L*) = Landscape w/ native viewport adaptation
  • 39. minor breakpointskey-device-related tweaks Major Breakpoint 1 Major Breakpoint 2 (media query in document head) (media query in document head) Major Breakpoint 3 Minor (media query in document head) Breakpoint Minor Breakpoint (@media) for small devices Minor Minor Minor w/media query Breakpoint Breakpoint Breakpoint support (@media) (@media) (@media) 360 480 645 732 1024 320 px to 720 px wide 720 px to 1024 px 320 720 < 320 px wide target and/or unable to target device: nothing isunderstand further device: Symbian here...but change in Symbian some tablets instructions touch (L) adjust line that’s ok! image touch (P) most NetBooks iPhone (P) length alignment many Desktops some Android (P) many Android (P) many S40 (P) many BlackBerry most S60 (P) S60 QWERTY Most S60 (L) (P) = Portrait S40 QWERTY (L) = Landscape (L*) = Landscape w/ native viewport adaptation
  • 40. OMG... ” http://www.flickr.com/photos/richardmoross/1413692087
  • 41. Existential question of the day:Does it make sense to create a breakpointif there is no known device with thatscreen size?(...or put more bluntly is it worth setting a breakpointjust so stuff looks pretty when you resize yourdesktop browser?)
  • 42. Follow-up question:Does it therefore make sense to create abreakpoint just because there IS a knowndevice with that screen size?
  • 43. Answer: Yes, and yes...• Be pragmatic. If content looks ‘wrong’ at a given screen size on the desktop, fix it (there’s probably a device out there that will match those conditions).• Anticipate problems. Leave breathing space and don’t micro-manage the layout.• If the layout keeps breaking during testing, that’s a sign that your tolerance for diversity may be too low...consider changing the design!
  • 44. examplereal-world major and minor breakpointsprimarily content-focussed but with a pragmaticeye on our project’s target devices
  • 45. major breakpointsDefault Major Breakpoint 1No media query 321 - 720 px Major Breakpoint 2 721 px onwards
  • 46. major breakpoints background image omitted to layout is primarily reduce page centered and now includes weight and background image reduce risk on older devicesDefault Major Breakpoint 1No media query 321 - 720 px ‘desktop’ layout including floats Major Breakpoint 2 721 px onwards
  • 47. Note: Screenshotstaken on a Mac for minordemonstrationpurposes. breakpoints Minor Breakpoint @360 px (cross-checked for Nokia touch) Minor Breakpoint @480 px (cross-checked for Nokia touch) Minor Breakpoint @768 px (cross-checked for iPad)
  • 48. Minor BreakpointNote: Screenshots @360 px (cross-checked for Nokia touch)taken on a Mac for 50% 50%demonstrationpurposes. background 45% aligned bottom 70% 30% background aligned top Minor Breakpoint 50% @480 px (cross-checked for Nokia touch) 55% 45% custom Nokia font 3em line background x-position height adjustment Minor Breakpoint 30% @768 px (cross-checked for iPad)
  • 49. alignment (top/bottom) and x-position adjusted to suit the content (image) and context (screen size) image slides up and down revealing more (or less) of the content responsive divider implemented using border-image (degrades gracefully on all but IE)Component adapts to suit differing browser environmentse.g. slight differences in layout caused by different viewport implementations,differing baseline em values, wider/narrower native fonts, padding andmargin variations etc.
  • 50. ...but rememberMedia queries are wonderfully versatile but screensize is only one factor to consider.Screen size rarely aligns with browser (or device)capabilities.
  • 51. PAIN POINT when queried, these devices will all return a 320 pixel wide viewport value but each have vastly different browsers • good CSS and • strong CSS and • very basic CSS JavaScript JavaScript support and JavaScript • no touch screen • no touch screen but using proxy • advanced CSS • early WebKit browser such as and JavaScript • XHTML MP Opera Mini • touch events • modern WebKit
  • 52. Responsive design will only get you half way.Always pair responsive design with a feature detectionand adaptation strategy.
  • 53. STEP 1 Media queries detect screen size and servesize-appropriate layouts and basic behaviours appropriately layout sized backgrounds basic look basic and feel functionality
  • 54. STEP 1 STEP 2 Media queries detect Feature detection screen size and serve clarifies actual browsersize-appropriate layouts capabilities and enables and basic behaviours further enhancements + appropriately enhanced look functionality layout sized and feel enhancements backgrounds someday we’ll (even) more (hopefully) be appropriate basic look basic able to detect graphics or and feel functionality other useful media formats stuff like (e.g. SVG) bandwidth
  • 55. TIP The more (accurate) information you can detect, the more intelligently you can adapt. Client-side feature detection is only one of the tools you can use. Others include device databases, user agent strings and your own (domain and region-specific) tacit knowledge.
  • 56. TIP Why should we need our own tacit knowledge when we can detect browser capabilities using JavaScript or libraries such as Modernizr? Because ‘support’ is rarely a binary thing. Also....some browsers lie.
  • 57. TIP More information about feature detection, can be found in Bryan’s Breaking Development presentation: Adaptation
  • 58. Part 3: responsive content & media http://www.flickr.com/photos/mrs_logic/4548681436
  • 59. “Optimize front-end performance first,thats where 80% or more of the end-userresponse time is spent.— Yahoo: The importance of front-end performance
  • 60. “ Optimize front-end performance first, thats where 80% or more of the end-user response time is spent. — Yahoo: The importance of front-end performance This was written with the desktop in mind... research suggests performance impact on mobile is closer to 97%.Web Performance Today: 97% of mobile end-user response time happens on the client
  • 61. and yet...
  • 62. most responsive image techniquesare primarily client-side fetching new images = extra hp requests and latency 2. request new image 1. detect 3. done! we screen have the size right image
  • 63. often imposinga heavy burden onconstrained devices 3. adapt markup fetching new images = extra hp requests and latency 4. request new image 2. spider the DOM 5. repaint, reflow as needed 1. detect screen size 6. done! we have the right image
  • 64. TECHNIQUE Serving more appropriate* images to constrained devices A pragmatic approach using both server and client. *the nature of an “appropriate image” is complicated. To better understand the problem, and what standards bodies are hoping to do to solve it, we recommend reading A framework for discussing responsive images by Jason Grigsby
  • 65. heavy-liftingSTRATEGY server determine basic device capabilities then choose/adapt and conditionally load most http://domain.org appropriate mark-up... delivery server-side pre-processing delivers the most appropriate markup, images and scripts on initial load just-in-time tweaks clarifies device capabilities (using feature detection) and adapts on the client fly as needed (e.g. on reorientation, new data, dynamic components)
  • 66. to determine necessaryproperties such asscreen size UA string device database to identify device and therefore, screen size see Bryan’s AdaptationHEAVY LIFTING presentation for greater device request detail on this technique
  • 67. to determine necessaryproperties such asscreen size UA string to override the occasional property device based on real-world or project-specific database to identify device tacit data knowledge and therefore, screen size see Bryan’s AdaptationHEAVY LIFTING presentation for greater device request detail on this technique
  • 68. to determine necessaryproperties such asscreen size UA string to override the occasional property device based on real-world or project-specific database to identify device tacit data knowledge and therefore, screen size data application video logic generate final cookie markup images see Bryan’s AdaptationHEAVY LIFTING presentation for greater detail on this technique
  • 69. final markup cookie containing resource bundle device profile containing references needed for future client-side tweaks device gets the most appropriate images on first load (in most cases) no additional client-side processing is requiredDELIVERY
  • 70. client-sideTWEAKSon as-needed basis on orientation change
  • 71. images etc.client-side new media is only fetched ifTWEAKS actually needed updated device profile cookie senton as-needed basis back to server JavaScript swaps images/media on orientation change @media changes layout and other styles
  • 72. BONUS uses onResize event (because onOrientation change doesn’t work on all devices) JavaScript also swaps images when screen is resized. This enables you to test adaptation on desktop browsers!
  • 73. Demo...
  • 74. TIP This technique isn’t just good for images... you can use it to implement other useful (progressive) enhancements. These include specifying: • more appropriate image formats (e.g. SVG) • mobile-friendly alternates for 3rd party widgets • alternative functional components (e.g. form elements) • alternate content representations (e.g. visual alternatives to complex tabular data)
  • 75. EXAMPLE A simple content enhancement “One Web” is a great ideal, but sometimes, adding or removing content based on device/user context can dramatically improve the experience.
  • 76. Scenario:Provide each user with customized downloadinstructions based on detection of their browser version.Benefits:• increases likelihood of a download• reduces the amount of stuff users need to read/ understand
  • 77. UA string determine device platform (e.g. S60 3rd Edition) device database determine device platform determine device model (in cases where UA string (e.g. Nokia N8-00) doesn’t provide it) so we can do this... choose appropriate device- specific message (populated with device model number) generate final enhance existing content with markup device-specific messageNote: Content was merely enhanced(not swapped entirely) as we expectedcertain people would visit the site fromone device (e.g. a PC) but need to reviewdownload instructions for another
  • 78. Server-side adaptation pain points• reliance on cookies• reliance on external data• say good-bye to the intelligent default• CDNs anyone?
  • 79. PAIN POINT Reliance on cookies • what happens if cookies are disabled? • what do we do about the EU Cookie Directive?
  • 80. PAIN POINT What about unknown devices? • what happens to new devices that are not yet in a device database or your collection of tacit knowledge? (...the reality is, no method is perfect, combining server-side and client-side detection helps plug the gaps)
  • 81. TIP - don’t panic an 80/20 approach will get you quite far • on many site, 80% of traffic seems to come from about 20% of devices • of the other 20%, most are known devices • regularly reviewing your logs can help catch whatever is left
  • 82. PAIN POINT Say goodbye to the ‘intelligent default’ • how do we create intelligent default content or behaviours when there is no longer a ‘normal/ average/typical’ screen size or even a ‘typical’ device?
  • 83. mobile first? <something-or-other> just-in-timedesktop first?
  • 84. PAIN POINT CDNs anyone? • CDNs currently couldn’t care less about changes in device context. A URL is presumed to represent a single, cacheable resource. • Will aggressive caching turn into a problem? (Would we even have created CDNs, or have designed them quite differently if content had been variable, based on device context from the very start?)
  • 85. Part 4: design workflows http://www.flickr.com/photos/jurvetson/5201796697
  • 86. Some key goals when designing multi-context image-sets• visual consistency in the given context• message clarity & thematic consistency across contexts• appropriate image weight for each context
  • 87. visual consistency (in the given context) not so much here alignment of graphical elements maers here
  • 88. message clarity & thematic consistencyacross contexts largest larger small
  • 89. we began witha “normal” workflow
  • 90. each graphic designed in one context
  • 91. Adobe Fireworks enables you to design and export different sizes from one single artboard but rapidly switched toa more context-sensitive approach approach
  • 92. Benefits Designing graphics together provides a more global and contextual view. • Helped eliminate alignment errors, continuity issues etc. • Helped maintain thematic consistency. Images don’t have to be identical but the overall message should not be lost. • Tip: Don’t forget that you can also vary file types (e.g. PNG, JPG) to increase performance at certain sizes.
  • 93. PAIN POINT It’s still not flexible enough... Graphical design tools enabling the use of variables, conditionals etc. would be really nice right about now.
  • 94. Part 5: embrace opportunities http://www.flickr.com/photos/ganesha_isis/4439563089
  • 95. We realised half way through the project thatwith only minor changes, we could supportanother 80-100 Nokia feature phones.Many of these older, low-end devices would also beeligible to update to the new (proxy-based) NokiaBrowser for mobile phones.
  • 96. UA string Goal: get information out device database to more people determine device platform everyone older S40 else devices change doctype from no change required HTML5 to XHTML MP to mobile firstresponsive approach serve a lightweight CSS MP style sheet generate final generate final markup markup
  • 97. Reminder User agent strings are not evil. User agent strings can be incredibly useful so long as you understand their limitations and use them to enhance rather than exclude.
  • 98. So how did it go?
  • 99. So how did it go?Within five days of our (soft) launch...
  • 100. the site had been visited by people from133 countries
  • 101. on 51 different Nokia devices(and of course many non- Nokia devices)
  • 102. oldest smallest Nokia N70 Nokia 1680 XHTML MP XHTML MP 176 x 208 px 128 x 160 px 2005 2008 3 of these users including the odd were in the US! unexpected ones
  • 103. So far...the most popular page(just behind the home page) is the page withinstructions to update your browser :-)
  • 104. a few final words...http://www.flickr.com/photos/dwonderwall/3341419492
  • 105. on being pragmatic Perform a cost-benefit analysis for every technique you use.
  • 106. on being pragmatic Old doesn’t mean bad and new doesn’t mean good. If a technique does more good than bad it’s fair game. (Until a significantly better one comes along.)
  • 107. on being pragmatic ...develop your mobile strategy but in the meantime...there are useful things you can do today
  • 108. STEP 1 STEP 2 STEP 3Review your traffic Test your site on those Develop an action planlogs and determine devices and determine to address common issueswhat mobile devices where the experience such as these:are accessing your breaks downsite today • key content that is only accessible on hover • key controls that are too small to manipulate on touch screens • modal windows that become unusable on small screens • unnecessary http requests • unnecessarily heavy graphics and media repeat...
  • 109. @yiibu scontact uat hello@yiibu.com thank you many thanks to the amazing photographers on http://www.flickr.com/creativecommons/by-2.0 http://creativecommons.org/licenses/by/2.0 http://www.flickr.com/photos/tinou/453593446