Next / Previous / Contents / Shipman's homepage

6. Input file format

6.1. Input design considerations

The general approach to banding data entry is the venerable batch model from the early history of computing. The operator prepares a text file and runs it through a data compiler program that checks the data for validity as much as possible. If there are any errors, the input file is corrected and then re-run through the compiler. The compiler translates the data to the flat-file format required by IBP.

A special-purpose electronic form for entering banding data may seem like a good idea, but the author prefers to use a regular text editor, emacs, for bulk data entry. Special-purpose forms are hard to build and maintain. Furthermore, the search and replace functions of a good text editor can make life easier when it is time to fix errors.

The author's preference is to stick to fixed-field input where the input has a fixed-field format. However, his feeling is that a mixture of free-field and fixed-field techniques can be better than either pure approach.

In this particular case, there are several fields at the end of the encounter line that are not always used: disposition, note number, feather-pulled, cloacal swab, and color bands. This suggests a mixed format, using fixed-size fields for all the fields up to the net field, with free-form fields added after that for the less-common items.

Because of the large volume of data and the limited time available to enter it, efficiency is a critical consideration. The first step to improving data rate is to minimize the number of keystrokes. However, “think time” is important, too. Some input situations can make the data entry operator stop and think. Minimizing those situations is the second step in performance tuning. The goal is to stay close to the maximum keying rate.