6

I am working on a plugin for an Integrated Development Environment which should be able to allow the user to set keyboard shortcuts in order to perform certain actions with ease. However I am having a bit of a problem with this and programming it in order to know what a valid keyboard shortcut looks like, especially as there are so many different keyboard layouts.

But a friend recently suggested to me to only allow standard modifiers and keys which are on the standard English keyboard. So basically only allowing a-z to be used in the keyboard shortcut, and not any other languages. As English is my primary language I do not know how users of other languages use keyboard shortcuts.
My friend assures me that even though his primary language is a different one to English, he switches to the English keyboard in order to perform keyboard shortcuts. But perhaps that is just him, or just his language.

So I want to know if it is acceptable for me to restrict keyboard shortcuts to those which only use keys which are in the English keyboard or if users of other languages would find this rather a nuisance.

There are a huge amount of different languages so to set which keys can and cannot be used if I am to allow all keyboard layouts is a vast amount and would be hard to easily implement.

So would this be a big nuisance to users of other languages or this a norm?

Note: This is not a default set of keyboard shortcuts, the plugin has its own menu and allows a user to customize it by adding their own actions to it. It also will allow them to set their own custom keyboard shortcuts to trigger the actions. These are the custom keyboard shortcuts that I am asking about as I need to create a validation process for them.

2
  • what language does your friend use may I ask? In my experience with Japanese and Chinese most of them still type their languages using an English keyboard. Commented Feb 22, 2017 at 10:24
  • @theotherone: He speaks a language which would be in the group you mentioned.
    – user91255
    Commented Feb 23, 2017 at 18:38

3 Answers 3

0

Update:

With the additional information you gave, I would say that you should not limit the choice of shortcuts. There is really no need to validate shortcuts beyond "is this shortcut already taken by another item?". If the user can press the shortcut and wants to use it, why prohibit it?

Just be sure to use a shortcut entry field that uses the same mechanism that the rest of the app uses though, don't give them checkboxes for the modifier keys and a text field to type a character in. With the checkboxes and text field, the user could type in Command-Shift-1 on a keyboard where 1 already requires holding shift, so when they press that shortcut, you would not recognize it because you receive it as Command-Shift-& instead.

So have the user press the shortcut, and intercept it, and write a description for the shortcut that expresses what it is (in this case Command-Shift-&) to configure what shortcut a menu item gets, and all bases should be covered.

The only reason special characters are rarely used is that, when you assign different keyboard shortcuts for each language, it costs money to hire QA people to test each language again. So why go to all that effort if you can use the same shortcuts for all languages?

Old answer:

Are you saying that you are creating a plugin for setting arbitrary (user-defined?) shortcuts on existing actions, or are you creating a plugin that adds its own menu items that need good shortcuts? Or are you creating a plugin that adds shortcuts defined by you to existing menu items in an IDE that otherwise wouldn't have one?

You should not limit what shortcuts a user may set. If the user finds it convenient to type Ctrl+Shift+Alt-` because that's the three keys in the lower left of their keyboard layout, then let them.

If, on the other hand, you're providing a default set of shortcuts, you should limit yourself to characters that everyone can type. That way, your plugin will just work for everyone, out of the box. This is a bit harder than it seems. While most Japanese keyboards have (to put it simplified) both Japanese and English characters on the key caps and can switch between them, not all ASCII characters can be typed with all modifier keys.

E.g. on a German keyboard, You press Shift+7 to get the slash key. So the common Command+/ key command becomes impossible to set up, because your app will see it as Command-Shift-7.

Similarly, on French keyboards, numbers are shifted (so Shift+& is how you get a '1'), so Ctrl+Shift+1 is impossible to type (or at least ambiguous with Ctrl+Shift+&).

That said, a quick google seems to indicate that the letters from A-Z, the left delete, space and return keys are possible to type on most non-English keyboards, (though I'm not 100% sure about A-Z on Russian keyboards, I got conflicting information). A few more keys are available if you can assume a full-size keyboard (not a laptop one), including numpad numbers, enter, forward delete, page up/down etc.

Also note that if the IDE has shortcuts of its own already, and you're adding, they may also be different between languages. E.g. on MacOS, window switching is done with whatever key is in the lower left of your keyboard. This may be ` on a US keyboard, but will be < on a German one. Similarly, WASD as a replacement for arrow keys in games is ZQSD on French keyboards, to maintain the inverted-T arrangement.

3
  • In order to clarify what I mean I have added a note to the end of my question.
    – user91255
    Commented Feb 22, 2017 at 16:33
  • In reply to your update: The reason to limit is because with the programming language I am using it seems as though I have to specify a regex for what should be accepted as a valid keyboard shortcut. So for instance I shouldn't accept just Ctrl+Shift on its own, nor Shift+F on its own. But because there are so many keys, I am not sure how to specify all of them. The problem really is is that I am only detecting the key press, and it detects all the stages of something like Ctrl+Alt+F meaning that it is hard to get the right and valid one from it. Perhaps I am mistaken in my thinking though?
    – user91255
    Commented Feb 23, 2017 at 18:37
  • The problem would really be with keys like Tab which aren't counted as modifiers, but shouldn't be used. And although I can blacklist the ones on the English keyboard layout, I don't know for other languages so my friend thought a whitelist would be better.
    – user91255
    Commented Feb 23, 2017 at 18:38
3

In general, not only is acceptable, but recommendable. Unless your application is going to be used in a country where diacritical and special characters are common, the use of this characters should be avoided.

Just imagine the level of friction for someone used to an English keyboard if she has to learn how to add the special characters AND the shortcut. Failure is guaranteed.

For more information on what would happen, see what a regular user would need to do to use a shortcut with special characters

Note: my native language is Spanish and we have a few different characters and accented letters when compared to English. I have never, EVER seen a shortcut using these characters, not even in Spanish versions of software.

In short: your friend is correct, just use common English characters

1
  • In order to clarify what I mean I have added a note to the end of my question.
    – user91255
    Commented Feb 22, 2017 at 16:32
0

I would ask yourself who your target audience is. If you are focussing mainly on a user group which uses English keyboards then why would it be an issue?

If instead the user group is going to be using a traditional Chinese keyboard then obviously you would tailor it more to that.

I would argue as well that because it is only a user shortcut, it's not hindering them at all, they just will be unable to perform actions as quickly.

Saying that, its not like you can't add these shortcuts for other keyboards in the future with more time or experience as required.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.