WO2004095415A1

WO2004095415A1 - Dialog window button proxies near cursor

Info

Publication number: WO2004095415A1
Application number: PCT/US2004/012659
Authority: WO
Inventors: David A. Yost
Original assignee: Yost David A
Priority date: 2003-04-23
Filing date: 2004-04-22
Publication date: 2004-11-04

Abstract

The present invention enhances the Graphical User Interface (GUI) of a new or existing application program (including operating system application programs) when a dialog window appears (item 12). It does so by providing a convenient auxiliary Control Window containing conveniently-placed proxy buttons (item 16) near the user's cursor which operate corresponding buttons in the dialog window and which are visually connected to the buttons in the dialog window by a transparent beam of colored light (item 18) in a graphics drawing layer just behind the buttons (item 23). The system provides for situations in which an application programmer wants explicitly to provide the layout of affected buttons for the Control Window as well as for situations in which the application programmer has not provided for this new functionality in any way.

Description

low Dutton proxies near cursor

Inventor David Arthur Yost, 1218 Payne Drive, Los Altos, CA 94024-5724 USA

Related Application

This application is related to U.S. Provisional Patent Application Serial Number 60/465,129, filed April 23, 2003, and entitled "System and method for enhancing the usability of a dialog window by providing an auxiliary window containing conveniently-placed proxy buttons near the user's cursor which operate corresponding buttons in the dialog window", incorporates such application hereinto in its entirety by reference, and claims priority thereto.

Technical Field

The invention is related to software user interface windows, and especially to dialog windows, alert windows, drop-down "sheet" windows, and other windows with the purpose of asking a question of the user or informing the user of something that requires an answer or acknowledgment; to the visual presentation of the dialog information and/or question and user response mechanisms; to user input gestures to answer or acknowledge the dialog window's information and or question using a mouse, other pointing device, or keyboard, for example by the clicking of a GUI button or typing a key on a keyboard; and to the supplying of supplementary "proxy" buttons near the cursor which operate similarly to the actual buttons in the dialog window.

Background of Invention

A typical occurrence in Graphical User Interfaces is for the software to display (or "pop up") a so-called Dialog Window whose purpose is to ask a question of a user, which the user typically must answer or dismiss by clicking a UI button or typing a key which has been designed to have an equivalent effect to clicking one of those buttons. Sometimes but not always, the user is prohibited from taking some or any other action until they have answered the question posed by the Dialog Window. The question may be merely a request for acknowledgment of information given in the dialog window, the response typically being the activating of a button, typically named "OK".

The Kensington MouseWorks system enhancement (later referred to as the "warped cursor" approach) works thus: when a window containing a default button is displayed, MouseWorks mores the cursor (without any user gesture) to the default button (a default button is one that is invokable by hitting the Return key). The MouseWorks approach has three disadvantages:

• It takes the cursor, which is usually totally under user control, and suddenly moves it across the screen without warning. This action violates the user control over the mouse and is disruptive.

• If MouseWorks moves the mouse just as you were about to click something, you end up clicking the dialog window's default button instead, with potentially disastrous effect. The present invention is less susceptible to this problem because it requires you to move the cursor a bit before a click will have the possibly-accidental effect of activating a button in the dialog window.

• After MouseWorks has jerked the cursor over to the dialog window and you've clicked, the cursor is still there, and typically you have to move it back again to where you were working.

Microsoft Windows 2000 (and later and possibly earlier versions) offers this same capability as offered by Kensington MouseWorks. Technical Problem

A pop-up dialog window is a disruption. To deal with the disruption, the user must move the mouse away from where he's working to one of the buttons on the dialog window, or he must switch from the mode of using the pointing device to using the keyboard, often by moving the pointing device hand to the keyboard and back again to the pointing device.

The dialog window is traditionally placed in the center of the screen, regardless of where the cursor is; thus, the dialog window buttons are usually not near the cursor. Placing the dialog window behind the cursor is not a good solution.

The problem is to minimize the disruption caused by the distance f om the cursor to the dialog window buttons.

Technical Solution

The invention eases the disruption of a dialog window by offering additional copies of the dialog window buttons (proxy buttons) very near to the cursor.

In case even this attempt by the invention to be helpful may be regarded as an unwanted intrusion, the invention is ready and willing to get out of the way; while the invention is displayed, all other user input gestures, including but not limited to moving the cursor a small distance away from the proxy buttons, clicking a pointing device button or a keyboard key, will force the invention immediately to cease its intervention and hide its visual representations. In the preferred embodiment, this evasive action by the user is not consumed by the invention but rather will have its usual effect, for example a clicking of the mouse. Advantageous Effects

