Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

The FT Web App: Coding Responsively

505 vues

Publié le

Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/XCerdb.

Rob Shilston discusses the need for coding responsively, not just designing responsively, along with the development process in place at Financial Times. Filmed at qconsf.com.

Rob Shilston is a director of the FT's Labs division, which works on experimental web technologies and produces products such as the FT web app. He is currently responsible for the technical delivery of the FT web app and its hosting infrastructure. Prior to FT Labs, Rob founded the web consulting firm Assanka, which was acquired by the FT in January 2012.

Publié dans : Technologie, Design
  • Soyez le premier à commenter

The FT Web App: Coding Responsively

  1. 1. The FT eb pp:Coding responsivelyDr Robert Shilston (rob@labs.ft.com)Director, FT Labs (@ftlabs)
  2. 2. Watch the video with slide synchronization on InfoQ.com! http://www.infoq.com/presentations /FT-Coding-Responsively InfoQ.com: News & Community Site• 750,000 unique visitors/month• Published in 4 languages (English, Chinese, Japanese and Brazilian Portuguese)• Post content from our QCon conferences• News 15-20 / week• Articles 3-4 / week• Presentations (videos) 12-15 / week• Interviews 2-3 / week• Books 1 / month
  3. 3. Presented at QCon San Francisco www.qconsf.comPurpose of QCon- to empower software development by facilitating the spread ofknowledge and innovationStrategy - practitioner-driven conference designed for YOU: influencers ofchange and innovation in your teams- speakers and topics driving the evolution and innovation- connecting and catalyzing the influencers and innovatorsHighlights- attended by more than 12,000 delegates since 2007- held in 9 cities worldwide
  4. 4. Historical comparison1880 1900 1920 1940 1960 1980 2000 2020
  5. 5. Nesprintorks offline Fast start upPortable Clipping/savingLong battery life Can be read in the darkCan be read in bright sunlight Updates in real timeCheap Electronic deliveryUbiquity SearchBookmarking PersonalisationSharing Deep linking
  6. 6. ‘Traditional’ eborks offline Fast start upPortable Clipping/savingLong battery life Can be read in the darkCan be read in bright sunlight Updates in real timeCheap Electronic deliveryUbiquity SearchBookmarking PersonalisationSharing Deep linking
  7. 7. ppsorks offline Fast start upPortable Clipping/savingLong battery life Can be read in the darkCan be read in bright sunlight Updates in real timeCheap Electronic deliveryUbiquity SearchBookmarking PersonalisationSharing Deep linking
  8. 8. HTML5 is not a ‘mobile thing’.It’s not an alternative to nativeapps.It’s a ay of making betterebsites.
  9. 9. elcome back to the ebThe FT eb app provides a touch optimised userexperience ithout native code.
  10. 10. Sometimes it’shat e’ve doneBut e’ve learned a lot, so to be honest sometimes it’shat e ould do if e did itagain.
  11. 11. genda•  Coding responsively –  Layout and interactions –  Connection state –  OS•  Development process –  Branching and feature flags –  Testing and deployment
  12. 12. But first, let’s consider:hat is an app?
  13. 13. 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
  14. 14. hat an ‘app’ is to us:app (n). a distributed computer softareapplication designed for optimal use on specificscreen sizes and ith particular interfacetechnologies,
  15. 15. So let’s start:hy code responsively?
  16. 16. Ho an app might run Desktop Laptop Click Type Tablet Phone Move Touch In car screen eroplane Speak Listen Games + TV Point Think? console Kiosk Billboard ???
  17. 17. Layout and interactions•  Screen size –  Not the same as resolution•  Instant touch feedback•  Click and mouse hover effects•  Keyboard shortcuts•  Reading experience –  Easier to read narro columns –  Paragraph leading and guttering
  18. 18. Floed columns
  19. 19. Floed columns
  20. 20. Scroller
  21. 21. Fastclick•  Speed up touch interactions•  Eliminates 300ms lag<script src=fastclick.js></script>window.addEventListener(load, function() { new FastClick(document.body);}, false);
  22. 22. Connection stateOr hy online and offline events shouldnot be trusted to anser the question ‘aree online?’
  23. 23. 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?
  24. 24. Q: If the value of navigator.onLine is true,hat does that mean?: The device might be online.
  25. 25. For hen there’s no connection•  ppCache –  Essential for offline 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
  26. 26. 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  
  27. 27. Squeezing your bits•  Devices tend to limit HTML5 storage•  Storing images offline: Base64 encoded data-URIs + UTF-16 storage encoding = Inefficient
  28. 28. n image storage solution1.  Donload images as gzipped base642.  Squeeze 2⅔ base64 characters into one UTF-16 character3.  Push that into the database4.  Reverse hen rendering the page•  Go to http://labs.ft.com/ to read more.
  29. 29. 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
  30. 30. 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
  31. 31. Going native
  32. 32. 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
  33. 33. Search on ndroid
  34. 34. Search on indos 8
  35. 35. Search on iPad
  36. 36. Search on iPhone
  37. 37. Native rappers•  Invoke same core online eb site•  rapper to eb communication –  via HTML5 postMessage –  JavaScript function calls
  38. 38. But ith multiple devices, surelyManaging the release process is hard?
  39. 39. The Old Days: Branches Feature  “Banana”   Dev   Feature  “Apple”   Merge   Test   Merge   Trunk   Release   to  live  
  40. 40. The alternative: Feature flags•  Develop in one place•  Sitch bits of code on and offif (Flags.get(WidgetEnabled’)) { ... }•  Centralise those sitchesfunction get(flagname) { switch flagname: case WidgetEnabled: return isAndroid ...•  Don’t associate multiple things to the same flag
  41. 41. Feature flags: Override for testingScreenshot of flag tool
  42. 42. 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 ...
  43. 43. Feature flags 2.0•  Server-side decisions control client side behaviour –  Enable /B feature release –  Deploy features to different platforms –  Push flags to client•  Share flags client and server side –  Get feedback on /B testing•  Remember analytics!
  44. 44. 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
  45. 45. Final points
  46. 46. HTML5 sites can be greatBut building a good HTML5site is very hard.
  47. 47. “The biggest mistake e made as acompany as betting too much onHTML5 as opposed to native,”“It just asn’t ready”
  48. 48. 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, its a multi-variable equation
  49. 49. Summary•  appCache + localStorage + intelligent bootstrapping + good use of storage = reliable offline app•  You don’t have to sacrifice features•  ith good optimisations you can get a great app experience
  50. 50. ere trying to help•  Your dev team can use our code –  github.com/ftlabs•  e blog about techniques at labs.ft.com•  Talks at conferences like this one
  51. 51. “Don’t build native apps, build eb apps” -­‐  Tim  Berners-­‐Lee  
  52. 52. Thanks rob@labs.ft.com @FTLabs Do you ant to build this stuff? Join in. jobs@labs.ft.comImage  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