The Humane Interface, The Deadline

This article appears in slightly different form in the May/June 2000 issue of IEEE Micro © 2000 IEEE.

Doing It Right

This time I look at two books that aim at making life easier for humans. The first tells how to make computer interfaces that humans can use. The second uses fiction to explore the ways humans can work together to produce good software.

The Humane Interface -- New Directions for Designing Interactive Systems by Jef Raskin (Addison-Wesley, Reading MA, 2000, 254pp, www.aw.com, ISBN 0-201-37937-6, $24.95)

[NOTE: Jef Raskin died shortly after this review appeared.] Jef Raskin's best known work is the Macintosh. That product brought about a revolution in computer interface design, but yesterday's revolutionary idea has become today's entrenched paradigm. Raskin has moved on. In this book he shows the flaws of the desktop-and-application approach and explains how it can evolve into something much easier for humans to use.

Raskin centers his ideal system on your content -- not named files in a hierarchy of directories, but just content. You can have files and directories, but only if you decide to mark their boundaries in an otherwise undifferentiated sea of content.

Rather than applications to process your content, Raskin gives you individual commands. Thus, rather than buying Photoshop and Word, you buy individual (or perhaps groups of) image processing commands from Adobe and text manipulation commands from Microsoft. You can use the text commands to add text to images, and you can use the image processing commands to manipulate the images in your printed documents.

This sounds like component software or Unix filters. It's not a radically new idea, but Raskin arrives at it from a different direction. He begins by asking how he can make interfaces that humans can learn easily and use efficiently. To answer that question, he looks at the equipment on both sides of that interface: the computer and the human.

Many people have studied human cognition, but few have applied what we know about the capabilities and limitations of humans to the problems of interface design. To do this, Raskin applies techniques and observations that the cognitive psychologist Bernard J. Baars discusses in his book A Cognitive Theory of Consciousness (Cambridge, 1988).

Raskin takes a fundamental principle from Baars' work: humans can accomplish many tasks in parallel, but can only pay attention to one at a time. We all know this, but many people design interfaces as if it weren't true. Raskin gives examples of this error -- taken from widely used software products.

The fact that we have at most one locus of attention, while most tasks we perform with computers require us to accomplish a variety of subtasks in parallel, leads to the principle of automaticity: the more we can do without thinking, the more efficient we are. Anything that makes us think about what we already know how to do slows us down. This principle leads to the following conclusions:

• Interfaces should be modeless - the way to accomplish a task should be the same under all circumstances.
  
• Interfaces that change in an attempt to adapt to your actions can actually slow you down.

Raskin elaborates on these points with many examples. Some of the examples are surprising. They show the inefficiency of widely practiced interface design techniques.

Raskin turns a lot of attention to the problems of navigation. He likens current navigation methods in applications, operating systems, and the web to trying to find your way around a maze with only the ground-level view of where you are and where you've been. He proposes a two-prong approach to improving this situation: a zooming video camera metaphor for finding your way around a pictorial representation of your content, and a text-search facility that differs sharply from the most commonly used search facilities.

Raskin also applies quantitative methods to interface design. He uses the goals, objects, methods, and selection rules (GOMS) technique developed by Stuart Card, Thomas Moran, and Allen Newell to measure the relative efficiencies of alternative interfaces.

I haven't come near to covering all of the topics Raskin addresses in this marvelous book -- icons, programming environments, documentation, the number of buttons on a mouse, and even cables and connectors.

If you have anything to do with designing any aspect of computer systems for use by humans, you should read this book. People will be talking about it for a long time.

The Deadline -- A Novel about Project Management by Tom DeMarco (Dorset 

House, New York NY, 1997, 320pp, www.dorsethouse.com, ISBN 0-932633-39-0, 

$24.95) 

In 1964 I knew assembly language for the IBM 650, and I had recently learned Fortran II.  I sat down with the IBM Cobol manuals to see what that language was all about.  It took me very little time to decide that it was not a language I wanted to program in.  I don't regret this 

decision, but it shut me out of the world in which Tom DeMarco was later to flourish.  

Fifteen years and many languages later, I wound up (briefly) advising a large California bank, and the book that bridged the gap between my way of thinking and theirs was Tom DeMarco's Structured Analysis and System Specification (Prentice Hall, 1979).  I still remember how exciting it was to use DeMarco's methods to produce diagrams that represented the elements of the bank's proposed application.  The bank, however, was less concerned with the quality of the information than with the fact that my "work product" was drawn in pencil on D-size graph paper.  We parted company.  They later went out of business.  

In 1979, DeMarco was insightful.  Today he is wise.  Then he was concerned with how software modules work together.  Today he focuses on how people work together.  His book is fiction, but it teaches many real lessons about project management and team building.  

Here is the essence of the plot.  Mr.  Tompkins, a middle-aged middle manager, is laid off from a thinly disguised AT&T, kidnapped by a beautiful and resourceful industrial spy, and spirited away to Moravia, a post-Communist third world country somewhere on the Adriatic coast.  A thinly disguised Bill Gates has acquired this country secretly in a stock swap and has decided to help it dominate the shrink-wrap software business by producing knockoffs of Quicken, PhotoShop, Quark XPress, PageMill, Painter, and Lotus Notes, and giving them away.  

Tompkins takes the job of managing this development.  Because Moravia has far more programmers than required to develop these six products, Tompkins sets up three parallel projects for each product, turning the whole operation into a project management laboratory.  He gets carte blanche from Bill, and everything seems to be going smoothly.  

Just as Thompkins is beginning to feel complacent, Bill returns to the States to work on his house, leaving the sinister bean counter Allair Belok in charge.  Belok embodies every stupid, unscrupulous, bullying executive you've ever worked for.  Sadly, his tactics seem true to life. They certainly rang a few bells for me.  Thompkins must face arbitrarily shortened schedules, merging of his parallel projects, and forced overtime.  On top of this, he must contend with the well meaning purveyors of process improvement, whom Belok sics on him with even more unreasonable goals.  

Thompkins is not alone in his struggles, however.  Belinda Binda, the world's greatest project manager, burnt out and now a bag lady, agrees to help Thompkins staff his projects.  So does Ex-general Markov, former head of software development for the Moravian army.  Lahksa, the beautiful resourceful spy, runs around the world sending Thompkins consultants for 

brief visits.  The reclusive Aristotle Keneros, Moravia's first programmer, helps to divert the process improvement folks, and teaches Thompkins the importance of debugging the decomposition and interfaces during the design phase.  

That's it for the plot.  DeMarco patterned Mr. Thompkins after George Gamow's character of the same name.  Gamow had a wonderful ability to explain physics and mathematics with stories.  In One Two Three .  .  .  Infinity, one of my favorite books when I was in high school, he explains complex numbers with a story about buried treasure.  Mr. Thompkins is a 

