Allow Increment and Decrement Buttons to have Adjustable Acceleration Rates

[JackDunaway]

Here's a very fundamental User Interface concept that LabVIEW lacks: 

When you press and hold an increment or decrement button on a numeric/ring/slider...etc..., the rate at which the value changes is constant: painfully slow. Typically, in other applications, button presses will increase the rate of change of the number proportional to the amount of time held, and if you hold it for 5 seconds or so that sucker is flying.

We want the same native behavior for increment/decrement buttons in LabVIEW, but we want it to be configurable. Consider a Property Node that defines a Lookup Table for the velocity profile of the increment:

The way the above code is read: For 0<t<1000, the control only moves at 1unit/sec. For 1000<t<3000, the control moves at 10units/sec. For 3000<t<5000, the control moves at 100units/sec. Another (more difficult?) way to define the velocity profile is to provide the velocity profile vs. time as a formula.

Of course, while the "typical" profile would start off slow and accelerate, I'm sure the ability to create unique accel/decel profiles would give incredible control for some awesome, one-of-a-kind User Interfaces.

(As a side note, if LabVIEW simply implements a fixed acceleration rate that was non-configurable, I will still be frustrated and still take the XControl route.)

I'm sure someone can think of a better, more intuitive implementation, but the concept remains:

For a press-and-hold on Increment/Decrement buttons, the control should increase its rate of change proportional to the amount of time it has been held, as defined by the programmer.

[Tom_Hawkins]

This is a great idea (and I've voted it up) but your lookup table example is absolutely NOT the way to implement it... it needs to be a gradual, continuous acceleration rather than a step change at a certain time.

Real-world devices like temperature controllers seem to be particularly fond of the step-change implementation, and inevitably it's when the value is just about to reach the setting you want that the controller suddenly decides to start flying off in steps ten times as big. I have lost count of the threats of violence against inanimate objects that I've issued at this point 😉

If we could specify an initial period during which the increment rate was constant, then an acceleration rate, then a limiting value to the increment rate (just to keep things sensible), that would indeed help to creat awesome UI's.

Of course the ideal would be for the rate of change to depend on how hard you hold down the mouse button, but this would need cooperation from hardware vendors...

[JackDunaway]

Well, tmh, I agree with you. I would rather input my profile as a formula to allow for a smooth acceleration, but as you stated, industry sure is fond of the lookup tables.

On the other hand, since button response is a function of user-perception, you could granularize the step changes in the lookup table such that the user is fooled into perceiving very smooth transitions. The array of lookups could be generated in a For Loop with 100 iterations from a formula, then be fed into the PN. You may even find that only 10 steps are necessary to satisfy perception.

That is why I proposed the idea as a lookup table: it should be easier to implement on NI's behalf, it is a little more "industry standard" than defining a formula, it should perform a little faster than the formula, and it could be perceived just as smooth as a formula.

[JÞB]

Shift+Inc and Shift+Dec.  Watch it fly

[PalleM]

@Jeff·Þ·Bohrer: Holy smokes, thats just way too much 

I like this idea, since all those awesome shortcuts, isn't helping the end user (how would they know to hold shift while clicking the buttons?)  (and no, info like that doesn't belong in the manual to my programs )