Since the invention's proxy buttons are very close to the cursor, it is easy for the user to move the mouse to one or the other of them and click it. This action is generally far easier than moving the cursor to the actual dialog window buttons, and easier than interrupting normal pointing device use to type a key on the keyboard.

Since any other user input gesture forces the invention to cease its intervention and to withdraw its visual representation, and furthermore such an input gesture will nevertheless have its normal effect with respect to other graphical representations on the display, the invention avoids compounding the dialog window disruption with its own action.

The failure mode of the "warped cursor" approach is that the user decides to click something on the display, and before he has a chance to complete this action, a dialog window appears, and the cursor is summarily moved ("warped") over to the default button of the dialog window, thus interpreting the user's click as a click of a newly-appeared button on the dialog window. The invention does not have this failure mode. The worst case for the invention would be if the user happens to be moving the mouse in the direction of something to click, and that something is then covered by a proxy button. The probability of this failure mode is considered to be so low as to be inconsequential, and besides, the invention can be implemented such that a timeout mechanism prevents even this eventuality.

Description of Drawings

Figure 1 shows a typical example, in the initial state: a display with no windows visible. Cursor is at lower left.

Figure 2 shows a typical example, but with the invention inactive or not yet visible. Figure 2 is like Figure 1 except that a single dialog window is visible. The dialog window has a Cancel button and an OK button. The cursor is far away from the buttons. The invention is not active.

Figure 3 shows a typical example with the invention active and visible. Figure 3 is like Figure 2 except that the invention is active, displaying a light beam from the dialog buttons extending downward toward small proxy Cancel and OK buttons placed near the cursor by the invention.

Figure 4 is like Figure 3 except that invisible outlines of some user interface objects are elucidated.

Figure 5 is like Figure 3 except that outline of the Light Beam is elucidated.

Figure 6 shows a window other than a dialog window: a web browser window with two buttons in it. The invention is displaying a Light Beam extending to two small proxies of those buttons.

Figure 7 shows the Window Helper process steps.

Figure 8 shows the Make Control Pad process steps.

Figure 9 shows the make Control Window process steps. Figure 10 shows the Handle Events process steps.

Best Mode

The User Experience

Figure 1 shows the initial condition before a typical Graphical User Interface dialog window is displayed.

A Graphical Display (outline: 10) with the Cursor (11) at lower left.

Figure 2 shows an example of an application displaying a dialog window, without the action of the invention.

While the cursor (11) is at lower left on the Display (10), the Target Window (12) has appeared, with its Interesting Buttons (22) — interesting because clicking them will close the window.

Figure 3 shows the invention in action.

Figure 4 shows the outline of some of the objects in Figure 3 which are invisible.

The opening of the Target Window (12) has triggered the Window Helper process to create and display a borderless, partially-transparent Control Window (20) in a layer in front of the Target Window (12) and in front of all other windows on the Display (10). The Control Window contains these elements: • Interesting Button Copies (23), which are copies of the Interesting Buttons (22,

Figure 2)

• Control Pad (24) (transparent), which contains the Interesting Button Copies (23)

• Proxy Buttons (16), which are proxies for the Interesting Buttons (22, Figure 2) in the Target Window (12) • Remote Control Pad (14) (transparent), which contains the Proxy Buttons (16) • Light Beam (18), a partially-transparent beam of colored light connecting the Control Pad (24) with the Remote Control Pad (14). The Light Beam is in the rearmost layer of the Control Window; the Proxy Buttons and the Interesting Button Copies are in the front most layer.

To construct the partially-transparent, borderless Control Window (outline: 20), the Window Helper process of the invention first identifies the Interesting Buttons (22) in the Target Window and makes a Control Pad (24), which is a transparent, rectangular container just large enough to enclose the Interesting Button Copies (23), which it makes to look exactly like the Interesting Buttons (22). The Window Helper then makes the Remote Control Pad (14), patterned after the Control Pad and its contents and decides the position of the Remote Control Pad relative to the Cursor (11). Finally, the Window Helper constructs the Control Window (20) to be just large enough to contain the Control Pad (24) and the Remote Control Pad (14). The Control Window's size and shape is also just sufficient to include the Light Beam (18). Figure 5 shows the outline of the Light Beam (18).

