From wagner@weru.ksu.edu Wed Jul 23 09:08:58 1997

Comments on Joel's and my (Larry's) postings:

1) Joel shows an approach on how the necessary process information could be gathered from the user, as well as representing it in graphical form.

2) I showed what I view is the most logical conceptual view of how an operation should be described, as an ordered list of processes with shared process parameters not being repeated. There are a couple of reasons why I feel that this is the best way to represent an operation, at least as the data structure:

a) The concept is simple and flexible. It should be easy for users to grasp and understand what an operation is, ie. a simple ordered list of processes.

b) It is straightforward on how each of the models would handle an operation. They read in and perform each "process" in sequence. Thus, the code to handle operations in the models would be concise and uncomplicated. Keeping the operation interface code in the model clean and simple will make it much easier to add new processes or modify existing processes within the models themselves. We have experienced this benefit with WEPS already.

3) Joel packages things in a manner that appears to combine several processes together and presents them to the user as a single unit. This is not in itself necessarily bad as many of the processes are not independent of each other when they are grouped to represent an operation. This idea has the potential to "pull together" related process information into less screen area compared to addressing each process individually. If the related processes that are grouped have shared parameters, I can envision this approach handling my desire to "have the user enter shared parameter values only once". However, I find Joel's current implementation somewhat confusing to follow at this time.

4) After discussing the "assemblage of processes" with Larry Hagen, the following comments surfaced:

a) At least for us, and thus, probably many of our potential users, would prefer to "build" an operation by selecting processes, groups of processes, and possibly other operations (just another group of processes) from a list. Therefore, it would be similar to creating a management/crop rotation file where operations are selected for specified dates. The user would have the option of "drilling down" for each process selected to change the default parameter values or to access alternate methods of specifying those values (possibly graphical methods like what Joel has presented). The similarity between constructing operations and constructing management/crop rotation files should also benefit the user.

b) Larry Hagen envisioned experienced users building operations not wanting to bother with the graphical aspects once they "understood" the process parameter values.

c) Larry Hagen also raised the question concerning the number of users that would be "building" operations. For example, assuming NRCS would not allow field offices to create new operations, ie., they could only use the operations in a list developed at the State or other level by presumably better trained individuals. Then, would the graphical representations be beneficial enough to these "few" users to justify the implementation effort? My thoughts on Hagen's comment is that we have other users of MOSES that will benefit, however, it should be considered when we decide priorities on which features/capabilities are to be implemented first though (ie, good management/crop rotation editor or good operation builder component).

d) We saw Joel's graphical methods capable of producing process effects that could not be represented by typical mathematical relationships used in the current models. This would need to be addressed in any actual implementation.

5) The more I think about all of this, the more I envision a method of building operations in a manner similar to building management/crop rotation sequences. As mentioned in 4a above, the user would be able to "drill down" to access different methods or levels of detail pertaining to a single process or group of processes (likely employing some of the ideas and concepts that Joel has presented). There may be more than one "view" that the elements (processes) of the operation can be seen in. Obviously, a "list" view would be one in which the processes making up an operation are shown in sequence. Another is a "notebook" view that could deal more easily with groups of processes being presented together, as well as shared parameters, yet still reveal the order of the processes to the user. There could conceivably be other "views" as well that the user could select from, depending on whether he was building a new operation, modifying an existing one, or only tuning selected process parameter values. The "views" could possibly group or package the elements of an operation in other ways that benefited the user, but the underlying data structure would remain a simple ordered list of individual processes.