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."
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)
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.
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.
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.
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.
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.
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 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.
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 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.
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.
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.
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).
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.
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.
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.
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!
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.
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.
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.
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 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!
> 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.
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!"
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.
kleiba2 | 11 hours ago
bux93 | 10 hours ago
Someone | 10 hours ago
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?
kleiba2 | 9 hours ago
PDF link in the box on the right.
sixsell1 | 7 hours ago
Someone | 7 hours ago
benji-york | 7 hours ago
acheron | 8 hours ago
jandrese | 5 hours ago
kleiba2 | 3 hours ago
pjc50 | 11 hours ago
(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)
khalic | 10 hours ago
LoganDark | 9 hours ago
firmretention | 9 hours ago
Affric | 9 hours ago
Crazy to add complexity like this.
dreamcompiler | 5 hours ago
jandrese | 5 hours ago
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.
Ajedi32 | 6 hours ago
soneil | 9 hours ago
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.
RobotToaster | 9 hours ago
abanana | 6 hours ago
whycome | 5 hours ago
TonyTrapp | 9 hours ago
Anecdotally, this seems to be the case on the majority of websites where I have to use such 2FA codes.
abanana | 6 hours ago
jandrese | 5 hours ago
msdz | 9 hours ago
- 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.
jandrese | 5 hours ago
zanecodes | 4 hours ago
recursivecaveat | 4 hours ago
janeway | 9 hours ago
llm_nerd | 9 hours ago
K0nserv | 7 hours ago
This is just a classic case of a developer situated firmly at the first peak of the Dunning Kruger graph.
llm_nerd | 7 hours ago
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.
abanana | 5 hours ago
llm_nerd | 4 hours ago
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.
Liquid_Fire | 4 hours ago
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!
theoli | 9 hours ago
Retr0id | 9 hours ago
moring | 8 hours ago
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.
Ajedi32 | 6 hours ago
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.
AlienRobot | 5 hours ago
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.
nvme0n1p1 | 5 hours ago
jandrese | 5 hours ago
fer | 8 hours ago
ralferoo | 7 hours ago
psd1 | 3 hours ago
abanana | 5 hours 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">.
fer | 4 hours ago
abanana | 2 hours ago
barrenko | 8 hours ago
Very nice blog layout btw.
frou_dh | 8 hours ago
ralferoo | 7 hours ago
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.
dreamcompiler | 5 hours ago
pizzafeelsright | 7 hours ago
lvbyte | 6 hours ago
pirates | 6 hours ago
creaturemachine | 5 hours ago
pizzafeelsright | 5 hours ago
hbn | 6 hours ago
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.
creaturemachine | 5 hours ago
_bent | 6 hours ago
david422 | 5 hours ago
whycome | 5 hours ago
wolrah | 3 hours ago
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.
nailer | 2 hours ago
Yes, exactly! It's like devloper doesn't understand that automating thibgs like this is the point of computers.
zitterbewegung | 7 hours ago
summarybot | 7 hours ago
thaumasiotes | 7 hours ago
That sounds... aggressively unergonomic. Are programmers not expected to frequently use numbers?
boredatoms | 7 hours ago
summarybot | 7 hours ago
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 :)
jandrese | 5 hours ago
> 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.
summarybot | 3 hours ago
tl;dr: right hand even,, left hand odd,,, increasing from index to pinky. "Look ma, no eyes!"
burntcaramel | 7 hours ago