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
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.
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.
The standard mouse, from
reports movement with two degrees of freedom: sideways motion in any combination with forward-back.
Many alternatives have been proposed and productised
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.
The standard qwertyuiop
layout was designed to avoid high speeds,
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
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
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
Then, when you realised that changing balls was easier
than putting in a new ink ribbon, you could explore
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.
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…
(or other non-mouse) on every desk is as likely as a Dvorak.
- 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?
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
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.
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
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,
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
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.
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.
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,
But it is clearly better to eliminate it than to mitigate.
What is the mouse-steering equivalent of the 'golfball'?
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
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
(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
changes in (X,Y)
that it detects
(These changes are mapped by the OS into changes
in an on-screen cursor position
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
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
at lower cost is one benefit of the algorithm.
A more precise
(δX, δY), however, is not the same as a good
) direction is inconsistently reported,
relative to user space.
At each step the algorithm also estimates
has a frame-rotation-independent meaning,
we can thus accumulate a good value for
the mouse rotation since a mouse motion started.
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
rotated by the summed estimated
accumulated to give total
change as a position, superposed (with matched starts)
on the real positions from which the 19×19 images
(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
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.
over time are very well matched,
as shown by the accuracy with which the
adjusts the estimated
vectors and hence the successive
they add up to.
Even accumulated errors in position,
over hundreds of steps,
remain smaller than a pixel.
By passing the rotated
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.
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
Our upper figure at right shows the standard
XY-mouse way to do this, as in (for example)
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…
How many times does the 'once' at right repeat,
for one completion above it?
You lose count.
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.
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.
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.
The man need not turn, but reaching
is far easier if he can move and grow at once.
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
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
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
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'
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,
by the UKIPO,
and pending in the US, EU and India.
There are precursors to our work,
but the early
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
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
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
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.
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
output as natural as a drag with
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
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.
Getting a working TurnMouse into circulation has suffered the
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.
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
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.