Applications, User Interfaces, and Servers in the Soup
Pages: 1, 2
So Groove taught me a lot about the future of the application. But what really punctuated my equilibrium was a demo copy of Tenix. It doesn't contain Groove's incredibly sophisticated synchronization, and therefore doesn't let users do things simultaneously, like edit a file together. But the degree of integration of Tenix into Office and the desktop is eye-opening.
You can pull down a menu in most Office products and save a document to a Tenix workspace, where it's available to all of your colleagues wherever they are in the world, or send it in peer-to-peer fashion to a single colleague. In an upcoming version of Tenix (to be released in the first quarter of 2003), you will be able to right-click on anything on your Explorer desktop and save it to a workspace.
At this point, I find it hard to say whether I am running Word with an embedded Tenix service or running Tenix with an embedded Word service. We begin to sense the dissolution of the standalone application.
According to Dan Gagnier, director of business development for Tenix, you may be more likely to encounter a Tenix salesperson than a Groove salesperson if you live in Canada, the U.K., or Europe. Tenix's use is growing among legal, banking, and accounting firms in those countries and Tenix has won a strong foothold through a deal with the Canadian Bar Association.
Tenix developers are very conscious of standards, in order to maximize portability. Ryan Duffield, director of application development, estimated that the software is "90 percent ported" to the Macintosh already, because they follow standards. They use SOAP for as much communication as they can, along with AES and triple DES encryption.
Once an Office application is integrated with Groove or Tenix, the same component breakdown of the Office model that allowed integration actually allows the application to fade into the background. Theoretically, a SOAP request could be sent to Excel and it will return results, without a user ever feeling he or she has run Excel. And that observation leads to possibilities for the next stage in services and applications.
Next Step: The Soup
A recent article by Larry Lange claims as "Myth No. 1" that "Web Services Is A Revolution." Well, nobody could love cynicism more than me (because to love something to such an extent would disqualify one from being a cynic), but I'm just about convinced that Web services do represent a revolution.
Perhaps not Web services as they are properly called, using HTTP and port 80 and SOAP. Perhaps not the commercial utopia of seamless online shopping through heavyweight infrastructure elements such as UDDI or ebXML. But something component-based and widely distributed, related to what I've seen in the collaboration environments I just described. They can use CORBA for all I care. That's, in fact, the technology behind Bonobo, the component foundation of the GNOME desktop.
As said by Jack Ozzie, brother of Ray Ozzie and vice president of developer services at Groove Networks, "Web services was imagined for back-end computers processing car orders. But when you bring it to the desktop, it really opens up possibilities."
The reason I see the innovations of Groove and Tenix as qualitatively different from the simple Google service mentioned near the beginning of this article is that Google merely embeds one distinct application in another, whereas Groove and Tenix embed entirely new ways of working with the computer and the network.
Where are we heading? Every aspect of an application becomes componentized and offers its own protocol. The user is left with an astonishingly thin user interface layer accessing all of these servers. Servers are nested within other servers.
The application -- mainstay of the computer field for some 50 years, preceding the operating system, the network, the programming language, the command line, and just about every other aspect of computing -- almost disappears. What is left is a framework that handles the contacts between the user interface, the local operating system, and the network.
A Head's Up for Developers
The profound degree of integration that third-party collaboration products have achieved with Microsoft Office shows the power of components and Web services. Without sharing source code, different companies have created an interface so seamless that you couldn't tell it's made of separate products.
This should be a wake-up call to free software developers, because easy integration has always been a trump card in the Free Software Movement. I am one of many people, for instance, who spends their whole day within the Emacs editor, running a dozen different programs within its framework and enjoying its powerful interface for cursor movement and text manipulation with each application. Well, Groove and Tenix show that proprietary application developers can play the same game. In fact, the flexibility provided by Microsoft in its libraries and component interfaces is cited by two Harvard Business School professors as its chief competitive advantage.
But I don't have the patience here to get hung up on a debate between free and proprietary software. A deeper lesson comes from watching the evolution of the cursor movement and the text-editing capabilities I mentioned as the great strength of Emacs. People liked this interface so much that it got integrated in the bash shell (the primary user interface to all programs) and then, through the Readline library, into countless other free software programs.
Superficially, the Readline example looks simply like developers imitating a popular look and feel and taking advantage of code reuse. But I see something more significant: the interface elements people like most about Emacs have become abstract from the Emacs application and have taken on a life of their own.
It's not hard to envision a totally different relationship, at this point, between a user interface and an application. The application reduces to DLLs, components, and SOAP interfaces. The user interface is something the user can tack on.
The importance of components is illustrated by its choice as the cover feature in a recent issue (October 2002) of the Communications of the ACM. The stories focus on using components to build large back-end support systems, a worthy topic for this engineering journal. But it's unfortunate that nothing is said about the possible impact of the components on user interfaces, even though the other major set of articles in that issue concerns user interfaces.
(Do not confuse the user interfaces I talk about here with the interfaces to components, which are a completely different matter and have a very limited purpose. Component interfaces define the methods called, the parameters passed, and a few other aspects like object properties and perhaps pre- or post-conditions.)
More Attention to the User Interface
The popularity of PDAs and cell phones, along with attempts to develop easy-to-use voice and audio interfaces, strain our current state of the art in user interfaces. Perhaps improvements on the back end -- Web services -- can free us to find creative solutions on the surface.
Point and click looked very appealing in an earlier age, back in the '80s or so. As applications and users alike became more sophisticated, point-and-click options burgeoned into information overload.
The invention of cascading menus came in the nick of time, rescuing us from an unmanageably huge number of application options. But after a few years, even cascading menus were not enough to hold back the flood, and we were saved again by the invention of tabbed dialog boxes. In each case, users learned to accept new user interface elements in order to be able to manage mega-applications.
And even so, one could argue that option overload still afflicts us. Darn it, here's a Web page that requires Java to work. Do I enable it through the Security tab of the Settings item of the Properties submenu of the File menu, or through the Applications tab of the Security item of the Options submenu of the Tools menu?
Browsers (whose user interface model is already ten years old -- the approximate age of the NCSA Mosaic browser) have very neat navigational functions for Web pages. But a few Back, Forward, and Print buttons are probably not enough for the richer, more flexible applications to come.
So we may be ready for another revolution in user interfaces on the same order as the GUI. But perhaps instead of dazzling, richer interfaces, we could go in the direction of minimal user interfaces that expand and contract to match the service being offered, customized to the user's preferences.
The latter direction seems to be the natural direction components and Web services are heading. A vague Microsoft announcement about a project code-named XDocs suggests a new approach to generating interfaces linked directly to some kinds of XML schemas.
If the new computing environment de-emphasizes full-scale applications and elevates the interchange of data among services, user interfaces have to change radically. Essentially, we should make it as easy as possible for users to request and redirect data flows, and to hook up components. This is a very different idea of "user interface" from the one we've inherited from the early '80s.
Current user interface designers have accomplished some impressive translations of complex computer concepts into visual terms every user can grasp. Take, for instance, the concept of "a variable that can take on one of a limited set of specified values." That concept is represented in the C language as an enum. In user interfaces, it is elegantly represented by drop-down lists and radio buttons. As another example, the simple checkbox is a visual representation of the programming concept known as a Boolean.
We need similar visual metaphors, easy to grasp quickly and manipulate in rich combinations, for such concepts as piping output to another program, setting up filters, and launching programs upon the reception of particular events.
Perhaps a future version of Windows will contain a My Interface feature, which lets you set keystrokes, functions, and other aspects of your interaction with services.
Spending is down and venture capital is tight for the moment, but innovation in computing is not dead. We are being buffeted by paradigm-shifting possibilities in the forms of new devices, new protocols (often running on top of the highest layer in the OSI model, just as SOAP runs over the HTTP layer), and new demands by users. I believe we will see not only major changes in applications, user interfaces, and servers, but a basic reconceptualization of what is an application, a user interfaces, or a server.
Return to Policy DevCenter