Geometeer







Using a mouse that reports
consistent-direction translation,
and rotation

Tim Poston         Manohar Srikanth

Udayan Umapathi     Varun Vasudevan

                       

Pages here and there
Home
Where I've been
Publications
Patents
Anarkik3D (external)
Nordic River (external)
Therataxis (external)
Freedom by degrees
Xelular sets (1st look)
Tensegrities (1st look)
Freedom by degrees
Ultrasound hotspots
2×2
Walk to NIAS
Fiction
Sculpture
Joy of Ignorance

Abstract:
The standard mouse reports motion of its sensing point, in its own ('sideways', 'back and forth') frame that turns with it.  To move a cursor along a straight line, we can move the mouse straight and without the wrist turn normally used to compensate arm pivoting;  or, move it on a curve, simultaneously turning it.  The TurnMouse, interoperable with a standard XY mouse wherever one is expected (patents issued and pending), reports also its turning.  This can be used to as a third degree of freedom in input, controlling the turn, scale, jaws, etc., of a displayed 2D object, or the Z-translation or Z-axis rotation of a 3D object whose X and Y translation or rotation is simultaneously dragged as usual, or the three degrees of freedom of a 3D clipping plane.  Reduced mode switching makes manipulation simpler and faster.  Reported via the 'scroll wheel' channel, sensed turns immediately improve user control of all 2D and 3D applications that use scroll input.  They also adjust the reported changes in X and Y to a consistent, un-rotating reference frame (between pauses), giving an easier and faster 'dead pre-reckoning' open loop control when moving the cursor to a target.  This makes the TurnMouse an improved XY mouse, even if software makes no direct use of the reported turns.

Introduction
The standard mouse, from Engelbart onward, reports movement with two degrees of freedom: sideways motion in any combination with forward-back.  Many alternatives have been proposed and productised since, but with very little adoption by users outside the gaming context.  They typically addressed the chief control defect of the standard mouse: that many tasks demand control of more than two degrees of freedom, so that the mouse has to switch around between controlling different kinds of translation, rotation, zooming, etc., in an inevitably clumsy manner.  They typically neglected the factors controlling user adoption, which we illustrate by the history of the keyboard.

Typewriter innovation

The standard qwertyuiop layout was designed to avoid high speeds,
which jammed early typewriters: later ones jammed much less easily.
The Dvorak keyboard (right) addresses speed.
With equal training, a typist can work much faster on it.
We leave its boosters to explain why, and give other advantages.
Accepting these as true, why (in over 70 years) has it not become popular?

Because it is not popular.

Train on a Dvorak machine, and you type faster and better, on your machine and others like it.  Sit down at somebody else's keyboard — most people do this quite often — and you hunt and peck slowly, and in public.  Few people have achieved comfortable speed in both keyboards: Dvorak may be easier than qwertyuiop, but "master both" is harder than either one.  For an existing qwertyuiop user, there is some real (and boring) retraining to master Dvorak.  It also risks confusing carefully acquired qwertyuiop reflexes:  damaging a skill that remains important.
Some computers have an installed Dvorak option, but many don't.
In this situation, a rational non-hermit is likely to stay with
qwertyuiop.

Contrast this with the 1961 advent of the IBM Selectric, or 'golfball' typewriter.
It wholly ended jamming, as the letters no longer sat on separate moving stalks.
(Pure ergonomics might have made this the moment of triumph for Dvorak, as a 'function' row had not yet added keys beyond home-key-holding reach.
Pure ergonomics do not rule.)

The user could type exactly as before, minus un-jamming time.  There was a new power to change fonts (just switch balls) but nobody had to use it.  You could buy one ball, and stick with Courier output.   Then, when you realised that changing balls was easier than putting in a new ink ribbon, you could explore multiple fonts.

The learning curve was trivial, an old problem vanished,
and there was new power available when you were ready for it.
The Selectric quickly dominated the market.


Mouse innovation
Software can easily make a joystick control a cursor in software designed for a mouse,
but does this make a mass user switch likely?
There are awkward questions…

  • Install that adaptation on your machine, or in an application:   find it everywhere?
  • Learn to use the joystick for editing:   how soon are you faster than with a mouse?
  • When you have to use a mouse, after retraining for joystick, are you still as fast with it?
  • Play games as well as fighting MSWord:   does this look good to your boss?
A joystick (or other non-mouse) on every desk is as likely as a Dvorak.

Touch screens are now more and more popular, but they are best for very end-consumer electronics.  It's fine to select a photo with a fingertip, but to pick a mistyped letter in a word, or a term in a spreadsheet formula, most fingers are too big and clumsy.  Business and tech users will still use mice for a long time, but they need not behave like today's mice.

What mouse innovation can avoid the new-device traps?

A new element that has succeeded by avoiding the traps, more than by positive merit, is the 1990s 'scroll wheel'.  This does not interfere with the previous uses of the mouse — if you grab a scroll mouse and ignore the wheel, all your habits work.  Only some special software insists that you use it: you can still scroll a web page with the browser's sliders.  You can still click your PowerPoint™ show forward, without touching the wheel.   Combined with strong support from Microsoft, ease of adoption has made it near universal although scrolling (its iconic use) is actually slower with it than with a plain mouse.
It is a third degree of freedom, but not a good one.

The wheel is hard to turn while simultaneously moving the mouse (using quite different muscle groups) and adds little to productivity.  Its awkwardness in control tasks is attested by the fact that unlike mouse motion, whose meaning is often modified by clicking or pressing a button, software designers usually let it act alone.  Pressing with one finger while scrolling with another is simply too unhandy to combine.
The wheelmouse is thus a pair of devices — a 2-degree-of-freedom and a 1-dof— rather than an integrated 3-dof device, for dextrous control of three simultaneous degrees of freedom such as a rigid planar position (X and Y of the centre, angle θ of turn), 3D translation (X and Y and Z), 3D rotation about all possible axes, etc.


Whole-mouse rotation

Rotation is, as noted a dozen years ago, a far better third degree of freedom to report.   (We are used to moving and turning any object together, with integrated motions of wrist, elbow and shoulder.)   The fingers simply grasp the mouse, sometimes clicking or pressing a button, with none of the fine movements that are hard to coordinate with a moving grasp.
There are other ways to sense rotation than by comparing the output of two balls, or two optical sensors.  We prefer to use a single optical sensor, detecting rotation by a more sensitive algorithm described in our issued and pending patents, but here we assume only that rotation is somehow sensed.  It is also important that an X and Y motion should be reported where the operating system expects to find it, so that this mouse is a plug-in replacement for the standard type, where software and the user expect that.  The angle θ of turn should be available, but no more compulsory to use than a different-font 'golfball'.  Making it available in the disguise of scroll-wheel data allows many applications to use it without new programming, as discussed in more detail below.  This further supports an incremental, non-interfering change, and thus the prospects of widespread adoption.


Mouse frames and world frames
The typical mouse fails to report its rotation, but its rotation affects its reports.
From Engelbart's mouse to any current optical mouse, the meanings of 'sideways' and 'forward' rotate with it.
Early optical mice (1982, 1983, 1985) used an XY coordinate system embedded in the pad, and would not work right when rotated: this enforced an unrotating reporting frame, by restricting the user.   Most mice move more freely, but large motions have counter-intuitive results.   An easy motion, if your elbow is on the table, is to pivot on that point.   Point the mouse straight outward, and it moves like this:


The mouse moves exactly sideways, all the way, so the software moves the cursor exactly in the screen's global sideways direction.


To move exactly straight, you must follow a curve:  or if you move straight, the mouse must not turn.

This is difficult.

When you first learn to draw a straight line, with a pencil, you do best if the teacher shows "The underside of the forearm to the thumb should be a straight line", and you hold it like the drawing at left.  This does not let the wrist bend while drawing a straight line: the forearm and hand move together.
Do this with a mouse…
Does a straight line show on the screen?
Yes, if  elbow motion is parallel to the line⇒

The forearm usually changes angle as it moves:  e.g., straightening naturally as you reach forward.
Moving this way, the unchanging direction of motion does change, turning relative to the mouse.

The curve followed by the cursor veers off to the left.
Does this matter?
To create a straight line, it doesn't.
'Rubber-banding', pioneered in Ivan Sutherland's Sketchpad in1963 (before even the mouse!),
lets you control a straight line by its ends, leaving its straightness to the software.
Most interfaces don't ask you to move the cursor along (or near) an exact straight line,
because the standard mouse interface makes that hard.
A veering brush stroke looks wrong.  Tough: buy a graphics tablet.
With a standard mouse, you cannot make a good job of your own signature.
What if you don't care about paths, just want to click in certain places?   If you want to do that fast, particularly in a shoot-em-up game where milliseconds matter, the path makes a difference:

Mont Blanc is under attack by vampire smileys.   A single bite hardly matters… but one bite too many and Mont Blanc will rise up in the moonlight, and sink icy teeth into the Matterhorn.

You banish them with clicks of a blessed cursor , but you must get the cursor there fast to do that.  Your vision detects one, and within a tenth of a second or so your motor cortex is planning muscle motions that will carry the mouse that will move the cursor to the smiley and click! save the mountain one bite.

Vision sees accurately where the smiley is.  Your motor cortex is expert at planning a hand motion path (not exactly straight: optimal, given the mechanics) with a click at the end.  If cursor motion corresponds simply to motion of the physical mouse, vision can merely watch, for the next few tens of milliseconds.  It has no time to intervene, but no need to: a good plan has been made, and is being executed.

If the cursor path veers from the planned one, the story is very different.  Your vision must catch the deviation, feed revised data to the motor system, where plans are updated, taking time.  The cursor does not guide itself to close with the target, and the eye control loop takes around 200 milliseconds.  To guide the cursor to the right place, you must move slowly, and give the order "Muscles…Click!" at just the right moment in advance.
Or, you must pre-plan a cursor path and achieve it with a differently curved mouse path.
A human can and does learn to allow for sources of path veering, including mechanical ones, and very interesting work has been done on this.   Fast targeting with a standard mouse is evidently possible.   Expert game players achieve it, just as a typist who learned a perfect rhythm could type many words per minute with few jammed keys.   But the learning curve is steep.   It is clearly better for the technology never to present the veering problem, particularly to the novice.
There are trade-offs in managing the problem:  a large scaling of cursor motion to mouse motion reduces the unintentional mouse turning, but requires finer position control of the physical mouse.   (This may be one reason why gamers seek out high cost, ultra-precise mice.)   But it is clearly better to eliminate it than to mitigate.

What is the mouse-steering equivalent of the 'golfball'?


Mouse reform
A rotation-sensing mouse both opens up new options (like the Selectric font changes) and dissolves an old problem (like jammed keys), without the downside of re-skilling/de-skilling like the Dvorak keyboard or an office joystick.
In the sections below we describe how a TurnMouse can

  • replace an XY mouse, with no new demands on the user or programmer of existing applications,
  • report XY movement more accurately, and in a consistent direction,
  • report θ changes as well as XY, allowing better applications in 2D and 3D,
  • Give new design options for games, or emulate a joystick in existing ones, and
  • replace an (XY, scroll) mouse in existing software, improving usability and performance
    with no reprogramming (though new code could improve them further).


The TurnMouse system

Plug-in as an XY mouse
An operating system (OS) such as Windows or Linux comes equipped with standard protocols by which a mouse can report the (δXδY) changes in (X,Y) that it detects  (These changes are mapped by the OS into changes (δuδv) in an on-screen cursor position (u,v), but it is not the function of the mouse to maintain any such integrated point value:  it reports only short-time differences.)
A mouse that senses (δXδYδθ) senses, in particular,  δX and δY.  It can thus report them by the protocols expected of a standard mouse, by the OS.  The options for δθ are more various.
Once the TurnMouse becomes common, one can expect the OS creators to add support for it.  In the meanwhile, a device driver can set up a thread (as real time as the OS permits) which is continually updated with δθ and (optionally) accumulated θ values corresponding to mouse motion.  An application program can link with a library to obtain these values without incorporating or tweaking source code.  However, such a library is needed for each of Java and C++ (where it is a library of classes), for C (a library of functions), etc., to be distributed with the commercial release of TurnMouse hardware.
In the shorter term, requiring no novelty in the code, the driver can report δθ (appropriately scaled) as a rotation of the scroll wheel, using the protocol provided by the OS.  With a Windows driver, this makes anya scroll-driven code work as TurnMouse demo.  It allows use of existing library utilities like the Java
MouseWheelListener, and allows the same code to run a scroll-based hint of what could be controlled simultaneously with XY, for users with no TurnMouse.  Not even the violin — perhaps the steepest learning curve for any physical control system— requires fingering controls on the moving handle of the bow:  scroll-mouse users typically pause mouse motion to turn the wheel.  The hint, however, is significant.
This also enables TurnMouse input to existing, widely distributed code, with the results below.


