Visual Command Sequence Desktop Agent

1. Field of the Invention

This invention relates generally to data processing. More particularly, this invention relates to graphical user interfaces. Even more particularly, this invention relates to a system and method of automating user commands input into a graphical user interface system.

2. Background of the Invention

Graphical user interfaces have improved the ease with which many tasks may be accomplished on a computer. In a traditional text-based user interface, a user would have to remember the file name and path of the application, and the arguments given to that application in order to execute it. In a graphical user interface, the user need only activate an icon that represents the application and select the arguments when prompted to execute that application. Since the properties assigned to the graphic icon link it to the executable file and specify its complete directory path, there is no need to memorize that information. Microsoft Corporation's WINDOWS.TM. and Apple Computer, Inc.'s MacIntosh.TM. operating systems are examples of successful graphical user interfaces.

Many computer users perform the same sequence of tasks repeatedly. For example, a software developer may repeatedly execute a sequence of three commands that compile a dynamically linked library (DLL), copy the DLL to another directory, and then execute a program. After running the program, debugging the DLL, and possible revising the source code of the DLL, the user may execute the same sequence of three commands that were executed previously. The above sequence of three commands each involve manual invocation through a series of mouse (or other pointing device) movements and button (or key) clicks. Since each command may take anywhere from several seconds, to several minutes to execute, the user is required to wait until each command completes before taking action to execute the next command. Furthermore, continual repetitions of these mouse movements and key clicks can contribute to repetitive stress injuries.

Accordingly, there is a need in the art for a method and system of automating command sequence input into a graphical user interface. It is desirable that such a method should not involve user intervention. Furthermore, such a method should be intuitive to even an unsophisticated user.

A part of the operating system, or a part of an application, or a separate low priority process, continually runs in the background of a computer and monitors the commands a user invokes. When a user invokes a command, that event is logged. The event log includes the command, the parameters passed to the command, and the date and time the command was executed. When the computer is mostly idle, the event log is analyzed for multiple instances of sequences, or patterns, of commands with the same parameters specified. If the number of instances of a sequence, or pattern, exceeds a specified threshold over a certain period of time, a dialog box is presented to the user. The dialog box asks the user if a shortcut script should be created for that sequence or pattern or commands and their parameters. If the user gives and affirmative response, an icon is placed on the computer desktop that, when chosen by the user, will execute those commands, with their parameters.

FIG. 1 is a block diagram of a computer suitable for use in implementing the present invention.

FIG. 2 is a block diagram showing the interconnection of some of the principle components inside the processor chassis of FIG. 1.

FIG. 3 illustrates the appearance of a desktop metaphor as used by a graphical user interface.

FIG. 4 illustrates the use of a pull-down menu as used by a graphical user interface.

FIG. 5 is a flow chart illustrating the steps to log visual commands and their parameters.

FIG. 6 is a flow chart illustrating the steps to create a command sequence shortcut script.

FIG. 7 illustrates an example of a dialog box that can be used to interrogate the user whether or not a shortcut script should be created.

FIG. 1 illustrates a computer 100 that is suitable for implementing the present invention. Computer 100 includes a chassis 102 containing one or more circuit boards (not shown), a floppy drive 112, and a hard drive 114. A representative block diagram of the elements included on the circuit boards inside chassis 102 is shown in FIG. 2. A central processing unit (CPU) 210 is connected to a system bus 214. System bus 214 also connects to memory 208 that includes both read only memory (ROM) and random access memory (RAM); a display interface 202 that controls monitor 106 to display images on screen 108; a hard drive and floppy drive interface 204 that controls hard drive 114 and floppy drive 112; a serial/mouse port that communicates with mouse 110 to allow the user to manipulate a cursor or other graphical objects; and a keyboard interface 212 that communicates with keyboard 104 to allow the user to enter text or keystroke commands. Although many other components of computer 100 are not shown, such components and their interconnection are well known to those of ordinary skill in the art. Accordingly, further details concerning the construction and composition of computer 100 and the circuit boards inside chassis 102 need not be disclosed with the present invention.

When the computer 100 is running, program instructions stored on a floppy disk in floppy drive 114, or on hard drive 114, or in memory 208 that comprise a graphical user interface (GUI) program are executed by CPU 210 causing the graphical elements that comprise the user's view of the graphical user interface to be displayed on screen 108. FIG. 3 shows the appearance of screen 108 with one possible graphical user interface displayed. The GUI displays a window 300 with a menu bar 301. Inside window 300 icons are displayed that each represent an object. For example icons 302, 303, 304, 305, 306, 307, and 308 are shown. Each of these icons represent a file, a program, a shortcut, a shortcut script, or a tool. For example, icon 308 represents an object called DEMO that is associated with a word processing program. Object DEMO may be opened by using mouse 110 to place cursor 310 over icon 308, and depressing a button on mouse 110 twice in quick succession.

Another way actions are accomplished by the user using a GUI is through the use of pull-down menu 301. This is illustrated in FIG. 4. Cursor 310 is first positioned on pull-down menu 301 over the desired class of actions and a mouse button depressed. In FIG. 4, the class of actions selected were the "Edit" commands. This causes pull-down menu 320 to appear. Pull-down menu 320 displays a number of possible commands, actions, or files that the user may select. The user then positions cursor 310 over the desired choice and depresses a mouse button. The GUI then takes the appropriate action in response to the user's choice.

