Dead keys are not intuitive

by Michael S. Kaplan, published on 2004/12/17 02:27 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2004/12/17/323257.aspx


The dead key mechanism in keyboard layouts is rooted in European typewriters. One would type the accent character and the typewriter's head would not advance, then one would type the base character and it would. The term dead key refers to the fact that the position is not advanced after typing the diacritic mark.

So since people are used to this from typewriters, adding a similar mechanism to Windows should be easy, right?

Well, no.

After all, if you are used to Unicode then you know that one first types the base character and then the diacritic. If you are used to typewriters, you expect to see the diacritic. And in both cases you expect that what is finally produced is always made up of the constituent parts that were typed.

In keyboard layouts on Windows, none of these assumptions are true. Nothing is visible after typing the dead key. The layout defines what is to appear when the combination of the dead key and the base character is typed and there is no rule guiding what must appear.

This is a mechanism that is very easy and intuitive if you know about it, otherwise it is as confusing as hell.

Also, you can only have each pairing of keystrokes produce a single UTF-16 code point. I would not have believed it, but this limitation is one of the most common questions I am asked about (not #1 but definitly in the top five -- most often to do with user-created Polytonic Greek keyboards since there is no precomposed form in Unicode). This is not an MSKLC limitation, it is a core limitation in the keyboard layout architecture, as one can find in the kbd.h header file from the Windows DDK (available to all for a mere $199 plus s/h):

/***************************************************************************\
*
* Dead Key (diaresis) tables
*
* LATER #####: supplant by an NLS API that composes Diacritic+Base -> WCHAR
*
\***************************************************************************/
typedef struct {
    DWORD  dwBoth;  // diacritic & char
    WCHAR  wchComposed;
    USHORT uFlags;
} DEADKEY, *KBD_LONG_POINTER PDEADKEY;

There is only room for a single WCHAR for the precomposed character. Sorry! 

There is also a comment above the struct by someone who no longer works on keyboards (their name removed from above for obvious reasons!), and no NLS API was ever added for the sake of keyboards that would combine the two characters to create the dead key. Technically one already exists -- the FoldString API with the MAP_PRECOMPOSED flag. However, such an API could never be used at this point, since there has been many years of potential keyboard layouts shipped that allow one to attach to two unrelated characters a third unrelated character.

(I'll see about talking to someone about removing the comment!)

Now one thing that is possible in the Windows architecture is chaining dead keys together, so that a dead key plus a base character will then wait treat the combination as another dead key waiting for yet a third base character. One could then chain that as well, and so on -- adding more and more keystrokes to produce in the end a single code point. This feature is not currently supported by MSKLC since the demand for combinations of three or more keystrokes always involve multiple characters being produced -- one is simply not enough here for anyone who has ever asked....

On the whole, my earlier words about dead keys sum up the situation best:

This is a mechanism that is very easy and intuitive if you know about it, otherwise it is as confusing as hell.

Luckily there are many ways to produce input with keyboards that is much more intuitive to potential users. Lets leave dead keys for the people who are used to them.

 


# Anonymous on 17 Dec 2004 6:56 AM:

I know that the feature of using random keys exists, but it seems like a pretty stupid feature.

Couldn't you make your keyboard creator use that API call or maybe normalization form C to validate smart dead key usage?

# Jake on 17 Dec 2004 6:58 AM:

I saw you and Cathy Wissink talking about keyboards at a conference last year. I remember a great line you guys had "Dead keys -- neither dead nor keys". Great stuff, keep the posts coming!

# Michael Kaplan on 17 Dec 2004 8:04 AM:

Validating dead keys to make sure that base character and diacritic equal the combining character -- that is a very interesting idea. Definitely something to look into for v.Next of MSKLC!

# Michael Kaplan on 17 Dec 2004 8:05 AM:

Hi Jake,

Thanks for the kind words, and glad you liked the presentation!

# Ben Hutchings on 17 Dec 2004 8:28 AM:

"Also, you can only have each pairing of keystrokes produce a single UTF-16 code point."

Surely the limitation is to one code unit (WCHAR), not one code point, which means anything outside the BMP is unavailable.

# Michael Kaplan on 17 Dec 2004 8:42 AM:

Yes, that is the limitation -- one WCHAR.

I figured that most people do not know what a code unit is but lots of people can guess at the meaning of a "UTF-16 code point" (since anything outside the BMP would require a pair of UTF-16 code points!).

# Chris Nahr on 18 Dec 2004 1:13 AM:

Maybe they're difficult to implement, but how are dead keys not intuitive to the user? Are you saying that pressing a clearly labeled accent key and then "a" is less intuitive than hunting for some crazy Ctrl/Shift combo, or pasting from the Character Map? Sorry, I'm not following you there...

# Michael Kaplan on 18 Dec 2004 3:52 AM:

As I said in the fourth paragraph:

After all, if you are used to Unicode then you know that one first types the base character and then the diacritic. If you are used to typewriters, you expect to see the diacritic. And in both cases you expect that what is finally produced is always made up of the constituent parts that were typed.

I have seen how most users try this -- they either hit the letter before the diacritic (which does not work right) or they hit the diacritic twice since nothing appears (and then they get two dicritics). The current design is understandable if explained; it does not help a user who tries to use the pictures on the keyboard.

# Chris Nahr on 19 Dec 2004 12:58 AM:

That makes sense, I didn't think that people would try to type the letter first and then the accent. You're also right that the accent not showing up immediately might be confusing to some users.

Regardless, speaking as a German whose keyboard has accent keys to produce French accents, I do believe the dead key method is the optimal solution for this problem, even if it would be even nicer if the above issues were resolved.

Michael Everson on 19 Jun 2009 10:26 AM:

Dead keys were not confined to European typewriters.


Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

referenced by

2011/04/23 Solution: The Dead Keys Conundrum: An Encyclopedia Brown Mystery

2011/04/16 Chain Chain Chain, Chain of Dead Keys

2009/06/18 Those keys aren't going to be extended; they're dead!

2007/11/21 Michael's Keyboard Laws for Developers, Part 4

2007/02/11 MSKLC can't do everything, even in the 1.4 version

2006/12/24 Despite a report to the contrary, >1000 seems to work

2006/03/28 Only ONE WCHAR per dead key

2006/03/24 Getting all you can out of a keyboard layout, Part #3

2005/11/15 It is not easy to chain dead keys on Windows

2005/08/05 What MSKLC can't do

2005/02/24 The keyboard does not do what I tell it to!

2005/01/19 He's dead [keys], Jim.

go to newer or older post, or back to index or month or day