When the Control Window has appeared, the user can very easily move the cursor the short distance toward the Remote Control Pad (14) and click on one of its Proxy Buttons in lieu of moving the cursor even farther to click one of the Interesting Buttons (22) in the Target Window (12). Alternatively, the user can make the Control Window (20) disappear

• by moving the cursor away from the Remote Control Pad (14), or

• by clicking other than on one of the Proxy Buttons (16).

hi the preferred embodiment, a click that makes the Control Window disappear is delivered to the target object underneath it as it would be delivered if the Control Window did not exist, thus minimizing any disruption to the flow of the user's work.

Keystrokes typed by the user while the Control Window is displayed are delivered effectively as if the Control Window did not exist, typically to the Target Window. Figure 6 shows a web browser example in which this would be useful. In the web browser example in Figure 6, the Light Beam (18) (along with everything in it) stays visible even as the user types text into the Text Field (26) in the Target Window (12) on the Display (10). Because the Control Window remains intact after the user is finished typing text, the invention affords the user the option of clicking a button near the cursor on the Remote Control Pad.

System preparation

Software implementing the invention must be in place for the invention to work. There are two nonexclusive possibilities:

• The software can be added to an application by the application's developer.

• The software can be added to the UI toolkit software that is used by applications and also possibly added to the platform's Window Server or other Operating System components.

Application preparation

The system can work without any special preparation by the application programmer. However, an application programmer can exert more fine control over how the system works by programming some of the windows of the application to specify exactly how they will work with the system. There are two optional steps for each window in the application a. (optional) Make a call to the UI toolkit that explicitly designates this window as a Prepared Window. A Prepared Window explicitly designates whether the window should be subject to the effects of the invention or not. b. (optional) If (a) has been programmed for this window, then in the preferred embodiment of the invention, use the existing facilities of the UI toolkit software to place the Interesting Buttons in a container (known in various UI toolkits as a view, a panel, or a canvas) and give distinctive names to the container and each button within the container, then communicate to the enhanced UI toolkit software that implements the invention the identifier of the container and the identifier for the window to which it belongs.

User preparation

The operation of the Window Helper can be made optional by the user, and its parameters can be made adjustable by the user. Adjustable parameters could include

• Preferred Light Beam display characteristics, including o color o texture o transparency

• Preferred Distance of the Remote Control Pad Relative to the Cursor (integer). In the preferred embodiment, this distance is 4 pixels.

• Orientation Preference (integer) - where to put the center of the Remote Control Pad relative to the Cursor in degrees of rotation from East. In Figure 3, which displays the preferred embodiment, the orientation of the center of the Remote Control Pad with respect to the Cursor is 90 degrees (i.e. directly above the point of the Cursor).

• Orientation Varies (boolean) - whether the Orientation Preference should vary with the direction from the cursor to the Control Pad. In the preferred embodiment, the Orientation Varies option is false.

• Disappearance Time Delay (integer) - a time delay after which the Control Window will disappear if there is no mouse activity toward it (0 signifies infinite delay). In the preferred embodiment, Disappearance Time Delay is 0 (signifying infinite).

• Remote Control Pad Overlaps Dialog (boolean) - whether to allow the Remote Control Pad to appear in a position that overlaps with the Target Window. In the preferred embodiment, Remote Control Pad Overlaps Dialog is true. Operation

The Window Helper process (Figure 7)

The Window Helper process is the heart of the system. It makes the system visible to the user and interacts with the user. The Window Helper is in Waiting State (inactive) until it triggered into action (Step 7-1).

7-1. When a window appears, the Window Helper is triggered into action. Go to Step 7-2.

7-2. Determine if the Target Window is a Prepared Window, i.e. a window that the application programmer has programmed to explicitly specify its behavior with the Window Helper. If Yes, go to Step 7-3; if No, go to Step 7-13.

7-3. Determine if the application programmer has enabled this window for use with the Window Helper.

If Yes, go to Step 7-4; if No, go to Step 7-15.

7-4. Determine if the window has a ready-made Control Pad, provided for it by the application programmer.

If Yes, go to Step 7-5; if No, go to Step 7-13.

7-5. Get the Control Pad provided for the window by the application programmer. Go to Step 7-6.

7-6. Determine if the cursor position is ?far enough away?. The cursor is ?far enough away? in the preferred embodiment if the Cursor is in such a position that the Remote Control Pad will not overlap the Control Pad. Another possible definition of ?far enough away? is that the Cursor is in such a position that the Remote Control Pad will not overlap the Target Window. User preferences or implementation choice may further require that the Cursor be some additional small distance further away from the Control Pad or the Target Window, depending on which object is being avoided. If Yes, go to Step 7-7; if No, go to Step 7-17.

