Offline web applications workshop

Workshop Report

The W3C held the Future of Offline Web Applications Workshop in Redwood City, California, USA on the 5th of November 2011 (see Agenda) in order to discuss how the Web might evolve to best include offline applications.

We received twenty nine Position Papers and had over fifty people in attendance (see raw minutes), which meant there was not going to be time to present each paper individually. Instead of choosing papers to be presented we asked each submitter to do a 2 minute lightning review of their paper. Everyone then wrote down ideas for topics on which we should spend the rest of the day. The notes were then stuck to the wall. As you can see we had quite the collection:

• 

  Our first whiteboard with stick notes

• 

  Our second whiteboard

• 

  Our whiteboard

We spent some time organizing these into similar topic categories, which were then entered into a moderation system which allowed everyone to vote up or down their favorite themes. In parallel, another group decided to try to write an offline application to see what might be missing from the currently deployed technologies. This report will recap the topics discussed, the outcomes and ideas for future plans.

The themes were as follows:

• Use Cases

higher level discussion than user experience: what uses will these apps have?

• “Fixing” AppCache flaws

Programatic cache inspection and manipulation. Caching of master page. Network behavior clarifications. Quote management.

• Convergence

Combining existing solutions. AppCache AND Widgets living together.

• User Experience

How will the user interact with offline apps? Are they in the browser or native looking? Look and feel? Interactions between native apps, web apps and APIs. Performance.

• Developer Experience

Teaching, coding, debuggers, IDEs, test suites. How can we enhance the lives of those who want to develop Web applications?

Use Cases

Participants to the workshop started by identifying what use cases “offline” Web applications were meant to fulfill. The discussions highlighted the following roles:

• applications that are still available to the user when the network is no longer available (provided the user knows how to access them)
• applications that are “installed” by the user — associated with a greater sense of ownership
• applications that are granted additional privileges (for instance, via an “installation” step)

It was also noted that AppCache serves a dual purpose:

• making possible to use a Web app once disconnected,
• improving caching performances of on-line Web applications.

Based on the discussions, it seemed that the current design of AppCache is more oriented toward the latter than the former.

“Fixing” Application Cache

The most requested topic for discussion was: how do we fix HTML 5’s application cache (AppCache)? We started this discussion by having Tobie Langel present his paper “AppCache Wows, Vows and Woes”, which succinctly laid out issues with AppCache:

1. The update model requires developers to write applications that are essentially offline, but may be connected, rather than an online application that may be offline on occasion.
2. The “master entry” is implicitly cached.
3. AppCache updates are triggered via a change in the manifest, not the document itself.
4. AppCache doesn't work well with Content Delivery Network (CDN), in particular due to use of URL fingerprinting

Convergence

Before tackling the second topic, “Convergence”, we received an overview of the state of W3C Widgets from Marcos Cáceres, the editor of the W3C Widgets Recommendations.

Currently there are a number of similar, but incompatible solutions in the area of installable Web applications. Is there a need to converge on a single solution amongst those? Is there enough overlap between Widgets and AppCache that they should converge? Is the whole idea of “installed software” going to be obsolete?

Beyond competing solutions for installable Web applications, there was a sense that AppCache and W3C Widgets provide in some areas overlapping solutions. Widgets configuration files provide more hooks for application-specific properties, but a number of these have rough equivalent in HTML5 (e.g. >meta name='application-name'>).

While several participants confirmed their interest for a common packaging format for downloadable Web applications, there was no strong sense of convergence expressed at the workshop, and further discussion will be needed to make progress on this topic. The Web Applications Working Group is the group chartered in W3C to look at this space.

User Experience

Currently, the user experience associating with AppCache is not well defined, and a user can't really see the list of applications that are available to her when disconnected. It was suggested that “installable” Web applications should be better promoted in the underlying OS, to give them better visibility to the user.

There was no clear consensus on whether binding the user experience of “installing” a Web application meant that the application could be granted additional privileges. Some extra-permissions were mentioned as possibly easy to grant to such an “installed” Web application: greater disk quota, or a relaxed same-origin policy. But requiring users to approve a set of further permissions at installation time does not necessarily work well since users tend either to make uninformed decisions, or to avoid installing the app.

The link between a Web app and the availability/visibility of a browser chrome was also discussed, exposing different approaches that have been experimented with: running Web app as a pinned tab, or running it in a separate process in a chromeless browser. It was established that users expect different behaviors inside a browser chrome vs in a chromeless Web app: for instance, in terms of following links, or in the presence of ads.

Developer Experience

A few of the workshop participants decided to test the real difficulties with AppCache during a mini hackathon organized in parallel to the plenary discussions, which confirmed the diagnostics presented in a number of the papers submitted to the workshop.

In addition to these, it also made it clear what obstacles developers face when using AppCache:

• the difficulty to reset an application cache
• the confusion caused by having to reload a cached Web page twice to see its effects: first reload notes updated manifest, second reload actually updates the cached resources
• the difficulty of understanding how AppCache intersect with regular caching of resources
• the impossibility to add a resource to an existing ApplicationCache without requiring a (double) reload of the page

The desire to mark a resource as part of the AppCache from within the HTML markup was also mentioned.

It was acknowledged that the developers tools available in browsers were not up to the task yet — the result of the tension between making a feature available sooner, or waiting until all the associated tools be available, and thus delaying it.

Next steps

As a result of these discussions, the following bugs were opened on the HTML bug tracker:

• appcache: always up-to-date applications to make some files always downloaded when on-line
• appcache: remove the requirement for the MIME type to make the MIME type of manifest file optional
• appcache: allow a manifest to be identified by something other than its URL
• appcache: makes manifest servable from CDN

The Fixing App Cache community group was also formed to track follow-up discussions on the topic.

It was noted that the interactions between Web developers and standards experts was very fruitful and should be encouraged in other occasions.