This is what I sees getting missed in a lot of LLM conversations. They're amplifiers. Full stop. If you have good practices they supercharge them, if you had bad practices, same thing.
> But they insisted. E.g hijack brosser native controls.
[Rant-Example] The goshdarn ticketing-system hijacks alt-f, so that instead of opening the File menu of my browser, and instead toggles the favorite-status of whatever ticket I happen to be viewing.
A mistake was made early on even letting web apps see keystrokes like that. In a better world, modifier keys were used in a principled way from the start - only the window manager gets to see meta-anything, only the shell or GUI app gets to see control-anything, and web apps can work with alt-anything.
To be fair, the native browser controls have had too many quirks and features fox UX/UI consistency.
Corporate needs their Brand™ look precisely as specified in their expensive Style Guide. IBM wouldn't want the Google vibes of Android Material Design TextFields, I imagine.
Scratch beneath the visuals, and starker technical differences appear.
Safari on iOS (used to?) has a 350ms debounce delay on every tap / click, in case you want to do a multitouch gesture.
JavaScript (Frameworks) were the only way this arbitrary delay to user input could be reduced before 2015, when Apple finally released a native API for this.
This is what I sees getting missed in a lot of LLM conversations. They're amplifiers. Full stop. If you have good practices they supercharge them, if you had bad practices, same thing.
I saw a trend of UX/UI designers coming with practice which I knew better were wrong. But they insisted. E.g hijack brosser native controls.
Will never know whether they passed along some manager/PM commandements or were just incompetent.
> But they insisted. E.g hijack brosser native controls.
[Rant-Example] The goshdarn ticketing-system hijacks alt-f, so that instead of opening the File menu of my browser, and instead toggles the favorite-status of whatever ticket I happen to be viewing.
A mistake was made early on even letting web apps see keystrokes like that. In a better world, modifier keys were used in a principled way from the start - only the window manager gets to see meta-anything, only the shell or GUI app gets to see control-anything, and web apps can work with alt-anything.
Have you tried creating a ticket complaining about this?
1 reply →
To be fair, the native browser controls have had too many quirks and features fox UX/UI consistency.
Corporate needs their Brand™ look precisely as specified in their expensive Style Guide. IBM wouldn't want the Google vibes of Android Material Design TextFields, I imagine.
Scratch beneath the visuals, and starker technical differences appear.
Safari on iOS (used to?) has a 350ms debounce delay on every tap / click, in case you want to do a multitouch gesture.
JavaScript (Frameworks) were the only way this arbitrary delay to user input could be reduced before 2015, when Apple finally released a native API for this.
https://webkit.org/blog/5610/more-responsive-tapping-on-ios/
> To be fair, the native browser controls have had too many quirks and features fox UX/UI consistency.
Well, too many to have a single website be consistent across browsers.
But as a user I'm using one specific browsers, and I expect all websites be consistent for that browser.
With some resistance. Now they do it far more often.