As can be seen from the examples, above, many mouse button presses, and much positioning of the cursor may be required to execute even a simple command. Accordingly, many GUIs, such as Microsoft WINDOWS.TM., include the ability to create a shortcut. Shortcuts are quick ways to get to the programs and documents that are used often. For example, if the user creates a shortcut to run a word processor, an icon of a pen and paper will appear on the computer desktop displayed on the screen. Then, to run the word processor, the user just presses a mouse button twice while the cursor is over the pen and paper icon, and it will run the word processor. Alternatively, to edit a particular document in the word processor, the user may drag and drop the icon representing that document on the pen and paper icon, and the word processor will start up and load that document for editing. Shortcut scripts are different from shortcuts in that they may be used to execute many different kinds of commands, or automate long command sequences. However, shortcut scripts may be difficult to create, and may require programming knowledge uncharacteristic of an unsophisticated user.

Each series of user actions can be represented by a text based command and parameters. For example, take the following series of GUI operations performed by the user: (1) the cursor is placed over an icon that represents a file called "DEMO" and the mouse button is depressed once. This selects the file DEMO. (2) Then the command "Rename" is selected from a pull-down menu. (3) The user is prompted for, and supplies a new file name "REMO." This series of graphical commands can be represented by a single textual command to the disk operating system of "MOVE DEMO REMO". Of course, a textual form is not the only way to represent the command but is used here for illustrative purposes.

FIG. 5 is a flow chart that summarizes the steps that may be used to log GUI commands and parameters. All, or part, of these steps may be done by the GUI, the operating system, a low-level process running in the background, an application, or any combination of the preceding. In a step 500, the user's commands and parameters are monitored. In a step 502, each command and it's parameters are converted to text form. In a step 504 the text form of each command, and it's parameters, are stored in a log along with a time stamp indicating when the command was executed. This command log may be stored in memory or on a disk. Furthermore, in step 502 the command and it's parameters may be converted to some form other than a textual representation, such as a proprietary binary format, before being stored in the command log.

FIG. 6 is a flow chart that summarizes the steps that may be used to automatically create a command sequence shortcut script. In a step 602 a time interval is waited. This time interval may be measured in time units, or as a predetermined number of GUI commands. It may also be desirable to wait until the computer 100 is mostly idle so that the process to automatically create a shortcut script does not slow the execution of other computer tasks. In a step 604 the command log is examined for repeating sequences of commands and parameters, or patterns of commands and parameters. This may be done by successively taking each command and it's parameters in the command log and comparing it with every other command and it's parameters in the command log to see how many occurrences of that command and the same parameters has occurred. If a command with the same parameters has occurred more than a threshold number of times, the commands in the log that occurred within a few commands before, and a few commands after that command can be examined to see if those command have occurred in the same sequence and roughly the same number of times as that command. If they have, a repeating command sequence has probably been detected. The threshold number of times a command, or pattern of commands, must occur before it is considered a pattern may be initially set to a default value. However, it is desirable to let the user adjust that value through a variety of means that are well known in the art. Other methods of detecting repeating sequences, such as self-correlating the command log, are also well known in the art and as such, need not be further detailed here.

In a step 606, if a repeating sequence has not been detected, the process loops back to step 602 to wait a predetermined time interval. If a repeating sequence has been detected, step 608 checks to see if a shortcut script for the detected sequence has already been created. If it has, there is no reason to create another one and the process loops back to step 602 to wait a predetermined time interval. In a step 610, the user is asked if a shortcut script should be created for this command sequence. This step is optional. It is desirable, however, to ask the user if a shortcut script should be created so the user will not be surprised by the appearance of a new shortcut script icon, and to allow the user to avoid clutter on the screen.

FIG. 7 illustrates an example of a dialog box 330 displayed on screen 108 that can be used to ask the user if a shortcut script should be created for a command sequence. A textual representation of the command sequence 331 is displayed so the user may examine the commands that will be included in the shortcut script. The user may then choose to create a shortcut script by positioning the cursor over the "YES" button 333 and depressing a mouse button. Alternatively, the user may choose not to create a shortcut script by positioning the cursor over the "NO" button 334 and depressing a mouse button. Another alternative would be for the user to choose to edit the command sequence. This could be done by positioning the cursor over the "EDIT" button 335 and depressing a mouse button. The GUI would then allow the user to add, delete, or change the commands and parameters in the command sequence. The user would then be given the opportunity to make a shortcut script out of the modified command sequence.

In a step 612 if the user elected not to create a shortcut script, the process loops back to step 602 to wait a predetermined time interval. The process may optionally delete one or more instances of the command sequence from the command log so that the user will not be asked if a shortcut script should be created for that command sequence until that command sequence has been repeated more times. If the user elected to create a shortcut script, step 614 creates the shortcut script, and places an icon representing that shortcut script on screen 108. Once an icon representing a shortcut script is displayed on the screen, all the GUI commands that affect other types objects may be applied to the shortcut script. (i.e. it may be copied, moved, edited, deleted, etc.)

The above description is included to illustrate the preferred embodiments. It is not meant to limit the scope of the invention. The scope of the invention is to be limited only by the following claims. From the above discussion, many variations will be apparent to one skilled in the art that would yet be encompassed by the spirit and scope of the invention.