A better XY mouse
Our new algorithm extracts from the typically 19×19 optical mouse window, sampled 1,000 times per second, motion data with sub-pixel precision (comparable to that currently achieved using more and finer pixels, laser light, and thousands of frames per second, for gaming mice).  It needs such precision to estimate θ.  (In one step the optical mouse view can move by one or two pixel widths:  the extra difference in the CCD locations from a typical 1-millisecond turn is much smaller than a pixel.)  Fortunately, it has it, so a more precise (δXδY) at lower cost is one benefit of the algorithm.   A more precise (δXδY), however, is not the same as a good (XY), if the (δXδY ) direction is inconsistently reported, relative to user space.
At each step the algorithm also estimates δθ. Since δθ has a frame-rotation-independent meaning, we can thus accumulate a good value for Δθ, the mouse rotation since a mouse motion started.  Rotating (δXδY) by Δθ, before reporting it, gives a directionally consistent step throughout the motion.  (We start each motion with Δθ = 0, since otherwise a mouse would accumulate un-user-predictable angular bias over time.)  The figure below compares estimated  (δXδY), rotated by the summed estimated Δθ accumulated to give total (XY) change as a position, superposed (with matched starts) on the real positions from which the 19×19 images came.  (The images were created from a larger 'mouse pad' image by computing what an 19×19 camera would see at those precisely known positions.  Experiments with real 19×19 camera images are at an earlier stage, but indicate similar results.)
The red arrows show values of θ not Δθ, and a jolting start made the first few (δXδYδθ) less accurate; hence the uniform phase difference between the red ('real') and blue (estimated) direction arrows. The changes Δθ over time are very well matched, as shown by the accuracy with which the estimated Δθ adjusts the estimated (δXδY) vectors and hence the successive (XY) they add up to.  Even accumulated errors in position, over hundreds of steps, remain smaller than a pixel.

By passing the rotated (δXδY) estimates to the operating system, we have a directionally consistent mouse.  The cursor path, in all software, will not veer from the shape of the path followed by the real mouse.
This should make a major difference in the speed and accuracy with which a user can interact with XY-mouse oriented software.   We will explore and quantify this, and distinguish between the effects of the new mouse's improved precision and those of its directional consistency.


An (XY, θ) mouse
Directionally consistent XY reporting will be among the first-exploited aspects of this development, since it plugs in seamlessly to all current software that uses a mouse.   Wherever precision and speed matter, we expect this to give strong appeal to users.   The resulting availability of economical mice which sense rotation, even if bought first for their directional consistency (just as some users bought a Selectric to avoid key jams), will encourage developers to create software that uses their ability to report rotation.
3-dof mice in 2D

The typical graphical user interface (GUI) is full of objects that must be rotated, as well as dragged from one screen location (δuδv) to another.
Our upper figure at right shows the standard XY-mouse way to do this, as in (for example) PowerPoint™.
You need to put the green star in the red place.   You drag it across to roughly the right place, you move the cursor to the turning-handle, you drag that to rotate the star (about a centre chosen by the software, not by you), need to translate it some more, rotate some more…   How many separate drags?
You lose count.
With a TurnMouse (lower right), just move the star and turn it… once.
How many times does the 'once' at right repeat, for one completion above it?
You lose count.
Replacing the turning-handle by scroll wheel action gives no speed up, as you still find yourself switching between translation and rotation.


Move & turn with an XY mouse.


Move & turn with a TurnMouse.

If we care about more than the final angle, if to avoid collisions we must turn as we go,
the skill difference is even stronger.
A brush needs to turn as it moves, for gracefully varying widths.
What artist would accept a brush that can move or turn, but not both together?
Every artist with a mouse-driven digital brush.     Until now.

Many applications let you fix a curve by adjusting the XY positions of its nodes, and its directions at these nodes, as in (at right) fitting the red curve to the mouse outline.  With a TurnMouse plugged in, it is much easier and faster to adjust a curve if we can (for instance) 'roll' a node/direction widget along the target shape.

Lay a map over another map, or over a satellite picture.
Slide around and turn, simultaneously.
Choose the centre of the turn.
In a left-button drag, turning a TurnMouse can turn the map around the cursor:
in a right-button drag, turning it zooms from the cursor.
All maps should be so easily moved and scaled.
Fit onto , giving  .

The man need not turn, but reaching is far easier if he can move and grow at once.
The simultaneous 3rd degree of freedom afforded by mouse rotation
need not map only to rotation of something in a display.

