A widget sounds a bit like a dashboard, but unlike dashboards, widgets allow you to input data as well as view it. In addition, desktop widgets generally run on a widget engine, which is a runtime environment that may be ported to two or more operating systems and provide security, local-management, and access to system and network resources through platform agnostic APIs. Dashboards, on the other hand, tend to be stand-alone applications. Figure 1 shows the general architecture of a desktop widget engine.

Figure 1: Architecture of a desktop widget engine

Desktop widgets have been around for a very long time. The first set of desktop widgets were introduced by Apple back in 1983 with their release of Apple Desktop Accessories (see Figure 2).

Obviously Apple was way ahead of the curve, but these early widgets were not Internet enabled – the popular Internet, as we know it, didn’t exist – so their utility was pretty limited.

Although there were assorted forays into Internet connected widgets in the late 1990s, most notably in push technology provided by PointCast and Microsoft’s Active Desktop Update, it wasn’t until Konfabulator (see Figure 3) came along in 2003 that Internet widgets truly arrived. Today it’s hard to imagine a widget engine that doesn’t connect to the Internet – at least one that is useful.

Figure 3: Konfabulator (2005)

Konfabulator was eventually purchased by Yahoo! - becoming Yahoo! Widgets, which offers a fantastic assortment of consumers-oriented desktop widgets – things like clocks, weather dashboards, stock tickers, music streaming, etc.

Today there are many widget engines including Dashboard on Mac OS X, Google Gadgets, Microsoft Gadgets and about a dozen other widget engines from small vendors, freeware, and open source projects (see this list on Wikipedia).

What strikes me, however, is that all of these widget engines are designed for fairly trivial consumer-oriented tasks. There are very few widgets for the enterprise. I’m only aware of one vendor that offers enterprise widgets, Extensio, but they are not in the business of providing a widget engine; a platform on which other vendors can build widgets. Extensio’s widgets are tied to their own proprietary Information server and while interesting they hardly represent a platform on which an ecosystem of enterprise widgets can grow.

What is needed is an enterprise widget ecosystem. The ecosystem would have to be portable across the most common desktop operating systems and it would need to be backend agnostic. The Fit Client, the Grand Convergence of the web, RIA, widgets, and client/server applications, is the best kind of platform on which to build an enterprise widget engine. You could build an enterprise widget ecosystem on top of Fit Clients such as Yahoo! Widgets, Google Gadgets, Adobe AIR or the like, but the requirements for enterprise widgets are different from consumer widgets so perhaps a new platform is needed.

First and foremost, the enterprise widget platform needs to be secure so that widgets are restricted to a sandbox independent of other widgets. At the same time, however, the ability to link widgets together so that widgets can act as data feeds for other widgets (Extensio does this to some degree) is also important. Another important requirement is manageability. An enterprise widget engine needs to provide centralized management and provisioning so that the IT department can monitor who is using which widgets and deploy and remove widgets over the network from a central location.

The question that comes to most people's mind when I talk about enterprise widgets is, “why would the enterprise need widgets in the first place?” Good question. I think the answer lies in the narrow focus of widgets. Organizations that write their own software, or even those that use packaged ERP software, tend to provide mammoth client applications (desktop or web based) that provide much more functionality than any single employee needs. One employee uses one set of windows and menus while another uses something different, but they all use the same application. That in my mind is not very effective. It would be better if employees could have only those input forms or views on their desktop that they need and wanted. If you buy that argument, then you have an excellent use-case for widgets.

The idea of each employee having a few to a dozen small enterprise widgets on their desktop may seem like a maintenance nightmare, but actually it would be much easier than maintaining a mammoth interface. For one thing each widget could evolve separately so that you could update functionality without having to do a huge application release. The narrow focus of widgets also makes testing, maintenance, and development a lot easier. In addition, if the backend data sources are accessed as micro-services (very granular web services) or REST resources, then creating new enterprise widgets would be much easier than adding new features to a large desktop client.

Enterprise widgets provide a win-win for everyone. Tacit workers can have a more focused desktop – just the views and input forms they want and need – while IT has an easier time updating and adding functionality.

The enterprise widget platform is very different in many ways from the traditional mammoth front ends we are used to. They allow an organization to be more nimble and its workforce to be more effective. In my opinion, the days of large enterprise application front ends are coming to a close. In the future, the desktop will become the enterprise front end and every employee will have exactly the enterprise functionality they want and need.

• Which Technologies Will Carry the Rich Internet Torch?
• The Grand Convergence: Web + RIA + Widgets + Client/Server
• The "Uncanny Valley" Theory Doesn't Apply to Desktop UI
• Engelbart's Usability Dilemma: Efficiency vs Ease-of-Use