7-7. Invoke the Make Control Window procedure (Figure 9). Go to Step 7-8.

7-8. Determine if the Make Control Window procedure succeeded. If Yes, go to Step 7-9; if No, go to Step 7-18.

7-9. If the Make Control Window procedure succeeded (8 -> Yes), display the Control Window. Go to Step 7-10.

7-10. Invoke the Handle Events procedure (Figure 10). Go to Step 7-11.

7-11. Remove the Control Window from the Display. Go to Step 7-12.

7-12. The Window Helper goes back to Waiting State.

Done.

7-13. Invoke the Make Control Pad procedure for this window (Figure 8).

Go to Step 7-14.

7-14. Determine if the Make Control Pad procedure was successful in making a Control Pad. If Yes, go to Step 7-6; if No, go to Step 7-16. 7-15. The application programmer has programmed the window to be a Prepared Window and has specifically disabled the Window Helper to operate with it (3 -> No). Done.

7-16. The Make Control Pad procedure (13) was not successful (14 -> No). Done.

7-17. The Cursor is not "far enough away" (6 -> No). The Window Helper takes no further action.

Done.

7-18. The Make Control Window procedure failed (8 -> No). The Window Helper takes no further action. Done.

Additional considerations:

1. If the Subject Application is deactivated while the Window Helper process is in progress, the Window Helper process immediately removes anything it has displayed on the Display and reverts to Waiting State.

2. If the Target Window closes while the Window Helper process is in progress, the Window Helper process immediately removes anything it has displayed on the Display and reverts to Waiting State.

The Make Control Pad process (Figure 8)

The Make Control Pad process is invoked dynamically if necessary to make a Control Pad for a window that was not prepared with a designated Control Pad by the application programmer. This process also determines if the window is appropriate for use with the Window Helper. If the window is not appropriate, the process returns with a failure indication.

8-1. Begin.

Go to Step 8-2.

8-2. Determine if the window is used modally. In the preferred embodiment, this test is available and is used, but in other implementations, it may not be possible to make this determination, so this step is skipped and the flow goes to Step 8-8.

If Yes, go to Step 8-3; if No (or feature not implemented), go to Step 8-8.

8-3. Determine if there are buttons in the window.

If Yes, go to Step 8-4; if No, go to Step 8-10.

8-4. If there are buttons in the window (3 -> Yes), assume all of them are Interesting Buttons (i.e. ones that will close the window) and make a list of them. In the preferred embodiment, the toolkit has a way for the programmer to designate which buttons are capable of causing the window to close; with such a toolkit, if the implementation software can determine that all such buttons have been so designated by the programmer, the set of Interesting Buttons is restricted to the buttons so designated. Go to Step 8-5.

8-5. Make a Control Pad container (known in various UI toolkits as a view, panel, or canvas) containing Interested Button Copies such that if the container were overlaid on the window at the appropriate place its buttons would have the same size, shape, and position as the Interesting Buttons, and the Control Pad would be just large enough to enclose the container's buttons. In the preferred embodiment, the Interesting Button Copies also have the same highlighting and animation as the Interesting Buttons. Go to Step 8-6. 8-6. Make a Control Pad Controller object that has methods to invoke each of the button press actions of the Interesting Buttons in the Target Window. Each Proxy Button of the Remote Control Pad will invoke its corresponding method of this controller. Go to Step 8-7.

8-7. Success. Return the Control Pad to the caller. In the preferred embodiment, this window is now marked as if it were a Prepared Window, it is enabled for use with Window Helper, and the dynamically-created Control Pad is cached for use the next time this window is made visible.

Done. Return with a Success indication.

8-8. Determine if the window has an enabled close box in the title bar of the window. If yes, then we assume that the window is not functioning as a modal dialog. An implementation may choose to omit this step and go to Step 8-3.

If Yes, go to Step 8-9; if No, go to Step 8-3.

8-9. If the window has a close box (8 -> Yes), the Make Control Pad process assumes that the window is not dismissed via a button. Done. Return with a Failure indication.

8-10. If the window has no buttons (3 -> No), the Make Control Pad process assumes that the window is not dismissed via a button.

Done. Return with a failure indication.

Make Control Window process (Figure 9)

