@b(3 USER INTERFACE PRINCIPLES)

This section attempts to outline the unifying principles to be used in designing the 
user or man/machine interfaces to Pilot tools.  By consistent application
of these principles in all parts of Pilot, it is hoped that users will find
the penalty of learning to manipulate Pilot objects as small as possible.

All designs for user interfaces to SIMMER tools must attempt to follow the
principles outlined here.  Deviations must be noted explicitly  and justified
to the S.A.G. and T.R.B.

@b(3.1 Influences)

No new concepts have consciously been introduced in this document.  An amalgam
of ideas has been made, borrowing and modifying as appropriate.  In particular
the following systems were influential.

      1. The Jade window management system

      2. The ICL Perq window management system

      3.  The Apple Macintosh

      4.  The SERC Spy editor


@b(3.2  Mode of working)

There follows a list of concepts underlying the mechanism outlined in 
Section 3.3.


@B(3.2.1  Workstations)

Pilot is intended to allow work to be carried out in a @i(user driven) way.  This
conflicts with traditional operating system demands, especially in that a user
at an interactive workstation may not wish to finish his current task before
initiating a new one.  Indeed, it is often easiest to initiate several 
subsidiary tasks on the way to completing a primary task.  As some tasks
may require significant processing by the machine between interactions with
the user, it is also often desirable to initiate more than one subtask in
parallel, giving attention to them only as necessary.

This definition of task and sub-task is, of course, recursive to an abitrary
depth.

UNIX allows sub-tasks to be initiated as new son/daughter processes.  
Workstations have combined this with multiple windowing, opening a new 
window for every process requiring user attention.  By entering its 
window, a user may interact with any currently existent task (or sub-task).
The only limit to this is the processing power and memory size of the 
workstation.

Pilot will use multiple windows, with overlapping and pushing and popping
of stacked windows to allow maximum parallelism of tasks.  Section 3.3 
expands this idea.


@B(3.2.2  Non-keyboard interaction)

Most interactive systems, prior to workstations, assumed that a keyboard
had replaced the batch cardreader and a glass teletype the lineprinter.  
Workstations typically allow alternative input devices, especially
pointing devices, and graphical, rather that textual, output devices.
Pilot will use mouse type pointing combined with menus and button clicking
to speed up interaction.  The keyboard will only be used for entering 
textual information.  All members of Pilot design teams should make the
effort to familiarise themselves with such a system.  It is not enough
to read about these ideas, use of facilities embodying them radically alters
one's whole view of what is desirable.


@b(3.2.3 Selection and pointing)

Pointing involves using mouse or other pointing device movements to position
a cursor on the workstation screen. This cursor may move from window to window
as well as within windows and is part of the window management support.

Once the cursor is positioned (pointed) at a relevant area of the screen, this
area may be indicated as the currently selected one by clicking a button. A
@i(click) involves depressing and releasing the button.

Where two areas, usually defined by symbols or boxes, are to be linked the
button may be depressed while pointing at the first and released after moving to point to the second.
This would be used when drawing lines, for example.

Similarly, when a symbol is to be moved, it will be pointed to and a button depressed.
Keeping the button depressed the cursor will be moved to point at a new location.
The button will now be released to deposit the symbol at the current location.
It is important that the symbol @i(tracks) the cursor so that its exact final position
is known before the button is released.

@b(3.2.4 Desktop metaphor)

The interfaces will use a desktop metaphor, in some ways like those in the Apple
Macintosh. This will view the world within a tool's window as a work space on
which are placed objects, represented by graphical symbols. Tools and pieces of
work will both be represented by such symbols. By selecting a symbol the user
may either invoke a tool without specifying an object to be manipulated by it
or may specify an object which already exists and which he wishes to open for
further manipulation by its creating tool.


@b(3.3  Mechanisms)


@B(3.3.1  Icons and Menus)

Within Pilot, as a consequence of 3.2.3, above, much use will be made of
@i(menus) and @i(icons).  There is a general meaning attached to each of these,
but the best way of representing them is an open question.  One of the purposes
of Pilot is to experiment ways of presenting and soliciting information.

