The basis of this belief is Microsoft's Tablet PC edition of XP, which incorporates ink into the operating system. In addition, Microsoft made sure that applications (both old and new) are ready to run, Visual Studio Windows development tools integrate the technology, and a set of hardware specifications for Tablet PC-based devices exists.
Based on my evaluation, this "version 1.0" of Microsoft's Tablet PC will be a huge boon to vertical applications that were previously confined to highly proprietary platforms. For general purpose business use, however, the operating system is not quite ready for prime time. Don't throw away that ink pen and pad of paper just yet.
The true measure of any new platform's success is the extent to which it makes users more productive. In vertical scenarios, where clipboards and paper forms were once the norm, the potential benefits of a widely available and accepted tablet development platform are undeniable.
Tablet PC is destined to become the de facto standard for tablet-based vertical applications as well as for the stylus-enablement of existing Windows applications. With a few exceptions, the operating system appears to have most of the necessary underpinnings for developers of those vertical applications to take advantage of styli as a pointing device, ink as a data type, and handwriting recognition.
For stylus-based tablets to reach the masses, three constituencies will need to move the needle in their respective disciplines.
First, Microsoft developers must not only do a better job of integrating tablet-based functionality into Windows as well as the applications, but they must also fix some showstopper bugs. I expect those bugs to be fixed in short order.
Second, third-party developers of horizontal applications must figure out how Tablet PC capabilities can substantially improve productivity. There are all sorts of vendors, from Corel to Groove Networks, that have already gone the extra mile to create tablet-enabled applications.
Finally, hardware vendors that manufacture Tablet PC-based systems must deliver solutions that don't compromise the objectives of those developers or short change users. For example, if someone expects me (as Toshiba does) to use a Tablet PC instead of pen and paper for taking meeting notes, then the battery life had better be outstanding. And, I should be able to change batteries without powering down.
One of the two devices I tested--Acer's TravelMate C100 convertible (a notebook computer that converts into a tablet) lacked a provision for swapping batteries without powering down. Compaq's convertible allows you to put the system into standby mode and gives you 30 seconds to make a battery switch. Toshiba's convertible had the same problem as the Acer. Toshiba officials suggested putting the system into hibernate mode instead (which takes longer to go into and to come out of than standby mode). But that's ridiculous. Can you imagine a meeting with lawyers where every minute is money and someone says "Excuse me, can we all stop for a few minutes so I can change my battery?"
Integration could be better
One of the ways that the Tablet PC attempts to beat the utility of basic pen and paper is its ability to search through ink for specific text. Anyone who has filled a yellow pad or a composition notebook, only to flip through every page of it later in search of those all important notes you made several months ago will appreciate this feature.
This ability to search through ink depends on TabletPC's ability to recognise the ink it's sifting through as text--a feature better known as handwriting recognition (HR). I tried searching for the word "object," which I had written in cursive using a yellow pad-like application called Journal. I invoked that search on two separate occasions--one from within Journal and the other using the Find command from Windows XP's Start menu. Both searches found the document.
Unfortunately, the user interface is inconsistent between the Journal and XP's Find command. Whereas Journal's search function lists the document and subsequently highlights the recognised text when the document is opened, the search results of XP's Find command only lists the document. The text is not highlighted when the document is opened from the results screen.
In addition, despite the fact that Microsoft developed specific extensions for Tablet PC support in Microsoft Office, the Find command was incapable of locating the same handwritten text when it was cut and pasted into Microsoft Word. Nor did it find ink that was added directly to a Word document via the special toolbar that's afforded to Word by those extensions. Another oversight is the fact that Journal's search only searches Journal documents and has no option to expand the search into other applications.
The extensions for Microsoft Office had other problems in terms of uniformity in user interface and bugs. For example, not all of the ink tools to which I had access when using the Journal were present when inputting ink into other ink-enabled applications such as Word or another special application called Sticky Notes, which is included with the Tablet PC software.
Version 1.0 Blues (will 3.0 get it right?)
I also bumped into some bugs in the Tablet PC extensions for Microsoft Office. Before ink can be input into a Word document, the user must create a region in the document where the writing (or drawing) will take place. I was able to consistently reproduce an artifact problem with the boundaries to this region when the region was resized. (View screen image.)
But also found a show-stopping bug in Outlook. One of the cool things about Tablet PC is that as long as you are using WordMail to compose your e-mails, you can reply to e-mails using ink. The reply-with-ink feature is not present if you don't use WordMail (which I don't). Unfortunately, when I used WordMail to test this feature, it was crippled by a temperamental "insert ink" button. In some cases, the button was illuminated so that I could tap it and begin to respond to an e-mail with ink; in other cases the button remained grayed out and inaccessible. Microsoft acknowledged the bug and officials said a fix is in progress.
Although not insurmountable, using ink to respond to e-mails presents another challenge if you're sending that e-mail to someone who doesn't use Outlook. Currently, there is no Internet standard for ink. To overcome this, users must take care to format their e-mails with HTML since that is the most universally understood document format. Although ink is unavailable as an option if the plain text format is selected, it is available in two other formats supported by WordMail--rich text and HTML. If you choose rich text and the e-mail is opened with something other than a client that supports rich text (e.g., a browser), an object stub like "<<... OLE_Obj... >>" instead of the ink may appear when the recipient opens the e-mail.
Lack of a standard for ink presents another problem for users who prefer to scroll through a long thread of back and forth e-mails. In my tests where a recipient of my e-mail was able to view my ink in-line with the rest of the message but preferred to respond to my e-mail with plain text, the original notes I sent to him came back in his reply as two non-integrated attachments-one that held the text, and another that was a GIF image.
Another bug had to do with the calibration of the stylus to the tablet. In Tablet PC, achieving the equivalent of a right mouse click requires a tap and hold (on the display) with the stylus. When the user does this, a small animation appears indicating that the system has detected such a request. However, there are certain areas of an application's window where a right-mouse click shouldn't be possible. For example, the arrows used for scrolling a Word document vertically shouldn't be right-mouse clickable. Microsoft wondered whether this could be a hardware problem that was isolated to one tablet. But I was able to reproduce it on Toshiba's Tablet PC on the eve of the big Tablet PC launch in New York City.
