The FT eb pp: Coding responsively Dr Robert Shilston - PowerPoint PPT Presentation

The FT  eb  pp: Coding responsively Dr Robert Shilston (rob@labs.ft.com) Director, FT Labs (@ftlabs)

Historical comparison 1880 1900 1920 1940 1960 1980 2000 2020

Ne  sprint  orks o ffl ine Fast start up Portable Clipping/saving Long battery life Can be read in the dark Can be read in bright sunlight Updates in real time Cheap Electronic delivery Ubiquity Search Bookmarking Personalisation Sharing Deep linking

‘Traditional’  eb  orks o ffl ine Fast start up Portable Clipping/saving Long battery life Can be read in the dark Can be read in bright sunlight Updates in real time Cheap Electronic delivery Ubiquity Search Bookmarking Personalisation Sharing Deep linking

 pps  orks o ffl ine Fast start up Portable Clipping/saving Long battery life Can be read in the dark Can be read in bright sunlight Updates in real time Cheap Electronic delivery Ubiquity Search Bookmarking Personalisation Sharing Deep linking

HTML5 is HTML5 is not a ‘mobile thing’ not a ‘mobile thing’. . It’s It’s not an alternative not an alternative to native to native apps. apps. It’s a It’s a  ay of making ay of making better better  ebsites ebsites. .

 elcome back to the elcome back to the  eb eb The FT  eb app provides a touch optimised user experience  ithout native code.

Sometimes it’s  hat hat  e’ve done e’ve done But  e’ve learned a lot, so to be honest sometimes it’s  hat hat  e e  ould do if ould do if  e did it e did it again. again.

 genda • Coding responsively – Layout and interactions – Connection state – OS • Development process – Branching and feature flags – Testing and deployment

But first, let’s consider:  hat is an app? hat is an app?

 hat is an ‘app’? • Built for a single platform • In an app store •  ritten in native code • Built for mobile • Designed for touch interactions NO TH  NKS

 hat an ‘app’ is to us: app (n). app (n). a distributed computer soft  are application designed for optimal use on specific screen sizes and  ith particular interface technologies ,

So let’s start:  hy code responsively? hy code responsively?

Ne  devices

Ho  an app might run Desktop Laptop Click Type Tablet Phone Move Touch In car screen  eroplane Speak Listen Games + TV console Point See Glasses Kiosk Think? Billboard  atch

Layout and interactions • Screen size – Not the same as resolution • Instant touch feedback • Click and mouse hover e ff ects • Keyboard shortcuts • Reading experience – Easier to read narro  columns – Paragraph leading and guttering

Fastclick • Speed up touch interactions • Eliminates 300ms lag <script src='fastclick.js'></script> window.addEventListener('load', function() { new FastClick(document.body); }, false);

Scroller

Flo  ed columns

Flo  ed columns

Reflo  ing

Resizing

Connection state Connection state Or  hy online and o ffl ine events should not be trusted to ans  er the question ‘are  e online?’

navigator.onLine  re you online if? – You’ve got  ifi signal? – You’ve got 3G signal? – If DNS resolves? If T  itter loads? –  ill my site? –  ill Facebook?

Q: If the value of navigator.onLine is true ,  hat does that mean?  : The device might be online.

For  hen there’s no connection •  ppCache – Essential for o ffl ine functionality – Just use it to bootstrap your app. • LocalStorage – Great for code and templates • Cookies – Shared  ith the server – Included in every request •  ebSQL / IndexedDB – Great for content

HTML5 ¡AppCache ¡for ¡ ini=al ¡page ¡load ¡ Splash ¡screen ¡ ¡ Beware. ¡ ¡AppCache ¡needs ¡ careful ¡handling. ¡ Basic ¡CSS ¡/ ¡Fonts ¡ Bootstrap ¡& ¡error ¡handling ¡ LocalStorage ¡for ¡code ¡ ¡ Main ¡app ¡code ¡ and ¡templates ¡ Main ¡CSS ¡& ¡HTML ¡templates ¡ Cookies ¡for ¡data ¡shared ¡ with ¡the ¡server ¡ Authen=ca=on ¡ Text ¡and ¡image ¡content ¡ WebSQL ¡/ ¡IndexedDB ¡for ¡ news ¡content ¡