With a floating palette or tool-tip it is current practice to position it, then — in a separate action — move the cursor over the buttons until the desired one is highlighted for clicking.
Turn the mouse as you drag the palette,
and you could simultaneously choose your button.


The basic human locomotion is to walk;
basic screen locomotion is dragging.
With a plain XY mouse, even (for neuromotor reasons) with a scroll mouse,
it is impossible to do anything else simultaneously with dragging.
The jaw muscles of the actor at left must act autonomously as he moves,
as there is no XY-mouse way for the user to chew gum,
and walk, at the same time.

3-dof mice in 3D
Too many 3D applications displays look like the one at right.  ⇒
(This particular one is from 3D Studio Max.)   Why the multiplicity of views?
One cause is the tradition from engineering drawings, where flat paper must represent a 3D object exactly.  For a real object, in the hands, nobody feels the need for such disparate simultaneous views.  Our stereo vision constructs depth from two nearby eyes, but we rarely look at an object both directly and in a mirror, at once, to understand it.


The spatial understanding cues we are best adapted to are stereopsis (for many of us), and motion effects:  move the head and the eyes' view changes, or move the object in the hand.  The image at left (from Rasmol) is a fine example:  hard to see clearly while still (or while still loading), it is vividly 3D when it rotates.  But an autonomously rotating object is hard to edit or even to pick a point in, so this cue is limited.  Download the actual Protein Explorer and you can actively rotate molecules with an XY-mouse, to help see the three-dimensional structure. This is still, however, only a kind of 'looking at it'.

The XY-mouse drags in this interaction are typical:  drag sideways around the vertical axis, up and down around the sideways one.  The absence of a way to turn around the axis pointing away from us is OK for comprehension (the 'same view' just rotates) but a pain if we want to fit two molecules or fragments together … as a 'rational drug designer' often needs to do.
To rotate the teapot about a vertical axis, drag sideways in the bottom-left or top-right window:  at top left, you can't.  To turn around its handle-to-spout axis, use either top window, but not the bottom left (the view along that axis) or bottom right (where that axis is skew to the screen, not flat in it).
This is a painful way to adjust a 3D angle, usually with many window switches, back and forth.
Just as bad is changing the teapot's location;  drag forward+sideways at top left, forward+up at top right, sideways+up at bottom left, and in some plane (no toward/from me) at bottom right.
To go somewhere in particular, again, needs many switches.

