Usability Issues

Much work in the field of Computer Supported Collaborative Working
(CSCW) has started from a detailed set of usability requirements,
and attempted to engineer a system to support these requirements. In
single user systems, this works well, but for near-synchronous shared
tools, there is a real danger that this result in systems that do not
perform well in real-world networks.

We have started with a high-level set of usage and performance
requirements, and worked through a solution that satisfies these
high-level requirements. Such a solution imposes a tight set of
constraints on the operations that can be performed on the data set.
In designing wb, it appears that Van Jacobson also pursued this design
path, although as the high-level requirements were slightly different,
their resulting constraint set is different. There is, of course, a
danger that in pursuing this type of path, the resultant system
performs well but does not properly support any required task. It is
dangerous to attempt to draw general conclusions from a small number of
examples, but we believe that both nte and wb have resulted in systems
that support the users' tasks well. Furthermore, we believe that
engineering a CSCW tool around a set of constraints that ensure good
performance is likely to result in a tool that is more likely to be
used.

Having said this, it is vital that detailed usability requirements are
given a great deal of attention when working within our
constraint set. The detailed requirements we used to design nte
include:

Nt should be as simple as possible to
use. It is not a word processor, as is not intended for single user
usage.

It should always be possible to tell who is in the
conference.

It should always be obvious who is performing any
change at any time.

WYSIWIS (What You See Is What I See) is
not a requirement. Different users should be able to edit different
parts of the document simultaneously, even if these parts are separated
by several screens of text.

The primary user operations are:

Block creation

Text addition

Text
deletion

Block deletion

Block moving

Cut, Copy and
Paste of text

Search and replace within a block

Setting the
font and colour of a block for identification purposes.

Using a
Shared Pointer

Loading text from a file

Saving text to a
file

We expect that no other user operations on the
text need to be supported as they are unnecessary and increase the
complexity of the user interface. Other operations should be added
only where they aid the above operations.

It should be possible
to prevent other users from editing a particular block of text - a kind
of ``annotation only'' mode.

It should be possible to save the
resulting text as either ASCII text or as structured text maintaining
the block structure.

It should be possible to save selected
blocks only.

There is little point in discussing all of
these detailed design decisions here, as most of them are
uninteresting. However, a few are worthy of mention, as they were not
obvious (at least to the author).