Same goes for phone numbers too. When I enter a phone number into a field, only to be told on pressing submit that 'phone number cannot contain spaces', I despair for technology. So your form accepts spaces, and you made your website check for spaces, but simply removing them is beyond the capabilities of your code? Websites suck.
In the UK, bank accounts have a thing called a sort code, which is six digits, conventionally grouped into three pairs, separated by hyphens (eg 08-92-73). It seems to be completely random whether an input for these will be a text box which requires hyphens, a text box which forbids hyphens, three tiny text boxes which you have to tab between manually to enter each digit pair, or three tiny text boxes where JavaScript automatically moves the focus to the next after you have entered two digits.
Naturally, you cannot reliably paste into any of them.
But then, my bank has disabled copying everywhere sort codes are displayed anyway!
Honorable mention for microsoft windows where entering an IP address/netmask in the ipv4 adapter config screen requires you to enter digits into four tiny text boxes where tab moves your cursor to the next IP address instead of selecting the next part of the current IP address.
UX galore yet I feel we've gone backwards. The damn thing has so much padding it doesn't even fit on my full-HD monitor. Except it should, but they capped the height and made it so I have to scroll. I just don't have the words, I'll let you guys decide further from that image.
Best of all is the three boxes+javascript option when it responds too slowly and drops some of the digits you typed. And then the "automation" interferes with your attempts to correct the number. Aargh!
I'm shocked at the performance of some large websites on mobile. Apparently whatever JavaScript they use makes it impossible to type in the search box for at least 10 seconds after the page finishes loading.
I often have exactly this problem with IDEs trying to be clever. I'm typing the bits of the code in my own way, the IDE's trying to fill out bits in its own way, and the whole thing's a mess.
I've seen one which is a single text box with grey placeholder text that has hyphens ("12-34-56") yet does not accept hyphens, so you need to type in the format "123456"...
This is basically how Excel works when you use custom number formatting. You can set a number format to display numeric data in a specified way (e.g. "00-00-00" for a sort code, or "0000 0000 0000 0000" for a CC number).
Excel will store the data as a number, and display it with the selected format, but you can't type it in with the spaces etc. - it needs to be input as just a number.
The official postcode format insists on the space between the outward and inward.
I'm not sure why. The Inward code is always Number-Letter-Letter. The outward code can be variable length and format. The space is certainly beneficial for visually parsing, but why W11AA isn't valid when W1 1AA is valid is confusing.
Yes the official format includes a space. But since the postcode is unambiguous whether the space is there or not, from an UX point of view just accept either and add the space correctly in the parsing code.
Sometimes you can feel that the code has been written by an engineer who is following the 'spec' to the letter instead of thinking of UX.
Auto-inserting while typing is not a good option, IMO, for the reason you mention, and I tend not to like forms that do this sort of thing.
Let the user type in the postcode and when they submit you can parse it as a whole maybe just in the backend, insert the space and display with the space from then on. Simple.
In Australia we have an account number and a BSB - Bank State Branch number which, unsurprisingly, represents the bank, state, and branch.
These are almost universally displayed as two groups of three digits, that's seven characters, count them... separated by a hyphen and almost universally have to be entered in to a six character field, non-numeric characters not accepted.
Metro Bank has a great feature for transfer amounts. When you type an amount, commas are added automatically.
However, if you paste a number with commas in it, it will display correctly, but on the next screen you will discover it is transferring a different amount, as if it parsed the number up to the first comma.
(As an aside, this is one of the underrated things about best-practice React: that kind of bug can never ever happen. What is displayed is fixed by the rendering of the data model, never the other way around.)
What annoys me (unreasonably) is when the website then blames me by saying something like "You entered an invalid phone number." No, the phone number I entered is perfectly valid, it's that your crappy software can't parse it! <bangs head on table repeatedly>
we need a system like we have for email whereby it doesn't matter if the letters are uppercase or lowercase, as long as the information is there (email alphanumerical, credit card and phone numbers numerical). sadly there are still a few people who say or question capital letters in their email address, but that's better than being outright rejected as valid input
Incidentally: how do your customers know how you entered their email address? That's a matter that is at the discretion of the mailserver software; it can be automatically rewritten.
What you typed into your mailer isn't guaranteed to be reflected in any of the headers the recipient sees. Far from it.
