GB2231982A - Command editor and authoring system - Google Patents

Abstract

A command editor enables a program author to create a computer program in the form of a stored list of commands. Each command is of one of a variety of command types and may include one or more parameters each being of one of a plurality of parameter types. The command editor comprises command entry means (SBTN, DLG) by which the author can select the command type and specify any required parameters to define a command to be included in the command list. The command entry means includes: parameter menu display means (PARTAB, SBTN, 18, 20) for displaying to the author a menu including parameter names representing available parameters of the given parameter type; parameter selection means (SBTN, 14, 15L) by which the author can select a predefined parameter for inclusion in the command by pointing to the corresponding parameter name on the displayed menu; and means (DLG) for activating the parameter menu display means in response to the selection of a command type requiring a parameter of the given parameter type. The command editor may form scripting means in an authoring system for defining user interfaces. <IMAGE>

Description

Description COMMAND EDITOR AND AUTHORING SYSTEM The invention relates to a command editor comprising means by which a program author can create a computer program in the form of a stored list of commands, each command being of one of a variety of command types each type being representable by a corresponding command name, at least one type of command requiring one or more parameters each being of one of a plurality of parameter types, parameters of at least one parameter type being representable by respective parameter names, the command editor comprising command entry means by which the author can select the command type and specify any required parameters to define a command to be included in the command list.

The invention further relates to an authoring system for use in defining the user interface of a computer or computer-controlled apparatus (the target system), the authoring system including: - display design means for use by an author in defining graphic and/or textual items for presentation to a user by a display means of the target system; and - scripting means by which the author can define one or more scripts each to be associated with a display item and each script comprising a list of commands defining a desired form of interaction between the target system and the user in association with the display of the associated display item.

The conventional method of creating programs for computers (including microprocessors, microcontrollers, digital signal processors and so forth) involves firstly the specification of the program's required performance. The specification is then passed to a skilled programmer who creates the final program by means of the keyboard entry of textual names representing the predefined functions to generate a source code program, and the subsequent parsing and conversion into executable (object) code by means of a compiling and linking system.

The conventional command editor is therefore simply a text editor and the conventional command entry means is a keyboard.

The editing and compiling functions are performed independently, although often by the same host computer system programmed first as an editor and then as a compiler. The object code may be suitable for executing on the same host system, but very often the program is being created to run on a different type of computer system, in which case a so-called cross-compiler is used. To avoid ambiguity, the computer system for which the program is being created will be referred to herein as the "target system", in contradistinction to any "host" computer by means of which the authoring system is implemented.

The definition of the program by keyboard entry of source code requires a skilled programmer who has knowledge of a given programming language, for example 'C', as well as an ability to translate program specifications into logical algorithms suitable for execution by a computer.

The programmer must know what types of functions are available in the given language and how to invoke them. He or she must know what types of parameters must be supplied to complete each command. The programmer must also be aware of many limitations of the compiler's ability to understand his/her intentions. For example, in the 'C' language, the programmer must attend meticulously to punctuation and also be aware at all times whether data is being referenced directly or by means of an address pointer.

There is an increasing need for programs to be created quickly by users themselves, or at least by authors who are closer in outlook to the intended users of the target system.

This may be the case where the program is a very simple tool created by an individual user of the target system to perform a specific task which arises in the course of using the target system. It may also be the case in larger applications where an iterative design process is required, and where the skilled programmer is not suited to the evaluation and respecification of each prototype. In such cases, the amount of time and effort between each revision of the specification and the revised compiled program may become so great that an iterative development process becomes very expensive or totally impractical.

An area where this is a particular problem is in the design of so-called user interfaces for computer systems. The user interface refers to the presentation of information to the user, most commonly via a display screen, and the form of interaction between the user and the target system in response to the displayed information. The user input may take the form of physical or on-screen button-presses, selections from displayed menus by scanning or by means of a pointer (such as a "mouse") and so on. Any system with a poor user interface is in practical terms a poor system, and this applies not just to general purpose computer systems but to all manner of consumer apparatus, technical instruments, process control or other systems which are computer controlled.While computers and computer-controlled systems offer ever more numerous and sophisticated features for the user, these features are only of practical value if the relatively unskilled user can avail himself of them via a simple and "friendly" user interface.

The customary approach to designing a user interface involves a graphic designer drawing screen layouts, which are then measured and the co-ordinates incorporated by a skilled programmer into a computer program, along with the code defining the user interaction and the rest of the application. It is usually fairly late in the design process when the results can be seen on a screen and tried by users. Often shortcomings in the design are then apparent but very difficult to correct. The design cycle is far too long.

In addition, user interfaces designed predominantly by the design engineers or programmers of a computer-controlled system often lead to "unfriendly" systems, because such authors tend to have difficulties in seeing their system with the eyes of a naive user.

It is an object of the invention to enable program authors, especially those unskilled in programming, to create programs more quickly, for example to design user interfaces for other programs or systems.

The stated problems have been recognised in recent years, and various attempts have been made to enable non-expert programmers to develop relatively complex programs. For example, so-called "fourth generation languages" (4GL) generally provide a new language with greatly relaxed requirements for syntax, punctuation, declaration of variables and so on, so that the programming language takes on a form more like natural language.

There are also authoring systems available which simplify the implementation of user interfaces, eliminating the need for a programmer to translate a screen design "manually" into coordinate values and write the program to integrate it with all of the other necessary functions in the correct manner. One such system is recently available in the form of the HyperCard system from Apple Computer Corp., described for example in "The Complete HyperCard Handbook" by Danny Goodman, published by Bantam Computer Books (ISBN 0 553 34577X). HyperCard includes a menu-and-pointer driven screen designing facility which operates in the manner of the well known menu-driven drawing systems such as MacPaint, also from Apple Computer Corp., but with special facilities so that buttons, sliders, windows, icons etc. can be designed and positioned on the screen as desired. Each graphical object such as a button, slider or an entire screen can have a program called a "script" attached to it to define the interaction with the user which is associated with that object.

The HyperCard system then executes the script whenever that object is displayed (the object may be invisible), for example to detect a user input signal specified by the script and to display in response a new screen, or to add an item such as a menu to the display.

HyperCard scripts are written in a special language HyperTalk, designed so that the non-expert can learn how to create a script relatively easily, while the system takes care of linking the scripts to the graphical objects and executing them at the appropriate times. However the scripts are still entered by typing at a keyboard so that, although the language HyperTalk is close to natural language in form, it is still necessary to learn the language before programming, so as to remember what types of commands are available, their names, what parameters they require as well as what their effect is.

It is also a problem that however simple and natural is the programming language, the keyboard-entry inevitably risks errors in programs arising for example from a mis-spelling or mis-remembering of a command's or a parameter's name, or from specifying parameters in the wrong order. One aspect of this problem which it is an object of the invention to mitigate results from the fact that, in creating any large program, the author invariably extends the language available to him by defining and naming many new items, for example variables, data files, high-level functions, display items and so on.

