Ian Rogers
Knowledge-driven editors can improve productivity by taking care of the
low-level details of a design artifact, and by guiding the user through an
interaction. Despite this, editors that dictate their knowledge too strongly
can actually reduce usability by forbidding a sequence of interactions that
the user has planned - a sequence that may be the most natural to the user.
This paper introduces the use of an automatically managed
"To Do" list as the primary method for the knowledge agent
to communicate to the user. The "To Do" list guides the user
to a correctly constructed design artifact, without overly
constraining the user.
Syntax-directed editors, such as some programming tools,
and graphical, network editors, have the desirable effect of
ensuring that the manipulated artifact is at least syntactically
correct. For example, they ensure that a piece of program
code contains no spurious or missing text items, or that an
architectural drawing has doors placed in the walls instead
of in the middle of rooms.
Although the tool may have syntactic, superficial knowledge of the domain,
it's unlikely to have much semantic, deep knowledge - the tool would have to
be at least as intelligent as the user to have complete domain knowledge. This
means that the user is likely, at some stage, to produce a design artifact
that contains semantic errors even though the editor has accepted it as
correct.
For the purposes of this paper we can ignore how semantic
errors are recognised, and just assume that an expert user is
able to spot an error that they've made. For example, the
designer may simply be reconsidering an earlier, hastily
made, opportunistic decision. This is a normal part of expert
designer's behaviour [2, 5].
Making changes to partial designs is an area where syntax and semantics
directed editors suddenly become very weak. Although the designer may know
exactly what changes are required, the process of making the necessary
corrections to the design may take the design artifact through an intermediate
stage that is forbidden by the editor. This sort of "change reluctance" or
"viscosity" is well known [1].
For example, consider an architectural design tool that
"knows" that all rooms should have a door. The designer
may have decided to move a door from one wall to another
and, out of habit or choice, wants to delete the original door
before replacing it in its new location. The editor will forbid
this, and the designer may well find it difficult to discover a
sequence of operations the editor will allow.
Constraint-based editors can alleviate this problem [3], and
this simple example may have obvious solutions, but, in
general, an editor that enforces built in rules too strictly may
lock the user into premature design decisions simply
because it's too difficult to change.
The tool is intended to support rapid prototyping, particularly when a sales
representative is prompting specifications and requirements from a customer.
To this end, syntax directed editors are used for some views so that the user
doesn't have to waste time manipulating the diagram's layout. The tool also
contains a "coherency checking" module that can check certain parts of a
design for functional correctness, and can also raise issues about the design
that it thinks the designer hasn't addressed.
If the CORECT tool used a traditional knowledge driven editor, the user would
be constantly interrupted with dialogue boxes pointing out errors in the
design, or even being forbidden from making certain changes! This would
seriously disrupt the user's chain of thought.
To avoid this, the CORECT tool supports an automatically managed agenda, or
"To Do" list. The editors allow any change to be made that the user desires.
If this change introduces new errors, a short description of the error is
added to the agenda. The agenda item also includes a long description and a
list of design objects the error effects. If the user selects a particular
agenda item for viewing, the long description is displayed in the agenda
window, and any effected items are highlighted in all visible views. The long
description may include some hints to guide the designer's next operation, and
highlighting design objects may scroll them to a visible part of the view
pane, orienting the designer to the correct area of the user interface.
Figure 1:
This technique allows the user to rapidly enter designs into
the tool without hindrance from the "helpful" knowledge
agent. This is particularly true when the user is making a
planned change that takes the design through intermediate
stages containing errors.
Some other uses for the agenda manager include automatically fixing errors it
knows how to fix when instructed to do so by the user. Also, if there is an
agenda item stating that more information is required about a particular part
of the design, the agenda manager could highlight the correct dialogue box for
entering that data.
This problem can be reduced by relaxing the control the editor has over the
interaction, and replacing this control with an automatically managed "To Do"
list. The "To Do" list acts as an aide-memoire to ensure that a designer
always completes any sequence of changes made to a design artifact.
Abstract
Introduction
"To Do" LISTS IN THE CORECT TOOL
The CORECT (Collaborative Requirements Capture Tool) project is building a
tool which needs to address this problem. The domain is complex electronic
systems design, and all users of the tool are experts in the field. The tool
will support all stages of the sales and design process, from initial contact
with the customer through to complete system specification and verification.
The tool presents a number of views onto a common design artifact. These views
are intended to be used by all members of a design team in order to aid the
communication of ideas and decisions [4].
Conclusion
In this paper I hope to have shown that although knowledge driven editors have
their benefits, they can also hinder usability by over-constraining the user
to a particular sequence of actions.
ACKNOWLEDGEMENTS
This research is supported by SERC grant No. GR/J53461
and DTI grant no. IED4/1/7025. The Partners on the
CORECT project are Racal, Intelligent Applications Ltd.,
Edinburgh University and University of Sussex.