Squeezing your bits • Devices tend to limit HTML5 storage • Storing images o ffl ine: Base64 encoded data-URIs + UTF-16 storage encoding = Ine ffi cient

 n image storage solution 1. Do  nload images as gzipped base64 2. Squeeze 2 ⅔ base64 characters into one UTF-16 character 3. Push that into the database 4. Reverse  hen rendering the page • Go to http://labs.ft.com/ to read more.

Tips for coping  ith the net  ork • Batching your requests • Prioritise requests – User requested content first –  nalytics last • Progress bars – Sho  feedback fast – Be pessimistic

One HTTP request! •  ggressive batching - collect requests asynchronously: api.add('getStory', {'path': '/1'}, callback1); api.add('getStory', {'path': '/2'}, callback2); api.send(callback3); api.add('analytics', params, callback4); api.send(callback5); • Callbacks per action and per group

Going native Going native

 cclimatised users •  ndroid – Back and Search buttons – Sharing: Intent.ACTION_SEND –  idgets – Background content do  nloading •  indo  s 8 – Sharing and Search charms – Home screen tile – Nav bar

Search on  ndroid

Search on  indo  s 8

Search on iPad

Search on iPhone

Native  rappers • Invoke same core online  eb site •  rapper to  eb communication – via HTML5 postMessage – JavaScript function calls

But  ith multiple devices, surely Managing the release process Managing the release process is hard?

The Old Days: Branches Feature ¡“Banana” ¡ Dev ¡ Feature ¡“Apple” ¡ Merge ¡ Test ¡ Merge ¡ Trunk ¡ Release ¡ to ¡live ¡

The alternative: Feature flags • Develop in one place • S  itch bits of code on and o ff if (Flags.get('WidgetEnabled’)) { ... } • Centralise those s  itches function get(flagname) { switch flagname: case 'WidgetEnabled': return isAndroid ... • Don’t associate multiple things to the same flag

Feature flags: Override for testing Screenshot of flag tool

Feature flags: Override for testing • Code example: function get(flagname) { flagoverrides = JSON.parse(localstorage.getItem('flags')); if (flagname in flagoverrides) { return flagoverrides[flagname]; } switch flagname: case 'AppleEnabled': return isAndroid ...

Feature flags 2.0 • Server-side decisions control client side behaviour – Enable  /B feature release – Deploy features to di ff erent platforms – Push flags to client • Share flags client and server side – Get feedback on  /B testing • Remember analytics!

Client-side code updates • The bootstrap code: – Runs  hat’s in localStorage –  sks the server if there’s a ne  version •  llo  beta users to get version first – Do  nloads it for use next time • Minimises  ppCache aggravation • Gives us complete control

Final points Final points

HTML5 sites can be HTML5 sites can be great great But building a good HTML5 But building a good HTML5 site is site is very hard very hard. .

Summary • Less separation , more adaptation – Fe  er, more adaptive  ebsites • Less native , more  eb • HTML5 is NOT just a mobile solution, but a  ay of making better  ebsites . • Responsiveness is not about multiple static designs, it's a multi-variable equation

Summary • appCache + localStorage + intelligent bootstrapping + good use of storage = reliable o ffl ine app • You don’t have to sacrifice features •  ith good optimisations you can get a great app experience

 e're trying to help • Your dev team can use our code – github.com/ftlabs •  e blog about techniques at labs.ft.com • Consultancy available • Talks at conferences like this one

“Don’t build “Don’t build native apps native apps, , build build  eb apps eb apps” -­‑ ¡Tim ¡Berners-­‑Lee ¡

Thanks rob@labs.ft.com @FTLabs Do you  ant to build this stu ff ? Join in. jobs@labs.ft.com Image ¡credits:: ¡ ¡ hOp://cdn3.worldcarfans.co/2008/2/medium/9080214.017.Mini1L.jpg, ¡ ¡hOp://www.netbasic.com/blog/2008/10/mini-­‑car-­‑parking-­‑fail, ¡hOp://runningstopsigns.files.wordpress.com/ 2011/04/smart-­‑car.jpg ¡ ¡