Developing the XUI Style

Michael Good

Digital Equipment Corporation
Nashua, New Hampshire, USA

This material has been published in Coordinating User Interfaces for Consistency, Jakob Nielsen, Ed., 1989, pp. 75-88, the only definitive repository of the content that has been certified and accepted after peer review.  Copyright and all rights therein are retained by the Academic Press. This material may not be copied or reposted without explicit permission. Copyright © 1989 by Academic Press.

Introduction

In January 1987, Digital announced the DECwindows program for workstation software.¹ A major goal of the DECwindows program is to provide a consistent, modem user interface for workstation software. This goal was met through development of the XUI (X User Interface) style, which provides a consistent interface style across operating systems, including VMS and UNIX, and across different application programs. This chapter describes the methods that we have used to build consistent interfaces across a large set of software applications, as well as some of the philosophy which underlies these design methods. We believe that these methods can be used to build consistent interfaces in other environments as well.

The DECwindows program is Digital’s largest software development project to date. It was initiated at the highest levels of the software engineering organization. Hundreds of people from engineering, marketing, writing, management, sales, and support groups were involved from many different product lines around the world.

The XUI design center was a multiprocessing, networked workstation running the X Window System in international settings. The XUI style was designed for usability on workstations and personal computers with different screen sizes and different input devices, including tablets and mice with 1 or more buttons. Though the design was optimized for a large-screen workstation with a 3-button mouse, the differences in screen size and input device were not as important as the focus on multiprocessed, networked, international systems. Digital’s Software Usability Engineering group was the central force for defining a usable, consistent interface style. As a 9-person group, we worked together with the DECwindows user interface architect, about 50 development projects within Digital, and field test customers from different industries in an intensely collaborative effort.

Our interface development methods addressed both the technical and organizational aspects of developing a consistent user interface style for many different applications. Starting with traditional methods and moving to more innovative techniques, they include:

• Producing a user interface style guide,
• Producing a toolkit which implements style guide recommendations by default,
• Consulting and design with development teams for key applications,
• Widespread use of electronic mail and conferencing,
• Sharing early prototypes of the interface style, and
• Conducting user interface trade fairs.

We originally planned to use just the first four methods. We soon realized that these techniques, by themselves, left us far short of the goal of producing a consistent interface style. The first user interface trade fair was the turning point in converging on a consistent interface style.

In the remainder of the chapter I will discuss each of these methods. The three more innovative methods will be discussed in more detail than the traditional methods. I will conclude by describing the context in which these methods were used: an environment with a corporate commitment to consistency, and a contextual approach to interface design.

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 initial specification of the XUI style was developed by a 14-person team, consisting of software engineers from California and New England, software usability engineers, and a technical writer. A larger team convened a few months later to guide the initial version of the Style Guide.

Like all parts of the DECwindows program, the XUI Style Guide [Digital 1988] was developed iteratively. Iterative design and evolutionary delivery are standard techniques for developing usable systems [Gilb 1988; Gould and Lewis 1985; Good 1988] and exploit the iterative nature of most software design projects [Curtis et al. 1987]. The version of the Style Guide included in the XUI product was preceded by six earlier versions of the Style Guide and two versions of the original user interface design specification. Each new version incorporated lessons learned during the design and implementation of DECwindows system and application software. Final Style Guide decisions were made by the user interface architect, a software engineer with extensive experience in workstation interface design.

Style guides differ in their size and coverage. In our case, the full XUI Style Guide is about 150 pages long and contains over 50 illustrations. It focuses on describing the elements of the user interface style, such as windows, menus, scroll bars, dialog boxes, buttons, keyboard and pointing device operations, selection, and help. The Style Guide provides guidelines for the use and combination of these elements into an interface design.

An introductory philosophy section describes the basic principles of the XUI Style, such as user control, direct manipulation, progressive disclosure, aesthetics, and consistency, which can guide developers in using and extending the interface style. This section also includes brief subsections on the design process and avoiding common design pitfalls.

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 XUI Toolkit is provided for this purpose. An application developer can use the default values of the object-oriented toolkit to produce interface components which conform to the Style Guide specification. The XUI Toolkit implements nearly all of the interface features described in the XUI Style Guide.

The toolkit was also developed and delivered iteratively. During the most active development periods, new versions of the toolkit were built and distributed weekly to key software development projects. More stable versions were distributed monthly to the general development community within the corporation. The earliest versions of the toolkit used a relatively low-level programming interface to access all user interface features. Subsequent versions of the toolkit added a User Interface Language 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 XUI Toolkit is the ability to mix new, application-specific interface components with the standard XUI set of interface components. Application programmers can stick entirely to programming in the XUI Toolkit and User Interface Language, or may mix in references to the lower-level X Toolkit. This type of flexibility is a key to insuring user interface consistency, since the consistent style can evolve and expand to meet new demands in new situations.

