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

Over The Air 2011: Crap! It doesn't quite look right!

Or… how I learned to stop worrying and set my web sites free

Lyza Danger Gardner, co-founder Cloud Four @lyzadanger

Crap! It doesn't look quite right, or, how I learned to stop worrying and set my mobile web sites free

View more presentations from Lyza Gardner

• Founder of Cloud Four in 2007
• Explicitly for mobile web
• Lyza was on the team that built the Obama app
• Went through the app and realised that there was nothing in the app that couldn’t be done with the web
• hautelook.com – high performance mobile web
• deschutes brewery – one web
  
  • uses geolocation to find where to buy the beer
• mobile web is hard and getting harder
  
  • and it’s not just phones any more…
  • car radios, televisions, …
• and there’s a whole stack every time (any of which can change)
• in the 1990s, took print ideas and applied them – pixel perfect
  
  • customers believed that we had control…
  • “could you move the logo a half pixel to the right?”
• no one can possibly know enough – devices are continually appearing and you still have to deal with the old stuff
• how do you deal with WYSIWYG for customers…?

mobilewood

• 10 highly experienced mobile developers
• working on where we wanted the mobile web to go
• built http://futurefriend.ly
• three pages, two images, no interactivity
• 100 man hours
• -> not scaleable!

testing is very hard

• Cloud Four helped set up a device laboratory in downtown Portland
• multiple operators, device manufacturers
• but even a well-stocked device library will not help

take heart!

• relinquish control over a few things we thought we had down pat

• four considerations:
  
  1. content like water
     
     • consider wireframes that demonstrate the flow and flex of content across a continuum of device and window sizes
     • design approach: like proportion – not pixel perfect
     • build functional mockups, so you can show (not tell)
     • it will be an iterative process
     • will not be an overnight change – it’s not a brochure, despite what we told you earlier
     • it’s often surprising how willing customers will be to adapt or modify their content APIs
     • try using textile or markdown in CMS
  2. essentials first
     
     • not just mobile – pare down to the essentials
     • not just about design – about process, performance, experience for every user
     • start serene and simple
  3. arm the weapons!
     
     • responsive web design
     • fluid media: 100% width images
     • fluid grids
     • use media queries to enhance (mobile first)
     • see also Responsive Images (by Scott Jehl)
     • Boston Globe is a showcase
     • it’s ok to leave unmanaged gutter in % widths
     • use Modernizr’s modular approach (don’t test everything)
       
       • but it’s not infallible
     • use server-side work:
       
       • reordering – moving navigation around
         
         • android devices are too buggy
       • reduction – smaller images
       • respect – your users: don’t download graphics if you don’t use them
     • user agent sniffing – it ain’t perfect, but it gets the job done
     • don’t be afraid to do some server-side optimization
     • optimise!
       
       • especially your htaccess or apache config
       • use YSlow
       • make sure you gzip everything you can (not just html)
       • cache manifests are a little tricky to deal with
     • Cloud Four images:
       
       • server side sizing using WURFL for major sizes
       • common images are then cached
       • then 100% fluid sizing
  4. draw the line
     
     • set expectations with your customers
     • explain how you don’t have control over everything
     • don’t be afraid to pull out egregious hacks!
     • be ready to fail gracefully
     • this isn’t religion!
• frameworks:
  
  • Lyza likes the columnal CSS framework
  • most complex projects end up rolling their own…
• iOS rotation
  
  • use -webkit-text-size-adjust:none;

Lyza is writing a book – Head First Mobile Web

MomoLondon: Mobile Web & Widgets

This was a great Mobile Monday London. Short, snappy presentations; an exciting and relevant topic with a real buzz going on; announcements that you heard here first; and really useful networking afterwards.

Many thanks to Dan, Alex, Jo & Helen!

GSMA One API

Kevin Smith — Vodafone

Kevin works closely with Dan Applequist.

Aim to produce network enabler APIs across mobile operators — charging, location, messaging, user profile, connection profile. They’re a network-level complement to OMTP BONDI, using a RESTful and lightweight web services system.

Major European & Asian operators all involved.

Have a reference implementation (beta) available at http://oneapi.aepona.com. Go try it out!

OMTP BONDI

Nick Allott — OMTP

I went to the OMTP BONDI codefest back in January (sorry, I ran out of time to blog about it). So I didn’t take many notes on this presentation.

OMTP is an organisation of mobile operators working together (who would have thought!), with manufacturers and system providers joining in the fun. They’re working on defining a javascript API through which a web runtime environment can access and interact with device-specific information.

So there’s a location API (compatible with the W3C spec as it goes), access to calendar and contacts, etc. Crucially, they’re actually building a reference implementation in order to figure out how the API should work. That way they can change their spec as they discover that it doesn’t quite work in real situations. The spec so far looks good — more details and the downloadable SDK at http://bondi.omtp.org.

The only problem is that the reference implementation is built on Pocket Internet Explorer. Great access to device information, but really hard to make a good-looking, functional widget using web standards…

They’ve got one demo widget so far:

• EMCC Gig Guide w/last.fm
  • location
  • cached feeds
  • syncing calendars

And here’s where to find the latest widgets: http://bondi.omtp.org/widget-gallery/

Ikivo Enrich

Samuel Sweet, VP Sales

T-Omnia widget solution launched November 2008 in Korea. Based on Samsung, Windows Mobile & Ikivo Enrich.

• SVG display engine (provided by Ikivo)
• Javascript w/device APIs & AJAX support
• Aiming to support HTML display engine later
• W3C widget spec

“Putting lipstick on a pig” for Windows Mobile!

SK Telecom have had 300% increase in shipments month on month since they’ve launched the new interface.

Importantly, the W3C Widget spec now allows SVG as an alternate rendering option for widgets. This means that the Ikivo widget engine can be W3C-compatible.

Announcement tonight: Ikivo will be supporting BONDI

Firefox Mobile

Christian Sejersen

Currently called Fennec but will be called Firefox when it gets released. It runs on the same codebase.

Some countries currently have more than 50% Firefox usage. Mozilla are starting to wonder what they should do when they get a monopoly…

Fennec for Windows Mobile coming out soon (April?); Symbian version started not so long ago.

Shows a demo of running Fennec on Nokia N810 (Maemo) — Fennec Alpha Walkthrough on Vimeo

Browser controls are off the edge of the page to the left and right. Just scroll that way to see them.

Firefox Addons can be made compatible with Fennec. 20 or 30 Addons are available after a month, with no promotion from Mozilla.

There is full API compatibility between mobile and desktop, so once they add location & camera access to mobile, these APIs are available from the desktop build too.

My thoughts

As per Bruce Lawson’s talk at the Betavine birthday party, the browser writers don’t see the difference between mobile and desktop. I agree with them that the APIs and browser can be very similar, but I still think there’s a difference in how you would design a service.

A mobile service needs to take one particular function and “polish the hell out of it” (as goes the recommendation for iPhone app design). A desktop web app still needs to be polished, but has more leeway in its design. There’s also the interaction styles: a mouse is not a finger is not a d-pad, and you need to make the interface appropriate for each of these styles. Sure some of this can be done with stylesheets, but when you’ve got less screen space you want to deprioritise certain content off the screen completely.

Panel session

Chaired by Dan Appelquist

• Francois Daoust (W3C)
• Graham Thomas (T-Mobile)
  • 8 years at Nokia on UI & UX
  • Also bringing games into market (Club Nokia)
  • Been at T-Mobile for 7 years, now Head of Multimedia
  • T-Mobile very active in mobile internet — have iPhone and G1
• Christian Sejersen (Mozilla)
• Kevin Smith (Vodafone)
• Brad Sipes (CTO, Ikivo)
• Nick Allott (OMTP)

T-Mobile widget roadmap — want to have develop once, run across all handsets. Enabling the long tail…

SVG helps to bridge the gap between different screen sizes — since scalable. But Brad sees it more to “make things fun”.

Q: How does BONDI fit in with other web runtime initiatives, like Adobe AIR or Mozilla Prism?

