3 ms·

> Curious how you solved the WASD problem not if not by using a keymap in some way? Short answer, I just give the users an option to change their keyboard layo

> Curious how you solved the WASD problem not if not by using a keymap in some way? Short answer, I just give the users an option to change their keyboard layout and use arrow keys/mouse as a backup for menu traversal in case they set their bindings weird and get stuck. For apps where that's annoying to prompt, I still provide the option but default to assuming QWERTY layout unless I see some signal (language options) that tells me I should more explicitly ask. Longer answer, I don't have hard stats and this is mostly just based on my intuition, but my feeling is: - QWERTY tends to be a pretty safe default for most US users, DVORAK tends to be either uncommon or the people using it already have custom maps set up, which I don't want to mess with. - Other layouts tend to be associated with other languages, so using `navigator.language` seems to be a decent proxy? At the least, if `navigator.language` says something other than "en-us", at that point I might decide to surface a prompt to pick a keyboard layout. - Users would rather be able to select their controls from a list (ie, have some keybinding "templates" or common schemes that players can toggle on) and then customize them, rather than have to build their control-scheme from scratch. ---- I do think it would be easier to have better defaults if I could look up the base layout from a list of common values and default them to a layout that's likely close to what they want. Something like `navigator.keyboard.getLayout` would be useful to me, similar to `id/mapping` on a gamepad. There are privacy risks there too, but I see the use case at least. But that's not really the same thing as wanting a map of every key, a map of every key is less useful to me than a string that says "DVORAK". It's also important to understand that displaying the key on the screen isn't actually the problem here; I don't really understand what the Github repo is talking about in that sense. Without the new API, the prompt you display on the screen will always be correct 100% of the time: if you tell the user to press the "W" key, they'll press the key they associate with "W". So the problem is not "how do I tell the user which key to press", it's "which key should the user press?" And in that situation all you're really looking for is the ability to set sensible defaults; I can't think of an example where I've wanted to be prescriptive about "the user must use their left hand to navigate, and it must be in the location of WASD". So I don't really know what I'd even use a full keymap for, the most I want is a signal for which pre-defined default keymap I should load up. I guess I can use `getLayoutMap` to do that, but it's clumsy and inflexible and requires extra coding: it's kind of an inferior solution to just giving me a layout string that I match against a table. Matching against a table based on ID/layout is also what I already do for controller defaults, so it's annoying to me to have a separate system somewhere else. ---- I mentioned "pits of success" above. There are a few traps and good practices when working with keybindings (opinion me). Some bad outcomes: - Not having rebindable keys or alternate layouts that the user can set. - Not respecting user-rebound keys (my caps lock is escape, I want that button to register as escape in everyone's web app). - Showing inaccurate information onscreen, telling the user to press "W" when you mean something else. Note that this is impossible to do without `getLayoutMap`, and very easy to do with `getLayoutMap`. Some positive results: - Having better default keybindings, as long as they can still be changed As far as I can tell, giving devs the option to ignore user keymaps and to use physical key positions for bindings makes it easier for them to fall into the first 3 traps, and only marginally helps with the second positive result. ---- Anyway, second TLDR, have some common layouts in your key rebinding options that people can quick-select (you probably should have this for WASD/arrow-key toggling anyway, not everyone on QWERTY layouts likes WASD). If you're worried about defaults, use `navigator.language` as a signal for whether you need to be more proactive about asking for the keyboard layout up-front. I also don't really understand what the Github repo is talking about when it says that displaying messages is hard, because as far as I can tell messages about what key to press are the only part of this that are currently impossible to break, and I'm a little annoyed Chrome has now made it possible to break them. Again, maybe there's something I'm missing, I assume devs have some reason for asking for this. I just can't personally think of what it would be, it seems like really bad practice to be prescriptive about what keyboard controls people are allowed to use, and I don't know what else this feature is good for. ---- > That'd be great but there is no reason this couldn't be pursued as a separate layer on top of this instead of something that has to block it. I think my perspective is that I already do have this, it's my keyboard layout. Why are we taking away something that already exists and then reintroducing it as another separate layer that's optional? As a user, I want my keyboard customization to work in all apps, I don't want the developer to be able to override my preferences just because they don't feel like using them. It doesn't make sense to me that we'd get rid of a user-defined map that's currently working today, and then reintroduce it later.

zamadatix 5y ago
> - QWERTY tends to be a pretty safe default for most US users... Other layouts tend to be associated with other languages The point of this is to fix that assumption for the cases it is wrong as well as simplify that process. Rather than have the app assume things about language, country defaults, and non-customization to try to select a hardcoded keymap this API just lets the app reference the actual keymap directly without requiring the user to do anything. Either way though both methods are using a keymap even if you're trying to hide that's what you're really doing. This new way is however easier for app developers, requires less action from users, and more accurate than trying to heuristic your way to the keymap. Similarly: > Users would rather be able to select their controls from a list (ie, have some keybinding "templates" or common schemes that players can toggle on) and then customize them, rather than have to build their control-scheme from scratch. It's nice if this list can show the letter of the key, particularly once the user has left the config menu where you can reasonably show a full picture of the input device i.e. in use e.g. https://i.imgur.com/ZwVjubs.jpg https://i.imgur.com/ZwVjubs.jpg I still argue the entire set of rebinding points are an orthogonal issue. While rebinding is a useful feature it is neither gated by nor gates exposing the current keymap and fixing either individually will not provide the full advantages of having each. > I think my perspective is that I already do have this, it's my keyboard layout. As someone who actually uses a non-language default keymap I'll say it becomes immediately apparent I don't want my keyboard layout to have anything to do with the keymap (besides notification of what the key to press is) in a lot of cases. Of course there are many such as ctrl+c or cmd+q I want to stay the same letter regardless of location as well but exposing the keymap doesn't inherently force anyone to override that even if it allows it. It does however let the apps function fully for the first case.
- danShumway 5y ago
  > Rather than have the app assume things about language, country defaults, and non-customization to try to select a hardcoded keymap this API just lets the app reference the actual keymap directly without requiring the user to do anything. I think there's a really tangible difference between saying that AZERTY layouts prefer to use ZQSD for layout and saying that everyone is going to use the four keys on the left-hand side of the screen. It's sort of the same situation as controllers -- using physical maps to standardize controllers is just flat-out wrong, because different controllers have different conventions about what buttons in the same physical locations should commonly do. It's fine to say that there are common layouts that have defaults, but I think it's a much larger step to say that shortcuts/keybindings should be defined by physical location rather than convention. I don't completely see how that makes thing simpler for me as a developer (I don't want to intuit keyboard layouts by iterating over keys), and certainly I don't want it as a user. ---- > It's nice if this list can show the letter of the key, particularly once the user has left the config menu where you can reasonably show a full picture of the input device i.e. in use e.g. https://i.imgur.com/ZwVjubs.jpg https://i.imgur.com/ZwVjubs.jpg I have some other objections to your points below this (allowing applications to override user preferences is in fact a loss in user functionality, even if developers aren't forced to ignore those preferences), but I want to really focus in on this specific example, because you're not the first person I've seen bringing this up as a problem that needs to be fixed. And honestly, I really don't understand at all what people are talking about with this "fixing keymap messages" thing. I don't think I've ever had a problem with this[0]. Under the current scheme, before Chrome introduced this feature, it was impossible for a developer to mess this up. If you told the user to press "Z", and they pressed the key that they normally press to get "Z", no matter what their layout was or what their keyboard looked like your app would register a "Z" press. Whatever key you told them to press, if they pressed it you got that key. Perfect, impossible to break. But if you now are basing your prompts on a keymap that bypasses the user's keyboard layout and uses the physical position, and still labels those keys based on a QWERTY layout, then it is now possible to break the message and to tell the user to press the "Z" key, and then to have the "Z" key not work because what you're listening to is the physical location of the "Z" key on a QWERTY layout rather than the key that they use in their layout for typing a "Z". So I don't really understand what people are talking about with this objection; Chrome isn't fixing anything about user prompts because nothing needed to be fixed about matching user prompts to keybindings, it worked 100% of the time. The new feature actually breaks that and makes it possible to now implement user prompts that are inaccurate. I believe people who say they have struggled to implement this in the past, they wouldn't lie to me, but... for the life of me, I can't imagine how they're implementing keybindings then; I'm not sure what I could do architecturally to make inaccurate user prompts about keycodes into an issue for a webapp. ---- [0]: Okay, that's not quite true. I did have a problem with this once on a controller that mapped keys based on their physical location. The only time this has been a difficult problem for me to solve was when I was trying to figure out controller layouts and I realized that the letter painted on the controller button wouldn't consistently match up with the keycode across controllers.