For example, an application developer may want to build an interface component that mimics the appearance and behavior of an existing physical 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. A major role of the principles section in a style guide is to guide the development of these new interface components.

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 which will exemplify the XUI style.

Initially, application developers may believe that a style guide and toolkit will solve all their 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.

Usability engineers work with development groups in a number of ways. 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.

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.

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.

Electronic Conferencing

One measurable indication of the amount of electronic communication that has occurred throughout the DECwindows project is conference activity. Electronic conferencing, implemented with VAX Notes software [Gilbert 1988], is heavily used within Digital. Over 1000 VAX Notes conferences are available for corporate use.

Table 1 summarizes the writing activity in the 12 conferences most associated with DECwindows interface issues as of November 1988. 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 DECwindows conference, Table 1 lists:

• The month the conference was started,
• The month the conference was stopped (for those conferences no longer active),
• The number of main topics in the conference,
• The total number of notes in the conference, including main topics and replies to those topics, arranged hierarchically, and
• The mean number of new notes (topics and replies) entered in the conference each week.

Table 1: Activity in DECwindows Interface-Related Conferences

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 XUI 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 become 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. Of the 1126 people who participated in any of these 12 conferences, 77% participated in the General Information conference.

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 Toolkit and User Interface Language conference focus on two specific user interface tools used by programmers to develop their DECwindows user inter faces. Usage questions, suggestions, and bug reports are common entries. These conferences are used primarily by programmers, and are sponsored by the XUI Toolkit and User Interface Language development groups.

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. They cover all aspects of DECwindows programming, not just specific development tools.

The Performance Task Force conference is used for communication among the 21 engineers who have been measuring and analyzing XUI performance. Slow performance caused serious usability problems in the early parts of the DECwindows program and became the focus of much engineering effort. Most of the activity in the conference came in its first 5 months, with occasional updates since then.

The Examples conference is used for sharing DECwindows programming examples. It was started by the customer support organization and is used primarily by people in customer support and software services, with some participation by programmers in software engineering organizations.

The Marketing conference describes marketing and selling of DECwindows and XUI products. Sales, marketing, and support people are the primary contributors, with some participation by software engineering.

In addition to these 12 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.

Conferencing and Iterative Design

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.

In particular, the interaction between DECwindows system and application programmers is a key feature of the programmer-oriented conferences. When versions of the XUI software were being distributed weekly, often with incompatible changes, it was difficult for application developers to keep up-to-date. Programming documentation was sketchy during much of this time. These conferences allowed application developers to get their questions answered quickly by the people developing the system software that they were using. In turn, system software developers got quick and continual feedback on problems that programmers encountered while using the software, and many changes were made as a result.

Developing a New Interface Style

The methods described so far — producing a style guide and toolkit, extensive consulting and design, and heavy use of electronic communication — were techniques that we knew we would use from the beginning of the DECwindows program. They were methods that we knew we would need to apply to produce a set of consistent and usable applications. What we did not know then, but would soon find out, was how much more we needed to do. While these methods were important, they were not sufficient by themselves to produce a consistent XUI style.

One of the chief limitations was that we were viewing interface “style” from strictly an analytic perspective. From this perspective, style may be seen as something determinate which can be achieved through the application of many specific rules. As our work proceeded, it became clear that this perspective did not serve us well. Developers following the Style Guide specifications were creating very different types of interfaces to their products.

Style guides often emphasize the elements of an interface style; as a written document it is difficult to do otherwise. An object-oriented toolkit, by its very name, reveals its underlying analytic approach to interface design. What we needed to do was to develop a shared holistic, synthetic understanding of the XUI style to complement the analytic understanding of style.

Most of the developers responsible for XUI interfaces had little prior experience with direct-manipulation systems. In developing XUI software, they rapidly had to become familiar with new interface and programming technology. Designers may have been using toolkit elements such as scroll bars, push buttons, and dialog boxes as specified in the XUI Style Guide, but they often saw all of the parts but none of the whole.

In the art and design worlds, styles are often instantly recognizable after seeing a few examples. In architecture, for example, Bauhaus style is easily distinguished, at a glance, from Post-Modem style. 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 or industrial design. Therefore, we adapted some traditions from the art world with a view toward developing an “XUI school of design.” The first step was to facilitate the sharing of early designs, by sharing early graphical prototypes of different applications.

Sharing Early Prototypes

Our first step in building a shared, synthetic vision of the XUI style was to share early prototypes. The nature of the prototypes evolved with the prototyping tools we had available, and with the maturity of the interface style itself.

