Process for Producing Human-Computer Interface Prototypes

Cross-reference to related applications U.S. patent application Ser. No. 163,391 filed Mar. 7, 1988 entitled USER INTERFACE MANAGER by D.J. Rosenberg; J.L. Underhill; W.C. Bubie; and A. Marcus.

A microfiche appendix comprising 33 fiche containing 1176 frames forms a part of this application.

A portion of the disclosure of this patent document contains material to which a claim of copyright protection is made. The copyright owner has no objection to the copying of the patent document or the patent disclosure, but reversed all other rights.

Appendix A--High-level graphics language code for drawing a line segment

Appendix B--Complete specification of data structures

Appendix C--Intermediate code specification

Appendix D--Code for calculator prototype

Appendix E--Code for swapping UNDO icon and LINE icon in FIG. 4

Appendix I--Complete specification of all high-level graphics language commands

Appendix II--Compiler written in C for compiling high-level graphics language

Appendix III--Multiple Manager/Interpreter written in C

Appendix IV--Object Manager written in C

Appendix V--Input and Display Manager written in C

Appendix VI--Graphics Editor written in high-level graphics language

The invention relates to a process for producing prototypes of human computer interfaces and more particularly to a process for transforming a high-level language description of such an interface into a series of machine executable steps that implement the prototype interface.

An important feature of any computer system is the interface between the computer and the human operator. The commercial success or failure of computer systems often is due in a large part to the ease with which a human operator can use the system. An example of such a success is the Macintosh (trademark of Apple Computer Inc.) line of personal computers. The Macintosh line of personal computers is successful primarily because the components and interaction techniques used to complete tasks on the computers are very consistent throughout the product line. In addition, the concept of a "desktop" environment is depicted graphically in a meaningful manner, making common software components such as windows and icons easy to comprehend. Users are much more apt to understand how to complete a task if the same user interface components and techniques are repeated in each software application.

In developing a human computer interface it is necessary to generate many prototype interfaces, and to test them for ease of use with human operators. Because a large computer program lies at the heart of any sophisticated human-computer interface, it is very costly and time consuming to develop even one such interface, let alone a variety of prototypes which can be compared to each other to determine which one is preffered. For this reason, tools have been provided to aid in the specification and production of prototype human-computer interfaces.

Prior prototyping systems were unable to describe asynchronous events while a program was running in the high-level language used to create the prototypes. Typically, if asynchronous events, such as control of the mouse, had to be handled as part of the prototype, programmers were required to define those asynchronous events in a low-level programming language or by using a separate prototyping tool. In addition, if asynchronous events had to be linked to an item on the screen, the asynchronous event was linked to the X and Y coordinates of the item. This meant that if the item was moved to a new X and Y coordinates had to be specified to re-link the asynchronous event to the item.

For example, the BLOX (trademark of Rubel Software Inc.) interface development tool, uses state tables to describe states, changes of state ("transitions"), and actions for transitions. Each state table includes a test with one or more possible outcomes; each transition includes a possible action and entry to a new state. Table 1 below is a listing of BLOX code which would typically be used to draw line segments on a workstation in an interactive graphics application:

(Not shown above is the code for the tests GetPointCoordinates or the routine for the actions DropThisPoint, RecordFirstPoint, and DrawThis Line).

Using this state table, two states are identified and named GETTHELASTPOINT. The first state waits for mouse input to identify the line start point. Once received, the table tests to see if this point is within the screen work area (in this case, a window). Two transitions are then described for this test: one to enter a new state if the point is outside the work area, and a second to record the line start position and enter a new state to obtain the line end position. The second state waits for mouse input to identify the line end point and then tests to see if it is within the work area. Two more transitions are then described for this test: one to enter a new state if the point is outside the work area, and a second to draw the line and return to the initial state, thus restarting the cycle.

In prior art prototyping systems, the graphic elements consisted of a bitmap or a display list of graphic objects. The program used to execute the prototype could only interpret a bitmap or a display list, but not both.

