Introducing 'naked objects'
Frequently Asked Questions
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:
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?
Copyright (c) 2002 nakedobjects.org You may print this document for your own personal use, or you may copy it in electronic form for access within your organisation, provided this notice is preserved.