During the early parts of the XUI design process, our best rapid prototyping tools were graphics programs for drawing static pictures of the interface design. Each version of the XUI Style Guide has been extensively illustrated. The early illustrations were the first sketches of the interface design. Many of the illustrations showed different interface components being used together within a single window.

Static pictures abstracted from product interfaces do not communicate some of the most important parts of a graphical user interface. To overcome this limitation, our graphic designer and one of our product managers 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, like a time manager, spreadsheet, editor, and mail. In the second scenario, a software engineer is coding and debugging a program module. The engineer uses six different applications, like a debugger, editor, and electronic conferencing system.

The scenarios showed how the XUI 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 shown first to Digital’s president and executive committee, and shown later at about 20 different sites throughout the corporation. This started to give people a feel for the active parts of the XUI style, and was the first step towards developing a more holistic view of this style.

When improved rapid prototyping tools became available, we built our own XUI prototype, using a third scenario which also included several different DECwindows applications. By using the mouse to move through the simulated interface, people could more directly experience the interactive parts of the XUI style.

We introduced developers to the rapid prototyping tool, and taught teams how to build their own prototypes, using our scenario as a starting point. Soon, graphical user interface specifications became a standard part of the specification for DECwindows products, with the understanding that the interface would change as a result of iterative design. Prototypes were often used as the graphical part of the interface specification. The construction of early, understandable interface specifications reflected a large cultural change in our software development process.

User Interface Trade Fairs

Among the benefits claimed for iterative design and evolutionary delivery is the ability to discover differences between plans and results “early, before they be come a real danger to your project, and do something effective about them” [Gilb 1988, p. 237]. Our experience with evolutionary delivery by way of shared prototypes was a classic example of this benefit. It was only after we had seen several different prototypes developed by different groups that we realized just how much trouble we were in. We had developers doing their best to follow the Style Guide (and in some cases using the earliest versions of the Toolkit), but the interfaces being designed were not consistent with each other and in some cases not very usable. What could we do to change this?

At this point we borrowed some ideas from the art world: the idea of an art exhibit which helps to identify 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 attended the fair. The attendees were primarily the engineers, managers, and writers responsible for different DECwindows software products.

Several things happened at the fair. First, the attendees got to see a lot of different examples of the XUI style applied in different design situations. The exhibits contained many good ideas for solving various interface design problems. 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.

Second, and perhaps more important, the people responsible for the interface designs got to meet each other and form personal relationships. Designers not only saw what other designers were doing, but began to establish relationships which let them share each other’s work more easily. Designers from major groups in New England, California, and France were all present at the fair. The relationships formed at the fair continued throughout the development process. This made the use of electronic communication more effective: it’s easier to avoid some of the depersonalizing effects associated with electronic communication [Kiesler et al. 1985] when you’ve met the person behind the electronic address.

We felt that this first trade fair was the turning point in the XUI design process. After this fair, a set of divergent interfaces started converging over time, until we did indeed produce a set of consistent, usable products.

We have kept encouraging people to share their designs, often using the trade fair format. For example, one smaller-scale fair was held for computer-aided software engineering projects. Developers from 10 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.

About a year after the first trade fair, we held a much larger event called the “DECwindows Enterprise Fair.” This fair focused on bringing a shared understanding of the DECwindows program and XUI style to people within Digital who had not had much exposure to DECwindows products by this time, including sales, marketing, and support people.

The first fair, with 45 exhibitors and 600 attendees, took place for one afternoon in a vacant computer room in a newly-opened engineering building. The second fair, with 55 exhibitors and about 5500 attendees, took place over two days in a vacant shopping mall in an old mill complex. The exhibits at the first fair were throwaway prototypes and slide shows; the exhibits at the second fair were running, functional versions of the products. Despite the differences in scale and focus, both fairs shared the purpose of building personal relationships and bringing people up-to-date on DECwindows design efforts.

Sharing whole designs helps create a synthetic or holistic view of interface style. We wanted to create a shared vision of what it means to have an “XUI style interface,” but that vision cannot he 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.

Conclusion

In this chapter I have described several techniques that we used to produce a set of consistent, usable products in the XUI style. However, there is a set of larger issues regarding the development environment which transcend particular development methods. Corporate commitment to consistency and a group commitment to contextual methods were at the heart of the XUI development process.

Corporate Commitment

The development of the XUI 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.

Designing for consistency always involves making tradeoffs between the needs of individual components and the needs of the system as a whole. Developers of the individual components will naturally tend to advocate the needs of their own components. With a corporate commitment to consistency, the needs of the system as whole will also be heard effectively, and the extra work required to produce consistent interfaces will be planned for and facilitated.