The Make Control Window process uses the Control Pad's absolute position on the Display and the Cursor's absolute position on the Display is to make the Control Wmdow ad hoc. h the preferred embodiment, the system maintains only one Control Window, which is reused each time and reconfigured to match the new situation, but functionally it is as if the Control Window were made and disposed each time.

9-1. Begin. Go to Step 9-2.

9-2. Make a Remote Control Pad from the Control Pad. In the preferred embodiment, the Remote Control Pad, including its Proxy Buttons, is a copy of the Control Pad except that the dimensions of the control pad and its contents are 1/2 those of the Control Pad. The properties of the Proxy Buttons are the same as the properties of the Interesting Buttons, including highlighting, animation, and designated activation keys, if any. Go to Step 9-3.

9-3. Make a Remote Control Pad Controller that will respond to each button press in the Remote Control Pad by invoking the correspondmg action in the Control Pad Controller. Go to Step 9-4.

9-4. Determine the Display position of the Remote Control Pad thus: place the center of the Remote Control Pad on a line at the preferred orientation angle with respect to the Cursor such that the point of the Cursor is separated from the nearest point in the Remote Control Pad by the Preferred Distance of the Remote Control Pad Relative to the Cursor. In the preferred embodiment, the center of the Remote Control Pad is directly above the point of the Cursor, and the bottom of the Remote Control Pad is 4 pixels above the point of the Cursor.

If the calculated position would leave some of the Remote Control Pad beyond the left or right edge of the Display, then the Remote Control Pad position is adjusted so that the Remote Confrol Pad just touches the edge of the Display; in this case, the angle from the center of the Remote Control Pad to the point of the Cursor is allowed to deviate from the Orientation Preference angle. If the calculated position is such that the top of the Remote Control Panel would extend beyond the top of the Display, then the position is considered not to be 'suitable' (see Step 9- 5); otherwise the position is 'suitable'. In the above discussion, 'Display' means the combined area of all display screens used in conjunction. If the chosen Orientation Preference angle is not (as in the preferred embodiment) 90 degrees, the features described in the above process are modified accordingly. Go to Step 9-5.

9-5. Determine if Step 9-4 noted that the position calculated is 'suitable'. If Yes, go to Step 9-6; if No, go to Step 9-12.

9-6. If the position is suitable (5 -> Yes), make a Control Window sized and positioned so it is just big enough to contain the Control Pad and the Remote Control Pad. The window has no title bar and no borders; therefore its underlying overall rectangular shape is not apparent, with the Control Window's contents appearing as a non-rectangular, free-floating Light Beam containing buttons.

Go to Step 9-7.

9-7. Add the Control Pad to the Control Window if the Control Pad was created dynamically by the Make Control Pad process invoked by the Window Helper; otherwise, add a copy of the Target Window's (prepared) Control Pad to the Control Window. Position the Control Pad so that it exactly overlays the over the Interesting Buttons of the Target Window. Go to Step 9-8.

9-8. Add the Remote Control Pad to the Control Window. Go to Step 9-9.

9-9. Make the Light Beam object. Its shape is such that it fills the Remote Control Pad, the Control Pad, and all points in between. More exactly, its shape is the locus of points on all lines connecting every point on the perimeter of the Remote Control Pad to eveiy point on the perimeter of the Control Pad. The Light Beam object fills its area with a color or pattern, mixed transparently with the underlying colors on the Display. See Figure 5, callout 18.

In the preferred embodiment, the Light Beam is displayed with an opacity of 40%, meaning that its pixels are mixed in with the Display pixels behind it such that 40% of the value of a Light Beam pixel is mixed with 60% of the value of the corresponding color at each pixel location. Also in the preferred embodiment, the Light Beam is appears as a bundle of beams of blue light whose lightness varies across the beam to resemble sunbeams coming from clouds such that the sunbeams narrow toward the Remote Control Pad, connecting equivalent parts of the Control Pad to their equivalent parts in the Remote Control Pad as in Figure 3.

Optionally, the Light Beam can be animated, perhaps suggesting motion from the Remote Control Pad to the Control Pad. For example, the coloration can be varied in waves that slowly travel in that direction along the beam. Go to Step 9-10.

9-10. Add the Light Beam object to the Control Wmdow in the graphics drawing layer directly behind the Remote Control Pad and the Control Pad.

Go to Step 9-11.

9-11. Return the Control Window to the caller.

Go to Step 9-12.

9-12. The position arrived at in Step 9-4 is not 'suitable'. Done. Return with a failure indication to the caller.

