A couple of years ago one of the authors was working for a large global consulting company when it introduced an internal browser-based application for expenses processing: a customized version of the popular expenses processing package, Concur. The launch of the application was accompanied by much trumpeting of the 'millions of dollars' that it would save the corporation - a statement greeted with skepticism by a few of the more seasoned consultants. Within a few weeks, however, some of those skeptics were declaring that the company might well save its millions of dollars but in an unforeseen fashion: the joke being that the process of constructing an expense claim online was so frustrating that for small claims some consultants might choose just to write off the expense instead! (There is no evidence that that actually ever happened, but the user frustration was real enough).
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The story is not intended as a dig at that particular package: the arguments we are about to make apply to most contemporary business applications, whether packaged or bespoke. Concur is a functionally rich package, and doubtless the vendor has spent a great deal of effort in seeking to optimize the design of its user interface. The problem is that both the vendor and the customer have fallen victim to the mantra of 'thin client'.
Someone defined a mantra as 'a content-free phrase that, if repeated often enough, takes on the appearance of profundity'. That may be a little harsh: mantras often start as an attempt to embody a set of truths in a memorable form. The risk is that people forget what those original truths were and thus lose the ability to evaluate them in the context of changing circumstances.
The rush to the thin-client architecture for business systems, starting in the mid-late 1990s, was motivated by several truths, among them:
- Systems must be designed to be accessed from an increasing number of locations both inside and outside the organization, and from an increasing range of platforms.
- Maintaining client-side software for each type of platform is costly, as is the process of updating the software on each client device.
- Users will not tolerate long start-up delays each time they run an application.
- Putting all the business functionality on the client and the data on a server (as many first generation client-server systems did) can lead to poor performance.
- Mixing up presentation and business logic makes applications hard to extend or maintain.
At the time the idea of accessing all applications through an HTML browser looked like an attractive solution to all of these concerns. But looking at these points afresh in 2004 we get a very different perspective.
- A rich front-end written in Java will run on any platform that an HTML browser will run on, and more besides. When Safeway Stores in the UK developed their award-winning in-store pricing and stock management system they were forced to contravene the corporate 'thin-client' policy because the hand-held lacked sufficient flash memory to run the multi-megabyte Internet Explorer. So they built a Java client running on an open-source cut-down Java VM called Waba - which needed just a few kilobytes. Ironically, the new system was still classified as 'thick client'!
- There are now plenty of technologies that will automatically and transparently take care of client updates, from comprehensive software management solutions such as Marimba Castanet, to lightweight solutions such as Java WebStart.
- Typical available bandwidths have increased. Moreover, with Java WebStart the application is cached locally and updated from the server only when there is a new version.
- Whether thick-client or thin, most business systems are now multi-tiered, allowing appropriate business logic to be located close to the database server.
- As we showed in an earlier article in this series (Challenging the Dominant Design of the 4-Layer Architecture), even a well designed 4-layer architecture typically fails to achieve the intended separation of business and presentation logic: any business change almost always involves traversing all four of the layers, often iteratively. The thin client architecture doesn't improve this: it merely moves the physical location of the presentation layer.
What is really beginning to force the issue, however, is the growing awareness of the limitations of the browser interface from a user perspective. Our opening example is one of many. A couple of months ago we met with a large company in the engineering supplies business. They had launched an online application that allowed their frequent customers to order supplies, and provided other functionality to help those customers manage certain aspects of their own businesses. The new application has already been very successful in business terms. With a familiar browser-based interface it was easy for their customers to learn. Within weeks of the launch, however, the most active customers were beginning to express frustration with the user interface: not just because of the slow response time but with the strong modality. Keeping multiple jobs open at once, moving or copying objects between those jobs, dealing with a phone enquiry in the middle of a task - all the realities of their customers' businesses - are difficult if not impossible on the browser-based system.
The web browser was designed for navigating hypertext documents; it has adapted well to very simple business transactions, but not to more complex tasks. Alan Cooper made a useful distinction (see http://www.cooper.com/articles/art_your_programs_posture.htm) between 'sovereign' applications (used intensively) and 'transient' applications: his point being that they have very different user interface needs. The thin client architecture can often meet the needs of a transient application: Amazon.com and its one-click ordering is possibly the epitome of this approach. But a browser-based interface, with its strong sequentiality and modality, is totally unsuited to sovereign applications.
Sovereign applications are not just limited to those that the users deal with all-day every-day, such as order-taking, reservations and customer-service systems at call centres. An expenses processing program is sovereign: you might only touch it once a week or once a month, but the task of constructing a claim is often quite an intensive one. (All the more-so because the introduction of an expenses-processing system seems to encourage management to ask for much more data than they were getting on the paper version - the name of the hotel, the names of all the people you were dining with, the airline and flight number for the sector - because they now have tools to analyze it). A home banking system is a sovereign application - at least if you want to categorize and analyze your expenditure - as is an online grocery-ordering system. Such applications need the richness of a direct manipulation interface: allowing the user to engage directly with the elements that make up the business domain, and to undertake any legitimate action at any time and in any context.
Starting a couple of years ago, a number of analysts have been predicting the return of the rich client or the emergence of 'Rich Internet Applications' (RIAs) - see, for example, http://www3.gartner.com/5_about/press_releases/2002_04/pr20020402a.jsp or http://download.macromedia.com/pub/solutions/downloads/business/idc_impact_of_rias.pdf. New tools are appearing, such as Macromedia's Flex, that make it easier to build these RIAs . Each of these tools has its own strengths and its own application niches.
If you are building transient applications then three things are important: strong user guidance (because the users have little incentive to learn how to use the system), exciting visual design to attract the attention of browsing customers, and fast response so that they don't lose interest. Many of the new RIA tools are concentrating on these capabilities: especially the middle one.
For sovereign applications, however, the needs are quite different: fancy graphics are unnecessary and potentially irritating to the frequent user; strong guidance is less necessary because the users have more incentive and more opportunity to learn how to use the system. Indeed strong guidance can be a distinct negative: what the user of a sovereign application values most is a sense of being in control, and one of the keys to this is direct manipulation techniques. So why are direct manipulation interfaces so rare? In part it is because too many software designers think of applications only in transient terms. In part it is because writing a direct manipulation interface is really quite difficult.
Naked Objects changes that. All you write are the domain objects and you get a rich, direct manipulation interface for free. Many of the people who criticize the Naked Objects user interface are looking from the perspective of transient applications: it doesn't provide enough guidance, or it doesn't allow enough graphical customization. If all you want is a rich web application that offers simple transactions to occasional users then Naked Objects is not the optimal choice. But for sovereign applications the story is quite different. And as we demonstrated in (Challenging the Dominant Design of the 4-Layer Architecture) in addition to making it easy to build a direct manipulation interface, the Naked Objects approach results in a far cleaner object model, and applications that are much easier to change in response to subsequent unforeseen changes to business requirements.
The first part of the headline to this article ('Fat is the new thin') is tongue-in-cheek: we copied it from a recent headline in the fashion world.. But we do claim that by using Naked Objects it is possible to gain all of the advantages of a rich-client interface, without sacrificing the advantages of the thin-client approach - and with other architectural advantages to boot.
When we first started showing Naked Objects in late 1999 we got a lot of positive reactions, but the most common objection was 'we could never get this into our company, because we have a thin-client-only policy'. We still get that response, but much less frequently than four years ago. Now a growing number of people are learning that Naked Objects is a more effective way to build new sovereign applications, and some are investigating the possibility of using the framework to build new rich-client interfaces to existing applications. This works best when the existing application has a strong underlying object model that would make sense to the user: it took us only a matter of hours to build an effective demonstration of such an interface for the aforementioned engineering supplies company, because in their application the objects were so obvious and concrete.
Oh, and we've decided to have a go at the expenses processing domain. A screenshot from the prototype is shown below and we'll soon be releasing a demo version running remotely over the internet and showing the full approval cycle.
Different types of expense item (representing hotels, airfares, taxis and so forth) are dragged into a claim. You can copy any expense from a previous claim, or just drag one expense onto another to have it copy all the fields that aren't already filled. You can split and merge claims, or look up similar items in any context. We haven't been at it long and it's already quite nice to use. Perhaps too nice: it might encourage employees to file their claims early and often. ;-)