zamadatix 5y ago

> - QWERTY tends to be a pretty safe default for most US users... Other layouts tend to be associated with other languages The point of this is to fix that assumption for the cases it is wrong as well as simplify that process. Rather than have the app assume things about language, country defaults, and non-customization to try to select a hardcoded keymap this API just lets the app reference the actual keymap directly without requiring the user to do anything. Either way though both methods are using a keymap even if you're trying to hide that's what you're really doing. This new way is however easier for app developers, requires less action from users, and more accurate than trying to heuristic your way to the keymap. Similarly: > Users would rather be able to select their controls from a list (ie, have some keybinding "templates" or common schemes that players can toggle on) and then customize them, rather than have to build their control-scheme from scratch. It's nice if this list can show the letter of the key, particularly once the user has left the config menu where you can reasonably show a full picture of the input device i.e. in use e.g. https://i.imgur.com/ZwVjubs.jpg https://i.imgur.com/ZwVjubs.jpg I still argue the entire set of rebinding points are an orthogonal issue. While rebinding is a useful feature it is neither gated by nor gates exposing the current keymap and fixing either individually will not provide the full advantages of having each. > I think my perspective is that I already do have this, it's my keyboard layout. As someone who actually uses a non-language default keymap I'll say it becomes immediately apparent I don't want my keyboard layout to have anything to do with the keymap (besides notification of what the key to press is) in a lot of cases. Of course there are many such as ctrl+c or cmd+q I want to stay the same letter regardless of location as well but exposing the keymap doesn't inherently force anyone to override that even if it allows it. It does however let the apps function fully for the first case.

