Tuesday 4 October 2011

Over The Air 2011: The FT Web app - We've Got a Website for That

Andrew Betts, Assanka @triblondon

  • An app is:
    • responsive design
    • responsive to human interface (mouse, keyboard, touchscreen, TV remote, …)
  • The Daily app is now generating less than 50 tweets a day (and still going down)
    • Down from over 200
  • iPad web app also works on other devices
    • not just tablets – phones too
    • currently only accessibly on iPad
    • works on Android & QNX but not released yet
    • Android imminent, QNX a few months
  • server serves the same code to all devices
    • client does customisation and caches as much as it can
    • so can go offline and still access pages
  • FT web app
    • 8 months with 3 people
    • then additional 4 months with same people to get Android & Playbook

issues

  • flowed columns and flowing text around fixed elements
    • adobe webkit fork has great flow additions - but not available on devices
    • css3 template layouts – but again not supported
    • so have to measure content and cut it into positioned containers using Javascript
  • content balancing
    • always show a whole number of items across the width
    • done by classifying devices into four groups according to screen size
      • small, medium, large, large wide
  • podcast pages
    • want to keep playing audio even when move to another page
    • put audio player at the top of the DOM, so not altered
    • entire app is in a single page – just swap content in and out
  • swiping between sections
    • continuous carousel made out of three divs
    • middle one is always the current
    • outer ones are preloaded as required
    • implemented swipes using touch gestures
    • have to do your own gesture interpretation
      • distinguish between slow drags and flings

tools

  • playbook has remote web debugging
  • WeinRE can do similar, but can’t debug Javascript
  • TouchScroll allows you to keep headers fixed and snap to columns when swiping across
  • web debugging proxies (e.g. Charles)
  • use desktop for layout, but real device for interaction (swiping)

discoveries

  • people use native apps differently
    • they tap lightly and fast
    • the web browser waits for fast taps in case there’s a double tap to zoom
    • if you don’t want double tap to zoom
    • Assanka made fastclick

offline access

  • launching app offline
    • need to specify URLs in app manifest
    • if you change a single file, all of the manifest needs to be re-downloaded
    • store as little as possible
    • the more you store, the longer your app will take to launch
    • iOS manifest is buggy – you can get name conflicts with other webapps
      • so make sure you give your manifest a custom name
    • development is hell – things get cached the whole time
      • instead, add a comment that changes every minute (for dev)
      • still leaves you time to refresh a few times to check the cacheing
  • manifest is no good for editorial content
    • local storage is much faster than SQLite
    • so if you only access by key then use it
    • you need permission to store > 5Mb
    • strategy:
      • launch app from web, just store <= 5Mb and prompt to save to home screen
      • saved from home screen, immediately ask for 50Mb and never ask again
    • images downloaded from server as base64 encoded strings
      • can combine images into single requests
      • and can then gzip the whole thing
      • stored in local SQLite
      • rendered into DOM as a data: URI
      • base64 transfer also avoids operator image recompression!
  • analytics
    • can’t use Google analytics
    • log user actions into local DB
    • POST the log when requesting updated content
    • on the server, rewrite the log into an Apache format access log

unresolved issues

  • SSL security: no browser chrome, so no browser padlock
    • trusted, because we tell you…
  • Social media integration – OAuth in separate window doesn’t work
    • have to reload completely when return to app
  • offline adverts:
    • not technically hard, but ad server companies don’t know how to deal with them
    • can’t retract the ad
    • can’t measure clicks
    • can’t click through at all…
  • automated QA – selenium doesn’t really work
    • ended up using lots of people and lots of devices

platforms

  • Android is by far the poorest web environment when compared with iOS and QNX
    • mainly due to lack of hardware-accelerated CSS transitions
    • so FT have a native Android app which has a single native component – the gallery to enable swiping
    • the rest of the app is HTML/CSS/JS
  • QNX has a native app too, but only to have a home screen icon and to provide distribution

Q&A

  • upset Apple?
    • probably not – FT are specific market
  • differences between web app and native
    • web has more sections than native ever had
    • web app preloads content, so people swipe more often
    • as a result web app gets much more interaction
  • is not appearing in the app store an issue?
    • yes, but instead making tactical native apps
    • e.g. FT Top 100 Companies – tells users if you want the full edition, go to the web app

No comments: