Re: Ringmark, Core Mobile, and the Financial Times

Hi Robert,

That's awesome input. Thanks.

On 6/10/12 11:03 PM, "Robert Shilston" <robert.shilston@ft.com> wrote:

>Dear all,
>
>I've been holding off from posting to the list whilst I've been getting a
>sense of the attitudes of existing members.  However, the discussions
>have been relatively quiet so I thought I'd contribute my thoughts ahead
>of the face to face meeting.  To put these in context, let me introduce
>myself.  I'm the engineering manager of the Financial Times' web app, and
>founder of Assanka which was acquired by the FT to form FT Labs.
>
>In short, one of our challenges is to assess the amount of work needed to
>be done to for app.ft.com to support an arbitrary new device.  What we've
>found with many new devices is that the features we need might be
>present, just not behave very well.  So, just as Jet from Mozilla said a
>couple of weeks ago, the browser may claim to support wordBreak, but it
>not actually work.  Examples we've seen of this are, in my mind, closer
>to browser or hardware bugs than whether something's supported.  Here's a
>few:
>
>1) webkit animations running at just a couple of frames per second
>(Android Browser)
>2) local storage quota errors erratically firing (Windows 8)
>3) application cache manifest not being re-verified (iOS)
>4) CSS font family fall back list not being used during the loading of an
>@fontface custom font (PlayBook)
>
>I've given an examples above of issues across a range of different
>browsers.  I definitely don't think there's any value in pointing blame
>or comparing one browser as being significantly better or worse than
>others in this topic area - each of these bugs are things that would be
>very challenging to detect in JavaScript, yet cause us great amounts of
>effort to diagnose and work around.
>
>So, what I'm getting to is how should Ringmark assess these issues, or
>how should the group work to improve the ability for everyone to build
>web apps.
>
>I can hypothesise a comprehensive set of tests which would all verify
>functionality that's required for app.ft.com such that our supported
>devices would pass all tests, yet still behave very poorly because of
>implementation bugs.  I don't have a good answer for this, yet it's a big
>pain point for developers starting work on HTML5 mobile projects.

Agreed. Quality of implementation issues are both an extremely important
problem AND a tough one to measure, test and solve.

>Moving beyond browser bugs, then I think the features we'd like to be
>widely available, to enable both better web apps and faster adoption by
>new developers, would be:
>
>1) UI for managing local storage / local database quotas.  The quota
>management API indicates how this might be managed from a code point of
>view, but I'm not aware of a consistent interface or nomenclature used by
>browsers to empower users to manage their control over individual
>applications.

The problem with this is that UI-related features fall out of spec-land
because that's how browsers differentiate. As you noticed, the Quota
Management API, purposely avoids anything UI related. You won't get
consistency here, nor would that be really desirable for innovation.

The problem here is complex. On one hand, developers need a feel for the
device's UI, so that they can explain to the user what's going on. On the
other, different devices will have different constraints and will react
differently to the same quota request. E.g. a device with a lot of storage
might not prompt the user until you request a lot of data (there's is no
normative value for quota in the HTML5 spec), a smart device might
magically allow more data to sites you visit often or that you bookmarked,
another one might have deals with specific app providers and grant them
more storage before prompting. Etc.

>2) Ability to create home screen / chrome-less web apps without needing
>native wrappers.  A combination of
>https://people.mozilla.com/~anarayanan/webapps.html and the Fullscreen
>API will help this.

Absolutely. Both of those are in the scope of the coremob level 1 spec.
See the [AppConfig] and [FullScreen] Wiki pages.

>3) Ability to list and delete local databases:  At the moment, our app
>asks for a 5MB database by default (which browsers instantly grant
>without user-consent).  However, we can't then request it be increased to
>50MB (the largest limit on iOS).  Instead, we either have to ask the user
>to approve multiple intermediary steps, or request a large quota on a new
>database.  Once we're in this 'big database' mode, we then have a 5MB
>orphaned database that we'd like to delete, but currently have no ability
>to do so.

That's a WebSQL issue. WebSQL has been abandoned in favor of IndexedDB
which doesn't share the same limitations (you no longer have to specify
the size of your DB upon creation). [IndexedDB] is also in scope scope for
level 1.

>4) Ability to schedule background tasks:  Workers and SysApps may help
>achieve this.

It might be useful to start collecting use cases for this. This is
strongly tied to system and remote server push notifications (why spawn a
thread to poll for changes in geo-localization when the system can just
wake your app up when the device moved?) for which there is ongoing work
in the WebApps WG.

>5) Native touch scrolling as a CSS overflow option (iOS 5 introduces
>this, but I think it'd be great to champion this to other browsers)

Agreed. Needs to be spec'ed however. Not sure what the CSS WG's thought on
this issue are.

>6) Chrome adds Web Intents, but it'd be good to have more OS and browser
>neutral means of launching intents and similar.

Web Intents (or a similar service-orientated API) are high on the level 2
roadmap, but are far from being ready atm.

Best,

--tobie

[AppConfig]: http://www.w3.org/community/coremob/wiki/Features/AppConfig
[FullScreen]: http://www.w3.org/community/coremob/wiki/Features/Fullscreen

[IndexedDB]: http://www.w3.org/community/coremob/wiki/Features/IndexedDB

Received on Monday, 11 June 2012 08:56:38 UTC