by Michael S. Kaplan, published on 2012/09/25 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/09/25/10352917.aspx
At 7:56pm last night, someone sent me an email.
Now getting email is hardly an unusual thing for me.
In fact, if you omit spam (and don't class email you don't agree with as spam), it would be an unusual minute if someone hadn't contributed to my inbox!
So why on earth would this one particular email be something that I would comment about?
Not because it was about MSKLC; I have a dedicated folder for archiving those, which currently contains 16,956 items in it.
And not because it contains a suggestion for MSKLC. At least ⅓ of those 16,956 items do that.
But in this case, with this mail, something happened.
And, to quote Douglas Adams, "Once something actually happens somewhere in something as wildly complicated as the universe, Kevin knows where it will all end up- where “Kevin” is any random entity that doesn’t know nothin’ about nothin’"
In this case, it was about the File|Save As Image feature:
This is a feature that came out of one or those D&P meetings i first described back in the beginning of 2005 in Accessibility, Internationalization, and Keyboards (#3: MSKLC's UI):
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.
...
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....
In this case, Simon's spec (largely written after MSKLC was developed -- proof that even when PMs don't write specs they aren't lazy since both Simon and Cathy were very involved in the whole project!) had called out the need to make keyboards easy to document.
I told them we had no time to do it -- people would have to take screenshots of the tool in various states, or we'd risk slipping the release.
We all considered that, and everyone reluctantly agreed.
Then, back in my office, I was annoyed.
i had to try to do something.
and thus the "Save As Image" feature was born. I wrote up a simple screen scrape.
The next time we met, I shared this, and they were pleased we could take some steps to help keyboard authors.
My original prototype also included a "Save all states" functionality, but it was awkward and weird, and eventually we all agreed it was no good...
Now there was an earlier meeting (months earlier) about dead keys.
And how hard it was to see what was in them.
I mean, you had to right click on the key to get the Dead Key Dialog... option:
to launch the actual dialog:
This was really hard to imagine people finding intuitive or useful.
I hung my head and said "I can't work miracles, let alone design them!"
They agreed that this would be too hard to do.
For next week's meeting, I showed them my "tooltip" solution:
My original prototype looked much worse than that -- they spent that meeting figuring out how it should look, and ended up I think with a pretty good solution, I think!
As a side note, the contrast between MSLU and MSKLC is huge in terms of PM input. For MSLU, I leaned most heavily on Julie (my dev lead at the time), and the project was largely about her dream of a Unicode Layer on Win9x. But MSKLC was about Cathy, and her dream of a tool to make it easier to create keyboard layouts. I could have easily done MSKLC without her, but it would have sucked. So I am quite grateful for her involvement! :-)
Anyway, back to that email.
The DeadKey feature of MSKLC is more important than the time given to it. I am struggling now with how to communicate both to myself and others what the dead-key layout of my new keyboards is. How difficult would it be to add a refinement to MSKLC such that a .jpg of the dead-key layout could be requested also. All the code is there to do the jpgs for a standard layout, a CTL layout, a CTL-SHFT layout, etc. It should not be too difficult to add the dead-key image functionality.
This is indeed a big thing. It would be a great feature to add.
We clearly have all the data, right?
And now I am wishing for a D&P with Cathy and Simon to talk about it!
I should talk to some people... :-)
Doug Ewell on 25 Sep 2012 1:53 PM:
Seventeen thousand e-mails. Another good reason why MSKLC needs to be picked up again, by someone.
Matthew Slyman on 16 Apr 2013 3:05 AM:
The dead key tooltips are great! I've been using them extensively in designing my "Dvorak International Scientific" layout.
However... Due to apparent limitations/complications in using MLKLC for chained dead keys, I've switched to the new "KbdEdit Premium" for some of my work (putting it through its paces). Getting the back-end and user-interface right for chained dead keys is going to require some serious computer-science skills coupled with a real understanding of internationalization issues. You should talk to someone who understands data-structure design inside-out. Is that yourself?
It appears to me that a proper treatment of chained dead keys is going to require a tree-type or network-type/map-type structure (and that a similar structure should be used for the documentation/illustration of chained dead key configurations).
The deeper I've been delving into dead-keys, the more acutely I've felt the requirement for documentation capabilities. For example, I've been craving for a utility that would output a list (in Unicode order) of all the code points reachable with a given keyboard layout (and, for each point, the list of methods of composing that code-point). Export as Excel spreadsheet or Access database would be ideal (a text or CSV file would be fine). Shouldn't be too hard to do this based on a .klc file! Perhaps I'll try to do this (now, when to find the time???) Please let me know if you start this project first, so I won't have to bother!