# How should I allow a user to input a number where not all numbers are valid?

I have an application where users need to configure certain machine settings. One of these settings is an integer percentage value, from 1-100. Unfortunately, for historical reasons, we're not actually able to support all values from 1-100, so the range of options actually has all sorts of weird "holes" in it, so it looks a bit more like this:

``````1, 2, 3, 4, *, 6, *, 8, *, 12, *, 16, 17, 18
``````

The holes aren't regularly spaced, so we can't shrink the input by only giving the users the options 1-50, or tell them to only put in even numbers, or something clever like that.

Our current method is to use a normal number input, and simply highlight invalid numbers. This makes it easy for a user to see that their selection is wrong, but it's hard to see (a) why it's wrong, and (b) what a correct number might look like.

This leads me to my question: what input element is best suited to helping a user choose a valid number in a situation where not all numbers are valid (but a finite number of numbers are valid)?

• A conventional dropdown
• There's still ~50 numbers to choose from, that's a lot of dropdown options. It also feels a bit weird to use a dropdown for a number.
• A "datepicker"-type component
• The user can type in their number (w/ validation) or select a valid number from a list of numbers shown in a pop-up below the input.
• This would end up looking essentially like a grid of numbers - is that too much like a datepicker?
• Steppers
• ~50 numbers is probably too many to choose from easily with steppers, but once a number has been set, most adjustments are probably slightly up and slightly down.
• Side question: I'd love to hear more about these historical reasons why there are certain numbers not allowed. I could understand if the values had to be divisible by 2/4/5 or something but I'm curious what the limitations are. Jan 13, 2020 at 16:57
• Why not just a grid of valid numbers always visible showing selected as well as possible values (somewhat like the latter part of your second option). Is it really needed to have a regular input visible at all? User needs to know all possible values and selected value as well as stop him from filling an invalid value - this addresses all three that too in a single click, no? Jan 13, 2020 at 18:15
• Why not just hide this from the user and get the nearest number on the backend?
– ave
Jan 14, 2020 at 9:56
• @scunliffe: We have some old machines that can only handle a certain number of configuration options before they run out of memory. There are also two other settings, each with ~5 options, and if we included the full 5 * 5 * 100 = 2500 combinations, we'd hit the memory limit. Hence, we pick the most commonly-used setting combinations and only allow those. It's definitely a weird problem! There are better fixes, but they are more difficult and involve replacing expensive equipment - getting me to figure out this solution is a cheaper option... ;)
– Johz
Jan 14, 2020 at 9:59
• @Ave looks to be thinking on similar lines to me. Is it absolutely vital that the user picks one of your valid values, or would it be acceptable to "fudge" the user's input? If the user picks 5, then you can show them the number 5 and assure them that 5 is the value you're using, but behind the scenes you can just use 4 and hope nobody notices. If this were a volume control on your website's video player, that would be fine. If this were the control panel of a nuclear reactor, perhaps less so. Jan 14, 2020 at 10:18

The user is entering a number. That some values are invalid for technical reasons does not change the nature of the user interaction. I would go with an option that is the most natural to enter a number Perhaps keep a regular number field, but when the user finishes their input, nudge the number to the closest valid option with a minor message to go with it?

• These arrows are just the default UI of the `<input type=number>` in my browser. I can type in a number, but I can also use the mouse to increment. I don’t think the arrows matter much for the answer, but there’s some value in being able to click through similar values. Jan 13, 2020 at 15:08
• For starters, "other related valid values" doesn't make a lot of sense. What makes these values "related" to the one I typed? Also, I really don't like automatically changing the user's input. I would prefer that my input be left alone exactly as I entered it, and then the suggestion text to the side could say something like, "14 is not a valid input [because ...]; did you mean 12 or 16?" Jan 14, 2020 at 4:29
• "nearby" would be better than "related". Jan 14, 2020 at 6:10
• Note, in such case arrows should not mean "+1" and "-1", but "next valid value" and "previous valid value". Otherwise on some numbers they won't work, as the number will get adjusted right back. Jan 14, 2020 at 9:30
• Thanks, this was helpful! I agree with @CodyGray that automatically changing the input probably isn't the best way to go, but the idea of showing the neighbouring values is helpful. We can also probably augment the standard number picker interactions so that "next number" and "previous number" automatically skip the invalid ones.
– Johz
Jan 14, 2020 at 10:01

I think a horizontal slider with:

• Graduations (tick marks) showing the possible values
• A handle with a triangle end pointing to those tick marks
• Snapping to the closest possible value when you drop the handle
• A feedback of the actual value
• Of course, the ability to manipulate with the keyboard
• Optionally, the ability to use arrows or +/- to move to the next/previous allowed value
• Optionally, a direct input field, with the value being rounded to the closest valid one as soon as fous is lost

would provide the clearest visual indication of the possibilities.

Here's a quick possible example (strongly inspired by the macOS liner slider with tick marks):

(I got tired of adding further tick marks) If you have arrows or +/- or if you want direct input, it would probably be better for the value to be outside of the handle, of course.

• This, if the property is a representation of an analogue quantity (volume? brightness?) with arbitrary strange digitization constraints. Add a comment explaining that the slider will be snapped to the nearest value which the hardware is capable of accepting, as tick-marked, to avoid bug reports about not being able to set X to 15. Jan 14, 2020 at 15:00
• For the cases of brightness and volume mentioned by @nigel222, both of those are actually logarithmic in humans, so it'd make more sense to show a linear scale to the user and silently scale it logarithmically in the background. Otherwise you'll have the issue a lot of TVs have where 5->10 is a huge difference in volume, but 25->30 is barely noticeable Jan 15, 2020 at 4:13
• This was my first thought as well. The slider can be really good at disallowing bad inputs Jan 15, 2020 at 17:56

Elementary factor seems to be fixing the error.

You need some intelligent code that will loop after the collection from * and if it encounters a hole, enter a value less than (index - 1) and greater than (index + 1).

Also:

1. Dropdown with 50 options is too mundane(but it's possible to implement search inside)

2. DatePicker - sounds reasonably, 2 interactions to select a number, then all available immediately.

Steppers in this case, they intuitively don't seem like good options.

You can also use a simple input. Which, if you enter *, will take the value of the nearest number.

• "You need some intelligent code that will loop after the collection from * and if it encounters a hole, enter a value less than (index - 1) and greater than (index + 1)." – I can't figure out what you're saying here. It sounds like you're saying that if the user selects an illegal value, the code should search for the next invalid value, but that doesn't seem like it would accomplish anything. Also, "less than (index - 1) and greater than (index + 1)" is impossible; maybe there was a typo there? Jan 14, 2020 at 17:04
• Thank's You wake me from letarg. maybe I conveyed my thoughts in a somewhat chaotic way. When iterating a collection (e.g. 10 elements) (1,2,3,4,5,6,7,8,9,10) in this case the index changes sequentially (from 1 to 2 to 3 to 4) let's assume that 5 is missing. The algorithm should capture this and write a value less than 6 and greater than 4, then greater than (5-1) and less than (5+1) - the only natural number satisfying this equation is - 5. Jan 14, 2020 at 17:10
• You're math expert - if I make a mistake, which is possible - I would be grateful for improvement Jan 14, 2020 at 17:16
• FWIW, not possible to search a drop down in iPhone or iPad unless a keyboard is connected. Jan 15, 2020 at 16:49

If you can combine a normal number input with a drop down menu that greys out invalid number, and centers on the number entered, with up and down arrows that go to the next valid number, that strikes me as the most intuitive.

The user should not be bothered with your historical reasons for limitations.

Prepare a mapping between valid values and consecutive numbers, e.g.:

``````Id:          1, 2, 3, 4,    5,    6,     7,     8,  9, 10
Valid value: 1, 2, 3, 4, *, 6, *, 8, *, 12, *, 16, 17, 18
``````

and present the Id's to the user only ("pick a number between 1 and 50"). Behind the screens the chosen value must be mapped to the valid setting. And when you want to present the current setting to the user, perform the reverse mapping.

I don't know the complete structure of your system, I suppose however that you may run into ambiguity with support when the users start to report their settings. Either make the support department aware of the mapping or automate the problem reports where the mapping will be effected.

EDIT:

Should "some arbitrary value" (as named in one of the comments) is putting the OP off, present a slider with range from 1 to ~50 (without naming any values on it, only "min" and "max"), read the value and map it again with the mapping of the valid values.

• I'm not sure this would work most of the time. This isn't a magic trick, you can't just ask the user to pick a number with no other information. The user needs to know what the number means in order to choose the correct value, which means entering the actual value, not some arbitrary value that maps to what they actually need behind the scenes. Jan 15, 2020 at 14:41
• I'm not sure this comment applies to my answer - the OP didn't give any context either on their "integer percentage value, from 1-100". In this case it will be a number between 1 and ~50 (as the OP indicates there are ~50 valid values).
– Mike
Jan 15, 2020 at 15:03

On first wrong input give a error message and ask user to use the tooltip. Which shows valid and invalid numbers (invalid greyed out)