[HN Gopher] Keyboards and web apps, my post/rant for the year
___________________________________________________________________
Keyboards and web apps, my post/rant for the year
Author : todsacerdoti
Score : 70 points
Date : 2023-07-14 15:29 UTC (7 hours ago)
(HTM) web link (pb.co.za)
(TXT) w3m dump (pb.co.za)
| irrational wrote:
| So, calendars/dates are complex, storing people's names in a
| database is complex, keyboards are complex. What else?
|
| There are 2 hard problems in computer science: cache
| invalidation, naming things, off-by-1 errors, and all of the
| above.
| pieterbreed wrote:
| If i knew my post would do well on hn I would have posted it here
| myself. Well played.
| readonlyaccount wrote:
| 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.
| moritzwarhier wrote:
| The second reason web apps suck is when they have keyboard
| shortcuts.
|
| E.g. Outlook Web hijacks CMD+R on my Macbook, of all things.
|
| Wouldn't want to miss CTRL/CMD+K in some web apps though.
| eyelidlessness wrote:
| 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.
| teddarific wrote:
| Definitely one of my pet peeves is when an app overrides a
| default short cut. Especially one like refreshing the page.
|
| I wish there was some sort of universal agreement or API for
| what short cuts should do functionally.
| hnrodey wrote:
| Jira hijacks Control+F and directs you towards their custom
| search functionality. Exactly what I DON'T WANT.
| muxator wrote:
| Yep, github too is guilty of this sin.
|
| 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.
| zokier wrote:
| 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.
| saint_yossarian wrote:
| In Firefox you can enable the ui.key.textcontrol.prefer_n
| ative_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.
| ehnto wrote:
| Vimium kind of gets you there. At least, you don't have to move
| your mouse with it.
| edw519 wrote:
| Nice little rant.
|
| 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!"
|
| I wonder what that guy is doing today.
|
| And I wonder what OP will be doing tomorrow.
| pieterbreed wrote:
| OP will be sleeping in, eating at the pub nextdoor, looking at
| Table Mountain on the way back home and playing Dave the Diver
| in the afternoon.
| csw-001 wrote:
| 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...
| TonyStr wrote:
| That's a lot of work for satisfying very few people. My boss
| would not be happy
| jay_kyburz wrote:
| I'm normally the first person to say we browsers don't need
| to be any more complicated, but this is one thing I think
| would be pretty cool.
|
| Website authors could specify a list of [name, callback,
| defaultKey] and each browser could implement an interface to
| change the binding locally.
|
| There could be a button right in the address bar for both
| discovering them and changing them.
| ehnto wrote:
| 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.
| amadeuspagel wrote:
| What exactly is the problem with the new web APIs? What exactly
| doesn't work on Firefox and Safari?
| CharlesW wrote:
| 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.
| JohnFen wrote:
| 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.
| 20after4 wrote:
| This is already solved, web browsers have APIs protected by
| permissions that must be explicitly enabled by the user.
| JohnFen wrote:
| Yes, for a lot of the calls, but not all of them. And I'm
| very hesitant to trust the browsers at this level anyway.
| jrockway wrote:
| 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.
| pieterbreed wrote:
| As a dvorak typist HJKL as a concept is dead to me.
| jrockway wrote:
| I feel like it should have been jkl; anyway.
| zokier wrote:
| > 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.
| crote wrote:
| 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.
| blitz_skull wrote:
| 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.
| pieterbreed wrote:
| One of my users apologised for having an AZERTY keyboard. The
| people out there suffer us.
| crote wrote:
| Maybe your users are just used to it?
|
| For example, Reddit's rich text editor is broken for me. I
| cannot type an "e" 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.
| dwg wrote:
| 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 is a solution: check the keyboard event isComposing
| (https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...)
| property (alternatively, oncompositionstart and oncompositionend)
| and only submit if false.
| bastawhiz wrote:
| 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.
| 38 wrote:
| 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.
| croes wrote:
| An app without keyboard shortcuts is cumbersome to use
| pieterbreed wrote:
| Emacs or vi?
| sublinear wrote:
| Anyone can pose similar complaints for native apps and janky
| desktop environments. This has nothing to do with web apps at
| all.
| croes wrote:
| Native apps are apps, but web apps are apps in an app with
| already existing keyboard shortcuts
| recursive wrote:
| 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.
| a_wild_dandan wrote:
| 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.
| recursive wrote:
| 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.
| charcircuit wrote:
| >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.
| error503 wrote:
| 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.
| solardev wrote:
| 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.
| 38 wrote:
| if you cannot load the whole page for any reason, that's a
| failure of design. use pagination, that has existed since the
| 90s.
| charcircuit wrote:
| 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.
| croes wrote:
| How does pagination solve the search problem?
|
| The content you can find wih the browser search still
| doesn't do d the text on another page. A custom search
| could including a jump to the page.
| adhesive_wombat wrote:
| 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.
| 38 wrote:
| AKA books.
| SuperCuber wrote:
| 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
| 38 wrote:
| so can a POST form request. why people feel the need to
| reinvent stuff that's existed for decades is beyond me
| croes wrote:
| How does the user know which search to use? Ctrl-F vs
| search box with POST.
|
| Forcing a request what could be done locally is bad
| design.
| charonn0 wrote:
| By longstanding convention. Ctrl-F is the conventional
| in-page search combo, while a dedicated search field is
| the conventional website search engine.
| krono wrote:
| 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"
| jwells89 wrote:
| The extension StopTheMadness provides similar functionality
| for Safari, as well as prevention of other types of annoying
| behaviors (like nonstandard context menus).
| error503 wrote:
| 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_.
| kevincox wrote:
| 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.
| klardotsh wrote:
| 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).
| LanternLight83 wrote:
| 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.
| 38 wrote:
| bless you
| renewiltord wrote:
| Sorry, no. I can't use Gmail without shortcut keys and I love
| Gmail with. Great job, Google engineers. Good app. Good
| shortcuts.
| navanchauhan wrote:
| 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 :(
| ecf wrote:
| > please don't add keyboard shortcuts
|
| This is entirely unreasonable. Imagine Google docs not being
| able to offer a shortcut to enable bold formatting, for
| example. Terrible experience.
___________________________________________________________________
(page generated 2023-07-14 23:01 UTC)