Mis-remembering and/or mis-typing such names soon becomes a problem even for the skilled programmer.

The invention provides a command editor comprising means by which a program author can create a computer program in the form of a stored list of commands, each command being of one of a predetermined variety of command types each type being representable by a corresponding command name, at least one type of command requiring one or more parameters each being of one of a plurality of parameter types, parameters of at least one parameter type being representable by respective parameter names, the command editor comprising command entry means by which the author can select the command type and specify any required parameters to define a command to be included in the command list, characterised in that the command entry means includes:: - parameter menu display means for displaying to the author a menu including the said parameter names representing available parameters of the given parameter type; - parameter selection means by which the author can select a predefined parameter for inclusion in the command by pointing to the parameter name of that parameter on the displayed menu; and - means for activating the parameter menu display means in response to the selection of a command type requiring a parameter of the given parameter type.

The parameter names presented in the menu may comprise textual names as in conventional programming languages, but it should be understood that they may also comprise ideographic, pictographic or any other symbolic representations whereby the author can rapidly identify the desired parameters. Similar considerations apply in respect of the command names. The invention reduces the need to remember what type of parameters are required, and the order in which they must be supplied, and also eliminates the need to remember and type the correct names for the parameters, thereby reducing the time it takes to learn to use the command editor, and also reducing the risk of error associated with keyboard entry.

The available parameters of the given parameter type may include parameters having names defined by the author and the parameter menu display means may include means for displaying a menu including the said author-defined parameter names. This is particularly advantageous for example in user-interface design where a large number of graphical objects, - buttons, bit mapped icons, etc. - may have been designed and named for future reference, since it reduces the risk of forgetting what a particular item was called and of mis-typing the name. Similar advantages may arise for example where large numbers of named variables, files or functions have been defined. As another example, if the parameter to be entered specifies a colour, then a parameter menu in the form of a pallette of colours can be presented, so that the author need not remember or look up colour codes or the like.

The command editor may comprise parameter menu display means for more than one given parameter type, the activating means including means for activating each parameter menu display means in response to the selection of a command type requiring a parameter of the corresponding given parameter type. Thus each parameter type - variable, colour, text string, file record etc.

- can have its own menu for display.

The said activating means may include means for activating an appropriate alternative parameter entry means to enable the specification of a parameter of a parameter type, different to the or any of the given parameter types, for which no parameter menu display means is provided. Certain parameter types may not be suited for menu selection, and for these some other entry means, such as a keyboard, can be activated.

The activating means may comprise: - means for displaying a representation of the command including a command name and representations of any parameters required but not yet specified; and - means by which the author can point to such a representation of a not yet specified parameter of the or one of the given parameter type(s) to initiate the activation of the appropriate parameter menu display means. The author can thus see the complete command being built up, and can be informed of what parameters need to be specified, while retaining the freedom to specify them when and in whatever order he chooses.

The command editor may further comprise: - command list display means for displaying to the author a representation of the commands so far included in the command list being created. The displayed representation may for example comprise lines of textual and ideographic information, each line representing one command. The representation may thus resemble a conventional source code listing.

The command editor may further comprise: - command list editing means by which the author can delete or rearrange selected commands from the command list by pointing to the selected commands on the displayed representation of the command list.

The command entry means may further comprise: - command type menu display means for displaying to the author a menu comprising command names representing the types of commands available for inclusion in the command list; and - command type selection means by which the author can select the type of a command for inclusion in the program by pointing to the corresponding command name on the displayed menu. The entire command entry process can thus be menu-driven, eliminating the need to remember and type even the command names.

The command editor may further comprise: - tokenising means for storing the created command list in the form of a sequence of token values representing the command types and parameters making up the commands. This form of storage is compact and also facilitates interpreted execution of the program.

The invention further provides an authoring system of the type set forth in the second opening paragraph, characterised in that the scripting means comprises a command editor in accordance with the invention as set forth above.

For a parameter type including display items, a menu displayed by a corresponding parameter menu display means may include automatically parameter display item names defined by the author representing display items defined by the author using the display design means.

The authoring system may comprise means for switching to a simulation mode wherein the operation of the target system under the control of the program being created can be simulated, the authoring system further comprising means for interpreting the stored script or scripts so as to perform functions simulating the operation of the target system under control of the user interface. This provides a rapid prototyping facility which allows feedback from authors, users, managers and others to be incorporated into the user interface at an early stage in the design process.

The authoring system may comprise target display simulation means for displaying the defined display items in a form identical or equivalent to that in which they would appear on a display of the target system. For example, a domestic television receiver may be connected to the host computer by means of a video interface card. This enables the author to see the interface in the same form as the users will see it, rather than on a professional quality high resolution monitor. The target display may for example be that of a Compact Disc - Interactive player, a teletext driven display or a liquid crystal display, all having particular characteristics in terms of resolution, colours, character sets etc. that will affect the appearance of the finished user interface.

Similarly, the authoring system may comprise target input simulation means identical or equivalent to an input means of the target apparatus for controlling the simulated operation of the target system.

The interpreting means may include: - means for storing a program routine for implementing each type of command and included in the defined script or scripts in a coded form suitable for execution within the authoring system; and - means for identifying and causing the execution of the routines implementing the selected functions in accordance with the script, so as to simulate the interaction between the target system and a user in association with an item displayed by the target display simulation means.

Before switching to simulation mode, the created command list may be stored in the form of a sequence of token values representing the selected command types and parameters, and the interpreting means may include a table of pointers relating command type token values to memory locations of the coded routines for implementing the corresponding functions within the authoring system. Such sequences of token values are compact, and can be readily generated, since the menu options can conveniently be identified internally by means of numerical values. Such scripts can also be readily and rapidly interpreted to simulate the user interface at near full-speed, since there is no requirement for parsing and error checking by the interpreter.

The interpreting means may further include, for at least one type of parameter, a table of pointers relating parameter token values to memory locations of data defining corresponding parameters of the at least one type, and wherein, for a type of command including a parameter of the at least one type, the target system, under control of the corresponding program routine for implementing the said type of command, includes means for reading a parameter token value from the tokenised script and using the corresponding pointer from the said table to determine the location of the parameter data necessary for the implementation of the command.

Embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings, in which: Figures 1 and 2 show alternative configurations of hardware suitable for implementing an authoring system in accordance with the invention; Figures 3 to 14 illustrate screen displays of the authoring system in various states of operation; Figure 15 shows schematically the structure of the authoring system; Figure 16 shows schematically the structure of a command editor module within the system of Figure 15; and Figure 17 illustrates a screen display including a menu of author-defined parameter names.

Figure 1 shows a first configuration of hardware elements suitable for implementing the authoring system. The main element is a host computer 10, which may for example be an IBM PC-AT (trademark of IBM Corporation) or compatible computer. The host computer 10 is provided, in a manner which is conventional per se, with a display 11 (hereinafter referred to as the "host display") and with a keyboard 12 and mouse 14 for use by the user of the authoring system (hereinafter referred to as "the author") in controlling the system. The mouse 14 has left and right signalling buttons 15L and 15R respectively. The mouse 14 could of course be replaced by any suitable pointer-type input means, for example a graphics tablet, trackball or touch-sensitive screen. The host computer 10 includes an internal memory and also has access to a hard disc drive 16 or other mass storage device.

To enable realistic simulation of a target system which is of a different form to the host computer 10, the host computer is optionally provided with an interface 18 for driving a target display 20. In designing an application where the target system uses a domestic television as the display, then the interface 18 may comprise a plug-in video generator board which can be plugged in to the host computer 10 and set up to drive a domestic television receiver with the same resolution, aspect ratio, colour pallette etc. as the target system. One suitable board is Matra Harris' VSDD video display card. In other applications, the target display means 20 may for example be a liquid crystal display (LCD), so that the interface 18 becomes an LCD driver.

If the target system were of the same form as the host computer, then the host display 11 might suffice.

In many applications (for example in CD-I) the target system will use a pointer-type input device such as the mouse 14 for input. However, for an application where a different input device is used, for example an infra-red remote control handset, then an interface 22 is provided for connecting a remote control handset 24 or other target input means to the host to enable realistic simulation of the interaction between a user and the finished target system.

Where the application demands, a general input/output interface 26 may connect the host computer to means 27 for emulating functional elements of the target system, for example the tape transport mechanism of a video cassette recorder.

Alternatively a software module within the host computer 10 can be provided which mimics these functional elements of the target system.

Figure 2 shows an alternative hardware configuration in which the host computer 10 comprises a high-performance graphics workstation-type computer, so that the host display 11 is a larger, higher resolution display than that of the PC-type host of Figure 1. In Figure 2, the separate target display means 20 is replaced, by means of a software interface, by a part 20' of the host display 11 chosen to have the same resolution as the target display, for example a domestic television or an LCD. The target input means 24 (remote control handset) is also replaced by a representation 24' on the host display 11 which can be operated using the mouse 14 and one of the buttons 15L or 15R to simulate a user pressing buttons on a remote control handset or other target input device.

Those skilled in the art will recognise that many different hardware configurations may be suitable for implementing an authoring system, and that those described above are presented by way of example only. In particular, the nature of the components outside the basic host computer will depend to a great deal on the nature of the target system, and the extent to which it is to be emulated.

Figure 3 shows the main menu screen of the authoring system. Some of the screen displays shown in Figures 3 to 13 may appear on the host display 11, but it will be more convenient if all of the displays can appear on the target display 20, to avoid the need for the author to refer back and forth between two screens. A cross-shaped cursor 38 can be moved over the screen using the mouse 14, and an item under the cursor 38 can be selected for further processing by depressing the left mouse button 15L (this operation being referred to hereinafter as "clicking on" an item). The main menu is divided into two menus 40 and 42, relating to a design state and an interaction state of the system respectively.

The user interface is defined in terms of display "objects", each object being a self contained data structure which contains, in addition to data defining the appearance of the object on the display, information identifying the object and linking it to other objects. A screen object, for example, might contain information defining, say, a background colour for the screen, and then a large number of links to other objects or groups of objects which appear against the background when the screen is displayed. In the design state menu 40, options 40a to 40e allow the author to elect to design an entire screen of the user interface (40a), or a button (40b), a complex group of objects (40c), a pictograph or "bitmap" (40d) or a text object (40e). The options 40b-40e allow objects of the corresponding type to be created as named items independent of any particular screen.However, these types of objects can also be designed as parts of larger, named objects so that, for example, a bitmap can be designed as part of a screen, button or group after selecting the option 40a, 40b or 40c respectively.

The interaction menu 42 contains an option 42a to activate the interaction mode of the system, wherein the actual operation of a user interface under design can be tested with the authoring system acting as a prototype, as will be described below with reference to Figures 13 and 14. Further options 42b etc. may be provided for diagnostic or other operations which are not relevant to this description. A quit button 44 provides the option to finish editing and/or testing the user interface.

Figure 4 shows the situation after the screen design option 40a has been selected and (by means of further menu selections not illustrated) a particular user interface resource file has been loaded into memory from the disc 16, and a particular named screen, already partly designed in an earlier editing session, has been selected for editing. The system then enters a graphic design mode in which coloured shapes, text, bitmaps, buttons and so forth can be defined using the mouse 14 in a manner which may be similar in principle to prior art graphic designing systems and the prior art authoring system HyperCard.

The screen being designed for the purposes of this example might form part of an on-screen user interface for a domestic television set or satellite broadcast decoder. Such apparatuses are increasingly equipped with so many sophisticated features that an intuitive on-screen user interface is almost an essential part of the product if it is to be a success in the consumer market.

The screen being designed can be seen, without the various features which are superimposed upon it in the design state, in Figure 14. A background region 46 is shown black in the Figures, but in practice may be assigned any colour or may be "transparent" so that video signals currently being received by the target system are displayed as a background. Superimposed on this background 46 is a window 48 containing other windows 48a, b and c. The window 48a contains text 49 and a bit map 48d providing a title for the screen, the window 48b displays a menu of numbered options and the window 48c displays instructions for the user as to what form of interaction is required.In the example shown, the user of the finished target system will be able, by means of an infra-red remote keypad, to select by number certain television channels so that those channels are only viewable after entering a secret code, thereby allowing parental control of a child's viewing.

A button 50 is also drawn on the screen with text and bitmap information upon it indicating that activating this button will cause a different screen to be displayed, allowing access to other control facilities. Other screens of an interface for a television receiver may relate to tuning, volume and picture controls, subscription payment and so on, each providing graphic and/or textual information to guide the user through the desired operations.

For the purposes of designing the visual appearance of the screen, a "control box" menu 52 is optionally superimposed over the screen and provides various drawing options to enable lines, boxes, polygons and so on to be defined and coloured using the mouse 14 and left mouse button 15L in a manner well-known per se from general-purpose drawing systems. A select option 52a on the menu 52 allows individual objects such as the button 50 to be selected for further treatment. By clicking the left mouse button 15L with the cursor 38 over the option 52a and then clicking the button 15L again with the cursor 38 over the button object 50, that object has been selected in Figure 3, so that a so-called "drag-box" 54 appears surrounding the object 50. The mouse 14 and mouse button 15L can then be used to re-position or re-size the selected object (button 50) at will, in a manner known per se.

By clicking the right mouse button 15R, a "pop-out menu" 56 can be made to appear and disappear at a desired location on the screen. The pop-out menu 56 contains options 56a to 56g providing higher level operations to modify for example (56a) or rearrange (56b) the screen objects, or to add new objects (56f) such as buttons and bitmaps, to save the edited screen (56g), and so on. Clicking on an option on the pop-out menu 56 causes a further menu 58 of sub-options to be displayed, in a manner described in more detail in European Patent Application EP-A2 0 249 293.

