Of Widgets and The Next Big Thing

There is a growing realization of the power and potential of “widgets” as a new and sexy mechanism to render and share information in line with the Web 2.0 principles of openness, flexibility, aggregation, user power, and user content generation.

So, what is a widget? What is a service? What is SOA?

Imagine some kind of abstract space. Also imagine some data and something to transform and manipulate it. Call this a “widget”. This widget knows how to “render” itself whether visually or otherwise. This may be too strong. Rather than “knowing” how to render itself, it has some minimum set of requirements to be met by some rendering entity. It can also be helpful to such a rendering entity; it might provide hints and suggestions.

Back to our abstract space. This space knows how to manage an abstract container. There is a dialog between the space and the container. They can negotiate, come to agreements. A specific container implements an abstract container. There are many different kinds of concrete containers. There is a browser container or set of containers, a phone container, a toaster container, a set of car containers, etc. Some widgets are general, some very specific and managed only by specific containers. There is an SOA container. There are SOA “widgets”.

The “space” can dynamically “layout” containers in a cooperative and heuristic manner. Likewise, containers can “layout” widgets.

To be a little more concrete, what is a web page? A web page is a set of composed interacting, dynamic widgets. A widget could be a paragraph from the New Times. That paragraph could be “rendered’ in any space which has a container that knows about “paragraphs”. Paragraphs could talk to one another if their containers implemented the inter-widget communication protocol which is defined in the abstract container. However, talking paragraphs is probably not a good idea so most paragraph containers will pass on this.

So widget and service become synonymous. They are atomic bits of data and code in a wrapper which implements some subset of well-known protocols. Our software world becomes a set of primitive “widgets” which can be composed into other widgets and which can live wherever they can be contained. Web pages, inventory management software, toaster software, DVD software; they are all built with the same kinds of interchangeable building blocks, woven together in a multitude of ordered and cooperating patterns.

Moving forward

There is a lot of activity in this space, with companies like Google setting the pace. There is also a growing realization that if this technology is to attain its full potential, there is an urgent need for standards. Calls are already being made for the creation of a standard which will permit interoperability. This will happen. In the future, there will be a open widget interoperability standard. There will be an organization which will oversee the standard. It will also operate and oversee a set of compliance tests. There are two entities at play here; the “widgets” themselves and the surface that contains them. Both require standards. Several players are already active in this field. They include iGoogle, Netvibes, Pageflakes, Protopage, and WebWag. Each has their own widget standard and their own widget manager. Of course, they don’t interoperate. Still, it’s early days; we’ve been here before and we know how to go to the next level which is for everyone to get together and drive to a set of standards. Or, let some dominant player establish a de facto standard. Who wants to drive?