August 18, 2014 at 16:30Enter fractional values without changing layouts
How often do you have to enter fractional values into the interface of a program / web service? If often, then you are likely to encounter inappropriate behavior of such fields. For example, I regularly beat my forehead about absolutely stupid forms. Want to know why entering fractional values can lead to white-hot, and what to do about it? Welcome to cat.
According to my observations, the most common algorithms for their behavior are:
In general, in the courtyard of the XXI century, interfaces are developing, and such trivial actions as entering fractional values are still a headache for users. Several years ago I had the opportunity to design (and partially code) a small program, for users of which entering fractional values was a daily task. Naturally, I did not want to repeat the behaviors described above. As a result of some thought, a rather simple algorithm was born.
So what to do with fractional numbers? First of all, you must filter the input. Checking when submitting the form is a good thing, but it’s much more convenient for the user if you can enter the value the first time, and not after the kick from the side of the script. Here is my version of such a filter:
The result of this algorithm gives an excellent(wow) effect. Users no longer need to think about the layout, press Shift and guess if the programmer took a decimal point or comma. Experiments on live users showed that after 1-2 weeks of working with such a “smart” input field, returning to normal fields causes breaking and the desire to kill the programmer to break the keyboard.
PS. Honestly, this algorithm is so simple that I'm 146% sure that this approach has been used more than once or twice. But for unknown reasons, it was not widely used (if you do not believe me, find the nearest input field and check its behavior - I’m almost sure that it will fit into one of the three “clumsy” algorithms, and not the “correct” one that I cited).
PPS For those who write in Delphi or Lazarus, I’ll give a link to the CurrencyEdit component that implements this algorithm in the corresponding language: GitHub .
PPPS I do not cite specific examples solely out of respect in the authors of the respective programs. If any of Habr’s readers finds “incorrect” algorithms in his code and decides to change them to “correct” ones, thanks from users are guaranteed.
PPPPS Somehow I’m not quite in the subject: can I filter input in principle in HTML forms ?
According to my observations, the most common algorithms for their behavior are:
- Guess where to click. Such fields are most often found in desktop applications. The field strictly filters the input of any characters except digits and decimal separator. It would seem that everything is logical. But let's conduct an experiment: close your eyes and try to enter the decimal separator in such a strict field by pressing just one button. Happened? Oh, not a fact! The problem of strict filtering is that the user: a) does not know which of the two standard decimal separators the developer used; b) when entering numbers, you may not think about the current keyboard layout. As a result, an attempt to enter a separator in more than half of the cases fails. This is not too critical if you need to enter a single value once, but when you have to enter fractional numbers you have to regularly - this form behavior is tiring.
- Accuracy is first and foremost. This type is more characteristic of the web. The input is not filtered at all, and when you try to save the form, one of three things happens: an error message is displayed; the input field is cleared (or the previous value is returned); nothing happens at all (the form is checked in the background and its submission is blocked for no reason visible to the user). Apparently, some developers naively believe that the user always knows what to enter into the form.
- Well, something like that ... The third type of clumsy forms is periodically found everywhere. Predicting their behavior is almost impossible. For example, in one good, in general, shareware-program for conducting home accounting, when you try to enter an incorrect decimal, divide (more precisely, when you click the button with the separator symbol not in the current layout), the whole part of the number disappears without a trace. In another (also far from free) utility, entering any character other than a digit and the separator expected by the program generally raises a system exception. Finally, at one very large Russian online store, entering any invalid character leads to the insertion of a decimal point and two zeros in the fractional part, and entering a point leads to ... inserting a decimal point.
In general, in the courtyard of the XXI century, interfaces are developing, and such trivial actions as entering fractional values are still a headache for users. Several years ago I had the opportunity to design (and partially code) a small program, for users of which entering fractional values was a daily task. Naturally, I did not want to repeat the behaviors described above. As a result of some thought, a rather simple algorithm was born.
So what to do with fractional numbers? First of all, you must filter the input. Checking when submitting the form is a good thing, but it’s much more convenient for the user if you can enter the value the first time, and not after the kick from the side of the script. Here is my version of such a filter:
- Allow entering numbers from 0 to 9.
- When you press any button that carries any possible decimal separator in any layout, you need to replace the character sent from the keyboard with the correct decimal separator in the input field.
- block the attempt to enter more than one decimal separator.
- we limit the number of characters in the fractional part of the input number, depending on the type of data entered.
Example 1. A user in the Russian layout sequentially presses the keys [1] [2] [3] [b] [4] [5]. Result in the input field:123.45Example 2. A user in the English layout sequentially presses the keys [1] [2] [3] [Shift +?] [4] [5]. Result in the input field:123.45The result of this algorithm gives an excellent
PS. Honestly, this algorithm is so simple that I'm 146% sure that this approach has been used more than once or twice. But for unknown reasons, it was not widely used (if you do not believe me, find the nearest input field and check its behavior - I’m almost sure that it will fit into one of the three “clumsy” algorithms, and not the “correct” one that I cited).
PPS For those who write in Delphi or Lazarus, I’ll give a link to the CurrencyEdit component that implements this algorithm in the corresponding language: GitHub .
PPPS I do not cite specific examples solely out of respect in the authors of the respective programs. If any of Habr’s readers finds “incorrect” algorithms in his code and decides to change them to “correct” ones, thanks from users are guaranteed.
PPPPS Somehow I’m not quite in the subject: can I filter input in principle in HTML forms ?