Now and then, in a few of the old schlock science-fiction films, one will catch a glimpse of stitches or a zipper running down the back of an alien mutant's supposed skin. In object-oriented software development, despite frequent claims to the contrary, the seams are often no less visible than on the shoddily costumed bug-eyed denizens of a cheap sci-fi flick. If we judge the process by the end product, the promise of seamless object-oriented development remains largely unfulfilled.
Seamless development, according to the modern mythology of object technology, delivers better software through a simpler process. How? One common and consistent set of constructs—the concepts of the application domain as construed by real users dwelling in that fabled land of the real world—are carried throughout the entire development process, informing the models through which developers analyze and resolve their problems and ultimately becoming embodied in the very structure of the code itself. By thinking in objects, recirculating a single set of ideas through all activities of the process, developers simplify their work. So the public relations go.
However, developers are not the only ones who would stand to gain from a seamless development process were it ever to materialize on this planet. Much of my work focuses on improving the lot of users, saving them from suffering and humiliation at the hands of bad software with incomprehensibly alien user interfaces. Users have a stake in the fruits of seamless development. The constructs of the application domain that inform the classes and objects of the software can be, in turn, reflected back to the user in a user interface that is itself organized from those very terms. Mirabile dictu, the product of a seamless development process oriented by the objects of the user's world is a product that speaks the user's language and presents itself as a recognizable extension of the world within which the user works. It collects together those things that are thought of together or employed together by the user. (See Chapters 24 and 48.)
Users and developers alike have a stake in software that is easier to master and requires less ongoing technical support, but many organizations have found it hard to improve the usability of their products. Organizations fail to deliver usability to their users and customers for many reasons, but there are common barriers to success in this realm. In some cases, the organization itself is the problem, in others, the methods are ineffective, and sometimes the tools are to blame.
Some organizations fall victim to their own lack of real resolve. As long as an idea does not cost anything or take any time, these organizations are as ready as any of their competitors to hearken to the voice of the customer or to fit the interface to the user. Such groups may talk the talk, advocating intelligent user interfaces or user-friendly software, but, lacking a consistent and appropriately focused organizational commitment to usability, they never quite walk the walk. Increasingly, I also encounter organizations where the developers are more committed to improving software usability than their management. Management will not invest in training. They do not consider usability part of the job of software developers. They prefer more features to more usable software.
Other development groups, though fully committed to enhancing software usability, can be hampered by inadequate methods, relying, for example, on testing to discover usability defects instead of on good design to avoid them in the first place. They may be prepared to invest in usability, but are uncertain about where to invest. In some ways, these are the easiest groups to help, because they already have the will to proceed and the willingness to commit resources. They need only to be shown the way. Once they learn how to apply effective models, they can achieve dramatic gains in end-product usability.
Even a full and focused commitment to usability and a well-structured process may not be enough, however. Often, modern development tools are themselves impediments to delivering on the paired promises of software usability and seamless development. The tools not only do not support a truly seamless development process, some of them make it difficult to pursue a systematic, model-driven approach to usability engineering.
Software development tools continue to improve dramatically, particularly in the form of visual development tools. Visual development tools—from Visual Basic and Delphi to Visual C++ and J-Builder—represent a major advancement in software and applications development, not just as technology but also in terms of how such tools fit with the way human beings solve problems. The best of these tools make it easy for developers to move back and forth between the visual representation of the software on the user interface and the underlying code, to think in visible objects or in invisible code as suits the problem at hand.
Where the seams in the tools begin to show is between the user interface and the models by which developers represent objects, communication, and tasks. The promise of full and complete integration, raised in Chapter 23, is not materializing. Modeling tools are still just modeling tools and development tools are just development tools. Even where they can import each other's files or share information through an API, the zippers and stitches are often painfully obvious. Even worse, key connections and relationships fail to be recognized by the tools. For example, use cases are widely acknowledged as an important model for object-oriented development and are supported by some modeling tools, but the connection of use cases to the user interface is unrecognized by most such tools and remains solely in the minds of developers.
What, then, do we need from our tools in order to produce highly usable software through a seamless development process? We need the tool vendors to think outside their traditional boxes. We need them to understand view-based development, an idea that has been waiting a long time to be recognized (see Chapter 18).
A software system can be viewed from different perspectives. Each view or perspective highlights certain features or aspects of the system, while ignoring or de-emphasizing others. A process model, such as the venerable flowchart, handily conveys the structure of algorithms but shows little or nothing of data. A domain model effectively represents object classes and their relationships but is useless for screen layout. That the common models employed in software engineering are so focused on specific aspects is not a failing but a strength. Each view simplifies the system for some purposes, making it easier for developers to talk about and think about a particular issue or kind of problem in the course of producing the software.
The user interface itself is just one view of software, representing the software as actually seen by end users. A content model provides another view of the user interface as seen from the designer's point of view, modeling its contents apart from their visual appearance or manifestation within any actual graphical user interface (Constantine 1998). A context navigation map provides a representation of all the component parts of the user interface along with their interrelationships. (For more about content and navigation models, see Chapter 44.)
Even help files and documentation are really just alternative views of the underlying software. Although these views are often thought of by developers as an ancillary annoyance, both are actually parts of the user interface, since they mediate between users and the system. In practice, the ultimate usability of software depends not only on the quality of screen layout and of dialog design, but also on the quality of help files and manuals.
Of course, all of the models or views of a given system are intimately interrelated. After all, they describe a single system. Visual objects on the user interface are linked to internal objects and their methods, for example, and abstract components in a content model are manifest as particular user interface widgets. Various interaction contexts—windows, forms, dialog boxes, and the like—are linked by transitions that are achieved through selection of specific user interface widgets. Use cases not only model the interaction between users and the system but also imply interaction among communicating software objects.
In the rare case where online and offline documentation are current and accurate, these, too, are tightly tied to other views. They describe the visible and nonvisible features of the system using that same common vocabulary employed in the object model and reflected in the user interface design. They inform users of the use cases that they can accomplish through the software.
In a view-based perspective on software development, the objective of the developer is to build the software by completing the various views that describe and specify it. The objective of the development tools should be to support creating the underlying software while maintaining consistency between the code—one view—and all other views. At every moment, any view is a valid way of examining and modifying the system. Change the code and the represented interface changes. Alter a model and the code changes. Create a new content model and an empty form appears in the interface view. Add a use case and another entry is created in the help file. The developer who is stymied in one view can instantly shift to another and proceed.
One of the payoffs of a view-based development process supported by adequate tools is enhanced traceability. Everything in the software being developed is interconnected with the models and documentation describing it, right back to the original requirements.
While the developer is laying out the widgets of a particular form or dialog box, the use cases to be supported within that interaction context should be visible. In fact, the connection between each step in a use case and the widget or widgets used to enact the use case should be known to the system. If a content model has been created as an abstract view intermediate between the use case model and the user interface as implemented, it should be available to the developer while the user interface is being laid out with the visual development tool.
In general, it should be possible, from moment to moment, to move from one view to another, through linkages that are visible to the developer and known to the system. The developer should be able to see all the use cases supported by some interaction context within the user interface by no more than a click or a selection. Conversely, it should be possible to point to a step in a use case and get to the visual component or components that realize it or to drill down into the object model to see how it is implemented by objects.
In the course of solving a problem in one view, the developer may find it convenient to switch to another view that is more conducive to working out a solution. The developer should not have to generate code to see the working results nor reverse engineer a program to see the models. It should not be necessary to export models in one tool and import them in the next. All views need to be maintained in complete synchrony by an integrated development environment.
Many analysts have begun employing use cases as a core model for defining requirements. In an appropriate development environment and process, use cases support end-to-end requirements tracing. The use case model links most of the other views of interest in the development process. It ties back to the model of user roles on which it ultimately rests. It connects to the content and navigation models representing the abstract structure of the user interface, and, of course to the user interface itself. It is linked to the object class model or data model in its vocabulary and to the object communication model for software internals. It maps to the help that documents for the user the available use cases and how they are enacted. It is connected with test cases for regression testing and acceptance testing, as well as the scenarios for usability testing.
True, some software development tools support parts of this view-based development approach, but all fall down at one point or another, most particularly in bridging between use cases and object models on the one hand and the visual design of the user interface on the other. This is the crucial seam when it comes to producing highly usable software. It is time we ironed it out.
From Object Magazine, December 1997.