"Allow Undefined Values" interface refinement

[Mads]

When we use the "Allow Undefined Values" functionality of a ring control for example, this is not graphically done by allowing entry within the controls value field as one would expect - instead a new strangely placed and scaled temporary entry point pops up next to the control. This looks bad, and makes it less obvious to the users what is going on...

To illustrate:

Now, I can understand what the developers have been thinking; if we allow the input this (the proposed) way the users might think that they can write a text, like 5000 Hz in the example above...but what they really need to input is the *value* that the undefined text would be associated with.

Well, I do not think people will automatically understand this any better by putting the input outside the regular input. Optimally it should be possible to input both a text *and* the value and then that value should stay in the control this run-time (available to be selected from then on)...That might require a pop-up dialog instead. But even if you end up with todays solution of only entering the value - the <Value> input and indication afterwards should be placed within the control. That is more intuitive to the users, and will look better than todays solution.

[AristosQueue (NI)]

Doesn't that create a problem if one of the string entries actually is a numeric value but not the same numeric value? I've seen selection rings for things like "Month" where the strings are 1 to 12 but the numeric values are 0 to 11. I have a hard time imagining any interface that would mix that kind of mapping with "enter your own value", but it does seem like the control should avoid creating that ambiguity.

[Mads]

Changing the entry point does not have much affect on the issue you raise Aristos, does it? Perhaps you are thinking about the later idea of having text and value input?

Todays behaviour is that if you select other and enter a value that already has a text then that entry in the ring gets selected. If you enter a non-existent value you get a new text in the ring with that value shown as <Value>. That behaviour can still be used even if the entry is within the control as proposed.

So in your example case, if we can choose months "1"-"12" with values 0-11, and we choose "Other" and enter the value as 11, the control will show this as month "12" (just as consfusing today as with the proposed solution...). However if we enter 12, the control will show it as <12> . -So no difference needed there to move the entry point to within the control, really...

And if "Other" gave a dialog with inputs for both text and value that dialog could do a snity check...(and we would get rid of the <Value> entries as well which would be good...

I've introduced two ideas in one here really which might not be strategically the best thing to do...but I would be happier with any one of them.

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.

[yamihere]

This should have been implemented, what are they thinking at NI? What is your workaround? I was thinking of using the mouse down event to show a pop-up.