For the purposes of describing the present invention, the most important option on the pop-out menu 56 is the command editing option 56d. when this option is selected the sub-menu 58 offers the choice of editing a command list (corresponding broadly to a script in the prior art HyperCard system) attached either to the entire screen (58a) or to the selected object (the button 50 in Figure 4) (58b).

In response to the selection of option 58b, a command editor is activated which generates the display shown in Figure 5 and enables the author to create a script of commands which is to be available to be performed if a certain "event" occurs while the button 50 is displayed. The screen is divided horizontally into two areas, forming a selector button 60 and a list button 62.

In addition to a window area 62a for displaying text objects representing the commands in the list (the list is empty in Figure 5), the list button 62 contains an invisible insert button 62b in the form of a vertical strip to the left of the window area 62a which contains an insert arrow symbol 62c.

To the right of the window area 62a the list button 62 contains a group of objects forming a scroll bar 62d for controlling the scrolling of the command list text displayed in the area 62a in a manner well known in the art. To this end the scroll bar 62d includes up and down scrolling buttons 62e and 62f respectively and a scroll box area 62g for indicating which part of the command list is displayed in the window area 62a. A scroll box 62h (shown hatched) fills the scroll box area 62g to indicate that the entire list (being empty) is currently displayed.

while the cursor 38 is on the list button 62, a pop-out menu 64 is available under control of the right mouse button 15R. The pop-out menu 64 provides options 64a to 64d including "cut and paste" facilities (64a) such as are commonly found in conventional text editors, and a help facility (64c) with various help topics offered as options on a sub-menu 66. Option 64b provides other facilities not relevant to the present description, while option 64d allows the editing session to be terminated, in a manner to be described below with reference to Figure 10.

The command editor as described so far is little different from a conventional mouse-driven on-screen text editor, including for example that provided for script editing in the Hypercard system. However, the selector button 60 in the present system allows the entry of command names and parameters without using the keyboard, and without the need for the author to remember the commands and parameters available, their names, spelling, syntax and so forth.

To this end, the selector button 60 contains a window area 60a for the display of menus and a scroll bar 60b since, as the scroll box 60c indicates, only part of a menu may be able to be displayed in the window area 60a at a given time, depending on the number of options available. A title area 60d is also provided for information identifying the menu currently displayed, or for other information.

The title 68 currently displayed in Figure 5 indicates that a menu of command types is displayed in the window area 60a of the selector 60. All of the different command types available for inclusion in the script are represented in the area 60a (with scrolling) as menu options 68a,68b and so on. Since the script is being created to define part of an event-driven user interface program, the first command in every script is required to be of a type, named 'if event' in the example, which specifies an event to which the script is responsive. For convenience, this command type is the first option 68a on the commands menu. In authoring systems for other types of programs, of course, there may be no such limitations, or different limitations.

The selector menu is more than a mere listing of available command types such as might be displayed by a "help" function in a conventional system. Using the mouse 14 and left button 15L to point to and select the option 68a is all that is needed to initiate the inclusion of the event-specifying command into the script. After selecting a command type, a dialogue box 70 (Figure 6) relating to that command type is displayed on the list button, appearing at the place in the listing marked by the insert arrow 62c (top in this case). The dialogue box 70 contains a button 70a, which can be clicked on to confirm the selected command represented at 72 and effect its entry into the command list, a button 70b, which can be clicked on to abandon the selected command in case of error, and a button 70c which can be clicked on to display explanatory information about the selected command type.Selecting the button 70a immediately, however, would cause an error message to be displayed since the system automatically determines from stored information defining the menu options 68a etc. that the event-specifying command is not complete without certain parameters.

The representation 72 of the selected command in the dialogue box 70 includes not only the command type name 72a but also a representation 72b of any parameters that need to be specified for the command to be executed. The parameter representation 72b, being merely a row of dashes, acts as an invitation to the author to specify the parameter. There may be more than one parameter to be specified, and the author is required to click the mouse button 15L over this parameter representation 72b, which then becomes highlighted, and the selector 60 changes to display a menu of suitable parameters in the window 60a.

The new menu has a title 74 indicating that, since the system knows that the event-specifying command type 72a requires a parameter 72b defining a type of event, the menu options 74a etc. presented in the window 60a represent all the various event types that the system (strictly, the target system) is equipped to recognise. For example selecting option 74a would cause the command to respond to depression of the left mouse button 15L, whenever the cursor 38 is over the button 50 (see Figure 4) to which this script is attached. Similarly, selecting option 74b will allow a response to the depression of the right mouse button 15R, and options 74c and 74d allow a response to the releasing of the left and right buttons 15L and 15R respectively, also on the attached button.Options 74e and 74f allow a response when the cursor simply enters or leaves the attached object, for example to trigger a change of colour. Option 74g allows response to the keyboard and option 74h allows response to the infra-red remote control (24, Figure 1).

Bearing in mind the diverse natures of target systems, some types of events might be inapplicable in a given user interface.

For the present example of a television receiver user interface, for example, only the option 74h might be valid, since the television is not likely to be provided with a keyboard or a mouse. In more computer-like target systems, including for example a Compact Disc-Interactive (CD-I) application, then the mouse or other pointer might be the only input device.

Furthermore, other event types, not shown in Figure 5, might include timed events, events external to the user interface (such as signals from mechanisms within a target system), cursor movement (useful for dragging the attached object). For scripts attached to screens, an event might also comprise the addition or removal of a subsidiary object to or from the display.

In the present example, it is assumed that the remote-control option 74h is selected. This selection is then represented in place of the dashes 72b so that the complete command is represented at 72 (not illustrated). The author then confirms the command by clicking on the button 74a, the dialogue box 70 disappears and the command appears as a first line of text 62al in the window 62a of the list button 62. The insert arrow 62c moves down to indicate the next line to be entered and the selector 60 again displays the main command type menu comprising title 68 and options 68a, b, c and so on. This gives rise to the situation shown in Figure 7, in which the command type menu in the selector window area 60a has also been scrolled using the scroll bar 60c-60f, to display the last part of the menu, with options 68q to 68z.

In the example, an option 68x is selected to obtain a command named 'if RC' which allows discrimination between different codes received from the remote control 24. Again, the dialogue box 70 appears (Figure 8), containing the buttons 70a, b and c and the representation 72 of the complete command with spaces, in this case for three parameters.

Whereas the event-specifying command type (option 68a) required a single event-type parameter, the remote control code-specifying command (68x) requires three parameters. The first two parameters identify the type of remote control device from a number of standard options, while the third parameter is a code number identifying a button pressed on the remote control handset (24). Rather than provide a menu of all the possible codes, the title window 60d of the selector 60 displays a message 74 requesting the author to enter the desired code number by means of the keyboard 12. A typing cursor 76 appears in the appropriate place for the parameter and the author types the desired code ('53' in the example) before selecting the button 70a to complete the entry of the code-specifying command.

