by Robert Hess -- firstname.lastname@example.org
Some comments on things you've said recently about upcoming Apple technologies. In regard to QuickDraw GX, you left out the coolest thing about QuickDraw GX. Its replacement for the PrintMonitor is the coolest, most mind-blowingly wonderful thing I've seen in a long time (oh, yeah, even cooler than ultraSHIELD or RAM Doubler).
Forget the desktop printers... that's old hat, available in PrintJuggler and Leonard Rosenthol's DTPrinter. Here's a scenario any businessperson would love:
You print a 100-page document from Word, which goes to the new QuickDraw GX spooler instead of PrintMonitor. You quit out of Word. There, in the Finder, are icons representing your favorite printers. One icon shows that it is busy printing your 100-pager. You double-click on the icon and it shows (within the Finder) an informative window telling you what's going on, where in the job it is, and so on. Content, warm, and fuzzy, you go to lunch.
When you return, pages 1 through 50 are sitting in the printer bin. You look under the printer and see someone has kicked the LocalTalk box out of the wall. The box is damaged and will take a few hours to repair. If you had been using PrintMonitor, you staple all 50 pages to the body of the person who did this since you would have to reprint the entire job AND wait for the printer to be fixed.
Instead, you keep those 50 pages. You go to your Mac, open the printer info window (which tells you there was a weird problem with your job), and double-click on the document you halfway printed. SimpleText (the cool replacement for TeachText) opens and shows an image of your document. You scroll to page 50 and compare it to the last page that actually printed. They're not the same; it seems you have some extra pages numbered "i, ii, iii, etc." at the start of your document, so what says "50" at the bottom isn't really the 50th page. The last page that physically printed was page 57 of the spooled document.
You quit SimpleText, click on your spooled document, drag it to another printer in the building and tell it to start printing not from page 1, but from page 58.
Life is good.
As far as Apple Interactive Help goes, Apple should have shown you the demo they showed developers at WWDC (Word-Wide Developers Conference).
Essentially, Apple Help can use an application's intelligence along with Apple events to lead the user step-by-step through a complex task. Apple Help can even confirm that the user has completed a step correctly and can automatically go on to the next step.
A developer can build functionality into Apple Help. One example Apple uses: in response to the question, "How do I change the level of my Mac's volume?" Apple Help can either tell you how to do it, show you how to do it or provide you with a "louder" and a "softer" button to do it without even leaving Apple Help.
If a developer is willing to invest the time, Apple Help can do almost anything you can imagine. [I have a very good imagination - but I'm willing to give Apple Help the benefit of the doubt for the moment. -Adam]
Finally, OpenDoc. Apple's most touted hope for OpenDoc isn't that it lets you work on many components within a single document; OLE gives you that. Apple's hope is that developers can quit being forced by the competition of other developers to spend time and energy working on features which aren't in the immediate realm of the programmer's skills, and instead can work on the specific tool they wish to develop.
The best example of the need for this can be seen in any mainstream word processor or integrated package. Some people might say Word is the best text processor on the planet, but I'll bet you would have a hard time finding anyone outside Microsoft who thought Word was also best at tables, page layout, indexing, and formulas.
OpenDoc will let a user pick the best text processor, the best table editor, the best page layout application, the best indexer, and the best formula editor from a wide variety of vendors, and make them all work together despite the fact their programmers have never met, never spoken, and probably don't get along. And the developer of each of those components can focus on developing the one component they can write better than anyone else, and that's all.
Developers don't have to start from the ground and work their way up in developing OpenDoc components. They can retrofit existing code (especially if it's written in C++) fairly easily. If anything, the dramatically reduced size of "applications" should reduce development and testing times.