• CS: Prism currently in labs (local look & feel for web-based content). But don’t really have anything to say as Mozilla…
• NA: OMTP did due diligence and found 25 different ways of doing the same thing. Operators decided on a common standard and then broke it in 25 different ways…
• NA: 3 parts to standardisation
  1. APIs
  2. Display engine
  3. Security (one of the big problems for Java on mobile — see signed apps…)

Q: Sounds like lots of separate bits. Do they fit together?

• NA: Yes. At least all the people on this panel do… OMTP working with W3C. SVG long-established as rendering tech. OMTP location API is W3C compatible, and could use One API as implementation by getting location from http query.

Q: How do I make money out of writing a widget?

• GT: Key benefit of widgets — start using internet more, like iPhone & G1.
• KS: Earn £20K from Voda competition…?
• FD: sell the widget like the iPhone app store.

One advantage of interoperable widgets is that you can buy your widget from anywhere. You can have your own payment mechanism

• DA: Can we build interoperable application stores? Micropayments never really went anywhere with the web. Will we get there with widgets?
• FD: There were some standards about micropayments 10-15 years ago, but they werer never finished… Maybe it’s time to dust them off and complete them.

Q: What benefits do I get from a widget that I don’t get from HTML5? (Hugo from Google)

• FD: Widgets give you more context, but it’s just a wrapper.
• CS: A lot of the widget issues have come up because of security issues. But in essence it’s the same thing that needs to be solved across mobile and desktop.
• BS: Widgets give you local application feel that HTML5 isn’t aiming for initially. But HTML5 will converge in the longer term.
• NA: Some of the widget stuff has been created as a sticking plaster to avoid 15-20 different solutions while HTML5 gets itself ready.
• DA: BONDI allows HTML5 over https to take advantage of secured APIs.

Q: My question: widgets on the standby screen? What about battery life?

• GT: want them on the idle screen, with notification etc. Want eBay etc event-based dynamic.
• CS: Palm Pre will be fully web-based
• BS: T-Omnia has widget framework attached to button on the side of the phone. Can have lightweight widget framework on low-level phones that aren’t capable of running full HTML5 browser.
• NA: battery notification & event APIs planned for BONDI 1.1

Q: What sort of security model?

• NA: BONDI — consumer delegates trust to an entity. Doesn’t work to prompt the user for everything. Instead they should be able to trust Norton, Google, T-Mobile, etc.
• DA: using XML digital certificates within the widget

Q: If you had one widget, what would it be and how would you interact?

• BS: weather. would beep at me if thunderstorm coming in.
• KS: widget that tells me if my 8 year old daughter has turned off her light…
• CS: can I have a browser instead?
• FD: tells me which way I should vote on W3C…
• GT: M25 road traffic info
• NA: a widget that syncs my contacts
• DA: location-based ski conditions. What’s important is that the bar is lowered. I want my mom to write widgets!

Q: Have Palm come up with a way to make webapps feel like native apps? (Hugo, Google)

• CS: Mozilla often have discussions about how to make the browser look native. But people don’t care. They want Facebook to look like Facebook, not a T-Mobile application.

Q: What do operators feel about making widgets more available? (David Stone)

• GH: Shortly launching service with idle screen. Demo on idle screen. Gallery also available.

OverTheAir: Google Gears for Mobile -- Andrei Popescu (Google)

Currently running on Windows Mobile as an ActiveX control. Just launched Picasa Web Album for Mobile with Gears. Works in IE 6 & 7, IE Mobile 5 & 6, Firefox 1 & 2 (3 coming soon). Firefox plugin works on Mac. Safari support being worked on. The Mobile version has the same API as the desktop version. Google have also announced that they are porting Gears to Android (no surprise there…) — this will be a Netscape standard plugin, so will probably come to WebKit at a similar time.

Gears is a browser plugin that provides additional APIs to the browser (local storage in a SQLite database, worker threads, local server for server data offline). See http://code.google.com/apis/gears/ for documentation and samples.

Mobile version also provides a Desktop API, which allows creating an icon shortcut to the app. Can provide multiple resolution icons.

Worker threads cannot access the DOM and the window object, so Gears also provides HttpRequest and Timer APIs for them.

Security: Gears will ask the user if a URL wants to store and access information locally. Thereafter that URL is allowed to use Gears to access data from the same origin (scheme, host, port).