A CHI '98 Workshop Position Paper

Print-friendly Version

Applications are driven to feature excess, or`bloat,' by many forces both inside and outside the development group. Techniques for managing feature growth, described below, depend in part on the source of the request. The sources can be divided into three groups, end users, the development team, and other outside forces. End users request new features because they feel they can't accomplish their work without it, because the application doesn't support their preferred way of working, or because they have seen a'neat feature' in a competing application and think it would be useful. These requests are usually posed as a'needed feature' rather than as a problem they have or a task they need to perform.

A second source of requested features is the development team itself. Field studies, conducted by watching end users and doing follow-up interviews, will reveal needed enhancements. Marketing may suggest features that they believe will make the product more attractive to a wider user base. The developers themselves may suggest a feature just because they can do it, because it provides for some form of'symmetric' completeness, or because it is a personal favorite feature. A slightly different form of the latter is management's request for a favorite feature -- how do you tell your boss `No'?

Perhaps the strongest sources of new feature requests come from other sources outside the development team. These outside forces are often the original sources of requests from end users and the development team. The most obvious is product reviews, most of which focus on checklists of features because they are relatively easy to quantify and compare. A potential customer reads the review and stacks up the features and, after discarding products that don't contain features known to be needed, picks the one that does the most. ` does everything I could imagine needing.'  Feature parity -- does your application measure up? How many `lite' versions of a product are doing will two or three years after their introduction?

A more insidious outside source is the release-driven economic model of software -- hook users and get them to upgrade every eighteen months or so to the new version with new features. If there are no new versions, sales are more or less limited to the growth in the number of new computer users. After a while, product sales drop off and so do company profits.

Regardless of the sources of new feature requests, time and experience changes the things that people want and need to do and the way they want to work. Fifteen years ago the Apple Lisa word processor, LisaWrite, provided for styled text, multiple fonts, embedded graphics and charts. But by today's standards, its page formatting was limited, graphics and charts could not be edited in place, it had no style sheets, and its ruler-based formatting was intrusive, all features that most of us have come to expect.

Today's applications have more features than those of fifteen years ago and new control mechanisms have been developed to hide less-used features and to make common features more prominent. The Lisa had a non-hierarchical menu bar with command keys, modal dialogs with buttons, and simple tool palettes. Intervening systems and applications have added, in approximate order, toolbars, non-modal dialogs, hierarchical menus, multiple floating tool palettes, hierarchical menus, selection-sensitive menu bars and palettes, customizable-menus, popup menus, wizards, system generated`hints,' and most recently, panels that slide into view when`touched' and then hide automatically.

With the exception of toolbars, which were designed to make menu-based commands more prominent, all the mechanisms were designed to use hierarchy to hide sets of features until needed and, in most cases, make them more prominent when needed.

The upside of feature bloat is that some of the new features may actually enable specific users to do something they need to do, to work more efficiently, and/or to extend what they can do in an important way. These new features are important  and the reason for not freezing an application's feature set. However, by the third release or so, a product is usually`feature complete' in the sense that it meets the needs of most users, and the continued wholesale addition of new features clearly enters into its down-side phase.

Adding more features distracts the development team from fixing bugs and improving performance. In practice, they usually make an application bigger and slow it down, and sometimes force the user to add more memory, update the system software, and/or get a faster computer.

The addition of new features can introduce unavoidable complications for users that don't need or use the new features. For example, a simple e-mail program designed for low volume use may require only a button click to save a message. The addition of multiple mail folders to support heavy mail users will add complexity, that is, the need to specify which folder a message is to be saved to, and new commands for creating and deleting mail folders and for specifying which mail folder to view. The low volume mail user cannot avoid this additional complexity.

The novice user tries to gain an understanding of an application by looking around and`twisting the knobs' to see what they do. From this they develop a model of the purpose and operation. Doing this with a large, feature-rich application can be overwhelming because of the combinatorics, i.e., it normally takes several operations to complete a task. The user is wondering just what tasks can be performed and the sequence of operations necessary to perform them. Early success is important in engaging new users and encouraging them to explore further. Many users will find full-featured applications too complex to learn by inspection.

Increasing the number of features increases the amount of screen space devoted to controls and reduces the amount devoted to the content. The use of hierarchy to hide features makes the application more difficult for all to use. For example, to gain menu bar space for new features, existing menus (e.g., Font, Style, and Size) might be combined into a single hierarchical menu, and hierarchical menus are both more difficult to operate.

Adding more features can force the UI to be reorganized. A`new' user interface on to an existing product can be extremely disruptive to users, costing them significant relearning time. (Macromedia Director comes to mind.)

