User Interface Design of the WFO-Advanced Workstation

USER INTERFACE DESIGN OF THE WFO-ADVANCED WORKSTATION

U. Herb Grote* and Carl S. Bullock

NOAA Forecast Systems Laboratory
Boulder, Colorado 80303-3328

1. INTRODUCTION

The Forecast Systems Laboratory has always placed great emphasis on developing a user interface that is easy to use and that permits forecasters to perform their job more efficiently. The WFO-Advanced workstation design takes advantage of many years of experience with DARE (Denver AWIPS Risk Reduction and Requirements Evaluation) and earlier workstations (Bullock et al. 1988).

FSL's approach to user interface design has always included a significant amount of prototype development and early involvement of the operational forecasters. The availability of the X Window System and high performance workstations has provided significant challenges and also new opportunities. Over the years many tools have become available that simplify the development of window-based user interfaces.

2. USER INTERFACE DESIGN PHILOSOPHY

FSL's design philosophy reflects nearly 16 years of real-time workstation and user interface development. It has been shown repeatedly that the most important ingredient in developing a workstation user interface is that the designers be thoroughly familiar with the task to be performed. It is not sufficient for the designers and implementers to fulfill a series of functional and performance requirements delineated in a specifications document. In itself, this does not guarantee that the user interface will meet the user's needs. What is difficult to specify in such a document is how the user utilizes the various workstation functions in the context of performing the job. A user interface that causes the forecaster to hunt for the desired selectors or perform excessive mouse clicks may result in a delay of several minutes in issuing a severe weather warning. The requirements for a well-designed user interface go beyond being intuitive and easy to use. The user interface must simplify the user's task.

The following discussion elaborates on the basic philosophy used in the design of the WFO-Advanced user interface.

2.1 Organization and Layout Consistent with Task

The organization of the user interface must be logical to the user. The WFO-Advanced menu reflects a "funnel" approach (Snellman, 1982) to forecasting in which the user performs the basic forecasting tasks over successively smaller geographic areas. A number of scales have been predefined to help the user in this process. Furthermore, the organization of the screen allows users to monitor events on different geographic scales concurrently. The screen consists of four small monitoring windows and one main window for display of meteorological data. Also, the data selection menu is laid out from a meteorological perspective, i.e., by surface, upper air and volume, as opposed to strictly by data source.

2.2 Logical Consistency of User Interface

The components of the user interface must be efficiently organized and function together to do the desired job. Assume that the forecaster wants to view a 500 hPa height product: through the use of "family graphics", the user can actually load many additional products, such as 500 hPa vorticity, at the same time. Once the model grids are loaded from a menu, a single mouse click can then display the additional products by toggling a graphic on or off. A single mouse click will also change a contour field into an image, start animation, change the contour density, perform a zoom, underlay an image or invoke one of many other functions. The user can also load four images simultaneously into the main display window. In the case of radar, this allows the user to look at four different elevations at the same time. With a single selection, the user can overlay lightning data on the four radar images.

2.3 Fast Access to Frequently Used Data

Analysis of usage logs from DARE has provided valuable information regarding the most frequently used products. By making the most commonly requested products available with a single button click, as in the first menu layer, the system can be very responsive to most of the user requests. Since system performance is measured from the time the user decides to load a product to display, simplifying the user interface can significantly improve overall response (MacDonald, 1985). Performance is an underlying design driver for all parts of the workstation.

2.4 Easy Specification of User Request

Various load parameters are needed each time a product is loaded. For example, color maps, contour line style, plot density, text annotation, and the number of animation frames may need to be known to the system to properly load a product. When loading a radar image, the user interface automatically assumes that the user will want to view additional radar frames and therefore directs the system to load several frames (as specified by the default). Significant time can be saved if defaults for these values are predefined so that the user does not have to provide explicit information. WFO-Advanced uses defaults for many parameters based on individual forecasters preferences or general consensus. The user interface provides users the ability to redefine many of the system defaults.

2.5 Avoidance of Modality

Requiring the user to change operational modes can significantly reduce the efficiency of a user interface. For example, if the user has to exit the watch/warning mode in order to display an additional product, considerable time can be lost switching between modes. Executing an application should not prevent the user from performing other functions. When executing an application, such as the interactive skew-T, in the WFO-Advanced, the user can still perform other actions such as zooming or panning in one of the small monitoring windows.

2.6 System Transparency