Ideally, keyboard entry is only required by the system when no practical alternative is available, for example where a parameter is a numerical value. Even then, certain numerical parameters can be entered by menu, one example being colour values. Therefore, if the parameter to be specified were a colour, represented in the command by a numerical index referring to a colour look-up table (CLUT), then the system will (in a manner not illustrated) generate a menu comprising a pallette of colours to make the selection easier. Once a colour is selected and confirmed, the numerical value may appear in the displayed command line as displayed at 72 and in the command list window area 62a.It may also be possible to eliminate the keyboard entry step (illustrated in Figure 8) for specifying remote control codes if the command editor were made responsive to the remote control 24 (or any other target input device) and a suitable message were displayed at 60d.

Another example where keyboard entry might be necessary is in specifying simple alphanumeric variable names in commands.

It might be preferable, however, to provide a menu of the variables already named, so that they need not be re-typed, once they have been defined. It can be seen from this that not all menus are fixed by the system, many parameter menus comprising items defined by the author during the design process. The generation of such menus will be described below, with reference to Figures 16 and 17.

In Figure 9, the remote control code specifying command has been confirmed (button 70a in Figure 8) and appears as command line 62a2 in the listing window 62a (see Figure 10). Command type option 68e has been selected from the main command menu (68,68a,b,c etc.). This option 68e defines a command which will cause the display of a previously displayed screen. The dialogue box 70 then appears to display the command 72 with a space at 72b for a parameter identifying the previously displayed screen to be displayed. The selector 60 offers a choice of two parameter options 78a and 78b, under a title 78 which refers to the command type (68e) selected.The first option 78a, which is selected in this case, specifies that the screen displayed by the user interface immediately before the present screen should be returned to in response to the remote control unit 24 sending code 53 when the button 50 (see Figure 4) is displayed by the target system.

The second option 78b (not selected in this case) allows the user interface to return to a last marked screen. Option 68d on the main command menu 68,68a,b,c etc. allows a currently-displayed screen to be marked for future reference using the option 78b.

Another option 68c on the command menu allows a new screen to be called for display by the user interface. In that case, the possible parameter options are not limited to two, and the selector 60 will display a menu of options comprising the names of screens defined by the author previously. This is another example of a menu not fixed by the system.

In Figure 10, the command to step back to the last screen is displayed at 62a3 in the command listing, and two further commands have been added and are displayed at 62a4 and 62a5. The first of these commands (62a4) is the option 68y on the command menu and is used together with the remote control code-specifying command (option 68x, line 62a2) to delimit the commands which are to be executed conditionally on the receipt of the specified code ('53' in this case). For improved readability of the listing, the system automatically indents the lines (62a3 in this case) between the two commands as would be done by the programmer using some conventional programming languages.

The second of the added commands, line 62a5 in the listing is option 68b on the command menu and is used together with the event-specifying command (option 68a, line 62al) to delimit the commands which are to be executed conditionally on the occurrence of the specified event. The lines 62a2 to 62a4 between these two commands are similarly indented to improve readability. By adding further event-specifying commands after line 62a5, the button object 50 on the display (Figure 4) can be made to respond independently to more than one different event.

Similarly, further remote-control code-specifying commands could be inserted between the lines 62a4 and 62a5 to make the button object 50 respond independently to more than one code received from the remote control device 24.

The command editing session can be terminated recalling the pop-out menu 64 (by means of the right mouse button 15R) and selecting the option 64d. The consequent sub-menu 80 offers the option 80a to attach the new script to the button object 50 and the option 80b to abandon any changes made since entering the command editor. In either case, the system reverts to the screen designing state, as illustrated in Figure 11.

Because of the menu driven nature of the command editor, and because, for example, it is not possible to enter an incomplete command into the command listing, then the majority of errors which commonly arise in computer programs are prevented. As a further precaution, however, before the command editor will store the new script and return to the screen designer, it performs a check on the command list for other types of errors that are not trapped by the precautions. One such error is the omission of command options such as 68b, 68y which must be included to terminate a group of commands headed by a corresponding condition-specifying command option such as 68a or 68x respectively.Figure 12 illustrates that if, for example, the command option 68y had not been selected (line 62a4 in Figure 10) to terminate the code-specific part of the script headed by the code specifying command (option 68x, line 62a2), before selecting the option 80a on the pop-out menu 64/80, then the system would draw the author's attention to this error and would not allow the script to become part of the user interface. To this end, a message window 82 would appear, including an explanation of the error at 82a. A button 82b allows the author to confirm that he has noted the error. The message window 82 would then disappear and the command menu 68, 68a etc. be displayed by the selector 60 to allow the option 68y to be selected to insert the missing command.This can be done by dragging the insert arrow 62c to a position 62c' between lines 62a3 and 62a4 before selecting the command option 68y, or the command can be entered after line 62a4 and moved using the cut and paste option 64a on the pop-out menu 64.

By its nature, therefore, the novel menu-driven command editor of the authoring system described has the capacity to prevent a significant proportion of the errors commonly made even by skilled programmers ever being included in the program. This is a great advantage over prior art systems where trivial errors of spelling or punctuation become a major nuisance since they are not discovered until compilation or even execution of the program. Furthermore, these advantages are clearly not limited to the present example of script editing in user interface design: they are advantages that can be realised in any programming application though different commands and parameters may apply.

For example, in producing a large program, the author will typically wish to define or have pre-defined various high level functions requiring certain parameters. The command editor could then include these functions by name on a command menu, and their parameters could be required to be specified, by menu where possible, before the function call would be allowed to be entered into the program. Similarly, conditional commands and looping commands could be prevented from inclusion without their corresponding closing commands, thereby eliminating these and many similar errors that skilled programmers will recognise, and which presently make programming by unskilled programmers totally impractical.It should also be noted that program editing is facilitated for skilled programmers as well as for non-skilled programmers, since the former are not necessarily any less prone to typing errors than the latter, and may also be saved much of the trouble of learning a new language by using such a menu-driven command editor.

Once all detected errors have been corrected in the script, and option 80a on the command editor pop-out 64/80 menu has been selected, then the situation is as shown in Figure 11. Options 84a-84f relating to the saving and retrieval of the user interface in the memory and on disc are available on a sub-menu 84 of the screen designer pop-out menu 56, option 56g. Option 84a for example allows the copying of a previously defined object to form the basis of a new object, option 84d allows the loading of the predefined object itself for editing. Option 84f allows all changes made since the user interface was last saved to disc to be abandoned. Option 84b allows the user interface stored in the memory to be updated with all changes made (including, for example, the script newly attached to the button 50).The system would then return to the main menu (Figure 3) where selection of the quit button 44 will enable the complete updated user interface to be stored to disc, for future editing sessions or for incorporation by a programmer into the control program of the target system.

