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.
