Click for next page ( 39

The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement

Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 38
APPENDIX B Specific Comments on the Interactive Radio-Epidemiological Program Most of the following comments deal with the potential for making improvements in the impressive start made by the design team. Sponsors will need to consider not onlY the nolicY. but also the budgetary, implications of these suggestions. ~ ~ .. , Some of the concerns of the subcommittee set forth here might reflect the design team's decision to implement the mode! in the proprietary modeling-spreadsheet program ANALYTICA, rather than coding it directly. We recognize that there are savings in development expense if one uses this type of environment. However, the savings often mean that the model developer has less flexibility in preparing the user interface. Accordingly, some of our suggestions, particularly regarding system appearance and convenience, could be too difficult or too expensive to implement. Ultimately, their value depends on the size and nature of the user base. As stated above, the information supplied by the developers indicates that the primary target audience is small and familiar with the underI-Ying logic of the system. However, careful consideration needs to be given to other potential audiences, particularly those for whom the process is not well understood but who have a substantial stake in the outcome. The developers clearly were aware of this design consideration, but the design as implemented is only partially successful in addressing the broader stakeholder community. In particular, key features of a system to meet stakeholder needs might be difficult to implement if only the "browser" version of ANALYTICA is available to users. C7 ~ a ~ O ~ , Some of the ensuing comments reflect the interim nature of the development system and will not necessarily apply to a final implementation. Installation Given that the installation appears to use Install Shield, it should be possible to install the Am tiles and the ANALY 11(:A browser module In a single operation. That would make the system a little easier for computer novices. ~ ~ ~ ~ ~ . ~ . ~ . ~ ~ ~ . ~ ~ ~ . . ~ The version of ANALYTICA that is used is a trial version. Is there a simple browser version that can be installed without requiring the user to face the registration screen? drive? The setup program runs fine off the CD. Why 38 is the user instructed to copy it to the hard

OCR for page 38
ANALYTICS Constraints It is mildly annoying that ANALYTICA does not appear to support the wheel mouse. Some buttons appear to work on a single click; others require a double click. It is not intuitive in advance which are which. Double-clicking on a single-click button drops the user into an empty (blank) window. The redrawing of windows has some problems. In addition, ANALYTICA sometimes opens windows In odd locations; some have to be dragged back to the screen center for closing. The discIav of scroll bars is somewhat insensitive to completeness of display: they imply that a window contains more than is shown, whereas all window content is visible. Many more objects are selectable than is desirable in a system that will support inexperienced users. For example, clicking practically anywhere in the screen calls up a definition. Ideally, one wants to control all the selections that a user can make. Similarly, many of the menu-bar and tool-bar choices are of little interest to the user, as opposed to the system designer. Can they be suppressed or activated selectively? The cursor is uninformative about what one can and cannot operate: some things look like jumps but do not go anywhere. IREP Choices in Implementation The use of an edit table for names and reference number is not particularly intuitive. Also, the system is not apparently creating any kind of index of multiple runs with these data. If these were only labels, an editable text box would give the user an easier job, more flexibility, and less concern. Year edits are inconvenient and counterintuitive. A count-up and count-down boxes would make the user's life easier. Hitting (the most intuitive keystroke after typing a value), rather than registering the user's choice instead adds a blank line to what should be a one- line field. Edit tables carry information from the previous case instead of zeroing out when starting a new case. By entering a male who was born in ~ 952 with diagnosis in 2000 and indicating five exposures, the system preselected 1955 as the first exposure. Also, edit tables are not closed by the clicking of the green check (an expected outcome for users of this icon). Again, the transposition options on edit tables are of uncertain value; they seem to add considerable visual complexity without addressing a user need. 39

OCR for page 38
Input Data Note the discussion of date issues under "Accessibility". year would eliminate a user entry. Working on age rather than Dose-input information might be the least user-friendly aspect of the system, particularly if distributional data are expected to be the norm. The user should not be asked to type in a distribution name and parameters, but rather at a minimum should be offered a drop list and count-up and count-down boxes for parameters. Also, it seems awkward to have to provide the doses and dates on separate tables, inasmuch as when the two would naturally be lined up together in a single table. Serious consideration needs to be given to both the numerical and physical forms of the data received by expected users. Will the people responsible for adjudicating compensation claims for radiation-related cancer have dose information that describes a particular distribution, or are they expected to infer one? Do the data come in on paper or electronically? Related to this problem is the absence of error checking on data entry. The user gets well into the analysis before the system crashes with bad data. 40