User Interface

Requirements for FRAMES User Interface (FUI), PNNL-SA-32277

1.0 Introduction

The Framework for Risk Analysis in Multimedia Environmental Systems (FRAMES) is a software platform for selecting and implementing environmental software models for risk assessment and management problems. The FRAMES User Interface (FUI) allows users to link, select, and interact with environmental codes for environmental and human health analyses. The general concepts and specifications of FRAMES are provided in Whelan et al. (1997).

2.0 Purpose of FRAMES User Interface

The purpose of FUI is to provide users with an intuitive way to link, select, and interact with environmental codes in FRAMES. FUI should allow users to develop conceptual model of problem in a pictorial way. Currently, MEPAS© and Generation II (GENII) (MMSOILS need up-dates for current specifications) modules are available in FRAMES. Other codes are scheduled to be included in future. FUI also allows user to view FRAMES compatible files (i.e., those that meet FRAMES data specifications) from environmental codes in both textual and graphical modes.

3.0 Summary of Requirements for FRAMES User Interface

The FUI will:

  1. allow the user to create, access, save, and exit Global Input Data (GID) files.
  2. allow the user to pictorially develop a conceptual site model for scenario.
  3. provide help and about information to the user on how FUI operates.
  4. allow the user to select different environmental icons (constituents, source, vadose, aquifer, surface water, air, overland, intake, exposure, impacts, imports, exports, closed form, data viewers, and sensitivity/uncertainty) to develop conceptual picture of problem.
  5. provide the user with a signal light indicating the status of each icon associated with the scenario.
  6. provide data viewers to allow users to view text and graphical information produced by any module that adheres to FRAMES data file specifications.
  7. provide error messages to the user when inappropriate links and module selections occur.
  8. operate in Window95 and have the look and feel of Windows.
  9. allow access to modules selected for the scenario via Module Options List.

4.0 Input Requirements for FRAMES User Interface

The FUI is the first thing that the user sees when running FRAMES. FUI is used to define conceptual site model and modules to be used. The following are main functions of FUI:

  1. GID file control (open, close, save, save as, exit, and import scenario);
  2. scenario definition (select module types and connections);
  3. customize description of scenario (show user-define or system defined labels for icons);
  4. GO button to run all scenario models in sequence;
  5. on-line electronic help for FUI function and operations; and
  6. tool tips for Module icons on FUI tool bar.

File Control. The user must create or select a GID file for each scenario. This can be done through main screen of FUI and operates with Windows-like functionality. The user is  able to create a new or open an existing GID file. GID file naming convention follows Windows protocol. The user is also allowed to Save, Save As, and Close GID file. The Close function will query user if they want Save and Close or Close without saving. The user has option to exit FUI. Again, FUI asks if GID file should be saved or discarded and then exit FUI. Requirements for file control are summarized in the following list:

  • have look and feel of Windows
  • open existing GID files
  • save GID files
  • save As GID files
  • close GID files
  • exit GID files (without saving).

Scenario Definition. One of main functions of FUI is to allow users to define a conceptual site model for problem. FUI allows users to "drag 'n drop" module icons to pictorially define problem. Users can develop a full conceptual site model of problem by selecting and linking different module types (currently FRAMES has constituent, source term, vadose zone, aquifer, surface water, overland, air, intake, exposure, impacts, sensitivity, import, export, closed form, and data viewers). FUI has pre-defined rules for linking different module types (specific models have not been selected yet) and these are defined for each module types currently in FRAMES.

Once module types have been selected for scenario, models are selected for each module by clicking on module icons. Additional linkage rules are applied depending on description (DES) file information associated with each model. The FUI provides an error if user tries to link module inappropriately. four-stage status light system associated with icons should provide guidance to user as to current status of each module in scenario. Users also can delete an icon by dragging and dropping it into "trash" icon. Users can also do a print of scenario developed to a file or printer.

Once a module type icon is selected, the FUI provides user with a selection of models associated with that module type through General Information menu in Module Options List. The General Information menu is activated by "shift-left button" click of mouse when positioned over icon. This menu provides users with a list of models available under that module type. Users can scroll through list and read different descriptions of each model via DES file. DES file provides user with a brief description of model, its functions, limitations, linkages, and reference to more detailed information, including contact name and phone number of model developer. A DES file will exist for each model associated with FRAMES and is provided by model developer. A user selects a model based on DES files information and provides a unique name to icon associated with model.

