Planting the responsive seed

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.

276c149f793de9af4e98991ed52ff874?s=128

Patrick Hamann

June 26, 2013
Tweet

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!