The forecaster needs to be able to concentrate on the meteorology rather than on how to operate the system. A screen filled with resizable and overlapping windows may be ideal for a research meteorologist to analyze a particular set of data but may create an excessive screen management burden for an operational forecaster. To reduce the need for such screen management, WFO-Advanced uses tiled windows for displaying data. The system transparency is also illustrated by the fact that the user is unaware of the window implementation. The four "monitoring" windows use 24-bit color and the main window uses 8-bit color plus another 8 bits for overlays. This difference in implementation is hidden from the user.

2.7 Customization and Reconfiguration

Two levels of tailoring were desired for the WFO-Advanced user interface. At the low level the user interface needs to be configurable to allow individual forecaster's display preferences (such as color tables and contour intervals) and private procedures to be used. At the higher level, the user interface must be configurable to work with one or two monitors, with one mouse or two, with or without keypads, and with the text editor running on the graphic display or on a separate device. This flexibility allows the user interface to be tailored for the most efficient use for a particular site, hardware configuration, or user.

2.8 Partitioning of Major Tasks

In the WFO-Advanced, the text and graphic functions are fairly independent activities. As a result, the user interface has been designed so that each of these activities is essentially self-contained. This partitioning simplifies the user interface, since text products can be accessed through a separate menu. It also makes it possible to move the text menus to another screen without any impact on the software. Furthermore, the graphic functions are partitioned in such a manner that the entire user interface can be replicated on another screen. This approach avoids possible confusion when one user interface controls two graphic screens.

2.9 Ease of Learning

The user interface is designed to allow an uninitiated user to quickly perform the basic workstation functions. It is assumed that most users will not read the user guide from cover to cover before using the workstation. The interface must therefore be easy to learn and also very forgiving. It must survive interactive exploration by a novice user. Complex selections requiring simultaneous multiple actions, such as pressing a key on the keyboard and a mouse button, are avoided.

3. USER INTERFACE DESIGN APPROACH

FSL's software development technique is most closely described by the spiral model of software development. In the spiral model, the software evolves through a series of functional prototypes that eventually become the final product. Significant testing of each prototype occurs before the development proceeds to the next cycle.

The design of the first prototype is the most crucial since it provides the foundation for all subsequent development. FSL implemented two competing designs at the start of the WFO-Advanced project and evaluated them over a period of months. One design consisted of five tiled display windows with a menu bar at the top, and a second consisted of resizable and overlapping windows for the display and menu. A significant number of users provided feedback on the two alternatives. The selection of the best design was made in a user interface meeting after the pros and cons of the two approaches were discussed extensively.

With the guidance of the User Interface Working Group (UIWG), the user interface continued to evolve through a series of operational prototypes, each providing slightly more capability than the previous one. In addition to these scheduled prototypes, rapid prototype development of key features was done using a development tool known as tcl/tk. This rapid prototype development provided a means to test and refine user interface concepts before incorporating them into the operational prototype. The first comprehensive test of the entire system was performed approximately half way through the development and lasted several weeks. Feedback from this test resulted in a number of changes to the system. Approximately two months later forecasters from the National Weather Service evaluated the improved prototype system by using the system to make actual weather forecasts. This evaluation provided a high degree of confidence that the system would meet the needs of operational forecasters.

The three key components of the user interface design were design discussion, developing prototypes and testing. Each of these components is discussed in more detail.

3.1 Design Discussions

The design was performed by the UIWG comprising approximately five meteorologists, most with operational forecast experience, and a similar number of software engineers. The group met weekly for several hours to discuss the design of the user interface. Each design component was accepted by consensus. If there was significant disagreement or the group was uncertain about a particular approach, then a prototype of the component was prepared. The meeting notes were a valuable tool in documenting decisions and communicating the design to developers.

3.2 Developing Prototypes

Producing prototypes significantly reduces software development time since bad designs can be quickly identified before major software development commences. FSL relied heavily on tcl/tk to develop most of its prototypes. Tcl/tk proved so robust and flexible that it was integrated into the workstation software (Kelly, 1997). Several major user interface components (the product maker, text menus and volume browser) now use tcl/tk. Although, prototypes are immensely helpful in evaluating new design concepts FSL was careful not to create a prototype for every new concept. Creating unnecessary prototypes can increase costs and delay schedules.

3.3 Testing Prototypes

