Tweet
Tweet

Slide 1

Slide 1 text

Planting the responsive seed Patrick Hamann Breaking Borders - June 2013 g

Slide 2

Slide 2 text

Who am I? • @patrickhamann • Client-side developer • CSS and performance geek g

Slide 3

Slide 3 text

Who I work for g

Slide 4

Slide 4 text

Making the next generation of the Guardian g

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

The problem g

Slide 7

Slide 7 text

Latest news, sport and comment from the Guardian | The Guardian Search http://www.guardian.co.uk g

Slide 8

Slide 8 text

g Code smells

Slide 9

Slide 9 text

15-30% of the Guardian traffic is mobile g Tablet 11% Mobile 21% Dektop 68% Dektop Mobile Tablet

Slide 10

Slide 10 text

A new device landscape http://www.flickr.com/photos/brad_frost/7387823392

Slide 11

Slide 11 text

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/

Slide 12

Slide 12 text

Benefits of Planting the seed g • Start with a clean slate • Content strategy • Mobile first • Future-friendly platform • Buy one get 4 free!

Slide 13

Slide 13 text

The solution g

Slide 14

Slide 14 text

What are we doing? g m. www.

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Some tech g Scala Play! RequireJS Sass AWS PhantomJS Selenium localStorage CORS Grunt NodeJS Web Fonts Bower Jasmine

Slide 17

Slide 17 text

Some tech g Content API http://www.guardian.co.uk/open-platform

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Cutting the mustard - modern browser test g

Slide 21

Slide 21 text

It’s about browsers not devices

Slide 22

Slide 22 text

HTML4 vs HTML5 g

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Your doing it wrong http://www.flickr.com/photos/wickedboy007/8999289788

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Responsive images g WTF?! No SRC attribute?

Slide 28

Slide 28 text

g https://speakerdeck.com/paulrobertlloyd/the-edge-of-the-web-redux

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Lazy load secondary content g Sharing Related content Comments Popular content

Slide 32

Slide 32 text

Anatomy of a module g .js .html + .scss +

Slide 33

Slide 33 text

AMD g

Slide 34

Slide 34 text

OOCSS - BEM flavored g http://bem.info/

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

User load time expectations g http://www.webperformancetoday.com/2013/03/27/top-ecommerce-sites-are-slower-than-they-were-last-year/

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Navigation timing API g

Slide 39

Slide 39 text

R.U.M - Desktop g

Slide 40

Slide 40 text

R.U.M - Mobile g

Slide 41

Slide 41 text

What we have learnt g

Slide 42

Slide 42 text

g Design is not a service, designers must sit in the team.

Slide 43

Slide 43 text

g When you can, design in the browser. At the least, decide in the browser.

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

g Every new feature must be justified. • Optimize an existing feature • Remove an existing feature • Don’t add the new feature

Slide 46

Slide 46 text

Thank you! @patrickhamann http://github.com/guardian/frontend Breaking Borders - June 2013 g We’re hiring!