A desktop widget is a small application that provides very focused
information from a predetermined data source. Desktop widgets generally
have a small footprint, are of fixed dimensions, and provide
information “at-a-glance.”
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.
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.
No comments:
Post a Comment