The result is not only a clumsy interface, but a massive waste of space.
A typical display is only 1024 pixels wide (showing only as much detail as fits in less than a centimetre of a high-res printer's output).  Cut into this with a surround of widgets and menus, then cut vertically and laterally in half, and each 'window' becomes more like a 'keyhole'.  This is a major reason for giving a medical workstation a double display, with a way-high-end cost and double the desk space:  how else show all the views needed, sharply enough?

The lack of a closer-farther control usual with an XY-mouse is partially fixed
by allowing a scroll wheel to move the current selected object forward and back.
But this is not integrated with dragging:
A button press with one finger and a wheel roll with another is hard, so few programs ask it of the user.
'Left-button-down scroll' and 'right-button-down scroll' are impractical,
so 3D software generally has one meaning for scrolling: closer-farther.
The missing way of turn, about the user's line of sight, is still missing.
Use a TurnMouse, however, and a left drag can simultaneously change the X, Y and Z of a location,
and a right drag can turn an object about an arbitrary axis.

Many of these methods are covered by our patent, recently issued by the UKIPO, and pending in the US, EU and India.
There are precursors to our work, but the early
mechanical 3-dof mouse work has no discussion of interoperability or of controlling 3D location or rotation.  A 2003 patent for an optical 3-dof mouse (using two classic optical windows, rather than as we prefer, a single window and a superior algorithm) describes control of rotation about a single axis at a time — better achieved by an XY-mouse slider — rather than exploit the power of three simultaneously controlled degrees of freedom.

Such interaction is the core of the TurnMouse project, more so than the sensing modality: we are also developing a MEMS-accelerometer-based version.  Intuitive 3D control may be the single most powerful TurnMouse impact on software.  Beside moving an object such as a CAD model or CAT scan display, natural movement of an XYZ-cursor opens a wide range of interactions handled up to now (if at all) via an XY-cursor hovering over the 3D display like a surfer trying to herd dolphins.
A depth-controlled cursor affords control in depth.

As important as controlling location and attitude, in even looking at 3D objects — let alone working on them — is 'clipping' them graphically to see inside.

The placing of a clip plane is another 3-dof problem, smoothly handled by a TurnMouse,
hard with only an XY-mouse or a scroll-mouse.

This greatly enlarged control of 3D objects and scenes has analogies with the Selectric freedom of fonts,
achieved while removing the problem of jammed keys or veering paths, and adding no new difficulty.

Exploiting scroll-based software

The Google Earth XY-mouse interface (right) includes a slider for zoom, and another for Tilt (for a more oblique, '3D-feeling' view).  Zoom always occurs from the window centre:  A close look at a small area drags it to the middle first, or it zooms out of the window.  From space to a specific close-up, this usually means zoom→drag→zoom→drag→…  Choosing a different point would mean an extra widget to mark it and stay there while the cursor goes off to the slider.  The scroll wheel acts like the slider, though it could zoom from the cursor, with no widget.



Plug in a TurnMouse, with the driver sending turn data to the OS in scroll data disguise, and dragging immediately includes simultaneous zoom control.  (Google Earth zoom is set to be hypersensitive to the scroll wheel, so control is easiest with a reduced 'Scroll Coefficient' set on the driver.)  Plugging in a device cannot of course cursor-centre the zoom, but the experience immediately improves, and navigation is faster.

This is typical for adding a TurnMouse to existing software that uses scroll input.  A few programs map scroll input to something that should not act with every drag, only avoided by exactly not-turning the mouse.  More typically, the software becomes smoother, faster and more intuitive to use… although even more is possible, with the software made new.  Google Earth, for example, could control move-and-zoom with a left-button turning-drag, move-and-tilt with a right-button turning-drag.

Many 3D programs enable scroll input for zoom (enlarging the whole scene, or moving the viewpoint closer) or for pushing and pulling.  There is thus an immediate gain in usability for SketchUp, Maya, 3D Studio Max, Pro/ENGINEER, and a host of other applications.  However, because of scrolling's effective incompatibility with other fingering actions (as hard to coordinate with it as mouse bulk motion), Z control is 'the' thing that these programs allow it to do.  It acts as a kind of autonomous Z-slider, mounted between the eyes of the mouse.

A TurnMouse makes dragging with (X,Y,θ) output as natural as a drag with (X,Y);  and (X,Y) experience shows that left-button drags and right-button drags are easy.  Every 3D application can thus gain further from the TurnMouse by using a left drag for (X,Y,Z) motion, as already often comes with scroll wheel support, but a right drag for a newly-programmed arbitrary-axis rotation (of the scene, or of an object, as selected).  As noted above, clip plane slicing and 3D cursor control will also become important.  But even before any such new features are coded, the TurnMouse's existence has already improved these 3D applications, unexpectedly and unbeknownst to their architects.


Development develpments
Getting a working TurnMouse into circulation has suffered the usual tribulations!
Outside an existing manufacturer's pipeline, it is remarkably hard to get access to the 1000 frames/second produced by the 18×18 or so sensor array of an optical mouse chip, so our algorithm for getting Δθ out of that stream (as well as a more accurate (ΔX, ΔY) ) has only been tested in simulations, where it looks good, but doesn't plug in.
Varun and Udayan have a version using MEMS accelerometers, but this is not quite accurate enough yet.
The most direct way to piggyback on existing technology is to put two working sensors into one 3D-printed mouse and calculate the rotation from the difference between the (ΔX, ΔY)s.  The prototype below works very nicely!

               

We hope to make at least this version available soon.


Conclusions
Unlike most user input device innovations, the TurnMouse is interoperable — both technically and for user skills — with the familiar desk mouse.  Its XY-change reporting can be not merely precise, but directionally consistent over a movement, with sensed turn θ as an adjustment factor.  Reporting θ itself enables a wide range of smooth new interactions, since simultaneous control of (X,Y,θ) is a natural human skill, developed from early childhood and refined in every dextrous task.  Reporting θ via the scroll wheel pathway empowers many of these interactions at once, in popular tools ranging from Google Earth to 3D animation software to Pro/ENGINEER.  More and richer interactions will be added, but this immediate upgrade of existing programs will be a stepping stone in the TurnMouse's acceptance by many users (who will want one right now) and by game and application developers (who will soon see a new and powerful input device, already on many desks and lap-boards).

The builders and maintainers of operating systems and code utility libraries will not be far behind in adding and standardising support for TurnMouse interaction, simplifying the work of developers.