Widgets 1.0 responses and thoughts

Responses to the Widgets 1.0 spec on the web have been mixed, but mostly positive with a few negative comments here and there. There have been some positive responses, like the one on Ajaxian. The brief article on Ajaxian seems to clearly capture the point of the spec:

Everyone and their mother have created their own widget specifications, and now as a developer you need to make choices. Do you want it to work on Dashboard? Google? MSN? Yahoo!?
If the big hitters supported this widget standard then we could write once, widget everywhere. Kinda 🙂

And another really good point they make is that…

This standard will live and die by the support that it gets.

Dare Obasanjo wrote a fairly negative blog entry about the Widgets spec seems to kinda miss the point (and Mark Baker points that out in the comments), because he seems to think that Widgets 1.0 is trying to address web page embedded widgets, which it is not.

Arve Bersvendsen, who edited the very first versions of the Widgets 1.0 spec, took time to briefly blog about the widget spec; and so did Anne van Kesteren (currently the other editor of the Widgets spec), stating in his blog entry about Widgets 1.0 that for some time I thought widgets were the latest marketing trick and pretty useless. Now I think they can actually be really useful (and fun) for creating simple applications using HTML, ECMAScript and CSS. The website Musings from Mars also thought that Widgets 1.0 was a good idea, saying let’s hope the world came settle on a standard that would let developers write widgets that would work on all the various platforms (Yahoo, Apple, Opera, Google, and, yes, Microsoft).

It seems that in general people get what Widgets 1.0 is all about. For those who don’t, lets be clear. The purpose of the spec is (IMHO):

1. stop fragmentation of the Widget development space, particularly in relation to metadata and the APIs.
2. to provide a standardized way to package, sign, code, and record metadata about widgets. The theory being that, if adopted by vendors, you could write a widget once and run it on any conforming widget engine (Yes! the same as Java applets). Of course, this second point is very complex (or screwed!) because of the API problem, which is the greatest challenge for the standardization of widgets. I return to this massive issue later.

I think the cause of confusion has partly been the name “Widgets 1.0” and the lack of historical context around this spec. I guess this is why the original requirements document I wrote was named “packaging client-side web applications”. Even though the title made sure that very few people knew what the hell i was talking about, the title of my document captured (part) of the problem well… but capturing the problem well doesn’t help if people don’t know what the hell you are talking about. However, the Widget spec is wider in scope and so is the now renamed “Client-Side Web Applications (Widgets) Requirements” document. As I already discussed above, the scope of both documents now covers five issues surrounding widgets:

1. Packaging and how to digitally sign a widget
2. metadata and the manifest file
3. Scripting interfaces
4. Security
5. Auto-discovery

Packaging basically covers putting the widget into a zip or similar container file. The developer should have some mechanism to digitally sign these files so that the user can be sure that the file has not been screwed with.

The manifest file records the metadata about the widget, and hopefully the security context under which the widget will run, and a way of declaring default preferences for the widget. Despite what is currently said in the Widgets 1.0 spec, it will not be a requirement that a widget package contain an ‘index.html’ file. The manifest format will provide a (yet-to-be-specified) mechanism to allow developers to declare which file launches first. This will overcome the issues related to having an “index.html” and accommodate implementations, such as Yahoo!’s Widget Engine, that don’t use HTML as the UI language. That way, developers can name their “index” file whatever they want. However, we will probably recommend that developers name their main widget file “index.” for the sake of consistency. I personally would not like to formally specify “index.whatever” as the required file name, particularly in an internationalized context.

The Scripting Interfaces are a very impoverished part of the specification. At the moment the spec only attempts to define get and set preferences, and some widget geometry stuff. Like I said before, this is the area that needs most work… or maybe not…. If we consider that widget engines are mostly just web browsers (at least in the case of Opera, Vista Sidebar (IE), and Dashboard (WebKit) evidenced by the fact that they consume HTML, but have a few extra API extensions through JavaScript). In the case where the widget engine is not built on a browser, as is the case with Yahoo! widgets and Google, we still see browser-like tools being included into the API. For instance, Yahoo!’s Widget Engine includes a XMLHTMLRequest object, and implements SpiderMonkey (JavaScript 1.5). Even Flash, the greatest widget engine of them all, attempts to follow the web by supporting (very badly) HTML and CSS… and to Adobe’s credit, they’ve implement ECMAScript/ActionScript as an object-oriented language, even if it is really annoying to use. Regardless, ECMAScript web-based foundations.

So, I guess what I am trying to say is that it seems that the web itself seems to dictate what APIs should be part of a widget API and engine. Yahoo!’s widget engine is a notable exception but their UI/Widget language is highly problematic from an engineering standpoint because it does not clearly separate content, structure, and style… however, it is still super easy to use.

Security I don’t even want to think about security too much yet. All I know is that that the Info.plist model used by Dashbaord is a fine model. Finally, The auto-discovery is a simple mechanism that works that same as RSS works with relation to using a the HTML link element.

The development of this spec will proceed slowly over the next 2 months. I am still trying to put together a plan to address each red box in the specification. I am hoping to have a new draft published by the end January.