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).