Smooth Scrolling

[JackDunaway]

Oftentimes, I would rather have a smooth scrolling action rather than the line-by-line action. This is not just a whistle or bell to make UI's more modern; from a usability standpoint, it's easier visually to trace a smoothly animated object rather than a jerky object.

Here are two dorky little GIFs to illustrate the point (first is "clunky", second is "smooth"), but go ahead judge the difference yourself by opening the attached LV 8.2 VI. It contains a "simulated" smooth array using a cluster trick.

                

Oh yeah, this would apply to Arrays, and Trees, and Listboxes, and Clusters, Matrices, and Tables, and.... (hey, we currently have smooth scrolling for string indicators! One out of a half-dozen is a good start....)

I envision an option between clunky and smooth, because both options have their merits for different situations.

[JackDunaway]

(Just noticed that in saving for 8.2 the IPE was replaced by the single iteration while loop, and the code is a wreck. Well, hopefully it still works for you - don't judge the VI for style. :D)

Message Edited by JackDunaway on 04-16-2010 11:26 PM

[altenbach]

Basically, you want IndexVals to be non-integer.

What do you expect the index display to show if you scroll to index 1.5, for example?

(Or should this only work if the index display is hidden?)

[JackDunaway]

I thought about this when creating the idea, but it may be better to keep IndexVals as an integer rather than floating point. I would expect a "partially" scrolled element to still return the integer index as the floor of the partial index.

I would expect the Index Display to display only the integer values, not partial floating point values, and if you thumb through the Increment/Decrement buttons on the Index Display, you get the current line-by-line scrolling action, since the underlying datatype is I32.

The "partial" floating point would more appropriately be a property of the scrollbar. So in short, the Index Display remains I32, and the scrollbar is DBL, where they are linked (set one, the other changes). I guess this means a new property ScrollbarPos type DBL.

I can't enumerate the positive/negative ramifications of having two "indices" that are linked to each other. Maybe it would be better just to make IndexVals a DBL? I'm just interested in the best implementation that allows seamless native UI capabilities and programmatic manipulation.

***EDIT*** And I would not expect behavior to change based on whether the Scrollbar or Index Display are either visible or hidden.

Message Edited by JackDunaway on 04-17-2010 01:03 PM

[JackDunaway]

Keep in mind, our conversation above applies for arrays. There's still a large benefit in this Idea for Trees and MCL's, where IndexVal is not even relevant. And speaking of those two, I just realized that they have smooth scrolling horizontally, just not vertically. That being true, hopefully the implementation of this Idea would be relatively straightforward since it's already partially supported.