| HOME | HELP | FEEDBACK | SUBSCRIPTIONS | ARCHIVE | SEARCH | TABLE OF CONTENTS |
|
|
|
|||||||
|
|||||||||
a Remote Sensing and Modeling Lab., USDA-ARS, Beltsville, MD 20705 USA
b Duke Univ. Phytotron and USDA-ARS Remote Sensing Modeling Lab., Bldg. 007, Room 008, BARC-West, Beltsville, MD 20705 USA
c Dep. of Horticulture, Univ. of Maryland at College Park, College Park, MD 20742 USA
d Dep. of Soil and Plant Sciences, Mississippi State Univ., Mississippi State, MS 39762 USA
ypachepsky{at}asrr.arsusda.gov
Received for publication September 23, 1998.
 |
ABSTRACT |
|---|
 TOP ABSTRACT INTRODUCTIONInterface usabilityPlugging a crop simulator...NOTESDesign evaluation and discussionREFERENCES |
|---|
Abbreviations: DLL, dynamic link library • DSS, decision support system • GUI, graphical user interface
|
INTRODUCTION |
|---|
|
TOPABSTRACTINTRODUCTIONInterface usabilityPlugging a crop simulator...NOTESDesign evaluation and discussionREFERENCES |
|---|
Developing a simulator is the most important but only the first step in knowledge dissemination. The next step is to provide tools to simplify operation of the crop simulator by end users. The need for such tools stems from limits to the computer literacy of users, and from the lack of free time for learning and/or performing tedious procedures for entering data and displaying results. Without these tools, potential benefits from the use of the simulators may not be realized, and assembling the input data may be a formidable task. Developing a user interface that incorporates these tools has been recognized as an essential step toward increasing the utility of crop simulators and decision support systems (Landivar et al., 1989; Cox, 1996).
Command-line interfaces have been replaced during the last decade with graphical user interfaces (GUI) based on graphics (icons, pictures. and menus) instead of text. User interface design and implementation is a growing field in software engineering (Redmond-Pyle and Moore, 1995). The theoretical background of user interface development lies in human–computer interaction studies (Macaulay, 1995). The functioning of human cognition and memory has profound implications for interface development (Mandel, 1997). GUI development is centered on setting the usability requirements (Redmond-Pyle and Moore, 1995) that will simplify the performance of predefined tasks. The issues addressed are ease of learning, elimination of sources of errors, ergonomics, and prevention of frustration and negative feelings about the interface. The main issue, however, is understanding the user's needs.
Several graphical user interfaces to crop models are described in the literature (e.g., Hoogenboom et al., 1994; Van Evert and Campbell, 1994; Waldman and Rickman, 1996; Testezlaf et al., 1996). All of them have been built specifically for a single crop model or for a family of models. In spite of several attempts to standardize crop simulators, the numbers and contents of input and output files vary from one crop simulator to another. This does not mean, however, that each crop simulator or family (suite) of crop simulators must have its own GUI. Learning several different GUIs to perform similar tasks with different crop simulators is neither a necessary nor a desirable use of time for such busy people as farmers. Therefore, there is a need to develop a generic GUI that can be used with all, or at least most, crop simulators—a need that has already been discussed (e.g., Rewerts et al., 1989; Wu, 1992).
Crop simulators have various groups of users, including consultants, farmers, students, and researchers. The uses of crop simulators vary among the groups, and so do the usability requirements. Farmers constitute potentially the largest group of crop simulation users. On-farm crop simulations provide decision support information for farm operations. The on-farm simulations should provide (i) warnings of the need to perform certain management operations and (ii) a summary of the consequences of doing or not doing the operation. Results of the simulations should be presented in terms that are most meaningful for farmers. Surveys of on-farm use of computerized decision support systems (DSSs), both simulation- and non-simulation-based, have shown that the complexity of DSS use is one of the most limiting factors (Greer et al., 1994). One reason for this complexity is the absence of experience and the lack of interest in developing user interfaces shown by developers of expert systems and models (Rewerts et al., 1989). A GUI needs to be developed specifically for on-farm use.
More attention must be paid to usability of crop simulators. User interfaces appear to be the key components. The software industry is currently migrating from GUI to object-oriented user interfaces (OOUI) that provide direct manipulation of objects instead of providing functions to perform (Mandel, 1997). At the same time, the research community is accumulating experience in coupling spatiotemporal data with models (Srinivasan and Engel, 1994; Christakos, 1998)—in particular, in site-specific agriculture. These new trends present important directions for the development of user interfaces for crop simulators in order to enhance their use. Precision farming is the emerging technology where these interfaces can find direct applications.
Our objectives were to (i) develop a GUI specifically oriented to on-farm use and (ii) research the possibility of building a generic GUI that can be used with many crop simulators not necessarily having the same structure of input data. We call the interface GUICS, which stands for Graphical User Interface for Crop Simulations.
|
Interface usability |
|---|
|
TOPABSTRACTINTRODUCTIONInterface usabilityPlugging a crop simulator...NOTESDesign evaluation and discussionREFERENCES |
|---|
A typical list of tasks performed by a user of a crop simulator is shown in Table 1 . Broadly speaking, it includes data input, assembling data for a particular simulation, and analyzing the results. The list is general, and the specific content of any task depends on the user. For example, the analysis of crop simulation results may range from a sophisticated statistical and economic analysis (Thornton and Hoogenboom, 1994) to simply looking at the projected yield and the maturity date to determine profitability and the prospects of using the same machinery for several crops (Reddy et al., 1997). Another example is the comparison of simulated and measured data, which is common in research practice but is uncommon in the use of crop simulators on-farm.
|
GUICS is a WIMP interface (Martin and Eastman, 1996); the acronym indicates that the interface includes windows, icons, menus, and pointers. It has a user-centered design (Microsoft Press, 1995), which presumes the usability enhancement by providing six interface features: directness, user-in-control, consistency, forgiveness, feedback, and simplicity. These features are discussed below.
Directness Features
Directness means taking into account the fact that humans are much better at recognition than at recollection (Redmond-Pyle and Moore, 1995). Previous developments of interfaces for crop models have shown a need to present and process information in a hierarchical form (Akins et al., 1993; Humphries and Long, 1995). The hierarchy of information units in GUICS is based on the fact that one run of any crop simulator makes predictions for a particular combination of weather, soil, crop cultivar, and farm operations. Data on weather, soil, and the like, are referred to as datasets, and datasets are organized by data category according to the type of data. A complete set of datasets for a crop simulator is referred to as a scenario. Several related scenarios may be combined into a group that is called a project. Usually a project encompasses several scenarios that describe various fields, various management units within a field, various years, or various management practices. The projects are organized by users in a way that is convenient to them. In contrast, data categories are model-dependent and correspond to the various input files of the crop simulator. GUICS will accept any set of data categories, although the grouping of data by crop production factors (weather, soil, fertilizer, irrigation, variety, etc.) corresponds best to the user's mental model of crop growth as we encountered it.
The interface start-up window shown in Fig. 1 takes the user to the job immediately, as is recommended for application-oriented interfaces (Wood, 1998). The menu bar shows the limited number of mental objects (`Project', `Datasets', `Model', `Weather') that the user needs to operate the crop simulations. The `Project directory' window opens next. It contains a list of projects that have already been created, as well as the buttons `New', Open', `Copy', `Delete', and `Quit'. If no projects exist, all buttons except `New' will be disabled and grayed, to point the user to the action required. When a new project, a new simulation scenario, or a new dataset is created, the next window presents three tools for its future recognition: the name, the memo, and the icon (Fig. 2) . Giving the entity a name helps the user to recognize the item. The memo also facilitates recognition, because it appears any time an item is highlighted by clicking in a list of available projects, scenarios, or datasets (see the example shown in Fig. 3) .
|
|
|
Another way to help recollection is to use wizards that automate tasks through a dialog with the user (Microsoft Press, 1995). In GUICS, wizards are implemented to point out data categories that need to be reviewed when a new scenario is created. The user is guided though the process of picking datasets, as shown in Fig. 4 , and one data category is shown at a time. To help users recognize whether changes have been made to a particular scenario, each scenario has a status attribute, which is set to `Assembled' or `Computed', depending on whether the scenario is new or changed, or has been run (Fig. 3). Most buttons are provided with balloon tooltips explaining their meaning. Wizards are also implemented for filling the input data files. Data tables to be filled are shown to the user one at a time. The buttons `Next' and `Back' provide for navigation within the data input and scenario creation processes, and they are coordinated with the wizard.
|
Simulation results can be presented in several forms: graphics, tables, or text. Some interfaces show some simulation results immediately after the simulation run ends (e.g., Humphries and Long, 1995), but then the user needs to recall how to get to other forms of output. GUICS presents a choice of the type of output immediately after the simulation run (Fig. 5) . The user has a choice of how graphs are arranged on the screen, using the toolbar buttons `Tile', `Cover', `Cascade', and `Mixed'. Various types of printing are available using the Windows common printer dialog.
|
Pressing buttons with the same name results in the same action anywhere in GUICS. For example, the `Copy' button always presents a box asking for a new name, and the `Delete' button always presents a box asking for confirmation. The toolbar buttons `New', `Open', `Copy', and `Delete' work for projects, scenarios, and datasets in the same way. Windows keyboard shortcuts work in all situations in the same way as in other Windows applications: doubleclick will open an item, and selection of several items from a list is always done by holding down the `Shift' or `Ctrl' key while clicking. When multiple variables are available for selection to be displayed in tabular or graphical form, small boxes to checkmark are shown beside the variable names (Fig. 6) . As a user works with various models in GUICS, the appearance of the choice lists is always the same as in the examples in Fig. 6—although the content of the list is model-specific.
|
To facilitate forgiveness, GUICS does not allow any incomplete item to exist. No further progress will occur if the name of a project, scenario, or dataset is not entered. The same will happen if some data category is omitted during the assembly of a scenario. If a simulation run is interrupted, the scenario will have the status `Assembled' and no results will be available for viewing. All datasets have default contents to prevent the creation of bad data files. Deleting a dataset results in the deletion of all scenarios that included this dataset.
Deleting files in error is the most undesirable of all actions. The `Delete' key of the keyboard is not used in GUICS except in text boxes, where it can be used to correct typing errors during input. Warnings are issued at any attempt to delete a project, scenario, dataset, or weather station. If a group of items is to be deleted, warnings are issued separately for each item. When a dataset is changed, a dialogue box appears that provides information about the consequences of the choice (Martin and Eastman, 1996).
To help a user remember how to continue in the middle of an action, a reference help is included in GUICS. This is a task-oriented help, which explains all the actions possible in GUICS. It does not duplicate the GUICS User Manual (Acock et al., 1998), which is written to answer "How do I?" questions and shows all 55 windows and dialog boxes that can be encountered in GUICS.
Preventing faulty data from reaching the simulation is a critical part of the forgiveness of interfaces built for agricultural models (Akins et al., 1993; Cox, 1996). Since GUICS is a generic interface, we assume that checking whether the numbers in a data file are reasonable is a function of the model code. GUICS does, however, perform two types of checks that are not model-specific. First, when a dataset is imported, the data structure is checked for consistency with the input data script for this dataset as used in the simulator under consideration (see Plugging a Crop Simulator into GUICS, below). Second, weather datasets need special attention, because the quality of the weather data downloaded from farm weather stations via modems is not always satisfactory.
To automate access to weather data as far as possible, GUICS allows users to download weather from several weather stations and has two versions of the weather data for each station. One version is the raw binary data downloaded from the stations, and the other is the ascii file used as input by the crop simulators. The format for both files is specified to GUICS in a script file (explained in more detail below, in Documenting Input and Output Datasets). All weather stations accessed by GUICS to run a particular model must have the same format. The days for which weather data are available and the gaps in the sequence are listed each time the weather dataset is highlighted (Fig. 7) . To extend the ascii file, the user has to refresh it from one of the binary files in his or her possession. To fill a gap, the user has the option of patching the ascii file from a binary file downloaded from another weather station (perhaps that of a friendly neighbor) programmed in the same way as the station used before. The `Refresh' and `Patch' buttons are present in the weather data dialog box (Fig. 7) but are absent in the dialog boxes for other data.
|
Simplicity Features
The easy to learn and easy to use requirement presents the challenge of balancing maximum functionality and maximum simplicity while reducing the presentation of information to the minimum required to communicate adequately (Microsoft Press, 1995). This requirement has a lot to do with the functioning of human short-term memory, which typically can cope with no more than seven or eight options (Mandel, 1997). The number of active buttons or available menu options in GUICS never exceeds this number. The GUICS screens contain the minimum number of words to read (e.g., Fig. 3). Another simplification technique implemented in GUICS is clustering or progressive disclosure of information: large amounts of information are broken into smaller clusters that are easier to remember (Martin and Eastman, 1996). The two-tier organization of the information in GUICS (`project scenario', `data category dataset') discloses information progressively, reducing the amount available for a user to work with at any one time. Wizards for assembling new scenarios and for importing new datasets serve the same purpose.
Varying scenarios is another example of progressive disclosure in GUICS. Often users want to vary one aspect of a scenario, that is, to create one or more new scenarios which differ from the original in only a single category of data. An example is creating several scenarios that differ from the original one in weather data, while the datasets in all other categories (soil, cultivar, etc.) are kept the same in all variants. The button `Vary' shown in Fig. 3 leads first to a list of data categories and then, after the category is chosen, a list of datasets is presented for selection. After the selection is made, the list of scenarios has added to it a scenario with the same name as the original plus the number of the variant in brackets (Fig. 3). The memo of the dataset is appended to the memo of the original scenario, to form memos of the variants and to facilitate their recognition. The results of several scenarios can be viewed simultaneously in the same table, in graphs with different colors, or in summary or report windows shown simultaneously (Fig. 8) .
|
|
Plugging a crop simulator into guics |
|---|
|
TOPABSTRACTINTRODUCTIONInterface usabilityPlugging a crop simulator...NOTESDesign evaluation and discussionREFERENCES |
|---|
To make an existing crop simulator capable of working with GUICS, three operations are required. First, the input files and the simulator output may need to be reorganized. Second, the structure of the input and output datasets must be documented. Third, some standard code must be added to the simulator to notify GUICS with an appropriate Windows message when the simulation ends. The GUICS User Manual (Acock et al., 1998) contains details of these operations, and only a brief description is given here.
Modifying and Documenting Input and Output
The objectives of these operations are (i) to arrange for the input and output file names to be read from a single file RUN.DAT and (ii) to produce a PROFILE file that will be used in GUICS to name and display the datasets. The sequence of operations is straightforward:
An example of the PROFILE file for the soybean crop simulator GLYCIM is shown in Table 2 . Names given to files should be short, because they are used in GUICS in window titles and in lists.
|
A typical GLYCIM soil hydrology file is shown in Fig. 9a . It begins with two text lines. This is followed by the number of horizons (three, in this case). The next three lines are inherited from previous versions and are kept to allow us to use the datasets with old versions of the model. A table containing 14 columns and three rows follows. The number of the rows is the same as the number of soil horizons. The variables in the columns are depth to base of soil horizon (cm), hydraulic diffusivity at -15 bar (-1.5 MPa) (m2 d-1), volumetric water content at -15 bar, slope of log (hydraulic diffusivity) vs. volumetric water content, saturated water content, volumetric water content at field capacity, volumetric water content of air-dry soil, bulk density (g cm-3), the exponent in the water retention curve equation, saturated hydraulic conductivity (cm d-1), water potential of air entry (bar), sand content (%), clay content (%), and an integer pointer (not used). The beginning of the script file for this soil hydrology dataset is shown in Fig. 9b. The description of each entry in the dataset occupies three lines: line 1, `@' followed by the entry number; line 2, the name of the entry; line 3, the datum type followed by datum format in parentheses. Note that the formats in the scripts are used to display data in the dataset spreadsheet editor and not to read data from the original data files. Soil files of other models have other parameters, and the script file will be different. As the script is produced, GUICS will handle those different files.
|
Bracketing a Crop Simulator
We have worked with simulators coded in C++ and Fortran dialects, although any other language can be used if the compiler produces a Windows application (i.e., a program that uses Windows resources via Windows API). We have used Microsoft C/C++ and Microsoft Fortran 90. Programs written in dialects of Fortran 77 were recompiled with Fortran 90. In general, it is not necessary to use Microsoft compilers to produce Windows applications; for example, GUICS can also run a simulator compiled using a Borland compiler.
A Fortran program must be transformed to become a subroutine without parameters. We supply a standard WinMain program that (i) provides an interface with Windows, (ii) starts the aforementioned subroutine, and (iii) sends a final message to GUICS and returns.
A program written in C to run under Windows needs only to be updated to include the final message. A program written in C to run under DOS needs changes analogous to those for a Fortran program. We do not supply a WinMain program for DOS-C simulators.
We also recommend that the simulator be modified to include sending the current date being simulated to GUICS for display.
Using Simulator-Specific Graphics
Graphics specific to a crop simulator can be incorporated in GUICS by transforming the simulator and the graphics into dynamic link libraries. This is reflected in the PROFILE file of the simulator, and by including the corresponding item in the `Options' drop-down list on the menu bar. Since graphics may not be needed for every run, the options include turning the graphics DLL on and off.
|
Design evaluation and discussion |
|---|
|
TOPABSTRACTINTRODUCTIONInterface usabilityPlugging a crop simulator...NOTESDesign evaluation and discussionREFERENCES |
|---|
To evaluate GUICS, we used the general guidelines of usability testing (Rubin, 1994) and conducted observational interviews (Martin and Eastman, 1996). Acceptance was of concern, because users often prefer a familiar interface to the one that is supposedly improved (Rudisill et al., 1996). In the interview, we (i) outlined the new features of the interface, (ii) demonstrated how to get warnings of stress effects on yields (as shown in Fig. 8), (iii) asked the user to go through the whole process of crop simulation by himself, and recorded all difficulties that he experienced, (iv) asked users to point out any inconveniences, and discussed with them the usability of GUICS, (v) asked whether the users would prefer to keep WINGLY or to get GUICS. We also asked about the need for mapping tools for input and output, and about the need for resources to be accessed through Internet.
Two of the growers were able to go through the process of crop simulation immediately after our demonstration. Wizards appeared to be a big help. The main difficulties in operating the GUICS prototype arose because we had not been consistent in implementing Windows shortcut conventions and in including error messages in the wizards. Two users found the icons confusing. Guidelines on naming datasets and scenarios and on writing memos were requested. None of the users saw an advantage in combining various scenarios into projects for on-farm use. One of the users indicated that the accumulation and collection of garbage data might become an issue as data manipulation becomes easier. An automated update of ascii weather files was requested. Tools to generate several predicted weather files were desired. The ability to have several crop models running under the same interface was welcomed. None of the users objected to replacing WINGLY by GUICS, provided they were given a converter to transform WINGLY data files to GUICS data files.
Discussion of the need for mapping tools revealed a variety of interests, mostly related to the familiarity of the users with precision farming technology. All users agreed that it would be convenient to use a mapping unit as the kernel of a project relating soil, weather, management, and cultivar data. Two users thought that the soil mapping units could be kernel units, whereas one user thought that a field might be the more appropriate unit. Three users had yield monitors and thought that crop simulation should be related to yield map analysis, and that the appropriate tools should be integrated into GUICS. One user pointed out that the accumulation of data eventually might make desirable a database that would support complex queries. None of the users was aware of Internet resources that could help them to use GUICS as a decision support tool, although all them expressed interest in information on such resources.
GUICS was amended as a result of these interviews, and the amended version was used on 15 farms in 1997 and 1998. The only problems that we encountered were errors in downloads of weather data leading to faulty weather files being used in simulations.
The GUICS version 1.7 and the GUICS User Manual (Acock et al., 1998) are available at the anonymous FTP site asrr.arsusda.gov from the directory /pub/guics1_7/. The contact person is the corresponding author of this paper. The code is written in C++ using Microsoft Foundation Classes. GUICS runs under Windows 95, Windows 98, and Windows NT 4.0. GUICS with the GLYCIM example requires about 4.5 Mb of hard drive space.
The main advantage of GUICS is that a farmer can use the same interface to run different crop simulators corresponding to the various crops in the farm operation. The farmer can access whatever level of detail is needed. GUICS proved to be easy to learn and easy to use.
|
ACKNOWLEDGMENTS |
|---|
|
NOTES |
|---|
|
TOPABSTRACTINTRODUCTIONInterface usabilityPlugging a crop simulator...NOTESDesign evaluation and discussionREFERENCES |
|---|
|
REFERENCES |
|---|
|
TOPABSTRACTINTRODUCTIONInterface usabilityPlugging a crop simulator...NOTESDesign evaluation and discussionREFERENCES |
|---|
This article has been cited by other articles:
|
|
 |
|
  L. Carlini, G. Bellocchi, and M. Donatelli A Library to Generate Synthetic Precipitation Data Agron. J., September 5, 2006; 98(5): 1312 - 1317. [Abstract] [Full Text] [PDF]
|
|
|
|
|
|
W. L. Bauerle, D. J. Timlin, Y. A. Pachepsky, and S. Anantharamu Adaptation of the Biological Simulation Model MAESTRA for Use in a Generic User Interface Agron. J., January 5, 2006; 98(1): 220 - 228. [Abstract] [Full Text] [PDF]
|
|
|
|
|
|
I. Ali, F. D. Whisler, J. Iqbal, J. N. Jenkins, and J. M. Mckinion Soil Physical Properties Web Database for GOSSYM and GLYCIM Crop Simulation Models Agron. J., November 1, 2004; 96(6): 1706 - 1710. [Abstract] [Full Text] [PDF]
|
|
|
|
|
|
X. Mi, Y. Zou, and W. Wei The Model-Document-View Architecture and Its Application in Visual Rice Growth Model Agron. J., November 1, 2003; 95(6): 1432 - 1441. [Abstract] [Full Text] [PDF]
|
|
|
|
|
|
J. C. Ascough II, D. L. Hoag, G. S. McMaster, and W. M. Frasier Computer Use and Satisfaction by Great Plains Producers: Ordered Logit Model Analysis Agron. J., November 1, 2002; 94(6): 1263 - 1269. [Abstract] [Full Text] [PDF]
|
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| HOME | HELP | FEEDBACK | SUBSCRIPTIONS | ARCHIVE | SEARCH | TABLE OF CONTENTS |
| The SCI Journals | Crop Science | Vadose Zone Journal | |||
| Journal of Natural Resources and Life Sciences Education |
Soil Science Society of America Journal | ||||
| Journal of Plant Registrations | Journal of Environmental Quality |
The Plant Genome | |||
