Provide enough information in a technical document to allow your reader to understand the specific problem being addressed and to provide a context for your own document. This background information may include (1) a historical summary of the problem being addressed; (2) a brief summary of previous work on the topic, including, if appropriate, relevant theory; and (3) the specific reasons the document is being written.
In short documents, include background information in the introduction. In longer documents, however, putting some or all of the background information in a separate section with a heading may be more effective. Long and fairly complex reports, especially experimental reports where the purpose of the document is to verify, evaluate, illustrate, or apply one or more theories, often include a separate theory section.
1.1 Historical PerspectiveHistorically, the issue of modes in human computer interaction emerged as more and more functions were added to early word processors, and yet the size of the interface (e.g., number of function keys, screen area, etc.) stayed constant. One solution was to use the same key to engage several commands; this was implemented by providing the user with some mechanism to switch the application from one mode to another. Depending on the mode, hitting the same key would execute different commands. In this paper the term format/data-entry modes is used to describe this type of mode implementation. For example, the vi text editor has two modes of operation: "Command" and "Insert." In "Command" mode, pressing the "x" key will delete a character; in "Insert" mode this action will write the letter "x" on the screen.
Users of these early applications, however, were not always happy with such mode implementations: errors, or mode-errors, as these were termed by Norman (1981), caused confusion and frustration (Lewis, and Norman, 1983). Tesler (1981) captured this growing frustration in his influential article in Byte magazine and his pointed cry: "don't mode me in." Research on modes in the human computer interaction literature has mostly focused on various implementations for the mode switching mechanism (Monk, 1986; Thimbleby, 1982). The problem, nevertheless, has not disappeared: designing efficient modes and switching mechanisms continues to be part of any human-computer interface.
The same growing pains are now shared by designers and operators of supervisory control systems. Since most supervisory control systems are managed via a computer, format/data-entry modes for input of information and display switching are heavily used. But in most supervisory control systems there is also another type of mode: one that is used for controlling the process. This unique mode is the method used for engaging various control behaviors (e.g., reverse/drive gears in a car). In this paper, the term control modes is used to describe this type of implementation.
--A. Degani et al., "Mode Usage in Automated Cockpits: Some Initial Observations," Proceedings of the International Federation for Automatic Control (IFAC)