so I have a question about the price range filer case study: if the user types wrong numbers in the min and max text field for example: min: 250$ max: 100$
so what should I do? block the apply option or instead ignore that and let the option to apply and let him see his transaction history without any price limit.
Tnx
1. How fast is the program's reaction?
If it's almost realtime, you can safely do anything smart like assuming the numbers are reversed; maybe a label should display what you understood = what's being filtered, like "Showing results between $100 and $250" so the user knows what's happening. No need to block the flow: whenever the user fixes the mistake, things will go back to normal.
If it's slow, however, like a server-side query and a costly result list rendering with images, don't let it happen before it makes sense. Either disable the Apply button (a bit annoying) or change the caption to "$100 - $250" to make it clear: "okay, this is what you're applying now". The time between realizing the mistake and having a chance to fix it is super painful to the user.
2. How irreversible is your action?
If it's a lot of work to take it back, never let it happen unless it's completely clear. If it's like an admin area and the button means "Update all products within this price range", it's gonna hurt to undo the damage. (In this specific case, of course, you'll update 0 items so it's no big deal, but the general rule is, heavy operations should never fix bogus input automatically.)
3. Can you safely understand the input?
In foreign keyboards, sometimes another letter is where zero should be, so for example in Hungarian there's a typical mistake of entering "25ö - 1ööö", it's a valid range but with bad characters. I don't think anyone would be so kind as to fix this by replacing "ö"-s to zeros, but what sites usually do is cut the integer part and ignore the rest, giving you "25 - 1" which you would autofix to "1 - 25". Bad woodoo. So I'd say make a distinction between wrong input and very wrong input; some you can fix, some just don't make any sense. If you're really nice, you can react differently on those two - but either way, keep in mind that you don't always know what the user wanted. Stay on the safe side.
TLDR: Either make it harmless & easy to fix, or block it.
I would answer this from a user perspective:
As a user I will not like multiple clicks, so if you put a disabled button, I have to type to reduce the amount and its a big discomfort. So definetely a no no
I would rather allow the user to put any max amount and the backend would take care of it by showing the data max, so for eg if the data has options for only max $1000 and the user puts max $10,000 the system will show till $1000.
Another thing to think is do you think Slider is an easier option?
You can use break charts or scale break
https://js.devexpress.com/Documentation/Guide/UI_Components/Chart/Axes/Scale_Breaks/
Depends on the usage and your user, are they looking for options, would the user change the filter a few times or just once?
-the option with the error message - can work if the user would use it just once, or has a lot of filters to do... but only after the user selects "apply" so he won't get errors while filling in the number. no need to disable the button in my opinion. just make the error message clear.
I wouldn't let the option to apply and let him see his transaction history without any price limit. that is frustrating and would make the user think there is something wrong with the system/filtering.
more options:
what is the main purpose of this feature for the user? do you have data on it? which is more significant the min or the max? if you can answer these then in situations like this I would show the significant one. (for example: most users are interested in transactions under 1000$... and leave the min 0 then the maximum is the significant one)
or you can flip the min and max before the user selects apply (bigger number on the max)- a reason for mistake can be users confused the two fields.