bank clerk who goes to lectures on science, falls asleep, and has wonderful dreams that make the concepts clear.  

DeMarco has followed that tradition admirably.  His chapters are little vignettes of project management.  A problem arises, a consultant shows up to help solve the problem, and Thompkins adds a few aphorisms to his journal.  According to DeMarco, most of these aphorisms come from his own journal and represent lessons he learned the hard way.  

Here are a few of the aphorisms that I especially like: 

• Four Essentials of Good Management: Get the right people, match them to the right jobs, keep them motivated, and help their teams to jell and stay jelled. (All the rest is administrivia.)
  
• There are infinitely many ways to lose a day  . . . but not even one way to get one back.
  
• People under pressure don't think any faster.
  
• It's not what you don't know that kills you  . . . it's what you know that isn't so.

The last one is an old proverb, but DeMarco applies it to one of the sacred cows of software development, code inspection.  

I've discussed the more general aspects of DeMarco's book here, but parts of it get pretty technical -- though rarely enough to bog down the story.  DeMarco believes in metrics and modeling as project management tools, and several of his vignettes show surprising ways to use those tools.  

At the end of the book, Thompkins gives away his journal, saying "I can never imagine opening it again.  I don't need to.  I carry those hundred and one principles everywhere I go. They're carved into my hide." The book is a crash course in project management and team building.  If you do any sort of technical development, you should read it and absorb it.  

Windows 2000

This article appears in slightly different form in the March/April 2000 issue of IEEE Micro © 2000 IEEE.

On February 17, 2000, I attended Bill Gates' kickoff of Windows 2000. I've been using beta versions for a year, but now it's official, so I can talk about it.

The kickoff was an extravagant production. Television actors provided glamour as they struggled through ghastly scripts. The captain of the starship Enterprise, for example, came on stage to complain when Gates used the word enterprise to describe his new product's target applications. The great rock guitarist Carlos Santana and his band closed the proceedings, while an army of reporters and publicists fiddled with their laptops and cell phones and pretended to enjoy the music.

Unlike Santana, the kickoff show may never win a Grammy, but the demonstrations of features and performance inspired awe among the attendees. Gates trotted out benchmarks that put Windows 2000 price/performance ahead of all of Microsoft's competitors -- and well beyond that of prior Microsoft systems. Even more impressive were the demonstrations of dynamic reconfiguration and load balancing in multiprocessor clusters. An operator at a console put machines into and out of service by dragging and dropping icons, and processor usage gauges immediately reflected the automatic rebalancing. Other demos showed how easily a user with a laptop can synchronize with a server and how effectively an administrator can control and allocate resources with Active Directory (see below).

The most impressive measurements that Gates announced were of how infrequently the systems crash. Windows 2000 seems, at least in these tests, to be much more reliable and fault tolerant than its predecessors. My own experience (see below) hasn't been nearly as good as the studies Gates reported, but I test lots of software, and I reconfigure often -- all without the benefit of a trained system administrator.

The Operating System

Windows 2000 is a family of operating systems, all targeted at business users. It does not, as you might have thought from the name, replace Windows 98. It is instead an evolution of Windows NT 4. In fact, the earliest beta versions I received were called Windows NT 5.

The bottom of the line is Windows 2000 Professional, which is aimed at business desktops and laptops and at high-end workstations. There is nothing to prevent you from using this product at home, of course, but in seeking to improve security, Microsoft has removed hooks into the hardware that many video games depend on. Drivers for many older devices have also had difficulty migrating to Windows 2000, which is another obstacle to its home use.

The next member of the family is Windows 2000 Server. It's not very different from Professional, and many users will prefer it. Microsoft intends it for use as a file, printer, communications, or web server.

For high-end server applications, Microsoft provides Windows 2000 Advanced Server. This version supports huge memories and symmetric multiprocessor (SMP) configurations. It supports clustering and rolling upgrades. You might use a cluster of Advanced Server machines to support a high-traffic website.

The fourth member of the family is Windows 2000 Datacenter Server. When Microsoft releases it later this year, it will do what the other family members do, but it will support larger memories and more multiprocessors.

I quickly decided that I needed Windows 2000 Server for the tasks I want to run, so that's the only version I have direct experience with. I'm happy with it, because its user interface is much more that of like Windows 98 than Windows NT 4, and it's easier to configure unusual network configurations. I connect my Windows 2000 Server machine to the Internet via a digital subscriber line (DSL). I have a local Ethernet, and I use the Windows 2000 Server as a gateway to give the other machines Internet access. At the same time I connect the Windows 2000 Server as a client to an enterprise intranet via virtual private networking (VPN). This configuration may have been possible with Windows NT 4, but try as I might, I could never make it work.

I won't run through all of the features of Windows 2000. You can find a summary on the Microsoft website. If you use Windows NT 4, or even Windows 98 with standard business software and devices, you'll find Windows 2000 a significantly more capable, usable and reliable product.

Books

Windows 2000 will spawn a huge supply of third party books, and many have appeared already. I look at four good ones.

Active Directory for Dummies by Marcia Loughry (IDG, www.idgbooks.com, 2000, 402pp plus CD, ISBN 0-7645-0659-5, $24.99)

Windows 2000 Registry for Dummies by Glenn Weadock (IDG, www.idgbooks.com, 2000, 378pp plus CD, ISBN 0-7645-0489-4, $24.99)

It may seem incongruous to talk about anything as complex as Windows 2000 as being for dummies, but these two books, and the one that I discuss under security (below), adhere to the same formula that has made the dummies series such a runaway success. The authors know their audiences, and they talk to them as intelligent people who are just beginning to learn the subjects. While they must assume a certain degree of sophistication and general background, the authors explain everything about the topics of the books.

In addition to targeting their audiences accurately and not taking anything for granted, the dummies books enhance communication in other widely known but less widely used ways. Their page layouts, font selection, and clear illustrations draw readers in. The icons for warnings, tips, technical details, and other aspects of the text are consistent from book to book, so the more dummies books you read, the easier it is to find the information you're looking for. The informal and slightly humorous tone of the books helps establish a rapport between author and reader, despite the highly formulaic structure.

Another great strength of the dummies books is that they are task oriented. They identify the tasks you're likely to wish to perform, and they show you how to perform them. Yet the authors don't restrict themselves to a cookbook approach. With each task they give you the background to understand what you're doing and why you're doing it. This technique is sometimes called just in time learning, and studies show that it is an effective way to learn.

Blatantly stealing Apple's famous catch phrase, the dummies books proclaim themselves a reference for the rest of us. And in fact, in addition to their tutorial elements, they contain many aspects of good reference works -- starting in every case with an excellent index. The Active Directory book also has several helpful appendixes.

