User Interface Consistency in the DECwindows Program

Reprinted with permission from Proceedings of the Human Factors Society 32nd Annual Meeting (October 24-28, 1988, Anaheim, CA), Volume 1, pp. 259-263. Copyright © 1988 by the Human Factors and Ergonomics Society. All rights reserved.

Abstract

A major goal of the DECwindows program is to provide a consistent, state-of-the-art user interface for workstation software.¹ This interface extends across operating systems and many different types of application programs. Within the DECwindows program we have addressed both the technical and organizational aspects of developing consistent user interfaces across applications. Traditional methods for developing user interface consistency, such as the use of an interface style guide and toolkit, were supplemented with more innovative techniques. An exhibition and catalog of DECwindows application designs helped to develop a DECwindows school of interface design. Electronic conferencing software played an important role in facilitating communication among DECwindows contributors throughout the company. Preliminary user interviews suggest that the DECwindows interface style gives a consistent, usable feel to Digital's workstation applications.

Introduction

In January 1987, Digital announced the DECwindows program for workstation software. A major goal of the DECwindows program is to provide a consistent, state-of-the-art user interface for workstation software. Consistency in user interface extends across operating systems (VMS and UNIX) and across many different application programs. The goal of this paper is to share the methods that we have used to build consistent interfaces across a large set of software applications.

Digital's Software Usability Engineering Group has played a central role in developing the DECwindows user interface style, and in fostering its use by software development groups throughout the corporation. This has been an intensely collaborative effort among hundreds of people. Engineering, marketing, writing, management, sales, and support groups from many different product lines around the world have contributed to the development of this interface style.

We have used both traditional and innovative methods for developing a usable, consistent DECwindows interface style. These methods address both the technical and organizational aspects of developing consistent user interfaces across applications. They include:

As this paper is being written (June, 1988), we are doing iterative development of the DECwindows system. All results reflect data collected up to this point in the process, not data for the entire development cy cle.

User Interface Style Guide

One common technique for creating a consistent user interface style is to produce a style guide (e.g., Apple, 1987). The style guide describes the elements of the user interface style and shows examples of their use. It may also contain a philosophy or principles section, which describes underlying concepts of the interface style. A style guide often includes both specific design rules and more general design guidelines (Smith, 1986).

The DECwindows Style Guide has been developed iteratively with contributions from many Digital employees and customers. Four versions of the Style Guide have been produced to date, with a fifth under way. This was preceded by two versions of an earlier user interface design specification which served as the starting point for the Style Guide.

Toolkit

Style guides tend to be most effective when accompanied by software development tools which make it easy to follow the style guide recommendations. The DECwindows system provides a toolkit for this purpose. An application developer can use the default values of the toolkit to produce interface components which conform to the Style Guide specification.

The toolkit has also been developed and delivered iteratively. The earliest versions of the toolkit used a relatively low-level programming interface to access all user interface features. Subsequent versions of the toolkit have added new facilities to make interface development easier for programmers.

The DECwindows interface style is intended to be used by a large variety of applications. No general-purpose interface style can anticipate all the needs of different applications or all the good ideas of the future. An important part of the design of the DECwindows toolkit is the ability to mix new, application-specific interface components with the standard DECwindows set of interface components.

For example, an application developer may want to build an interface component that mimics the appearance and behavior of an existing tool as closely as possible. The existing tool might be used only in a specific type of job or in a specific piece of equipment. Standard functions can be accomplished using standard components, without inhibiting the development of new functions when needed. A major role of the principles section in a style guide is to guide the development of these new interface components.

Electronic Communication

Hundreds of people within Digital have contributed to the DECwindows system. These people come from different functions, different product lines, and different locations around the world. Electronic communication, including electronic mail and conferencing, has been essential for holding this distributed software engineering program together.

The standard DECwindows interest mailing list used by program management includes over 550 people, many of whom forward these messages to their own groups using their own mailing lists.

Through conferencing, mail, and networking software, people can review the toolkit and Style Guide specifications and let us know what meets their needs and what is unsatisfactory. As people begin to use DECwindows applications, we can then provide feedback to developers on how well their interfaces conform to the DECwindows style. All portions of the DECwindows user interface environment have been developed iteratively.

One measurable indication of the amount of electronic communication that has occurred throughout the DECwindows project is conference activity. Electronic conferencing is heavily used within Digital, with over 1000 VAX Notes conferences available for corporate use.

Table 1 summarizes the writing activity in the eight conferences most associated with DECwindows interface issues. This table shows just a subset of total electronic conferencing activity, since writing activity is recorded while reading activity generally is not. The conferences in the table are ordered by their date of creation. For each conference, Table 1 lists:

Conference Topic	Start	Stop	Participants	Topics	Notes	Notes per Week
Interface Design Team	11/86	3/87	13	48	121	6
User Interface Design	12/86		184	304	1578	20
General Information	1/87		551	597	4146	55
Style Guide Committee	6/87	10/87	16	55	192	11
Documentation	9/87		93	84	416	11
Programming #1	9/87	4/88	155	371	1792	64
User Interface Tools	1/88		84	187	712	31
Programming #2	3/88		193	372	1465	98

The Interface Design Team conference was a private conference, restricted to the 14-person team that developed the original user interface design specification. The 13 participants were the engineers from California and New England who developed the specification. The Style Guide writer was also a member of the conference. The Style Guide Committee conference played a similar role for the first few versions of the Style Guide, with membership open to a 29-person team, again primarily engineers.

The User Interface Design conference is the corporate conference for discussion of the DECwindows user interface style. Engineers, writers, and field personnel are the primary contributors to the conference. The conference is used to suggest changes to and ask questions about the interface style. It is regularly monitored by usability engineers and the DECwindows user interface architect. Changes to the Style Guide are posted in this conference as they become available, before a new version of the Style Guide is printed.

The General Information conference covers all aspects of the DECwindows program. Participation comes from every area of the corporation. This is the conference where people usually go first when they be come involved in DECwindows-related work, whether they are engineers or writers on a new project, or sales and support people on their first DECwindows-related work for customers. The conference has active participation by the engineering and marketing leaders of the DECwindows program.

The Documentation conference is used primarily by writers who are responsible for producing DECwindows manuals and on-line help. Engineers also participate, particularly those who produce software which supports the production of DECwindows documentation.

The two programming conferences are used primarily by DECwindows programmers to ask questions and swap hints about building DECwindows applications. The first conference was a restricted-membership conference for earlier, less stable versions of the DECwindows software. A second conference with general corporate membership was created when later versions of the software were more widely distributed throughout the company. The interaction between DECwindows system and application programmers is a key feature of these conferences: application developers can often get their questions answered quickly by the person who is developing the software they are using.

The User Interface Tools conference serves a similar purpose to the Programming conference, but focuses on the user interface tools used by programmers to develop their DECwindows user interfaces. In contrast, the Programming conferences cover all aspects of DECwindows programming, not just user interfaces. Again, the conference is used primarily by programmers, including the user interface tools developers.

In addition to these eight conferences, there are many other conferences devoted to specific portions of the DECwindows system. For instance, many DECwindows applications have their own conference, either for project use, corporate use, or both.

The DECwindows-related conferences are one way for the people who are developing. selling, and supporting DECwindows applications within Digital to communicate with the people responsible for designing and developing the base DECwindows software. The conferences also help to train people in the use of rapidly changing software. Early. quick. and incremental feedback from diverse people within the company played a major role in developing an interface style that could be used effectively for many types of applications.

Developing a New Interface Style

From an analytic perspective, "style" may be seen as something determinate which can be achieved through the specification of many rules. As our work proceeded, it became clear that this perspective did not serve us well. Developers following the Style Guide specifications were developing very different types of interfaces to their products.

In the art world. styles of art are often instantly recognizable after seeing a few examples. For example, Art Deco is easily distinguished, at a glance, from Impressionism. Further, no list of rules is used to make the distinction, and probably no complete list of rules ever could be written.

Developing a new interface style is somewhat like developing a new school of art. Therefore, we adapted some traditions from the art world with a view toward developing a "DECwindows school of design."

Early Prototyping

During the early parts of the DECwindows design process, our best rapid prototyping tools were graphics programs for drawing static pictures of the interface design. Each version of the Style Guide has been extensively illustrated. The early illustrations were the first sketches of the interface design.

Static pictures abstracted from product interfaces do not communicate some of the most important parts of a graphical user interface. To overcome this limitation, a graphic designer and marketing person put together a slide show which presented two scenarios for using DECwindows systems. In the first scenario, an administrative assistant prepares a quarterly sales report using nine different applications, such as time management, spreadsheet, editing, and mail. In the second scenario, a software engineer is coding and debugging a program module. The engineer uses six different applications, such as debugging, editing, and conferencing.

The scenarios showed how the DECwindows interface design style could be applied to a variety of different applications, and how it would feel to use these applications together to get a particular task done. It did not represent the final interface designs for any individual application. This slide show was given at many different sites throughout the corporation and began to gave people a feel for the active parts of the DECwindows interface design. It was the first step towards developing a more holistic view of the DECwindows user interface style.

When improved rapid prototyping tools became available, we put together a prototype DECwindows system, using a third scenario which also included several different DECwindows applications. People could use the mouse to run through a simulated DECwindows interface using this prototype. Developers on many different projects began to create their own prototypes, using our scenario as a starting point and a source for interface components. Some development teams used their prototype as their user interface specification.

User Interface Trade Fair

At this point we borrowed some additional ideas from the art world: the idea of an art exhibit which helps to define a style of art, and a catalog associated with the exhibit. We sponsored a user interface trade fair at which about 45 development teams exhibited their user interface designs, created using graphics programs and rapid prototyping tools. About 600 people, primarily engineers, managers, and writers, attended the fair. In this way, people working on one product got to see the early designs of other products. Within two weeks of the fair, we produced a 50-page trade fair catalog which captured many of the good ideas from various designs, encouraging their use in other products.

We have kept encouraging people to share their designs. In one example, a smaller-scale fair was held for computer-aided software engineering projects. Developers from ten different projects in this area shared their interface designs, and developed a list of consistency issues to be addressed either within that product family or through the DECwindows program as a whole.

Sharing whole designs helps create a synthetic or holistic view of interface style. We wish to create a shared vision of what it means to have a "DECwindows style interface," but that vision cannot be adequately expressed in terms of rules and guidelines (Dreyfus and Dreyfus, 1986). Guidelines and toolkits tend to approach design from an analytic perspective. We believe that combining synthetic and analytic approaches to developing a consistent user interface style is more effective than either approach used by itself.

Consulting and Design

Carroll and Campbell (1988) propose that computer artifacts embody implicit theories of human-computer interaction, which may turn out to be irreducible to explicit theories. Experience has indicated that applications developed according to an interface style are among the most powerful forces for communicating and evolving the interface style. Accordingly, we have spent much of our time working with application developers to produce usable interfaces for a set of key DECwindows applications.

Initially, application developers may believe that a style guide and toolkit will solve all the interface design problems. Instead, the style guide and toolkit tend to solve a set of standard problems and provide a framework which makes it easier to solve the application-dependent interface problems. The key applications will serve as models for future application developers, so we have devoted special attention to their design.

We have no standard relationship between usability engineers and application developers. In some cases, the usability engineer is part of the design team. In others, the development team does the design work, with the usability engineer serving as a consultant. Application developers are also able to ask for the usability engineering group's assistance on particular design issues at an informal review meeting

Conclusion

We are still doing iterative development of the DECwindows user interface design and software systems, so it is too early to tell precisely how well we have succeeded in developing a consistent, usable interface. We have conducted contextual interviews (Whiteside, Bennett, and Holtzblatt, in press) with DECwindows users, and preliminary results from these interviews are favorable. The DECwindows interface style appears to give a consistent, usable feel to applications produced within Digital. More contextual interviews will be conducted throughout the rest of the iterative design process, with a focus expanded to include DECwindows applications developed by other companies.

The development of the DECwindows user interface style was done in the context of a company-wide software development program, with a corporate commitment to user interface consistency. For years the company has had a strategic message promoting teamwork, and people within the corporation could see that a consistent user interface fit with the company's strategic direction. In our software development environment, designers were already used to making tradeoffs against an "optimal" design for one product in isolation in favor of a design which lets the products work better together. This corporate cultural background has greatly facilitated our work.

Developing consistent user interface styles across product families is a challenging task. We certainly do not have all the answers. We are eager to share our experiences with others so that we can help each other in meeting the challenges of building consistent, usable interfaces for a set of software applications.

Footnote

¹This paper is an expanded and revised version of a position paper submitted to the limited-attendance CHI '88 workshop on Coordinating User Interfaces for Consistency. DECwindows, VAX, and VMS are trademarks of Digital Equipment Corporation. UNIX is a trademark of AT&T Bell Laboratories. Apple is a registered trademark of Apple Computer, Inc. The views expressed in this paper are those of the author and do not necessarily reflect the views of Digital Equipment Corporaiion

Acknowledgments

Contributors to the DECwindows user interface design include Geoffrey Bock, Sue Bonde, Alana Brassard, Jeff Dike, Charlie Frean, Harry Hersh, Sandy Jones, Scott McGregor, Kelly O'Rourke, Tom Spine, Eliot Tarlin, Leo Treggiari, Jake VanNoy, Smokey Wallace, John Whiteside, Chauncey Wilson, and Dennis Wixon.

Many of the ideas in this paper have been refined thanks to participation in the CHI '88 Workshop on Coordinating User Interfaces for Consistency, chaired by Jakob Nielsen. The contributions of Bruce Tognazzini, Dan Rosenberg, Robert Glushko, Jonathan Grudin, and Richard Wolf were especially helpful.

References

Apple Computer, Inc. (1987). Human interface guidelines: The Apple desktop interface. Reading, MA: Addison-Wesley.

Carroll, J. M. and Campbell, R. L. (1988). Artifacts as psychological theories: The case of human-computer interaction (Tech. Report RC 13454). Yorktown Heights, NY: IBM Research Division, T. J. Watson Research Center.

Dreyfus, H. L. and Dreyfus, S. E. (1986). Mind over machine. New York: The Free Press.

Smith, S. L. (1986). Standards versus guidelines for designing user interface software. Behaviour and Information Technology, 5, 47-61.

Whiteside, J. A., Bennett, J. L. and Holtzblatt, K. A. (in press). Usability engineering: Our experience and evolution. In M. Helander (Ed.), The handbook of human-computer interaction. Amsterdam: North-Holland..