In the world of forms, there are two types of data input found on text fields. There’s data input that has no format (characters only). Then there’s data input that has a format (characters and symbols). You should not treat both types of data input the same.
Many designers put the responsibility on the user to format their data input. This causes major user experience problems when users fill out formatted data fields.
Format Uncertainty Leads to Abandonment
When users type their input they will notice that it isn’t formatted. This will make them wonder whether they should type the symbols in or not. This uncertainty can make some users uncomfortable and lead them to abandon the form.
Users who choose to type in the format will need to press extra keys to include the symbols. More typing increases their chance of making errors. This can slow them down even more and give them more reason to abandon the form.
Not only that but now there’s uncertainty on which symbols to use for the format. For example, users could use hyphens or periods to separate strings on a phone number. On a date, they could use slashes or hyphens.
The uncertainty of which format to use creates more mental work for the user. It also makes them question whether their data input will be valid or not.
Lack of Formats Make It Hard to Correct Mistakes
There are users who will choose not to add any symbols to their input just to be on the safe side. But the downside to this is that any mistakes they make will be hard to find and correct.
For example, a credit card number displayed without hyphens is hard to check and correct. The user isn’t going to memorize the entire number because it’s too long (up to 19 digits). Instead, they’ll scan a small set of numeric strings on the card to check their input.
They’re going to struggle to find which number they’re on each time they look back at their input. The lack of format makes all the numbers run together causing confusion. The fact that a credit card number can use the same digit more than once only makes it more confusing.
Format Your Fields with Input Masks
The best way to fix this user experience problem is to use input masks on formatted data fields. Input masks will auto insert the correct format in the field as the user types their input. They don’t have to type any symbols.
They no longer have to worry about which format to use or leaving it out. It eliminates format uncertainty which will prevent form abandonment. Seeing their input in the correct format will make checking and correcting mistakes easier.
You should apply input masks to data fields that have a specific format. These are data that contain symbols, such as time, dates, phone numbers, postal codes, social security, serial numbers and credit card numbers.
Treat Formatted Data Fields Like VIPs
Most text fields require characters only. But those that require symbols for a specific format deserve special attention. Don’t ignore them and leave the user to figure out the format. Take responsibility for the data input you get and always use input masks to specify your format.
Book
Affiliate
Which library for this would you recommend?
https://igorescobar.github.io/jQuery-Mask-Plugin/
This can get quite annoying if the user types the characters added in the input mask (e.g. the dashes in the credit card number) and then inserts an incorrect character.
This could be compensated for by e.g. still accepting the mask’s characters, but discard them when they’re in the mask’s characters’ place. But the implementation of that can get unwieldy, with a significant risk of introducing bugs in input patterns that you didn’t think of, degrading the user’s experience.
Therefore, I tend to err at the side of caution and do not tamper with the user’s input. Instead, I tend to be forgiving – accept the user typing dashes or leaving them out, and clearly indicate while typing whether the format is valid of not (and it will be valid most of the time due to the forgiveness).
Recently hit a wall when trying to make a CC number input trigger the numerical keyboard on mobile.
Currently, it seems you can’t have both, so it’s one thing or the other.
So, as about 50% of my conversions come from mobile (and rapidly growing), I opted for unmasked fields until I can find a better solution.
Sorry, I forgot to mention the problem is to trigger the correct, numerical keyboard on a masked input.
From a UX point of view this is absolutely correct and input masks are a better experience.
HOWEVER from an implementation perspective on the web this is much easier said than done. I am yet to find an open source plugin that both optimises input masks AND native mobile numeric and date virtual keyboards.
Also in practice interfering with users keypress by adding separators as they type introduces lots of bugs on device keyboards.
So if you are making sacrifices for one user group over another you need to be very careful about who gets the ‘optimal’ experience.
Be careful with using Input Masks if you want to target people with disabilities as well. Input masks do not work well with screen readers. An alternative to this would be:
https://github.com/filamentgroup/politespace
It only formats when the user’s focus leaves the field and unformats when they focus on it again.