![]() The list isn’t long, but the issues are rather jaw-dropping. After receiving that feedback on Keenforms, it occurred to me that there are quite a few programmers out there who are completely unaware of the problems the number input presents. The thing is, the issues cited in that article weren’t even the primary reasons why I decided to avoid it. The UK Government posted an article detailing some of the problems related to the number input. ![]() It should be noted I am not alone in the anti-number input camp. There are so many drawbacks related to number inputs when dealing with complex and conditional logic, much of it related to JavaScript issues, that for the past few years I've decided to avoid using it. Keenforms relies heavily on JavaScript and specifically React. It’s the only way to provide instant real-time feedback when creating dynamic conditional logic. However those aforementioned forms that I’ve built with those challenging requirements all required heavy use of JavaScript. I understand some people’s aversion to JavaScript. There were also some valid complaints about developers overusing JavaScript (guilty!). Using the number input makes it easier for screen readers as well. Certain mobile devices will show a number keypad instead of the full keyboard, making it easier to enter data. It has built-in validation to verify it is a number. A number input has native increment/decrement buttons. The pro-number input crowd has legitimate concerns, primarily around accessibility. However, we only use it in the dashboard and for only the simplest inputs. *Please note that Keenforms actually does use the number input inside our app. * We do have an input that’s labeled as a number, but when you add it to your form, it actually renders as. Recently I got some feedback about Keenforms, and the criticism I heard the most was the fact that Keenforms does not use the. It makes it easier to create dynamic and conditional functionality without having to write code from scratch. Keenforms is a drag-and-drop form builder with a no-code rules engine. I’ve seen so many forms that I felt compelled to build my own form builder that could handle at least some of the more challenging requests without the hassle of writing code from scratch every time. Of all the things that I’ve learned about what not to do, one of the easiest and best pieces of advice I can share is this: unless the use case is drop-dead simple, you should avoid using the number input. I’ve learned a lot of ways to overcome those challenges: what you should do, and more importantly, what you should not do when trying to meet those challenges. Each one presented a challenge that required some sort of outside-the-box or non-standard solution. However I will say this: of all the difficult, unconventional, and unusual requirements I’ve been asked to deliver over the past 15 years, most of those tasks revolved around building forms. I won’t pretend to be the expert on all things related to forms. And of all the things I’ve built on the front end, the thing that I’ve built most often is forms. While I’ve used a lot of technologies and built a lot of stuff over the years, the thing I have done the most is the front end, i.e. Second, what if the user prefers to use hypens instead of spaces, and the script insists on deleting them and insert spaces instead? While none of these issues are catastrophic, they could be potentially annoying, and as such perhaps even cause the user to make typos.I’ve been writing code for at least 15 years. First, the user may get stuck if trying to make corrections with the Backspace key, and the script keeps reinserting a space character as soon as the user erased it. For example, a number like 112233 might be best formatted as "11 22 33", while a number like 111222 might look better as "111 222".ĭespite this I thought it was an interesting programming exercise, but ran into problems rightaway. ![]() Not only that, there may also be individual user preferences within a country (regardless of any official format rules). But in all other cases you will just be causing pain for people who live in different countries than the one you are familiar with. For example, if you are an American in America, and you only permit other Americans in America to access your website, then go ahead and enforce the American phone number format. Please also notice that except in *extremely* limited cases, trying to force a phone number input like this is antisocial, and totally stupid.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |