Hacker News Reader

Comment by twic | Hacker News Reader

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!

View on HN

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.

The "." key does move the cursor to the next byte though, so you can quickly type an IP just like you would anywhere else.

Oh that's good to know, thanks!

Just look at this hot mess they are planning to replace it with:

https://imgur.com/a/bRlIpao

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.

... but not if you type dot instead!

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.

I think this way of doing things is quite common.

I've seen similar issues with postcodes as well, though it seems to have got better:

Type "LS29JT" and get an error because it does not like that you did not add the space "LS2 9JT"

Or even, type "LS2 9JT" and get an error because it does not like that you did add the space.

There’s a special place in hell for people who enforce space/no space in a postcode

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.

I think its to help with manual sorting.

Letters received need only have the W1 part read, to see where they should be sent.

When they reach Westminster, the 1AA part is read to sort them for final delivery.

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.

If you were to type

W111AA

One letter at a time, auto-inserting the space

W / W1 / W11 / W11 1 / W11 1A / W11 1AA

But for W1, you'd do

W / W1 / W11 / W1 1A / W1 1AA

Which would be jarring - you don't know when the inward code ends without typing a space, so you have to infer.

That said there's no reason not to allow [a-zA-Z0-9 ] and format after typing is finished (onBlur or even after submission).

(Poorly implemented address validation in the UK was behind the change in BFPO addresses 10 years ago -- https://fetchify.com/latest-news/lets-talk-about-bfpo-addres...)

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.

Probably the SO post I visit the most:

https://stackoverflow.com/questions/164979/regex-for-matchin...

That was an absolute delight of a read. I learned a few things. GIR OAA and SAN TA1 are wonderful postcodes.

I used to have a post code like W1F 9XX. That was fun

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.

Definitely one or my favourite minor annoyances.

Ha! Oops. I meant to put that bit about seven characters after the hyphen, thereby making seven characters. Doh.

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.)

Reply on news.ycombinator.com