[LAD] User eXperience in Linux Audio

[Tim E. Real]

On April 24, 2015 10:04:36 AM Thorsten Wilms wrote:
> On 23.04.2015 21:55, Len Ovens wrote:
> > 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.

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.