Buttons (Rob Laddish)

In order to make it easy for the user to interface with the program, we draw a number of user selectable buttons at the bottom edge of the screen. When a button is pointed at by the cue (it doesn't have to touch) or by the mouse, it becomes the pointed button, and it becomes highlighted. When the stylus button is pressed or the left mouse button is pressed, the pointed button becomes active.

There are 4 types of buttons. When a submenu button is selected, the set of menu buttons will be changed to the new menu. When a modal button is pressed, the button highlights in a different manner and stays highlighted until a new button is selected. This allows the user to interact with the display in different modes. For example, if the rotate modal button is selected, the virtual cue will change to a rotate icon, the rotate button will be highlighted, and the log window will prompt the user to continue. The user can then grab a portion of the pool table and rotate it around a z-axis centered in the middle of the pool table. The third type of button is the normal button, and selecting it causes an action to occur which is described in the log window. The last type of button is a passive button, like the log window, and it cannot be selected.

The log window exists above the row of buttons and is used to inform the user what actions will be performed if a button is selected, and what action has been performed after a button is selected. This allows us to present a button called "lights". When the use points at the "lights" button, it becomes the pointed button. The log window is filled with the current lighting status (on/off) and tells the user that selecting the button will turn lighting on. If the user selects it, the log window will now display "lighting is on". This removes the ambiguity associated with terse buttons like "lights" or "lights on" (are lights on, or does selecting the button turn lights on?). It also allows us to conserve screen real estate.

Buttons are defined internal as an array of character strings. Generic routines create buttons from these arrays and imform the program when a button is pressed on which menu. A routine specific to the menu is then called. If any of the strings contain newlines, then the button will have multiple lines of text in it. The text within a button is centered on each line, and the buttons are space equidistant from each other.

Problems Encountered

User tests revealed several problems. The first was that we had no indication that a button was pressed if the results were subtle. This was fixed by creating the log window and forcing it to change after button selections. The second problem is that the buttons must be level with the table to see clearly (z=0) and table itself comes up to z=0 on the outside. This limits the amount of information or number of buttons we can present. It would be useful to have larger amounts of text for the help screens. The third problem is that the buttons are currently confined to a single row. This causes the menu trees to have some depth. It would be easier to use if the menu trees were bushier. This can be fixed with more programming, but it is still limited by the height of the table. The final problem is that the buttons are arrayed across the bottom of the table, evenly spaced. This requires a large amount of arm motion for menus with a small number of buttons, and even worse, the virtual cue that the user points at buttons will not be visible unless the user holds the stylus over the table further than is comfortable. This problem could be solved by moving the buttons to the far end of the table, but then the user will not see the table edge and floor effects.

Related config file paramters:

See Also: