Excess Functionality

Author: Alan C. Dube

Date: 8/19/95

Excess Functionality as a Design Problem

Introduction

Computer systems are more powerful than ever before. Advances in hardware technology and software applications allow system users to accomplish many tasks in a short period of time. However, as users become more efficient with the systems they utilize, they demand more functionality from them. Companies that view information technology as a competitive tool strive to maximize their employees' productivity while gaining the highest return on investment from their systems. Hardware and software designers, in order to respond to these market-driven pressures and keep pace with their competitors, continue to develop and release increasingly complex applications. Therein lies the paradox: As systems evolve from a simple to a complex model, they often become excessive in functionality and harder to implement, maintain, learn, and use. This paper will define what "excess functionality" is, discuss the problems it creates within computer applications, and suggest ways to reduce these problems. The discussion will close by raising new issues to investigate concerning the functional design of computer systems.

Excess Functionality Defined

Laurel (1991) refers to functionality as what a computer program or system "does" and suggests that the definition of functionality "needs to be reconceived as what a person can do with a program, rather than what a program has the capacity to do" (p. 44). Excess functionality exists within a computer application when a task cannot be accomplished quickly and efficiently by a user due to the complexity of the product and the overwhelming number of functions within it. It is also evident when the user has to spend an inordinate amount of time mapping the application to the task, instead of mapping the task to the application.

Problems Within Computer Applications

Implementation and maintenance of excessively functional systems is a considerable challenge. Shneiderman (1992) points out that excess functionality means more code, error messages, and manuals to maintain, as well as introducing a greater chance of software bugs and slower program execution. One only has to look at the recent experiences of the software industry as a whole for proof of these assertions: New products and software releases have been rushed to market, only to be met with harsh criticism and bad press when the applications are found to be defective. Then the software suppliers are forced to quickly issue bug fixes, and the cycle continues.

When a computer application is first developed and released, much attention is paid to user ergonomics and task definition. When upgrading an application, designers seem to concentrate most of their efforts on backward compatibility with prior releases. This is usually done at the expense of incorporating the new improvements and functions of an application effectively from the user's point of view. Screen layouts and menu selections are often radically changed to allow for the new features, and documentation keys on how to "convert," when it should focus on how the application's functions will help the user to accomplish a task.

System designers often propagate the misconception that more is better. Be it a graphical, direct-manipulation interface or a textual, menu-driven application, software designers continue to confuse the user with a myriad of icons, button bars, and Alt, Ctrl, and Function key-driven features. The designers assume that users are motivated to learn new features and will do so by using the extra documentation, on-line help, or flashy tutorial provided. The issue of retention poses a major problem to this assumption. Requiring users to remember too many event sequences can have an adverse effect: they will not use features that are confusing and difficult to engage and will adapt their work habits accordingly. This defeats the purpose of "improving" the system in the first place.

If complex applications are difficult to implement and learn, to what degrees of success are they effectively used? Some of the data and industry information available in this area indicates that users do not take advantage of all that an application has to offer, and sometimes seek other ways to better use or improve an application's metaphor. A study conducted of 17 secretaries who used IBM's XEDIT editor showed that of the 141 commands available in XEDIT, only an average of 26 were used by each participant (Rosson, 1983). Products such as X/Soft's TabWorks and Apsley-Bolton's Easy Notebook Office are gaining in popularity because of what they allow the user to do: abandon the Microsoft Windows desktop in favor of a presentation that is easier to use and more comfortable to them (Leibs, 1994). TabWorks uses a three-ring binder display, complete with tabs, to represent files and programs in logical groups. Easy Notebook Office is designed with the mobile professional in mind. Its shell looks like the interior of a car, allowing users to click on different icons to perform various functions.

Reducing Excess Functionality

Designing something well is not an easy task. Choosing the right functionality for a software application can be even more daunting, given that the application is subservient to the computer system on which it operates. Norman (1988) observed that it usually takes five or six tries to get a product right, and that the development of technology follows a U-shaped curve of complexity. New applications are difficult to use, but then they mature and become simplified, reliable, and more powerful. After this stabilization, newcomers then discover how to add increased functionality at the expense of added complexity. Like radios, televisions, and watches, computer systems follow this pattern. The challenge for the system designer is to achieve the correct balance of functionality versus complexity.

To reduce excess functionality, a designer first needs to concentrate on the "task" and determine what is absolutely necessary to include in an application. This is done by listing, analyzing, and evaluating the tasks that the application is intended to be used for. Laurel (1991) as reflected in the following statement, stresses that "action" is the primary component of human-computer activity:

Focus on designing the action. The design of objects, environments, and characters is all subsidiary to this central goal. (p. 134)

For example, it does not make sense to design a marginal spreadsheet application into a good word processing package, especially when there are already many excellent spreadsheet products on the market.

Second, the application needs to balance the frequency of a function with the need to use it. Functions that are frequently used should be easier to engage; functions the are used infrequently need not be emphasized right away.

Third, the application should allow for smooth transition of the user from novice to expert, and provide an incremental approach to do so. Novices may feel more comfortable using menus whereas experts may prefer using icons, a command language interface, or macro routines. The current ability of the user should be accurately reflected in the current functional state of the application. Application control panels or initialization files should support adaptation and evolution.

Fourth, sound development practices should be used when building and delivering an application. Johnson (1994) suggests the following:

• • Lay out the basic design of the interface and prototype using several alternatives.

  • Usability test the alternative interfaces with real users.

  • Finalize the external design based on test results.

  • Usability test the alpha version of the product with real users and real tasks.

  • Fine tune the program flow based on test results and incorporate help and training into the product.

Finally, system designers should strive for application "invisibility" as described by Norman (1988):

I do think of myself not as using a computer but as doing a particular task. The computer is, in effect, invisible. (p. 185)

New Issues to Investigate

As the global community becomes increasingly computer literate and the need to share information grows, software and system designers will be faced with many new issues. Application functionality will be of central importance to the design and use of any computer-based system, be it an automatic teller machine, an information kiosk, or the Internet. Two new issues are emerging that will have to be dealt with: communication and interoperability.

Data no longer resides at one location. Users are now required, be it for personal or business reasons, to retrieve, update, and collate information from many geographically dispersed sources. System designers will not only be challenged to make this process transparent to the user, they will be required to keep it simple and integrate the data communications layer with their applications. This introduces the chance for error and complicates completion of the task. Document management products such as Lotus Notes are addressing this issue, but no clear standard has emerged for transaction processing systems.

As desktop and cooperative standards evolve, applications will be required to work together. Product suites, such as Microsoft Office, are a possible solution. However, users want the freedom to choose individually and incrementally from what is available, and not be forced into one company's suite, strategy or standard platform. Applications will have to be designed with this and mind, again keeping the process transparent to the user.

By concentrating on task completion, software and system designers can avoid making their applications hard to use. Applications can be function rich, without being excessive. Systems can educate, inform, and guide the user to new productivity levels. User-centered design should be used to drive systems and applications development, rather than imposing the will of the developer upon the user.

References

Johnson, S. (1994). Tour the software chamber of horrors. Computer Technology Review, Vol. 14, No. 6, 6.

Laurel, B. (1991). Computers as theatre. Reading, MA: Addison Wesley.

Leibs, S. (1994, August 15). Why can't PCs be more fun? Information Week, 27-34.

Norman, D. A. (1988). The psychology of everyday things. New York: Basic Books.

Rosson, M. B. (1983). Patterns of experience in text editing. Proc. CHI `83 Conference on Human Factors in Computing Systems (pp. 171-175). New York: ACM.

Shneiderman, B. (1992). Designing the user interface: Strategies for effective human-computer interaction (2nd ed.). Reading, MA: Addison Wesley.