Subject: Theta Menus
From: Don Hopkins <[email-masked]>
To: [email-masked]
Date: Sun, 18 May 86 21:50:27 EDT

Here are some preliminary notes and ideas...

			     Theta Menus

	Menu selection is based on the angle between the mouse down
event and the mouse up event. The radius should not have any bearing
on which menu item is selected, and could even be used as an argument
to the item.

	The advantage is that if the user is familiar with the menu,
no visual feedback is required to select an item. Just the direction
has to be known. There is no need to slow the mouse down and "park" in
in a small rectangle as with conventional pull down menus. If the user
is familiar with the menu, then no visual attention at all is
necessary. Thus you can be looking at something in one window while
traversing menus in another. Pull down menus require that you move in
the same direction every time you choose them (thus discarding theta),
and depend on how far you move the mouse (depending on the radius
instead). With pull down menus, there is no advantage to having fewer
menu items, because you need just as precise control to choose each
item.

	A mouse down event should pop up a menu of n items, such that
each item maps to a certian range of degrees, or sector, and the sum
of the sector widths is 360 degrees. It might be nice to make some
sectors wider than others, so that they are easier to choose. There
should be a way to specify where around the circle the first one
starts.

	When the mouse down event happens, a menu, whose center is
where the event occured, should pop up, showing sectors and the item
they select. As the mouse is subsequently moved around, the item whose
sector contains the angle between the menu center and the current
mouse location should be highlighted. When the mouse up event happens,
the current highlighted item should be chosen.

	There might be a safe zone around the menu center, of a
certian radius, in which no sectors are highlighted.  If the mouse up
event happens here, no items are chosen. Mousing down, then up without
moving would simply show the menu without choosing anything.
Alternately, one of the other mouse buttons could abort the selection.
(The latter has the advantage that no visual feedback is required.)

	As the mouse is moved further away from the center of the
menu, the user has more precise control over which item is selected,
because when the radius is greater, motion has less effect upon the
radius. 

	Some items could be submenus, which would be overlayed,
offset in the direction of the item, by a certian radius. You could
then see the path you used to get to a menu. There could be a way to
take a step back to the previous menu, and make another selection from
it. 

Applications:

	Choosing between n items, each item having a sector of 360/n
degrees. 

	Setting the time of an analog clock. Use one button to set the
minute hand, and the other to set the hour hand. Move in the direction
you want it pointing.

	Choosing from a color pallete. The menu is a circle of colors.
Move in the direction of the color you want. 

	Answering yes or no questions. Up for yes, down for no. 

	Scrolling the screen. The radius could supply an argument for
how far to scroll. Compare to scroll bars: You do not have to stop
looking at what you're scrolling to aim the mouse at a scroll bar. 

	Choosing percentages. Right for 25%, down for 50%, etc.

	Specifying a direction (and distance) to move in a game or
whatever. 

	Incorporate audio feedback for the blind.