Re: on value edit fields (i.e. the too small buttons inside)

On Tue,  3 Sep 2002 07:12, Friedrich W. H. Kossebau wrote:

> Is this all-over-KDE-spreaded style of offering value editing, which
> can be found one more time in the above mentioned dialog, really
> usable? These tiny buttons inside the edit field, should anybody
> really use them? What kind of mouse artists are we supposed to be? If
> I have a look at that really big slider to the right, I am not sure.

I frequently click the increase arrow in print dialogs to go from one 
copy to two copies. So I would say that for small changes, the small 
buttons are good; for large changes, sliders are better.

But I agree with you that the size of the buttons are horribly small. 
There seems to be a distressing habit among developers to make 
everything microscopically small; I guess its because all you young 
whipper-snappers still have perfect eyesight and expensive optical mice 
that never get dirty :-)

> Am I the only one to think this to be foolish? I see three problems:
>
> 1. tiny up/down buttons, hard to hit with the cursor

Agreed, with spades. Its not so much its hard to hit them, but its hard 
to hit the right one.

> 2. up/down looks like selection of predefined values

No, I don't see this at all.

> 3. no idea which values are achieved by which slider position, not
> even min/max

Sliders should *always* display values, at least start and end values. 
That's just common sense, and I'm amazed that anyone would forget that.

> Problem 1 should be solved by enlarging the icons. As they then won't
> fit anymore one above the other they have to be put somewhere else.
> Attached you can see two possibilities of which I like the first one
> better as one cannot accidentally click the wrong button.

Ah, but there is one other way of enlarging the icons. See my sample 
attached.

> Problem 2 should be solved by using -/+ symbols for de-/incremental
> steps.

I don't think Problem 2 is a problem, but if it was, I suppose this is 
a good solution.

> Problem 3 should be solved by printing the min/max values to the
> corresponding ends.

I agree.


-- 
Steven D'Aprano