danShumway 5y ago
> Rather than have the app assume things about language, country defaults, and non-customization to try to select a hardcoded keymap this API just lets the app reference the actual keymap directly without requiring the user to do anything. I think there's a really tangible difference between saying that AZERTY layouts prefer to use ZQSD for layout and saying that everyone is going to use the four keys on the left-hand side of the screen. It's sort of the same situation as controllers -- using physical maps to standardize controllers is just flat-out wrong, because different controllers have different conventions about what buttons in the same physical locations should commonly do. It's fine to say that there are common layouts that have defaults, but I think it's a much larger step to say that shortcuts/keybindings should be defined by physical location rather than convention. I don't completely see how that makes thing simpler for me as a developer (I don't want to intuit keyboard layouts by iterating over keys), and certainly I don't want it as a user. ---- > It's nice if this list can show the letter of the key, particularly once the user has left the config menu where you can reasonably show a full picture of the input device i.e. in use e.g. https://i.imgur.com/ZwVjubs.jpg https://i.imgur.com/ZwVjubs.jpg I have some other objections to your points below this (allowing applications to override user preferences is in fact a loss in user functionality, even if developers aren't forced to ignore those preferences), but I want to really focus in on this specific example, because you're not the first person I've seen bringing this up as a problem that needs to be fixed. And honestly, I really don't understand at all what people are talking about with this "fixing keymap messages" thing. I don't think I've ever had a problem with this[0]. Under the current scheme, before Chrome introduced this feature, it was impossible for a developer to mess this up. If you told the user to press "Z", and they pressed the key that they normally press to get "Z", no matter what their layout was or what their keyboard looked like your app would register a "Z" press. Whatever key you told them to press, if they pressed it you got that key. Perfect, impossible to break. But if you now are basing your prompts on a keymap that bypasses the user's keyboard layout and uses the physical position, and still labels those keys based on a QWERTY layout, then it is now possible to break the message and to tell the user to press the "Z" key, and then to have the "Z" key not work because what you're listening to is the physical location of the "Z" key on a QWERTY layout rather than the key that they use in their layout for typing a "Z". So I don't really understand what people are talking about with this objection; Chrome isn't fixing anything about user prompts because nothing needed to be fixed about matching user prompts to keybindings, it worked 100% of the time. The new feature actually breaks that and makes it possible to now implement user prompts that are inaccurate. I believe people who say they have struggled to implement this in the past, they wouldn't lie to me, but... for the life of me, I can't imagine how they're implementing keybindings then; I'm not sure what I could do architecturally to make inaccurate user prompts about keycodes into an issue for a webapp. ---- [0]: Okay, that's not quite true. I did have a problem with this once on a controller that mapped keys based on their physical location. The only time this has been a difficult problem for me to solve was when I was trying to figure out controller layouts and I realized that the letter painted on the controller button wouldn't consistently match up with the keycode across controllers.