Scott's Workblog

This blog has moved! Go to my new blog!

April 16, 2008

W3C releases working drafts for Widgets 1.0 specification

This week sees another milestone in W3C's effort to standardize the use of Widgets across platforms with the release of the Widgets v1.0 working draft documents. The specification aims to offer a single way of creating and distributing widgets on a range of platforms.

The current scope of the W3C work is set out in the Requirements document. W3C defines Widgets simply as:

mall client-side Web applications for displaying and updating remote data, that are packaged in a way to allow a single download and installation on a client machine, mobile phone, or mobile Internet device. Typical examples of widgets include clocks, CPU gauges, sticky notes, battery-life indicators, games, and those that make use of Web services, like weather forecasters, news readers, email checkers, photo albums and currency converters.

Another document, the Widget Landscape sets out the lay of the land in terms of what Widget platforms are out there, and how they approach the different aspects of Widget functionality.

The specification is targeting platforms such as Apple Dashboard, Microsoft Sidebar, Yahoo! Konfabulator, and mobile platforms such as WidSets. Web widgets, such as Google Gadgets, are not currently in scope, although when you dig into the details of the specification, its obvious that web widgets can potentially be developed in a similar manner.

After requirements, the first specification document is Packaging and Configuration which defines the zip-based format used to package the content of a Widget, the structure of the XML configuration document that goes inside it, and other aspects such as discovery and internationalization.

A surprising omission at this stage is the API specification. All Widget container platforms supply an API, typically accessed via JavaScript, that offers the Widget a way of storing and retrieving preferences, calling remote services, and executing various kinds of commands. Presumably this will be released next; currently there is only an Editor's Draft of "APIs and Events". Currently a developer of a Widget needs to make different API calls based on where the Widget is deployed to do very basic things like save and retrieve user settings.

Another aspect of a Widget API is extended features, especially in the case of web Widgets. The Google OpenSocial API is an example of an extended Widget API - in this case to enable Widgets to access things like friends lists and status information. Another is the widget collaboration API we developed here as part of our EU TenCompetence project, that enable things like activity-based chat and voting widgets to be developed using the draft W3C specification. (More on that in another post sometime).

Overall I think there is some great work going on in this W3C group, with a very practical focus that is based on taking a consensus view of "what is" rather than a more purist "what should be" approach (which has characterised some of the W3C's other recent work). I hope that once this spec is finalized the focus will move onto taking a similar approach to web widgets, for which there is an even more pressing need for interoperability. Our own work has shown that, with a few minor modifications (e.g. the addition to the API of a proxy method for safe tunneling of external Web API calls around cross-site script access restrictions), exactly the same model of packaging, manifest and API can also work within a web framework.

For more information on this and related activities, also check out the rest of the Web Application Formats Working Group pages.

main archive