I have a couple of devices that are 12V over usb-c. The devices themselves are fine, but the wallwarts the mffr provided are just that - 12v over usb-c. No PD. If a device is expecting 5V, there's a healthy chance it'll .. stop expecting 5V.
We blame usb-c for all this, but it does feel like some mffrs are going out of their way to screw it up.
Imagine if all USB-C cables had a patent owned by the consortium and an identification chip made by the consortium. The spec could require that devices would not use the cable at all unless the chip is cryptographically verified, and bad cable manufacturers could be sued into oblivion for breaking the patent.
The more I age, and the more I expect my devices to justwork™, the more I appreciate Apple’s pro consumer monopolistic moves.
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.
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.
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.
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.
This feels like a good place to reel out my favourite anecdote; community college IT (or for the natives; BTEC), 1998; our programming tutor told us to "ignore the internet" because it's a fad.
Almost 30 years, and every so often I still wonder about where that got him.
It used to be even more literally so - network mail started off as using FTP to SNDMSG onto a remote system instead of your own. In RFC475, FTP has MAIL and MLFL (mailfile) commands to support this.
I think it's neat that you can still find echoes of this. MAIL worked by just appending to MLFL, separating records with CRLF.CRLF - which is still how Data segments are terminated in SMTP.
Was that before or after UUCP? I know that UUCP carried a command in each message, so you would specify a message body with a tag that says pass it to the mail receiving peogram.
SNDMSG-over-ftp pre-dates UUCP by 5 years, so I think that one's pretty clear-cut.
(Not that I'm claiming anything's original here, ftp & smtp are both in the nwg/ietf family tree, which makes it easy to draw parallels. There's probably 100 other influences.)
I think what really stands out about this, is that having it installed as a pre-made brick is very cost-effective.
But this cost-effective route isn't readily available to most people, as most people don't build homes. Developers build lots, and then sell finished homes. So you need to entice developers. And historically, "the stick" is the only enticement developers remotely pay attention to.
"If you want a swift brick, install one yourself" is much easier said than done - you're talking about removing an existing brick, replacing it, hoping you don't damage the course or the cavity, probably voiding any warranty on a new home, etc. It's certainly not a £35 retrofit.
It may amuse you to know they're both essentially the same thing. GBP is formally Pound Sterling, formerly 1 pound (tower pound / 20 troy ounces) of Sterling Silver. Which is why £ is a stylised L.
The last one is so close to the point. Iran had Internet blackouts earlier this year, Russia has been experimenting with the same - options like shortwave are just as relevant as ever.
We blame usb-c for all this, but it does feel like some mffrs are going out of their way to screw it up.