| Food Composition Data: A User's Perspective (1987) |
|Systems considerations in the design of INFOODS|
The user interface for a system includes not only how users will communicate with the system, but also how the system will communicate with users in normal and error situations and how output will be formated and presented. There are many opinions about each of these issues, and none is completely correct for all audiences. Every user interface decision is problematic. This paper cannot hope to provide a complete discussion of the issues; the examples that follow are intended to convey the flavour and difficulty of the challenge.
If a single user-level language is chosen and imbedded in the system, the choice must be correct for all present and future audiences. Interfaces that adapt automatically to the characteristics of individual users and their growing knowledge of the system are a major research area today. Where such adaptation is possible, it complicates documentation both for the users themselves and for those who are expected to understand the processing and analysis activities of others. If one can design language for the system around the particular needs of the users to be served, be they the builders of food tables, epidemiologists, or hospital dieticians, much convenience may be gained for the users, and their learning and use of the system may be expedited. At the same time, such language design may require a great deal of learning on the part of users with other backgrounds or interests.
If the needs of several different types of users are to be supported, the system will end up with multiple languages and interfaces and all of the inconsistency and unpredictability to which that leads. Since large, diverse systems attract people with diverse needs and backgrounds, there are no easy solutions - but this may be another argument for not building such systems at all.
One popular solution, at least hypothetically, is to try to use a natural language, such as English, as the means of instructing the system. With advances in the technology in the last few years, this is probably a feasible option, although it entails considerable difficulty in design and implementation. More significant difficulties lie with the degree to which natural languages lack compactness of form and absolute clarity, which is why mathematical and other symbolic notation is used in statistical work. One of the greatest difficulties in using natural languages is getting people to understand them unambiguously.
All of the preceding comments on the user interface apply to picture languages, pointing languages, and even shouting-at-the-computer languages just as much as they apply to typed commands. One can either optimize for a particular group of users and leave everyone else somewhat inconvenienced and unhappy, or one can try to find compromises somewhere.
The actual mode of communication between user and system is almost a separate issue from that of the language used in the communication process, although some choices in this area can constrain, or remove constraints from, language choices. User oriented menus, help systems, command completion systems, and question-answering are good choices for raw beginners; it has been argued elsewhere  that they have a tendency to grow pathological for regular and experienced users. Many of the most interesting and sophisticated of the less traditional approaches to human-computer interfaces rely on specialized hardware which may prevent their application in many specific implementations.
One useful alternative to a single, firm, choice of interface is to design "agent" facilities so that the system can easily support programs - both system- and user provided - that run other programs on behalf of the user. Agents may be useful for supporting alternative command formats and presentations, default arrangements, and a choice of interfaces such as menus or question-asking. They are also a convenient framework for system extension facilities for use by the relatively casual user ; and they appear to be well-suited for building expert or assistant ones. By contrast, while they can be used to provide conversational or menu-driven environments, or those that require screen inputs, they tend not to work well, or at least to be difficult to support, when the underlying environment has any of those characteristics. These drawbacks impose some major constraints on system organization.
The difficulties and choices found in user communication with the system are paralleled in system communication with the user and with output presentation. The design of all formats around a 24 x 80 character display can be a severe limitation, especially for plots and graphics. Worse yet, in this day of stress on interaction, is the design of output for the line printer, with its headers and footers and its long and wide pages at low resolution. At the same time, there are still many analysts who prefer working with piles of paper to sitting at terminals; articles and food tables will probably be published and used on paper for a long time to come. Designs that depend on high-resolution graphics devices will exclude many users who will be unable to pay the price of entry to the system. Almost any solution will either make some class of potential users very unhappy or will limit the groups and types of users who can be served. This makes it very important to make decisions early and with an understanding of whose happiness is being considered and whose is being sacrificed.