Java Development News:

Part 5 - Building Rich Internet Applications with Naked Objects

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).

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.

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. ;-)

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.