25 Apr
2015
25 Apr
'15
4:19 a.m.
On April 24, 2015 10:04:36 AM Thorsten Wilms wrote:
On 23.04.2015 21:55, Len Ovens wrote:
Hey guys.
For anyone wrestling with control design and the mouse pointer
being too close to the screen edge, there *IS* an attractive
technique you might not be aware of or forgot.
If you use a trackball, it is heaven!
Er... but if it's a touch pad, as mentioned ye may be lifting yer finger.
It involves hiding the mouse pointer and forcing it to do tricks.
1: Upon receiving a mousePress event, immediately *hide* the mouse pointer.
2: Now force the invisible mouse to the *centre* of the screen (to give the
mouse pointer plenty of 'headroom' before it would ever reach an edge).
3: Now upon reception of a mouseMove event, do something useful
with the increment given by subtracting the new position from the
centre-screen position. (Add the given increment to some object's position
or value, edit-box value etc.)
4: Now immediately *force* the mouse pointer back to the centre of the screen.
5: Repeat 3: and 4: until mouseRelease event is received.
6: Now turn the mouse pointer back on. Done.
This technique can be used for example with:
Linear-movement knobs and dials, and both vertical and horizontal sliders.
Canvases (2D and 3D!).
Edit boxes.
I've used this technique since the mid-90's on Windows, and now Linux.
It was harder to do in Windows than Linux.
I know a Windows 3D app of the type Thorsten mentioned.
I remember when that edge-crossing thing was added.
I shook my head, laughed out loud to my friend who paid money for that
and was showing me the new version. So goofy that was, it seemed to me,
so I made this instead and added it to my own 3D apps!
I call it "Continuous borderless mouse movement" and my control class
names are like "RollEdit" RollCanvas" etc. because you can roll, roll,
roll,
without ever lifting the mouse button and re-positioning the mouse.
Coupled with mouse acceleration and accelerator modifiers,
you can roll a floating point edit box value with fine resolution,
or with a few more rolls plus acceleration, be into the thousands.
Great for example for 3D Z-axis zooming in/out quickly, continuously.
See examples in MusE, the continuous Pan and Zoom.
If I recall correctly, see also LMMS, and the audio editor Sweep.
I have yet to try, but believe the technique is good when you are forced
to deal with short sliders because you are not forced to map one
value-change per mouse-pixel movement, nor accept a mouse pointer
that goes way out of positional sync with the actual slider thumb
rectangle just to get good resolution/range stuffed into the short slider.
We discussed this in MusE recently, about our mixer, and I said if we
want short horizontal sliders stuffed into a thin vertical mixer strip,
then it will be really crucial that we get these sliders right.
So I believed that this technique was really a (the only?) practical
way to do it. Hide the mouse.
What do you think?
About *circular* motion knobs and dials:
The awesome thing about them is, as someone mentioned,
if you need more resolution you simply move out to a higher radius.
But I've always believed the 'hidden borderless continuous mouse'
technique cannot be used here.
Because the user needs to know that they are drawing an arc, and what
radius they are at.
Whether that is done by showing the mouse, or hiding the mouse but
showing say a 'radius line', if you are near the screen edge you are stuck.
Maybe linear-motion knobs really are best used with this technique.
So I just realized now that the above mentioned border *crossing*
technique may help with these circular-motion knobs.
Let the mouse cross the border. Not a big problem for the user,
they are mostly focused on the actual knob and its value.
They can move to (almost) any radius, and sure it's a little awkward
near screen edges (like Asteroids - never did well on that one).
But hey what else can you do...
Now, a bit far-fetched but, what about showing a sort of temporary
'proxy' circular-motion knob, somewhat larger and fancier/embellished,
in the centre of the screen when a real control is pressed?
Users focus on that proxy control as they are adjusting the value.
We can't get any better than screen centre in this situation, can we?
Thanks for bringing this up. Obviously I couldn't resist responding.
Tim.
That is why being able to adjust with both
horizontal and vertical
movement is a plus. Take a look at zita-mu1 for an example. It is also
important to continue watching the position of the mouse when it leaves
the application window.
Yes. If the linear knob happens to be too close to a corner of the
screen, both part of the vertical and the horizontal range may be out of
screen, though. Changing direction forces you to spend attention instead
of relying on autonomous movement, trained by repetition.
With pointer-based usage, you can allow the pointer to go beyond the
edge. Some 3D application will have the pointer appear on the other
side, as if it traveled through a portal. But with touch, you are out of
luck, have to move the active area and allow the finger to be repositioned.
I think in many cases, horizontal sliders with labels and numerical
values inside the slider area, are the better approach.