On 04.12.2017 13:53, Tavmjong Bah wrote:
- It allows for a label inside the widget. This is a nice space saving
feature. The widget handles changing the label text from black to white as the progress bar moves across the label.
This is very valuable, as the width of the slider is critical for efficient use and an external label would be "dead" space.
I played with such designs in mockups a few times. Example attached. It's part of a series where the colors where meant to signify minimum, negative range, exact zero, positive range or maximum. Note that I reduced the gap between labels and values to ease scanning. This at the cost that activating numerical editing may require a double or modifier-click.
- It adds the ability to drag the progress bar to change the value. If
one drags from the top (down arrow cursor) the change follows the cursor directly. If one drags along the bottom half (double headed cursor) the change is finer and relative to the current value.
Please don't call it a progress bar; it's a slider and the part of it that signifies the value could be called value bar or maybe indicator
There are a few cases to handle: - fast and course adjustments - fine and slow - small steps - precise input (numerical entry)
Because of this, I think it is a worthwhile idea to handle both fast-and-coarse and fine-and-slow adjusting in a discoverable manner, no modifiers used.
After all, I spend quite some time trying to come up with a good way to do just that. See https://thorwil.wordpress.com/2007/05/01/fan-sliders/ (which I am not saying is a solution, here).
One inspiration was the astonishingly complex ladder widget in Houdini: http://www.sidefx.com/docs/houdini/basics/ladder Of course that thing exists because value ranges can be huge and fine-grained in their consequences in that application.
Having 2 ways of adjusting available without modifier is nice, but it seems the GIMP widget is often misunderstood. Upper edge is used for setting the value to where the pointer is. A jump; only then do you have a 1:1 relation between movement and value change.
Both halves suffer from the delays when the value bar is not updated until the effect of the change has been rendered. I understand why it's done that way, but have to note that it makes hitting a desired value-range harder. I might prefer some pulsing/blinking or indicating both previous value and soon-to-be value, instead.
I've always found that dragging the progress bar to be a bit awkward. One problem is that one can not start the drag at the far right of the widget as that area is reserved for typing a value directly in.
That's a non-issue for the lower half, as it doesn't matter from where you start a slide and you have plenty of area to just do that. For the upper area, the user has to figure out that they have to click to the left of the numbers and do a drag, in order to reach that part of the range. That is rather bad.
Ways to deal with the slider vs numerical input issue: - trigger input only on the lower half, allow click-jump on the entire upper half. - Put the label unto the slider, but keep the numbers outside. - Use a narrow button to the right of the main widget, as sole mean to go into numerical input. - Interpret numbers and arrow keys as input as soon as the pointer hovers the widget (incompatible with pen and touch). - Activate numerical input only on double-click or some modifier-click. - Use the upper half for 1:1 adjustment, but without jump-to-pointer. Offer an alternative jump action, e.g. on middle-click.
Since I am rewriting this widget, I can adjust it to what people want:
- Do you want the progress bar?
Yes.
- If so, should it be the full height of the widget (quite a bit more
complicated)?
Maybe.
- Do you want to be able to drag the bar? With one/two methods?
Yes. Aside of 1:1 drag, a fine adjustment could be on Ctrl-drag and jump-to-pointer on middle-click.
