I have a few questions and thoughts and would really appreciate your feedback.
- After wrestling with some decisions, the mouse wheel will now always move the nearest unoccupied thumb, which can result in some exciting yo-yo action when this nearest thumb changes. Any thoughts, concerns or violent objections? I have trouble coming up with a satisfactory alternative right now (but see below for further discussion). I’ve noticed that the original behaviour was only ever moving the core
value (in a single or three-value slider), never
maxValue, but in such a context I do miss the ability to mouse wheel over a two-value slider, for instance, and there’s always a chance that
value is already taken by a touch event. Personally, I find my current implementation fairly intuitive … not to mention playful and vaguely hypnotic.
- If you use two touch inputs to drag two thumbs of a two-value slider across each other, you can get some tug-of-war style flickering because of value nudging. Perhaps this leads to a larger conversation about thumbs and values…
Thumbs and values
Would anyone find use in a flexible ordering of the thumbs, where e.g. min > max is allowed? One such application is a widget in the style of Vienna Power Pan that allows for inverting of left and right channels, or mapping any range of inputs to inverted outputs; I’m keen to explore this space. Of course this would be an opt-in feature.
How about defining “nudgability” (and “mousewheelability”, etc.) per thumb as part of the slider settings too, with sensible defaults? Obviously nudging makes no sense if values are free to overshoot each other anyway, so there is an interrelationship here to consider when setting everything up.
value will never nudge (and this aspect is conspicuously absent from the
setValue function signature) whereas most other nudging scenarios are automatically permitted where perhaps occasionally they shouldn’t be; in short, there are no doubt situations in which something different is desirable, one way or another, and precise control is lacking. Furthermore, I feel that the semantic assumptions about a three-value slider (namely that
value is the single value of interest, while
maxValue define its sliding range within a larger range) may not hold in all use cases.
Finally, this all led me to think that it could be worth introducing a more general system for this, where you could specify any number of slider thumbs and how they look/behave: the nValue[Horizontal/Vertical] Slider. That’s certainly a version 1.5 consideration, but it could inform how some of the refactorings play out in the short term.