The Great Horse Race of 1991: A Developer’s Point of View

Battles between software standards make good press, but for software developers, they are not to be taken lightly. As a principal in a company that developed some of the early desktop publishing software for PCs, our company spent two years crafting our program for the GEM environment. After the product was introduced, we then had to spend two more years bludgeoning the program into a shape acceptable to MS-Windows. The operation was a success, but the patient did not survive (or rather, is presently comatose).

A growing number of notebook systems will be announced this year and will trigger a round of debates on which horse will prevail in this new race of pen-based computing. As a developer who is considering writing apps for one or more stylus-based systems, I’ll discuss some of the pros and cons surrounding the principal contenders. My remarks are based on investigating multiple pen-based computers over the last year and on an intensive week spent at the GO Developer Seminar. The major points in recent announcements by GO Corporation and Microsoft are discussed elsewhere in this newsletter so I won’t repeat them here.

Basic Questions

Before coming up with a winner of the horse race, we’ll consider the system requirements for stylus-oriented applications. Are these inherently different from mouse-oriented GUI apps? If so, how? Next, we need to evaluate how well the various contenders meet the requirements for stylus-oriented applications. Is the system software up to snuff? Finally, how will the winner of the horse race be decided? Will technological merit have anything to do with it?

Application Requirements

In order to determine the technical requirements for stylus-based computing, you need to have a particular vision of how these machines will be used and who will buy them. There are differing visions of pen-based, mobile computing now being articulated in various corners of this nascent industry. As a software developer, it’s important to have your own vision. So, here goes:

• Stylus-based computing is for situations where mobility is essential, where a keyboard-based machine is too large, or where keyboard-input is clumsy or socially inappropriate.
• Stylus-based machines are appropriate for both vertical markets (industries such as insurance, real estate and health care) as well as horizontal tasks (personal information management, spreadsheets).
• Users of stylus-based machines will span the three worlds of mobile data entry (e.g. delivery persons, supermarket inventory takers, issuers of parking tickets), mobile data retrieval (architects accessing blueprints at a construction site), and mobile data analysis (field sales staff in insurance and real estate.) Of course, users in certain application areas (hospitals and health care) will require all three: data entry, retrieval and analysis.
• Users in both horizontal and vertical markets will need to connect with society’s modern technological infrastructure (email, fax, LANs, voicemail, WANs, etc.) Connections should be multiple, diverse, detachable and easily resumable.
• Stylus-based machines must have a high level of availability, more than the few hours per day allowed by present-day batteries and power-supply management techniques.

The Shape of the Winner

From our vision of pen-based computing, we can come up with the design requirements that should shape the winning horse. Of course, marketing factors and other intangibles often change the ultimate winner considerably. But the ideal specification looks something like this:

• The accessibility and ease-of-use requirements mean a modeless, direct manipulation interface (aka GUI). Direct manipulation does not, however, imply an equivalence between mouse and stylus. Rather, it is likely that new user interface conventions need to be established to make the most effective use of the cursorless pen interface (what GO Corp calls “pen-centric apps”). This places mouse-based GUIs like PenWindows at something of a disadvantage.
• The responsiveness requirement means that character recognition must occur at the lowest levels of the system. Consider the mouse tracking routines on the first Mac, written at such a low level that they are effectively part of the hardware. Compare that smooth responsiveness to the mushy feel of the mouse in Microsoft Windows, even on a 386. That’s the difference between a layer on top of DOS versus one underneath the operating system. The recognition module is complex enough that it can’t run at interrupt level, but must be its own operating system task. Running on a separate co-processor is the better approach, but preemptive multitasking is also acceptable.
• The requirements for maximum availability, mobility and responsiveness mitigate against use of a hard drive, not matter how small or light. This means at least 8 megabytes of RAM. Techniques to conserve power and mass storage must be built in at all levels of the system. For example, file system routines (or their object-oriented equivalents) may allow for transparent data compression and decompression upon read and write. Also, maximum reusability of software components should be strived for, through object-oriented subclassing.
• The requirement for diverse application domains implies a highly integrated system with easily interchangeable software components. This again supports a software environment that is thoroughly object-oriented. This also means built-in user interface objects to ensure consistency across application components. Also required is a visible User Interface Police, a la Apple.
• The diversity of application domains also implies interchangeability of handwriting recognition engines, as well as domain-specific recognition libraries available to applications within that domain (e.g. proofreader’s gestures for publishing industry applications, math symbols for scientific applications). This kind of pluggability should be supported by the system.
• The diversity of application domains means two things: the winning horse will have a lot of software developers betting on it, and software development must have a gently sloping learning curve, as opposed to what some call a “learning wall”. This implies developer-level compatibility with the DOS platform, as well as additional tools. This puts systems based on non-mainstream languages (e.g. Smalltalk and Lisp systems) at a disadvantage.
• New user populations running new kinds of pen-centric applications means that developers will have their hands full attempting to deliver flexible, responsive apps. This means that any technological detritus resulting from historical accidents (e.g. the 640K limit, DOS Real Mode, near and far pointers) should not clutter the hallways of progress. This will put DOS-based systems at a disadvantage.