In accordance with another important aspect of the system, however, the system is equipped not only to display the various objects (screens, buttons etc.) for the purpose of designing them, but also to interpret the commands attached to those objects by the command editor and execute them to enable an immediate and realistic simulation of the user interface (so far as it has been defined) in operation. Selecting the option 84c not only causes the user interface stored in memory to be updated but also causes the system to enter the interaction mode, as if the option 42a had been selected on the main menu (Figure 3).

On entry to the interaction mode, the system gives the author the opportunity (Figure 13) to specify which screen of the user interface he wishes to start from for the purpose of simulation. This allows the testing of an incomplete user interface, or a small part of a large interface. In Figure 13, a title 90 informs the author that the interaction mode has been activated, and buttons 90a and 90b allow the author to change the starting screen and/or the input device for interaction (mouse, joystick and so on) respectively. Clicking on button 90a causes a dialogue box 92 to be displayed containing a menu 94 of the named screens of the user interface. The author can select the screen which has just been edited, for example, by clicking on the appropriate name option 94a.After confirming the selected screen by clicking on a button 92a in the dialogue box 92, the box 92 then disappears and the interaction can be begun by clicking on a button 90c on the screen, or aborted by clicking on a button 90d.

In the interaction or simulation mode (Figure 14), the selected screen is displayed, not as a graphical object under design, but as a simulation of the final user interface in operation. In this state the system will behave almost exactly as the target system would under control of the user interface, as far as it has been designed, in particular by responding to the events (remote-control operations and so forth) defined by the commands in the scripts attached to the displayed objects such as the button 50. Therefore, the author can immediately test not only the appearance of individual screens, but also the sequences of screens, menus etc. that user interaction will cause to be displayed, thereby allowing the author to ensure that the interactions will be as logical and intuitive as he intended them to be.Sample users can also use the system in this state to provide feedback to the author at a stage when he can still respond to the feedback.

Figure 15 shows schematically the structure of the authoring system. Reference signs 11, 12, 14, 15L, 15R, 16, 18, 20, 22, 24, 26 and 27 refer to the hardware elements described above with reference to Figures 1 and 2. The remainder of the system comprises various functional modules which could be implemented as separate hardware modules, but in the present example comprise software processes all operating within the host computer system.

A module MMEN provides the highest level of control of the system, being responsible in particular for generating the main menu shown in Figure 3. Selecting one of the design state options (menu 40) causes control to pass to a group DES of modules implementing the design state of the system, while selecting the one of the interaction state options (menu 42) causes control to be passed to a group SIM of modules implementing the simulation functions of the system for prototyping.

Before describing the functions of these groups of modules DES and SIM, it is convenient to refer to a filer module FIL which is responsible for storage and retrieval of resource files defining a user interface from memory and from the disc store 16. The filer FIL is activated whenever the authoring system is first activated, in order to read the resource files for the user interface under design from the disc 16 into a resource memory RESM.

The user interface stored within the memory RESM will comprise primarily definitions OBJ of objects (screens, buttons, vectors, bitmaps etc.) for display, each object either having its own name or label, or being attached permanently to some other object. Another part LABS of the resource data comprises a table of such labels, together with pointers to the locations in the part OBJ where data defining the labelled object are stored. The objects can be stored with definitions of object type, coordinates, colour and so on in any convenient format. In particular, however, object definitions may contain pointers to scripts, which are stored in tokenised form another part TOKM of the memory RESM, in a manner described below. Also stored is a colour look-up table CLUT defining how the logical colours referenced within the resource memory will appear on the screen.

Rather than allow editing of the actual resource data RESM, the filer FIL automatically makes a copy RESM' of any resource data being edited, so that the copy RESM' can be modified by the design modules DES without fear of corrupting the original.

when leaving the design state (modules DES), the data RESM' is copied back into the original data RESM unless the author indicates that the changes made are to be abandoned (see Figure 11, option 84f). If the quit button is activated (44, Figure 3) in the main menu module, then the filer module FIL will store the modified data RESM to the disc 16 unless the author indicates that all changes made since the resource data were first loaded from disc are to be abandoned.

The resource data can be stored on the disc 16 in any convenient form. In one embodiment, they are stored in a form similar to 'C' source code so that a programmer can incorporate the user interface easily into 'C' programs defining the rest of the system. It would also be possible for the filer to generate genuine source code that could be compiled directly, and linked to the rest of the system.

In the design state modules DES, there are modules SCRD, BTD, GPD and TXD providing the functions of screen design, button design, group design, bitmap design and text design, respectively, as described above with reference to Figures 3 to 14, these modules being activated in response to selection of the options 40a, 40b, 40c, 40d and 40e in the main menu module MMEN respectively. As described above, certain of these modules can also be activated from within other modules using the pop-out menu 56. The design modules DES receive input from the mouse 14, 15L, 15R and also, as required, from the keyboard 12, while a design display generator module DDG produces the displays as described above, by means of the target display simulation means 18 and 20.

The principles of graphic design tools are well-known per se, and the internal workings of the modules SCRD, BTD, GPD, BMD and TXD will not be described further. It is also known by those skilled in the art how the object definitions that are the outputs of such modules can be linked together to define larger objects, and also how command lists can be attached to the object definitions to act as scripts defining interactions in a user interface.

The creation and storage of scripts in the system shown is not conventional, however, being performed by a command editor module CMED which will now be described in more detail with reference to Figure 16.

The command editor module CMED, shown schematically in Figure 16, has access to two main tables of data, a command table CMTAB and a parameter table PARTAB. The command table CMTAB is an array containing an entry for each available command type. A representative entry in the table CMTAB is shown expanded at CMENT. The entry CMENT contains: - a name CNAM (text or some other symbolic representation of the command type) to appear as an option (68a,68b etc.) in the selector menu (Figure 5) and in the displayed command listing (62a1,62a2 etc.Figures 7 to 10); - a token CTOK which is a short integer value identifying the command type for storage in the tokenised script data TOKM; - a size value CSZE defining the length of the command in a tokenised script, which may for example be 2 bytes for the command type token CTOK and a further 2 bytes for each parameter; - an indentation value CIND which may be +1, 0 or -1 depending on whether, in the command list to be displayed on screen in the list button window area (62a), this command causes the level of indentation to increase, remain the same or decrease; - a value or values CPART defining by means of a predetermined code the parameter type(s) of all parameters required by the command; - a pointer FUNAD to the location in a function memory FUN where there is stored an executable routine for implementing the command in the interaction state; and - a set of flags CFLG which may be used for various purposes, for example to cause an "experts only" command type to be hidden from a non-expert author on the selector menu.

The parameter table PARTAB contains, for each parameter type, a definition of all of the possible parameters of that type. This may for example indicate that a 16-bit number, a colour value, or a pointer to a text variable is required to specify a parameter of that type. However, as mentioned above and illustrated in Figure 17, the command editor also provides for menu selection of parameters defined by the author himself, with names or labels also defined by the author.

