Naked Objects
By Richard Pawson and Robert Matthews

Introducing 'naked objects'

The benefits of naked objects

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:


(we've exagerated the method name to make the point) rather than as:


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.