Given that there are significant reasons to continually add new features, how do we design and grow applications over time without creating a useless mess? The short answer is that we can't entirely, but with a clear vision of what the application needs to do, good basic design, careful management of feature additions, and occasional, selective restructuring of portions of the UI and underlying code, it is possible to build good products that last ten years or more before the application's user interface has to be redesigned. By then, the world will likely be a rather different place.

The basis for managing the bloat depends primarily on knowing your end users, customers, and target market. We can't know them by just visiting and talking. By and large, people do not consciously know and cannot express what they need at the intimate level we designers work. Talk with them, write down their suggestions, but don't take them at face value because they are usually offering solutions to unstated problems. Dig deeper. It is necessary to live with them in their environment to better understand their goals, the ways they work, and their problems. This must be done continuously throughout the life of the product because the user's goals, work style, and problems will continue to change as the product and their work evolves.

A solid, extensible design, is an absolute must for a long-lived application. Based on the work with end-users, customers, and marketing, it should be possible to develop a clear, concise user model. Apple's Lisa had such a design for its desktop, one that included very few computer-specific artifacts, and then only with clear physical representations. The Macintosh reintroduced several computer-specific artifacts, without clear physical representations, into a lesser featured desktop that ran only one application at a time. Several releases later when the Macintosh desktop began to approach parity with the Lisa's, the Mac's UI was both more complex and more difficult to use.

The user interface must employ the best extensible mechanism available. The hierarchy used to reduce the clutter is also creates the problem of finding things. To the extent possible, related controls should be grouped, by object or function as appropriate, and the groups placed in selection-sensitive mechanisms that will automatically display them when potentially needed and hide them when they are no longer useful. The grouping mechanisms include menu bars, toolbars, and property sheets, and context-sensitive popup menus.

Good task-based design can enable the integration and automation of task parts and relieve the user of having to learn and memorize the steps. For example, on the Lisa a user could copy a document by duplicating it and dragging the duplicate to a disk or folder. If a target diskette did not have enough space on it, the Lisa would inform the user, ask if the document should be split across several diskettes, and initiate and manage that action if the user approved.  It was not necessary for users to know that when a`too large' alert appeared they needed to start some utility application to split -- and later re-join -- the diskfile. Similarly, duplicating a hard disk and dragging to a diskette initiated a disk backup routine of full and incremental backups rather than just informing the user that `there isn't enough room on the destination diskette.'

This task recognition and automation is not the same as providing `wizards.' Wizards can help in a pinch, but they do not instruct the user on how to use the application's features. For example, Excel 5.0 provides a chart wizard for creating and editing a chart, however, when it is necessary to make a single change, e.g., adjusting the portion of the spreadsheet to be charted, the wizard takes the user through all the steps. A better approach might be a context-sensitive, tabbed`universal' property sheet. When the use clicks anywhere within the chart, the tabs would indicate various sets of chart-related attributes. The user just opens the application's one non-modal property's dialog if not already open, clicks on the appropriate tab, and edits the extent.

Lastly add a new UI mechanism only when it can be used to reduce the overall operational complexity of the interface rather than adding yet another mechanism for both users and UI designers to deal with. Feature Management

There will be a gazillion requests for new features from a wide variety of sources, as described above. The key to managing these is a prioritized `new features' list, and the key to making the priorities work is a clear, explicit description of the target market and customer and end-user needs as mentioned above. Saying`no' to your boss's request can be problematic. The use of priorities based on user and customer evaluations allows the designer to add requests at a low priority until their true need can be ascertained.

Of course requested features should not be added to this list right off. Most suggestions are based on the submitter's proposed solution to an unstated problem. Dig deeper to better understand the problem and develop other alternatives. One of the alternatives might be both solve the problem, fit better within the application's user model, and be a more general solution that can be used for other problems. An application's underlying metaphor will often suggest how the new features might best be added.

Selective Restructuring

Occasionally it becomes time to restructure portions of UI to remove the accumulated cruft and to utilize recently developed UI techniques. While the restructuring can be uncomfortable for users -- some are sure to complain -- careful restructurings extend an application's life, keeping it fresh and usable.

Is this approach to feature management guaranteed to work? Of course not, because it depends on good judgment and design, and on product management support. It's a matter of degree. But even in the worst of situations, these techniques can aid designers and help them maintain their sanity. Designing for people is much more complicated than designing something to meet the physics of the real world. It's physics verses psychology. We're dealing with people, and that's what makes it all so interesting.