Thus it is an object of the present invention to provide a process for producing prototypes of human-computer interfaces that avoids the limitations of the prior art processes discussed above.

The object is achieved by describing an interface prototype in a high-level graphics language having commands to describe asynchronous events, and to link asynchronous events to graphic objects. The high level graphic language description is compiled in a compiler to produce an intermediate low-level code that is optimized for interpretation. The low-level code is interpreted to implement the prototype interface. According to a further feature of the process, a graphic display portion of the human-computer interface is managed such that the behavior of graphic objects follows the graphic objects as they are repositioned in a display.

FIG. 1 is a schematic diagram of a computer system useful for practicing the method of the invention;

FIG. 2 is a schematic block diagram showing the software modules employed in practicing the method of the invention;

FIG. 3 is computer screen display of a prototype interface generated according by the method of the invention;

FIG. 4 is a computer screen display of another prototype generated by the method of the present invention; and

FIG. 5 is a schematic block diagram of a display manager employed to practice one aspect of the present invention.

FIG. 1 is a schematic diagram of a computer system on which the method of the present invention may be performed. A Microvax GPX II* or VAX II* computer 2, running the VMS* operating system, is used to store, process, and manipulate data (* registered trademarks of Digital Equipment Corporation). The Microvax computer contains a 72 Mb disk drive (not shown) and connects to a display terminal 4, which is typically a workstation with windowing capabilities. User inputs are accepted from a keyboard 6, a mouse 8, a digitizer puck 10, or a digitizer pen 12. Hardcopy output can also be directed to a printer 14.

This invention can run on other types of hardware; however, alterations must be made to the input/output functions of the workstation graphics software to accommodate the new devices.

The process employs a specialized high-level graphics language described below. This language provides great flexibility and ease in describing asynchronous events, linking them to screen items, and changing basic interface characteristics during program execution.

The high-level graphics language is structured as shown in Table 2. This language consists of a main section and optional procedures that follow. The main section begins with the statement begin main. and ends with the statement endmain. Any number of statements, consisting of commands, procedure calls, or comments, can fall between the two main statements. In this language, all variables are global and comments can be placed anywhere.

A complete specification of all the commands employed in the high-level graphics language is contained in Microfiche Appendix I. Table 3 depicts the types of control statements typically used in the high-level graphics language.

In comparison to prior systems, the high-level graphics language used in this invention simplifies the description of an asynchronous event while the program is executing. A typical asynchronous event is the need to write code so that if the screen is scrolling information and a user presses a mouse button, the terminal "beeps" to indicate an invalid entry. The high-level graphics language allows programmers to write code easily and in a more natural language to handle asynchronous events: prior systems required that programmers resort to a low-level language or another prototyping tool to write such code. Asynchronous events are both created and linked to a specific behavior using the high-level graphics command SETUP. A typical SETUP command is shown in table 4:

To activate this condition, the START command is used as shown in table 5:

To stop the condition from executing, the STOP command is used as shown in table 6:

Appendix A contains a listing in the high-level graphics language describing a typical asynchronous event: drawing a line segment on a workstation in an interactive graphics application.

The process according to the present invention makes use of a unique data structure to allow programmers to link an asynchronous event to a specific item the description of the asynchronous event; on the screen by storing the item and the behavior of the object in response to the event as a single object, regardless of the X and Y location of the item on the screen. For example, a circle drawn on the screen is defined as Graphic Object Type A and an alarm should sound when an asynchronous event, such as clicking the mouse, occurs. In this invention, all of this information is defined by the high-level graphics program and stored as one object. If the circle is moved to new X and Y location at some future data, the code used to handle the asynchronous event remains linked to it.

The unique data structures also permit image (bitmap) files and display list (graphic) files to be stored in the same database and assigned the same "object" characteristics. This differs from prior system where graphic files were stored as bitmaps or display lists in the database and treated only as bitmaps or display lists by the system. In addition, the high-level graphics language of this invention treats "objects," whether bitmaps or graphic objects, in exactly the same manner during program execution. Table 7 below depicts a typical object data structure used for images in this invention; complete data structures are listed in Appendix B.

