by Michael S. Kaplan, published on 2005/03/24 22:45 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/03/24/402055.aspx
This post is another of the series about international and non-international issues surrounding keyboards, MSKLC, and accessibility. Through them I will deal with issues important to developers in their application, issues important to keyboard authors in their works, and issues important in the use of MSKLC (and MSKLC's own accessibility triumphs and failures).
The first article deals with shortcuts. The second article deals with accelerators. The third article deals with the accessibility issue in MSKLC's own user interface.
This article deals with some of the issues one should consider when one is designing a keyboard.
First and foremost, try to use a layout that is printed on an actual keyboard's keys. As I have said many times before, many people have a conceptual block that keeps them from understanding the notion that the layout of the letters that the keyboard types must somehow always be what is printed on the keys. It is not true, and they are wrong. But you won't impress people by telling them they are stupid. So really think about this when they can.
Of course, as a strategy it has limited use since it is unlikely that you would be trying to create a keyboard if you needed to match what is printed on the keys -- that is probably already built in. So lets talk about the things to consider when you can't match what is printed on the keys.
You really should go with some kind of existing standard layout that people use. This is not a place for innovation! People have to type with this sucker, and it is much easier to do so if they do not have to learn the layout.
But maybe there are no keyboards, or no typewriters, or none of either that people like. So what do you do then?
You need to make sure that a lot of the basic punctuation will be included, especially !#$%^&*()[]{}\|;:'",.<>/?@ because if you don't then developers such as I am (or maybe as I used to be?) will be unlikely to use the keyboard. We need those little things to write code with. I have often been asked to look at people's keyboards and when I notice that people skip these or make some of them dead keys (like they do with the US International keyboard) that the layout kind of sucks for a particularly surly and opinionated group of users who are particularly anti-social anyway.
You have to know all of the letters in the language that the keyboard is for. This sounds obvious but even professionals can miss something on this one. So really try to cover the language well.
Now although this last point is important, don't over-reach. Keyboards that try to do much usually suffer from the handicap of not doing anything particularly well. Thus if trying to create a keyboard for English you do not need to add the letter é just so people can type the word resumé. People who do this sort of thing often find themselves needing to keep their resumés fresh. Keep the keyboards focused on what people need for their normal usage and keep "Ԁ" (U+0500, the CYRILLIC CAPITAL LETTER KOMI DE) off your everyday Russian keyboard layout.
(I have a sort of waking nightmare about this last point that the already barely usable Canadian National Standard keyboard, already so likely to trip on its overburdened self as it is deigned today, will need to support languages that use the Canadian Aboriginal Syllables and will thus need to add several new shift states and be completely unusable to all.)
For the layout itself, you will want to put the characters that are used most often closer to the middle and characters used less often toward the edges or in different shift states. It must be easier to type things as it is to say them, because people have to search for words enough and they do not want to have to search for letters once they have found the words that they want to express. Note that different languages will often have different usage frequencies and thus may be better served by layouts that take this into account.
This last point helps point to why the Canadian National Standard keyboard is overburdened -- it is attempting to support many languages and since it is impossible to do all of them well simultaneously, each one is shortchanged by the compromises....
Try not to use too many features -- you may like dead keys or SGCAPS or whatever but if you mix and match too many features then nobody will consider the keyboard to be usable, as no one can remember all the features since no one can remember them all.
Consistency and sensible usage of features is also good -- don't have dead keys type keys unrelated to the base character or the dead key that was typed. It is just really hard to stay intuitive when you try that hard to design against such a thing.
Knowing your target audience is also a good idea, since picking features that will not be intuitive to potential users will keep them from fulfilling such a potential....
Keep it as simple as you can manage to. MSKLC can give you many shift states but do not feel like you have to use every key on all of them. If people cannot remember where all the letters are on your keyboard, they will ultimately find to be forgettable. If you know what I mean.
And stay away from shortcuts used by Word. I do not know when they will fix the problem where they stomp on key combinations the keyboard uses. In the words of Captain Don Cragen on Law & Order, "I'd love to know when my mother in law is moving out, but I'm learning to lover her pot roast." If your keyboard does not work well with the shortcuts in Word then it is better to avoid them than to build keyboards you cannot use in Word.
Make the keyboard layout design process an iterative one, where you build draft versions for users and get feedback from them based on actual usage in their natural computing tasks. This is how you can find out when there are issues!
Ok, that' enough for now. But I will revisit this topic another day....
This post brought to you by "Ԁ" (U+0500, a.k.a. CYRILLIC CAPITAL LETTER KOMI DE)
# Mike Dimmick on 25 Mar 2005 6:58 AM:
# Mike on 25 Mar 2005 1:08 PM:
# Brian on 25 Mar 2005 2:52 PM:
# Michael Kaplan on 25 Mar 2005 9:08 PM:
# Pavel Šrubař on 26 Mar 2005 2:40 AM:
# ChipH on 26 Mar 2005 3:21 PM:
# Ian Argent on 26 Mar 2005 11:40 PM:
# Michael Kaplan on 27 Mar 2005 3:46 AM: