I can't use my number pad for 2FA codes
shkspr.mobi
shkspr.mobi
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.)
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.)
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).
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-...
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'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?
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.
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.
I think it made them just hard enough to ensure continuous employment of lots of web developers :)
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'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 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.
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 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.
“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.
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.
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.
p.s. please everyone: factory reset your phones before you sell them :)