On building a list of keyboards

Lots of the changes in Regional and Language Options in Vista are specifically there to address known usability problems. Looking at the tab that handles adding new keyboards, for example, looking at XP:

versus Vista:

In both cases, the button on the top is used to add or remove keyboards. Which do you think is the most intuitive, between the name of the tab and the text? For that mater, how much easier is it to update keyboards in the logon list if you don't read this blog and see posts like this one? And which one is easier to understand how to install additional UI languages? :-)

And I have actually received thank you notes via email for the removal of those two checkboxes for complex script and East Asian support (although we are not the ones who did the actual work, both Cathy and I championed this change strongly since it came up sdso often in customer feedback).

Anyway, back to that button -- let's press it and see what the view looks like, in XP:

versus Vista:

Mostly the same, though even here in Text Services Framework (a.k.a. Cicero) team did some minor changes to help with usability.

The major changes come when you hit the "Add..." button, though. The XP dialog had a whole bunch of problems:

Selecting the keyboard checkbox would get you to a list of keyboards, sorted alphabetically, sometimes starting at a keyboard that would be a reasonabkly intuitive next choice to add, but often not. Like if you choose Chinese (Taiwan) from that first list:

If you drop down the keyboard list, you'll see that this IME name has, alphabetically speaking, put you nowhere near the other IMEs:

With hundreds of keyboards and IMEs on the list, this is obviously pretty unwieldy. And this has been a huge pain point with customers. So let's see what they did for Vista:

Wow, a very filtered list, but with a clear option to show more. Cool!

Now it is not always obvious how the list is built, so I will explain what is going on. Let's look at Chinese (Taiwan) again:

Wow, definite benefits here -- and no weird scroilling issues to get to the other IMEs based on the keyboard names!

The actual list is basically constructed from three sources:

1. Any input methods that are based on a LANGID value that matches the locale's LANGID;
2. Any input methods that have specifically been associated with the locale;
3. Any items from the 'global list' the potentially applies to all locales;
4. The 'Show More...' item that gets you the full list.

Now #4 is kind of obvious and I will talk about #3 another day soon. And #1 is also mildly obvious, I think, and allows Vista to be sure and add keyboards (even legacy ones) to this list without requiring an additional association with a locale. So let's focus on #2....

If you open up intl.inf in your \WINDOWS\INF directory in XP, you will see a huge list like the following (sampled at random):

;
; List of locales.
; <LCID> = <Description>,<OEMCP>,<Language Group>,<langID:HKL pair>,<langID:HKL pair>,.....
;
[Locales]
00000404 = %Chinese_Taiwan%             ,950     ,9,,0404:00000404,0404:e0080404,0404:E0010404
00000409 = %English_United_States%      ,437     ,1,,0409:00000409
00000437 = %Georgian%                   ,437     ,16,5,0437:00000437,0409:00000409,0419:00000419

And those numbers at the end are a list of input methods. This is the source of #2.

Now ths list is mostly useless in XP, as #2 is not used for the list in Cicero, and only the first item on the list is added when you switch to any of the non-CJK locales (switching to Georgian, for example, will only add the Georgian keyboard, and not the US or Russian keyboards that are also on that list).

This is mainly as bug, and mainly our fault -- we were parsing the list and only giving the first one as the one to add; had we passed all of them, then they would all have been added.

Of course, in Vista the whole intl.inf file goes away. Now what do we do?

Well, if you call GetLocaleInfo with the new LCTYPE in Vista LOCALE_SKEYBOARDSTOINSTALL, documented as follows:

LOCALE_SKEYBOARDSTOINSTALL

Windows Vista and later: A semicolon-delimited list of keyboards to potentially install for the locale and to be used internally by Windows. There is no limit on the number of characters allowed for this string. To retrieve the name of the active input locale identifier (formerly called the keyboard layout), your application can call the GetKeyboardLayoutName function.

Trivia -- I originally checked this in myself with a small typo, and the constant name was briefly LOCALE_SKEYBOARDSTOINSTALLL (note the extra trailing 'L' there!). It was caught pretty quickly though, thankfully!

So now in Vista, all of the keyboards and IMEs on this per-locale list will be added to the list of keyboards in the UI above, and all of them will be added when you change your locale.

In fact the only downside of the 'fix' to our aggressive parsing that was ignoring most of the list is that Mike Williams will be seeing the US keyboard in a whole bunch more cases since the subsidiary PMs wanted the US keyboard on their lists in so many cases....

Sorry Mike, it wasn't aimed at you and it is wasn't our idea either (the SPMs are the ones who wanted it on their lists!).

In any case, all of the UI in Vista that I covered above is lots more intuitive, and directly addresses many longstanding complaints from customers about usability.

And I'll talk more about LOCALE_SKEYBOARDSTOINSTALLL another day, as well as the keyboard list, and what happens with custom locales....

This post brought to you by ლ (U+10da, a.k.a. GEORGIAN LETTER LAS)