FIG. 2 is a schematic block diagram showing the software modules employed in practicing the present invention. Initially, a standard text editor 16, such as EDT Editor* (*registered trademark of Digital Equipment Corporation), is used to create the high-level graphics language source code 18, needed to execute the prototype. Once code is created, it is sent through the high-level graphics language compiler 20, and the code is debugged if necessary (not shown). Microfiche Appendix II lists a compiler written in C for use on the Vax computer to compile the high-level graphics language.

The compiler 20 transforms the high-level graphics language program into the intermediate, low-level code 22, needed to execute the prototype. The compiler 20 first divides the high-level graphics language program into tokens of the language, such as numbers, commas, variables, and test strings. These tokens are then used to drive a parser portion of the compiler (not shown). The parser interprets the tokenized code, generates the intermediate low-level code, and writes it out to an intermediate code file (not shown).

The compiler uses two standard UNIX tools: LEX (to tokenize, or perform the lexical analysis and manipulate the symbol tables) and YACC (to provide the grammer of the high-level graphics language and the necessary semantic actions). For a complete description of the compiler tools LEX and YACC, refer to Principles of Compiler Design by A. Aho and J. Ullman, 1977, Bell Laboratories, ISBN -0-201-00022-9.

The resulting intermediate, low-level source code 22, is run to execute the prototype. A complete code specification for the intermediate low-level code is shown in Appendix C.

The process described thus far depicts a typical development environment. To execute the prototype in a runtime environment, the system employs a multiple task manager/interpreter 24. This manager/interpreter executes and coordinates all activity for the input and output devices and handles database access. A listing of computer code written in C for the Vax computer for implementing the manager/interpreter is contained in Microfiche Appendix III.

The manager/interpreter 20 is comprised of two parts: a scheduler and an interpreter. The scheduler keeps track of various tasks running at the same time in the multi-tasking environment of the prototyping system. When a task is begun, the scheduler reads in the intermediate code produced by the compiler during a process called "Readfile." If a program is currently being read, the scheduler stacks the new task code to be read later.

If more than one task is running at a time, the scheduler cycles through each active task by executing one line of code from each and passing the code to the interpreter. Depending upon the statement being executed, tasks can take several states as shown in table 8:

Between active task cycles, the scheduler also handles incoming mail from two mailboxes. High priority mail in the hpidptotp mailbox consists of special key handling; low priority mail in the 1pidp totp mailbox consists of information sent from the input manager in response to requests from the task manager.

The scheduler buffers low priority mail for use by the interpreter and changes task states accordingly. In general, all of the W<states>listed above are waiting for low priority mail. When it is received, the task state is reset to ACTIVE and the program counter is reset to the command that caused the W<state>. This is done because these types of statements are processed in two parts: the first time they are interpreted, an information request is made, and the second time they are interpreted, information returned and buffered by the scheduler is processed.

High priority mail comes from the input manager 28 and handles soft-key user input. The scheduler checks the high priority mailbox and completes all soft-key requests in the mailbox before continuing. Soft-key requests are listed in Table 9:

The interpreter receives one line of code at a time from the scheduler and determines if it is a control statement or a reserved word statement. Control statements are handled only by the interpreter. Reserved work statements are sent to object manager 26, for execution. In addition, appropriate variables are updated by the task manager. The display manager 30 implements the linkage between a graphic object and a type of behavior. Though the high-level graphics code is written to describe a linkage between an object and its behavior, the actual process occurs in the display manager as intermediate code is executed. This linkage allows programmers to reposition graphic objects on the screen and have the object's behavior accompany the object. A program for implementing the object manager 26, written in C for the Vax computer is included in Microfiche Appendix IV.

The display and input managers are structured as separate system elements; however, they are implemented as a single element. A program for implementing the input manager 28, and the display manager 30, written in C for the Vax computer is included in Microfiche Appendix V.

To handle user input, the system receives input from standard input device drivers 32, which may be connected to a mouse, keyboard, digitizer puck, or digitizer pen. This information is passed to the input manager 28, and then to the multiple task manager/interpreter 24, for processing. To send data to users, the multiple task manager/interpreter 24, passes information to the display manager 30, and on to standard output device drivers 34. The output device drivers are typically connected to a monitor or printing device (not shown in FIG. 2).

The graphic objects data base 36 is accessed by one of two editors. A standard bitmap editor 42, is used to create image files 38, for small, detailed images such as icons or foreign language characters. A graphics editor 44 is used to create graphic files 40, such as large screen displays. A program for implementing graphics editor 44, written in the high-level graphics language of the present invention, is included as Microfilm Appendix VI. Both types of objects generated by bit map editor 42 and graphics editor 44 are stored as graphic objects in the database 36, and are treated as objects by the object manager 26. Complete data structures for specifying graphic objects are listed in Appendix B.

FIG. 3 shows the display screen of a prototype interface that was produced using this invention. This figure depicts a calculator prototype with graphics (boxes) 45 and text (numbers and letters) 47 on the same screen. The high-level graphics code used to create this prototype is listed in Appendix D.

FIG. 4 shows the display screen of another type of prototype interface that was produced using this invention. This figure displays the interface with the graphics editor 44 used to create graphics in the system. Text (names) 46,48 and graphics (icons)50, 52 are integrated on the same screen, and windows are available for data manipulation. The high-level graphics code used to create the graphics editor 44 and including code to implement this interface is included in Microfiche Appendix VI.

Referring to FIG. 5, the graphics editor 44 consists of four primary blocks: a declaration block 54, where all variables are declared and set to specified or default values: a retrieval block 58, where stored graphic objects are retrieved and positioned for display on the screen; an AST asynchronous event) definition or setup block 56, where the behaviors of objects are described and linked to objects; an activation block 60, where the behaviors or actions are started; a hibernation block 62, where the interface prototype is put into a sleep state while awaiting the occurrence of a defined event to wake up and execute the action; and an AST Execution block 64. When the system is "hybernating", and a user actuates a mouse 66, the condition names in the AST/Setup block 56 is executed by the AST Execution block 64. The system then "hybernates" until further user input is received.

The graphics editor in this invention allows programmers to "swap" the positions of graphic icons at the top of the display. Not only do the positions of the icons change, but all functionality associated with the icon goes with it. In FIG. 4, to swap the positions of the UNDO icon, 46, and the LINE icon, 48, a programmer simply clicks the mouse button over the "SWITCH" icon, 50, and then clicks once on each of the icons to be swapped. A listing of high-level graphics language code, demonstrating how this is done is included in Appendix E.

This invention significantly reduces the time and effort required to produce a protoype because all of the programming can be done in the high-level graphics language used to execute the prototype. Prior systems required programmers to move between high- and low-level programming languages or other prototyping tools to execute such routine functions as asynchronous event handling.

This invention also accesses a central graphic object database that contains both bitmap and graphic object files with unique characteristics. Instead of treating these object types differently, depending upon the characteristics associated with them, this invention treats them all as "objects," resulting in both simplified program execution and extended functionality.

The high-level graphics language is also powerful enough so that prototype interfaces can be dynamically changed during runtime. Graphic objects and the behavior associated with them can be described by the high-level graphics language of the invention. Behaviors are physically linked to the data structure of a graphic object when the intermediate code is interpreted by the display manager. For example, the graphics editor used in this invention is written in the high-level graphics language. As programmers create graphics with the graphics editor, they can change the characteristics and behavior of the graphics editor itself without leaving the runtime environment of the graphics editor. This increases the speed at which graphics can be produced because interface modifications can be made as the editor is running.

The high-level graphics language used to execute a prototype also surpasses prior systems by linking asynchronous events with a specific screen item and storing them as one object, regardless of the item's X and Y position on the screen allowing the item's position to be changed without redefining a new X and Y location for the asynchronous event.