So there you have it: A set of system design requirements that logically follows from a particular vision of pen-based technology. I’ll leave it up to you to consider how well each of the contenders matches up to the shape of our hypothetical winner.

The Issue That Will Never Die

As mentioned earlier, marketing considerations often dilute ideal guidelines and can greatly change the outcome of the race. In this case, just add the following:

• Users of stylus-based machines will be willing to make certain sacrifices (e.g., performance, applicability to tasks) in order to gain certain major benefits (user-level compatibility with existing DOS applications, lower costs of hardware and support as a result of platform compatibility).

This guideline represents the basic premise behind Microsoft’s PenWindows, which represents a horse of an entirely different shape, and is considered by many to be a very serious contender.

I understand that compatibility with the past can be the single most important factor in determining the winner of the horse race. Witness the success of Windows 3.0 over OS/2 Presentation Manager, or the survival over 25 years of the IBM 360 instruction set, or the ongoing market momentum of technologically stagnant products like Lotus 1-2-3 or dBase IV, or even the uncanny survival of remnants of 8008 instructions in advanced CPUs like the 80486.

Many developers, perhaps overly impressed with the technical spark and sizzle of a new platform, give short shrift to the issue of user-level compatibility. User-level compatibility is not an issue for them, until they themselves are the users in question. Just try to pry them loose from their favorite character-mode text editor. If no one had asked at the GO Developer Seminar if Emacs or Brief ran on PenPoint, I would have done so (the answer is that development for PenPoint is done on a DOS machine, using any DOS-based text editor). Compatibility therefore, is a critical issue for both users and developers, and cannot be blithely cast aside. Accepting this one additional guideline changes the layout of the field as well as the shape of the winner. So why not include DOS-compatibility as one of our assumptions?

A Brief History of Revolutions

There is a case for a clean break with the past. The 45 years of computer technology have seen three generations of machines appear: mainframes, minis, and personal computers. Each generation represented a particular combination of mode of interaction, cost, configuration, user population, system software, and application domains and also represented incremental change along each of several dimensions. Overall, the trends have been:

• A reduction in physical size and cost
• An increase in interactivity, availability, and ease of use
• An increase in the diversity and size of the user population
• An increase in the diversity of application domains Moving from one point to another in each of these four scales has resulted in enough discontinuity with the past to require an entirely new platform for software development. It seems that stylus-based machines are the first instances of the next generation of machines. Certainly they will be reduced in size (if not in cost), will be more easily accessible to a larger set of users, and will be used for tasks in which computers do not currently play much of a role.

A New Generation, or What?

While a new generation of computer may be necessary, it has not yet appeared or is, at best, in the premature birth stage. And if the mainstream entrants have yet to appear, what additional characteristics can we expect from the new breed of machines? First, stylus-based machines should more properly be called “analog accessible.” That is, they are not so much handwriting-input machines as they are machines that allow for non-digital methods of input. These new input modes include not just hand-printed characters and gesture strokes, but also analog inputs such as voice and image (possibly through handheld scanners). These richer input modes have yet to appear.

Second, it is not clear that any of the entrants fully satisfy the requirements list presented earlier. In some cases, responsiveness and interactive bandwidth have decreased, due to sluggish performance on overloaded CPUs. Connectivity remains an open question. Availability and cost need further improvement. It may be several more years until the usability threshold is crossed.

Why Not Just Wait?

Given all this uncertainty, why not just wait until things become more clear before picking a target platform for your software development efforts? The answer is simple. Because you can’t wait until the race has begun to pick your winner.

Mitch Kapor and Jonathan Sachs didn’t wait when committing to the PC platform when it was far from clear that IBM would not stumble (as it had with its earlier PC entry, the 1501). Likewise with Paul Brainerd and Aldus Pagemaker on the Mac.

In the long term, there are deep technological currents that will result in a new generation of computers and create a new industry. This is as inevitable as next week’s Elvis story in the National Enquirer. In the short term, however, there are hard decisions to be made over the coming months regarding platforms, applications, and markets. A year from now, we may not look back at 1991 as the Year of the Stylus Computer, but you can bet we’ll see that the Year of the Stylus App Developer certainly arrived.