The Naked Objects framework directly encourages the design of
behaviourally-complete business objects. But what is the net benefit?
Behavioural completeness may satisfy some intellectual objective, but
does our approach deliver any concrete business benefits?
Our experience to date has demonstrated four such benefits:
- Naked objects can better accommodate future changes to business
requirements.
- Naked objects empower the user.
- Naked objects improve communication between developers and
users.
- Naked objects can speed up the development process.
We'll look at each of these in turn.
Naked objects can better accommodate future changes to business requirements
Systems built from naked objects are more agile, in the sense that
they can more easily accommodate future changes to the business
requirements - changes to product specifications, the organization
chart, internal rules and external regulations, business processes, and
relationships with suppliers and customers.
There are many techniques for building greater agility into
business systems. A common approach is to identify the thing that is
most likely to change, extricate it from the workings of the system,
and represent it in explicit and editable form. Workflow and other
business process modelling tools extract a representation of
the flow of work between people and between systems and make it
editable. Rules engines do the same for, say, product configuration
rules. However, the limitation of this approach is that business
changes don't often fit into neat parcels.
An alternative approach is to break up the whole system into
fine-grained components, of many different kinds, and then use a
general-purpose architecture to stitch them together into usable
systems. This, in essence, is the web services approach. Whilst this
technique may offer more flexibility than huge monolithic systems, it
is a fallacy to assume that finer-grained equals more agile. A
seemingly simple business change can easily require modifications to
dozens of components - and if those components are not well isolated
from each other, there can easily be a domino effect.
There is no such thing as a general-purpose representation that can
effortlessly accommodate any kind of unforeseen change. However, good
object modelling is probably the closest you can get towards this
ideal. This is because when object modelling is done well, the
responsibilities of the objects are not driven primarily by the
specific business requirements. Instead, the designers aim to identify
the inherent responsibilities that can be envisioned for such an
object. The initial implementation of those responsibilities may be
optimized to the immediate need, but the more abstract notion will have
been preserved in the design.
Take a simple example: it is natural when specifying a Customer
object to state that it needs to know the postal address of the
customer. But a responsibility-driven approach would suggest that the
real responsibility of a Customer object should be to know how to
communicate with the customer (even if the first iteration of the
system will cover only postal communication). If the object's message
interface is defined as:
communicateViaTheCustomersPreferredChannel(thisContent)
(we've exagerated the method name to make the point) rather than as:
getPostalAddress()
then if new forms of communication are introduced (e.g. email, fax,
instant message) only the code defining the Customer class need be
changed. All the other business objects that need to communicate with
the customer can continue to call the same method on the Customer
object without having to worry about specifying which of several
options to use (although the option of specifying the channel could be
added). As Alec Sharp observes: 'Procedural code gets information then
makes decisions. Object-oriented code tells objects to do things.'[Sharp1997]
Naked objects empower the user
Empowerment is a much-abused term in business. Often it is merely a
euphemism for downsizing, de-layering or plain old-fashioned
delegation. But the fact that it is often abused does not negate the
importance of the idea. To understand what naked objects contribute we
need to look more closely at the fundamental nature of empowerment.
Andrew Clement argues that empowerment takes two distinct forms:
functional and democratic [Clement1996]. Functional
empowerment 'is oriented to improving performance toward organizational
goals that are assumed to be shared unproblematically by all
participants' - for example, when a customer service representative is
given greater authority to resolve a customer's problem in the
interests of customer retention and the firm's reputation. Democratic
empowerment (we prefer to call this 'intrinsic' empowerment) has to do
with giving the individual a 'greater grasp and sense of their own
powers'. It is done in the interests of the individual and is not
oriented towards achieving any explicit external goal, though there may
be an indirect benefit to the business in improved motivation and staff
retention. Intrinsic empowerment is clearly a more subtle and elusive
notion. Most initiatives aimed at strengthening empowerment are,
despite the rhetoric, purely functional. Clement claims that 'For
empowerment to offer an authentic promise of enhancing work experiences
and outcomes, it needs to combine the attention to job effectiveness
aspects of the functional approach with the emancipatory aspirations of
the democratic approach.'
How naked objects support functional empowerment
The principal way in which naked objects support functional
empowerment is by reducing modality. Most systems are strongly modal,
and this can often infuriate users. The oft-told story of the Bravo
word processor illustrates one form of this problem: if you typed the
word 'EDIT' whilst in the wrong mode, it would be interpreted as
'select Everything; Delete it, then Insert the letter 'T'![Hiltzik1999] A more commonplace form of the problem
occurs in many transactional business systems where users are forced to
complete one task script before they can initiate another. Discrete
applications are themselves a form of modality: users have to switch
applications to invoke a particular function or piece of
information.
Apart from causing frustration, modality can be functionally
dis-empowering because the modes often cut across the way in which the
user thinks about the problem, or the order in which information
becomes available. Task oriented user interfaces, as discussed in
(ection 1) are always strongly modal. Modality cannot be eliminated, but if designers are
conscious of the problem, they can make it less obstructive.
One of the most effective ways to reduce modality is to adopt the
'noun-verb' form of interaction. Almost all core business systems today
follow the opposite 'verb-noun' style of interaction: the user selects
a verb or task from an initial menu (such as 'Modify customer record'
or 'Register new claim') and then supplies the data needed, in response
to the system's prompts. In a noun-verb style of interaction, the user
selects a noun and then chooses one of the available verbs to apply to
it. The desktop metaphor adopts this style of interaction: the file
icons represent nouns and the right-click pop-up menus provide the
verbs such as Open, Print and Mail. However, most applications launched
from the desktop show much less commitment to the noun-verb form.
Although noun-verb interaction is not necessarily more efficient than
verb-noun, there are several arguments suggesting that it is closer to
the way people think, especially in problem solving activities.
The noun-verb style of interaction fits well with an
object-oriented user interface (OOUI). But tools to support the design
of OOUIs (as distinct from object-oriented tools to support the design
of conventional GUIs) are few and far between. Naked objects, by
definition, provide an OOUI. The Naked Objects framework enables you
to produce this OOUI automatically from the business object
definitions.
Functional empowerment, or treating the user as a problem solver,
does not imply the elimination of all constraints. Certain rules need
to be enforced for both legislative and business reasons. But when the
business objects are naked, all such rules and constraints are
encapsulated into those objects rather than being associated with
scripts or procedures that sit on top of them. This is a better
solution all round. It gives the users much more freedom to decide how
to go about tackling the problem. It forces the designers to
distinguish more clearly between an absolute rule and a mere procedural
convention. And having decided that something is an absolute rule,
embedding it into the business object it applies to makes it much
harder for users to circumvent it. The panel illustrates the perils of
using scripted procedures to implement business rules rather than
encapsulating them in the underlying object.
How naked objects support intrinsic empowerment
Brenda Laurel states that 'Operating a computer program is all too
often a second-person experience: a person makes imperative statements
or pleas to the system, and the system takes action, completely
usurping the role of agency.'[Laurel1991] Over time
this has a subtle but cumulative impact on the users' sense of their
own self-worth and motivation. Naked objects contribute to the users'
sense of intrinsic empowerment by seeking to give the user a
first-person experience.
Taking this a stage further, Hutchins, Hollan and Norman state that
'There are two major metaphors for human-computer interaction: a
conversation metaphor and a model world metaphor. In a system built on
the conversation metaphor, the interface is a language medium in which
the user and the computer have a conversation about an assumed, but not
explicitly represented world. In this case, the interface is an implied
intermediary between the user and the world about which things are
said. In a system built on the model world metaphor, the interface
itself is a world where the user can act, and that changes in state in
response to user actions. . . Appropriate use of the model world
metaphor can create the sensation in the user of acting on the objects
of the task domain themselves.'[Hutchins1986]. They
might have been describing naked objects!
The Naked Objects framework provides mechanisms that reinforce the
model-world metaphor and that make it positively difficult to adopt the
conversational approach. For example, the reason why the framework
makes extensive use of drag and drop has nothing to do with efficiency,
but is because physical gestures aid this sense of direct engagement or
intrinsic empowerment.
Physical actions aid understanding and memory: child psychologists
tell us that children develop a stronger mental representation of
things that they can physically move than things that they can't - what
Bruner called an 'enactive representation'[Bruner1966]. (Bruner's ideas were one of the inspirations behind
the work of the Learning Research Group at Parc[Kay1990]). As children develop they make
increasing use of the symbolic and visual representations, but enactive
representations still play a role. Take the situation where two people
are travelling by car to a new destination: one is driving, the other
is navigating by reading the map, observing road signs and giving
directions. Ask both individuals subsequently to follow the same route
from memory and it is the driver who finds the task easier: the
movement of the muscles play an important role in memorizing where to
take the necessary turns.
The Naked Objects approach seeks to avoid verbal messages wherever
possible. Rather than waiting for the user to make an error then
popping up an intrusive error message, it prevents the user from making
the error. For example, dragging an object across a series of fields
will cause each field to colour red or green to indicate if the object
can be dropped there.
Finding ways around verbal messages requires some creative
thinking. The best way to avoid annoying 'Are you sure?' messages is to
provide the user with a generic 'undo' function. But there are
situations where this would be very difficult to implement - what then?
In the physical world, if a button or switch has serious consequences
it is usually coloured red, and if it has very serious consequences then
it will probably have a flip-cover. Putting a mouse-operated flip cover
over a software button or menu command would be easy: it would have the
same positive effect as an 'Are you sure?' message, but without the
sense of intrusion, or patronization. (We hope to implement this in a
future version of the framework.)
We do not claim that the user interface produced by the Naked
Objects framework is the epitome of user friendliness, at least in the
conventional sense of that phrase. There are well-established design
principles (such as Shneiderman's 10 golden rules [Shneiderman1998]) and specific techniques for
designing user interfaces that are more aesthetically pleasing, more
efficient in terms of the number of mouse-clicks or keystrokes required
to perform a task[Raskin2000], easier for the
beginner to understand, and less prone to user error. We have adopted
some of these principles; we could do more. But some are incompatible
with the auto-generation of the user interface that is part of our
approach. Some commentators have been strongly critical of the Naked
Objects framework for this reason.
Yet users continue to tell us that they really like the systems
that have been built using the framework. We conclude that what they
like is the sense of empowerment, both functional and intrinsic, that
naked objects provide, and that they value this more highly than
conventional notions of 'friendliness' and optimization.
Auto-generated user interfaces inevitably have limitations, and
some applications will require a handcrafted user interface - although
it will interface to the same business objects. However, as the case
studies in this book testify, the Naked Objects auto-generated user
interface has proven to be both highly effective and broadly
applicable.
Naked objects improve communication between developers and users
The first and most noticeable benefit of using our approach to
design and development is that the naked objects facilitate
communication between user and developer.
It has long been claimed that object-orientation bridges the
communication gap (sometimes called the 'semantic gap') between users
and developers. But in practice this has meant bridging the gap between
different stages in the software development cycle - for example
between analysis and design - not between what the user speaks about
and what the programmer codes. The end user representation of systems
developed using object-oriented techniques is seldom itself
object-oriented. Conversely, in many systems that have object-oriented user
interfaces the objects seen by the user do not necessarily mirror the
objects in the business layer.
Naked objects provide a genuine common language between the
developers and the end users of the system, and this makes it a lot
easier for users to become involved in the design of the system, which
is one of the tenets of most modern development methodologies.
In all the projects where we have deployed this approach, the users
involved in the design process have quickly become comfortable with the
language of objects. This is not limited to the idea of business
objects (such as Customers, Products, Orders, Payments, and so forth)
but also with concepts such as 'instance', 'class' and 'subclass',
'instance method' and 'class method', 'attribute' and 'association'.
After only a few hours of involvement in a Naked Objects project, the
users start to express their ideas and requests for new functionality
in object terms: 'Would it be possible to have a new action on the
Promotion object to visualize the leaflet?'; 'We need another sub-class
of Store to represent our Petrol Filling Stations'; 'I want to be able
to associate an individual Payment Method (object) with each different
Benefit (object), not just with the Scheme (object) overall'; and so
forth. The naked objects render the core business objects visible to
the users, so users talk of them quite naturally.
Contrast this with the normal state of affairs, where users specify
requirements in terms of alterations to processes: new menu items, new
reports, alterations to forms. Someone (maybe the developers, or maybe
an intermediary such as a systems analyst) must translate such requests
not only into the changes needed to the underlying data and functions,
but into all the screens and user interaction controllers that are
affected.
Naked objects can speed up the development process
The fact that the user interface is auto-generated from the
business object definitions makes it possible to prototype very
rapidly. Using our framework, simple requests for changes to the
prototype (such as a new attribute, association, or a simpler method)
can often be implemented in real time, in front of the users who are
making the suggestion. Not all the prototyping can or should be done
that way - sometimes it will be necessary to break for a couple of
hours or a couple of days, to knock up the necessary code. But we have
found that it is possible to get through many iterations in the time
that most approaches would permit only one.
The idea of rapid prototyping tools is hardly new, but with most
such tools you are merely developing the user interface. With naked
objects you are prototyping the underlying object model at the same
time as the user interface, because they are effectively the same
thing. During the prototyping, all the attributes, associations and
methods are rendered immediately visible to the user. (The finished
system may hide some of them again, but that comes later). This has the
advantage that the prototype itself documents the object model.
Anything that can eliminate documentation will be welcomed by
development organizations. An outsider observing most software
development methodologies in operation could be forgiven for thinking
that their purpose was to generate documentation. The tasks of
creating, editing, formatting, circulating and checking these documents
consume huge amounts of time and effort. But the real problem with
documentation-heavy methodologies is keeping the documents consistent
with each other. The more recent 'agile' methodologies typically
generate less documentation overall, and fewer types of document that
need to be kept in synchronization.
|