In Digital’s distributed organizational structure, there was no one central authority for DECwindows interface decisions. The user interface architect made the final decisions on the content of the Style Guide, but he did not make all the decisions about the Toolkit or application software. Here, the corporate commitment to consistency is associated with the corporate culture, not with particular organizational artifacts.

Contextual Interface Design

Underlying our XUI design work is a contextual, or interpretive, approach to user interface design. Contextual field research on human-computer interaction [Whiteside et al. 1988] is a process that allows the researcher to collect and interpret users’ responses to software as they are engaged in the use of that software. The researcher is present during the use of the software in the context of the user’s actual work setting and task. The researcher can both observe and question the user about his or her experience with the software and its impact on the work as it unfolds. Data collected in these contextual interviews includes:

• Users’ ongoing experience with the product,
• The nature of the users’ work,
• The impact of the product on the users’ work,
• The meaning of usability for the user,
• Directions for future products,
• Specific problems and strengths of specific products,
• Interaction of specific products with other products, and
• Interaction of the product with the users’ environment.

We do not assume that something is experienced as disruptive to work because it seems that way to us. We check out our interpretations with the user to establish a shared understanding of user experience which grounds our interpretations. Similarly, if we see a user doing something effortlessly, seemingly without awareness, we check this out. With the user as co-researcher, we can track aspects of usability to elements of the system implementation.

We conducted nearly 200 contextual interviews during the development of the XUI style. Data from these interviews contributed to the DECwindows program in three basic ways. First, it guided interface improvements in individual applications. Second, it guided the development of the interface components in the XUI Style Guide and Toolkit. Third, it contributed to a theory of usability which underlies some of the basic XUI principles, such as the focus on user control and user work.

Our commitment to a contextual, interpretive approach to design goes beyond conducting contextual interviews. It is intertwined with our emphasis on a holistic and synthetic understanding of interface style. It made possible the break- through of the first user interface trade fair. Winograd and Flores [1986] and Ehn [1988] present related theories of computer design.

Our user interviews and feedback from customers indicate that the XUI style does give a consistent, usable look and feel to diverse applications. The XUI style is flexible enough to support designs in many different application areas. We used a variety of methods to develop this consistent, usable interface style, grounded in a contextual approach to design and supported by a corporate commitment to consistency. We believe that our methods and approach to design can be adapted for use in other projects which need to address both the technical and organizational aspects of coordinating user interfaces for consistency.

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, Torn Spine, Eliot Tarlin, Leo Treggiari, Jake VanNoy, Smokey Wallace, John Whiteside, Chauncey Wilson, and Dennis Wixon.

Footnote

¹ Portions of this chapter appeared in the Proceedings of the Human Factors Society 32nd Annual Meeting, October 24-28, 1988, Anaheim, Vol. 1, pp. 259-263. DECwindows, VAX, VMS, and XUI are trademarks of Digital Equipment Corporation. X Window System is a trademark of the Massachusetts Institute of Technology. UNIX is a registered trademark of American Telephone & Telegraph Company. Apple is a 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 Corporation.

Academic Press journals may be found online at IDEAL (International Digital Electronic Access Library) at http://www.idealibrary.com or http://www.europe.idealibrary.com.

References

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

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

Curtis, B., Krasner, H., Shen, V. and Iscoe, N. (1987). On building software process models under the lamppost. Proc. 9th International Conference on Software Engineering (Monterey, CA, March 30-April 2), IEEE Computer Society, Washington, DC, 96-103.

Digital Equipment Corp. (1988). XUI Style Guide. Order No. AA-MG20A-TE, Maynard, MA, December.

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

Ehn, P. (1988). Work-Oriented Design of Computer Artifacts. Arbetslivscentrum, Stockholm (distributed by Almqvist & Wiksell International).

Gilb, T. (1988). Principles of Software Engineering Management. Addison-Wesley, Reading, MA.

Gilbert, P. D. (1988). Development of the VAX NOTES system. Digital Technical Journal, No. 6, 117-124.

Good, M. D. (1988). Software usability engineering. Digital Technical Journal, No. 6, 125-133.

Gould, J. D. and Lewis, C. (1985). Designing for usability: Key principles and what designers think. Communications of the ACM, 28 (3), 300-311.

Kiesler, S., Zubrow, D., Moses, A. M. and Geller, V. (1985). Affect in computer-mediated communication: An experiment in synchronous terminal-to-terminal discussion. Human-Computer Interaction, 1 (1), 77-104.

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

Whiteside, J. A., Bennett, J. L. and Holtzblatt, K. A. (1988). Usability engineering: Our experience and evolution. In M. Helander (Ed.), Handbook of Human-Computer Interaction, North-Holland, Amsterdam, 791-817.

Winograd, T. and Flores, F. (1986). Understanding Computers and Cognition. Ablex, Norwood, NJ.