It's easy to assume that we have it better now than we ever had it in the past. In raw numerical terms, today's computers are many thousands of times faster than the computers I grew up using in the '80s and '90s, and that has enabled the development of software that is wildly more capable but in many cases much more user-friendly than the apps I used back then. Yet say the word ClarisWorks — the name given to the precursor to iWork as Apple's office package — to a Mac user of my vintage and they'll pause for a moment, go a bit misty-eyed, and proceed to tell you with a slightly unsettling zeal how awesome and ahead-of-its-time it was.
And it really was. Before ClarisWorks, so-called integrated product suites were nothing of the kind. That is, while you might have gotten a word processor, spreadsheet app and drawing app bundled in one box (installed, of course, from a stack of floppy disks), they were essentially separate apps. While they might appear to be part of a suite on the surface — sharing a UI design, splash screen, even some common features — they were technically very distinct pieces of software.
That might have been a perfectly valid mindset in the '70s when tasks were often very compartmentalized, only coming together to produce a report or a brochure, very late in the (hugely complex and expensive) process. But by the late 80s, we wanted the power of desktop publishing (or DTP) in our hands. DTP would let anyone produce elementary school homework, a college essay, or a business proposal all by themselves, and being able to include graphics, pictures, charts and diagrams on a single, WYSIWYG document was vital.
Enter ClarisWorks in 1991, and enter one of its creators, Bob Hearn, into our story, writing in his excellent A Brief History of ClarisWorks:
We came up with a frame-based approach. Most of the functionality particular to the various application types was packaged up into "frames": word processing frames, graphics frames, etc. These frames were then used as building blocks to make documents of the appropriate types, in a unified programming framework. For example, a word processing document was essentially a bunch of text frames, one per page, linked together.
The result was that not only was most of the code shared across the document types, but the application was also truly integrated — the frames could be embedded in each other. For example, you could plop a spreadsheet frame right into your word processing document. Text objects in a graphics document had a full-featured word processing engine behind them. The database form editor used the built-in graphics environment.
Sign up for Computerworld eNewsletters.