The Handle Events process (Figure 10)

The Handle Events process operates while the Confrol Window is visible. 10-1. Begin

Go to Step 10-2.

10-2. Wait for a user input event. Go to Step 10-3.

10-3. Determine if the event is a mouse event.

If Yes, go to Step 10-4; if No, go to Step 10-6.

10-4. The event is a mouse event (3 -> Yes). Determine if it is motion only (no button activity).

If Yes, go to Step 10-5; if No, go to Step 10-9.

10-5. The event is a mouse motion event with no buttons pressed (4 -> Yes). Determine if the motion is toward the Remote Control Pad or if the Cursor position is within the Remote Control Pad.

If Yes, go to Step 10-2; if No, go to Step 10-14.

10-6. The Event is not a mouse event (3 -> No). Determine if it is a keyboard event. If Yes, go to Step 10-7; if No, go to Step 10-8.

10-7. Determine if the keyboard event is Return or Esc. If Yes, go to Step 10-13; if No, go to Step 10-8.

10-8. The event is either from a device other than a pointing device or keyboard (6 -> No) or it is a keyboard event other than Return or Esc (7 -> No). Pass the even back to the system to deliver as it would have done were the Handle Events process not active. Go to Step 10-2. 10-9. The event is a mouse event involving clicking (4 -> No). Determine if the event is within the Remote Control Pad.

If Yes, go to Step 10-10; if No, go to Step 10-14.

10-10. The event is within the Remote Control Pad (9 -> Yes). Determine if the event is a click on one of the Proxy Buttons.

If Yes, go to Step 10-8; if No, go to Step 10-2.

10-11. The event is a click on one of the buttons (10 -> Yes). Invoke the appropriate button action in the Remote Confrol Pad Controller. Go to Step 10-12.

10-12. The Handle Events process is finished.

Done.

10-13. If one of the Proxy Buttons is designated to be activated by the key event, call the Control Pad Controller method appropriate for the key and return to the caller.

Go to Step 10-12.

10-14. The event is a mouse event that either moved the cursor away from the Remote

Control Pad (5 -> No) or clicked somewhere other than on one of the Proxy Buttons (9 -> No). Pass the even back to the system to deliver as it would have done were the Handle Events process not active. Go to Step 10-12. Industrial Applicability

The invention can be implemented in a computer operating system, in a GUI software library, or in a specific application program.

Claims

1. A method of enhancing the use of a GUI that, upon the occurrence of particular events, generates a dialog window having one or more response buttons selectable by user placement of a mouse driven curser over one of the buttons and clicking a mouse actuator, comprising the steps of:

(a) sensing the generation, on a computer GUI, of a dialog window having one or more response buttons;

(b) determining the current position of a mouse curser on the GUI;

(c) generating proxy buttons on the GUI together with indicia visually linking the proxy buttons to corresponding response buttons, said proxy buttons being located at positions proximate the present curser position;

(d) determining that the user has selected a particular one of the proxy buttons using the mouse curser; and

(e) causing the computer to respond as if the user had selected the corresponding response button.

2. Computer logic for enhancing the use of a GUT that, upon the occurrence of particular events, generates a dialog window having one or more response buttons selectable by user placement of a mouse driven curser over a button and clicking a mouse actuator, comprising:

(a) logic for sensing the generation, on a computer GUI, of a dialog window having one or more response buttons; (b) logic for determining the current position of a mouse curser on the GUI;

(c) logic for generating proxy buttons on the GUI, said proxy buttons being located at positions proximate the curser position, and for generating indicia visually linking the proxy buttons to corresponding response buttons;

(d) logic for determining that the user has selected a particular one of the proxy buttons using the mouse curser; and

(e) logic for causing the computer to respond as if the user had selected the corresponding response button.

3. Software for enhancing the use of a GUI that, upon the occurrence of particular events, generates a dialog window having one or more response buttons selectable by user placement of a mouse driven curser over a response button and clicking a mouse actuator, comprising:

(a) means for sensing the generation, on a computer GUI, of a dialog window having one or more response buttons;

(b) means for determining the current position of a mouse curser on the GUI;

(c) means for generating proxy buttons on the GUI, said proxy buttons being located at positions proximate the curser position, and for generating indicia visually linking the proxy buttons to corresponding response buttons;

(d) means for determining that the user has selected a particular one of the proxy buttons using the mouse curser; and

(e) means for causing the computer to respond as if the user had selected the corresponding response button.