Details of the Simulated Interface

The simulated interface was developed to support the comparison of the use of two syntax structures over more than one style of input, keeping other factors, which might influence syntax usage, under control.

4.1 Requirements for the Interface

On the basis of the above, the general requirements for the experimental interface were determined. These are that:

i) the versions generated from the interface should vary only with respect to their syntax and input technique.

ii) the mode of representation of the entities should be constant: also it was thought best to restrict representation to a textual representation (rather then an iconic one). As

was also an exercise in investigating the notion of object-orientedness outside of the context of graphical a n d /o r Direct Manipulation interfaces.

iii) The ratio between the number of actions which are paired w ith the objects (and vice versa) in the system should be held constant.

Overall the variations to be compared should have the same TOTAL number of actions and objects and the pairings should yield identical numbers of options per object (or action). E.g.

Total number of objects = 4 {A, B, C, D} Total number of actions = 4 {1,2,3,4} Number of options per object (or action) = 3

OBJECT VERSION ACTION VERSION

B 2 3 4 B D A D D B C

This organisation contrasts with the situation that often occurs with extant systems where different objects may have different numbers of actions associated with them - a document may be associated with six or more actions; some of which may be unique to documents (e.g. Proofread) whereas a clock may only have one or two actions associated with it. The result is unequal option sets between the two versions (e.g. 6 :1 becomes 1:6). Number of options is a potential confounding factor because the preferred syntax might be correlated with the most (or least) frequent option type.

WLUL/tW A

4.2 Description of the Simulation

As described in Chapter 5, the simulated interface was written in HyperTalk, the

development language of HyperCard, on an Apple Macintosh II. It was a simulation of an interface in the sense that the system did not have full functionality, but apparent

functionality was suggested to the user by the provision of messages. As an illustration, if asked to send a memo the user would type in the name of the intended recipient and after a pause the system would indicate that the memo had been sent when, in fact, it had not. Also, when changes where made to a display such as in 'sorting the directory’; another card would be presented to the user which showed the directory in its new state, rather than any change taking place on the original view of the directory.

There were a number of versions of the interface and the differences between the versions will be described, first a description of the essential features of the interface will be given. All versions of the system had six objects (memo; calendar; graph; mailbox; report;

directory) and six actions (send; edit; copy; display; print; sort). Each object (or action) could be paired with three actions (or objects). Three of the objects could have their contents edited by the user (memo; report and graph) and three were static information sources (mailbox; calendar and directory), this difference being signalled by having the different groups paired with different action sets.

There was only one instance of any object (i.e. there was one memo, one graph etc.), an arrangement chosen to simplify the syntax to its most basic: object => action or action => object and to preserve exactly, the object:action ratios.

The interface also included facilities to support the test session. The task instructions were presented on screen. Subjects had only one opportunity to perform each task, after the task had been attempted, irrespective of the outcome, the next task description was presented. On the cards containing a task description there was an 'OK' button; subjects were instructed to click over this (using the mouse) when they had read the description. The initial screen of the interface was then presented (either with the Pick & Point presentation or the

Command-line presentation).

During task performance the system logged the commands chosen (Pick & Point group) or the strings typed (Command groups) as well as timing information (time to read the description; time to select the first and second commands for the Pick & Point condition).

\,.ilUL/kV>A

i) syntax (object => action versus action => object); ii) input style (command line versus Pick & Point style);

These differences were only apparent in the first screen shown to the user; once the user had specified the command, the system continued in the same way for all groups.

iii) task descriptions - the ordering and wording of the task instructions was balanced across the subjects.

In the Pick & Point condition, the initial screen displayed six boxes which were labelled either with six object names, or with six action names. To execute a command sequence (consisting of an object-action pair), the user was required to click on the appropriate box, using the mouse input device. This action caused a pop-up menu to appear giving the user three options (either all actions or all objects). The user then had to select one of the options to complete the command sequence.

An illustration of the initial screen for the Pick & Point/object => action Condition [OP] is given in Figure 6.1.

M e m o

s e n d

e d i t

c o p y

Ma i l boK

C a l e n d a r

R e p o r t

Gr a p h

D i r e c t o r y

Initial screen display for Pick & Point interface

In the Command-line condition, the initial screen displayed a command-line box with a flashing cursor. The user was required to type in the two words of the command sequence and

then to press the ’Enter’ button on the keyboard. If the typed sequence was incorrect for any reason (e.g. the words were in the wrong order; a word was mis-spelt etc.) a message box appeared which prompted the user to try again.

An illustration of the initial screen for the Command/action => object Condition [AC] is given in Figure 6.2.