5 November 2011
Hosted by Vodafone
Workshop Report
The W3C held the Future of Offline Web Applications Workshop in Redwood City, California, USA on the 5th of November 2011 in order to discuss how the Web might evolve to best include offline applications.
We received twenty nine 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:
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 former than the latter. However, there is much more demand to use it as a cache improvement than there is to use it for building offline apps.
“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 three issues with AppCache:
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.
The “master entry” is implicitly cached.
AppCache updates are triggered via a change in the manifest, not the document itself.
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.