I've always found it weird when a form admonishes you for writing spaces or dashes in e.g. a phone number or credit card number. Hey, implementation, you're a computer! Strip them out automatically on the backend if you don't like them!
As someone who uses Programmer Dvorak I often encounter pages where the js uses `event.code` instead of correct `event.key`. Silent discards of the shift key also affect Programmer Dvorak as the numbers require it.
Actually programmers use the symbols far more frequently than the numbers. The number row on Programmer Dvorak is, from left-to-right,
& [ { } ( = * ) + ] ! #
Looks really weird at first glance! but if you try it out, [square brackets] and (parens) are symmetrical fingers on opposing hands. By hand, [] is the ring fingers (2,0 on a qwerty). {} is (3,4 on the left-hand) and () is 5,8 aka your pointing fingers, left hand then right.
Having the luxury of the parens and frequent symbols (especially if you code Clojure or a Lisp) on the tippy-top row is awesome.
Plus, the numbers are also split by hand!
From middle-going-out:
Left hand: 91357
Right hand: 02468
Which lets you type numbers without looking for them by eye :)
There were lots of very in-depth UI studies in the 90s, which were implemented in the second half of the 90s and early 00s. Then someone let “designers” in the door and it was all thrown out.
First off: I’m not really well-versed in terms of UX design, so these next guesses are as good as anyone’s:
- Six boxes communicate “== six digits, != password” (try to imagine the least tech-savvy user)
- Some people might not be able to quickly hold six digits in their head at once (especially seems to be the case with older people, from my experience), so seeing “I’ve already got two/three/four” visually is potentially an efficiency boost. This also correlates (again, just from my anecdotal experience) with the population that doesn’t have a password manager handling 2FA for them automatically…
- This is probably down to preference, but IMO it also feels faster somehow than a single input field with six digits, when it works properly (with the caveat that it feels much worse/slower if it doesn’t work)
- Now that everyone does it, you’re kinda forced to adopt it as well for recognizability.
But it’s an interesting question – we can’t ever imagine entering postal ZIP codes like that and yet that’s an area where it’d actually make more sense since there’s usually some notion of “more significant” digits at the start vs. end, so you could perhaps do some cool tricks with regard to pre-filtering state, city etc. names. Whereas OTP codes are (AFAIK) essentially fully random digits with no meaningful distinction.
I have two products in the wild with PIN entry for kiosk users that have a regular text input field. I have been asked if it could be the typical single digit boxes thing like this, but _never_ by the actual kiosk users. The kiosk users don’t celebrate my input type choice either. It just goes to show that most users won’t even see the details unless they are impacted by those choices.
Web developer classic: use Javascript to replace the native, working, internationally supported standard inputs with a different input mechanism that doesn't work.
(saving you a click: AZERTY has digits on the shift key, and for some reason the JS is handling raw keys rather than processed characters)
My most hated one is not allowing me to right-click to open a context menu, or even worse, making right-click act the same as left-click, redirecting me to some page I never intended to go to.
Same. Whenever I visit a website and it has that ridiculous scroll-smoothing JavaScript, I get so annoyed because I have pixel-level trackpad scrolling on macOS and they're just making it feel terrible.
Another peeve I have with this type of input is when entering the last digit automatically submits the form. Once I fat-fingered the last digit and was about to hit backspace, but it was too late, the form submitted and verification failed. I had to wait an excruciating amount of time for the SMS send rate limit to expire before I could try again (I no longer remember which service this was for).
Same, but for dates. There's <input type="date">; it's literally a solved problem ffs. Forcing to scroll through years, months and days in your remarkably creative date selection widget is extremely user hostile.
On their website, when I enter a digit, the cursor advances to the next input box automatically. Deleting a digit with backspace also jumps back to the previous box. Seems to work perfectly for me. Maybe fixed since yesterday?
Read a bit further and the reason they had the issue was their uncommon keyboard layout, which is one that requires holding the shift key to access numeric digits. This broke the input filtering logic.
From a worldwide perspective, it is incredibly uncommon, and just from the basics of this issue it is clearly uncommon in Switzerland as well. The standard keyboard layout in Switzerland is QWERTZ (across all of its language speakers). This website is generally only used by the Swiss.
I mean, if a basic authentication mechanism of a critical government website doesn't work with a keyboard layout, odds are incredibly likely that said keyboard layout is uncommon. Like not one of the developers, testers, stakeholders, or even other users had a problem -- and this isn't a problem you can just ignore -- so it probably isn't that big of a deal.
Yet another example where using <form method="post"> and <input> with zero JavaScript would be a better user experience. If you are going to write custom code you have to clear the minimum bar of what the browser provides.
I've always found it weird when a form admonishes you for writing spaces or dashes in e.g. a phone number or credit card number. Hey, implementation, you're a computer! Strip them out automatically on the backend if you don't like them!
As someone who uses Programmer Dvorak I often encounter pages where the js uses `event.code` instead of correct `event.key`. Silent discards of the shift key also affect Programmer Dvorak as the numbers require it.
> Silent discards of the shift key also affect Programmer Dvorak as the numbers require it.
That sounds... aggressively unergonomic. Are programmers not expected to frequently use numbers?
Actually programmers use the symbols far more frequently than the numbers. The number row on Programmer Dvorak is, from left-to-right,
Looks really weird at first glance! but if you try it out, [square brackets] and (parens) are symmetrical fingers on opposing hands. By hand, [] is the ring fingers (2,0 on a qwerty). {} is (3,4 on the left-hand) and () is 5,8 aka your pointing fingers, left hand then right.Having the luxury of the parens and frequent symbols (especially if you code Clojure or a Lisp) on the tippy-top row is awesome.
Plus, the numbers are also split by hand!
From middle-going-out:
Left hand: 91357 Right hand: 02468
Which lets you type numbers without looking for them by eye :)
We use the ( ) [ ] { } keys more often than numbers, so it works out nice
> So statistically speaking I’m surprised that this bug hasn’t been noticed and fixed yet!
I'm not so surprised, given that you cannot write support tickets if the bug prevents you from registering...
Also, I don't think people have high hopes that a broken government website will ever get fixed.
Reading this makes me feel like we have not learned any lessons at all in software engineering and UI design since the 1980s.
There were lots of very in-depth UI studies in the 90s, which were implemented in the second half of the 90s and early 00s. Then someone let “designers” in the door and it was all thrown out.
IBM CUA (1987) should be required reading https://en.wikipedia.org/wiki/IBM_Common_User_Access
Maybe, but I’ve searched for it many times out of curiosity, but have never managed to locate it online, and wouldn’t know if paper copies exist.
From Wikipedia, I get to https://web.archive.org/web/20010204033600/http://publib.bou...
That has one live link: https://web.archive.org/web/20010107084700/http://publib.bou..., but from there, the trail runs dead.
Do you have a link?
This one maybe? https://archive.org/details/ibm-saa-cua-basic-interface-desi...
PDF link in the box on the right.
pdf contains plenty of labels "PICTURE 73 HERE" but not pictures. That's pretty important for a book about UI...
FWIW In the Apple ecosystem this usually gets filled in automatically based on the source.
I'm curious if there's a reason this six-cell mechanism has become the defacto?
It seems this should just be a single input field styled appropriately, but it feels like there must be an underlying reason I'm missing.
First off: I’m not really well-versed in terms of UX design, so these next guesses are as good as anyone’s:
- Six boxes communicate “== six digits, != password” (try to imagine the least tech-savvy user)
- Some people might not be able to quickly hold six digits in their head at once (especially seems to be the case with older people, from my experience), so seeing “I’ve already got two/three/four” visually is potentially an efficiency boost. This also correlates (again, just from my anecdotal experience) with the population that doesn’t have a password manager handling 2FA for them automatically…
- This is probably down to preference, but IMO it also feels faster somehow than a single input field with six digits, when it works properly (with the caveat that it feels much worse/slower if it doesn’t work)
- Now that everyone does it, you’re kinda forced to adopt it as well for recognizability.
But it’s an interesting question – we can’t ever imagine entering postal ZIP codes like that and yet that’s an area where it’d actually make more sense since there’s usually some notion of “more significant” digits at the start vs. end, so you could perhaps do some cool tricks with regard to pre-filtering state, city etc. names. Whereas OTP codes are (AFAIK) essentially fully random digits with no meaningful distinction.
I'm guessing someone at some point thought that preventing copy and paste would stop bots, then everyone copied them.
> It seems this should just be a single input field styled appropriately
Anecdotally, this seems to be the case on the majority of websites where I have to use such 2FA codes.
I have two products in the wild with PIN entry for kiosk users that have a regular text input field. I have been asked if it could be the typical single digit boxes thing like this, but _never_ by the actual kiosk users. The kiosk users don’t celebrate my input type choice either. It just goes to show that most users won’t even see the details unless they are impacted by those choices.
Web developer classic: use Javascript to replace the native, working, internationally supported standard inputs with a different input mechanism that doesn't work.
(saving you a click: AZERTY has digits on the shift key, and for some reason the JS is handling raw keys rather than processed characters)
Former web dev here, you’re… right :-/ the only thing that angers me more than this pattern is when they decide to fuck up scrolling
My most hated one is not allowing me to right-click to open a context menu, or even worse, making right-click act the same as left-click, redirecting me to some page I never intended to go to.
These are all great nominations.
Crazy to add complexity like this.
Same. Whenever I visit a website and it has that ridiculous scroll-smoothing JavaScript, I get so annoyed because I have pixel-level trackpad scrolling on macOS and they're just making it feel terrible.
On X.com on my Chrome browser I am unable to correct digits if I entered a wrong number.
Very nice blog layout btw.
Another peeve I have with this type of input is when entering the last digit automatically submits the form. Once I fat-fingered the last digit and was about to hit backspace, but it was too late, the form submitted and verification failed. I had to wait an excruciating amount of time for the SMS send rate limit to expire before I could try again (I no longer remember which service this was for).
Same, but for dates. There's <input type="date">; it's literally a solved problem ffs. Forcing to scroll through years, months and days in your remarkably creative date selection widget is extremely user hostile.
On their website, when I enter a digit, the cursor advances to the next input box automatically. Deleting a digit with backspace also jumps back to the previous box. Seems to work perfectly for me. Maybe fixed since yesterday?
Read a bit further and the reason they had the issue was their uncommon keyboard layout, which is one that requires holding the shift key to access numeric digits. This broke the input filtering logic.
It's not uncommon it's used in France, which has a population of 66M (also Belgium).
This is just a classic case of a developer situated firmly at the first peak of the Dunning Kruger graph.
From a worldwide perspective, it is incredibly uncommon, and just from the basics of this issue it is clearly uncommon in Switzerland as well. The standard keyboard layout in Switzerland is QWERTZ (across all of its language speakers). This website is generally only used by the Swiss.
I mean, if a basic authentication mechanism of a critical government website doesn't work with a keyboard layout, odds are incredibly likely that said keyboard layout is uncommon. Like not one of the developers, testers, stakeholders, or even other users had a problem -- and this isn't a problem you can just ignore -- so it probably isn't that big of a deal.
Yet another example where using <form method="post"> and <input> with zero JavaScript would be a better user experience. If you are going to write custom code you have to clear the minimum bar of what the browser provides.