A representative text display is shown in Figure 1, including the master control window in the upper-left corner of the screen, and three text display windows. One display window shows the editor controls, another displays a list of surface observations, and the last shows the product selection browser. We are currently using the HP VUE window manager, so Motif-like window frames are shown here.
(Click to see a full-screen display - 85k.)
In addition to the dedicated text display screen shown here, individual text display windows are available on the graphic display screens. These display windows are not fully integrated into the event dispatching mechanism, and lack the auto-update and alarm capabilities to be discussed later.
The window in the upper-left corner of Figure 1 is the master control window for the text display. It provides a list of the windows available, and the product displayed in each. Clicking on the associated entry in the list brings that window to the front, opening it if necessary. Four windows are available by default, but more may be created if desired. The control window also provides access to the product alarm/alert mechanism, specification of the user (to provide access to that user's customized scripts), access to interactive evaluation logs, and access to the standard Exit button in the File menu which exits the entire text subsystem.
As shown in Figure 2, each display window contains (from top to bottom) a menu bar, a control bar, a text display widget, and a status bar. The menu bar provides access to a set of pulldown menus for controlling the operation of the window.
A set of common operating controls have been put into the control bar, immediately below the menu bar. The Browser button provides access to an interactive product browser. The Load command button and text entry widget next to it are for typed command entry, using a subset of AFOS command-line syntax. The Enter Editor button puts the window into text editing mode. The Accum toggle button causes loaded products to be accumulated (appended) to the window, rather than overwriting existing contents. The Update Obs button causes any surface observations in the window to be automatically replaced with new ones as they become available.
Most of the screen space within the display window is occupied by the text display widget itself. A monospaced font is used here for compatibility with columnar text products that rely on spaces for formatting. The size of the font used for displaying in this widget may be changed by the user.
The bottom of the display window holds a one-line status widget, for display of status and error messages.
The product browser works by providing a controlled way of interactively filtering the thousands of available text products down to a manageable handful from which selection can be made for loading. The first pass of filtering is done by restricting the area of origin and the general type of product, via the Origin and Class controls. Next, an AFOS-like product identifier is created by selecting left-to-right from the originating site, the product category, and finally, the product designator. As a selection is made in each panel, the panel(s) to the right are dynamically updated to reflect the products available down this path.
Upon entering the editor, the loading of products is disabled to prevent accidental overwriting of the product being edited. (If an additional product is desired, it can be cut from another window and pasted into the edit window). Two additional user interface widgets appear below the control bar: the product header and the edit tool bar (Figure 4).
The product header displays the two-line AFOS header for the product. Originally this header display was not editable, but at the request of Denver forecasters, it now has basic editing capabilities, to allow for headers not currently recognized by the header block dialog box.
The Edit tool bar contains buttons to provide easy access to the following edit operations: Cut, Copy, Paste, Fill, Edit Header, Save & Exit, Cancel, and Insert/Overstrike.
Cut, Copy, and Paste support copying of selected text from one part of a window to another, between text windows, as well as to and from other X windows, including other text editors.
The Fill button fills and auto-wraps the currently selected text.
Edit header pops up the same dialog box used when the editor is first entered, to help the user create a well-formed product header.
Save & Exit writes the contents of the edit window to the database, and disseminates the product if appropriate. In the current version, all products are sent to the local AFOS, which then decides to disseminate or not.
Cancel terminates the editing session, and reloads the product last displayed in the window, if there was a product loaded when the editor was entered.
Individual forecasters can extend the capabilities by writing scripts, written in Tcl. Very simple scripts can be very useful to forecasters, such as simply loading a common set of related products. But since the scripting language is Tcl, a wide variety of control structures are available for use in more complicated scripts.
While the use of Tcl/Tk has been a major asset to the project, there were a few issues related to its use that caused some problems. The largest organizational problem we had with Tcl is that there are only two namespaces: global and function-local. This well-known problem with Tcl will be remedied in future versions of the language. We addressed the problem with a set of standard global variable prefixes.
Customization of the Tk text widget was also rather difficult. The Tk text widget is the most complicated and functional of the Tk widget set, implementing essentially an entire text editor. For us, it was a classic software reuse problem of an existing component being "almost, but not quite" what we needed. The auto-wrap capability was frustratingly close to what we needed, but in the end, we turned it off and implemented our own version.
For example, the UNIX command line
textdb -r DENNOWDEN | more
will pipe the latest Denver nowcast into a display program for online viewing, and the command line
textdb -w DENWRKNOW < workFile.txt
will store the contents of workFile.txt (created by an application program, for example) as a work file in the text database.
The DARE text subsystem, in turn, was designed to build upon forecaster familiarity with AFOS. And so, elements of the AFOS user interface, such as product naming and command-line syntax can still be seen in the WFO-Advanced text system.
The DARE text subsystem has been in operational use at the Denver and Norman forecast offices for a decade. The system runs on MicroVAX workstation hardware, under the VMS operating system, and uses a windowing system built in-house. As one might expect, the system is beginning to show its age. One of the major goals of the WFO-Advanced text subsystem is to provide a more portable and extensible system.
The basic text display framework used in the earlier system was similar to that in use now, but the editing philosophy was substantially different. All text generation and editing was done within a commercial off-the-shelf (COTS) word processing application, WordPerfect. Interaction between the display and editing components was aided somewhat by a set of WordPerfect macros and Tcl/Tk dialog boxes, but was still awkward.
Integration of a COTS word processor with the text display was not well received by forecasters, which can be attributed to two major causes. First, a full-featured word processor provides a major set of capabilities which are totally irrelevant to the job of today's forecast preparation. These capabilities are at best irrelevant, and at worst a major source of distraction and confusion. Second, text products as currently distributed over AFOS (and worse) are subject to a wide variety of constraints for backward compatibility with existing systems. Today's forecast product is upper-case ASCII subset, with restricted line length, often relying on monospaced fonts for columnar alignment. Using a full-featured word processor for such a restricted final product is just not a good conceptual match.
Another integration difficulty with this approach was the difficulty of communicating between the display application and the word processor. A scriptable word processor (one that could be sent scripts or commands by other applications) would have made the interface smoother. For example, when a new text warning product needed to be edited, all the system could do was pop an alert dialog stating "Please press the Edit Warning button in the editor button box." In our current implementation (as in the DARE version) the product is automatically retrieved by the editor, and is all set for the user to begin editing.
The 1995 text subsystem implemented a product selection browser via a large three-level deep set of cascading menus. The first menu selected the originating site, the second level specified the category, and the final menu selected the individual product. The menus were dynamically modified to reflect geographic origin and message category filters. Unfortunately, the resulting mass of cascading menus was physically too difficult to reliably traverse. A momentary misdirection of the mouse could cause one to have to start the menu traversal over at the root menu. Adopting the multipanel dialog box approach used in DARE resulted in higher user satisfaction.
Mathewson, M. A., 1996: Using the AWIPS Forecast Preparation System (AFPS). Preprints, 12th International Conference on Interactive Information and Processing Systems (IIPS) for Meteorology, Oceanography, and Hydrology, Atlanta, Amer. Meteor. Soc., 194-197.
Ousterhout, J., 1994: Tcl and the Tk Toolkit. Addison-Wesley.
Roberts, W. F., Kucera, P. C., Lusk, C. M., Walker, D. C., and Johnson, L. E., 1996: 1995 Real-Time Forecast Exercise for WFO-Advanced. Preprints, 12th International Conference on Interactive Information and Processing Systems (IIPS) for Meteorology, Oceanography, and Hydrology, Atlanta, Amer. Meteor. Soc., 198-201.
Corresponding author address: Michael Biere, NOAA/ERL/FSL/SDD R/E/FS4, 325 Broadway, Boulder, CO 80303; e-mail michael.biere@noaa.gov.