On The Power of PenPoint by Robert Carr and Dan Shafer

Summary of the Book

Some background: Robert Carr worked on FrameWorks before joining GO Corp, and there developed ideas about live embedded documents as seen in PenPoint. GO is one of the sad stories of a purely technology company with a clear vision that failed despite great technology because of lack of a market; many technologists thought pen computers were the next market opportunity, but it seems the consumer didn't agree.

PenPoint is a clean and capable OS, well designed for its niche. In fact, today's operating systems still lack many of its features. Besides the UI ideas such as pen-centricity, the notebook metaphor, automatic window layout, do-what-I-mean-not-what-I-say smart objects, and multitasking, this OS supports compound documents with live embedding, traversal, and storage; object orientation with multiple APIs, persistance, object versioning; and mobile features such as connectivity, and RAM-based file storage. In addition it was designed with real-world goals in mind like low RAM usage, ease of use for novices, convenience for developers (through the use of C rather than something more esoteric), and compatibility with existing OS file formats.

It's a shame, but technology isn't enough. Slow machines and dim screens make a pen computer less convenient than a pad of paper, and the consumers have voted that they don't want a hard-to-read, heavy, and expensive automated pad of paper. If it had been a computer, running DOS or Windows programs, rather than a pad of paper emulater, it might have fared better.

These types of machines may return to fashion the arm as mobile Web connection machines, in other words as Net Computers rather than as pen computers, but in the meantime GO Corp and PenPoint have become technological landfill.


Thoughts

PenPoint's component model addressed many of the issues we're facing; they came up with a clean multilayered OS, and the ideas were in place for the creation of new interfaces at different levels in addition to the GO-supplied ones, should the OS have become popular. The extensive integration of gesture recognition into the UI parallels the eventual inclusion of glove or 3d-mouse interfaces into our products; PenPoint uses a Model-View-Controller architecture just as we must.

What lessons can we learn from the GO experience? The biggest lesson is to find a real market for one's technology; we must find a way to provide value to consumers, not forgetting compatibility with what's already out there, before any technological advances.

PenPoint uses UIDs to identify resources and objects: fixed-length ID numbers that remain unique across machines and time. Today the accepted mechanism for this is variable-length URLs.

PenPoint uses Mac-like resources, whereas the modern approach is to use object orientation and save such data with the object. Rather than storing all noncode data, we now store that data plus the class name of the object all together. Resources exist to make language translation easy; this is done within a configurable UI system using a UI editor, which allows one to search for and modify any textual components in a system. This change results in new versions of the encompassing components, or in another way of thinking a new bundle of components. The text fields of components may also be replaced by run-time switchable text generators, which use a global language state to determine which of several text choices to present.

PenPoint solves object security issues with a keyed access approach, which separated access to an object into public and privately accessible functions. Java uses a different namespace access protection method, which provides only class-level security control. Both methods provide about the same abilities and convenience.

PenPoint files application data the same way that a DOS app would; with special save/restore code rather than a persistent object approach. This fits better with PenPoint's the low-memory-use and old-OS-compatibility goals. So PenPoint only have save/restore on an application level, rather than on an object level. This differs somewhat from our goals, as we must have an finer-grained save/restore that's able to work with individual objects, and that can be used for sending state change information about individual properties of such objects. The idea of applying compression on top of whatever the object ends up sending is a good one, except that since the best compressions are achievable by the object itself due to its extra knowledge, we'd rather have each object handle its own property compression.


Questions

How capable is PenPoint's versioning support?


References

R. Carr, D. Shafer, The Power of PenPoint, ISBN 0-201-57763-1, Addison Wesley, 1991.
 
 
Substantive changes:
    March 21, 1996: created.
Copyright © 1996, Steve Colwell, All Rights Reserved
Home page