To this end, the parameter table PARTAB contains label data in a table ADP, containing an entry for each item named by the author. One such entry is shown expanded at LBENT, and comprises: - the label name LBNA, for example a text string, to be displayed in the parameter menus and command lists; - a value LBTP identifying the type of object to which the label refers, for example screen, bitmap, button, variable, filename; - a label token LBNO which uniquely identifies the object (and its label) within the authoring system; and - a pointer LBPR which point to the location of the data for the object, for example in the part OBJ of the resource data RESM/RESM'.

The selector part (60) of the command editor display (Figure 5, for example) is generated by a selector module SBTN, which initially involves the display of all the command type names CNAM as options (68a, 68b etc.) on the selector menu. when a command type has been selected, the module SBTN activates a dialogue module DLG which uses the various parts of the appropriate entry CMENT to determine what parameters are required and to display the dialogue box (70, Figure 6) accordingly.

The dialogue module DLG then uses each parameter type value CPART and data in the parameter table PARTAB to determine the appropriate means by which the author is to be prompted to specify a parameter. In the case of the numerical value required to specify the remote control code, illustrated in Figure 8, the module DLG instructs the module SBTN to display the text instructions 74 in the title window 60a of the selector 60, and then takes direct input from the keyboard 12.

If, on the other hand, the parameter type value CPART indicates that an author-defined parameter is required, then the table ADP is scanned to find all entries (LBENT) in which the type identifier LBTP matches the type of parameter required and passes the names LBNA of all those which match to the module SBTN which displays them as a menu in the window 62a and returns any name selected by the author. Figure 17 illustrates this, in a situation where the command type option 68c has been selected from the command menu (see Figure 5). This command type is for causing the target system to display a new screen, and requires a screen name for its parameter. The dialogue module DLG thus identifies all ADP entries with LBTP corresponding to the type "screen", and the module SBTN displays the names of these as options 92a, 92b etc. in the menu window area 60a. The menu is shown scrolled to the end so that only options 920 to 92z are visible in the window. A title 92 in the title window 60d indicates the type of parameter menu being displayed.

Assuming that all parameters have been specified, and the command confirmed for inclusion in the command list (button 70a, Figure 8, for example), then the completed command is passed to a list module LBTN which builds up the command list in the form of a linked list of entries command line entries such as that shown expanded at LSTEN.Each command line entry LSTEN contains: - a value LIND giving the indentation level of the command line in the displayed listing; - various flags LFLG as required, for example to indicate that the line has been marked for manipulation by the cut-and-paste facilities (option 64a, Figure 5); - a pointer LTXP to a text string in memory which will be displayed by the module LBTN on the display means 18,20 in the list button window area (62a); - a token LTOK defining the command type for the command and further tokens or values defining the parameters, if any, that have been specified; and - a link pointer LNK to point to the next command line entry LSTEN in the list CMLST.

The modules SBTN, DLG and LBTN operate in a continuous loop until the pop-out menu (for example 64, Figure 10) is activated and, for example, the option 64d is selected to terminate the editing of the command listing. If the sub-option 80b is selected, then the edited command list CMLST is abandoned, but if the sub-option 80a is selected to update the resource data RESM', then an error checking module ERCH is activated which checks for errors of the type described above with reference to Figure 12. If an error is detected, the appropriate message box (82, Figure 12) is displayed, and the editor loop comprising the modules SBTN, DLG and LBTN is reactivated.

If no error is detected, then the edited command list CMLST is converted by a script filer module CMFIL in to a compact, tokenised form, shown expanded at STOK. The tokenised script STOK comprises a sequence of numerical values, the first of which (S), defines the size of the script, in bytes, for example. Each command line entry LSTEN, represented on-screen at 62a1,62a2 and so forth, is converted as in to a corresponding sequence 62a1',62a2' etc. of one or more token values, the first of which is always a command type (C) token.

Depending on the command type, each such C token may be followed by one or more parameter (P) tokens, one for each parameter required to complete the command. Where the parameter is a simple integer value, then the P token may simply equal that value. If, on the other hand, the parameter is a named object, then the P token may comprise the value LBNO which, via the label data LABS in the resource data RESM/RESM', uniquely identifies the desired object. The object type can also be identified if, for example, the type value LBTP occupies 5 bits and the value LBNO occupies the remaining 11 bits of a 16-bit P token. A special (T) token marks the end of the script. The tokenised script STOK is stored by the module CMFIL in the part TOKM of the resource data RESM', together with information linking it to its associated display object data in the part OBJ of the resource data.

Two further modules ED and HLP of the command editor module CMED are shown dotted in Figure 16, indicating that they are not active all the time, but may become activated using the pop-out menu options 64a and 64c respectively (see Figure 5). The first module ED provides cut-and-paste facilities, by means of which lines or groups of command lines can be moved within, or deleted from, the command list. The module operates by manipulating the pointers LNK that connect the command line entries CMENT in the command list CMLST, and uses the flags LFLG to mark lines for moving or deletion. The other module HLP displays "help" information via the display means 18,20, in response to requests for the information received from the author via the mouse 14,15L,15R.

Returning to Figure 15, the operation of the simulation (interaction) modules SIM can now be described. The modules SIM have available to them the stored resource data RESM and, either directly or in some equivalent form, the command table CMTAB, the parameter table PARTAB and a function store FUN. The function store FUN contains an executable (object code) routine for causing the host computer to implement each type of command that may be included in a script.

An interpreter module INT reads linking data and tokenised scripts from the resource data and causes a simulation display module SDG to display the objects defined by the data OBJ, so that the display means 18,20 reproduces the eventual target display. At the same time, any scripts attached to any of the displayed objects are identified by the interpreter INT and a table constructed defining all of the event types that are relevant to any of these active scripts. This table is passed to an event handler module EVH which monitors the appropriate input devices, in this case the remote control 22,24 and, optionally the external devices 26,27.

when a relevant event is detected by the event handler EVH, this information is passed back to the interpreter INT which then finds the tokens (in TOKM) for any commands to be executed in response to that event. Each token can be related, via the pointer FUNAD in the command table CMTAB, to an object code routine in the function store FUN. The interpreter INT can then cause the host computer 10 to execute the routine, which will also read from the tokenised script the appropriate parameters stored in the script following the command token.

It should be appreciated that, while the command lines 62a1-5 displayed by the command editor are similar in their textual appearance to the lines of source code that would be generated using a conventional program editor, they are only provided as a visual representation of a stored program. It is of particular benefit that, because the command types and parameters are selected from menus of options already known to the command editor, the stored program can be represented by a series of simple token values. This approach greatly facilitates the prototyping (simulation) function of the authoring system, since the tokenised commands can be interpreted almost at the full speed of a compiled program, without the need for parsing and error-checking that makes conventional interpreted languages slow to execute. At the same time, there is no need for a skilled programmer to convert the resource data in to source code, and then to compile it and link it, before the prototype can be seen in action. These functions can be performed if necessary once the interface has been fully tested and finally determined, from the resource data stored on the disc 16.