Summary of requirements for Scenario Definition are:

  1. display four-stage status light system to inform the user of scenario condition
  2. "drag and drop" module type icons to build conceptual site model, status light without colored lights
  3. link module type icons and provide errors if linked improperly
  4. select models associated with module type (user can use DES files to determine appropriate models), a red light should appear after model has been selected
  5. input data to model though its module user interface (MUI), a yellow light should appear after data input is completed.
  6. run model, a green light should appear after model has successfully run
  7. allow "drag and drop" of module type icon into "trash can" to remove it from the conceptual site model picture
  8. ability to print scenario picture to printer or file.

Customize description of scenario. The FUI allows users to customize their scenarios by displaying a user-defined name for each module type or that name and computer-defined labels (object ID). When a user selects a model for a module type, he is required to provide a name for the module. The computer will define a label for that module to pass on to other modules for linkages. Uses have an option in the FUI to use the name they have provided or that name and label that computer has assigned to module.

GO button to run all scenario models in sequence. The FUI allows users to click on "GO" button and run all modules associated with scenario. In many cases, users change a value in the source module and all modules downstream change status to "yellow" (input complete but model needs to be run). The status of these modules change because FUI does not know how change upstream will impact results downstream. If the user is unsure, the "GO" button can be used to run all modules. The user also can click on each individual module to run it and look at results one step at a time; in that case, the "GO" button should not be used.

On-line electronic help for FUI function and operations. The FUI has on-line help associated with FRAMES functions and operation of software.  FUI help also has references to more information. Help will also be provided on FRAMES and its data specifications (i.e., WFF, AFF, SCF, WCF, ATO, EPF, HIF, RIF, and SUF). This help will be in HTML format. There is also an About function that provides users with title, version number, and a brief description of model.

5.0 Output Requirements for FRAMES User Interface

There are two main types of output from FUI: 1) scenario diagram printed to file or printer and 2) textual and graphical viewers for standard FRAMES files. FUI allows the user to select the module type icons and link them together to build a pictorial diagram of scenario. Users and reviewers can view this pictorial diagram of scenario whenever GID file is opened. The scenario can also be printed to a file or printer for documentation.

The generic textual and graphical viewers associated with FUI are used to review and interpret results from scenario analysis. These viewers are considered generic because they read all FRAMES specified files (i.e., WFF, AFF, SCF, WCF, ATO, EPF, RIF, HIF, and SUF). The textual viewers allow the user to review data as produced and determine if information is appropriate. These data cannot be printed though FUI but individual files can be printed via viewers. Before graphical viewers can be used, they require Microsoft Excel and GNUPLOT to be on system. These viewers link with Microsoft Excel or GNUPLOT (for air concentrations) to plot results. The requirements for these text and graphical views are defined in Viewers Requirements Document.

6.0 Scientific Requirements for FRAMES User Interface

None.

7.0 Recommendations

The following is a list of recommendations on future additions and updates to this module. This list is not meant to be all-inclusive but includes only the modifications that have been suggested by users and developers. This list can be used to help prioritize modifications to this and other modules based on the overall strategy of the software system.

Recommended additions and modifications to this module are:

  1. plus Operator to combine fluxes, concentrations, doses, and impacts from different models
  2. print module user interface data from FUI Module Options List
  3. copy Modules (model selected and data)
  4. copy Scenario and data (module, models, and data)
  5. new Module icons
  6. allow multiple sources in scenario
  7. allow secondary source in scenario
  8. add constituent database modules (MMEDE or some form of MMEDE)
  9. import other model input files (i.e., MEPAS 3.2 PRM, GENII input file)
  10. report writer for FRAMES files

8.0 References

Whelan G., K. J. Castleton, J. W. Buck, G. M. Gelston, B. L. Hoopes, M. A. Pelton, D. L. Strenge, and R. N Kickert. 1997. "Concepts of a Framework for Risk Analysis in Multimedia Environmental Systems (FRAMES)." PNNL-11748, Pacific Northwest National Laboratory, Richland, Washington.