Various individuals tested and evaluated the WFO-Advanced during its development. The members of the UIWG tested each prototype before it was implemented or integrated into the workstation. Also, inhouse meteorologists performed extensive evaluation of the new features and provided their feedback to to the UIWG and software developers. Of particular value were FSL's daily weather briefings, which provided an ideal opportunity to continually test new features in a quasioperational environment. FSL conducted two formal exercises to test the entire system for an extended period of time. Valuable information was collected through usage logs, by forecaster observation and by written and oral feedback. All of this information provided valuable guidance in refining the design.

4. SPECIAL FEATURES OF THE WFO-ADVANCED USER INTERFACE

Three specific examples of the WFO-Advanced user interface are presented here to illustrate particular features of the WFO-Advanced user interface. For a complete description of each of these and other menus the reader is referred to the WFO-Advanced User Guide (FSL 1996).

4.1 Screen and Menu Layout

Figure 1 shows the WFO-Advanced user interface with its main window and four smaller "monitoring" windows along the side.

Figure 1. WFO-Advanced User Interface.
To simplify the user interface, only the main window can be used to load new products. This restriction eliminates the ambiguity of which window is the target of a menu action and the complexity of multiple menus for multiple windows. A click of the third mouse button over a small window quickly swaps the contents of that window with the main window. Except for the ability to load new products and toggle overlays, the small windows can perform most of the functions of the main window. Animation, zoom, and pan are all possible in the small windows.

4.2 Volume Browser

The volume browser (shown in Figure 2) is used to select and load model data and other three-dimensional datasets.

Figure 2. The Volume Browser Dialog Box.
The browser was designed specifically to allow access to over 30,000 gridded fields. The user selects one or more models, fields, and planes and the menu lists all possible permutations of these parameters. The user can then select any or all of these products to be loaded to the screen.

The browser is multidimensional in that model, field, level, and time are used to fully specify a product (if no other product has been loaded, the time is the most recent). However, the menu is smart enough to complete the specification if two choices can uniquely specify a product. For example, if a user selects a model and precipitation, the menu will complete the specification by providing "surface" as the level.

If a complete specification has been provided and the user wants to see the same fields at the same levels for another model, the user need only select the new model. The browser will automatically complete the specifications for these products.

4.3 Product Maker

The product maker (shown in Figure 3) allows the user to create a new derived field from gridded data.

Figure 3. The Product Maker Dialog Box.
This provides significant additional capability that did not exist in previous FSL workstations. The product maker menu consists of three major parts: the fields, operators, and the stack. To create a new product the user selects the desired data by specifying model, field, height, and time in the field menu. This specification is automatically transferred into the first register in the stack. Additional fields can then be specified in the same manner and loaded into the other registers. The desired operator is then selected from the menu and the operation is executed. Upon completion of the operation, the newly defined field is displayed in the primary display window, as is any other graphic product. The product maker provides considerable flexibility in defining new products.

5. SUMMARY

The design of a user interface requires the early and continuous involvement of the end user. Extensive use of prototypes is invaluable in the development of the user interface since even the best system specifications cannot adequately capture how the various functions are used by the forecaster in performing the job. Forecasters tested the WFO-Advanced system repeatedly and provided regular feedback on the usability of the system. This feedback significantly reduced the risk that the system would not meet the needs of an operational forecast office.

6. REFERENCES

Bullock, C., Wakefield, J., Brundage, J., Walts, D., LeFebvre, T., Amstein. P., 1988, The DARE Workstation and some Lessons Learned from its Operational Use, Preprints Fourth International Conference on Interactive Information Processing Systems for Meteorology, Oceanography, and Hydrology, Anaheim, CA.
Kelly, S., 1997, The Application Interface for the WFO-Advanced Forecaster Workstation, D2D. Preprints Thirteenth International Conference on Interactive Information Processing Systems for Meteorology, Oceanography, and Hydrology, Long Beach, CA.
MacDonald, A. E., 1985, Design Considerations of Operational Systems: A Perspective based Upon the PROFS Experience. Preprints International Conference on Interactive Information Processing Systems for Meteorology, Oceanography, and Hydrology, Los Angeles, CA.
Forecast Systems Laboratory, 1996, WFO-Advanced User Guide, (http://www.fsl.noaa.gov/~osborn/D2DUG_ToCFigs.html)
Snellman, L. W., 1982, Impact of AFOS on Operational Forecasting, Reprints, 9th Conference on Weather Forecasting and Analysis, AMS, 13 - 16.

* Corresponding Author Address: U. Herb Grote, NOAA/ERL/FSL, Mail Code: R/E/FS4, 325 Broadway, Boulder, CO 80303-3328; e-mail: u.herb.grote@noaa.gov.