Netvibes announced a “Universal Widget API” at last week’s Future of Web Apps conference in London, promising a write-once run anywhere widget environment using an open-source widget runtime. The new widget system encourages publishers to author widgets using the Netvibes API and extend the reach of their content beyond the Netvibes user base through an adaptable wrapper. In this post I’ll walk through some of the differences between widget deployment endpoints from the publisher’s point of view, explaining just a few ways a widget must adjust its dialect and structure to adapt and optimize in different widget environments.

  1. Manifests
  2. Inline and collapsed widgets
  3. Storing local variables
  4. Platform look and feel
  5. Requesting remote data
  6. Internationalization and localization
  7. Libraries
  8. Summary

The manifest

Each widget platform requires some sort of manifest file, a definition of a widget’s contents, file, and author information for interpretation by the widget platform and its widget directory. A manifest file will commonly collect pointers to files within the widget package (CSS, JavaScript, widget preview image), a description of the widget (title, summary, author), and any libraries or non-baseline features you would like to include with each widget render.

The widget description is easily standardized, collecting an author’s name, e-mail, and URL, the widget’s homepage on the web, and a description of the widget’s function. The widget title is a bit more difficult, as some publishers would like to dynamically update the title to display a total number of unread mail messages, the current weather, or an active search term.

Inline and collapsed widgets

Most web widget engines offer an “inline” option, placing your widget code directly into the page instead of inside of the default placement within a sub-page (iframe). Inline widgets can change the page’s background color, interact with other widget content on the page, create a dynamic widget title, and more. Permissioning inline access varies by platform but can be a useful option for your widget.

Collapsed Microsoft gadget weather

Microsoft gadgets support a collapsed display mode for inline gadgets, displaying extra information about a gadget’s content within the gadget title bar. In the example above I’ve collapsed the Windows Live weather gadget, displaying a weather icon and today’s temperature high’s and lows instead of a multi-day forecast. A collapsed mode allows more widget content in the same available space.

Storing local variables

Apple Dashboard widget weather location

Your widget may require some configuration to function at its best. You might ask the user to input a ZIP Code, a user ID, or a favorite baseball team to deliver the appropriate content in your widget. You might also allow customization of colors within the widget frame or text, the total number of items to display (3 days of weather, the latest 5 San Francisco Giants news stories, etc.), or whatever else might be applicable to your widget’s display and customization.

Widget variables and configurations are stored on the widget platform’s servers, letting users input their preferences once and have the same configuration across multiple computers. The default method of preference input is usually a text input field, but you can provide a drop-down list of possible options, radio buttons, checkboxes, and many other choices.

Platform look and feel

Each widget platform typically has its own design, styling a widget window, creating a specially styled button, or generally matching the look and feel of the surrounding environment. Windows Vista Sidebar will appreciate an Aero Glass look-and-feel, Mac users will look for Aqua-styled buttons, Windows Live gadgets might display a FancyButton, etc. Each widget can adopt the default settings of the web browser, explicitly bind with the target platform’s UI, or package a custom CSSfile.

Requesting remote data

Web widgets typically request data through the hosting platform’s proxy, supplying a remote URL to a specialized data type handler and specifying a preferred response such as XML or JSON. The platform caches each request by default for a period of time (usually about 30 minutes) to increase performance and lighten the load of all the Google Personalized Homepage users subscribed to BoingBoing’s RSS feed or requesting earthquake updates for northern California.

Here’s an example of how developers can request an feed on three different personalized web homepages:

Google
_IG_FetchFeedAsJSON('http://example.com/rss.xml', CallbackFn, 5)
Netvibes
Ajax.Request(NV_XML_REQUEST_URL + 'url?' + escape(http://example.com/rss.xml), {method:'get', onSuccess:CallbackFn})
Windows Live
Web.Network.createRequest(Web.Network.Type.XML, 'http://example.com/rss.xml', {proxy:'rss', numItems:5}, CallbackFn)

In the example above I specified a web feed URL, a callback function, the total number of feed items I would like returned, and I would like the data returned to my callback function as a JSON object. Each platform also has request proxies for generic data, XML, JSON request, etc. Your get, post, put, and delete proxied functionalities may vary by platform.

Internationalization and localization

Hello world. Hola mundo. G’day mate.

The newest web products are launching to a global audience, finding popularity beyond English-speaking borders and becoming the hot thing in France, Poland, or Japan. Some widget platforms support internationalization and localization bundles, allowing a widget author to define unique phrases sent to English, French, Polish, or Japanese users. The widget platform interprets the language requested by each user’s browser combined with the international domain being accessed and passes this information along to any widget willing to listen. A Google Canada user might view your widget and request the content in French for example. Google Personalized homepage currently supports 15 languages throughout its widget platform.

Libraries

Widget platforms can contain a set of basic features available to each widget but expand their capabilities through additional libraries. Google gadgets can request an analytics module to track widget views, add tabs, and more. My Yahoo! widgets might tie into already loaded YUI libraries. Windows Live Gadgets even have a preferred method of string concatenation (StringBuilder).

A universal widget could load the appropriate library at each destination on demand, or provide a generalized runtime to load similar functionality through its own modules.

Summary

The immediate concern with any write-once run anywhere solution is an abstracted non-native feel for each deployment. Like the promises of Java and wxWidgets for desktop applications, cross platform solutions can sometimes feel a bit alien and heavy when compared to a native application. Developers can extend the reach of their applications quickly and easily, trading off a native look-and-feel, performance and memory utilization, and more for a broader list of compatible platforms.

A universal widget might lose out on advertising opportunities available in each widget platform’s gallery. Your widget may not be listed in the Apple Dashboard gallery, the Google Gadgets directory, Windows Live Gadgets Gallery, etc. Users of each platform typically are directed to these directories to find new pieces of content and it’s a free form of advertising for your widget and your brand.

I think universal widgets combined with a good statistics tool will help new widget developers better understand their deployed audience and tweak their offerings over time to deliver the best possible experience for each platform. Widget developers and publishing sites will want to better understand the parent environment of their widget (Google homepage, Live.com, Netvibes, tec.), web browser and version, language, country, and much more. Netvibes will likely see an increase in widgets available for their platform and abstract some of the work needed to stay on top of the changes at each widget platform.

There are many more differences between platforms than I’ve covered in this post, but I hope it gives you a good idea of what it means to integrate well across multiple points of deployment.