And let me paste. Especially if you're going to insist on doing it by SMS (also though please don't) then surely you should know that both Android and iOS make it easy and prominent to copy the code to clipboard...
Or my favorite variant: Allow paste, but require at least one character type event before allowing submission (because otherwise the password/OTP field must be empty, right?)
Both of these are stupid but we should blame the OS/browser, there is no reason the site should be able to tell the difference or block pasting in the first place.
For the vast majority of the time I don't think the site's goal is even to "tell the difference" rather they implemented the form with the wrong event trigger instead of one that makes sense for monitoring inputs. You definitely want these other events in other scenarios so blaming the browser for having them isn't going to help anything.
You'd be surprised, even for the paste half of the equation, how many go out of their way to make a completely custom input to do it better™ that fails to support obvious things by happenstance. See the topic's article about looking for number keycodes instead of processing text input as an example.
There are actually some good reasons. The default paste action will just paste text or HTML. However most OS clipboards have the ability to paste various types of content. If the clipboard contains a "better" media type it makes sense for the application to handle it and prevent the default action.
For example:
1. Pasting an image into a markdown field. A common action is to upload the image and insert the correct markup to embed it.
2. Pasting richer content inside an application. For example when copying a rich widget you may embed a text representation, HTML representation but if the user pastes the widget back into your app it is often best to keep a "native" representation that can be used to faithfully reconstruct the original data.
Related, my current rage-inducing gripe is that at $DAYJOB, where I have to use a Windows VDI, pasting text from OneNote into a Jira comment results in a screenshot.
I don't know whether OneNote is more to blame (I already hate it because Ctrl-C rarely works to copy) or Jira, or Windows, or who, but it's just maddening.
(Clarification: pasting text results in a picture as an attachment. Didn't mean to imply that pasting would actually take a snapshot of the screen.)
Presumably browsers could replace a paste with n “key down” and “key up” events, but I bet that causes other issues elsewhere and doesn’t seem like the right solution.
Ultimately, misguided developers or PMs will always find a way to make our lives harder if they set their mind to it; let’s not make it an arms race.
That said, for password managers and known-bad sites, your proposal sounds tempting!
The question is whether I know it despite not being a front-end developer, or because of not being a front-end developer.
(Around 8–10 years ago I worked on keyboard input for ChromeOS, and way too much of it was trying to emulate 1995 Windows Netscape so that most sites would mostly work.)
I've seen this in React where an autofill doesn't do anything in terms of invoking the changed callbacks. As such, adding 1 character invokes the callback, and sets the value for React. You obviously remove it.
I don't often see websites blocking paste on OTP code fields. What I do see often is websites breaking up the OTP field into n separate input fields, and having some code that auto-switches between the input fields as you type them. However, the auto-switching code doesn't handle pastes, so if you try to paste the entire code only the first digit gets entered. ‘Don’t f* with paste’ doesn't help with that.
These are also terrible if you need to go back because you mistyped. Shift+Tab brings your cursor back to correct it but their code pushes the cursor right back into the next empty box. (And they do this with a lot more than just OTP.)
I’ve to do this with OTP codes at work as well. Reimplementing paste here I’d say is pretty trivial (though you have to add Yet Another Event Listener) but I’d agree with the general sentiment here to just not overcomplicate it at all if possible
Ugh yeah, honestly if paste is disabled because that was the most effort they were going to put in to 'fixing' that I'll excuse it. Better to not even appear briefly like it might work!
There are a few sites I've found over the years which won't allow this for password fields. They nag and nag that you need strong passwords... great, mine's 100 characters of gibberish in my password manager. Then when it comes time to paste it, they've got that disabled. You know, for security purposes.
I once had an account with a bank whose website did this, but only for the change password form. Which wouldn't have been too bad except they also had a "force users to change their password every X months" policy. I was so annoyed that I opened dev tools and used the console to circumvent their stupid javascript every time.
Banks are guilty of worse, but they're difficult to switch. And how do you know that the next one will be any better? Smaller banks in particular seem to be using some whitebox software title to do their online banking, so you might go to all the trouble only to discover the exact same. How many times can you switch up your direct deposit before HR/payroll gets annoyed with you?
> Android and iOS make it easy and prominent to copy the code to clipboard
I've noticed some inconsistency on Android: many, but not all, SMS notifications from Google Messages (Pixel) contain a "Copy code" button when the message has an OTP. I wonder if there's some kind of heuristic or list of known phrases/senders baked into the app, always lagging behind as things evolve.
OTP messages from non-A-list services have only the "Reply" / "Mark as read" buttons on the notification a substantial portion of the time, at which point one can type the code manually or copy the whole message after opening it.
> I wonder if there's some kind of heuristic or list of known phrases/senders baked into the app,
It's actually rely on specific message format. And it's a function of google message app instead of system wide function. Although the pattern isn't documented anywhere.
But that’s the same as pressing the paste shortcut. I guess the force option emulates keypresses or something like that to always allow paste, which the right click option of Firefox doesn’t do.
Tangential, but are there any really good integrations with authenticator apps/autofill like the way iPhone autofills SMS codes?
I know SMS is less secure but the UX of autofill on e.g. iPhone at least is so much nicer than having to pop out of my browser/app, open an authenticator app etc.
Hijacking back button, shortcuts and key events has to be one of the most annoying thing. This breaks autocomplete/autocorrect, paste and many other use-case like the author encountered.
> Perhaps developers need to test on something other than MacBooks?
Another sign that the website you are on was only tested on macOS used to be scrollbars everywhere, since there is no visual difference between overflow: scroll and overflow: hidden. Unfortunately now the default in most places seems to be hidden scrollbars, which is great because if a page or component happens to layout just right, it will simply look like there's no more content and you'll have to rely on the user just knowing they can scroll or you have to add additional cues. If only there was some standard visual cue that could indicate that you can scroll and how far in you currently are!
(And of course, the wrong overflow values are still hiding everywhere, so it didn't really fix the problem...)
I see more and more website use multiple inputs with JavaScript to handle automatically moving from one to the other for OTP codes, including GitHub. It's always buggy because the devs reimplement basic navigation (focus, deletion, arrow keys, etc.) and it turns out that stuff is hard to get right, so they get it wrong. Often, just typing too fast breaks those inputs (<https://github.com/login/device/> for example).
A simple input is much better, even at the cost of a UI that is slightly more ambigous for the user on desktop (on mobile, there's a bagillion things to make inputting OTP codes easy).
Overly controlling code like this also prevents copy/paste. For example, I have had to manually type passwords from my password manager, because a form refused to let me paste from the clipboard.
Maybe the developers even know better, but were forced to do it by project managers (or other management)? Because this sounds like just the kind of "security issue" a manager could get hung up on...
If you have project managers that tell developers to implement features like this, and you don't have a product management function which actually represents what users want, then ... I mean, I don't even know where to go with that.
You're a terrible developer if some project manager tells you to disable paste... and you listen to. I know it's easier to pick jira task, implement them feeling you're making the world a better place.
This will be an unpopular opinion but part of your job as a good developer is being able to explain to your boss why this is an asinine thing to do, and convince them otherwise. If you're both powerless to make a decision as small as this and unable to convince even a single person above you to back you up on it you're not a very effective engineer.
That basically says "your skill as a good developer depends on your boss being somewhat reasonable."
Not everyone's boss is even a little bit reasonable. You might be both a very skilled engineer and capable of explaining things very clearly and persuasively, but communication always takes two (or more) parties, and both those parties have to be approaching that communication in good faith in order for the actual skills of communication to really matter.
There's this trope that most bosses are this curious mix of idiot, sadist, and fat cat blueblood completely incapable of reason, who produces nothing of value, and just sits around thinking of ways to make things harder on the engineers.
Most people are reasonable, including people who happen to be managers. Most people will listen to you if you make informed, persuasive arguments. And even when they don't, most people will be able to articulate to you a perfectly valid reason why the thing you want to do can't happen, or can't happen yet.
As a thought experiment, playing devil's advocate in a way, suppose the boss tries to be reasonable and ends up telling the developer "you make a good point, and I would support it, but my hands are tied because x." Presumably there is some value of x here that, while terrible for UX/a11y, actually exists in some fashion when it comes to using the clipboard for passwords. Maybe the fact that all apps can arbitrarily read from the clipboard, and people tend to be too lazy to copy a non-secret to the clipboard between pasting a secret and opening a sketchy app? Recent versions of Android toss up a toast notification saying something like "<app> has pasted from the clipboard" when an app does so, and I've seen it for no apparent reason in some apps -- usually apps associated with IoT junk, but sometimes even apps that ought to be reputable.
I'm not normally a fan of ecosystem lock-in, but using Google products as my password manager, browser, and mobile OS means I very rarely have to use my clipboard for passwords, which is a good feeling. Unlike a third-party password manager with a great browser extension could offer, this ensures seamless autofill with most mobile apps nowadays, too.
I didn't say "all" or even "most". You were the one making absolute categorical statements.
Some managers are unreasonable, and will not change their minds about what they've decided because of the arguments, no matter how rational and well-expressed, of people beneath them.
Declaring categorically that any engineer who cannot persuade their manager not to do something bloody stupid is a bad engineer is insulting to engineers who are, in fact, in exactly that situation, and is, from where I sit, part of a very large category of mistake where someone tries to avoid having to apply human judgement and critical thinking by making a hard and fast rule about things that are much more nuanced and fuzzy.
And too many websites force you to type the 2FA code, like, actually hitting the keys one after another, instead of allowing pasting the code despite the fact that they send the 6 digits to your email.
...and despite the fact that it's a single use code that expires after a few minutes. I mean, a password in the clipboard could conceivably be a security risk if you leave your computer unlocked, but a 2FA code?
I see this problem on bank account forms all the time, where they need you to type and confirm your bank account number for things like direct deposit or ACH payments.
I'm more likely to get it wrong twice than I am if I just copy and paste it from my actual bank account website once.
I've seen it here more than with 2FA forms. So you're doing enough routing number verification to tell me that what I just typed in is Bank of America (I know it is) but you still make me manually type it - twice - just to increase my odds of making a mistake?
When a website refuses to let me paste my password I open DevTools, manually add a value="password" attribute on the input, and submit the form. I don't know what kind of moron makes these decisions, but thanks, now everybody can see my password in plaintext while I'm putting it in.
Check if your password manager has a "perform auto-type" (or similar) function, where it can send keyboard events to another window. That way your browser (or whatever app) doesn't have to support paste to work.
You've pretty much dug out your own answer: The browser exposes both event.key and event.code in the keypress event. If it didn't life would be pretty miserable for interactive content expecting positional things like wasd.
The parent of the comment I replied said that their kb lies about the key being pressed, so there's no way for the browser to know and fingerprint the user as the comment I replied implied.
Another pet peeve of mine is that some websites would intercept Cmd+F to provide their own, usually inferior, version of search, and all browsers being complicit. I wish there was a setting that would prevent websites from overriding browser's own hotkeys.
I'm imagining a drop down with all values between 000000 and 999999. And they somehow override the ability to just type into it to jump to the right value, you need to find it. And the list is unordered and randomized every page load.
Maybe this is a hot take, but the `key` API in the dom was a massive mistake. I've been writing JavaScript since the aughts and I've never managed to use it in a way where it didn't feel like a mistake. It's always issues like this, where certain keys don't have the value you expect. Or capitalization becomes an issue. Or modifier keys get in the way. Or god forbid your user has a keyboard with a weird layout or does chording and the API just completely gives up.
As ugly as the keyCode/which APIs are, they work. I've never had an issue with them.
`keyCode` are just raw Windows codes, which are a mess if you ever stray from Windows or US English. `VK_A` does not necessarily correspond to an ‘a’ and does not necessarily correspond to the same position as A on a US keyboard — in general there is nothing you can reliably say about it.
`code` is useful for key positions, e.g. for WASD movement in a game. `key` is useful as the interpretation of a key, but primarily for non-text keys, since IMEs and virtual keyboards mean that text does not necessarily correspond directly to keys.
While we are bitching about crappy inputs on websites, I haven’t seen anybody mention a bug I see on some sites. If you autofill things, the websites validation code doesn’t get triggered and will act like you didn’t enter anything in the fields that got autofilled. It’s like they are explicitly waiting for keystroke events to trigger a “user entered something” and forgot to add an “OR $(shit is in the field)” to their conditional.
As a result you have to go back to all the autofilled fields and type something to trigger their validation logic.
Using `code` here is pure ineptitude. It represents the physical position of a key, and is only useful for things like games using WASD movement; the same physical key routinely maps to different inputs under different languages and layouts. And `code` might not be set at all for on-screen (e.g. phone) keyboards. And IMEs don't necessarily send key events at all.
This sort of complexity is a major reason I've been moving in the direction of dropping Javascript on sites I build. My last web app only used 4 lines of JS for dismissing messages. Django SSR, templates, forms, and plain HTML work in extremely predictable ways. It's much easier to reason about and test plain HTML.
> There are two ways to do this - a right way and a wrong way - using KeyboardEvent.
I reject this strongly: they’re both wrong. It’s not reasonable to control this via a KeyboardEvent at all. If you want to do this sort of thing, you should only manipulate in real-time based on the input’s value and selection, triggering on 'input' events when !event.isComposing. Otherwise, you will break things for some users.
Also, you should very, very strongly consider not manipulating the field contents, but only validating (and somewhat relaxed masking at that). The web just doesn’t give good, robust primitives for input masking.
My general philosophy on this is clients will find ways to circumvent literally any special validation you are doing because they are vaguely in charge of their browser. Definitely use html form types, input, and pattern to attempt to ensure the user can't just do something wrong, but the backend needs to be the authority on what is actually valid. I like this unix style "strings as the universal data type" idea - it's not about how it happens, it's about the output. I honestly can't comprehend how something thought it was better to do `const validKeys = [NUMPAD_1, NUMPAD_2, ...];` and not `const validCharacters = '01234567890';`.
Clearly the dev responsible for the input made a mistake, but why does it extrapolate into that javascript hatred? Like, before javascript is was impossible to make a mistake? The whole web was a perfect place without an issue?
Before JavaScript it was impossible to make this mistake, yes. The web was originally envisioned such that the hypertext described the form elements and the browser was responsible for the UI behavior. JavaScript brought the idea of a Turing complete language you can use to completely define the behavior of your UI, and with that it brought the possibility of an infinite number of mistakes that devs can make.
> Before JavaScript it was impossible to make this mistake
Before JavaScript it was impossible to even implement such functionality on the client side...
There was no "number" input before HTML5 spec which came out in 2008, and was adopting for 6 years before finally becoming a recommendation in 2014. You had to let user put any text in the input and do the validation on the backend, which had the same Turing complete language running letting you make any mistakes you want.
Rule of least power is just a design principle, and it could not hold as an axiom of good design for the web, because when the least power becomes not enough power, it takes years for the adoption of new powers needed – that's why JavaScript exists in the first place.
A small peeve that frustrates me to no end is when I want to enter some numbers in iOS, and the app gives me a qwerty keyboard interface instead of a numpad.
On a similar note, the Danish government issues ID system doesn't work well with password managers. If the password managers fill in your username, you need to hit space to unlock the sign-in button. The password field, while it does support copy-paste, somehow manages to lock out password managers, so you need to open the password manager, copy your password and then paste (for some reason that field doesn't have the "forget to unlock sign-in" on paste feature.
I wrote a long comment about text-fields being overly aggressive and controlling, but then I clicked and accidentally dragged in my browser's URL text field (this should have selected some of the text!), and the page got reloaded, which deleted my comment.
I give up. But I guess at least this proves my point.
One slightly inconvenient workaround is using GhostText and then using a proper text editor for long comments - precisely to avoid the eagerly-user-input-destroying web
I am about 24 hours into using ghostText after losing a significant amount of effort to a distracted `C-w`. Browser tab gone; much swearing ensued. I was tempted to start logging my own keystrokes after this… but that's not a good idea.
With this extension (+1), I'm happy that `C-w` does as God, readline, and Emacs intended.
Yeah, that's another fundamental fail of the OS - it should allow you to simply register an "OS input editor" that can be used in any text input field so you can use all the features (including recovery) of a dedicated text editing app instead of relying on whatever shoddy substitution some apps have come up with
> I really wish that browsers gave control back to the users
Exactly this. Browsers have stopped doing their job as the "User's Agent" and instead are acting more in the interest of web developers. Consequently, developers now see the browser window as a limitless empty canvas that they can just do whatever they want in, regardless of the user's desires.
One great concept I find very useful is just fail, like this thing of not showing letters is just wasted work, it has all the potential to be stressful without adding any value, let the user type whatever they want, if the result match the expected value, go ahead, otherwise retry
I personally never really cared for this setup, as on most keyboards that pattern is staggered and tilted while trying to emulate the straight number pad layout. The straight lines of the number pad are kind of the whole point to me for having a separate number pad area.
Meanwhile all the numbers are still there on the regular keyboard just one row higher than you're normally typing. Plus, for a lot of typing a typist is already pressing the symbols on the number row anyways, so it's not like a typist is having to stretch to locations they're not normally pressing anyways. I'm not an accountant or mathematician or whatever so I tend to eschew number pads, so I'm probably a bit biased.
> it's not like a typist is having to stretch to locations they're not normally pressing anyways.
But they have to stretch, that's the issue, why do something unergonomic when you can do it better? On phones you have numpad input for the same reason - it's more convenient than the "familiar" horizontal keys
> straight lines of the number pad are kind of the whole point to me for having a separate number pad area.
But your fingers aren't straight, so that's also suboptimal. On the other hand you don't need to move your hand off home row and can also add more convenient backspace for error correction
People already routinely type at least !, @, and $ often enough and it doesn't seem to be that big of a deal.
> On phones you have numpad input for the same reason
Yes, a straight grid of numbers for touchscreens not one heavily skewed to the side. Also, the number pad keyboard means larger hitboxes for numbers to type them faster. There's also no real "home row" on a phone keyboard.
Look, if it makes you happy, do it. I'm just suggesting that to me its not really that much better than just pressing the keys that are practically always there on any regular keyboard. I'd personally just rather get better at pressing the number row keys instead of ensuring I'm on a keyboard or OS configuration to allow me to have some non-standard numberpad layer on the keyboard.
Well you tell me my fingers aren't straight and aligning a number pad to straight lines is worse than skewed.
> Why do you insist a worse way is better just because you personally don't care?
I didn't say I didn't care. In my personal experiences it's worse. I've had laptops that had it, and it never felt good. Plus it was only on that one laptop, not my keyboard at school or work, not the keyboard at a friend's house, not the keyboard on my desktop, etc.
> This topic is about website input forms, what OS configuration do you need to visit a website?
So a keyboard layer that isn't labeled on your keyboard and is on some sites and not others and not on most other apps you use. Clearly the optimal way for the site to support as input, I'm sure it'll get lots of adoption in random two factor input code boxes. I'll definitely commit this pattern to muscle memory for the random site I encounter supporting this.
> Well you tell me my fingers aren't straight and aligning a number pad to straight lines is worse than skewed.
Yes, I also told you it's not a relevant factor for the phone (do you hold 3 fingers of different length on your screen touchpad? Skewed parallel to the screen so that rearranging buttons would fit it better??), yet you ignored it. Apples and oranges
> In my personal experiences it's worse. I've had laptops that had it, and it never felt good.
Which laptop allows using uio as 123 when in a numeric input field?
> it was only on that one laptop, not my keyboard at school or work, not the keyboard at a friend's house, not the keyboard on my desktop, etc.
Ok, so you didn't know how to do some simple keyboard remapping. How is this relevant for this conversation about an additional web input form option?
> definitely commit this pattern to muscle memory for the randomsite I encounter supporting this.
You don't need to commit anything, your memory can remain as blank as it is now with only some vague memory of something similar from your past, it would still work. Similarly, if it works in just 1% of input forms, it would still be an improvement... in 1% of cases. Where did you get and idea that universal adoption is a prerequisite from? Phone numpad-like mode doesn't work everywhere, still useful when it does
> Ok, so you didn't know how to do some simple keyboard remapping
This topic is about website input forms, what OS configuration do you need to visit a website? Dang you're being highly inconsistent here. Should this just be an input on a website or an OS level keyboard remap?
You're being quite rude to assume I don't know how to remap keys. I know how, I just don't care keeping a keyboard map on me all the time and remapping everyone's keyboard just because I'd like to type numbers not using the number row. I'd rather just have the muscle memory of being fast with the number row.
> Which laptop allows using uio as 123 when in a numeric input field?
Not uio as 123, but that's not really emulating a computer number pad anyways as a computer number pad has 789 along the top. So not only is it skewed you're wanting it flipped from how normal keyboard numberpads are.
FWIW it was a line of Dell Inspiron laptops in the late 90s and a Compaq laptop in the mid 2000s that had a number pad on the keyboard, however it usually reused the 789 along the top. It wasn't a massively uncommon feature back then, but it definitely wasn't on every laptop. Mostly on business focused machines from my experience.
You're being incredibly hostile to me just saying I used that kind input before and personally didn't care much for it. I'm just sharing my personal experiences using that input you're suggesting for a couple of decades on and off. An input style that clearly wasn't popular enough to continue carrying forward on modern laptops despite being somewhat common decades ago.
> Should this just be an input on a website or an OS level keyboard remap?
Up to you, I didn't bring all this irrelevant personal stuff up. Or instead of doing either you could bring up another one: faux inconsistency
> to assume I don't know how to remap keys.
No, I assumed you didn't
> I know how, I just don't care keeping a keyboard map on me all the time and remapping everyone's keyboard just because I'd like to type numbers not using the number row.
This is also hyperbolic nonsense, you don't need to do any of that (why would you ever keep a keyboard map on you at all???), keyboards you use 99% of the time is literally just a few of them, so remapping them is nowhere close to remapping everyone's
> So not only is it skewed
Which I've already addressed and you still couldn't respond. Your fingers are skewed, so ergonomic numpad wouldn't be linear
> you're wanting it flipped from how normal keyboard numberpads are.
Or I want it matching how (very frequently used) normal phone numpads are. But that's also an sidetracking nitpick since proper design would match whatever the use wants, so 789 would also fit
> FWIW it was a line of Dell Inspiron laptops
FWIW this is false, there were/are no such laptops, you're just too tied in trying to twist your personal story into some argument to address what I'm actually saying. Laptop is not aware of your input fields, so they can't dynamically switch to a numpad on the main alpha keys. And yes, they reused 789, so again, no laptop used an ergonomic no-mod numpad input mode.
> just saying I used that kind input before and personally didn't care much for it.
That's not all you're saying, and more importantly, that's not what I was arguing against since, again, how is your experience relevant this? Yet you keep bringing it up...
> Your fingers are skewed, so ergonomic numpad wouldn't be linear
And yet the numpad people really seem to like is a straight grid.
> That's not all you're saying
My original comment was literally my personal experiences and the reasons why I had those experiences.
> how is your experience relevant this?
I used pretty dang similar keyboard layouts on several devices for over 20 years and didn't enjoy it. That's what makes it relevant. It's like you're saying, "chocolate is objectively the best flavor of ice cream" and I'm saying I've had it a bunch over 20 years and still prefer vanilla. And apparently it's not exactly a feature most other people are clamoring for, because while there are some laptops out there with that feature it is pretty much never a notable one. In fact, its such a non-notable feature you're telling me they don't exist. Instead, people who want a number pad choose to buy bigger laptops with a number pad laid out in a straight grid instead of dealing with the number pad mixed in the alpha keys.
> FWIW this is false, there were/are no such laptops
You're trying to gas light me saying laptops sitting in my closet don't exist and couldn't possibly work. Turns out Dell even has decently modern-ish Latitude laptops with this layout. And looking at my stack of laptops I even have an HP that had that feature as well. You're right they didn't know the input field, but you'd just hold fn with your left finger and suddenly they'd be number pad keys (or toggle fn lock or numlock or whatever for the specific model).
I'm done here dude. You're being so toxic to someone just sharing a personal experience of using a keyboard like this and finding it not that great, to the point you're trying to gaslight me into believing these laptops don't exist. You're clearly not interested in any bit of a productive conversation. You don't need to get so angry and rude over someone sharing their experience over a keyboard layout feature.
> And yet the numpad people really seem to like is a straight grid.
I'm a "numpad person", and you aren't one of us, you "eschew numpads", so why do you speak on our behalf? Also, people like a lot of suboptimal things, so what? Like, you really seem to like all these non sequiturs and using personal experiences in place of addresing an argument. What does this prove?
> My original comment was literally my personal experiences and the reasons why I had those experiences.
And my original replies were literally about everything but. They were about how humeric row was worse due to having to stretch and how regular numpad isn't as perfectly ergonomic etc.
> on several devices for over 20 years and didn't enjoy it. That's what makes it relevant.
But how does it, specifically? You still haven't answered the original question about how your unwillingness to remap numpads on your friend's keyboard is relevant to a web form where you don't need to remap anything, veering off into some other snark
> It's like you're saying, "chocolate is objectively the best flavor of ice cream" and I'm saying I've had it a bunch over 20 years and still prefer vanilla.
More like me saying "your fingers have different length, so a design that takes that into account is more ergonomic" and you saying you have 20 years of experience eating chocolate
> You're right they didn't know the input field
> Not uio
So why are you trying to gaslight me into believing they exist when they don't?
> and couldn't possibly work.
That's again something you've made up, it could work: you track active input field type and switch to a numpad mode if it's numeric. Just like phones already do
> You're clearly not interested in any bit of a productive conversation.
For that you'd need to start saying something productive instead of measuring anger over the wire
You're so toxically wanting to gaslight me you didn't even look at the keyboards in question to see that yes, they do have the choice to use uio as numbers.
> I'm a "numpad person"
And yet you thought the top row of a PC numpad was 123...
I did, both of the links, you're just again "toxically" shifting your ignorance unto me and replacing substantive conversation with personal attacks
> they do have the choice to use uio as numbers.
No they dont, both pics start with 789 as the top, which is unergonomic (even for "pure" numpad emulation that requires shifting all the /*-+ signs to unfamiliar locations), that's underutilizing your most ergonomic finger/key. And I've specifically mentioned "uio as 123", so you're just openly disingenious now claiming any uio nubers are fine
> And yet you thought the top row of a PC numpad was 123...
That's your fantasy again, of course I knew it's 789 on an unmodded PC numpad, I was typing on a keyboard with a numpad! But I'm also not as limited in my perspecive as to think that whatever exists is the best thing ever and perfectly reflects the inner desires of the people, so I have a different remap, though that's a minor thing you're trying to blow out of proprtion because you can't address the substance of the other claims
They do. Not 123, but "they do have the choice to use uio as numbers".
I say "they do have the choice to use uio as numbers". You say they don't. I look at the photo, and they have uio as 4, 5 6. I guess those aren't numbers to you, only 1, 2, 3 qualify as numbers. This is why I say your responses are toxic. You're literally telling me here they're not being used as numbers ("no they don't"), when they are being used as numbers, just not the specific numbers you're wanting here.
The keys being shifted one row up from your idea to include the zero and period in the number pad is pretty much an immaterial difference to me here. This is why I say "I used pretty dang similar keyboard layouts", note "pretty dang similar" not "entirely, exactly, 100% as you suggested". Ergonomics are often subjective and individual (not everyone's hands are the same!), but you're acting like what you consider ergonomic is just completely factual and unyielding and apply globally. The reasons why I didn't care for the numpad mixed in the keyboard's alpha keys wouldn't change if you shifted the rows around.
All I've really been saying is I personally don't care for having numpads mixed in the alpha keys, and you're telling me those keyboards similar to your idea don't exist and berating me for assuming I'm too dumb to know how keyboard remapping works. This is why I say your responses are toxic. I'm really done here though, I don't think you'll ever accept there are keyboards that have uio as numbers or that other people have their own experiences with what is ergonomic.
> Not 123, but "they do have the choice to use uio as numbers".
So they don't, and all you have to do to understand the context is just not cut out your own words "Not uio as 123," is what I've shortened in my quote to "not uio", so no matter how much you stare at the pictures, you can't remove that. If you followed the conversation honestly, you could even fit 789, but still not 456. You also forgot the other part about input field recognition, so you've twisted both of my original qualifiers to fit your irrelevant experience as an important argument
> The keys being shifted one row up from your idea to include the zero and period in the number pad is pretty much an immaterial difference to me here.
You can include 0 and period just fine without any shifts. And it is material, just like breaking positioning of signs is. You're not a numpad person, so you don't know/care, but I am and do, so...
> This is why I say "I used pretty dang similar keyboard layouts"
...that is why I keep saying that your experience is not related to what I was talking about
> Ergonomics are often subjective and individual (not everyone's hands are the same!)
But everyone's hands have fingers of different length which don't move in perfect grids. You can't subjectivate your way out of this simple biological fact
> The reasons why I didn't care for the numpad mixed in the keyboard's alpha keys wouldn't change if you shifted the rows around.
But then the reasons why other people care would change
> All I've really been saying
That's not what ... oh, wait, your just repeating the same falsehoods that I've already addressed
I really hate how modern developers try to reinvent forms. They always, always get it worse than the basic OS/HTML forms we've had for decades. Those dead stupid, simple forms were highly accessible, very performant, and easy to understand.
It seems like forgotten information, but all of these computer interfaces that were invented in the 80s and 90s were built by doctorate level professionals who spent years thinking about these things. Why do all these bozos who took a six month code boot camp (or at best, finished a four year degree with a 2.9 GPA) think the ten minutes they spent thinking about it lead to some brilliant insight?
Very relatedly, my own pet peeve is when controls that are obviously HTML links are replaced with OnClick handlers by some framework, so that I cannot middle click to open in a new tab.
I've encountered navigation bars that use this pattern, which is really frustrating to my preferred way of browsing.
Same thing with lacking right-click to open in a new tab or copy a link. Broken web page, IMO. I will only use such a site because I have to (for work or an unavoidable subject such as health or banking). I will never become a returning user of such a site if I can avoid it.
Somewhat related is a plugin (Safari, Mac) called StoptheMadness). It aims to end stupid crap like this. I’m not the dev.
just about everything today refreshes when you breathe on it, it's so irritating, especially when it's not there any more and you were just looking at it. right-click, save-image-as... "let's reload that..." WHY? I'm looking right at it.
Google does this and drives me nuts. If I search for say "pizza" it will show ~3 results from google maps. Those links you can not Cmd-Click to open in a new tab where as the normal search result links you can. My normal behavior on most pages of results (including HN) so to scan the list, Cmd-click the links I'm interested to open new tabs for each them them. Then explore each tab. I can right click and pick "open in a new tab" but WTF are then preventing Cmd-Click? >:(
Plus, you get a whole bunch of functionality for free when you just use the OS or browser's standard controls, buttons, and forms. When you "roll your own" they are almost always less functional versions of the standard ones, so you also have to "roll your own" functionality to catch up to what the OS already provides.
I will never understand software engineers who feel they need to build their own custom controls, or who won't push back when their "designers" insist on it. You could be doing so much with your life, but here you are re-implementing scrolling again.
It goes beyond the web. Native apps suffer from this too, albeit to a somewhat lesser extent. Some developers just love building their own, inevitably shittier versions of platform-provided controls.
I think about the famous Steve Jobs quote in regards to modern software a lot:
“The only problem with [modern software developers" is they just have no taste. They have absolutely no taste.”
Most developers working today haven't regularly used software that doesn't suck so they're not personally offended by unusable designs or 500ms of latency when typing.
In my experience, these decisions are usually made by product or design people.
The one that annoys me most is whenever someone needs to enter a code with a fixed length. Like a 6 digit OTP code. They want to have a UI with 6 separate input fields: _ _ _ _ _ _ that behaves like one input and only allows the correct values and has the cursor behave correctly jumping from one box to the next as you type / backspace. Turns out, creating that UI element is kinda time consuming and adds NOTHING and at best results in the same user experience as just tossing in an HTML input element, and more often than not results in some non-standard behavior that breaks something (auto-fill, paste, arrow key, accessibility, etc, etc). Just use a standard input, throw some css on it to make it the characters big if you want.
I doubt they're even decisions, but rather a side effect of the only visual design being considered without any awareness of functional/usable design factors.
> I really hate how modern developers try to reinvent forms. They always, always get it worse than the basic OS/HTML forms we've had for decades. Those dead stupid, simple forms were highly accessible, very performant, and easy to understand.
Because the web is a terrible platform that made basic reusable components far harder than they ever needed to be, so every developer got into bad habits of rolling their own solutions to every problem. It's gotten better now but modernizing involves throwing out literal decades of practice.
What do you mean? There's plenty of simple standard HTML to achieve nearly everything needed (except fancy nonsense and tracking). As GP says, simple, highly accessible, very performant, easy to understand (both for the developer and the user).
You couldn't even use input type="date" until a couple of years ago because of Safari support. There was more than enough time of the web missing absolutely basic crap like this that you had to assume that most things weren't available batteries-included, and because of poor modularization related to css and the massive amount of Javascript needed to get anything done, too often the solution was "use a giant-ass framework".
For developers supporting projects implemented using simple raw-js or things like jquery, it's no wonder they developed a habit of DIY. I've had review so much code and push back on this stuff, so I fully understand why it happens.
> You couldn't even use input type="date" until a couple of years ago because of Safari support.
God, that was such a pain. I recently ripped 20k(!) SLOC out of a project that was finally allowed to drop support for those old Safari versions. All just to display one single datetime picker.
The entire rest of the project is less than 2k SLOC.
I work with a lot of “doctorate-level professionals”. They are as flawed as everyone else.
You took “don’t reimplement the browser”, something that is generally incredibly true, and cargo-culted it into placing some old farts on a pedestal just because they were there ‘first’.
You're right that they're as flawed as anyone else, but the point still stands that they spent years studying these problems. Years that modern developers, especially front end developers just don't have.
I'm not saying these ideas shouldn't be revisited, but if you're going to revisit them, do it at an academic institute, where you can spend time figuring out the problems, not at your commercial job where you have to ship next week, no matter how broken it is.
Nah, these are broad strokes you are painting with. Sure some of them needlessly reinvent, but some back end people needlessly reinvent databases and API basics.
But my experience is not the same. It has always been others telling the front-end devs what we "need" to have. I am constantly pushing back with "buttons and links should look and act like buttons and links", "right clicks don't belong in CRUD apps", and "we have a select component that does that". But _BUSINESSES_ want their identity and unique perspective baked into the app.
There is similar reinventing trends movement also in the backend universe.
For example, there is a fashion [1] to include hashes in the names of static assets served. But that's what ETag header is invented for, in the RFC since a decade and implemented in all browsers.
[1] (I deliberately call it a fashion, not a standard; would rather say that RFC 7232 is a standard in this particular case)
It's the boot camp point I think, over-represented in FE (but I haven't done a survey and not GP, just my impression) perhaps because it's more tangible/accessible - 'oh yeah I'll learn to make websites'.
Or perhaps just that it skews young, which I could believe, and might be easier to find survey data on.
> Perhaps developers need to test on something other than MacBooks?
This. So much this.
I've gotten down-voted in the past for being really harsh on Macs, this is because I've worked places where the company would only issue MacBooks to its developers, and requests for non-Macs were denied by a blanket policy. So I kind of hold a grudge that's more fairly directed at the companies rather than Apple (but still, Apple's "our way or the highway" approach is antithetical to my way of interacting with computers). These company policies not only affect developer productivity when your engineers have decades of experience training themselves to be productive on their non-Mac system of choice, but it gets so much dumber when your company officially supports non-Mac-using users.
Also, give out old phones with old software... if you want to target 90% of the smartphone population, optimize for whatever phone (performance-wise) is in the 10th worst percentile. Also do bandwidth testing on slower speeds... 120mb autoplaying video on mobile is stupid, but stuff like that appears way too often, because noone tests it outside of newest phones on highest speeds possible.
To be fair, any autoplaying video is stupid. The whole concept was invented to inflate metrics and manipulate user behavior for the benefit of the app/site owner.
They do but only if it's with sound on. I really wish there was a browser that would simply treat <video> as an unknown tag unless you explicitly allow that particular website to play video.
The non-stupid reverse would be not to deny the requests for non-macs? So you'd have a mix of Dell Inspirons (or whatever) and MacBooks according to what was requested; some Edge users, some Chrome/Firefox but on Windows or Linux users, etc.
Well, yeah. For the productivity reason it's weird to tell engineers that they must use either a PC or Mac (and forget blanket "PC", if you're most productive on Linux or FreeBSD then ideally engineers can use those).
The one rationale that makes sense to me when it comes to restricting choice to a certain degree is the ability for IT to remote-wipe if necessary.
How important that is will depend on context. At my current place of work, most company data is accessed through various web applications so if the computer were compromised, there is no sensitive data kept locally that would require wiping. Though I suppose it could be argued that browser caches could be sensitive, and even if you couldn't sign on to those web apps, due to MFA, an attacker could still get information about procedures and tech used that would get them closer.
But if they're using JAMF or something they can at least support Windows and Mac. The only other reason that I can think of that a company would have such a policy is economic... but lost productivity and user frustration is a hidden cost, so how real the economic advantages of standardizing are is something I question.
Best of both worlds: standardize on issuing one system (probably Mac) that is authorized for sensitive company things like coding, email, VPN, and essentially all actions that change official state; and then also give a budget for test devices that get absolutely no more access or authorization than a device bought at any retailer for consumer use (phones, tablets, computers, VR headsets, etc.). Anyone using the latter for unauthorized purposes (more than just testing with the same methods that any user of the product could do) would be equally insubordinate as if they used their own personal funds to acquire the device, since they're equivalently unmanaged.
Testing is more thorough, and endpoint management remains focused on just the one authorized system.
That's not the "best of both worlds." From a customer perspective, sure, you're ensuring that the product is well supported on their devices. That makes sense.
But that's "the best of one world", not "both."
The other half of the equation is developer experience and productivity.
I'm not going to blanket bash Mac or Apple, because many people love their devices. But being someone who has used computers since the 1980s, who has vision difficulties (the fonts and inability to adjust them on MacBooks actually cause me headaches) and is extremely accustomed to a particular workflow, keyboard layout, shortcuts, the ability to customize all aspects of the desktop environment ... I find the experience of using MacOS 8 hours per day to be intolerable. To pour salt on the wound, the new habits that I started forming on the work devices began interfering with my use of personal devices (suddenly muscle memory was getting confused).
And yes, it's my choice where to work. The last time I got downvoted for expressing this opinion, I said that I almost resigned due to this. Had the company not been able to accommodate me (the CEO was actually surprised to learn that IT had instituted a blanket policy and said "that's dumb, of course we will issue PCs to those who request them") then I would have eventually found work elsewhere because it was that big of a misalignment for me. And I tried to adjust for a year and a half before finding myself in the position where I was really thinking that I couldn't do it anymore.
People who have grown up using Macs, or who feel comfortable using either or, cannot empathazise with this position. But after 40 years of being a programmer, having high functioning autism and thus being inflexible in routines and habits, my computer and my way of interacting with it is almost an extension of me. When you mess with that tool, my productivity and morale drops very significantly. And having spoken with others in these environments, I know that I'm not the only one.
But, again, this isn't really trying to bash Mac, it's attacking a policy that ignores that software engineers are most productive on certain systems vs others and that those choices are deeply personal.
Again, security is only one factor. An important one, but you can't have "best of both worlds" while ignoring one massive "world" that I was talking about.
I didn't mean to imply no other "worlds" -- sorry if I did! I was just using that "both worlds" metaphor to refer to the two particular forces I perceived to be referenced in the parent comment and the article, ostensibly at odds with each other: the benefits of having many devices with which to test the product, and the benefits (not that this produces exclusively benefits) of limiting the scope of workstation device management. In other words, I'm just suggesting a way to avoid a narrow testbed given a narrow workstation issuance policy.
I happen to struggle with the trackpad on non-Mac laptops to an extreme degree, and while I don't put that in the same category as reasonable accommodations required by the ADA of course (probably just lack of practice), it does help me (along with web UI a11y training and formal job responsibility) empathize with the point you are making to some extent. Glad to hear it eventually worked out with the CEO.
Perhaps the acknowledged lack of flexibility on your part should be weighed against the practical considerations and economy of standardization in a large organization.
Standardizing on a small set of easily available hardware, a single popular OS, and a single set of tools across an organization can have vast benefits in direct proportion to the scale of that organization.
On the other hand, you are one person who is set in their ways.
In some ways, I’m a lot like you. I know the straitjacket feeling when placed into an unfamiliar or uncustomized environment. At this point, adapting to new interfaces has happened so often and so many times that I consider it a core job skill.
To be fair, they should not only test on something other than a MacBook, but also on a few machines with low RAM, old/different browsers, slow connections, ad blockers, JavaScript disabled, etc. etc.
Well yeah, but their first mistake was implementing a form text field by listening for event triggers.
For example:
1. Pasting an image into a markdown field. A common action is to upload the image and insert the correct markup to embed it.
2. Pasting richer content inside an application. For example when copying a rich widget you may embed a text representation, HTML representation but if the user pastes the widget back into your app it is often best to keep a "native" representation that can be used to faithfully reconstruct the original data.
I don't know whether OneNote is more to blame (I already hate it because Ctrl-C rarely works to copy) or Jira, or Windows, or who, but it's just maddening.
(Clarification: pasting text results in a picture as an attachment. Didn't mean to imply that pasting would actually take a snapshot of the screen.)
Ultimately, misguided developers or PMs will always find a way to make our lives harder if they set their mind to it; let’s not make it an arms race.
That said, for password managers and known-bad sites, your proposal sounds tempting!
Or a single text input event. Key events will get you nowhere in the presence of CJK IMEs, for instance.
(Around 8–10 years ago I worked on keyboard input for ChromeOS, and way too much of it was trying to emulate 1995 Windows Netscape so that most sites would mostly work.)
https://underpassapp.com/StopTheMadness/
I've noticed some inconsistency on Android: many, but not all, SMS notifications from Google Messages (Pixel) contain a "Copy code" button when the message has an OTP. I wonder if there's some kind of heuristic or list of known phrases/senders baked into the app, always lagging behind as things evolve.
OTP messages from non-A-list services have only the "Reply" / "Mark as read" buttons on the notification a substantial portion of the time, at which point one can type the code manually or copy the whole message after opening it.
It's actually rely on specific message format. And it's a function of google message app instead of system wide function. Although the pattern isn't documented anywhere.
https://blog.google/products/messages/five-new-features-try-...
I know SMS is less secure but the UX of autofill on e.g. iPhone at least is so much nicer than having to pop out of my browser/app, open an authenticator app etc.
Related to accessibility concerns of numeric and number input, there is a good blog post from UK Gov that was on the front page a (long?) while ago: https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-des...
I just checked and it seems like they hijacked it so it navigates the search suggestions instead (ie. pressing "end" goes to the last suggestion)?
It also means if I've pressed page down, then press down it jumps upwards to the top of the page.
Extremely user-hostile choices.
Another sign that the website you are on was only tested on macOS used to be scrollbars everywhere, since there is no visual difference between overflow: scroll and overflow: hidden. Unfortunately now the default in most places seems to be hidden scrollbars, which is great because if a page or component happens to layout just right, it will simply look like there's no more content and you'll have to rely on the user just knowing they can scroll or you have to add additional cues. If only there was some standard visual cue that could indicate that you can scroll and how far in you currently are!
(And of course, the wrong overflow values are still hiding everywhere, so it didn't really fix the problem...)
A simple input is much better, even at the cost of a UI that is slightly more ambigous for the user on desktop (on mobile, there's a bagillion things to make inputting OTP codes easy).
Not everyone's boss is even a little bit reasonable. You might be both a very skilled engineer and capable of explaining things very clearly and persuasively, but communication always takes two (or more) parties, and both those parties have to be approaching that communication in good faith in order for the actual skills of communication to really matter.
Most people are reasonable, including people who happen to be managers. Most people will listen to you if you make informed, persuasive arguments. And even when they don't, most people will be able to articulate to you a perfectly valid reason why the thing you want to do can't happen, or can't happen yet.
I'm not normally a fan of ecosystem lock-in, but using Google products as my password manager, browser, and mobile OS means I very rarely have to use my clipboard for passwords, which is a good feeling. Unlike a third-party password manager with a great browser extension could offer, this ensures seamless autofill with most mobile apps nowadays, too.
Some managers are unreasonable, and will not change their minds about what they've decided because of the arguments, no matter how rational and well-expressed, of people beneath them.
Declaring categorically that any engineer who cannot persuade their manager not to do something bloody stupid is a bad engineer is insulting to engineers who are, in fact, in exactly that situation, and is, from where I sit, part of a very large category of mistake where someone tries to avoid having to apply human judgement and critical thinking by making a hard and fast rule about things that are much more nuanced and fuzzy.
I've seen some of these that magically work with paste, but plenty that don't.
[1]: https://shkspr.mobi/blog/2023/10/firefox-might-remember-old-...
I'm more likely to get it wrong twice than I am if I just copy and paste it from my actual bank account website once.
Not only does your browser know the character code, it knows the key that is pressed. For details I do recommend reading the article itself.
Of course, your 2FA updates every 30 seconds so hurry.
As ugly as the keyCode/which APIs are, they work. I've never had an issue with them.
`code` is useful for key positions, e.g. for WASD movement in a game. `key` is useful as the interpretation of a key, but primarily for non-text keys, since IMEs and virtual keyboards mean that text does not necessarily correspond directly to keys.
As a result you have to go back to all the autofilled fields and type something to trigger their validation logic.
Annoying….
I reject this strongly: they’re both wrong. It’s not reasonable to control this via a KeyboardEvent at all. If you want to do this sort of thing, you should only manipulate in real-time based on the input’s value and selection, triggering on 'input' events when !event.isComposing. Otherwise, you will break things for some users.
Also, you should very, very strongly consider not manipulating the field contents, but only validating (and somewhat relaxed masking at that). The web just doesn’t give good, robust primitives for input masking.
JavaScript violates the rule of least power in this regard: https://en.m.wikipedia.org/wiki/Rule_of_least_power
Before JavaScript it was impossible to even implement such functionality on the client side...
There was no "number" input before HTML5 spec which came out in 2008, and was adopting for 6 years before finally becoming a recommendation in 2014. You had to let user put any text in the input and do the validation on the backend, which had the same Turing complete language running letting you make any mistakes you want.
Rule of least power is just a design principle, and it could not hold as an axiom of good design for the web, because when the least power becomes not enough power, it takes years for the adoption of new powers needed – that's why JavaScript exists in the first place.
Such a small thing, but it drives me up the wall.
I give up. But I guess at least this proves my point.
With this extension (+1), I'm happy that `C-w` does as God, readline, and Emacs intended.
- do not prevent default
- do not limit my input to the exact number of characters
- do not listen to any event other than “blur” unless you’re updating another part of the UI in real time
I really wish that browsers gave control back to the users, and I say this as a FE developer.
Exactly this. Browsers have stopped doing their job as the "User's Agent" and instead are acting more in the interest of web developers. Consequently, developers now see the browser window as a limitless empty canvas that they can just do whatever they want in, regardless of the user's desires.
uio
jkl
m,.
to be used as a keypad so you don't need to move your hand to the actual keypad.
Or you can break actual keypads.
Meanwhile all the numbers are still there on the regular keyboard just one row higher than you're normally typing. Plus, for a lot of typing a typist is already pressing the symbols on the number row anyways, so it's not like a typist is having to stretch to locations they're not normally pressing anyways. I'm not an accountant or mathematician or whatever so I tend to eschew number pads, so I'm probably a bit biased.
But they have to stretch, that's the issue, why do something unergonomic when you can do it better? On phones you have numpad input for the same reason - it's more convenient than the "familiar" horizontal keys
> straight lines of the number pad are kind of the whole point to me for having a separate number pad area.
But your fingers aren't straight, so that's also suboptimal. On the other hand you don't need to move your hand off home row and can also add more convenient backspace for error correction
People already routinely type at least !, @, and $ often enough and it doesn't seem to be that big of a deal.
> On phones you have numpad input for the same reason
Yes, a straight grid of numbers for touchscreens not one heavily skewed to the side. Also, the number pad keyboard means larger hitboxes for numbers to type them faster. There's also no real "home row" on a phone keyboard.
Look, if it makes you happy, do it. I'm just suggesting that to me its not really that much better than just pressing the keys that are practically always there on any regular keyboard. I'd personally just rather get better at pressing the number row keys instead of ensuring I'm on a keyboard or OS configuration to allow me to have some non-standard numberpad layer on the keyboard.
Ok, it's a medium type of a deal, so? Why do you insist a worse way is better just because you personally don't care?
> straight grid of numbers for touchscreens not one heavily skewed to the side.
Why would it be skewed? You use fingers completely different on a phone, so why would you expect the same form?
> Also, the number pad keyboard means larger hitboxes for numbers to type them faster.
And alpha keys are closer to your fingers so you can type those 4 numbers faster
> There's also no real "home row" on a phone keyboard.
There is, check where your thumb(s) "rest" when you type on your phone
> instead of ensuring I'm on a keyboard or OS configuration
This topic is about website input forms, what OS configuration do you need to visit a website?
Well you tell me my fingers aren't straight and aligning a number pad to straight lines is worse than skewed.
> Why do you insist a worse way is better just because you personally don't care?
I didn't say I didn't care. In my personal experiences it's worse. I've had laptops that had it, and it never felt good. Plus it was only on that one laptop, not my keyboard at school or work, not the keyboard at a friend's house, not the keyboard on my desktop, etc.
> This topic is about website input forms, what OS configuration do you need to visit a website?
So a keyboard layer that isn't labeled on your keyboard and is on some sites and not others and not on most other apps you use. Clearly the optimal way for the site to support as input, I'm sure it'll get lots of adoption in random two factor input code boxes. I'll definitely commit this pattern to muscle memory for the random site I encounter supporting this.
Yes, I also told you it's not a relevant factor for the phone (do you hold 3 fingers of different length on your screen touchpad? Skewed parallel to the screen so that rearranging buttons would fit it better??), yet you ignored it. Apples and oranges
> In my personal experiences it's worse. I've had laptops that had it, and it never felt good.
Which laptop allows using uio as 123 when in a numeric input field?
> it was only on that one laptop, not my keyboard at school or work, not the keyboard at a friend's house, not the keyboard on my desktop, etc.
Ok, so you didn't know how to do some simple keyboard remapping. How is this relevant for this conversation about an additional web input form option?
> definitely commit this pattern to muscle memory for the randomsite I encounter supporting this.
You don't need to commit anything, your memory can remain as blank as it is now with only some vague memory of something similar from your past, it would still work. Similarly, if it works in just 1% of input forms, it would still be an improvement... in 1% of cases. Where did you get and idea that universal adoption is a prerequisite from? Phone numpad-like mode doesn't work everywhere, still useful when it does
This topic is about website input forms, what OS configuration do you need to visit a website? Dang you're being highly inconsistent here. Should this just be an input on a website or an OS level keyboard remap?
You're being quite rude to assume I don't know how to remap keys. I know how, I just don't care keeping a keyboard map on me all the time and remapping everyone's keyboard just because I'd like to type numbers not using the number row. I'd rather just have the muscle memory of being fast with the number row.
> Which laptop allows using uio as 123 when in a numeric input field?
Not uio as 123, but that's not really emulating a computer number pad anyways as a computer number pad has 789 along the top. So not only is it skewed you're wanting it flipped from how normal keyboard numberpads are.
FWIW it was a line of Dell Inspiron laptops in the late 90s and a Compaq laptop in the mid 2000s that had a number pad on the keyboard, however it usually reused the 789 along the top. It wasn't a massively uncommon feature back then, but it definitely wasn't on every laptop. Mostly on business focused machines from my experience.
You're being incredibly hostile to me just saying I used that kind input before and personally didn't care much for it. I'm just sharing my personal experiences using that input you're suggesting for a couple of decades on and off. An input style that clearly wasn't popular enough to continue carrying forward on modern laptops despite being somewhat common decades ago.
Up to you, I didn't bring all this irrelevant personal stuff up. Or instead of doing either you could bring up another one: faux inconsistency
> to assume I don't know how to remap keys.
No, I assumed you didn't
> I know how, I just don't care keeping a keyboard map on me all the time and remapping everyone's keyboard just because I'd like to type numbers not using the number row.
This is also hyperbolic nonsense, you don't need to do any of that (why would you ever keep a keyboard map on you at all???), keyboards you use 99% of the time is literally just a few of them, so remapping them is nowhere close to remapping everyone's
> So not only is it skewed
Which I've already addressed and you still couldn't respond. Your fingers are skewed, so ergonomic numpad wouldn't be linear
> you're wanting it flipped from how normal keyboard numberpads are.
Or I want it matching how (very frequently used) normal phone numpads are. But that's also an sidetracking nitpick since proper design would match whatever the use wants, so 789 would also fit
> FWIW it was a line of Dell Inspiron laptops
FWIW this is false, there were/are no such laptops, you're just too tied in trying to twist your personal story into some argument to address what I'm actually saying. Laptop is not aware of your input fields, so they can't dynamically switch to a numpad on the main alpha keys. And yes, they reused 789, so again, no laptop used an ergonomic no-mod numpad input mode.
> just saying I used that kind input before and personally didn't care much for it.
That's not all you're saying, and more importantly, that's not what I was arguing against since, again, how is your experience relevant this? Yet you keep bringing it up...
And yet the numpad people really seem to like is a straight grid.
> That's not all you're saying
My original comment was literally my personal experiences and the reasons why I had those experiences.
> how is your experience relevant this?
I used pretty dang similar keyboard layouts on several devices for over 20 years and didn't enjoy it. That's what makes it relevant. It's like you're saying, "chocolate is objectively the best flavor of ice cream" and I'm saying I've had it a bunch over 20 years and still prefer vanilla. And apparently it's not exactly a feature most other people are clamoring for, because while there are some laptops out there with that feature it is pretty much never a notable one. In fact, its such a non-notable feature you're telling me they don't exist. Instead, people who want a number pad choose to buy bigger laptops with a number pad laid out in a straight grid instead of dealing with the number pad mixed in the alpha keys.
> FWIW this is false, there were/are no such laptops
You're trying to gas light me saying laptops sitting in my closet don't exist and couldn't possibly work. Turns out Dell even has decently modern-ish Latitude laptops with this layout. And looking at my stack of laptops I even have an HP that had that feature as well. You're right they didn't know the input field, but you'd just hold fn with your left finger and suddenly they'd be number pad keys (or toggle fn lock or numlock or whatever for the specific model).
https://www.computer-keyboards.com/laptop_keyboard_for_dell_...
https://www.cpumedics.com/dell-pk130vn1a00-black-keyboard-us...
I'm done here dude. You're being so toxic to someone just sharing a personal experience of using a keyboard like this and finding it not that great, to the point you're trying to gaslight me into believing these laptops don't exist. You're clearly not interested in any bit of a productive conversation. You don't need to get so angry and rude over someone sharing their experience over a keyboard layout feature.
I'm a "numpad person", and you aren't one of us, you "eschew numpads", so why do you speak on our behalf? Also, people like a lot of suboptimal things, so what? Like, you really seem to like all these non sequiturs and using personal experiences in place of addresing an argument. What does this prove?
> My original comment was literally my personal experiences and the reasons why I had those experiences.
And my original replies were literally about everything but. They were about how humeric row was worse due to having to stretch and how regular numpad isn't as perfectly ergonomic etc.
> on several devices for over 20 years and didn't enjoy it. That's what makes it relevant.
But how does it, specifically? You still haven't answered the original question about how your unwillingness to remap numpads on your friend's keyboard is relevant to a web form where you don't need to remap anything, veering off into some other snark
> It's like you're saying, "chocolate is objectively the best flavor of ice cream" and I'm saying I've had it a bunch over 20 years and still prefer vanilla.
More like me saying "your fingers have different length, so a design that takes that into account is more ergonomic" and you saying you have 20 years of experience eating chocolate
> You're right they didn't know the input field
> Not uio
So why are you trying to gaslight me into believing they exist when they don't?
> and couldn't possibly work.
That's again something you've made up, it could work: you track active input field type and switch to a numpad mode if it's numeric. Just like phones already do
> You're clearly not interested in any bit of a productive conversation.
For that you'd need to start saying something productive instead of measuring anger over the wire
You're so toxically wanting to gaslight me you didn't even look at the keyboards in question to see that yes, they do have the choice to use uio as numbers.
> I'm a "numpad person"
And yet you thought the top row of a PC numpad was 123...
I did, both of the links, you're just again "toxically" shifting your ignorance unto me and replacing substantive conversation with personal attacks
> they do have the choice to use uio as numbers.
No they dont, both pics start with 789 as the top, which is unergonomic (even for "pure" numpad emulation that requires shifting all the /*-+ signs to unfamiliar locations), that's underutilizing your most ergonomic finger/key. And I've specifically mentioned "uio as 123", so you're just openly disingenious now claiming any uio nubers are fine
> And yet you thought the top row of a PC numpad was 123...
That's your fantasy again, of course I knew it's 789 on an unmodded PC numpad, I was typing on a keyboard with a numpad! But I'm also not as limited in my perspecive as to think that whatever exists is the best thing ever and perfectly reflects the inner desires of the people, so I have a different remap, though that's a minor thing you're trying to blow out of proprtion because you can't address the substance of the other claims
> No they dont
They do. Not 123, but "they do have the choice to use uio as numbers".
I say "they do have the choice to use uio as numbers". You say they don't. I look at the photo, and they have uio as 4, 5 6. I guess those aren't numbers to you, only 1, 2, 3 qualify as numbers. This is why I say your responses are toxic. You're literally telling me here they're not being used as numbers ("no they don't"), when they are being used as numbers, just not the specific numbers you're wanting here.
The keys being shifted one row up from your idea to include the zero and period in the number pad is pretty much an immaterial difference to me here. This is why I say "I used pretty dang similar keyboard layouts", note "pretty dang similar" not "entirely, exactly, 100% as you suggested". Ergonomics are often subjective and individual (not everyone's hands are the same!), but you're acting like what you consider ergonomic is just completely factual and unyielding and apply globally. The reasons why I didn't care for the numpad mixed in the keyboard's alpha keys wouldn't change if you shifted the rows around.
All I've really been saying is I personally don't care for having numpads mixed in the alpha keys, and you're telling me those keyboards similar to your idea don't exist and berating me for assuming I'm too dumb to know how keyboard remapping works. This is why I say your responses are toxic. I'm really done here though, I don't think you'll ever accept there are keyboards that have uio as numbers or that other people have their own experiences with what is ergonomic.
So they don't, and all you have to do to understand the context is just not cut out your own words "Not uio as 123," is what I've shortened in my quote to "not uio", so no matter how much you stare at the pictures, you can't remove that. If you followed the conversation honestly, you could even fit 789, but still not 456. You also forgot the other part about input field recognition, so you've twisted both of my original qualifiers to fit your irrelevant experience as an important argument
> The keys being shifted one row up from your idea to include the zero and period in the number pad is pretty much an immaterial difference to me here.
You can include 0 and period just fine without any shifts. And it is material, just like breaking positioning of signs is. You're not a numpad person, so you don't know/care, but I am and do, so...
> This is why I say "I used pretty dang similar keyboard layouts"
...that is why I keep saying that your experience is not related to what I was talking about
> Ergonomics are often subjective and individual (not everyone's hands are the same!)
But everyone's hands have fingers of different length which don't move in perfect grids. You can't subjectivate your way out of this simple biological fact
> The reasons why I didn't care for the numpad mixed in the keyboard's alpha keys wouldn't change if you shifted the rows around.
But then the reasons why other people care would change
> All I've really been saying
That's not what ... oh, wait, your just repeating the same falsehoods that I've already addressed
It seems like forgotten information, but all of these computer interfaces that were invented in the 80s and 90s were built by doctorate level professionals who spent years thinking about these things. Why do all these bozos who took a six month code boot camp (or at best, finished a four year degree with a 2.9 GPA) think the ten minutes they spent thinking about it lead to some brilliant insight?
I've encountered navigation bars that use this pattern, which is really frustrating to my preferred way of browsing.
Somewhat related is a plugin (Safari, Mac) called StoptheMadness). It aims to end stupid crap like this. I’m not the dev.
I will never understand software engineers who feel they need to build their own custom controls, or who won't push back when their "designers" insist on it. You could be doing so much with your life, but here you are re-implementing scrolling again.
“The only problem with [modern software developers" is they just have no taste. They have absolutely no taste.”
Most developers working today haven't regularly used software that doesn't suck so they're not personally offended by unusable designs or 500ms of latency when typing.
The one that annoys me most is whenever someone needs to enter a code with a fixed length. Like a 6 digit OTP code. They want to have a UI with 6 separate input fields: _ _ _ _ _ _ that behaves like one input and only allows the correct values and has the cursor behave correctly jumping from one box to the next as you type / backspace. Turns out, creating that UI element is kinda time consuming and adds NOTHING and at best results in the same user experience as just tossing in an HTML input element, and more often than not results in some non-standard behavior that breaks something (auto-fill, paste, arrow key, accessibility, etc, etc). Just use a standard input, throw some css on it to make it the characters big if you want.
I believe most people that do this kind of thing do it because they don‘t know there‘s a native API that works better for these things.
Remember, the software engineers that are good at their jobs aren‘t the ones that end up teaching at coding bootcamps.
Because the web is a terrible platform that made basic reusable components far harder than they ever needed to be, so every developer got into bad habits of rolling their own solutions to every problem. It's gotten better now but modernizing involves throwing out literal decades of practice.
For developers supporting projects implemented using simple raw-js or things like jquery, it's no wonder they developed a habit of DIY. I've had review so much code and push back on this stuff, so I fully understand why it happens.
God, that was such a pain. I recently ripped 20k(!) SLOC out of a project that was finally allowed to drop support for those old Safari versions. All just to display one single datetime picker.
The entire rest of the project is less than 2k SLOC.
I hate when people try to do the dropdown and the "write your own" in one field. It's very confusing how to use those.
I think it made them just hard enough to ensure continuous employment of lots of web developers :)
You took “don’t reimplement the browser”, something that is generally incredibly true, and cargo-culted it into placing some old farts on a pedestal just because they were there ‘first’.
I'm not saying these ideas shouldn't be revisited, but if you're going to revisit them, do it at an academic institute, where you can spend time figuring out the problems, not at your commercial job where you have to ship next week, no matter how broken it is.
But my experience is not the same. It has always been others telling the front-end devs what we "need" to have. I am constantly pushing back with "buttons and links should look and act like buttons and links", "right clicks don't belong in CRUD apps", and "we have a select component that does that". But _BUSINESSES_ want their identity and unique perspective baked into the app.
For example, there is a fashion [1] to include hashes in the names of static assets served. But that's what ETag header is invented for, in the RFC since a decade and implemented in all browsers.
[1] (I deliberately call it a fashion, not a standard; would rather say that RFC 7232 is a standard in this particular case)
Or perhaps just that it skews young, which I could believe, and might be easier to find survey data on.
This. So much this.
I've gotten down-voted in the past for being really harsh on Macs, this is because I've worked places where the company would only issue MacBooks to its developers, and requests for non-Macs were denied by a blanket policy. So I kind of hold a grudge that's more fairly directed at the companies rather than Apple (but still, Apple's "our way or the highway" approach is antithetical to my way of interacting with computers). These company policies not only affect developer productivity when your engineers have decades of experience training themselves to be productive on their non-Mac system of choice, but it gets so much dumber when your company officially supports non-Mac-using users.
p.s. please everyone: factory reset your phones before you sell them :)
The one rationale that makes sense to me when it comes to restricting choice to a certain degree is the ability for IT to remote-wipe if necessary.
How important that is will depend on context. At my current place of work, most company data is accessed through various web applications so if the computer were compromised, there is no sensitive data kept locally that would require wiping. Though I suppose it could be argued that browser caches could be sensitive, and even if you couldn't sign on to those web apps, due to MFA, an attacker could still get information about procedures and tech used that would get them closer.
But if they're using JAMF or something they can at least support Windows and Mac. The only other reason that I can think of that a company would have such a policy is economic... but lost productivity and user frustration is a hidden cost, so how real the economic advantages of standardizing are is something I question.
Testing is more thorough, and endpoint management remains focused on just the one authorized system.
But that's "the best of one world", not "both."
The other half of the equation is developer experience and productivity.
I'm not going to blanket bash Mac or Apple, because many people love their devices. But being someone who has used computers since the 1980s, who has vision difficulties (the fonts and inability to adjust them on MacBooks actually cause me headaches) and is extremely accustomed to a particular workflow, keyboard layout, shortcuts, the ability to customize all aspects of the desktop environment ... I find the experience of using MacOS 8 hours per day to be intolerable. To pour salt on the wound, the new habits that I started forming on the work devices began interfering with my use of personal devices (suddenly muscle memory was getting confused).
And yes, it's my choice where to work. The last time I got downvoted for expressing this opinion, I said that I almost resigned due to this. Had the company not been able to accommodate me (the CEO was actually surprised to learn that IT had instituted a blanket policy and said "that's dumb, of course we will issue PCs to those who request them") then I would have eventually found work elsewhere because it was that big of a misalignment for me. And I tried to adjust for a year and a half before finding myself in the position where I was really thinking that I couldn't do it anymore.
People who have grown up using Macs, or who feel comfortable using either or, cannot empathazise with this position. But after 40 years of being a programmer, having high functioning autism and thus being inflexible in routines and habits, my computer and my way of interacting with it is almost an extension of me. When you mess with that tool, my productivity and morale drops very significantly. And having spoken with others in these environments, I know that I'm not the only one.
But, again, this isn't really trying to bash Mac, it's attacking a policy that ignores that software engineers are most productive on certain systems vs others and that those choices are deeply personal.
Again, security is only one factor. An important one, but you can't have "best of both worlds" while ignoring one massive "world" that I was talking about.
ignoring the biggest of world, mac aren't the standard, nor more widespread, and never was
I happen to struggle with the trackpad on non-Mac laptops to an extreme degree, and while I don't put that in the same category as reasonable accommodations required by the ADA of course (probably just lack of practice), it does help me (along with web UI a11y training and formal job responsibility) empathize with the point you are making to some extent. Glad to hear it eventually worked out with the CEO.
Standardizing on a small set of easily available hardware, a single popular OS, and a single set of tools across an organization can have vast benefits in direct proportion to the scale of that organization.
On the other hand, you are one person who is set in their ways.
In some ways, I’m a lot like you. I know the straitjacket feeling when placed into an unfamiliar or uncustomized environment. At this point, adapting to new interfaces has happened so often and so many times that I consider it a core job skill.