The registry book contains information every Windows 2000 user should know about. The registry is an evolution of the registries of Windows NT 4 and Windows 98. If those were always a mystery to you, read this book now.

The Active Directory book may be more interesting to administrators than to average users. Active Directory centralizes resource allocation and control. It is a database of configuration information, some of which would have been stored in the registry under Windows NT 4. The book leads you through the daunting task of setting up directory services for an enterprise. 

Given the important role Windows 2000 will play over the next few years, I recommend that you spend a few hours reading these books and getting the ideas straight now. That knowledge is bound to pay off as time goes by. 

Inside Windows 2000 Server by William Boswell (New Riders, www.newriders.com, 2000, 1496pp, ISBN 1-56205-929-7, $49.99)

Boswell's book is very different from the dummies books. It contains a great deal more detail, but you may have to dig harder to get it out. It is definitely more of a reference work than a tutorial. Although it contains many how-to procedures, it is not fundamentally task oriented.

The book has an attractive and readable layout, and its binding allows it to lie flat when open to almost any of its 1500 pages. It is comprehensive and clearly written. While I can't attest to the accuracy of everything in it, it does list three technical reviewers.

If you're a system administrator, you need this kind of reference book. This one seems like a good investment.

 

Security

I became a regular Internet user in the early 1980s, but I never worried much about security until recently. This was not because the threats weren't real. I remember reading a congressional report on databases and invasion of privacy more than 30 years ago, and the threats were scary then. And if you want to see how that aspect of the problem has developed, read Simson Garfinkel's new book Database Nation (O'Reily, www.oreilly.com, 2000, ISBN 1-56592-653-6, $24.95).

While I think the kinds of threats that Garfinkel describes are more ominous, I'm concerned here with the kinds of threats you can reasonably do something about on your own Windows 2000 Server machine, namely, the threats of unauthorized access to your machine and to other machines on the networks your machine connects to.

Windows 2000 Server Security for Dummies by Paul Sanna (IDG, www.idgbooks.com, 2000, 378pp plus CD, ISBN 0-7645-0470-3, $24.99)

If you're a system administrator, this book will lead you through the basic steps you can take to protect your system without totally disconnecting it from the world. Like the dummies books I describe above, this book leads you through the tasks you need to accomplish, supplying you at each stage with the information you need to understand the procedure you're following.

If you're responsible for the security of a Windows 2000 Server system, reading this book is a really good idea.

I found another excellent resource for securing Windows-based systems (not necessarily Windows 2000). This is the website of Gibson Research of Laguna Hills, California (http://grc.com). When you go to this site and the first thing you see is your name on the screen, you know you have work to do. Steve Gibson leads you through some simple steps that will greatly reduce your vulnerability.

One of Gibson's recommendations is to use the Zone Alarm 2.0 personal firewall, which you can obtain free from Zonelabs.com of San Francisco, California. I downloaded this product and have been using it more or less successfully. Zonelabs does not certify the product for the configuration I'm running, and so I don't blame them completely for the occasional blue screens of death that occur when the program fails to handle kernel mode exceptions properly.

Using Zone Alarm has been very revealing. It quite regularly reports probes from unauthorized IP addresses. I'm still tweaking the settings and learning to use it effectively, but I'm happy to have it running, despite the occasional crashes. It's certainly a product worth investigating, and you can't beat the price.

Happy New Year 2000

This article appears in slightly different form in the January/February 2000 issue of IEEE Micro © 2000 IEEE.

A Look Back

I looked back at my first columns of previous years to see if I could spot trends. It's an interesting progression. I'll let you decide about the trends.

In 1988 I complained about the way Word 3.01 implemented styles. I also reviewed books about Word Perfect and microcomputer busses.

In 1990 I reviewed a book about the problems of Japanese language computing. Most of those problems have evaporated in the intervening 10 years.

In 1992 I wrote about upgrading my Macintosh SE/30 to 8 megabytes of main memory and installing the System 7 operating system.

In 1993 I compared Word 5.1 for the Macintosh with Word for Windows 2.0, and reviewed MKS Toolkit 4.1 for DOS and books about debugging, Windows NT, friendly software design, and a realtime kernel.

In 1994 I reviewed some Macintosh utilities and a book about the Intel Pentium architecture.

In 1995 I reviewed four books about the Internet and the TCP/IP protocol.

In 1996 I reviewed Bill Gates' The Road Ahead, a book about the coming information highway. He suggests that you view mergers of ISPs and content providers skeptically. I wonder what he thinks of AOL's acquisition of Time Warner.

In 1997 I wrote about object-relational databases and reviewed a book about how Microsoft conducts its business.

In 1998 I wrote about how Apple was beginning to make a comeback, and I reviewed three interesting books about how technology will affect the society of the future.

In 1999 I wrote about Apple's G3 and iMac computers, reviewed a four-volume handbook of programming languages, and talked about my difficulties getting the Windows NT5 beta software to run on my PC.

This year I'm still struggling with Windows NT5 (now they call it Windows 2000 Server) beta software, but it's a lot better. At the moment I'm running Build 2195, and I'm quite happy with it. I'll say more when I see the released product.

Practical Programming Advice

I've read many books about programming in the last 35 years, and from time to time I review especially good ones. In the past the good ones have been few and far between, but that seems to be changing. In my Nov/Dec 1999 column, I reviewed Extreme Programming Explained by Kent Beck. This time I was delighted to discover another excellent programming book from the same publisher. 

The Pragmatic Programmer -- From Journeyman to Master by Andrew Hunt and David Thomas (Addison-Wesley, Reading MA, 1999, 321pp, ISBN 0-201-61622-X, $34.95)

Andrew Hunt and David Thomas are software consultants doing business as The Pragmatic Programmers (www.pragmaticprogrammer.com). They have produced an outstanding book about programming, and many of the insights they offer apply to other engineering disciplines as well.

In August 1993 I reviewed Steve McConnell's Code Complete (Microsoft, 1993), which assembles in one thick book everything that a journeyman programmer should know. Hunt and Thomas, in a thin book, give you a glimpse of the kind of thinking that leads to the next step -- mastery of the craft of programming. More broadly, if you participate in technological innovation and have access to computer-based tools, you can probably apply many pragmatic programming principles to your own work.

In his foreword to the book, Ward Cunningham says:

Imagine that you are sitting in a meeting . . . thinking that you would rather be programming. Dave and Andy would be thinking about why they were having the meeting, wondering if they could do something to take the place of the meeting, and deciding if that something could be automated so that the work of the meeting just happens in the future. Then they would do it.

To follow an approach like this, you must always be thinking about what you are doing, and you must be so comfortable with your tools that you can take the step from thought to reality.

Hunt and Thomas talk about tools and how to be comfortable with them. They focus strongly on basics like using plain text, command shells, scripting languages, and a good text editor. The main thrust of their book, however, is about attitude -- an approach to life. This could have led them to a programming version of the Tao Te Ching, but instead they have stayed true to their title. They find practical examples to illustrate everything they say.

Much of what Hunt and Thomas say in this book is simple folk wisdom -- care about your work, take responsibility, know when to stop, and so forth. Yet when I look at the whole package, with each homily applied to specific technical contexts, I find the book inspiring. I enjoy the affirmation of many things I've believed for years, and it moves me to return to paths I've strayed from.

The late Rudolph Langer, a great programmer and for many years the editor-in-chief of Sybex, used to collect books of aphorisms. He would have loved the way the authors boiled down much of their advice into 70 catch phrases. For example, DRY - don't repeat yourself, summarizes a deep and important discussion of how to eliminate duplication and increase orthogonality. Configure, don't integrate summarizes an important insight into how to use metadata to increase the reliability and flexibility of your systems.

When I programmed the PDP-8, I treasured a three-fold instruction card that fit in my shirt pocket. It was the only reference I ever needed. Hunt and Thomas have not matched that size target, but their book comes with a quick reference card. It contains their 70 aphorisms (they call them tips) and 11 checklists. For example, the Law of Demeter for Functions checklist says

An object's methods should call only methods belonging to:

• Itself
  
• Any parameters passed in
  
• Objects it creates
  
• Component objects

The authors' discussion of this law occurs in a chapter on flexibility. It's a good example of how they move easily between generalities and specifics.

I could go on and on about this book -- the discussions of projects, the exercises and answers, the references, the bibliography and resource lists. It hangs together and communicates its message extremely well. And not surprisingly, the authors applied many of the methods and philosophy they describe to producing it.

If you're a programmer, or even if you're in a seemingly unrelated engineering discipline, Hunt and Thomas have a lot to say to you. Buy their book. Read it. Become a pragmatic programmer.

Extreme Programming, Cathedral and the Bazaar

This article appears in slightly different form in the November/December 1999 issue of IEEE Micro © 1999 IEEE.

Changes

In my final column of the 1900s I look at two books that challenge twentieth century ideas about developing software and making money from it.

Extreme Programming Explained by Kent Beck (Addison-Wesley, 2000, 212pp, ISBN 0-201-61641-6, www.awl.com, $29.95)

Kent Beck knows how to design and implement software. He advocated using design patterns years before most people had heard of them, and he pioneered CRC (classes, responsibility, collaboration) cards, a low-overhead design methodology.

Programming lies between art and engineering. Too much influence from either can make it an economically unprofitable activity. Isolated artists, working from an inner vision, can produce brilliant work, often quickly. But it's a rare artist whose inner vision coincides with what users want.

Engineering, on the other hand, is thorough and methodical. Engineers insist on complete functional specifications. They devise comprehensive testing regimens, prepare and verify detailed design plans, then build the product. They constantly review each other's work and monitor their adherence to the plan.

This style of engineering requires long product cycles, especially when measured by Internet time. Even a thorough analysis phase usually fails to produce a functional specification that perfectly foresees and communicates what end users need and how they will use the product. This leads to changes, which often produce delays and weaken the overall design.

Extreme programming (EP) adopts the proven techniques that make engineering robust but replaces the long product cycles. An EP project compresses the cycle of specification, design, implementation, and testing into a time period of a week or so. Within that period it uses smaller cycles -- some as short as a few minutes. In this way it replaces the ballistic approach (that is, plan the whole trajectory, then blast off) with frequent course corrections based on feedback.

Beck calls his style of programming extreme because he pushes accepted techniques and principles as far as he can. For example, he requires two programmers to participate in any programming session, leading to non-stop code reviews. Programmers write tests before they write code, and they perform unit testing every time they change anything.

Beck integrates and tests the entire system many times per day. Customers (he requires one to be part of the team) continually test the system's functionality.

Beck clearly separates the roles of customers, management, and developers in defining the functionality and dates of releases. He requires releases to be as small as possible, consisting of just the most important new features. Customers receive new capabilities every few weeks. As they use them, they discover important possibilities or gaps, and these help define the content of subsequent releases.

Because the project meanders in this way, EP requires each piece of software to be the simplest that supports the current requirement. It avoids designing on speculation. As a result EP calls for frequent redesign or refactoring. In other design methodologies, redesigning something that already works is anathema. EP's frequent testing makes this a low-risk activity. EP programmers who see ways to simplify the design or eliminate duplication are obliged to do so. Anyone can modify any code at any time -- no matter who wrote it.

Because communication is such an important part of an EP project, Beck requires the project to have a single overarching metaphor. He bases all project jargon on the metaphor, and he uses it for everything from talking with customers to deciding how the code should work.

Beck's book is easy to read. He explains the principles well, and he doesn't bring in a lot of unnecessary detail. You can read it in a few hours. Then you'll know what EP is and how it works, but you won't really know how to do it. For that, Beck advises, "you will have to go online, talk to some of the coaches mentioned here, wait for the how-to books to follow, or just make up your own version."

If your programming projects aren't proceeding as effectively as you'd like, read this book. You'll probably find something you can use.

The Cathedral and the Bazaar by Eric S. Raymond (O'Reilly, Sebastopol CA, 1999, 280pp, ISBN 1-56592-724-9, www.oreilly.com, $19.95)

In the summer of 1968 the company I worked for hired two high school students to modify Digital's PDP-8 assembler. They moved the symbol table from core memory to disk, maintained it in alphabetical order, and replaced the linear search with a binary search. In the early 1970s I modified programs from DEC, Hewlett-Packard, Data General, and Varian. All of those companies provided source code. Nowadays, few companies do so.

Eric Raymond has been producing open source code for about fifteen years. Much of it is still popular today. Nonetheless, Linus Torvald's Linux project went against much of what Raymond thought he knew. His efforts to understand the Linux model and his experiences leading the Fetchmail project led to the essays in this book. They contain interesting technical and sociological observations of the open source process, and they contain aphorisms embodying the lessons Raymond learned from the Fetchmail project. My favorites are:

• Release early. Release often. And listen to your users.
  
• Smart data structures and dumb code works a lot better than the other way around.

The first of these leads to a style similar to Beck's extreme programming. It responds to the impatience and the parallelism of the Internet culture.

I've heard the second in many forms over the years. Raymond cites Brooks's Mythical Man Month (1969) for one version. I remember the stress Butler Lampson placed on this point in his 1968 lectures on operating systems at UC Berkeley. It's so important, and so often ignored.

If Raymond had stopped at the observations and the aphorisms, this would have been an excellent book. He goes on, however, to frame broader general principles. They seem plausible, but he presents many of them as facts and mixes them with the other material. I think this detracts from the clarity and value of the book.

Despite the quibble, you should read this book. It provides useful insights into the open source movement and its place in the future of software development.

Pot Pourri

This article appears in slightly different form in the September/October 1999 issue of IEEE Micro © 1999 IEEE.

This time I look at a loosely related collection of interesting ideas. Jini is a new technology from Sun. It aims at enabling you to network anything, anytime, anywhere. Java is a programming language and a platform. It has matured considerably since I first wrote about it (Micro Review, June, 1996). WinWriters is a support organization for online help developers. They recently put on a conference about JavaHelp. Adobe Acrobat is the principal tool for working with Adobe's portable document format (PDF).

Jini

Many people have recognized the potential of large numbers of mildly intelligent communicating  devices. Devices as disparate as switches, lights, cameras, sensors, printers, vending machines, and large relational databases might all benefit from exchanging information. In the 1980s, Micro's editor-in-chief, Ken Sakamura, headed the TRON Project, a large cooperative effort based on this idea.

Java's roots are in embedded systems and consumer electronics. From the first, it was also intimately associated with networking. Jini brings these threads together to provide a model for networking arbitrary devices.

Many systems for distributed computing run afoul of the seven fallacious assumptions identified by computer scientist Peter Deutsch:

• The network is reliable.
  
• Latency is zero.
  
• Bandwidth is infinite.
  
• The network is secure.
  
• Topology doesn't change.
  
• There is one administrator.
  
• Transport cost is zero.
  

Jini provides explicit support for the difficulties and failure modes that these assumptions try to hide. The result is a powerful mechanism built on a few simple ideas and protocols. Because it builds on Java, Jini leads developers to this mechanism along a short, familiar path.

Here is a slightly oversimplified explanation of what Jini is and how it works. It begins when someone starts a lookup service, which is essentially the only piece of system administration required. Devices that have services to offer can register with a nearby lookup service when they connect to a network. They don't need to know its location in advance.

Registering means leasing space on the lookup service for a small proxy program to be downloaded to devices seeking services of the registered provider's type. The proxy knows how to communicate with the provider and implements a standard interface for services of that type.

Jini has a concept of remote events. It is a simple model that separates the event mechanism from event policy, leaving the latter to individual applications. It facilitates the use of third-party event listening services, and it supports Jini transactions. Transactions are the key to designing robust, reliable distributed applications.

This brief overview of Jini doesn't capture all of the details--even all of the major details. I hope it gives you the general idea.

Core Jini by W. Keith Edwards (Prentice Hall, 1999, 812pp, www.phptr.com, ISBN 0-13-014469-X, $49.99)

Keith Edwards is a researcher at Xerox PARC, where he works on distributed object technology and user interfaces for information management. He was an early Jini user -- long before its first public release. He understands the underlying issues and philosophy, and he explains them clearly in this book.

Edwards' book is especially valuable, because he combines an intelligent discussion of the underlying concepts with a clear explanation of how to perform the basic tasks. He understands what developers need to know, and he explains the material patiently, using complete, working examples to illustrate the points.

Edwards sees Jini as resting on five key concepts: discovery, lookup, leasing, remote events, and transactions. He explains these concepts lucidly and shows how they fit together to make a complete workable system. If you read this explanation carefully, you will understand Jini at a significant and useful level.

On one hand, I'd like to say that everyone should read this book. This is surely true of the first 120 pages, which cover the conceptual material. On the other hand, this is a highly technical book. If you're not a working Java programmer, most of the book will make difficult reading. With that caveat, I recommend it highly.

Java

Java Power Reference by David Flanagan (O'Reilly, 1999, CD-ROM, www.oreilly.com, ISBN 1-56592-589-0, $19.95)

The Java Power Reference is a CD-based top-level quick reference for the Java 2 platform. It provides useful functionality not available elsewhere, but it falls short of what Flanagan could have done with the material he has already produced for his books.

Flanagan's Java in a Nutshell (see Micro Review, June 1996) has grown into a series of four books, making quick access and effective cross referencing difficult. The material cries out for an online approach. Rather than taking this approach, Flanagan has decided to leave the detailed material to the books. He says:

So, while Java in a Nutshell contains a paragraph or two about each class and interface, the Java Power Reference contains a paragraph or two about each package.

At 107 megabytes, the Java Power Reference falls far short of filling the CD. I think Flanagan would do his users a service by copying those extra paragraphs from the books onto the CD. In fact, I'll be surprised if he doesn't do something like that after he brings all the nutshell books up to date.

The best thing about the Java Power Reference is that it gives you an overview of the Java 2 platform and lets you explore it. You can find a lot of tantalizing packages, but you won't find many words about what they do and how the designers intended you to use them.

The other important thing the Java Power Reference gives you is a search capability. You can search for any package, class, method, or field name, without having to hunt through the hierarchy for it. You can even perform wildcard searches for names you're not sure of.

The Java Power Reference is a useful supplement to the online documentation that comes with the JDK distribution. It's not everything it could be, but it's well worth the price.

WinWriters

The WinWriters organization (www.winwriters.com), based in Seattle WA, specializes in training and supporting developers of online help systems. Their principal, Joe Welinske, is an expert in the field and a good organizer. In May, 1999, I attended their JumpStart Conference for JavaHelp Technology.

JavaHelp is one of many HTML-based formats for online help. Because the JavaHelp API is based on the Java foundation classes (JFC), the JavaHelp format is well suited to providing online help for Java programs. It provides many excellent capabilities not available in other formats.

All the major vendors of online help authoring tools have announced support for JavaHelp, but Sun is not supporting the JavaHelp API aggressively. You can find the JavaHelp page on the java.sun.com website if you already know the URL, but the main pages have no obvious links to it. The field of HTML-based online help methodologies is extremely competitive, so JavaHelp is unlikely to succeed if Sun's support remains lukewarm.

Despite JavaHelp's uncertain future, I'm glad I attended the JumpStart Conference. WinWriters put together a focused series of presentations that covered the material. They integrated vendor presentations with talks by relatively impartial (and highly regarded) online help developers. They accommodated questions, but kept the program on schedule and deflected the occasional "I just want to hear myself talk" contributions.

WinWriters puts on many conferences of this sort. I haven't attended others, but I have heard only good reports of them. The WinWriters website contains summaries and supplemental information from recent ones. Be sure to visit it if you are interested in online help systems.

Adobe Acrobat

Adobe's PostScript language created the desktop publishing industry. It decoupled publishing applications from printer drivers by providing a universal output format. It made WYSIWYG possible by carrying the same output format to display screens.

While PostScript works well for communicating between computers and printing devices, PostScript files are not very good for document storage and interchange, because they are large and difficult to manipulate. Adobe's portable document format (PDF) addresses this situation. Adobe Acrobat, and its companion program, the distiller, convert PostScript files into much smaller PDF files. The freely available PDF viewer allows anyone to view or print PDF files.

These programs have been evolving for several years, and Adobe has just brought out version 4 in a convenient package.

Adobe Acrobat 4 (Adobe Systems, www.adobe.com, $99 upgrade)

Because the PDF reader is freely available and many websites provide some documents in PDF, I assume you are generally aware of the features and capabilities of version 3. Version 4 provides substantial improvements in many areas.

Acrobat 4 facilitates collaborative review of PDF documents through its support of annotations and digital signatures. PDF places annotations in separate layers on top of the original, so you can always see and recover the original. It lets you view and manipulate annotations in a number of ways. Acrobat 4 includes many annotation tools (pencil, clip art, highlighter, and so forth) that were not available in earlier versions.

Acrobat 4 also provides better and clearer options for font bundling and file compression. These were sources of problems with prior versions. It is increasingly likely that high-end print shops will accept PDF 4 documents as input. Adobe provides a mechanism for print shops to specify packages of options to allow you to prepare PDF files to their specifications.

You can convert documents to PDF much more easily than with earlier versions. In many cases you can simply drag documents to the distiller icon. Microsoft Office 2000 programs can all write PDF directly.

One of my favorite features is Acrobat's ability to capture individual HTML pages or entire websites. The resulting document contains all of the links in the original but resides in a single file. You can view or print it in formatted pages, without the usual awkward breaks of printed HTML pages.

Acrobat 4 is a significant improvement over Acrobat 3. It will make many people's lives a lot easier. If you haven't got it yet, rush out and buy it. It's a real winner.

Dynamics in Document Design. WebWorks Publisher

This article appears in slightly different form in the July/August 1999 issue of IEEE Micro © 1999 IEEE.

This time I review a book and a software package. The book sets out to help you create documents that are "less ugly and less confusing." The software package helps you produce printed and online hypertext documents from a single source. Its documentation could have benefited from the precepts in the book.   

Documents for Readers

Dynamics in Document Design by Karen A. Schriver (Wiley, New York NY, 1997, 592pp, ISBN 0-471-30636-3, $44.99)

Karen Schriver holds a PhD degree in rhetoric and document design from Carnegie Mellon University. She is a former professor and a former co-director of CMU's late lamented Communications Design Center. She now runs her own research and consulting firm. The essential messages of her book are the following: 

• The way readers interact with documents is more important and more complex than most people realize.
  
• Words and images interact in surprising ways to produce their combined effects on readers.
  
• Designers can obtain useful information from classical rhetoric, experimental psychology, and usability testing. 
  

"Know your audience" is one of the main rules of technical writing. Creators of instruction manuals and online help systems routinely perform an audience analysis before they begin. Before Schriver's book, however, document designers didn't really know what to do with the information. Schriver shows that designers hit this dead end because the next step is neither simple nor mechanical.

Engineers, scientists, physicians, and many other professionals routinely carry out tasks that are neither simple nor mechanical. Their education and training give them the tools they need. Document designers, on the other hand, usually lack comparable education and training in document design. Their main resources are collections of valuable but superficial rules, and software packages that help them enforce those rules.

Designers who get beyond the cookbook level usually do so haphazardly -- slowly accumulating principles and techniques that pertain to their own contexts, but rarely generalizing them for the benefit of the entire profession. Schriver tries to "capture the texture of the choices" experienced document designers make and "represent the subtlety of the knowledge they rely on in carrying out their work."

Schriver's book is important, because it makes a real contribution in this direction. Through examples from her research and consulting, she helps us form a realistic picture of the people who use documentation and the problems they have doing so. Document designers who read this book carefully will come away with increased sensitivity to their audience. They will also have a clearer picture of the gaps they need to fill in their own knowledge and skills. Educators will come away with good ideas for improving curricula in technical and professional communication.

The book is scholarly, well organized, and a gold mine of ideas, but it would benefit from sharper editing. One example is the way Schriver describes her research work. Her audience -- "those who would like to further improve their work with verbal and visual language" -- have to wade through details of research procedure and methodology that have little to do with improving document designs.

Sharp editing would also reduce the 150 pages Schriver devotes to "situating document design." This is extremely interesting background material, and some of it is central to the main themes, but Schriver gives us little help in separating the wheat from the chaff.

VCRs are the symbol for inscrutable technical products with frustrating documentation. Two of Schriver's best examples deal with VCRs. I especially enjoyed reading about her attempts to use a pair of VCRs to edit videotapes she had made.

Schriver and a colleague recorded their efforts to connect the two VCRs, a cable outlet, a converter box, and a TV so that they could edit tapes and at other times watch or record cable TV programs. This is a predictable use of the equipment. The manufacturers could have foreseen and provided instructions for this task. Instead, before they found ways to simplify the problem, Schriver and her colleague confronted a problem space of over 5000 plausible combinations of wiring and settings. It took them ten hours to find the right combination.

Schriver concludes that changes to the product design and the documentation could have simplified the task. The main product changes she suggests are

• Standard arrangement and naming of inputs, outputs, and functionality.
  
• A display to help users monitor the effects of different wiring and settings.
  

The documentation changes are

• Anticipation of and instructions for tasks users might wish to perform.
  
• Illustrations to give users a mental picture of how signals pass through the system.
  
• A clear distinction between settings that are essential for connecting and operating the equipment and those that merely support "creeping featurism."
  
• Clear explanations of the effects and interrelationships of the possible settings and connections.
  

Her ten hour ordeal also gave Schriver a chance to experience personally another of her research findings: people tend to blame themselves for not understanding faulty products and documentation, but in fact, most people read instructions, try hard to make things work, and don't give up easily.

A key part of Schriver's book deals with typography and space. Schriver weaves together theories about rhetoric, facts about type legibility, experimental findings of the gestalt psychologists, and practical techniques for arranging material in grids.  The strength of this section is the way it draws together many factors -- making it difficult to summarize. Document designers will come away with few prescriptive rules but with enhanced sensitivity to helping readers see the structure and interrelationships of the text.

The material about typography and space is complex but clear. Schriver's discussion of the interplay of words and pictures is a little fuzzier. Even though she is able to distill a page of guidelines from the material, Schriver acknowledges that this is an area of ongoing research. She analyzes an attractive but ineptly designed website to help show how important it is to pay attention to this area -- and how easy it is to make words and pictures work at cross purposes.

Schriver finishes this substantial book by offering evidence, in the form of research studies, that paying attention to reader feedback improves document quality. At the same time she acknowledges that we don't fully understand how to obtain, interpret, and use such feedback.

In summary, this is a valuable book for anyone who wishes to inform or persuade others through words and images. But don't expect answers on a silver platter. If you don't intend to work hard to put the lessons of this book into practice in your own work, you won't get much benefit from reading it.

Single-Sourcing

WebWorks Publisher 2000 for Windows (Quadralay, Austin TX, www.quadralay.com, $895)

In Silicon Valley and much of the rest of the world, Adobe FrameMaker is the tool of choice for designing printed manuals. Many FrameMaker users wish to produce hypertext versions of the same material for use on websites or as online help. The principal tools for producing hypertext, however, can do little with FrameMaker output.

WebWorks Publisher is the exception. It transforms FrameMaker output into a variety of hypertext formats. It achieves great flexibility through the following features:

• Exploiting the structure that FrameMaker's paragraph, character, and table styles impose on the content.
  
• Generating hyperlinks from FrameMaker markers (such as those used for cross-references and generated tables).
  
• Enabling users to design templates for different kinds of hypertext pages (for example, contents, index, body).
  
• Specifying all of its mappings as programs in a powerful macro language.
  

In short, WebWorks Publisher extracts every bit of structure that it can from the FrameMaker output, then allows you to control the mapping of each element to achieve whatever effect you wish.

So far, so good, but all this flexibility presents you with a substantial programming problem. Quadralay provides project templates that let you map your FrameMaker output in acceptable but unimaginative ways. To achieve the kind of flexibility most designers are likely to want, however, you need to write some macros. At that point you must confront Quadralay's documentation.

The product has no printed documentation, but Quadralay's online help is thorough, informative, and authoritative. It appears to have been lovingly written by the product's designers. The only problem is that it is not very helpful. For example, many users will start at the first topic under Using WebWorks Publisher, namely, Managing WebWorks 2000 Projects. This largely vacuous topic leads to the detailed Setting Project Options topic. This topic states clearly what each setting means, but it gives no information about why you might choose one setting over another. It doesn't help you think about how to set up a project that fits your work style.

I found myself slowly increasing my understanding as I dived into topic after topic. The information seems to be there. The authors provide lots of facts but little indication of their significance.

WebWorks Publisher is a powerful tool -- perhaps the only sensible choice for a FrameMaker user -- but learning how to use it is a research project. If you decide to use it, allocate plenty of time for learning, or hire a consultant to bring you up to speed.

Bringing up the Rear

This article appears in slightly different form in the May/June 1999 issue of IEEE Micro © 1999 IEEE.

The last few years have seen substantial changes in the enterprise applications market. The traditional client/server architecture is giving way, except on Windows platforms, to multi-tier distributed architectures with generic browser clients.

The installed base is large enough to justify new client/server applications in the Windows environment. As Roger Sessions explained in his book COM and DCOM -- Microsoft's Vision for Distributed Objects (Micro Review, Mar/Apr 1998), Microsoft has a coherent strategy for distributed applications. This strategy leads to architectures somewhere between Windows-specific clients on a Windows-specific network and generic browsers on a generic intranet.

While strategists lay out grand plans on the marketing front, application developers and customizers scramble to identify and learn to use appropriate tools. This column looks at some old tools that assume new significance in this situation: Visual Basic, Perl, and online help authoring tools.

Visual Basic

Microsoft's Visual Basic 6 comes with excellent documentation. Within the framework of Visual Studio and the MSDN library, Microsoft has put together an exemplary package of procedural help and tutorial examples. Nonetheless, large numbers of third-party books try to complement the Microsoft documentation.

The three authors whose books on Visual Basic appear here look at the elephant from different viewpoints. Steven Holzner begins with Visual Basic fundamentals and small local problems. After the first 600 pages or so, he introduces more global issues, and by the time he reaches the index, he has covered everything thoroughly.

Dan Appleman doesn't bother with the material in Holzner's first 600 pages. He jumps into global issues from the beginning and focuses on giving you a thorough understanding of how to approach the design of reusable components. By the time he reaches the index, he has given back most of that 600-page head start. If Holzner wants to answer all your questions, Appleman wants to give you a deep understanding of the fundamental principles.

Ted Pattison uses only 300 pages to get from the introduction to the index. He covers much of the same material as Appleman, but a lot more concisely. He also gives examples of how to interface with Microsoft transaction processing capabilities. Pattison's book is more about Visual Basic's environment than it is about Visual Basic itself.

 

Visual Basic 6 Black Book by Steven Holzner (Coriolis, Scottsdale AZ, 1998, 1132pp plus CD, ISBN 1-57610-283-1, www.coriolis.com, $49.99)

Holzner and the team at Coriolis have put together a logically arranged, attractive, well designed, and extremely thorough book. It's a small thing, but I appreciate the fact that, except for the first and last fifty pages or so, the book lies flat and open to whatever page you turn to.

Holzner makes it easy to find out how to accomplish specific tasks. Most chapters begin with a table with columns labeled "If you need an immediate solution to" and "See page." After a brief "in depth" section, the chapter provides the promised solutions in short, well illustrated procedural essays.

If you plan to work with Visual Basic and expect to have questions like "How do I add buttons to a toolbar at runtime" or "How do I use a code component without creating an object," this is the book for you.

Developing COM/ActiveX Components with Visual Basic 6: A Guide to the Perplexed by Dan Appleman (Sams, Indianapolis IN, 1998, 888pp plus CD, ISBN 1-56276-576-0, www.samspublishing.com, $49.99)

Appleman's subtitle imitates the title of a set of 800-year-old talmudic commentaries by Maimonides. Appleman's point is that he hopes to augment the Microsoft documentation, not replace it. You may wish to draw other parallels between Appleman's book and talmudic commentary.

ActiveX (the technology formerly known as OLE) is a collection of object-oriented capabilities based on COM. Visual Basic is the front end that successfully hides ActiveX's complexities -- making it possible for average programmers to develop powerful reusable software components in minimal time.

Appleman's complaint is that Visual Basic hides ActiveX's complexities so successfully that programmers are left in the dark. The philosophy behind the Microsoft documentation is something like "You don't need to know how a car works to drive it." Appleman's answer might be "Yes, but you ought to know enough to understand why it's a bad idea to drive on a rough road or into a river or off a cliff."

Appleman's definition of an expert is someone who understands the fundamentals of a subject. He hopes to give you such a good grounding in using Visual Basic for ActiveX and COM development that you'll think all the techniques he describes are obvious.

Appleman's day job is creating reusable components for sale. That forces him to focus continually on all the right issues. He wrote this book from that perspective. If you want to build reusable components of high quality, this book is a very good place to start. 

Programming Distributed Applications with COM and Microsoft Visual Basic 6.0 by Ted Pattison (Microsoft Press, Redmond WA, 1998, 344pp plus CD, ISBN 1-57231-961-5, mspress.microsoft.com, $44.99)

Pattison thinks COM is the most important thing a Windows programmer can learn. Unfortunately, the early COM documentation was hard to understand without thorough grounding in C++. Pattison wrote this book to help Visual Basic programmers understand COM and to help C++ programmers understand how Visual Basic handles COM.

Pattison's book is short on examples, but the accompanying CD contains complete, functioning examples that you can run and examine. This is in keeping with Pattison's general approach. The material is all there. It's concise. You have to figure out the subtleties for yourself.

If you're a fairly sophisticated programmer and you want a quick tour of the COM basics without someone holding your hand, this book is an excellent choice.

Perl

Larry Wall's Perl language (Micro Review, October 97) is a wonderful example of collaborative software development. A key to making this collaborative effort successful has been the commitment and support of Tim O'Reilly and his company, O'Reilly associates. Originally known for a few definitive Unix books, O'Reilly Associates has grown into the leading publisher of books about Perl, Linux, Apache, Python, Tcl, and other collaborative open source projects.

The common gateway interface (CGI) is the standard protocol for using server-side computer programs to add dynamic content to web pages. Perl has become the leading language for CGI programming.

  

Perl Resource Kit for Windows (O'Reilly, Sebastopol CA, 1998, 4 volumes plus CD, ISBN 1-56592-409-6, www.oreilly.com, $149.95)

The software in this kit is free. You pay for the books and the CD.

Perl is a moving target. As soon as a book or CD appears it begins to become outdated. Nonetheless, this kit is a definitive Perl distribution for the Windows environment. It includes hundreds of Perl modules from the comprehensive Perl archive network (CPAN). You have to start somewhere, and this snapshot of Perl is as good a place as any.

The Perl distribution contains both client side and server side components. The Perl Utilities Guide by Brian Jepson, one of the four books in the kit, leads you through the complexities of installing and configuring those components. It also gives you an overview of how to write, debug, and run Perl programs within the framework of the Windows component object model (COM).

Programming with Perl Modules by Erik Olson, the second book in the kit, gives examples of how to use the most popular CPAN modules to develop applications. He devotes a chapter to Lincoln Stein's CGI.pm, a module to support CGI applications.

The Perl community values and rewards good documentation. Perl programmers produce documentation for their modules using a markup language called pod (for plain old documentation). The final two books in the kit contain David Futato's compilation of written documentation for many of the CPAN modules.

Learning Perl/Tk by Nancy Walsh (O'Reilly, Sebastopol CA, 1999, 376pp, ISBN 1-56592-314-6, www.oreilly.com, $32.95)

Visual Basic provides designers an easy, visual way to specify, arrange, customize, and program graphical elements. This has made it the most popular tool for producing graphic user interfaces (GUIs) for distributed applications.

The Tk toolkit, originally developed for the Tcl language, gives Perl many of the same GUI development tools that Visual Basic has. This book explains how Perl and Tk work together, and it provides step-by-step instructions for using all of Tk's graphical elements.

Unlike Visual Basic, which hides such details, Tk makes its geometry management explicit. Walsh covers this material carefully in a lengthy chapter. Reading it is a good way to learn to use Tk effectively.

The book does not teach Perl programming, but it is a worthwhile introduction to Perl/Tk.

Perl and CGI for the World Wide Web by Elizabeth Castro (Peachpit, Berkeley CA, 1999, 272pp, ISBN 0-201-35358-X, www.peachpit.com, $18.99)

The Peachpit Visual Quickstart Guide series, and Elizabeth Castro's books in particular, are examples of user help at its best.

Do you want to know how to reverse the contents of an array? Look in the index. Turn to page 99. There you find the simple procedure, an example of the code in context, two helpful (but tiny) screen shots, and three tips, including one that refers to the material about sorting arrays on page 98.

If you need to do Perl and CGI programming from time to time, this is a good reference to keep nearby.

 

Online Help Authoring Tools

Online help was once almost exclusively a Windows phenomenon. Help authors prepared RTF files and passed them through the Windows help compiler. Microsoft's WinHelp engine was the only way to display the resulting HLP files.

Nowadays there are other possibilities. The WinHelp engine, as it exists in current Windows systems, is more powerful than its predecessors. Nonetheless, Microsoft is phasing it out in favor of HTML Help. HTML Help is still Windows based and compiled, but an ActiveX-enabled browser can view much of an HTML Help file on any platform. More important from Microsoft's point of view is the fact that HTML Help blends seamlessly with web content.

At the same time, Sun and Netscape, trying to support their own views of distributed computing, have introduced formats for HTML-based online help. These have evolved into WebHelp, which uses both a Java applet and an ActiveX control to display help files on any platform.

Steve Wexler's book describes HTML Help and Microsoft's tools for producing help systems in that format. But the best tool for all formats, including HTML Help, is RoboHELP from Blue Sky Software.

The Official Microsoft HTML Help Authoring Kit by Steve Wexler (Microsoft Press, Redmond WA, 1998, 312pp plus CD, ISBN 1-57231-603-9, mspress.microsoft.com, $39.99)

Steve Wexler is a well respected expert in the field of online help for Windows systems. He is the ideal person to describe Microsoft's approach.

The WinHelp engine is a Windows executable program. It stands alone and only runs on Windows systems. The HTML Help engine, on the other hand, is an ActiveX control, so it integrates tightly with a container application -- including an ActiveX enabled browser on any platform.

If you want a clear description of how this works and how to use Microsoft's tools to produce HTML Help systems, this is the definitive book.

RoboHELP Office 7.0 (Blue Sky Software, La Jolla CA, www.blue-sky.com, $799)

I have talked about RoboHELP many times in these columns (see Micro Review, May/June 1998). Blue Sky has long been the premier producer of tools for creating online help, and they are working aggressively to stay that way. Building on the basic RoboHELP package, which originally supported only WinHelp development, Blue Sky has moved to support development of all online help formats.

Blue Sky uses a two-pronged approach to this problem. They offer a single source capability based on the original RoboHELP approach. They also provide a separate authoring environment, with essentially the same user interface, for producing HTML Help. From this environment, you can import a WinHelp-oriented project, then fine tune it for HTML Help.

Version 7 also introduces a number of productivity improvements to earlier versions. These make it easier to produce indexes, browse sequences, and modular help systems, and they simplify macro programming.

If you need to produce online help in any format for any platform, this is the product to use, even if you hate Windows.