Skip to Content
Eric Wood recently pointed me to this resource and asked that I chime in when possible. I’ve been involved with the Widgets initiative at SAP since the beginning and hope to continue contributing despite other commitments. To that end, I wanted to take a moment to share some of my thoughts.  Widgets are an excellent way to deliver micro apps. that fulfill niche requirements but they can provide much more. The technology is a bit of a double-edged sword. Everything about Widgets screams micro app. The ability to rapidly develop and deploy point solutions attached to the desktop is compelling enough that some folks might not think farther than solving that niche requirement. This approach can drastically limit the usefulness of your widgets.  I encourage folks to think of widgets in a larger context. The widget engine is essentially a full screen app. Individual widgets are windows, views or pallets within that app. As such, it should be possible to develop a collection of widgets that, although self contained and useful in their own right, interact like frames or views within a traditional app. to provide additional functionality.  In this context, the widget engine becomes a “Heterogeneous App”. Abstracted data from a variety of sources that need not be related feed a collection of widgets. Properly developed widgets organize that data into a common data model that can be used to drive other widgets aware of the data model.  You might ask, why take this approach over a traditional app?  This approach allows for a more complete componentization of major UI views. Each view is a self contained widget. If a new arrangement of that view is needed, it can be developed and deployed on its own. Similarly, if a particular user doesn’t need a particular view, they simply dismiss it. They are free to assemble widgets as needed, scaling their desktop from a single widget to a monolithic app as needed.  For example let’s decompose a typical email app into widgets. Message categories and item lister Message reader Message editor Contacts  In a traditional app, users have a very limited number of layout choices. Implemented as discrete widgets, users have full freedom to show and arrange views however they want. In addition, each view could be available in a variety of flavors. Beyond simply reskinning, one user might prefer a plain text message editor, another may prefer rich text, while still another might never need to send messages. Rather than developing the killer app that tries to serve all needs, developers can deploy point solutions that answer specific needs. Users then have the freedom to work how they want.  Developing the collection of widgets as a related set allows for extended functionality. A contacts widgets might be useful on its own, but so much more useful if it knows what viewer and editor you use for messages. If all these widgets share a common data model, things like drag and drop between widgets is possible. A common data model also enables unique widgets. For example a universal widget control bar aware of a related set of widgets and their interrelated actions.  Back to my earlier point of widgets being a double-edged sword… both aspects mentioned above are relevant but doing both well is difficult. On the one hand you want individual widgets to be simple, self-contained and useful in their own right, on the other hand there’s functionality to be leveraged if your widgets interact. The trick is to extend functionality through interaction without creating hard dependencies or spoiling the stand-alone usefulness of each widget.  Interaction on the level I’m suggesting argues for a more rigorous object oriented approach to widget development rather than the “whatever works” approach common to point solution development. The technology can accommodate both. Try not to miss the forest for the trees.
To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Dainius Vaznys
    The idea of an application implemented as a set of widgets is certainly OK. In fact when we go to a functionality beyond simple things like ‘display this’, ‘put it over there’ and so on, we can’t solve it with a single widget. This way, we have built a set of widgets that allow to book leave requests, edit them, change one’s mind and cancel the request and so on. If we tried to build this functionality in a single widget, it would be quite a big one, probably not very easy to use. If instead of that you have a small widget that displays a list of your leave request where you can launch another widget to edit it, you have two widgets, communicating together, each implementing their own piece.

    Now the trick comes when you try to implement such a set of widgets. When they talk to each other, they have to precisely understand what counterparties say. This means they have to agree on a common protocol that defines what messages are sent between widgets, what parameters they include and so on. That’s the case for Yahoo! widgets. To make matter the worse, Dashboard widgets don’t have built-in mechanism for inter-widget communication. So what we came up with is a Dashboard widget plugin that uses Mac OS pub/sub messaging middleware for inter-widget communication. Now to make it work, both communicating widgets have to agree on the name of the topic/queue they will be talking thru. With all the reasoning above, I think an application as a set of widgets is only feasible if it is done by a single company. The dependencies between the widgets are so important that it is hard to imaging that an application could be assembled out of widgets done by multiple vendors. It could only be true if all the vendors agree on a common interface. This is what makes to take some caution when we read the word ‘heterogeneous’ in the title .


Leave a Reply