Where's the beef?

Who Cares What It Does
as Long as It Looks Slick?

by Conrad Weisert, November 13, 2006
© Information Disciplines, Inc., Chicago

NOTE: This article may be circulated freely as long as the copyright notice is included.

A few years ago we began seeing a strange phenomenon in the specification and development of computer application systems: a shift away from emphasis on what the application does toward emphasis on what it looks like to an on-line user. That phenomenon followed and was very likely influenced by the emergence of graphical interface tools and languages, such as Visual Basic1.

That seemed especially puzzling in the case of information systems, still among the most common computer applications. An information system produces outputs in the form of reports or displays that contain information that its users need and want. That information constitutes the main, often the sole, purpose of the system. Nevertheless, I continue to encounter application development project teams well along in software development who are unable to show me a list of the output data items their proposed new system is to produce.

Specifying a proposed new system

While making a presentation to a professional society group several years ago, I reported that I had recently encountered several failed projects in which the process of specifying a new application had gone through these four steps:

  1. To start, model the main screen, i.e. the first thing an on-line user sees. Provide menus or buttons for the user to select which of the system's transactions or other principal functions he or she wishes to perform.
  2. For each of those system functions, model another screen. Use a form to capture user input. Provide further menus for the user to select subfunctions.
  3. Continue modeling screens until no lower-level functions remain.
  4. Develop program code to implement business rules and other logic behind the forms and other screens.
One may involve representatives of the sponsoring users at various points to review and approve the prototype screens.

Of course, I meant my anecdote to raise amused but serious concern about a growing requirements crisis. To my surprise, however, an earnest young man cornered me after the presentation. "But of course that's the way to specify and develop a system," he protested. "How else could you do it?"

What if we're going to buy packaged application software?

It's obvious that the four-step process process described above, like all iterative and incremental approaches, won't work at all if our intent is to develop requirements that might be met by a packaged software product. But often, the process of evaluating, choosing, and installing packaged software is even more interface-driven than custom development.

Here many organizations substitute a vendor demonstration for most of the requirements elicitation and documentation. Typical vendor presentations place great emphasis on the attractiveness and slickness of the user interface and gloss over detailed issues of exactly what their product does in specific situations. It's not unusual for executives in the buyer organization, after being impressed by such a demonstration, to make a commitment to buy and install the product. A project to do so is then formed. Not until the user training stage of the project or even parallel pilot testing do the new system's shortcomings relative to the users' real requirements come to light.

So, when should we design the user interface?

The look and feel of the user interface will affect the usability and acceptance of an application system, in particular:

Important as those things are to the success of a project, they have nothing at all to do with the functionality of a system. If a system doesn't do what the users need, the most elegant interface imaginable won't salvage it. But if a system fully satisfies its users needs, we can graft a wide variety of user interfaces onto it.

In theory it ought to be much easier to graft an entirely new user interface onto an existing system than to extend or alter the system's functionality. In practice, however, weak interface-driven design undermines our ability to alter the user interface after the system has been developed.

Consider for example a subroutine for processing a particular type of transaction. As we've noted in discussing input transaction specification that subroutine should know as little as possible about the source, entry mode, and external representation of its input data items. The identical subroutine could be used whether the input came from a GUI form, from a prompting dialog, from a telephone keypad, from another application's XML output, or from some other kind of batch record. Unfortunately, however, many new systems invert the logical module hierarchy, so that the transaction processing subroutine is subordinate to various "controls" belonging to a GUI form. Worse, the processing logic may be fragmented into pieces subordinate to multiple controls, making it impossible or prohibitively expensive to alter the user interface beyond cosmetic changes. This is an unavoidable result of the interface-driven approach to development that we described earlier.

Such an inverted structure, with the actual processing subordinate to the end-user input-output, is sometimes called an "application framework" by its supporters. That sort of application-framework design approach is in conflict with two well-established principles of software design:

Functionality first

Regardless of the process we use for gathering system requirements or the techniques we use for documenting those requirements, we should always start by specifying exactly what the proposed new system is to do. Once rigorous functional requirements have been approved by the sponsoring end users, we can evaluate packaged software products to identify candidates that support the required functionality. If we then elect to pursue custom development (in-house or contracted) we can then:

If we do that right, we should have a lot of flexibility in the final step, including the ability to provide more than one interface to assemble and submit transactions, such as:

1 -- Visual Basic® is a series of proprietary products from Microsoft, having little relationship to the original BASIC progamming language.

Return to IDI home page
technical articles
methodology material

Last modified November 25, 2006