Russell Heywood
January 21, 1998

Introduction to the Passive Response Interaction Style

The significant characteristics of passive response interfaces are not currently widely supported by UI toolkits, but it is likely that the increasing computational power of personal computers will cause this type of interface to soon become more common. Interfaces which passively respond to users do not directly accept user input in any form. Instead, they observe the interactions of the user with the primary interface and then, based on some set of heuristics, they perform some operations. The intent of these operations is to anticipate work that the user may soon have to do and automate it, thus improving the efficiency of the application for the user. The hope, of course, is that the operations performed do actually assist rather than confuse and frustrate the user.

This interaction style has several unique features that, depending on the development tools used, may make it somewhat tricky or time consuming to implement. First, a successful implementation must efficiently examine the behavior of the user. This means that the implementation must contain some code and data structures which record and make decisions about user behavior without degrading performance excessively. Also, the interface should graciously defer to the user’s judgement when making decisions. This means that the user should (a) notice when the system has made an automated decision, but (b) not be unduly distracted by the notification, and (c) be able to efficiently reverse the automated decision if it turned out to be incorrect. Finally, the interface’s decision-making heuristics should be adaptive rather than fixed. For example, if the user must frequently reverse the decisions of the passive response system, then the system should become more conservative so as not to annoy the user.

Passive Response Benchmark: A Text Editor with Automated Error Correction

This benchmark implementation will be a simple text-only word processor that performs automatic error corrections adaptively, somewhat similar to the way that late versions of Microsoft Word attempt to "auto-correct" and "auto-format" text as it is typed. Any mistakes that the user makes frequently should be "noticed" by the interface and corrected.

Such a program would be a good benchmark for this sort of interaction style because a successful implementation must contain some of the most complex elements of passive response. First, data structures must exist which organize and store relatively large amounts of user behavior information (mistake-correction pairs); poor data structures would yield either low efficiency improvement or costly performance degradation. Second, some operations must be performed without any specific command from the user (the automatic correction mistakes), so any implementation must consider the complications involved with performing tasks concurrently with the user's input. Finally, the grace with which the implementation handles the consequences of an incorrect passive response will become immediately evident. That is, if the interface makes too many errors or if they are too difficult to notice or correct, the interface will be totally unusable because the user's work will be either incredibly slow or hopelessly corrupted.

This benchmark does not elucidate some issues that may be important in more complex interfaces: how should the adaptive system recognize and cope with multiple users? What sort and how much information about the user should be stored from instance to instance? Certainly it might be beneficial to save some knowledge of the user for later so that the interface does not have to re-learn the characteristics of the user each time, but how reasonable is it to dump that information onto permanent storage? Also, this interface may slightly degrade performance if it makes a number of mistakes, but one could imagine a PRS that causes much more serious errors. For example, suppose a data entry system attempts to improve user performance by anticipating needed entry forms and producing them ahead of time in some arrangement on the screen. Since data entry forms often look almost the same, and the PRS will tend to behave inconsistently (i.e. it will not always be totally clear to the user what the interface is likely to do next) the user might wind up unwittingly entering data into the wrong form because she intended to do something other than what the PRS anticipated. In this sort of case, the user will at best waste time correcting the error she made, but could wind up unknowingly committing false data to a database (which has incalculable consequences.)

Benchmark Specification:

Primary Interface:

The following are requirements of the completed implementation of the benchmark program's primary interface (the text editor):

Passive Response System:

First, some definitiions:
- The user finishes the word that contains the current cursor position when he types a space, tab, carriage return, or uses the navigation commands to move the current text entry point away from the word.
- An error is characterized as a word that the user finishes and then later navigates back to, changing it either using a select-replace action or backspacing out some or all of the characters of the word and replacing them with other characters.  An error is not the complete deletion of a word, nor is it the backspacing of characters in the currently forming word.  The reason for this is that even though users may sometimes correct their own errors before typing a space to go on to the next word, they may sometimes type so little of the word that it becomes nonsensical to try to automate the correction of those errors.
- The system corrects the user when it replaces an error word that the user has typed with one that the system believes is the appropriate correction of that error.
- The user reverses the system's correction when he replaces a corrected word with the original error word.  If the user replaces a corrected word with some word that is different than the original error word, this should not be considered a reversal.
- The system's aggressiveness is a coefficient that the user can change as part of the environment of the program.  When aggressiveness is high, the system is very likely to make corrections for the user, even if the user reversed one or more of the system's corrections before.  When aggressiveness is low, the system is less likely to make corrections on behalf of the user if the user has reversed the system's correction.
- An error-correction pair's replacement probability number is an integer that represents how likely it should be that, the next time the user makes that error, the system corrects that error.  The RPN is given by reversals - error frequency.

The PRS should, then, have the following characteristics and behaviors: