Creating an effective user interface for HP IVIBuild - HP Interactive Visual Interface

Creating an Effective User Interface for HP IVIBuild

AMONG THE PRESENT and potential customers for HP's computer systems are companies that are increasingly integrating computers into their manufacturing processes. However, the computer focus of these companies is more on solutions than on hardware and software development. To help provide these solutions on HP computer systems there are efforts within the company to encourage or enable independent software vendors (ISVs) to develop these software solutions. HP IVI from HP's Industrial Applications Center (IAC) is one such effort. Its purpose is to help ISVs build graphical user interfaces for their applications used in industrial applications.

Why the need for a graphical user interface? Many of the operators and users of computer-based systems in an industrial environment are not computer literate. They typically perform tasks like controlling an automated spray paint line, and the interfaces to the tools they use are typically knobs, dials, buttons and other physical and visual objects. A command line interface is a totally foreign approach for these people, and many of them refuse to deal with it. Whatever can be done to enable the interfaces to come closer to the users' current way of doing things is seen as having value. A graphical user interface is seen as having the greatest potential in making the interface familiar. Recent developments in user interface technologies [1] are very suitable for graphical user interfaces in industrial automation applications.

Background

HP IVIBuild is a tool that enables users to develop graphical user interfaces interactively. Therefore, it seemed appropriate that it should have a graphical user interface. For this capability the HP IVIBuild developers decided to use the graphical user interface components that were under development at HP's Interface Technology Operation (ITO) in Corvallis, Oregon. These components are commonly called widgets. [2] They include things like menus, scrollbars, pushbuttons, text-edit boxes, and radio buttons. They are the raw materials from which a graphical user interface is assembled. The HP IVIBuild team had no idea that using widgets would lead to collaborating with visual design professionals.

Neither did we, the visual design professionals, know about the HP IVI team. We are the usability design and engineering group of HP's Software Engineering Systems Division (SESD). We are former industrial designers who switched our design focus from designing hardware enclosures to the area of user interfaces, plus one graphic designer. At the time our division was developing what would become the HP SoftBench environment, [3] and we were also looking to ITO for the necessary widgets. Rather than passively waiting to see what they might provide, we were encouraged by our management to lend our professional expertise to the widget development, and ITO was open-minded enough to listen to some of our ideas.

We didn't begin with any proven graphic user interface expertise. We had done some design analyses of the leading graphical user interfaces. Also, coming from a background in which our experience and training forces us to process information visually gave us some ideas about how an effective graphical interface should look. and because our experience with software and computers was limited to being application users, we had some first-hand knowledge about the user interface requirements for users who are not software literate.

Basic Principles

Three principles have established the foundation for graphical user interfaces in recent years, notably in office-oriented applications. The first principle is that is it easier for most people to have their alternatives presented to them in a manner that allows them to make choices rather than having to remember all of the alternatives. Choosing a command from a menu is often easier than remembering it. The second fundamental principle is that making these choices by some means of direct manipulation is often preferred over typing in text commands. Pushing a button or dragging a file icon into a folder icon or a trash can are two examples of direct manipulation. Finally, the third principle is to use metaphors from the real world. For example, we know what to do with a pushbutton.

In our analyses of the many graphical interfaces existing today, one of the impressions we formed was how confusing they could be because of the flat and bland graphics. This is especially true in multiwindow environments in which there is a high degree of overlapping and the similarity of the graphic images seems to blend al the images together into one confusing mass. We thought that creating greater visual distinctiveness between objects would significantly enhance a user's ability to keep things sorted out.

3D Appearance of Widgets

Our first attempts to express widgets graphically were with the traditional black lines on a white background. To get away from the sameness mentioned above, some of the widgets were drawn to look three-dimensional and to look and act like pushbuttons. It soon became apparent that the displays of the future would not be constrained to simple black and white, and that larger areas of solid color could be used. This was a significant breakthrough.

With the capability to use color, we added three colors to the black and white. By using light, middle, and dark versions of a color, we could make a button look very three-dimensional. This was achieved by making the top and left edges light, the flat surfaces the middle value, and the bottom and right edges dark. This technique makes it appear as though a light is shining on the button from the upper left. Another nice by-product of this technique is that by momentarily switching the light and dark colors when a button is selected, it actually appears to be pushed in. It was so effective that people got a little silly pushing buttons the first time they saw a working prototype.

People intuitively grasp the notion that if something appears to protrude, it can be pushed or selected to generate some action. Widgets that accept or display inputs appear to be recessed. Noninteractive things like labels are flat. Scrollbars are hybrids, with a recessed groove containing raised controls. Menu bars look like large buttons with several labels on them. Whtn the mouse drags over a menu item, it appears to raise, transforming itself into a button. When a menu item is selected by releasing the mouse button, the feedback mechanism is the same shadow reversal the pushbutton uses to appear recessed. Fig. 1 shows the transition from a total 2D appearance to a full 3D appearance.

Most people found this 3D appearance appealing. It became a key factor in the subsequent adoption of the HP widgets by the Open Software Foundation (OSF) for their OSF/Motif standard user interface. [4]

A New Principle

The 3D appearacne ends up creating a new fundamental graphical user interface principle: the visual separation and dsitinction of what we call user space and interface space. User space is where the user's inputs go, or where the user performs work. Examples are the space provided in a word processor for entering text, or the space provided in a paint program for creating images. It also includes those areas where the user is asked to input data like the name of a file.

The rest of the screen is the interface space, or the visual manifestations of the applications and/or the operating system. Included in this category are items like window frames, dialog boxes, tool panels, menus, and the metaphorical desktop. The interface space, whether controlled by the application or the operating system, is where all of the 3D effect is found.

In office-oriented applications, which have been driving the graphical user interface movement to date, the 2D user space is usually dominant in terms of screen area. The main focus of these applications is generally to provide a tool that allows the user to create different forms of documents such as mail messages, memos, charts, spreadsheets, overhead slides, and newsletters. Based on these applications, the user space is perceived to be the WYSIWYG equivalent of some sort of paper document, whether a small notepad or a large drawing. It is predominantly two-dimensional, which is appropriate because the resulting documents are also two-dimensional.

There is an emergence of graphical user interfaces in which the interface space dominates because the main function of the applications is not document creation but some form of process setup and control. Examples include things like configuring and running a set of test instruments, or monitoring and controlling a complex temperature control system or an assembly line. HP IVIVuild is geared to create interfaces of this latter type. The 3D widgets (or OSF-Motif widgets) are particularly well-suited to this type of interface because the physical reality they convey is much closer to the mental model most people have of activities that are control-panel oriented. Fig. 2 shows one windown for an office-oriented application and another for an instrument control panel.

HP IVIBuild before Redesign

In the early stages of development, the HP IVI team used the initial version of the widget code from HP's Information Technology Operation. The early results of their using this code produced the 3D appearance shown in Fig. 3. Unfortunately the 3D effect was largely lost and the user interface was hard to understand. This early result wan not a surprise because the HP IBIBuild team han not yet had enough experience with widgets and consequently had little notion of how to achieve and use the 3D effect. They were also unfamiliar with many of the standard techniques and practices for creating graphical user interfaces.

Our group had concurrently been using the 3D widgets with our own HP SoftBench tools. That successful experience plus the acceptance of HP widgets for OSF/Motif gave us a certain amount of credibility. As a r esult we soon found ourselves in contact with the HP IVIBuild team. Like our experiences with the ITO team in the development of widgets, the HP IVIBuild people were very open-minded in letting us get involved with their product.

HP IVIBuild was different for us in that it not only uses conventional widgets to create a graphical user interface, but it can also create graphic objects that behave like widgets. What this means is that buttons and scrollbars can be supplemented with graphic representations of objects that can change to reflect current status. For example, a graphic image of a storage tank can change to show the current level of the liquid it contains, or an assembly line schematic can be changed to reflect the status of each work cell. The output of HP IVIBuild can range from simple windows with menu bars and dialog boxes to very complex control-panel-like layouts with animated graphics and numerous controls. These capabilities were not obvious in the original interface shown in Fig. 3.

The Structure of HP IVIBuild

The HP IVIBuild user interface is divided into three parts: a utility box, a tool box, and a workspace.

The Utility Box. This area holds the menu bar, a prompt window, several status indicators, and some commonly used commands in the form of pushbuttons.

The Tool Box. This area is like a palette of various graphic or widget creation tools. It has three modes: graphics, widgets, and models. The graphic mode functions like a typical paint program, displaying numerous drawing tool buttons as well as mechanisms for displaying and selecting items such as colors, patterns, and line weights. The widget mode is used for creating and specifying the widgets. The models mode is used to get access to models, which are templates or libraries of previously created work. Fig. 4 shows the utility box and tool boxes at an early point in the design stage of HP IVIBuild.

The Workspace. This is the area in which the user does the work of building a user interface. In this area graphic or widget objects are put together on a kind of three-dimensional sheet of paper. After assembly, they are stored away for use as finished products or as models for reuse or modification. For example, a simple dialog box might be used as a template for other dialog boxes, eliminating the need to start each one from scratch.

Collaboration

The early efforts by the industrial designers focused on sorting out the functionality found in e ach of the HP IVIBuild areas and then finding reasonable ways of presenting each area. The utility box and the tool box visual layouts received the most attention. One of the first steps was determining the menu structure in the utility box. Certain conventions and many examples exist in industry showing how applications organize and perform activities like editing and filing--for example, the locations of commands like cut, copy, paste, and quit in a word-processing package. And certain conventions exist in terms of dialog box layout, like where the OK, cancel, and help buttons should go. We followed accepted general practices wherever possible, and tried to develop acceptable solutions where no previous models existed.

The tool box with its various modes was probably the most complex job. The final layout chosen for the tool box owes many of its approaches to showing status and offering choices or functions to existing de facto standards for paint programs. There were instances where we were forced by technical limitations to deviate from these standards. For example, a simple draw tool like the one used to draw a rectangle typically requires a decision about whether the rectangle is to be filled in or left as an outline. A typical solution is to have one button with a rectangle on it, with the left half hollow and the right half filled (what looks like one button is in fact two buttons). In our case the widgets wouldn't allow that approach, so we ended up with a separate button to turn the fill function on or off. Fig. 5 shows the design recommendation for the utility and greater visual distinctiveness between objects would significantly enhance a user's ability to keep things sorted out.

3D Appearance of Widgets

Our first attempts to express widges graphically were with the traditional black lines on a white background. To get away from the sameness mentioned above, some of the widgets were drawn to look three-dimensional and to look and act like pushbuttons. It soon became apparent that the displays of the future would not be constrained to simple black and white, and that larger areas of solid color could be used. This was a significant breakthrough.

With the capability to use color, we added three colors to the black and white. By using light, middle, and dark versions of a color, we could make a button look very three-dimensional. This was achieved by making the top and left edges light, the flat surfaces the middle value, and the bottom and right edges dark. This technique makes it appear as though a light is shining on the button from the upper left. Anoter nice by-product of this technique is that by momentarily switching the light and dark colors when a button is selected, it actually appears to be pushed in. It was so effective that people got a little silly pushing buttons the first time they saw a working prototype.

People intuitively grasp the notion that if something appears to protrude, it can be pushed or selected to generate some action. Widgets that accept or display inputs appear to be recessed. Noninteractive things like labels are flat. Scrollbars are hybrids, with a recessed groove containing raised controls. Menu bars look like large buttons with several labels on them. When the mouse drags over a menu item, it appears to raise, transforming itself into a button. When a menu item is selected by releasing the mouse button, the feedback mechanism is the same shadow reversal the pushbutton uses to appear recessed. Fig. 1 shows the transition from a total 2D appearance to a full 3D appearance.

Most people found this 3D appearance appealing. It became a key factor in the subsequent adoption of the HP widgets by the Open Software Foundation (OSF) for their OSF/Motif standard user interface. [4]

A New Principle

The 3D appearance ends up creating a new fundamental graphical user interface principle: the visual separation and distinction of what we call user space and interface space. User space is where the user's inputs go, or where the user performs work. Examples are the space provided in a word processor for entering text, or the space provided in a paint program for creating images. It also includes those areas where the user is asked to input data like the name of a file.

The rest of the screen is the interface space, or the visual manifestations of the applications and/or the operating system. Included in this category are items like window frames, dialog boxes, tool panels, menus, and the metaphorical desktop. The interface space, whether controlled by the application or the operating system, is where all of the 3D effect is found.

In office-oriented applications, which have been driving the graphical user interface movement to date, the 2D user space is usually dominant in terms of screen area. The main focus of these applications is generally to provide a tool that allows the user to create different forms of documents such as mail messages, memos, charts, spreadsheets, overhead slides, and newsletters. Based on these applications, the user space is perceived to be the WYSIWYG equivalent of some sort of paper document, whether a small notepad or a large drawing. It is predominantly two-dimensional, which is appropriate because the resulting documents are also two-dimensional.

