ug, nothing worse than web apps capturing my browser interactions. please don't add keyboard shortcuts, don't disable right click, don't capture Ctrl+F preventing me from using the browser search.
no, your re-implementation of existing browser feature is not better or even wanted.
Unsure about other browsers but Firefox lets you allow/block websites from overriding default keyboard shortcuts on a per-site basis as well as globally (defaults to global allow).
Individual site config is located here: application menu bar > "Tools" > "Page Info" > "Permissions" tab > "Override keyboard shortcuts"
The extension StopTheMadness provides similar functionality for Safari, as well as prevention of other types of annoying behaviors (like nonstandard context menus).
Unfortunately this breaks some semantically-compatible extensions to standard shortcuts, like Ctrl-C in Google Docs, which is a perfectly reasonable, necessary, and helpful override, unlike many.
I have found allowing overrides is unfortunately the least annoying of two bad options. But I still get unreasonably annoyed when web apps steal Ctrl-K which I use constantly.
On the other hand Google Docs also steals Ctrl-H which I never want to not open the browser history browser. I really wish Firefox has much more customizable keyboard shortcuts. Being about to define arbitrary bindings and control which bindings can be overridden by which sites would be an incredible productivity feature.
GitHub (and GitLab, and Linear if I recall, and others) overriding Ctrl-F (or /, which Tridactyl needs) is a crime against humanity. I know GitHub claimed they'd stop, but I still was getting weird interactions not long ago (then again, the entire recent UI redesign of GitHub drives me absolutely insane to the point that I have zero positive things to say about it, so maybe I'm just no longer their target audience).
I haven't heard any discussion about it, and second your take on the redesign. I find it harder to use, prone to the sort of unfriendly-ness discussed in this thread, and more resource intensive and/or less responsive.
I feel you, I do. I am a simple GitHub user with simple needs, and GitHub's latest redesign is a giant leap toward unnecessary complexity. I don't need multiple panels and all the geegaws. My use of GH in terms of what I need to do for my employer has become much more difficult lately. And the whole search debacle is the worst. I absolutely depended on that feature, and they somehow managed to Nerf it!
The absolute worst thing is the basic code view. If I accidentally click inside it, a text cursor shows up. Ctrl+F is then hijacked to do... previously nothing! I need to find some piece of unclickable chrome to click on and remove the "focus" from the code view, then I can Ctrl+F to find what I'm looking for with the browser's page search.
This is absolutely infuriating, and the crux of it all is that I can't even edit the code that is taking focus and hijacking shortcuts! The goggles do nothing!
And for heck's sake outlook, really, did we NEED modifier-less keyboard shortcuts triggered by single letters? $deity help you if you try to type in Slack while Outlook's Web App is focused; you're likely to archive a dozen emails and possibly delete a folder.
Even though Discourse allows you to get the native Ctrl-F functionality by pressing the combination again, I hate the fact that it even captures that in the first place :(
It does have to do with web apps because web apps are built on web technologies. And those technologies involve a standardized set of events that are used to react to keyboard interactions. And those standards are deficient.
Non-web apps are subject web technology specifications.
I think I'm misunderstanding your reasoning. To me, an app's feature set and its implementation details are unrelated topics. Whether your project came from an app store, the web, a friend's USB stick, etc, is irrelevant to what it does. Ditto for the internal technologies it uses -- Qt, Electron, .NET, pure assembly, etc.
I absolutely sympathize with webpages disabling search features and so on, but I'm not sure why exactly. Pointing to app implementation doesn't seem quite right, if that makes sense.
I'm not talking about where it came from. All web apps use the "web platform". HTML, CSS, JS, DOM, and related technologies. Web apps are limited to behaviors that are possible using these technologies.
As an example, you can't make a web app that controls display brightness.* It has everything to do with the fact that it's a web app. Web apps are built on web stuff, and web stuff provides no way to do it.
So it is with keyboard events.
* As far as I know, this is true. Maybe there's some new experimental spec or something? But you get the point.
Again, you can say the same about native apps and userland. It sounds like you just don't like the way the Web APIs have expanded in scope over the last 20 years or so. This is the better future. It used to be so much uglier in the era of flash, activex, etc.
Oh and by the way the screen brightness probably can be adjusted using the USB APIs if someone bothered to port over drivers for the most common keyboards.
At least all major browsers alert the user to choose if the web app can use these APIs unlike native apps.
>don't capture Ctrl+F preventing me from using the browser search.
Browser search only searches visible text in the DOM. For performance reasons the whole page might not be loaded into the DOM. This means the default browser search will provide incomplete results.
Maybe, but maybe (usually) that's exactly what I wanted. Browser search has well-defined semantics, many of which are useful in ways that are not exactly 'searching the content'. These are semantically different things and overloading the shortcut is frustrating. Use a different shortcut for your incompatible functionality. For example I might use Ctrl-F to look for a UI element like 'Contact Us' that's hidden at the bottom of the page, or to refer to a stanza I read a minute or two ago without trying to find it with my eyes and the scroll bar. Or even to try to find where what I searched for appears when I have clicked on a search result. This last one is especially frustrating.
If I specifically want to search the entire corpus of data on an infinitely-scrolling site, I will use its search function intentionally, since that is a semantically different action.
This isn't some insolvable problem. Just have a separate search box and use that for cross-pagination/serverside search. Use a separate hotkey for it, like '/', as many sites do, and leave ctrl-F for the browser search.
Reminds me of that sort story (Asimov? Seems like him) where someone hits on the genius idea of printing thing out of the computer to read later and, after a few false starts including gigantic billboards which you have to read using sliding ladders, hits on the astounding trick of gluing thin sheets of text into portable stacks joined by one edge.
Why paginate when it doesn't make sense? I don't want a pastebin to be spread over multiple pages. I want the text file to show up on one page, but to not cause any performance issues. I want to be able to search for any line in that text file without having to search each page.
default ctrl-f will only search through the current page while the site-provided one can search through all content... this is not really an argument against it existing
But it's about inpage search, it's just a lazy loading page.
The dedicated search field is for searching my websites and the result would be a list of my pages that contain the search term. Ctrl-F jumps to the location of the search term on the page I'm already at.
Concrete information on Japanese input for your list:
For English input, being able to submit comments/chats with the enter key is a feature, but for Japanese (and maybe Chinese?) users it's a bug.
In Japanese the enter key is used multiple times to select from multiple possible characters while composing a sentence—it's just how Japanese input works. If an app submits when enter is pressed, it's very difficult to finish typing even a single sentence. Often the only solution is to compose text elsewhere and then copy/paste.
There's a better solution: wrap your inputs in a form element and rely on the submit event rather than a keyboard event. The browser knows (or should know!) if the user intends to submit or not.
This is a very strange rant. I’ve built keyboard shortcuts for app used by thousands of international monthly users and have never had a complaint about it.
Also… “onKeyPress” gives you names for most non-letter key presses.
For example, Reddit's rich text editor is broken for me. I cannot type an "é" in it - unless I switch to the manual Markdown mode. Is it annoying? Absolutely. But it only bothers me once every few days and there is a workaround, so whatever.
As international keyboard user – yes, I'm so used that keyboard shortcuts don't work for me that I don't bother to report it. I did it many years ago, but after tens of "we can't do anything about it" answers stopped.
Has anyone worked with/built a web app that let's users set let their hot keys? Seems like it should be possible? That way users who like hot keys can just pick the ones they want...
It certainly is possible, it just so rarely shows up in modern web projects. It is not something I have ever seen raised in a UX design meeting or during development.
I honestly think it's just lack of awareness. I know it's partly because we warned against jacking native behavior, I think that probably scared people off shortcuts on the web early on. Now we have really complex web apps, but shortcuts are still not being thought about.
Reminds me of the president of a software house that wrote inventory software for large commercial warehouses. One of his customers required "Box ID", an essential capability that not only tells you how many we own, but exactly which boxes they are in. Everyone has it today.
These people attempted to satisfy this customer, but after a year and nothing to ship (it's not that hard!), they backed out and cried, "We'll never do Box ID again!"
Imagine an app without keyboard shortcuts. Web sites.. sorry,apps, not having them is one of the reasons they suck. Please, try and compensate for sucky sites by pretending better that they are apps.
I think this is a normal (and unhealthy) consequence of the JS browser APIs keeping expandong. A sort of Greenspuns Tenth Rule Of Programming that happened on the web platform.
I am not sure there is a cure. Every successful platform would have been bound to eventually become that.
AWS has this thing that allows you to connect to an virtual machine from the web console, giving you browser based terminal. Very convenient and nifty. Except using ^W to delete word is so hardwired in my muscle memory that I ended up accidentally closing the tab (and losing state) endless times... I don't think its solvable problem
That being said, same issue happens, albeit to a lesser degree, with desktop apps where occasionally the DE/WM shortcuts conflict with some applications shortcuts.
In Firefox you can enable the ui.key.textcontrol.prefer_native_key_bindings_over_builtin_shortcut_key_definitions setting, but I think you also need to enable Emacs keys in Gtk.
With this I'm able to use Ctrl+w normally in the Gitpod terminal, so this might work for the one in AWS as well.
My personal annoyance is when they hijack cmd-f to implement custom search functionality. Especially (but not only) when they fail to handle cmd-e and even more especially cmd-g.
I even understand why in some cases it’s necessary to provide custom search. For example to implement search over lazy loaded content which hasn’t yet loaded. But it never works as expected, even when it’s done well.
I don’t generally use Google Docs but was surprised to note the other day when using it momentarily with a client that it hijacks Cmd + Shift + R (clear cache and reload tab) on Mac Firefox. Not sure if there are others - I assume so. Truly obnoxious.
It seems not very well known that you can actually reclaim your alt/option key on MacOS by using the Unicode Hex Input Source for your keyboard. It's not a particularly useful tip if you every need to type accented characters, but great for the rest of us.
I suppose the problem is that sometimes you want keyboard shortcuts to be non-arbitrary keys. If you're on dvorak, you wouldn't want WASD to be your movement keys in an FPS. They are nowhere near each other. So applications need some sort of API to figure out what keyboard layout is in use, so they can setup the appropriate bindings. (The OS tells them which letter was pressed, not which (row, col) on the keyboard was pressed. But in this case, you kind of want that raw key matrix event.)
This is basically impossible, because the key matrix -> letter translation can be done in multiple places (in the keyboard firmware, in the OS, etc.). Hilariously, sometimes your keyboard firmware has to be aware of the OS translation; you cannot send a & keypress event over USB, so you have to send "shift + 7" if you want a key that generates that input. Because of all this, application developers have to add a "key binding preferences" page to their application. There is absolutely no way they can target a certain physical location on your keyboard.
None of this is specific to Javascript, of course. This is all about protocols and the OS.
> This is basically impossible, because the key matrix -> letter translation can be done in multiple places (in the keyboard firmware, in the OS, etc.). Hilariously, sometimes your keyboard firmware has to be aware of the OS translation; you cannot send a & keypress event over USB, so you have to send "shift + 7" if you want a key that generates that input
As someone who just is getting into custom keyboards, this is one really ugly wart in the whole stack. imho ideally keyboard would just send individual scancodes and the host would manage all the key layout stuff. But making fully custom layouts complete with custom modifiers is afaik pretty much impossible with Windows/Mac/mobiles, and even on Linux its bit of a pain. So it ends up easier for keyboard to pretend to be a standard keyboard and have macros to send complex scancode sequences and then just have standard US qwerty layout on host side. Which kinda works until you want to input stuff that is not on the standard US layout at which point you need some different layout on the host, and then you need to remap the keyboard so that it is in sync with the layout. And then you need to sync these configurations across different computers and operating systems.
Sometimes standardization is great, but sometimes it hides all sorts of pitfalls that you'll stumble upon once you actually want to step outside the standard solutions.
It's not really a problem with the APIs, it is a problem with the common knowledge of how keyboards work.
There is no 1:1 keyboard position -> letter mapping, nor is there a 1:1 letter -> keyboard position mapping. This means something like "detect a press and hold of whatever key results in the input 'w'" is impossible. You can detect an "input" event for it, but there is no guarantee that there will be a "keydown" or "keyup" event. Similarly, you can't have something like "show the label on the key which is normally labelled 'w' on a Qwerty keyboard". It is not guaranteed to have a character associated with it.
Technically nothing is stopping you from creating shortcuts, but you are going to have an awfully hard time creating them in a way which works for all users.
getLayoutMap(), which Mozilla and Apple initially determined carried a significant fingerprinting risk. I don't know if Apple's position or the spec changed, but caniuse says Safari's Technology Preview does support it, so it's apparently coming there soon.
This is one of the big reasons why I am not on board with the webapp train. In order for them to be realistic replacements for real applications, the API would have to be very robust. And a very robust API comes with serious privacy issues.
The web is far too hostile of a place to allow exposure of a robust API to it.
no, your re-implementation of existing browser feature is not better or even wanted.