November, 2010

A customer wanted to do one of those user-hostile things that Windows doesn't make easy to do (the sort of thing I tend to call out on this Web site). After receiving an explanation that Windows doesn't provide a way of doing what they want because it abuses the component in question and goes against user expectations, the customer countered, "Yes, we understand that, but our case is different."

The customer then proceeded to explain how they intended to use this newfound power (if only they could figure out how to do it) and under what circumstances they intend to invoke it. Their explanation was interesting in that the description could be applied to any other program on the planet.

Yes, we understand that, but our case is different. We would do this only after the user installs the program or reconfigures it from the Add or Remove Programs control panel. After a few days, we would stop doing it, unless triggered by a reinstall or a reconfiguration.

So far, there's nothing here that explains why your program should be able to do this, but not, say, Photoshop. There is no evidence that this program is any different from the tens of thousands of other programs out there, many of which probably want to do that very same thing this program wants to do.

Just because you say that your case is different doesn't make it so.

At Microsoft, the take-away is the essential message of a presentation or the conclusion that you are expected to draw from a situation. It is something you are expected to remember when the whole thing is over, a piece of information you take away with you as you leave the room.

XYZ demo take away (title of a document)

The preferred intensifier is key, and you probably see it attached to the phrase take-away more often than not. This example comes from a presentation on the results of a user study:

Results: XYZ Tough to Use

• ...
• Key take-away:
  • Migration to XYZ will be difficult
  • Need to show value of using the power of DEF

In fact, every single slide in this presentation had a bullet point at the bottom called Key take-away. (And, as you may have noticed, the heading is the singular take-away even though multiple take-aways were listed.)

Another use of the term take-away follows in the same spirit as the "essential message" usage, but the idea of "taking away" is taken literally: A take-away is a small information card that sales and marketing people give to potential customers. Think of it as the business card for a service rather than for a person.

[Raymond is currently away; this message was pre-recorded.]

Some time ago, I spent the Thanksgiving holiday with my nieces (ages 3 and 5 at the time), and I overheard this conversation between them.

"Thanksgiving is over."

— Christmas is coming!

"It's Christmas time!"

— Today is Christmas!

KJK::Hyperion asks, "Could you shed some light on Get/SetMessageExtraInfo? It's almost like nobody on earth used them, ever, and I can't get some sample code."

Yup, that's about right. Nobody on earth (to within experimental error) ever used them.

These functions were introduced on July 20, 1990 (I'm looking at the change history right now) at the request of what was then called the Hand-Writing Windows group, which shipped the first version of Windows for Pen Computing in 1992. The idea was that each input event from the custom pen hardware would have this extra information associated with it, and the software that converted pen input into strokes (and ultimately into gestures or characters via handwriting recognition) would use this extra information to guide the conversion process.

Seeing as Pen Windows died a hasty death, I think it's fairly accurate to say that nobody on earth will admit to having used these functions.

For those of you fortunate enough never to have been exposed to Pen Windows, here are some random tidbits of information.

First, applications needed to be modified to support pen input. In particular, edit controls did not accept text input from the pen. You had to replace them with one of the following:

• Handwriting edit control (hedit). This accepted free form handwriting input.
• Boxed edit control (bedit). This accepted handwriting input, but you had to write one letter per box. This constraint resulted in much better character recognition.

Both of these controls were significantly larger than the standard edit control. They needed to be, in order to give enough room for the user to write. This in turned means that you had to edit all your dialog templates and custom window layout to take into account the larger pen-aware controls.

And just changing your controls wasn't enough. You also had to write extra code to call various character recognition functions to get the user's pen input converted and recognized.

Here's an artist's conception of what the boxed edit control looked like:

That weird triangle-shaped thingie was, I believe, called the dinky. What did it do? Beats me.

There are still vestiges of the old Pen Windows product in the GetSystemMetrics function: Check out SM_PENWINDOWS.

(Note that the old Pen Windows product is unrelated to the current Tablet PC product, even though they both do handwriting recognition.)

Bonus chatter: The Windows touch team saw their opportunity and commandeered the extra info (perhaps resurrecting the ghost of Pen Windows) and use the extra info to specify the source of the input.

[Raymond is currently away; this message was pre-recorded.]