The title of this month's column is too obscure a reference to stand unexplained.
Thirty years ago in Advertisements for Myself, Norman Mailer established his reputation, partly for talent but mostly for arrogance. In a section of the book called "Evaluations -- Quick and Expensive Comments of the Talent in the Room," he trashed most of his contemporary writers. Myrick Land documented the ensuing feuds in his less celebrated but funnier book, The Fine Art of Literary Mayhem. The Mailer chapter -- Mailer must have been miffed to find that the entire book was not devoted to him -- was titled, "Mr. Norman Mailer Challenges All the Talent in the Room."
Microsoft spent megabucks rolling out Windows 3.0 this May and will be spending more over the next months to encourage Windows 2 users to upgrade and nonusers to take the plunge. Is this upgrade such a big deal?
It's such a big deal. Bill Gates claims that Windows 3.0 will have an impact on every aspect of the personal computer industry. He's probably right. The following are some thoughts on Windows 3.0 vs. the talent in the room, with the glaring exception of the heavyweight contender out in the hall. As Stephen Morse pointed out in PC Week, Presentation Manager is quite capable of delaying itself with no help from Windows 3.0
Industry watcher Stewart Alsop's view is that the release of Windows 3.0 will increase Apple arket share along with the Windows market share, both at the cost of DOS. PC Week quotes Bill Gates as predicting that Windows will outsell DOS in a year.
Windows as a threat to DOS is, in a sense, nonsense. Nobody is going to buy Windows rather than DOS. Windows is a DOS extension, more closely integrated with DOS than any shell, requiring and using DOS, in particular the DOS file system. Furthermore, Windows 3 supports non-Windows applications, meaning plain DOS applications. Finally, any way you slice the Windows/DOS pie, Microsoft gets fed.
The threat that Windows poses is to DOS as a development platform. It raises the question, is there any reason to develop for plain DOS anymore? The answer is surely yes. Here's a sample of some classes of users who will still need or want raw DOS.
It's interesting to speculate on how many of these machines will go on cranking away in such environments. And that's all we can do: speculate. Industry history is not long enough to base predictions on, and pre-personal computer software and hardware experience is an entirely different world of technology and pricing. But the matter is unimportant in terms of developing commercial software. Such machines and people effectively become invisible to the market. One application, already sold, is not a market; people who have no need to spend money are not potential customers. The veil falls on these people.
But for new purchases of personal computers for business and other commercial uses, raw DOS is dead. With upgrades running $50 even for run-time users, Windows 3 is priced well, and Microsoft is pushing it hard.
The actual competitors to Windows on Intel CPU-based hardware are the other DOS extenders or Windowing systems. Anyone interested in the technical details of how DOS extenders can live with Windows 3.0 should read Ray Duncan's Extending DOS (Addison-Wesley, 1990). Theoretically, the DOS Protected-Mode Interface (DPMI) lets a DOS extender attain full compatibility with Windows 3.0. But now that there is a canonical windowing extension to DOS produced and marketed by the DOS folks, it won't be fun to compete in that market. And Windows 3 is much better than Windows of the past.
Windows 3 is a big improvement over Windows 2. What strikes one immediately is that the Romper Room primary colors have been replaced by a suite of sophisticated color schemes. This is of no technical significance whatever, but it is indicative of the hand of designers in the user interface, and that's very important to the product's success. At the low end, where a big battle will begin this fall, this sort of thing matters a lot.
Microsoft's Windows 3 GUI team included human factors psychologists, and visual designers were involved in the development of the GUI. The result is a product that should be significantly more attractive to users than Windows 2. The user is given full control over color, but it's easier to select a predefined suite of colors that look good together than to tweak individual colors. This is a good example of providing the customizability but guiding the user toward reasonable customizations.
The Windows interface now uses proportional fonts. Not only does this make the display more readable, but it also raises the professional look of the product. Examining installed fonts and installing new ones is simple and intuitive. The next release is expected to use TrueType outline fonts.
Setup and configuration for particular hardware is largely automatic. This is also very important if Microsoft expects Windows to bring new people into computing. Apple, which has an easier job of it, has set up plug-and-play expectations that Windows has to come close to meeting, and does. Also, user-friendly Control Panel options let the user select printer and network options from lists; these selections become effective immediately, without reinstalling or restarting Windows.
There are some holes in the GUI that let DOS show through. The SysEdit program, which brings up all configuration files for editing, is very handy, but looking through a Maclike window at DOS batch commands will be a disorienting thing for a new computer user.
All these user interface issues are important to the user acceptance and the success of the platform. More important from a technical perspective are the questions of what capabilities the product supports, and how easy it is to develop for it.
The big accomplishment is probably memory management. Running in protected mode on the 286 and 386, supporting virtual 8086 machines on the 386, are things that matter. 3.0 is also more cognizant of networks than 2.x, but it doesn't demand a lot of network awareness from the user. New APIs let network applications mask the difference between local and remote resources. Transparency of remote access is going to become important.
It will take time for the benefits of interapplication communication to emerge, but the dynamic data exchange messaging protocol (DDE) provides the basis for applications that cooperate in ways not seen before.
The reassuring news is the ease of transition from Version 2 to Version 3, which, Windows developers are saying, is a piece of cake. The essential tool, of course, is the Windows SDK, and device driver developers will need the DDK. New Windows developers should probably start, according to developers at a recent meeting of the Software Entrepreneurs Forum, with Charles Petzold's Programming Windows.
While the GUI is not as unified and intuitive as the Mac's, it's close enough to make a Windows box look like a direct competitor to a Mac. And technically, Windows has capabilities that go well beyond what the Mac does at present.
Of course, Apple has something up its sleeve.
At the Apple Worldwide Developers Conference in May, developers got five days' intense exposure to System 7, the biggest thing in Apple system software since the original Mac operating system. It's expected to be out by the end of the year.
System 7 includes a new Finder and other reworkings of the user interface. The improvements are impressive, delivering more power and customizability to the user while at the same time making the interface more consistent, with fewer things to learn. There's something more than consistency involved; it has to do with getting across to the user a big idea, a general metaphor, and letting the user figure out how things ought to work. Apple does a better job of this than anybody in the industry, and Finder 7 is better at it than the current Finder.
Now, pretty much anything the user can click on does something reasonable: Applications, utilities, desk accessories, and control panels all launch when clicked; documents open; and other things return useful information about themselves. Some formerly opaque objects now open to reveal their components. This natural extension of the click-to-open idea eliminates the need for one utility and one user interface: The font/DA mover is no longer needed because fonts and DAs (desk accessories) are stored in openable containers.
Not all the changes reduce the set of concepts the user has to acquire. Apple agonized over one element that it has finally added to the interface: The movable modal dialog box. The user interface had not previously distinguished modality from immovability, and separating these aspects visually caused a lot of headaches. The final design, drawing both its visual appearance and performance from existing elements, will probably pass completely unnoticed by most users, which will be evidence that Apple did it right.
There's a Find menu option for finding files; it seems to be fast, and allows a lot of ways to direct the search. There are a number of smaller tweaks to the GUI. Band selection and window and trash behavior have been honed. The new trash can is another example of the tighter integration of the interface: The trash can was formerly a unique object, but now it's a folder, with no peculiar behavior to learn and adapt to. There are new sizes and colors of icons. The outline views in folders and the new keyboard equivalents for mouse moves look like similar features in Windows.
There's also a system-wide help system called "Balloon Help." Turn it on via an ever present menu item, and anything you point at gives some helpful account of itself in a pop-up cartoon-style word balloon. Apple has already documented the system itself with Balloon Help. Developers can add Balloon Help to their applications without changing any code; the help messages are just resources with pointers to the resources (menu items, controls, window parts, and so on) that they document. Balloon Help is one aspect of the Toolbox Help Manager, which provides facilities for more customized help systems. Balloon Help is intended to provide a basic level of help, letting the user ask, "What is this?" or "What does this do?" It's not intended to be the basis of a complete on-line documentation system, but Help Manager is intended to provide the tools for building such a system.
System 7 includes virtual memory, which the user can turn on or off. MultiFinder is always on, so the System 7 Mac is never a one-application machine. Finder, the system-support application, is always on, reachable via an everpresent menu at the right end of the menubar, its capabilities available to other applications via Apple's interapplication communication.
The interapplication communication (IAC) and networking features are nice. IAC includes several components, particularly AppleEvents, Edition Manager, and the PPC Toolbox.
AppleEvents and changes to the current Event Manager implement the framework for a standard language of messages that applications can pass to each other or to the Finder. The set of standard events is largely undefined; Apple is soliciting developer input. A few events have been defined, including Oapp (open application), ODoc (open document), PDoc (print document), and Quit. All future applications are expected to support these, and others that are being defined. A set of events called "Finder Events" has been defined and implemented in the Finder; applications can avail themselves of the capabilities of the Finder by generating Finder Events.
The Edition Manager implements the publish and subscribe capability. This is live copy and paste: When the "published" document or document section is updated, all subscribing documents are also updated. Apple wants all applications to support publish and subscribe, making the facility as ubiquitous as copy and paste. There currently are some user interface issues to be resolved; even Apple's own HyperCard team appears to be holding off on support for Edition Manager until these issues are resolved.
The PPC Toolbox is the low-level facility for implementing process-to-process communication. Since there is no standard set of events at this level, it will require close cooperation between application developers to use this level. Because it's low level, it will provide higher performance than AppleEvents. It will probably be used by large software vendors to put high-performance integration into suites of applications. This superiority of performance and integration will probably be used to sell the idea that users ought to buy all their applications from one vendor. Only the big guys will be able to make this pitch.
It seems likely that the things that Windows 3.0 and Mac System Software Version 7 have in common will define personal computer application development in the '90s.
Graphical user interfaces are here to stay. A serious push in the low end of the market by clone makers bundling Windows and Apple trying to redefine itself as a company will make it very hard to sell a DOS box. I've hinted at this low-end war, but anyone who reads the weeklies or heard John Sculley speak at the Developer's Conference this spring knows that Apple is claiming to be ready to accept significantly lower margins to compete at the low end with a line of high-volume, low-cost Macs. These machines will all run System 7 and will not, unless Apple blows it badly, be feeble machines. They will be competitive in price and performance with 386 clones running Windows 3.0.
Multitasking, interapplication communication, and transparent network accesses will result in new kinds of applications. Large vendors will develop interlocking suites of applications rather than integrated packages. Smaller vendors will develop small, targeted applications. Utility developers will come up with enhancement products that ride on other products, sending messages to these products to get their work done. Although this last scenario sounds a little like spreadsheet macros, there is a difference in control. A spreadsheet macro runs within the spreadsheet application and is vendor-specific; these utility applications use other applications but are separate, clickable applications, and they should work with any applications that support the AppleEvents they generate.
Overall, Apple and Microsoft are saying, we'll see more, smaller applications.
Applications will, more and more, take on a tool aspect. What, exactly, does this mean? Like all the preceding predictions, this is just what Apple and Microsoft are telling developers. It would be an uncharitable exaggeration to say that the message Apple and Microsoft have for third-party developers is: "We'll talk to the users; you just talk to us." That's not what they're saying. Nevertheless, if the model of interprocess or interapplication communication that Apple and Microsoft are pushing comes fully into existence, it would be conceivable for a user to use a product without ever seeing its user interface.
Nobody is talking about what "more smaller applications" implies in the battle for computer store shelf space.
The differences between Windows 3 and System 7 are less important than the similarities. Apple has the better user interface, but it's not clear that that will make any difference to anyone but current Mac users. I can't see a Mac user converting happily to Windows, but the superiority of the Mac interface may not be great enough to affect buying decisions by present PC users or new computer buyers.
One significant difference between the two systems has to do with their file systems. Windows 3.0 still uses the short DOS file names and sometimes requires the user to deal with DOS path names. More objectlike file management tools are expected in the future, but right now the file handling has some kludgy aspects, and the DOS file names are unfriendly.
Mac's System 7 has a new file tracking system called "Alias Manager." On the surface, Alias Manager lets users create aliases, which are small files that refer to other files. Create several aliases for an application and you can store the aliases in different folders. Click on any of the aliases and the original application gets launched. The user doesn't have to worry about paths, because the Alias Manager keeps track of the original even if it or the aliases are moved or renamed.
The Alias Manager does more than permit aliasing of files, though. It is, as of System 7, the tool of choice for keeping track of files for any purpose. The standard file facility will use it, so any application using Standard File will get the benefits of Alias Manager from it. Alias Manager can be used for a wide variety of purposes. For one example, you put an alias for every data file on your hard disk into a folder called archive, then archive all the data files to floppy disks. Now when you click on the alias in the archive folder, the Alias Manager will prompt you to insert the appropriate diskette. Since the alias files themselves are very small, this lets you catalog all your diskettes. Aliasing volumes lets you kludge a simple network manager. The highlight of the Alias Manager session at the Developer's Conference was the simple Adventure game created on the desktop without any programming simply by aliasing files and folders.
The alias manager works by maintaining alias records in memory, and employs a whole battery of heuristics for identifying the target volume and the target. It is not easily confused by mere renaming or moving of the target, and will search across network zones and request mounting of volumes if necessary.
The discussion of Mac OS and Windows similarities and differences ought to lead to a discussion of porting strategies, or to a discussion of techniques for developing one program for both environments. A couple of years ago, Michael Brian Bentley wrote an interesting but intimidating book called The Viewport Technician (Scott, Foresman, 1988), about writing software for multiple windowing platforms. If it's getting easier to do that, and to end up with efficient programs, that would be news, but it's not clear that it is.
The porting problem has been addressed for two applications that will be bundled with Windows 3 and System 7: ToolBook and HyperCard. ToolBook, from Microsoft co-founder Paul Allen's company Asymmetrix, is a HyperCard-like software construction kit that requires Windows 3.0. ToolBook substitutes the page-in-book metaphor for HyperCard's card-in-stack metaphor and has some more concrete differences with HyperCard as well, but it is definitely intended to be the HyperCard equivalent for Windows. The latest version of HyperCard, 2.0, has some powerful features, but it still lacks some of the capabilities of ToolBook. The products are enough alike that Heizer Software has already announced a product that converts HyperCard stacks into ToolBook books. I haven't seen it yet.
I have seen ToolBook, and I've seen HyperCard 2.0. I reviewed ToolBook in Personal Workstation magazine recently, and will be writing more about it and HyperCard 2.0 here soon. What follows here is a look at how "the hypertext problem" is handled by ToolBook and HyperCard 2.0.
In my June column I talked about ways in which some people have used HyperCard and HyperTalk to do research into what could be called the hypertext problem. The problem is how to implement links in text, and there is as yet no consensus on the proper way to do it. After writing that column, I got my hands on HyperCard 2.0. Apple did a better job of leaving the developer's options open than I expected when I wrote that column, but still didn't provide everything the hypertext author might want. Meanwhile, Windows 3.0 came out, and Asymmetrix finally got to release its ToolBook. ToolBook runs under Windows 3.0 and is very comparable to HyperCard 2.0, but its approach to the hypertext problem differs fundamentally from HyperCard's.
The basic problem is this: Given a body of text, we want to be able to permit the reader to click on part of the text and have something happen. The "something" is usually the display of further information on the subject covered in the clicked-on text. This is information that doesn't fit into the linear structure of the running text: a definition, an optional detail, a digression. The further information may be displayed in any of a variety of ways: As a replacement text that takes the place of the clicked-on text, in a pop-up field overlayed on the clicked-on field, or in another body of text like the original body.
What I call the hypertext problem has two parts. The first part of the problem is how to indicate to the user what can be clicked on. In linear, printed text, there are established conventions (for example, parentheses and footnotes) for signalling a departure from strict linear structure. The footnote convention is the closest to what goes on in hypertext systems: We use a superscripted character to signal the existence of a link to a block of text at the foot of the current page. Among the techniques proposed for signalling hypertext links are superscripted characters, font changes, and boxes around text.
The other part of the hypertext problem involves that imprecise phrase, "permit the reader to click on parts of the text." What could a hypertext author mean by "part"? Must every link be tied to a single word? Footnotes in linear printed text often refer to entire sentences or paragraphs, although there is often no visual cue to suggest this. Can the clickable zones in a hypertext document overlap; that is, can you arrange that a sentence and a word in the sentence are each independently clickable, each invoking a different text link? Must clickable text be contiguous?
But this second part of the problem gets a little deeper than this. Does the link pertain to a particular instance of the text, to any appearance of that text in the text field, or to the nth word in the field, whatever it might be? For particular hypertext purposes, any of these might be desirable.
Case 1: Linking off a particular instance of a particular string. If you want the link object (the clickable text) to have substance, so that it remains a functioning link even when you move it somewhere else, you probably want something like this.
Case 2: Linking off any instance of a particular string. One excellent use of hypertext links is to provide definitions for technical terms in a document. The author does not want to force the reader to look at the definition the first time a particular term is used, but wants to allow the user to look up the word by clicking on any instance of the word in the document. The logic is that, for any particular use of the term, the user may be able to work out part of its meaning from context or outside knowledge, but may still need a definition later when the term is used in a different context. For this or a variety of other reasons, a full hypertext authoring system ought to allow the author to create a single link for all instances of a particular word or phrase.
Case 3: Linking off whatever string occupies a particular position. "Position" here refers to text position in a document, not pixel location on a screen. This approach allows the author to create links that depend on the structural features of a document. While this might not be useful for casual text, it might make sense for highly formalized documents, such as a block of assembly language code.
This is one way of slicing up some of the hypertext territory; these cases don't cover all the possibilities or represent the only way to segment the possibilities. I present them only to give some framework for looking at what ToolBook and HyperCard 2.0 actually do.
ToolBook has two main ways to show the clickable text to the user. First, the cursor changes when passing over this text. Second, there is a facility for making all the links visible. One convenient time to do this is when the cursor passes over the text field. This technique puts a box around each instance of linking text. These two techniques are well thought out. The cursor change does not use any element that might have another meaning in the text, such as italics, and is perfectly obvious if you're looking for it without being terribly intrusive if you're not. The boxing also does not use a feature that you would want to use for other text purposes. The boxes could clash with other framing devices, and could look ugly, but since it can be toggled on or off easily, this is not too serious. It's chiefly a peeking device for the user. You could also use font-style change to signal a link, since ToolBook lets you mix fonts and styles within a field, something that HyperCard formerly did not do.
ToolBook implements links via hotwords. A hotword is an object with properties, a script, and a place in the object hierarchy of ToolBook. You create a hotword by selecting text and choosing a menu option that makes that text a hotword. A hotword is a Case 1 link, a link off a specific instance of text. You can move or copy it and the link moves with it, because the link is defined by the script of the object. You can also edit the text of a hotword, although if you delete all its text, the object disappears.
In June, I documented some of the contortions that HyperCard stack developers went through to kludge some sort of hypertext facility in HyperCard. Because HyperCard and ToolBook both have programming languages, that sort of roll-your-own hypertext is always possible. There's probably no approach to hypertext that can't be implemented, some way or other, with each of these products. But hypertext systems have to have reasonable performance, and that means that the hypertext abilities of these products depend on the techniques built in. With Version 2.0, HyperCard has more hypertext capabilities built in than it formerly had.
In the area of showing the clickable text to the user, HyperCard puts all the decisions in the hands of the developer. Since there are different purposes for hypertext and the jury is still out on the user-interface decisions, this is generally the smart approach when you want to provide a flexible hypertext authoring system. But the flexibility Apple offers is chiefly in font and style change, which is a usurpation of the features of text for the purposes of hypertext. One option for marking links that would not be at all easy to implement in HyperCard is the ToolBook box, and messing with the cursor in HyperTalk could be problematic.
HyperCard implements links via field handlers. Text can be grouped, providing some of the capability of ToolBook's hotwords, and a field script can examine attributes of the clicked word, clicked line, or arbitrary grouping of clicked-on text. It's possible to test font or style and link off it, which is an interesting reversal: Instead of highlighting the link, you link off the highlight. HyperCard's field handler approach to hypertext means that you can key off any instance of a particular word or text with a single handler (Case 2). Case 3 links are also fairly directly supported by this scheme, but not Case 1 links.
Here are my closing thoughts on ToolBook, HyperCard, and the hypertext problem:
The indication of links: This is hypertext; i.e., more than text. To indicate the links, the author must add something to the text, and in particular to the visual appearance of the text. I'm not sure that it is widely understood that the indication of links raises spatial design problems. Writers have not in the past had to deal with such issues, but hypertext authors, because they are working in more than one dimension, do have to deal with spatial design in their documents. It is up to the hypertext author to create and indicate links without making the document ugly and unreadable.
What to link from: Between the two of them, HyperCard and ToolBook cover the linking techniques I somewhat arbitrarily defined here. In my opinion, both of them ought to provide the tools for creating any of the types of links I've described, or any reasonable kind of link anybody might come up with, if they are to serve as general hypertext authoring systems. Neither, of course, is being marketed as a general hypertext authoring system, but many people will be building hypertext documents with them. And until someone demonstrates an unequivocally "best" way to implement hypertext links, the hypertext author should not be constrained to one or a few techniques.
Win 3 vs. DOS
1. The users of dedicated one-application PC-class machines that do their respective jobs well. If such a user sees no need to upgrade an 8086-class machine running DOS and such an application, then the user will probably not make the significant investment required. Some such applications, despite Windows 3's support for non-Windows applications, will need an upgrade, and some perfectly functional applications that happen to be no longer supported won't be getting any upgrade.
2. The impecunious. Also behind the veil. To make use of Windows 3.0, in particular to be able to use multitasking, the minimum configuration is a 286 with 2 Mbyte of memory and EGA. Any PC owner who doesn't have this hardware has the choice of buying it or doing without Windows. Some will do without, and like homeless people in the census, will drop out of the demographics.
3. Users of embedded systems. Last fall, Microsoft released ROM Executable MS-DOS v.3.22, a true DOS in ROM. Datalight and Digital Research both also sell ROMable DOS clones. These users probably don't need windows and icons.
4. Engineers and scientists. There should be no compelling reason for anyone in this market to buy or hang on to a raw DOS machine as a CPU; if there is in a year or two, it will mean that Windows developers have not been seeing all the market opportunities. But a raw-DOS machine as a device is another thing altogether. One can easily imagine an array of DOS machines controlling instruments, with a Windows box standing between all of them and the researcher user.
Win 3 vs. other DOS Extenders
Win 3 vs. Win 2
System 7 vs. System 6
Win 3 vs. System 7
ToolBook vs. HyperCard
ToolBook and the Hypertext Problem
HyperCard 2.0 and the Hypertext Problem