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!
> Hey, implementation, you're a computer! Strip them out automatically on the backend if you don't like them!
This is one of my most hated categories of pet peeves, software that does something in a way that causes a human to have to expend effort every time they use it which could easily be fixed by one-time effort on the developer's part, but the developer is either uninterested or hostile to the idea of fixing it. Computers exist to do the tedious stuff for us, if software makes us do tedious stuff for it that could be avoided with a bit more work on the software side then the software is wrong.
"Enterprise" software on Windows that "requires admin" has been a long time top subcategory here, where in literally 100% of cases I've ever dug in to in 20+ years of professional IT they could change a couple of default paths to point either within the user's private folders or a common user-accessible folder like ProgramData and solve it forever, but instead they tell people to give everyone local admin and people who don't know better actually listen to that idiocy while competent administrators are forced to fire up ProcMon and track down what it's doing so they can bodge around it by pushing out permissions changes or config changes through their management platform of choice.
> software that does something in a way that causes a human to have to expend effort every time they use it which could easily be fixed by one-time effort on the developer's part, but the developer is either uninterested or hostile to the idea of fixing it.
Yes, exactly! It's like devloper doesn't understand that automating thibgs like this is the point of computers.
Especially in the UK, bank sort codes are typically presented to the user as e.g. 04-00-04 by every banking app or website, but whenever you have to enter them (e.g. to pay someone else) they usually require you to not enter the dashes. Some of the most annoying sites limit the input to 6 characters but don't strip out the dashes, so you'd end up with 04-00- and then it complains.
And then there are the ones that implement it as 6 separate boxes, and these are the only fields in the form that auto advance to the next field on input and also often break delete if you want to undo the previous digit.
Hey, Monzo's Sort code, the first one to my knowledge to start with a zero. I spent six months unable to pay my council tax bill because their stupid system was treating the sort code as an integer and therefore dropping the leading zero, on the backend, before
Hey, Monzo's Sort code, the first one to my knowledge to start with a zero. I spent six months unable to pay my council tax bill because their stupid system was treating the sort code as an integer and therefore dropping the leading zero, on the backend, before validating that it had six digits. At one point they asked me if I'd be willing to sign up for a different bank.
Not sure about whether it's the first to have a leading zero or not. Certainly the -04 at the end suggests it was one of the first in the 04- block, but then again most banks have multiple sort codes, so who knows.
I'm not really sure how these get allocated, but looking through some of my payment recipients, Revolut is also lowish in this block with 04-00-67, but also with leading zeros, Santander has 09-01-32 and 09-01-33, co-op has 08-92-99, Nationwide has 07-01-16, 07-08-06, 07-19-86.
That looks to me almost like potentially a bank can get a sort code block as large as just the first 2 digits, e.g. Nationwide which has been around for a long time and all seem to start 07-. But that doesn't explain then why Monzo and Revolut are both in the 04-00- block.
EDIT: it seems that sort codes are assigned by pay.uk [1] and Wikipedia has a surprising amount of information [2]. Most interestingly, originally banks were 2 digits long, and so each bank had their own 2 digit prefix, and the single digit banks had a zero appended, so e.g. NatWest was originally Westminster (6) and became 60-. There's a whole load of 04- sort codes for "Utility Banks" [3] and Monzo seems to have been the second such bank (BFC is before it, but 04-00-01 is unlisted, so maybe Monzo was the third).
This is a common frustration in Australia with the ABN (business numbers), they are 11 digits but commonly shown with spaces, including on the ABN registry. However many sites have the 11 character limit.
I have a keyboard shortcut to easily enter my email address. On certain forms it inadvertently adds an invisible space at the end. So many forms complain that I didn’t enter a valid email address. They should be ignoring or stripping any trailing spaces!
The amount of forms, even on government websites that can't do the unfathomably complicated logic of stripping the space if it doesn't want it is baffling.
Regarding your credit card example, in my password manager where I paste my credit card number from, I added a no-spaces copy of the number for me to paste in because practically every input on the internet accepts spaces but has a max character limit. So if I paste it in with the spaces, it'll cut off the last 3 digits, making me go back, delete the spaces, and manually type in my last 3 digits that were removed.
Not having the space looks and feels wrong, and I think the post office would agree. I have a feeling the trend toward space omission was due to fields formatted for US zips.
But you can just add the space back in! It’s a strict format of six characters, alternating digits and letters, with a space. There is no deviation. You can easily write a parser and a formatter for it. It kills me how often this is a struggle on forms.
Fun fact: even the “send a free letter to santa” is compliant by making his postal code “H0H 0H0”
It goes against Postels law, but it's much simpler and less error prone to only accept data in the representation you actually use for further processing, vs writing an ad-hoc parser and normalizer.
I use spaces everywhere I can, it’s part of a pattern I use that’s easy for me to remember for when I have to enter it often, and the space usually counts as a special character. I’d say 90-95% of the time it works.
I do but then again I am different in that I built a secondary keyboard that (macro) types long passwords for me. Bank site: Shift H. Think of it as a password manager that has an encrypted index (my brain) using hardware and without the index is mess of random characters. Portable and external.
Yes, for every time a bug like this is discovered and reported, there are probably hundreds of times when someone else just gave up or found a work around after much frustration.
I'm frequently astonished by how terrible and buggy modern software can get away with being and still survive. Working around bugs to accomplish what I need to accomplish is so normal to me now that I sometimes don't even notice how terrible the software is until I see someone less technically skilled than me try to use it.
If you have an issue with an open source software, you need to register on a website that is made for developers, that will try to sell you a git hosting service, write a bug following a technical format, and you are expected to given information in a reproducible way.
If you have an issue with a closed source freeware, you just use a contact form on their website or leave a comment on their blog or whatever.
The amount of friction to report a bug that FLOSS puts on users is absolutely insane. It's almost like it's trying to deny anyone who isn't a technical person from reporting problems they are having.
GitHub is meant for developers. Plenty of OSS has forums or Zulip/Discord chats for ordinary users to get support in a more casual way. Sometimes not, but there's just as much closed source software with poor support too.
It's been noticed, but nobody with access to the website has been told or cares. The author is almost certainly the first person to do a root cause analysis and come up with the solution though.
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.
While it started beforehand, it was really smartphones and especially the iPhone that gave so many UI guys an excuse to discard all of the studies of the past and start from scratch. "Oh, but it's a touch interface, these lessons are about mouse users, certainly discoverability and clearly differentiating UI elements don't apply anymore. Our users are so smart they will just know that a half swipe from the middle of the object is different than a half swipe from the edge, and they don't have to be told about functionality that is infused at birth now."
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 :)
What is the advantage of this order vs. numerical order? If I'm reading your post correctly the numbers are arranged 7531902468 on the keyboard, with maybe a space in the middle? Is there some mathematical property where odd and even numbers are more likely to alternate than for odds or evens to be found side by side? Maybe 0 is more likely to appear so they want it on an index finger? It just seems unlikely that the next most common digit is 9, unless this was developed by people who set prices on items.
Very simply: if it's an even number, it's your left hand. If it's an odd number, it's your right hand. If you want to type a number like 2,467,333 you can do it without looking for the numbers. On qwerty I tend to "lose my footing" when it comes to typing numbers out. But if it's a 2 on programmer-dvorak, it's right hand, index finger. 2468 is each of your four digits, in order. and 1357 is the other hand's digits. However, I hold left-shift to access the numbers which means my pinky is unavailable for the left numerical ascension, so I tend to do 1 and 3 with my index, and 5 with middle, and 7 with ring. Nine [9] and Zero [0] are "stretch" numbers in the middle: 9 and 0 are reached via one's index fingers going diagonally toward the middle of the tippy-top row.
tl;dr: right hand even,, left hand odd,,, increasing from index to pinky. "Look ma, no eyes!"
That doesn't suit my lifestyle - never going to drag a keyboard to a coffee shop, for example. Also I would gently challenge the notion that people are able to type numbers without looking accurately on a standard keyboard. Can you type 15,483,523 on the first try with no errors? Because when I try on qwerty mode I get 26,584,634 lol.
I use a layout with an AZERTY-style shifted digit row for coding (and for everything else). A quick check of one C++ codebase I've been working with shows ~20× as many instances of digit-row symbols as digits (18× for QWERTY digit-row symbols, 27× for those in my layout), though C++ is unusually symbol-heavy. A couple of ECMAScript repositories show 3× or 10×. On some Common Lisp, digit-row symbols are 5× as common as digits for my layout and 22× for QWERTY (almost entirely because QWERTY parentheses are terrible). I don't expect to see a lot of code where numeric literals are more common than type modifiers and operators and such… most of the times numbers are being manipulated in code, they're not being typed in directly as digits but going through comparisons and arithmetic and such, and that's symbols.
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.
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.
My equally uninformed guess is that the presence of six empty boxes communicates that the code entered must be exactly six digits long in a way that a generic text input doesn't. It clearly delineates the digits which makes it easy to see how many you've entered and how many are empty, and the presence of an empty box suggests that it needs to be filled while a number that's simply shorter than the input field doesn't. At least, that's my steelman; maybe browsers should check if a field's min-length and max-length are the same and style them similarly?
I think people were entering the SMS short code the digits were sent from instead of the digits so they wanted to make it clearer that it was 6 digits they want you to look for.
When I get sent a verification code from myGov (via text message), the message contains the 6 digit code, AND a 6 digit phone number for the help desk. I have to stop and double check which is the code, because I have accidentally entered the phone number many times.
I wish they were just regular inputs. A significant portion of them I encounter have some kind of cursor navigation or paste bug. I think this mechanism is the perfect Goldilocks-zone control of simple enough that people rewrite it from scratch, but text input has enough hidden complexity that it's easy to get something wrong.
Santander's banking website uses both in some places, e.g. confirming a new payment. "Enter your 5-digit PIN and the 6-digit 2FA code we've just sent you", with 5 little input fields for the former, and a single standard input field for the latter. Perhaps a deliberate decision to make them look different, but it just looks like they couldn't make up their mind.
That sounds quite likely. Not the stopping bots part, just the idea that someone chose to do it for some reason, and everybody copied them without knowing the reason. Happens all too often.
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.
Likewise usurping Ctrl-F with their own shitty global search function rather than the perfectly good page search provided by the browser. Looking at you, Confluence.
Usually Ctrl-F still works for me, but / almost always gets consumed by the stupid search that never works properly. But then that's usually because you're on a site with infinite scroll so even the Ctrl-F search is going to be limited, even if you are in the correct thread.
One thing is really dislike about modern UI design is where you see a headline that seems kinda interesting but you don't click on it right away. Come back a bit later and it's just gone. There was some A/B testing on the headline and now it's completely different, probably now all clickbaity so I won't be inclined to check it out.
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.
I've seen cases where it was done well, but unless you're willing to invest great engineering effort into making sure it's done well, the built-in version (which already has had a lot of engineering effort put into it) is almost always going to be better.
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.
My pet peeve is in the "create a report" section of InvestEngine (useful for doing reports aligned to tax year). If you try to type a date at all, the year always ends up as 000n and no amount of typing numbers will get it to accept a 4 digit year (or even a 2 digit year starting 20). The only way to undo this state is to click today and then page through the years and months using the arrows on their stupid date widget.
Not investigated what framework it's using, but it looks like a mobile app compiled to WASM. It's just something I need to put up with I guess, it's just annoying when I need to generate a bunch of reports every year for my company end-of-year accounts, so it's not worth wasting time on trying to automate.
Unfortunately, with the mobile OS's datepickers being so bad from a usability perspective, it's a long way from being a solved problem. Typing the date directly into a single textbox is great for some of us but not for others, so an alternative has to be provided.
Yes, some date selection widgets can be poorly designed and user hostile, but the well-designed ones tend to be fine. The ideal, based on real user research by gov.uk, appears to be to use 3 separate textboxes, instead of <input type="date">.
I just tested on all the devices I have at hand and they let me pick or type, and the picker is usable. Is this an iPhone problem? Because it sounds like an iPhone problem.
The link I gave there explains the problem. The picker is perfectly usable if you know how it's meant to be used - like most things really. The problem is the flat design, controls looking like headings rather than controls, leading to a surprising number of people not having any idea of how to change the year.
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.
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.
I'd understand a developer in e.g. America not being aware of it, but to one in Switzerland, France is right next door. A developer working on something as important as their government login system should be well aware of different keyboard layouts surrounding, and leaking into, their country.
Yes, I understand where France is relative to Switzerland. But the basic fact remains that not one of the developers or testers or stakeholders encountered this, and it was so rare apparently the very first person to encounter it -- given that it was literally a blocking issue, and not just some transient issue -- is the linked article.
Is it a regrettable bug that made a poor assumption that breaks in special cases? Sure. Is it "Dunning-Kruger" (groan), or some demonstration of how stupid the developers are? Give me a break.
The Dunning-Kruger thing wasn’t meant to disparage the developer and certainly not to call them stupid. It’s simply a reflection on not knowing what you don’t know and thinking you know more than you do. Everyone goes through that.
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!
> Hey, implementation, you're a computer! Strip them out automatically on the backend if you don't like them!
This is one of my most hated categories of pet peeves, software that does something in a way that causes a human to have to expend effort every time they use it which could easily be fixed by one-time effort on the developer's part, but the developer is either uninterested or hostile to the idea of fixing it. Computers exist to do the tedious stuff for us, if software makes us do tedious stuff for it that could be avoided with a bit more work on the software side then the software is wrong.
"Enterprise" software on Windows that "requires admin" has been a long time top subcategory here, where in literally 100% of cases I've ever dug in to in 20+ years of professional IT they could change a couple of default paths to point either within the user's private folders or a common user-accessible folder like ProgramData and solve it forever, but instead they tell people to give everyone local admin and people who don't know better actually listen to that idiocy while competent administrators are forced to fire up ProcMon and track down what it's doing so they can bodge around it by pushing out permissions changes or config changes through their management platform of choice.
> software that does something in a way that causes a human to have to expend effort every time they use it which could easily be fixed by one-time effort on the developer's part, but the developer is either uninterested or hostile to the idea of fixing it.
Yes, exactly! It's like devloper doesn't understand that automating thibgs like this is the point of computers.
Especially in the UK, bank sort codes are typically presented to the user as e.g. 04-00-04 by every banking app or website, but whenever you have to enter them (e.g. to pay someone else) they usually require you to not enter the dashes. Some of the most annoying sites limit the input to 6 characters but don't strip out the dashes, so you'd end up with 04-00- and then it complains.
And then there are the ones that implement it as 6 separate boxes, and these are the only fields in the form that auto advance to the next field on input and also often break delete if you want to undo the previous digit.
Hey, Monzo's Sort code, the first one to my knowledge to start with a zero. I spent six months unable to pay my council tax bill because their stupid system was treating the sort code as an integer and therefore dropping the leading zero, on the backend, before
Hey, Monzo's Sort code, the first one to my knowledge to start with a zero. I spent six months unable to pay my council tax bill because their stupid system was treating the sort code as an integer and therefore dropping the leading zero, on the backend, before validating that it had six digits. At one point they asked me if I'd be willing to sign up for a different bank.
Not sure about whether it's the first to have a leading zero or not. Certainly the -04 at the end suggests it was one of the first in the 04- block, but then again most banks have multiple sort codes, so who knows.
I'm not really sure how these get allocated, but looking through some of my payment recipients, Revolut is also lowish in this block with 04-00-67, but also with leading zeros, Santander has 09-01-32 and 09-01-33, co-op has 08-92-99, Nationwide has 07-01-16, 07-08-06, 07-19-86.
That looks to me almost like potentially a bank can get a sort code block as large as just the first 2 digits, e.g. Nationwide which has been around for a long time and all seem to start 07-. But that doesn't explain then why Monzo and Revolut are both in the 04-00- block.
EDIT: it seems that sort codes are assigned by pay.uk [1] and Wikipedia has a surprising amount of information [2]. Most interestingly, originally banks were 2 digits long, and so each bank had their own 2 digit prefix, and the single digit banks had a zero appended, so e.g. NatWest was originally Westminster (6) and became 60-. There's a whole load of 04- sort codes for "Utility Banks" [3] and Monzo seems to have been the second such bank (BFC is before it, but 04-00-01 is unlisted, so maybe Monzo was the third).
[1] https://www.wearepay.uk/what-we-do/payment-systems/access-to...
[2] https://en.wikipedia.org/wiki/Sort_code
[3] https://en.wikipedia.org/wiki/Sort_code#04_codes
This is a common frustration in Australia with the ABN (business numbers), they are 11 digits but commonly shown with spaces, including on the ABN registry. However many sites have the 11 character limit.
And of course you often cannot paste a 6-digit number into these fields. You have to type all 6 digits by hand.
I have a keyboard shortcut to easily enter my email address. On certain forms it inadvertently adds an invisible space at the end. So many forms complain that I didn’t enter a valid email address. They should be ignoring or stripping any trailing spaces!
In Canada our postal codes are formatted:
X#X #X#
Where X is a letter and # is a digit.
The amount of forms, even on government websites that can't do the unfathomably complicated logic of stripping the space if it doesn't want it is baffling.
Regarding your credit card example, in my password manager where I paste my credit card number from, I added a no-spaces copy of the number for me to paste in because practically every input on the internet accepts spaces but has a max character limit. So if I paste it in with the spaces, it'll cut off the last 3 digits, making me go back, delete the spaces, and manually type in my last 3 digits that were removed.
Not having the space looks and feels wrong, and I think the post office would agree. I have a feeling the trend toward space omission was due to fields formatted for US zips.
But you can just add the space back in! It’s a strict format of six characters, alternating digits and letters, with a space. There is no deviation. You can easily write a parser and a formatter for it. It kills me how often this is a struggle on forms.
Fun fact: even the “send a free letter to santa” is compliant by making his postal code “H0H 0H0”
It goes against Postels law, but it's much simpler and less error prone to only accept data in the representation you actually use for further processing, vs writing an ad-hoc parser and normalizer.
APIs, yes - humans, no.
a password with a space at the end would be broken in many systems.
Does anyone even use passwords with spaces? I've always wanted to try and find out how many sites can't handle it.
I use spaces everywhere I can, it’s part of a pattern I use that’s easy for me to remember for when I have to enter it often, and the space usually counts as a special character. I’d say 90-95% of the time it works.
If you're living the passphrase life then spaces make them easier to type.
I do but then again I am different in that I built a secondary keyboard that (macro) types long passwords for me. Bank site: Shift H. Think of it as a password manager that has an encrypted index (my brain) using hardware and without the index is mess of random characters. Portable and external.
> 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.
Yes, for every time a bug like this is discovered and reported, there are probably hundreds of times when someone else just gave up or found a work around after much frustration.
I'm frequently astonished by how terrible and buggy modern software can get away with being and still survive. Working around bugs to accomplish what I need to accomplish is so normal to me now that I sometimes don't even notice how terrible the software is until I see someone less technically skilled than me try to use it.
One problem I notice with FLOSS is this.
If you have an issue with an open source software, you need to register on a website that is made for developers, that will try to sell you a git hosting service, write a bug following a technical format, and you are expected to given information in a reproducible way.
If you have an issue with a closed source freeware, you just use a contact form on their website or leave a comment on their blog or whatever.
The amount of friction to report a bug that FLOSS puts on users is absolutely insane. It's almost like it's trying to deny anyone who isn't a technical person from reporting problems they are having.
GitHub is meant for developers. Plenty of OSS has forums or Zulip/Discord chats for ordinary users to get support in a more casual way. Sometimes not, but there's just as much closed source software with poor support too.
It's been noticed, but nobody with access to the website has been told or cares. The author is almost certainly the first person to do a root cause analysis and come up with the solution though.
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.
While it started beforehand, it was really smartphones and especially the iPhone that gave so many UI guys an excuse to discard all of the studies of the past and start from scratch. "Oh, but it's a touch interface, these lessons are about mouse users, certainly discoverability and clearly differentiating UI elements don't apply anymore. Our users are so smart they will just know that a half swipe from the middle of the object is different than a half swipe from the edge, and they don't have to be told about functionality that is infused at birth now."
Yes. It was around the time when "UI design" changed to "UX design".
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.
Thanks! No pictures and way uglier than Apple’s HIG book, but much more than I ever found.
pdf contains plenty of labels "PICTURE 73 HERE" but not pictures. That's pretty important for a book about UI...
This appears to be a successor document: https://archive.org/details/common-user-access-basic-interfa...
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 :)
> Plus, the numbers are also split by hand!
> From middle-going-out:
> Left hand: 91357 Right hand: 02468
What is the advantage of this order vs. numerical order? If I'm reading your post correctly the numbers are arranged 7531902468 on the keyboard, with maybe a space in the middle? Is there some mathematical property where odd and even numbers are more likely to alternate than for odds or evens to be found side by side? Maybe 0 is more likely to appear so they want it on an index finger? It just seems unlikely that the next most common digit is 9, unless this was developed by people who set prices on items.
Very simply: if it's an even number, it's your left hand. If it's an odd number, it's your right hand. If you want to type a number like 2,467,333 you can do it without looking for the numbers. On qwerty I tend to "lose my footing" when it comes to typing numbers out. But if it's a 2 on programmer-dvorak, it's right hand, index finger. 2468 is each of your four digits, in order. and 1357 is the other hand's digits. However, I hold left-shift to access the numbers which means my pinky is unavailable for the left numerical ascension, so I tend to do 1 and 3 with my index, and 5 with middle, and 7 with ring. Nine [9] and Zero [0] are "stretch" numbers in the middle: 9 and 0 are reached via one's index fingers going diagonally toward the middle of the tippy-top row.
tl;dr: right hand even,, left hand odd,,, increasing from index to pinky. "Look ma, no eyes!"
> If you want to type a number like 2,467,333 you can do it without looking for the numbers.
You don't need a special keyboard layout for that. Any layout at all has the same feature.
> On qwerty I tend to "lose my footing" when it comes to typing numbers out.
Why not use the numpad?
What numpad :)?
The only possible answer to that is "get a real keyboard".
That doesn't suit my lifestyle - never going to drag a keyboard to a coffee shop, for example. Also I would gently challenge the notion that people are able to type numbers without looking accurately on a standard keyboard. Can you type 15,483,523 on the first try with no errors? Because when I try on qwerty mode I get 26,584,634 lol.
I use a layout with an AZERTY-style shifted digit row for coding (and for everything else). A quick check of one C++ codebase I've been working with shows ~20× as many instances of digit-row symbols as digits (18× for QWERTY digit-row symbols, 27× for those in my layout), though C++ is unusually symbol-heavy. A couple of ECMAScript repositories show 3× or 10×. On some Common Lisp, digit-row symbols are 5× as common as digits for my layout and 22× for QWERTY (almost entirely because QWERTY parentheses are terrible). I don't expect to see a lot of code where numeric literals are more common than type modifiers and operators and such… most of the times numbers are being manipulated in code, they're not being typed in directly as digits but going through comparisons and arithmetic and such, and that's symbols.
We use the ( ) [ ] { } keys more often than numbers, so it works out nice
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.
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.
My equally uninformed guess is that the presence of six empty boxes communicates that the code entered must be exactly six digits long in a way that a generic text input doesn't. It clearly delineates the digits which makes it easy to see how many you've entered and how many are empty, and the presence of an empty box suggests that it needs to be filled while a number that's simply shorter than the input field doesn't. At least, that's my steelman; maybe browsers should check if a field's min-length and max-length are the same and style them similarly?
I think people were entering the SMS short code the digits were sent from instead of the digits so they wanted to make it clearer that it was 6 digits they want you to look for.
When I get sent a verification code from myGov (via text message), the message contains the 6 digit code, AND a 6 digit phone number for the help desk. I have to stop and double check which is the code, because I have accidentally entered the phone number many times.
I wish they were just regular inputs. A significant portion of them I encounter have some kind of cursor navigation or paste bug. I think this mechanism is the perfect Goldilocks-zone control of simple enough that people rewrite it from scratch, but text input has enough hidden complexity that it's easy to get something wrong.
> 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.
Santander's banking website uses both in some places, e.g. confirming a new payment. "Enter your 5-digit PIN and the 6-digit 2FA code we've just sent you", with 5 little input fields for the former, and a single standard input field for the latter. Perhaps a deliberate decision to make them look different, but it just looks like they couldn't make up their mind.
Or the input fields are provided by different widgets they downloaded from different places on the Internet.
I'm guessing someone at some point thought that preventing copy and paste would stop bots, then everyone copied them.
That sounds quite likely. Not the stopping bots part, just the idea that someone chose to do it for some reason, and everybody copied them without knowing the reason. Happens all too often.
Describes religion. Code is a type of religion I guess
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.
Likewise usurping Ctrl-F with their own shitty global search function rather than the perfectly good page search provided by the browser. Looking at you, Confluence.
Usually Ctrl-F still works for me, but / almost always gets consumed by the stupid search that never works properly. But then that's usually because you're on a site with infinite scroll so even the Ctrl-F search is going to be limited, even if you are in the correct thread.
One thing is really dislike about modern UI design is where you see a headline that seems kinda interesting but you don't click on it right away. Come back a bit later and it's just gone. There was some A/B testing on the headline and now it's completely different, probably now all clickbaity so I won't be inclined to check it out.
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.
I've seen cases where it was done well, but unless you're willing to invest great engineering effort into making sure it's done well, the built-in version (which already has had a lot of engineering effort put into it) is almost always going to be better.
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.
My pet peeve is in the "create a report" section of InvestEngine (useful for doing reports aligned to tax year). If you try to type a date at all, the year always ends up as 000n and no amount of typing numbers will get it to accept a 4 digit year (or even a 2 digit year starting 20). The only way to undo this state is to click today and then page through the years and months using the arrows on their stupid date widget.
Is this a browser app? Have you tried greasemonkey/tampermonkey?
Not investigated what framework it's using, but it looks like a mobile app compiled to WASM. It's just something I need to put up with I guess, it's just annoying when I need to generate a bunch of reports every year for my company end-of-year accounts, so it's not worth wasting time on trying to automate.
We had a discussion about this one not too long ago.
https://news.ycombinator.com/item?id=45887957
Unfortunately, with the mobile OS's datepickers being so bad from a usability perspective, it's a long way from being a solved problem. Typing the date directly into a single textbox is great for some of us but not for others, so an alternative has to be provided.
Yes, some date selection widgets can be poorly designed and user hostile, but the well-designed ones tend to be fine. The ideal, based on real user research by gov.uk, appears to be to use 3 separate textboxes, instead of <input type="date">.
I just tested on all the devices I have at hand and they let me pick or type, and the picker is usable. Is this an iPhone problem? Because it sounds like an iPhone problem.
The link I gave there explains the problem. The picker is perfectly usable if you know how it's meant to be used - like most things really. The problem is the flat design, controls looking like headings rather than controls, leading to a surprising number of people not having any idea of how to change the year.
On X.com on my Chrome browser I am unable to correct digits if I entered a wrong number.
Very nice blog layout btw.
FWIW In the Apple ecosystem this usually gets filled in automatically based on the source.
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.
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.
I'd understand a developer in e.g. America not being aware of it, but to one in Switzerland, France is right next door. A developer working on something as important as their government login system should be well aware of different keyboard layouts surrounding, and leaking into, their country.
Yes, I understand where France is relative to Switzerland. But the basic fact remains that not one of the developers or testers or stakeholders encountered this, and it was so rare apparently the very first person to encounter it -- given that it was literally a blocking issue, and not just some transient issue -- is the linked article.
Is it a regrettable bug that made a poor assumption that breaks in special cases? Sure. Is it "Dunning-Kruger" (groan), or some demonstration of how stupid the developers are? Give me a break.
> apparently the very first person to encounter it
We don't really know that.
It may have been the first person able to complain - given you couldn't even file a support ticket without getting through this prompt!
The Dunning-Kruger thing wasn’t meant to disparage the developer and certainly not to call them stupid. It’s simply a reflection on not knowing what you don’t know and thinking you know more than you do. Everyone goes through that.