Essentially, a menu is a set of alternatives, from which the user may select
by pointing and button clicking.  This does not constrain designers to
vertical lists.

An icon is a graphical symbol. One of its uses will be to
define an area on the screen which can be pointed to in order to select
from a set of alternatives.
Icons will also be used as symbols within graphical representations, such as activity
diagrams in the process interaction tool.


@B(3.3.2 Forms)

@i(Forms) are an extension of the menu concept.  They 
represent sets of attributes associated with objects and actions.  By pointing
and selecting within a form a user may manipulate its attributes one at a time, potentially in any
meaningful order.

Note that the system imposes only such control as is essential to preserve
meaning.  Form filling is user structured, not system driven in Pilot.


@B(3.3.3  Window creation)

Wherever a selection from a form implies the start of an interactive
sub-task, a new window will be generated automatically.

The position and size of the window will be set by the new task
to appropriate defaults, but the user will be able to move and scale it as 
appropriate.  The ability for windows to overlie one another is clearly 
important, to avoid filling the screen too quickly or having to use@
inappropriately small windows.


@B(3.3.4  Window interactions)

Some tasks produce values for use by others.  UNIX introduced the pipe as a
mechanism for dynamically associating the output of one process with the
input of another.  Regardless of whether pipes are used to implement them,
Pilot will provide two user facilities for this purpose, allowing values
generated in one window to be used in another.

Interactive use requires the ability to select a value from one window, by
pointing, and to place it as a new value in another.  The possibility also
exists that type or precision may need to be changed automatically when
appropriate.

Where two tasks are to cooperate without further user interaction, a 
permanent association between any output of one and any input of another
must be possible.  Again, some appropriate conversion may be needed.
If possible this will be specified by pointing and selecting.


@B(3.3.5  Graphical construction)

Pilot will support graphical construction by dragging of symbols from
menus and joining with "rubber band" lines.  This will enable large amounts
of information to be input purely graphically, wherever suitable symbols can be defined.

Underlying this will be a mechanism which allows particular tools to attach
their own manings to graphical symbols.  This mechanism will also allow
the links between symbols to be expressed.  In this way the structure of 
graphical representation will be able to express logical relationships 
between symbols, with an applications defined significance.


@B(3.3.6  Value setting)

A number of mechanisms will be used in Pilot to allow users to enter values
into forms.  They will seek to minimise the use of the keyboard.  They
will include the  following.

Where a known set of discrete alternatives exist, a menu of these could be
offered for selection.  This is rather like the Macintosh "station selection"
buttons in its radio analogy for dialogues.

Where a continuous integer range with known bounds is involved a 
"slide potentiometer" approach could be used.  This is like the Spy editor's
mechanism for moving rapidly to an approximate location in a file.  In
the latter a long bar is used to represent the file's length.  By pointing
at the appropriate distance along the bar the current editing position 
within the file is varied.  An associated display gives the exact line number.

As implied by 3.3.1 a sub-task may be needed to generate a value.  Where this 
is the case appropriate mechanisms will exist to return it.

Binary values could be set by a toggle switch, thrown by pointing and clicking.

Where no other mechanism is appropriate, values will be entered or edited
textually.  It is important to be able to edit an existing textual value, as as
well as enter a new one.
@n()

@B(3.3.7  Help)

One button on the mouse (or its equivalent) will be the select button.  A
second will be the help button.  Thus wherever a selection is to be made, the
user can first obtain help concerning each selection.  In Pilot help will 
consist of a simple text.

@b(3.3.8 Alerts)

A specialised form will be used when the system wishes to report an inconsistent
action by the user or to query an apparently dangerous selection, such as deleting
all objects in a folder. These will be known as @i(alerts). They will invite the user
to take some corrective action or to confirm a possibly dangerous selection,
in accordance with the text from the system contained in the form. Until the
user replies to an alert all actions in that window are blocked.
@n()