Planting the responsive seed

The Guardian recently released a new mobile site on m.guardian.co.uk, but in fact it is the planting of a seed of a more ambitious project to replace the desktop website with a future-friendly, single domain responsive product. We will learn how we are using mobile-first responsive techniques and client-side technology to set the foundations of that future, what have we learnt along the way and how it will scale.

Transcript

1. Planting the responsive seed Patrick Hamann Breaking Borders - June 2013 g
2. Who am I? • @patrickhamann • Client-side developer • CSS and performance geek g
3. Who I work for g
4. Making the next generation of the Guardian g
5. What I’m going to cover today • Why we needed to go responsive • How we are doing it • What we have learnt along the way • Questions g
6. The problem g
7. Latest news, sport and comment from the Guardian | The Guardian Search http://www.guardian.co.uk g
8. g Code smells
9. 15-30% of the Guardian traffic is mobile g Tablet 11% Mobile 21% Dektop 68% Dektop Mobile Tablet
10. A new device landscape http://www.flickr.com/photos/brad_frost/7387823392
11. g Creating a separate mobile experience can actually be a blessing in disguise. It gives you time to re-evaluate, prioritize, strip down and focus on what’s really important. [...] this process eventually changes the way you think about your content, infrastructure, user experience and approach. Brad Frost Planting the seed for a responsive future - 2012 http://bradfrostweb.com/blog/mobile/planting-the-seed-for-a-responsive-future/
12. Benefits of Planting the seed g • Start with a clean slate • Content strategy • Mobile first • Future-friendly platform • Buy one get 4 free!
13. The solution g
14. What are we doing? g m. www.
15. How are we doing it? g • Build upon open software and API’s • Progressive enhancement • Detect features not devices • Modular decoupled systems • Performance by design • Build upon open software and API’s • Progressive enhancement • Detect features not devices • Modular decoupled systems • Performance by design
16. Some tech g Scala Play! RequireJS Sass AWS PhantomJS Selenium localStorage CORS Grunt NodeJS Web Fonts Bower Jasmine
17. Some tech g Content API http://www.guardian.co.uk/open-platform
18. How are we doing it? g • Build upon open software and API’s • Progressive enhancement • Detect features not devices • Modular decoupled systems • Performance by design
19. g As a web developer “cutting the mustard” provides me with an opportunity to wipe the client-side development slate clean and start afresh.. [...] The increasing popularity of mobile web browsing, and the availability of responsive web design has forced my team to refactor how we think a modern webpage should be built. Tom Maslen BBC News - 2012 http://responsivenews.co.uk/post/18948466399/cutting-the-mustard
20. Cutting the mustard - modern browser test g
21. It’s about browsers not devices
22. HTML4 vs HTML5 g
23. How are we doing it? g • Build upon open software and API’s • Progressive enhancement • Detect features not devices • Modular decoupled systems • Performance by design
24. Your doing it wrong http://www.flickr.com/photos/wickedboy007/8999289788
25. Web fonts g • Detect support • Fetch async • Base64 encoded • Batch all fonts as strings in one request • Cache in localStorage • Reduces HTTP requests • Mobile HTTP cache is unreliable
26. Responsive images g • Assume everyone is on a low connection • Remove from DOM • Detect connection • Assuming connection may be bad... • Demand load based on features
27. Responsive images g WTF?! No SRC attribute?
28. g https://speakerdeck.com/paulrobertlloyd/the-edge-of-the-web-redux
29. How are we doing it? g • Build upon open software and API’s • Progressive enhancement • Detect features not devices • Modular decoupled systems • Performance by design
30. Swimlaning g • Each section of the website is its own application and server • (fronts, articles, video, galleries, tag e.t.c) • Deploy individually • If one application fails, the rest continue unharmed • Enforce one blocking request for “core content” per page
31. Lazy load secondary content g Sharing Related content Comments Popular content
32. Anatomy of a module g .js .html + .scss +
33. AMD g
34. OOCSS - BEM flavored g http://bem.info/
35. How are we doing it? g • Build upon open software and API’s • Progressive enhancement • Detect features not devices • Modular decoupled systems • Performance by design
36. User load time expectations g http://www.webperformancetoday.com/2013/03/27/top-ecommerce-sites-are-slower-than-they-were-last-year/
37. Performance first g • Compress everything, even HTML (whitespace & gzip) • Caching • Far -future headers, max-age, invalidation • Latency is a big problem on mobile • CDN’s are one solution to this • Load only bare minimum (Images, CSS & JS) • R.U.M
38. Navigation timing API g
39. R.U.M - Desktop g
40. R.U.M - Mobile g
41. What we have learnt g
42. g Design is not a service, designers must sit in the team.
43. g When you can, design in the browser. At the least, decide in the browser.
44. g Testing is hard. • It is impossible to test on every device • Build up small core library (Android 2.3, iOS 4, Blackberry 9) • Focus on browsers
45. g Every new feature must be justified. • Optimize an existing feature • Remove an existing feature • Don’t add the new feature
46. Thank you! @patrickhamann http://github.com/guardian/frontend Breaking Borders - June 2013 g We’re hiring!