About one and a half years ago, Microsoft introduced a revolutionary new feature in their line of desktop operating systems: support for Tablet PCs. From a software point of view, this mainly means support for "digital ink." But let's start at the very beginning.
Tablet PCs are similar to notebook PCs in many ways. Most Tablet PCs have a keyboard and display configuration that is virtually identical to other laptops, and at first sight, the main difference is that Tablet PCs are generally lightweight and slightly smaller than many of the high-powered notebooks, especially those used by developers. Tablet PCs are regular PCs and not scaled-down portables like PDAs. The Tablet PC operating system is a superset of Windows XP, and will therefore run all the software you can run on your other PCs, and then some.
From a hardware viewpoint, the main difference between tablets and "regular" PCs is the support for pen-based operation. This additional feature set (mouse and keyboard support is unchanged) calls for a mechanism than can recognize pens moved on the display. This is accomplished through a "digitizer," which is a device that is mounted behind the display that uses electromagnetism to sense pen position and orientation. Oh, and of course, Tablet PCs can generally have a "flat" orientation of the display at least part of the time they are being used Most tablet devices allow "swiveling" the display around from its notebook position to being laid down flat with the display facing upwards, allowing for convenient pen operation when desired. This mode of operation, paired with the pen-enabled operating system and pen-enabled applications, effectively simulates pen and paper, a mode very familiar to many "users."
So when would one use a Tablet PC? Well, I am glad you asked! Tablet PCs have many uses, but it seems that only a few of them are obvious to developers. I think this may have to do with the fact that most developers have the luxury of sitting down at a desk when they work on their computer. At the very least we can set our notebooks on our lap. But this is not true for a wide range of professions! Just think about scientists in a lab, policemen out in the field, manufacturing professions, trucking, and many more. Professionals in those jobs could benefit greatly from the power of PCs, yet since they are constantly up and about, using notebook or desktop computers is not always a viable solution. And neither are PDAs, since those are generally companion devices and not meant for stand alone operation. Just imagine having a Pocket PC as your only computer! Tablet PCs, on the other hand, are powerful PCs that you can operate in practically any situation because you can easily cradle a Tablet PC in one hand and operate the pen interface with the other.
There seems to be a shared agreement in the software industry that there is a huge untapped market, representing great opportunities for a number of third-party vendors of all sizes. So my question to you is: Does your code think in ink yet?
Before you think about answering that question, I should probably discuss what it means to "think in ink" or to "treat ink as a first-class citizen." By default, Tablet PCs can run all Windows applications, even in pen-mode, since the operating system provides features such as the "Input Panel," which translates pen input (such as handwriting) into regular keyboard input, and streams it to the application as if someone actually pressed the buttons. Therefore, the application will likely not know the difference between pen and keyboard input and it will operate as always.
However, even if an application does know the difference between a keyboard and the pen, you can be sure that users will know the difference between simple keyboard input and the somewhat cumbersome ink Input Panel. The Input Panel really represents a worst-case scenario for tablet users. Yes, it works, and yes, it will ink-enable every application, but the experience leaves much to be desired. Instead, what we need are applications that support ink natively and seamlessly without the need for the Input Panel. Providing this functionality is not very hard from a technical point of view. The Tablet PC Platform SDK provides a number of ink-input classes that you can simply attach to controls on the screen. For instance, you can simply attach an "ink collector" class to a TextBox control to enable handwriting on that text box. Recognition of the handwriting will not happen entirely automatically, but almost. All the developer needs to do is call the ToString() method on the Ink object. This takes the ink input and converts it to regular text (and it does so with a surprisingly high level of success).
But is that really all? Well, technically yes, but it will result in poor UI design. One of the key problems with ink input is that you simply need a larger area for handwriting than for keyboard input. Simply attaching an ink collector to a TextBox control will result in having only the area inside the text box available for handwriting, which could require the user to write tiny letters, and even so, they would quickly run out of room. Also, recognition results for such tiny writing would be catastrophic. Clearly, a larger area is required. For this reason, many examples operate based on huge textboxes. While this solution works fine for samples, it is not acceptable in production applications because to non-Tablet PC users, the application would look completely unacceptable, featuring only a handful of controls on each form, leaving the user wondering what possessed the developer to create such odd screen layouts for no apparent reason.
Unfortunately, no clear standards have evolved to solve the issue. Personally, I like a solution where each text box uses an ink collector not to recognize ink, but simply to hook pen events. This way, the application can react to the pen whenever it is moved anywhere near the text box (or any other control for that matter), and "unfold" a slightly larger pen input area. I like to use a separate, borderless window that fades in and out based on pen events. This window collects pen input and performs recognition, the results of which are then communicated to the actual text box. In my experience, this works great for Tablet PC scenarios, and it does not affect the experience for non-Tablet PC users in any negative way.
Of course, that leaves developers with the problem of how to add this functionality to all text boxes and other input controls, and how to do so in a way that doesn't detrimentally affect application performance. If you have read my past articles, you probably already know the answer to the first problem. I personally never use the standard Windows Forms controls. Instead, I use my own subclasses, which allows me to easily add my own features. The scenario I describe in this article is a perfect example. I can simply change my TextBox class and add ink functionality in a generic fashion. This way I can ink-enable entire applications. In fact, I can ink-enable all applications EPS (my company) ever builds, simply by using our derived controls, which is what we always do anyway.
The answer to the second question is similarly simple: It is probably safe to assume that most users will only use one pen at a time, and that they'll use the pen only on one control at a time. Therefore, it is perfectly fine to use only one ink collector throughout an application or app domain. You can make the ink collector object a static member of the text box ("shared" in VB) or encapsulate it into a singleton class. This way, the very first control instantiated in an app domain will take a slight performance hit (which should not be noticeable), and subsequent application performance should not be impacted at all.
Tablet PCs are fantastic devices. They open up whole new market segments that previously remained untapped-something that does not occur all that often these days. And best of all, companies of all sizes can take advantage of these opportunities. The initial investment required to get into Tablet PC development is negligible, especially since programmers can do Tablet PC development on regular desktop computers simply by installing the Tablet PC Platform SDK. There is no cost involved, other than your own time. Although I have to warn you: Once you get hooked on the Tablet PC concept, you might find yourself buying an actual Tablet PC device, which will cost you about as much as a good notebook computer (which it essentially is). (Someone has to have the hardware to do QA testing, right?)
If you haven't tried Tablet PC development, I encourage you to get started right away! There are great opportunities in this field and they are relatively easy to tap into. And if you have a great use for Tablet PC functionality, drop me an email! I am always interested in the creative ideas people come up with. And yes, I am even willing to attempt to read hand-written emails...
