|
In this section we address some of the questions that people often
raise when they are first shown the concept of naked objects - but
before they have started to use the framework for themselves. Most of
the questions relate to whether the approach is suitable for their
kind of systems or their business environment in general.
What types of business systems benefit most from being designed as naked objects?
Naked objects work well wherever:
- It is recognised that the resulting business system needs to
support a form of problem solving.
- There is considerable uncertainty in the business requirements
for the system.
One could argue that both of these apply to any new business
systems project, but the degree varies.
Systems at the customer interface are good candidates for a
problem-solving approach. That said, it must be recognized that the
empowering, expressive nature of the resulting systems assume a
reasonable degree of familiarity on the part of the user. We do not
claim that naked object systems are 'intuitive'. In fact, we subscribe
to Jeff Raskin's view that there is no such thing as intuitiveness (at
least in the way that most people mean), but only familiarity[Raskin2000]. If the users are customer service
representatives who interact with the system frequently, if not
continuously, then they will quickly become familiar enough with the
system to gain the advantage of having direct access to the objects. If
they use the system only occasionally, lack of familiarity may become a
problem.
For this reason, naked objects are seldom appropriate for systems
that will be directly used by the customers - they are probably better
off with a more scripted approach. There are some exceptions, such as
on-line banking combined with Quicken-style personal financial
management, or on-line grocery shopping. Both of these involve frequent
and quite intensive use, and it is possible to see how naked objects
could benefit both.
However, once you have developed a system from naked objects, there
is nothing to stop you from developing a more conventional scripted
user interface that invokes the capabilities of the same objects (on
the server) - either to provide restricted interaction for a specific
class of users, or to cope with the limitations of a browser interface.
The customer interface is not the only area that benefits from a
problem-solving style of interaction. Resource scheduling is another,
especially in the intersection between planning and operations.
Airlines, for example, have sophisticated tools for planning and
running the schedule. But when significant disruption occurs, caused by
a storm perhaps, the systems provide very limited support for
simulating and then executing live workarounds. Pricing and promotions,
trading, network operations, and risk management are also examples of
intense operational activities that demand a problem-solving approach.
Look also for anything that fits the value shop model of business:
project management, emergency response, campaign management, and so
forth.
Even where there is not an explicit demand for a problem-solving
style of user interaction, naked objects can be a highly effective
approach for any systems project where the system requirements are
uncertain. (In several projects of this nature that we've been involved
with, the sponsors have eventually recognized that a problem-solving
interface was actually one of the keys to success).
Our experience suggests that business systems projects broadly fit
into two categories: the engineering dominated and the requirements
dominated. (Some fit both categories; they are invariably a nightmare,
but fortunately they are rare). Engineering dominated applications
(such as a new credit card transaction clearing system, an airline
reservation system, or any form of infrastructural service) need a
rigorous, heavyweight methodology. But many new business applications
do not make heavy demands upon the technology. Instead, the challenge
comes from changing functional requirements, and even the purpose of
the system. Naked objects are particularly well suited to these
problems.
Doesn't expressiveness come at the expense of business efficiency?
If you have an absolutely standardized task then providing the user
with multiple ways of tackling this task will be less efficient than
optimizing the system to the one best solution. But the ratio of
non-standard to standard tasks is increasing, because problems that can
be completely standardized are either being fully automated, removing
the human from the loop, or, through the use of self-service
technologies, are being delegated to users outside the organization.
The armies of clerks performing high volume 'data entry' tasks are
disappearing fast.
Consider the example of checking-in at an airport. Self-check-in
kiosks are increasingly common. Passengers retrieve their bookings,
check their seat assignments or change them to any available seat, then
print out their boarding passes and self-adhesive luggage labels as
required. For everyone except those with out-of-the-ordinary
requirements, the kiosks save considerable time. As use of these
machines grows, a growing proportion of the passengers queuing at the
regular check-in desks have non-standard problems: excess luggage, a
routing change, or colleagues on different bookings they want to sit
with. It follows that the systems used by the check-in staff need to be
designed primarily for problem solving rather than optimized for the
routine transactions that are increasingly being undertaken on the
self-service kiosks.
At the DSFA, when the implemented system was first submitted for
user acceptance tests, one of the first users reported that he could
now process a 'standard' child benefit in just six minutes, compared to
twenty on the old system, and he could process a '16+ extension' (a child
staying on for further education) in one minute rather than five. This
was a single user's report, not a comprehensive analysis. But what is
interesting about this story is that the system was not explicitly
designed to optimize the handling of standard cases!
It is commonly asserted that power users prefer keyboard shortcuts
to mouse-driven operations. There is some truth to this, but it needs
more careful examination. One of the great ironies in the history of
personal computing is that the inventor of the mouse (Doug Englebart)
was not seeking to make computers easier for beginners to use, but to
make computers more expressive for power users[Englebart1968]. The mouse was only half of his invention. On the other
side of the keyboard lay a 'chording' device with five piano-style
keys, which the user depressed simultaneously in memorized combinations
to invoke different operations on the items being pointed at with the
mouse. In fact, the mouse (or equivalent pointing device) is a highly
efficient mechanism for assigning relationships between objects. But
keyboard shortcuts can sometimes be a lot more efficient than
mouse-activated pop up menus. This is something else that will be
provided in a future release of the Naked Objects framework.
Are our staff up to using this style of system?
Not everyone wants more responsibility or more freedom of
expression. Some may prefer the comfortable position of not having to
think. But business managers must not jump to conclusions about this.
As one systems manager of a bank told us during an interview: 'For
years we've told the users that they can't do anything unless it is
expressed in terms of the seven core transactions that our mainframe
banking system can support. Now we have this all-singing all-dancing
client-server system with a fancy user interface and guess what . . .
the users are complaining that they don't know what to do with it.
We've drummed all the creativity out of them!'
The whole concept of naked objects undoubtedly embodies an
optimistic view of the user's capabilities. It will not succeed
everywhere. But we find the opposite philosophy too awful to
contemplate.
At the end of the day, we must all recognize that any transition to
a more empowered style of working requires a great deal of education,
and may dictate a transitional period where there is more guidance and
handholding. As we said earlier, if you design a system from naked
objects, then it is always possible to layer scripted procedures on top
of those objects - in fact they are very easy to write. But if you
design a system around scripted procedures, you will find it very hard
indeed to make the system more expressive later.
How can we still implement necessary business controls?
All of the examples contained in this book show some form of
business controls in operation: you cannot create a Payment except in
the context of a Benefit Scheme that has been signed off by an
Officer; you cannot violate the minimum connecting time between Flight
Segments at any Airport (at least not within a single Booking); you
cannot create two different Price Adjustments on the same Product
Group, unless they are of the Cumulative type. With naked objects these
controls or constraints must be implemented within the business
object(s) to which they apply. By contrast, most business systems
enforce controls at the level of the scripted interaction. Enforcing
them at the level of the business objects not only gives the users more
freedom to invoke the objects in the order that best suits the problem
they are addressing, but actually permits a stronger level of
control.
This approach will not be welcomed by advocates of 'rules-based'
systems design, where the principle is to extract all business rules
into a separate representation so that the rules can more readily be
changed. We do not like that approach for two reasons. The first is
that you can end up with an awful lot of rules (even down to the level
of checking the validity of a date), with the result that finding all
the rules affected by a proposed business change can actually be
harder. The second is that the rules-based approach seems to encourage
those whose goal is to remove all decision rights from the
users.
Implementing a rule or constraint inside the object or the
relationship to which it applies makes it easy to find when it needs to
be changed. And if you practice the disciplines of writing code that is
easy to read and alter, then the rules will be easy to edit.
How do you get around the need for dialog boxes?
Designing systems without access to dialog boxes is quite a
challenge. It is even more extreme than not allowing the separation of
entity and controller objects. But once you accept these constraints,
it leads to better object modelling.
Consider the example of a banking system - a perennial favourite in
object textbooks. Account is clearly an object, and it is natural to
think of Checking Account and Savings Account as specialized
sub-classes. A conventional use-case analysis will suggest that all
Accounts will need methods for depositing, withdrawing, generating
statements and applying charges, amongst others. But how should the
system handle a transfer of funds between accounts?
Many people argue that this functionality belongs in some kind of a
process, not to either of the Account objects.
If we don't allow the addition of scripts or controllers on top of
the entity objects, then another option is to implement
TransferTo(Account, CurrencyValue) as a method on both the Account
classes. This could then generate a dialog box wherein the user could
specify the Account to be transferred to and the amount. But the Naked
Objects framework doesn't support dialog boxes. It can translate a
zero-parameter method into an action on the pop-up menu for that
object, and realize a one-parameter method by dragging one object onto
another. But it cannot translate a multi-parameter method into a user
action.
The solution is to implement Transfer as a class of object in its
own right. Its attributes are the two accounts, the amount to transfer,
and the date/time. The methods on the two account objects then become,
effectively, 'Create New Transfer', which creates a new instance of
Transfer, ready populated with the 'from' account. Alternatively, the
user could shortcut this by dragging one account onto the other, which
returns a new Transfer object with both the 'from' and 'to' fields
populated. After specifying the amount to transfer, the user then
invokes the 'Execute' or 'Make it so' method on the Transfer
object.
Critics will say that all we have done is created a Transfer
process, or even a Transfer dialog box, and called it an object; but
they are missing an important point. Because each transfer is now
modelled as an instantiated object, it can be directly referred to in
future, for purposes of audit, or even reversal. In fact, for our
banking application, Withdrawals and Deposits should similarly be
treated as noun-objects not as verbs. (It would be legitimate to refer
to all of these examples as 'form' objects, where the form provides a
permanent record of that instance of a process). If you treat each of
those concepts as merely a verb or process then you cannot refer
directly to, say, a particular withdrawal, but must reconstruct it, in
effect, from the audit trail.
Many good object modellers would have seen that solution
immediately. For the rest - Naked Objects will not automatically
present them with the best solution, but it will make it considerably
harder to implement some of the poorer ones.
How can Naked Objects meet the requirement for multiple views?
Using Naked Objects, all user views are generated automatically
from the business object definitions; but it is a common requirement
for a system to provide multiple views of the same business object. How
does Naked Objects address this?
We need to distinguish two different kinds of alternative views.
The first we shall call multiple representations: we might want to view
a collection of objects as a list, or as a table, or perhaps as a
graph. The Viewing Mechanism that forms part of the Naked Objects
framework already provides several alternative generic views of
objects. The default view is a small icon. The 'opened' view lists the
attributes and shows all the associated objects as active icons.
Alternatively, an object can be portrayed as plain text, or, if it
implements the 'hasImage' interface, it can be displayed as an image.
Collections of objects can be shown as a single icon or a list. If the
objects in the list are all of the same type then the collection can be
viewed as a table, or a tiled layout of images. If the objects in the
collection implement the 'mappable' interface, then they can be located
on a two-dimensional geographic or schematic map. All of these generic
views are automatically provided, without any explicit programming, and
users can select any of them. This capability is conceptually the same
as the Windows (or equivalent) capability to view the contents of a
folder as icons, a summarized list, thumbnails or details. We expect
that a broader range of generic views will be added in time - for
example, the ability to view any array of numbers as a chart, as in a
spreadsheet application. Capable programmers can extend the framework
themselves to add new kinds of generic views.
The second concept we shall call selective views: providing the
user with a partial view of an object, showing only certain of its
attributes, associations, and methods. This may be because a certain
user is not authorized to see other information, or simply in order to
reduce screen clutter.
The Naked Objects framework does permit you to customize views
through the use of About objects - you can specify which attributes,
associations and methods are available to a given user or role. The
same mechanisms could also be used to control the view, or behaviour,
of an object according to its state (where that state is either
explicitly represented, or derived from other attributes and
associations).
But in general, the idea of designing systems from naked objects is
to avoid too much contextualizing. The aim is to give the user as rich
a potential view of any object as possible unless the screen gets too
cluttered. This is in marked contrast to the usual approach to systems
design, which is to give the user the minimum information necessary to
complete a particular task - thereby limiting the users' opportunity to
learn to see the big picture.
A positive side effect of naked objects is that they help to
preserve the integrity of the object model. For example, a
conventionally-designed system may display on an invoice the name and
address of the customer, which will have been extracted from the
Customer object. Whilst this may not be breaking the rule of
encapsulation in the technical sense, it is certainly damages the
user's understanding of the object model. Using naked objects, the
Invoice will not display the customer's name and address as separate
fields: it will display an icon representing the Customer within the
Invoice. To check, or alter the customer's address, the user must open
the Customer object and make the alteration there.
How do you avoid shared business objects becoming 'bloated'?
If the only way that the user can invoke an action is by selecting
a method upon a core business object, and if objects are going to be
shared across different uses or departments, then aren't those core
business objects quickly going to become bloated with methods,
attributes and associations?
An object with too many methods, attributes and associations smells
suspiciously like a monolithic program - suggesting that agility will
be reduced. The answer, in most cases is to use the technique of
aggregation: split a single object into natural components, even if
those components are never accessed outside the context of their parent
object, and aggregate those components. Thus, the Customer object might
have components to model the Identity information, Medical history, and
so forth. This also helps with performance. An object with too many
attributes takes a long time to load into memory from secondary
storage. Using aggregation, the object can choose to load only pointers
to its component objects, and load their attributes only if a component
object is to be viewed by the user, or invoked by a method on the main
object.
Can Naked Objects work in a 'thin client' architecture?
More and more organizations claim to have adopted a 'thin client'
policy, but the meaning of that term varies considerably. To some
people it means that every application must run within a browser; but
then to some large plug-ins are acceptable, while to others they are
unacceptable; and some even take the view that the client must run pure
HTML, with no Java code. Alternatively, thin client may not imply
operation within a browser, but within other architectural or hardware
constraints.
The Naked Objects framework can work within any of these
constraints - although this may involve writing an alternative generic
viewing mechanism for your preferred client architecture. For example,
a pure HTML implementation might portray each object as a web page,
with the action methods shown as buttons. Drag and drop would not be
possible, but point and click would be. Multiple panes, including a
tree view of recently visited objects, would permit all the same
operations to be conducted. But it would not feel nearly as expressive
to the user.
However, we believe that the 'thin client' idea (or, at least, most
interpretations of it) needs to be challenged. When first proposed, the
idea of running everything within a browser held considerable appeal,
because it eliminated the need to maintain software directly on client
machines. But there are now several technical means of achieving this
goal. Another motivation was to provide a standardized user interface
environment, but, as we have seen, there is very little standardization
in the user interaction model offered by different browser-based
applications. Moreover, the basic HTML interface is not a good
interface for undertaking any kind of problem-solving activity. It was
intended only for browsing published information. Transactional
capabilities have gradually been added, but they are something of a
kludge in user interface design terms. The third motivation for
standardization on a browser interface is for consumer access. However,
naked objects are best suited for frequent-use applications, which
primarily means in-house users.
Would Naked Objects permit users to develop their own applications?
Many people have pointed out that whilst naked objects improve the
expressiveness of the system for the end-user, the Naked Objects
framework does not do the same for the developer. Why make the
developer write code in a text editor, when much of the initial
development could also be done with techniques such as drag and
drop?
For several reasons. The first is that we were anxious not to let
the idea of developer expressiveness and end-user expressiveness become
confused. Tools such as VisualBasic already offer a great deal of
expressiveness to the developer, but the user interfaces that result
are frequently not very expressive for the end-user. By deliberately
contrasting the developer environment and the end-user environment, our
aim was to keep the developers focussed on creating expressive systems
for their users, not for themselves.
Secondly, it's not clear that graphical representations and drag
and drop (or equivalent) gestures are particularly relevant to
developers. Certainly, they are relevant to designing screen layouts, but
the whole idea of Naked Objects is that you don't design screen layouts
- they are auto-generated by the system. Graphical representations can
also help developers navigate around large amounts of code; but so too
do state-of-the-art integrated development environments such as
VisualAge, Eclipse, or TogetherJ which can all be used in conjunction with Naked Objects
to develop applications. All that's left is writing functional code
in a programming language such as Java. At this stage, graphical
representations add little value - what the developers benefit from
most at this stage are advanced code-support tools such as automated
test suites and refactoring browsers.
We think that attempts to make programming an entirely graphical
operation are misguided. They are generally aimed at end-user
programming; but is that what we need? Naked objects were conceived to
support problem solving by end-users, not programming by end-users.
Problem solving means finding a solution for a single specific context.
Programming involves finding an abstract solution to a whole class of
problems. These are different skills. The spreadsheet is an
extraordinarily powerful tool for solving individual problems and is
simple to use, but writing a spreadsheet template that is robust enough
for others to use too requires a different degree of discipline. Is
that what we want end-users to be doing?
|