For diagnostic purposes, the modules SIM may produce output via the host display 11, for example listing any commands as they are performed, listing the labels of objects as they are displayed, and so on. So that the interaction mode can be terminated, some input means other than the target input means 22, 24, for example the keyboard 12, can be used. It may be convenient if the facility is provided whereby pressing a certain key on the keyboard 12 causes the system to revert directly to the design state, and to activate the screen design module SCRD to allow immediate editing of the screen that was being displayed by the interaction modules SIM at the time when that key was pressed.

The screen displays reproduced in Figures 3 to 14 and Figure 17 of the accompanying drawings comprise works protected under the copyright law of the United Kingdom and other countries. The applicants hereby give notice that in filing this application they do not waive any copyright in these works except to the extent necessary for the reproduction and distribution of this patent specification as such.

From reading the present disclosure, many variations will be apparent to persons skilled in the art. Such variations may involve other features which are already known in the design, manufacture and use of command editors, authoring systems and component parts thereof and which may be used instead of or in addition to features already described herein. Although claims have been formulated in this application to particular combinations of features, it should be understood that the scope of the disclosure of the present application also includes any novel feature or any novel combination of features disclosed herein either explicitly or implicitly or any generalisation thereof, whether or not it relates to the same invention as presently claimed in any claim and whether or not it mitigates any or all of the same technical problems as does the present invention. The applicants hereby give notice that new claims may be formulated to such features and/or combinations of such features during the prosecution of the present application or of any further application derived therefrom.

Claims (20)

Claims

1. A command editor comprising means by which a program author can create a computer program in the form of a stored list of commands, each command being of one of a variety of command types each type being representable by a corresponding command name, at least one type of command requiring one or more parameters each being of one of a plurality of parameter types, parameters of at least one parameter type being representable by respective parameter names, the command editor comprising command entry means by which the author can select the command type and specify any required parameters to define a command to be included in the command list, characterised in that the command entry means includes:: - parameter menu display means for displaying to the author a menu including the said parameter names representing available parameters of the given parameter type; - parameter selection means by which the author can select a predefined parameter for inclusion in the command by pointing to the parameter name of that parameter on the displayed menu; and - means for activating the parameter menu display means in response to the selection of a command type requiring a parameter of the given parameter type.

2. A command editor as claimed in Claim 1 wherein the available parameters of the given parameter type include parameters having names defined by the author and the parameter menu display means includes means for displaying a menu including the said author-defined parameter names.

3. A command editor as claimed in Claim 1 or Claim 2 comprising parameter menu display means for more than one given parameter type, the activating means including means for activating each parameter menu display means in response to the selection of a command type requiring a parameter of the corresponding given parameter type.

4. A command editor as claimed in any of Claims 1 to 3 wherein the said activating means includes means for activating an appropriate alternative parameter entry means to enable the specification of a parameter of a parameter type, different to the or any of the given parameter types, for which no parameter menu display means is provided.

5. A command editor as claimed in any of Claims 1 to 4 wherein the activating means comprises: - means for displaying a representation of the command including a command name and representations of any parameters required but not yet specified; and - means by which the author can point to such a representation of a not yet specified parameter of the or one of the given parameter type(s) to initiate the activation of the appropriate parameter menu display means.

6. A command editor as claimed in any of Claims 1 to 5 further comprising: - command list display means for displaying to the author a representation of the commands so far included in the command list being created.

7. A command editor as claimed in Claim 6 further comprising: - command list editing means by which the author can delete or rearrange selected commands from the command list by pointing to the selected commands on the displayed representation of the command list.

8. A command editor as claimed in Claim 6 or Claim 7 wherein the displayed representation comprises lines of textual and ideographic information, each line representing one command.

9. A command editor as claimed in any of Claims 1 to 8 wherein the command entry means further comprises: - command type menu display means for displaying to the author a menu comprising command names representing the types of commands available for inclusion in the command list; and - command type selection means by which the author can select the type of a command for inclusion in the program by pointing to the corresponding command name on the displayed menu.

10. A command editor as claimed in any preceding claim further comprising: - tokenising means for storing the created command list in the form of a sequence of token values representing the command types and parameters making up the commands.

11. An authoring system for use in defining the user interface of a computer or computer-controlled apparatus (the target system), the authoring system including: - display design means for use by an author in defining graphic and/or textual items for presentation to a user by a display means of the target system; and - scripting means by which the author can define one or more scripts, each to be associated with a display item, the script comprising a list of commands defining a desired form of interaction between the target system and the user in association with the displayed item; characterised in that the scripting means comprises a command editor as claimed in any of Claims 1 to 10.

12. An authoring system as claimed in Claim 11 wherein, for a parameter type including display items, a menu displayed by a corresponding parameter menu display means includes automatically display item names defined by the author representing display items defined by the author using the display design means.

13. An authoring system as claimed in Claim 11 or Claim 12 comprising means for switching to a simulation mode wherein the operation of the target system under the control of the program being created can be simulated, the authoring system further comprising means for interpreting the stored script or scripts so as to perform functions simulating the operation of the target system under control of the user interface.

14. An authoring system as claimed in Claim 13 comprising target display simulation means for displaying the defined display items in a form identical or equivalent to that in which they would appear on a display of the target system.

15. An authoring system as claimed in Claim 13 or 14 comprising target input simulation means identical or equivalent to an input means of the target apparatus for controlling the simulated operation of the target system.

16. An authoring system as claimed in any of Claims 13 to 15 wherein the interpreting means includes: - means for storing a program routine for implementing each type of command included in the defined script or scripts in a coded form suitable for execution within the authoring system; and - means for identifying and causing the execution of the coded routines in accordance with the script, so as to simulate the interaction between the target system and a user in association with an item displayed by the target display simulation means.

17. An authoring system as claimed in Claim 16 wherein, before switching to simulation mode, the created command list is stored in the form of a sequence of token values representing the command types and parameters making up the commands in the created script, and wherein the interpreting means includes a table of pointers relating command type token values to memory locations of the coded routines for implementing the corresponding functions within the authoring system.

18. An authoring system as claimed in Claim 17 wherein for at least one type of parameter, the interpreting means includes a table of pointers relating parameter token values to memory locations of data defining corresponding parameters of the at least one type, and wherein, for a type of command including a parameter of the at least one type, the target system, under control of the corresponding program routine for implementing the said type of command, includes means for reading a parameter token value from the tokenised script and using the corresponding pointer from the said table to determine the location of the parameter data necessary for the implementation of the command.

19. A command editor substantially as described herein with reference to Figures 5 to 10, 12, 16 and 17 of the accompanying drawings.

20. An authoring system substantially as described herein with reference to the accompanying drawings.