Accessibility, Internationalization, and Keyboards (#3: MSKLC's UI)

by Michael S. Kaplan, published on 2005/01/03 02:53 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/01/03/345719.aspx

Developing the Microsoft Keyboard Layout Creator was a unique experience.

Almost all of the good ideas and concepts came from Cathy Wissink and Simon Earnshaw. At the time they represented the bulk of the NLS Program Management team (now they each have 5-6 people under them in GIFT -- we have grown quite a bit since then!). The three of us would have weekly meetings and talk about what kinds of tools would meet some of the customer requests that had been coming in. It was a little unconventional as projects go, since I did not have a spec to work from. But at these weekly meetings I was able to show them what I had and they were able to provide corrective measures. We started calling the meeting the Dog and Pony Show, shortened to Dog & Pony and eventually to D&P and these were very creative meetings with lots of good ideas in them.

I mention the D&P because it helps point to the continuous "beta" and "usability" testing that was happening throughout the development cycle of MSKLC. Although it was pretty unconventional, it proved to be very effective when things line up as they did.

One of the most worrying concepts that came up in some of these meetings was accessibility, and not just in the conventional sense of making sure there are shortcuts and accelerators. The entire user interface has to be accessible in an intuitive way. Even though the operation of keyboard authoring was not necessarily an intuitive one.

Look at a simple operation of assigning letters to keys:

You could use the mouse to select buttons on the "faux keyboard" that is the MSKLC user unterface, which opens the editing dialog.

Or you could press the key once to select it and a second time to open up an editing dialog.

Or you could use drag 'n drop to put text onto a key from Word or IE.

Or you could right-click on a key and get an array of editing choices.

Or you can use arrow keys to move around the keys to select the one you want.

Or you could load an existing keyboard layout and modify that ².

The idea was that nobody would use all of these methods, but everyone would use the ones with which they were most comfortable. And very accessible.

Now with that said, there were things that did not quite as well, such as support for high contrast or large fonts. Though both problems are somewhat mitigated by the ability to change the colors and to resize the keyboard, respectively, there are tweaks to the DPI settings that can even mess up the layout of the resizing, which is pretty doubleplusungood.

All three of these functionalities (high contrast, large fonts, DPI changes) are considered important in many cases to accessibility in the conventional sense of the word. And the mitigation is not all that great even when it would work -- it would be better for MSKLC to simply handle these issues without requiring extra tweaks. Its just a feeling I have that if the UI is only usable to a customer after they change it then I have not really done the best I can for them....

There is also another kind of "accessibility". If you look at MSKLC it gives you 50 keys whose assignments you can alter and 10 more that you cannot. But these days even the smallest non-laptop keyboards have 101 keys, so what about the other 41 keys? If they cannot be accessed, isn't that an accessibility problem?

Well, yes, sorta. But most of those keys are things like the numeric keypad and the function keys and things that we really don't want people accessing, so it is not really something that anyone here loses too much sleep about. :-)

Now it is interesting to consider that the ability to create custom keyboards means that if there are specific problems or difficulties a user has such as a mising finger or fingers that a keyboard can be fashioned which will help them by assigning the most common letters to the keys that are most accessible to the individual user. I was indeed contacted by someone from the Accessibility team just before we shipped MSKLC who we talked with about potential usages of the tool.

This is not the only example of such a collabotation. We often end up either working together or doing each others' work -- for example, the Windows Accessibility folks are the ones who own and had developed the OSK (On-Screen Keyboard), which is often used by people trying to use other language keyboards when they do not know the layout. And Wei Wu and I worked with devs on the Tablet team to develop a good international solution for the TabletPC's soft keyboard.

1 - The most visible UI I have ever created would have to be some of the new wizards I added to the huge collection of existing wizards in Access 97 and Access 2000. But MSKLC definitely picks up the silver medal.

2 - Although it is last on the list here, it is probably the most commonly used feature, and it highlighted the pattern of those weekly meetings. I would show the current state of the UI, Simon or Cathy would bring up a feature they felt was crucial, I would push back and explain why it was not feasible, they would grudgingly accept this, but the issues they brought up would keep bothering me until I thought of a way to make it feasible. Then I would show it to them the next week. I am pretty sure that was how the meeting became known as D&P in the first place....

This post sponsored by "" (U+e000, a.k.a. the first PRIVATE USE codepoint).
It ought to be a square box most of the time!

# JD on 3 Jan 2005 6:10 AM:

# Michael Kaplan on 3 Jan 2005 7:08 AM:

referenced by

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