by Michael S. Kaplan, published on 2007/11/15 07:46 -08:00, original URI: http://blogs.msdn.com/michkap/archive/2007/11/15/6252257.aspx
Another exciting series, brought to you by SiaO!
If you are a developer and you deal with the keyboard at all, there really are good rules to live by.
I am going to call them laws, but as something of a Jeffersonianesque rational anarchist, my feelings on LAW are not as clearcut as yours might be. So feel free to mentally consider them my keyboard guidelines or keyboard best practices if the series title seems a tad too pretentious for your tastes. :-)
The first law is simple enough to state but not always obvious to developers, unless they really think about it carefully.
VK_A is not always "A"
Just yesterday two very similar questions came in from two different people that somewhat relate to this very law -- this one:
I have a console app that prompts the user for a confirmation when performing certain commands. The prompt is of the form “Are you really sure that you want to do this destructive command? (Y/N)”. The code reads from stdin to get the key pressed by the user. It currently compares the char to ‘Y’ or ‘y’ to indicate confirmation. Since this doesn’t localize I am wondering if there is a better way to solve this issue than putting IDS_CONFIRMED “Y” into the rc file and testing the uppercased key pressed with this string.
and this other one:
Is there guideline for ‘yes’/’no’ user response for console applications in terms of globalization? In other words, is it ok for console apps to blindly take ‘y’ as ‘Yes’, or console apps should be implemented to take localized ‘y’ such as ‘o’ for fr-fr? I found one of console apps on LHS that takes only ‘y’ as Yes since ‘y’ (or ‘Y’) user response is hardcoded. Any suggestions/guidelines are appreciated.
Now between both messages, you can see two very similar and interesting trends here:
There is another related law that I will cover tomorrow, by the way!
To make this a localization problem is to assume that the input language always covers the user interface language.
Now we'll ignore the Vista/Speech example of this assumption (ref:here and here) and instead appeal to logic.
There are 158 keyboard layout DLLs that ship in Vista (we'll ignore IMEs for now), covering the input of most of the 208 locales.
Yet there are only 35 full language SKUs and ~65 LIPs (Language Interface Packs).
And not every keyboard has script coverage in a UI language, let alone full language coverage.
Which means that even if you ignore the ability to switch to some random different keyboard, the fact is that some users will have as single keyboard chosen that no UI language will cover.
So this problem that both of the questions were asking about CANNOT be a localization or localizability problem, unless we choose to solve the problem poorly, or incompletely.
Alright, now I have said how NOT to solve the problem, which begs the question of how to contemplate solving it.
Anyone out there have an idea in mind about how to solve this one? :-)
This post brought to you by y (U+0079, a.k.a. LATIN SMALL LETTER Y)
# Ben Cooke on Thursday, November 15, 2007 1:25 PM:
I'm not sure I'm completely following the chain of thought in this entry. Let's see where I lost it...
* The people asking the questions want to get a positive or negative response from the user in a console app.
* They want to localize it so that the responses are made in the UI language.
* You say that this is a problem because the input language might not match the UI language.
So what issues result from this? I guess the localized "y" or "n" might result in asking the user to type something that isn't in his keyboard layout, but presumably sticking to latin letters would mean that the necessary characters are available *somewhere*.
I'm also not really sure how this relates to the virtual keycodes. I'm a little rusty, but I believe they basically relate to the physical key on the keyboard, not to the character generated when pressing that key. In that case, presumably what VK_Y generates doesn't really matter to the app because it's just going to see the bunch of unicode (or "OEM charset") characters that result. They say "Do you want to continue? (æ/¶)" (to pick two characters at random) and then I'm left to press whatever key combo produces those characters in my current input locale. (Which is AltGr+A and AltGr+R respectively.)
The best I can come up with as a possible solution, given my incomplete understanding of what exactly the problem is, is to turn the console app into a GUI app and have the user click on a button marked "Kuké"! :)
# Michael S. Kaplan on Thursday, November 15, 2007 2:03 PM:
Um, if you tell a customer type "Y"or "N" and the keyboard has no such thing on their keyboard, then there is nothing for them to type.
Since I can change my keyboard layout, the letter might be unavailable to me.
So the advice the user is given is to type a letter that they cannot type.
Some would say this is not as good plan. others, realizing it is Microsoft, would say that this happens all the time so it is not a big deal if the instructions cannot be followed by users.
# Michael S. Kaplan on Thursday, November 15, 2007 2:05 PM:
Further -- the developer always assumes --
1) Latin is available somewhere, and
2) The VK_* values have meaning that they can use
Both points are not true.
# John Cowan on Thursday, November 15, 2007 2:50 PM:
I don't understand this (but I'm far from being a Windows maven). Console applications are written in one or more languages and are operating in that language. This has nothing to do with Windows UI languages particularly: a console app could be written to talk to the user in Ainu, even though there's no Ainu-localized version of Windows. Ainu is normally written in extended katakana, so then it's a matter of making the program accept suitable characters (*not* keystrokes) representing the Ainu words for "yes" and "no".
A more serious i18n problem is that lots of languages don't have general purpose "yes" and "no" words: typically, as in the case of Irish, they repeat the verb with or without a negation marker. That means that general-purpose AskYesOrNo routines are bad i18n; the translator needs to be able to specify separate "Yes" and "No" strings for each use in the code, not merely at a single place.
# Maurits on Thursday, November 15, 2007 5:11 PM:
Do any languages' translations of "yes" and "no" start with the same character?
# Tore on Thursday, November 15, 2007 5:58 PM:
Well, some keys are probably constant:
"Press enter to confirm; any other key to abort."
# Michael S. Kaplan on Thursday, November 15, 2007 6:19 PM:
Hey John,
In the world of Windows, the command line utilities often have the same language as Windows -- which would mean that if localized they would tend to follow UI language of Windows....
But the main point is that treating the prompts as a loc. issue leads to serious issues -- you are in fact indirectly pointing out the road to the solution here. :-)
# C++ guy on Thursday, November 15, 2007 6:59 PM:
Number the options like:
1. Yes
2. No
Numbers are available on every keyboard layout, no?
# Michael S. Kaplan on Thursday, November 15, 2007 8:58 PM:
Hey c++ guy -- yes, that is in fact the solution! :-)
The only times that Arabic-Indic digits are not available are some cases where nastive digits are, but then the understanding is still there. It is the way around the inherent limitations in the conventional locakizability solutions....
# Cheong on Thursday, November 15, 2007 10:01 PM:
How about the arrows? Are they supposed to change on keyboard layout?
Perheps "<-" for Yes and "->" for No, with the "Yes(<-)" button on the left and "No(->)" button on the right will do?
# Michael S. Kaplan on Friday, November 16, 2007 3:06 AM:
Hi Cheong,
Arrows are an interesting idea, though there are some times that they are not practical given their meta behavior and status -- people expect the cursor to move and such....
But in some situations they could also work here. :-)
# Cheong on Friday, November 16, 2007 5:45 AM:
Recently I've read some interesting discussion (in Chinese) on usability. Someone argue that only using the arrows is better, because even those low-grade(in the sense of both "marks" and "education level") people can handle the game console controllers without problem. So if your action involves non-input related operation and you want to support keyboard-only control, you'd better limit yourself to the choice of arrows plus select/cancel button.
That leads to this thought. :)
# gjcoram on Monday, November 19, 2007 7:51 AM:
This law (part 1) seems to be focused on console apps; does the same sort of problem arise in keyboard shortcuts? (eg, I've got a menu that says Ctrl-J will do something, and my .rc file has an accelerator defined for VK_J with VIRTKEY, CONTROL, NOINVERT -- though, I just checked and the .rc file has "J" not VK_J).
And: how does it happen that VK_A is not "A"? Is it in the keyboard itself, or in the keyboard driver? I've got a US keyboard, so suppose I ask for the German layout (where Y and Z are swapped) and press the Y key. Does my app get VK_Y which is really a Z, or does it get VK_Z?
# Michael S. Kaplan on Monday, November 19, 2007 9:43 AM:
Well, you have to keep in mind that there are plenty of other language keyboards where there is no "A" on them -- but there is still a VK_A, though the user probably has no idea that uch a thing is there....
In the German case, the VK_A moves around....
referenced by
2012/05/02 Who owns keyboard testing?
2012/04/26 Michael's Keyboard Laws for Developers, Part 5
2007/11/21 Michael's Keyboard Laws for Developers, Part 4