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


This post is another of the series 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).

The first article deals with shortcuts. The second article deals with accelerators.

This article is going to take the second most visible piece of UI I have created since I came to Microsoft 1 and tear it apart, from an accessibility standpoint.

 

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 2.

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:

Just a quick OT:
IIRC, Newspeak adjectives have three degrees of the positive (e.g. "good", "plusgood", "doubleplusgood") but only two degrees of the negative (e.g. "ungood", "doubleungood"). Of course, the only reason I remember this is because I used to say "doubleplusungood" myself until I reread the appendix. :)

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

I can be much more negative than Orwell. ;-)

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

2012/09/25 Kevin knows where it will all end up- where 'Kevin' is any random entity that doesn’t know nothin’ about nothin’

2010/07/07 [Pretty much] All the things you can't do with SGCAPS, and why

2008/11/04 Strange control over CTRL and control characters

2008/05/17 Do your utmost to be conventional (and then pimp, q.d. or p.r.n.)

2007/08/09 Some of the less intuitive parts of MSKLC's user interface

2007/01/22 Confusion in the user interface can happen anywhere

2005/03/24 Accessibility, Internationalization, and Keyboards (#4 Creating good keyboards, part A)

2005/01/03 What's a spec? What's a design doc?

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