Negotiating User-Initiated
Cancellation and Interruption Requests
Manuel A. Pérez-Quiñones
Human-Computer Interaction Laboratory
Naval Research Laboratory, Code 5512
Washington, DC 20375-5337
perez@aic.nrl.navy.mil
+1-202-767-9003
John L. Sibert
Department of EE and CS
The George Washington University
Washington, DC 20052
sibert@seas.gwu.edu
+1-202-994-4953
ABSTRACT
Interruptions and cancellations are important parts of a user
interface, yet they are treated as special cases in user interface design and
notations. In an effort to build a dialogue
notation that allows for effective definition of these commands or user turns, we
present a behavioral definition of
interruptions and cancellations. We show several examples
of how our definition accounts for different forms of behavior. The behavioral
definitions provided here are a step
towards providing better support for the definition and
implementation of these turns.
Keywords
Cancellations, interruptions, human-computer dialogues.
INTRODUCTION
A desirable property of all human-computer dialogues is to
put the user in complete control of the dialogue flow. To
achieve this goal, the user must be able to interrupt the system at any time and
be able to request a cancellation of any
dialogue. We assume a synchronous dialogue between the
user and the computer with each taking alternate turns, much
as in human conversations. If interruptions and cancellations
are allowed, the system response must be consistent with
how humans deal with interruptions and cancellation in
human conversations. These are rarely accepted without
some form of negotiation between the participants. This
negotiation helps the participants ground the conversation
[1] and allows them to consider the possible implications.
Not all interruptions and cancellations need to be negotiated.
Some may be accepted without any negotiation because the
possible "damage" done is minimal.
Cancellation requests, also referred to as the abort command,
are difficult to define using dialogue notations and difficult to
implement [3]. One reason for this is the poor understanding
of what should happen, from a behavioral point of view,
when users request cancellations. Also, the representation of
these commands in dialogue notations is usually done as an
afterthought. As a result, a complete definition of the abort
semantics would make a "complete mess of the hierarchical
structure of the dialogue description" [2] page 263. The
notations are usually extended with global states, or special
transitions to handle cancel requests. In addition, they provide no guidance or
suggestions on what would be the appropriate way to implement these user turns.
In this paper we present a behavioral definition of interruptions and
cancellations. This definition is based on a behavioral description of how humans
negotiate interruptions and
cancellations. A dialogue model [4] is being developed that
considers the behavioral as well as the constructional issues
related with the definition and implementation of interruptions and
cancellations.
BEHAVIORAL DEFINITIONS
Cancellation Requests
A cancellation occurs when the user decides not to continue
the current exchange and terminates the dialogue. A cancellation request can
occur only at a user's turn. But more
importantly, it could occur at any user's turn (1). It is a request
to terminate the dialogue in which the request is made. The
system, as a response to the user request, has three options:
(a) accept the request and terminate the dialogue, (b) reject
the request and leave the dialogue unaffected, or (c) initiate a
negotiation with the user on the consequences of accepting
or rejecting the request. Furthermore, the results of the negotiation can only
be: either a user acceptance of the consequences of the cancellation and thus a
system acceptance of
the request, or a user refusal of the consequences and thus a
system rejection of the request. Figure 1 shows all the possible paths taken
based on this definition.

Figure 1. Cancellation Request Semantics
The second user's turn state, labelled with an asterisk (*) in
the figure, is a special state where the user's actions are limited to acceptance
or rejection of the negotiation. This
restriction prevents recursive definitions of cancellations,
where each cancellation leads to negotiation over another
cancellation (i.e. cancellation of a cancellation of a cancellationÉ). A
cancellation request can only be voided by following the reject path out of the
user's negotiation state.
Interruption Requests
An interruption occurs when the user desires to take a turn in
the interaction while the system is in the middle of one of its
turns. For the user to take a turn at this point, he/she must
request an interruption first. This results in an asynchronous
event which must be handled by the system (2). The possible
outcomes of an interruption request are: (a) the system
ignores the request, or (b) the system accepts the interruption request and thus
the dialogue is interrupted. If the
request is accepted, a negotiation with the user will determine when to resume
the interrupted dialogue. Figure 2
shows the possible paths taken in an interruption request
based on this definition.

Figure 2. Interruption Semantics (partial)
Combination of Interruptions and Cancellations
Interruptions, as defined above, have very limited usefulness. But when combined
with cancellations, all the power
of interruptions is realized. Because a cancellation request is
a user-initiated turn that can occur at any user's turn, a cancellation request
can occur at the user's turn in the interrupted state of a user-initiated
interruption. A combined
diagram can be obtained by superimposing the initial user
state of Figure 1 with the user's turn in the interrupted state
of Figure 2. The resulting diagram, shown in Figure 3, contains the complete
definition of an interruption request.

Figure 3. Interruption Semantics (full)
Examples
A quick study of interruptions and cancellations in humancomputer interfaces
reveals many different behaviors. In
this section, we briefly describe some examples using the
semantics presented here.
On Unix systems, Control-C and Control-Z are used to
interrupt processes. Control-C is an interruption followed
by an implicit cancellation. Its behavior is specified as an
interruption request, which is followed by an automatic cancellation request that
is accepted by default. Control-Z, on
the other hand, is just an interruption request that is automatically accepted.
The process is left interrupted until the
commands fg (foreground) or bg (background) resume the
process. A process cancellation request can be issued with
the kill command, which is accepted without a negotiation.
On the Macintosh, a Command-. (period) while the computer is printing, is defined
identically to a Control-C in
Unix; the print job is terminated. A Cancel button in a dialogue box is defined
as a cancellation-request that is, in
most cases, automatically accepted.
Other systems provide the full behavior of the interruption
request. For example, interrupting an ftp download in
Netscape is defined as an interruption request with a negotiation (Are you sure
you want to abort the download?) over a
cancellation request. Accepting the consequences of the
cancellation terminates the download; rejecting the consequences automatically
resumes the interrupted download.
Use of Behavioral Definitions
The definitions presented work as templates for each
instance of the handling of these user turns. Definition of
new handlers require identifying which system transitions
will be taken automatically and which will be done as a
result of negotiation with the user. The examples above contain some transitions
that were taken without user negotiation (e.g. cancellation request in
Control-C). A second step
is to determine which (if any,) user actions are to be collapsed into one. In the
Netscape example, the user's interruption is also a cancellation request.
Therefore, two
transitions (interruption-accepted and cancellation-request)
are made based on a single user action.
REFERENCES
- Clark, H.H. and Brennan, S.E., Grounding in Communication, in Shared
Cognition: Thinking as Social Practice, J. Levine, L.B. Resnick, and S.D.
Behrend, Editor. 1991, APA Books: Washington, D. C.
- Dix, A., et al. Human-Computer Interaction. Prentice-Hall, 1993.
- Myers, B., ed. Languages for Developing User Interfaces. 1992, Jones
and Bartlett Publishers: Boston, MA.
- Pérez, M.A. Conversational Dialogue in Graphical User Interfaces:
Interaction Technique Feedback and Dialogue Structure, in Proceedings
Companion of the ACM CHI'95 Conference on Human Factors in Computing Systems,
(Denver, Colorado, 1995), Addison-Wesley, pp. 71-72.
End Notes
(1) We are only concerned with user-initiated requests.
(2) The event is asynchronous because it is generated by the
user during the system's turn.