There is an emergence of graphical user interfaces in which the interface space dominates because the main function of the applications is not document creation but some form of process setup and control. Examples include things like configuring and running a set of test instruments, or monitoring and controlling a complex temperature control system or an assembly line. HP IVIBuild is geared to create interfaces of this latter type. The 3D widgets (or OSF/Motif widgets) are particularly well-suited to this type of interface because the physical reality they convey is much closer to the mental model most people have of activities that are control-panel oriented. Fig. 2 shows one window for an office-oriented application and another for an instrument control panel.

HP IVIBuild before Redesign

In the early stages of development, the HP IVI team used the initial version of the widget code from HP's Information Technology Operation. The early results of their using this code produced the 3D appearance shown in Fig 3. Unfortunately the 3D effect was largely lost and the user interface was hard to understand. This early result was not a surprise because the HP IVIBuild team had not yet had enough experience with widgets and consequently had little notion of how to achieve and use the 3D effect. They were also unfamiliar with many of the standard techniques and practices for creating graphical user interfaces.

Our group had concurrently been using the 3D widgets with our own HP SoftBench tools. That successful experience plus the acceptance of HP widgets for OSF/Motif gave us a certain amount of credibility. As a result we soon found ourselves in contact with the HP IVIBuild team. Like our experiences with the ITO team in the development of widgets, the HP IVIBuild people were very open-minded in letting us get involved with their product.

HP IVIBuild was different for us in that it not only uses conventional widgets to create a graphical user interface, but it can also create graphic objects that behave like widgets. What this means is that buttons and scrollbars can be supplemented with graphic representations of objects that can change to reflect current status. For example, a graphic image of a storage tank can change to show the current level of the liquid it contains, or an assembly line schematic can be changed to reflect the status of each work cell. The output of HP IVIBuild can range from simple windows with menu bars and dialog boxes to very complex control-panel-like layouts with animated graphics and numerous controls. These capabilities were not obvious in the original interface shown in Fig. 3.

The Structure of HP IVIBuild

The HP IVIBuild user interface is divided into three parts: a utility box, a tool box, and a workspace.

The Utility Box. This area holds the menu bar, a prompt window, several status indicators, and some commonly used commands in the form of pushbuttons.

The Tool Box. This area is like a palette of various graphic or widget creation tools. It has three modes: graphics, widgets, and models. The graphics mode functions like a typical paint program, displaying numerous drawing tool buttons as well as mechanisms for displaying and selecting items such as colors, patterns, and line weights. The widget mode is used for creating and specifying the widgets. The models mode is used to get access to models, which are templates or libraries of previously created work. Fig. 4 shows the utility box and tool boxes at an early point in the design stage of HP IVIBuild.

The Workspace. This is the area in which the user does the work of building a user interface. In this area graphic or widget objects are put together on a kind of three-dimensional sheet ot paper. After assembly, they are stored away for use as finished products or as models for reuse or modification. For example, a simple dialog box might be used as a template for other dialog boxes, eliminating the need to start each one from scratch.

Collaboration

The early efforts by the industrial designers focused on sorting out the functionally found in each of the HP IVIBuild areas and then finding reasonable ways of presenting each area. The utility box and the tool box visual layouts received the most attention. One of the first steps was determining the menu structure in the utility box. Certain conventions and many examples exist in industry showing how applications organize and perform activities like editing and filing -- for example, the locations of commands like cut, copy, paste, and quit in a word-processing package. And certain conventions exist in terms of dialog box layout, like where the OK, cancel, and help buttons should go. We followed accepted general practices wherever possible, and tried to develop acceptable solutions where no previous models existed.

The tool box with its various modes was probably the most complex job. The final layout chosen for the tool box owes many of its approaches to showing status and offering choices or functions to existing de facto standards for paint programs. There were instances where we were forced by technical limitations to deviate from these standards. For example, a simple draw tool like the one used to draw a rectangle typically requires a decision about whether the rectangle is to be filled in or left as an outline. A typical solution is to have one button with a rectangle on it, with the left half hollow and the right half filled (what looks like one button is in fact two buttons). In our case the widgets wouldn't allow that approach, so we ended up with a separate button to turn the fill function on or off. Fig. 5 shows the design recommendation for the utility and tool boxes at a later stage in the development.

Colors were another area where the designers had something to contribute. We had some color schemes in hand from our earlier work on widgets as well as from our work with HP's SoftBench product. This greatly simplified the tricky decisions required to convey the 3D quality of widgets. We provided the color names and RGB values that had to be assigned to each widget component to make the 3D effect work and provide a pleasant overall interface.

Fonts were also important. Graphical user interfaces in general, and the 3D widgets in particular, are very much dependent on good fonts to be successful. While the popular notion of a graphical interface centers on icons, most of the work is still done with words, and good proportionally spaced fonts make words work better. The HP IVIBuild team decided to use some display fonts that had been created by HP expressly for 3D widgets. These fonts provided both behavioral benefits (text properly centered in widgets, text baselines lined up, etc.) and a consistent, high-quality look.

The designers also created all of the biomaps and icons associated with the tool boxes and other aspects of the product. One challenge with many of the tool box buttons, especially for those in the widgets mode, was to express the 3D nature on a small scale and with only two colors. The illusion of using three colors was achieved by using a light and a dark color and then introducing a dithered pattern that the eye blends together to form a third color (see Fig. 6).

The final area of collaboration was to do something visual and graphical to help explain and sell HP IVIBuild. Some sample screens were created that express how HP IVIBuild can actually be used. With just a little prompting on how to use the 3D effect, a designer used HP IVIBuild to create two sample screens for each of seven potential application areas. These compelling images, achieved through the use of the actual tool, have done more to explain HP IVIBuild and its capabilities than a volume of marketing brochures. One of these sample screens is shown in Fig. 2 on page 8.

Conclusion

We learned a few things as a result of this collaborative exercise. One is that experts often have problems communicating their concepts and ideas to nonexperts. In this case we had two groups of experts. We found that it was important to have a main conduit or interpreter between the user interface designer and the rest of the software team. Without someone to answer all of the questions the user interface designer asks, and interpret the various dialogs with the team members, the communication process really breaks down. One designer interfacing with a half-dozen individual team members means a half-dozen different interfacing styles.

Another lesson we learned is how important it can be to have an early vision of what you are trying to do. Tools exist that enable designers to create this vision and user scenarios quite quickly. The power and usefulness of these visuals should not be underestimated. They are powerful catalysts for people's thinking and communication. Once these are analyzed, discussed, and modified, the product is better understood by all concerned. Only at this point should the interface coding begin. The mistake should not be made of brining the visual design help in at the very end to fix up the icons. Chances are the flaws go far beyond cosmetic graphics, and at this point the investment has been so great that significant changes are nearly impossible.

References

[1] A.O. Deininger and C.V. Fernandez, "Making Computer Behavior Consistent: The HP OSF/Motif Graphical User Interface," Hewlett-Packard Journal, Vol. 41, no. 3, June 1990, pp. 6-12.

[2] D.L. McMinds and B.J. Ellsworth, "Programming with HP OSF/Motif Widgets," Ibid, pp. 26-35.

[3] M.R. Cagan, "The HP Softbench Environment: An Architecture for a New Generation of Software Tools," Ibid, pp. 36-47.

[4] "OSF/Motif," Ibid, p. 8.

Steven R. Anderson Visual interface designer Steve Anderson helped design the user interface for the HP IVIBuild product. He joined HP's Calculator Products Division in 1976 and was responsible for the industrial design package for the HP 9845 computer/controller and computer system furniture products, including the HP 92214 CAD worktable. Now a lead designer on the HP VUE graphical environment for HP-UX workstations, Steve's professional interests include making computers visually appearing and fun to use. He is named as an inventor on an industrial design patent for a Xerox copier, coinventor of a product design layout patent on a color printer concept from HP Laboratories, and coinventor on a patent application for HP 3D widgets and extensions. Steve received a BS degree in industrial design from the University of Bridgeport in 1966. Born in Hibbing, Minnesota, he is married, has two children, and lives in Mountain View, California. He enjoys playing golf at dawn on Sundays, bicycling to work, and activities with his children.

Jennifer Chaffee Jennifer Chaffee worked on the user interface for the HP IVIBuild product at HP's Industrial Applications Center. She joined HP in 1988 and worked on HP OSF/Motif and the HP New-Wave Office. Before coming to HP, she worked in the industrial design and user interface department of the Xerox Corporation copier division. A 1985 graduate of the Rochester Institute of Technology with a BFA degree in graphic design and art history, Jennifer's professional interests include the visual design of computer user interfaces. Born in Forth Worth, Texas, she lives in Sunnyvale, California. She enjoys painting, pastels, pottery making, backpacking, travelling and photography.

COPYRIGHT 1990 Hewlett Packard Company
COPYRIGHT 2004 Gale Group