On 04.12.2017 13:53, Tavmjong Bah wrote:
1. It allows for a label inside the widget. This is a nice space
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
3. It adds the ability to drag the progress bar to change the value.
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
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:
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
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
- 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
* Do you want the progress bar?
* If so, should it be the full height of the widget (quite a bit
* 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.
thorwil's design for free software: