by Michael S. Kaplan, published on 2004/12/23 02:09 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2004/12/23/331112.aspx
This post will be one of a series that I will be putting up over the next few weeks 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).
As it is the first post, there will likely be questions in people's minds that relate to items that will show up in future posts; I promise I will be flattered that I was able to inspire such issues before covering them!
This is a huge area. Talking about keyboards, MSKLC, accessibility, surrounding international issues.... the list of topics not being covered may have been shorter....
Anyway, lets start with shortcuts.
These little beasties are a crucial way for some to get at core functionality. While some people prefer to go to use Edit|Cut, Edit|Copy, and Edit|Paste from the menus, many others like by <CONTROL + X>, <CONTROL + C>, and <CONTROL + V> for the functionality all across Windows. This is so true that the developers who wants to change the functionality from Cut/Copy/Paste to eXchange/Contribute/Verify will find that they face an uphill battle, fighting spinal reflexes and muscle memory.
There are other common shortcuts such as <CONTROL + A> for "Select all", <CONTROL + Z > for "Undo" and <CONTROL + Y> for "Redo", or the other magical editing shortcuts like <CONTROL + I> for italics, <CONTROL + B> for bold, and <CONTROL + U> for underline. Users are dismayed when they do not work if it seems like they ought to (like in a text editor -- I tend to define an "immature edfitor" as one that does not have these definitions!), and one of the best ways to upset users is to have that functionality and put it on some other shortcut. Or even worse to have no shortcut at all!
(There are other shortcuts that you can find out about by looking for the article entitled "Windows keyboard shortcuts overview" in Windows Help, but I am not referring to most of those, I am referring to application shortcuts that a developer might put in their application). But I highly recommend that other article since it has a lof useful shortcuts in it and is very useful to users.)
There is an even cooler page from the Accessibility folks entitled Keyboard Assistance that covers many of the applications that Microsoft ships beyond Windows. In fact there is only one part of that page which is not so great, which I will point out in a moment. I am not making up the importance of shortcuts and accessibility. Ignoring the fact that they host this site, they host articles like the one from Sara Ford1 enitled Testing for Accessibility which mentions shortcuts quite prominently in the accessibility testing that an application should do here. Incidentally, Sara's article rightfully does not try to separate shortcuts (the topic of this post) from accelerators (a topic coming soon). Why do I say rightfully? Because users do not usually distinguish and thus it is not entirely sensible for documentation to do so. Hell, I wouldn't separate them if I did not have to in order to describe the technical issues behind them that are the root of so many problems....
Anyway, these shortcuts are boon to people who have difficulty using the mouse and they open up worlds for people who want to get at that functionality. I love them even when I have no problems with the mouse because I do not have to break up keyboard usage (and I sometimes do have problems with the mouse, though for me the keyboard kind of sucks then too - but thats another story). This makes them a wonderful usabulity adjunct to people who have problems with using other means of common actions as long as they know about them, which is the reason that the commonly known ones are more likely to be used. I also must come back to Sara's articl, which has the coolest quote about accessibility in the world:
One final note about keyboard accessibility is that the more ways the user can perform a given task, the more accessible the functionality is.
This quote can even be extended beyond keybord accessibility, so I will be coming back to it in future posts since it was a guiding principle in the UI design of MSKLC.The more ways there are to perform a task, the more accessible the functionality is.
But as I mentioned, there is a spot where things fall down. Here it is....
Of course, they suck a little bit for languages that do not use the Latin script, where keys for X, C, V, A, Z, Y, I, B, U, and others are not present. I say "a little bit" since folks who buy a keyboard still have asccess to those shortcuts but they are under other keys. And who would instinctively know that <CONTROL + ฟ> on a keyboard with the Thai Kedamanee text layout printed on it would mean "Select All", that <CONTROL + न> on a keyboard with the Hindi Traditional layout printed on it would mean "Paste", or that <CONTROL + ਬ> on a keyboard with the Punabi layout printed on it would mean "Undo"? Some might actually make sense, but the odds of most of them meaning anything at all are unlikely.
One the other hand, things can also suck if you switch to another Latin script layout that does not match the letters on the keys on your actual keyboard. You may well be dismayed to see what looks on the hardware like <CONTROL + A> actually quit from your application rather than selecting all of the text when you switch to the French layout (since VK_A and VK_Q are switched). It may annoy you tremendously that the undo and redo functionality in what looks on the hardware like <CONTROL + Z> and <CONTROL + Y> seems to be swapped just because you switch to the German layout (where VK_Y and VK_Z are switched).
Speaking as a non-speaker of both the Latin and non-Latin category of languages, I am hard pressed to give an opinion on which is worse other than to say that I would think it was worse if it were my language. Dammit.
MSKLC actually comes in handy here -- you can load an existing keyboard layout and hover over the different keys to find out what is the key over each of these different letters. (Of course at that point we run into MSKLC usability issues, but thats a different issue, for another post!)
But why does that happen, exactly?
These items are not subject to localization since they are virtual key (VK_*) based and they can be subject to key repositioning when a keyboard layout repositions keys (for example the French layout switches the positions of "VK_A" and "VK_Q" which means that if I switch to the French keyboard on my US keyboard hardware I have to know that the key that has "A" printed on it is really going to mean QUIT if I hit it with the control key). Thankfully, outside of the Latin script languages there is very little moving around of the VK_* values.
This is a place where Chinese, Japanese, and Korean language keyboards do just as well (which is to say poorly). They keep the English positioning on the VK values even when a non-English keyboard layout is used (like in Japanese and Korean), which puts them with the rest of the non-Latin script languages. They regularly include the shortcut key in their user interface, on menu items and such, which is fairly cool. Of course this does not help if you do not know where the keys are, since they may not be printed accurately to the physical keyboard, but this makes them no worse off than every other language....
MSKLC does not offer direct customization here for where the virtual keys go; you can only indirectly change them by changing what scan codes go with what keys. This limitation has an interesting history and reason which borders on and approaches yet does not completely reach a justification -- see a future post for mone info!)
Note that beyond VK-repositioning there is no other consequence of letter assignment since localization does not affect the letter to be used (other than the fact that people may not be able to find them) and there is no dependence on anything outside of ASCII/VK stuff. Luckily, most other layouts do not move VKs around but a lot of Europe and elsewhere do so there is no 100% clean solution here.
So the place where shortcuts fall down is when the keyboard layout is switched so that it is different than the keys on the keyboard. Because then the discoverability of the shortcuts is significantly lower.
I just feel like every keyboard in another language should come with a huge mapping of the shortcuts, which is to say the VK_* assignments, to the key on the keyboard that represents it. Wouldn't that be a cool feature to have available when buy a keyboard? Or even better, any time you select a new keyboard layout, since where the biggest accessibility problem lies. This may not be practical but it seems like it would be handy! Well, that or the hypothetical keyboard whose key tops change letters when you change the layout2.
Addendum 23 Dec 2004 11:10am: The Japanese subsidiary has provided a good translation for some of these shortcuts here.
For developers, it is important to understand one more issue (assuming that your heads have not yet exploded). Thau is the fact that shortcuts are processed at the point of the WM_KEYDOWN message. This is very different from accelerators (which I will talk about another day) and is the main reason that there is no localization of the shortcuts -- they are processed before the virtual key is ever translated into a character. So while it may be useful to give documentation about how <CONTROL + ф> will make the text bold with the Bulgarian keyboard layout, it really is <CONTROL + B> that is doing the work. Windows never gets to the point where VK_B gets converted to U+0444 (CYRILLIC SMALL LETTER EF).
So, how to summarize this mess? I just looked over this post again after I was done writing it and realized it was a bit like the movie The Survivors3. There is no way to summarize it.
Except maybe to say that keyboard shortcuts are cool. Although they kinda suck sometimes, internationally....
1 - Sara's blog is an awesome resource that is on the short list of blogs I read, and not only because I screwed up accessibility to much on the mosdt visible piece of UI I have ever created. Its incredibly insightful, and she and I are fellow travelers in that we are both passionate about areas of which it is often tough to convince people of the importance.
2 - Although I am not aware of any commercially available keyboards that do this, it is a deisgn architecture that is wonderfully implemented on a project that Wei Wu, myself, and several TabletPC developers put to good use for the first update to the TabletPC soft keyboard, which has the job of emulating keyboard hardware. Changing the layout changes what shows up in soft keyboard, which is such a huge leap forward in the usability of everything except for shortcuts that it amazes me. It is of course not helpful for shortcuts since the universal documentation still talks about <CONTROL + X> for cut, etc. and the soft keyboard cannot change any of that.
3 - The Survivors (starring Robin Williams, Walter Matthau, and Jerry Reed). A fun movie. I remember an interview withJerry Reed where he was asked to summarize the movie and he said it was impossible to summarize -- the point of the movie kept changing every ten minutes.
This post brought to you by "ｳ" (U+ff73, a.k.a. HALFWIDTH KATAKANA LETTER U).
# Nektar on 23 Dec 2004 2:54 AM:
# Norman Diamond on 23 Dec 2004 5:03 PM:
# Michael Kaplan on 23 Dec 2004 7:47 PM:
# Michael Kaplan on 23 Dec 2004 8:27 PM:
# Mike Dimmick on 24 Dec 2004 6:42 AM:
# Serge Baltic on 4 Jan 2005 10:58 AM:
# Michael Kaplan on 4 Jan 2005 11:01 AM:
2012/10/25 The promise and limitations of Dvorak...
2008/06/19 Accelerator vs. Shortcut, revisited
2005/02/09 New info about old usability tests
go to newer or older post, or back to index or month or day