Helping users stay in
their cozy software homes

Imagine you're test-driving a new car.

You're tooling down the highway at 55 (OK -- 65) and decide to change radio stations.

The salesman tells you that changing the station requires six steps: pulling off to the side of the road, parking the car, shutting the engine off, getting out, going into the trunk and fiddling with the tuner controls.

Doesn't sound like the kind of car you'd want to drive every day, does it? But if you think about it, software design has been pretty much like that.

Programs have been arranged in ways that made sense to programmers, not users. Even so-called user-friendly machines are wild mish-moshes of unrelated software that users must somehow harness to perform related tasks.

Don't think so? Find a user experienced with, say, word processors and give her a copy of Quark XPress or FoxPro. See how far she gets without help.

It's time to start designing systems around users and the way they work, instead of trying to force users to jump through hoops. Systems should be designed to pull resources to the user so they can be used with the same tools already in use.

Take, for example, newsroom resources that are referred to only occasionally, such as computer-assisted reporting data, campaign finance data and system documentation. Useful on a more frequent basis are style books, lists of government employee names and addresses, and census results.

We all know of the trials and tribulations of trying to get reporters to use style books. And it would certainly make editors' lives easier if they could get their hands on a system manual without having to file an Foia.

But how do we get this information into the right hands?

We could put it on paper in the library, but librarians will tell you that many reporters and editors rarely visit.

We could teach everyone to use databases and spreadsheets, but we know some people won't want to be bothered -- and others simply will be too pressed for time to boot up something like that five minutes before deadline and wrestle it for a piece of data.

We could build custom applications in C++ or Visual Basic. Custom apps are usually easier to use (I will sing the praises of Visual Basic until you are sick), but we are still talking about forcing reporters and editors to leave their regular software to work in something else.

Having to boot another application -- or toggle between two -- may seem to be a petty consideration. (After all, for folks who read The Cole Papers, multitasking is daily occurrence.)

The genesis of this line of thought came to me in December at the Poynter Institute, where I was a guest faculty member at a seminar on the future of news libraries. Some of the finest newspaper librarians in the country were there, and they uniformly told a telling tale:

Users who have access to the library from their terminals dive into it.

Users who don't, don't.

In this case, the normal discussions of user aversion to new systems or technophobia are turned on their heads. Surely no one will argue that any reporter anywhere doesn't understand how to work the stacks, or has an irrational fear of newsprint.

The problem, said the librarians, is that reporters won't interrupt their work to go search for something that may or may not exist.

Research just doesn't get done. And stories -- and newspapers -- suffer.

One way to address this problem is to try to keep reporters in their cozy software homes by building custom applications that can be called from the word processor in macro language. This is a better solution from the user's point of view, since data can be accessed with a single mouse click from inside the story.

This is risky for an organization, however, because a large investment in programming can lock a newspaper into that word processor. And it doesn't answer the needs of, say, layout editors working in XPress and artists working in FreeHand -- unless you are willing to learn every macro language in the known digital universe.

Fortunately, there's an answer built into many APIs -- application programming interfaces.

Better yet, all Windows software and many programs for other environments use a single hypertext help system -- the Microsoft Windows Help engine. (A hypertext document is one that allows users to jump directly from topic to topic.)

Help files can be built in a word processor; no heavy programming is needed. In-house databases can be attached to the current file, so a user can look in one place for census data and the location of a command on a menu.

The engine is standard to the API, so the same custom Help file can be used in XPress, FreeHand and WordPerfect.

And here's an unexpected, undocumented benefit: Windows Help files will run as-is on a Macintosh, because the same engine is used in Microsoft Mac software such as Word and Excel. There are also recompilers that can be used to get them to run on UNIX platforms.

In both cases, you are limited to running essentially plain vanilla Help files -- Help files on Windows and OS/2 can do some fairly wild tricks involving bitmaps, dynamic link libraries (DLL) and other software toys.

Writing the Help files is actually fairly simple. Let's say you want to build a Help file with all the U.S. Census data for your state. You want people to be able to pick "Census" from a menu, then a town, then specific pieces of data -- say, the number of homes that lack indoor plumbing, for instance. (It's on STF-3, in case you think I'm pulling your leg.)

First, bring all your data into your word processor. Microsoft Word is preferred for a simple reason: Microsoft puts out lots of templates and tools for Help programming for Word, and none for competing word processors. It is possible to build Help files in any word processor that can save files in Rich Text Format, but you'll have to build the files by hand -- a tedious process.

Like so many brilliant ideas, the world had already dreamed this one up. There is a flourishing little WINHelp publishing industry churning out in-house documentation, reference works and all sorts of other texts. WINHelp publishers even have their own Listservs and Usegroups on the Internet (or Infobahn, if you're keeping up with the slang).

Just ask William McLuskie, a senior research analyst in the Research and Development Section, Administrative Computing Services, at North Carolina State University.

"We publish newsletters, announcements, installation instructions, new employee fact sheets, software tips and tricks, programming references, a 'fix your own problem yourself' database and documentation in WINHelp," McLuskie said.

"We were distributing various documents throughout our division. We were using MS Write because it is simple and we knew everyone would have access to it," McLuskie said. "As the documents grew in size, complexity and number, and we found that many documents were being used as reference materials, we decided to change over to WINHelp.

"We knew that WINHelp would also be available to everyone and that we could organize the information into more useful formats. Using the WINHelp search engine and hyper links, we could set up the information both for an initial reading and then for use as a reference document."

Users at N.C. State like the new system, McLuskie said.

"Actually, it is so easy to use that the only time they think about it is when they receive a document that isn't in WINHelp format. Most automatically turn to our LANews help file whenever they need help with new software or are having a problem, before asking the LAN administrator.

"The LAN administrators love it because they can type instructions once and let everyone take care of themselves.

"We are/will rely very heavily on hyper-text/-media publishing," McLuskie said. "It's cheap, fast, easy to change and update, simple to distribute, and just about everyone already understands how to use it."

WINHelp is even being used to publish stand-alone documents (ones that aren't meant to run only inside another piece of software).

"We created an electronic catalog for a military device, which used a few hypergraphics and a lot of hot spots," said Yossi Oren of Al-Daf Techno-Mercenaries in Rishon Le-Zion, Israel.

Hypergraphics are images that allow you to jump from one to the next the way hypertext allows you to jump from one verbal concept to the next. Hot spots are areas on the screen you can click on with your mouse to make things happen.

Oren says his users have been impressed by WINHelp publishing: "'Gee-whiz!' is their reaction."

Oren also said the decision to use WINHelp was simple: "It was either WINHelp or my own HT (hypertext) engine."

Help files are built as text files in a word processor. Special formatting is used to set up the jumps and link topics. Here are the basic steps:

A top page is set up with a list of topics. Each topic has a double underlined section -- the part the user sees -- followed by the jump tag in hidden text: Topic1topic1.

You then move down to the actual text for Topic1 and insert a footnote that says "topic1."

This can all be done by hand, but formatting hundreds of jumps gets tedious in a hurry. Stick with the templates put out by Microsoft and others, or buy a program designed to do the job, such as RoboHelp or HelpMagician.

In any case, you can obviously format any text in such a fashion. Census data, campaign records, internal stylebooks -- anything is fair game.

You can even do hypergraphics, where clicking on a drawing takes you to another drawing. There are obvious uses for this technique if you need to use schematics and diagrams.

Once the document is formatted, it must be compiled for the WINHelp engine. The first step is to have the word processor save the file as a Rich Text Format (.RTF) file. The file is then run through a help compiler.

Microsoft's compiler is called HC31.EXE. It ships with Visual Basic, Visual C++ and other programming tools. Compilers also ship with development tools from Borland and other companies, and there are compilers cruising around the Internet.

There's really nothing to the compile step: Just type "Compile Myfile.RTF" and your file gets compiled, assuming you've set it up correctly.

WINHelp publishing is a small enough niche to be a bit odd. For example, everyone's favorite tools are a couple of unsupported Microsoft files: What and Whag.

The latter is the never-finished Windows Help Author's Guide. Among the things left out when the project was abandoned are all the illustrations mentioned in the text. Still, no serious WINHelp author goes without them.

"Get What and Whag (Microsoft unsupported, both) and read, print, memorize, worship whatever's written there," Oren advises new WINHelp authors.

McLuskie said new WINHelp authors should look at what has already been done in the field.

"Take a long hard look at some 'professional' and 'nonprofessional' help files. Observe what was done right and what was done wrong," he said. "Talk to others and choose the right tools for you. I prefer to use Word 2.0 and a template that I wrote."

As long as you avoid such complications as calling DLLs straight from the Help file, you can get them to run on Macintosh, OS/2 and UNIX machines.

Using WINHelp files in OS/2 is simple, since OS/2 supplies support for native Windows. You can even call DLLs if you really want.

On a Macintosh, the trick is that Microsoft uses the same Help engine for Mac software such as Word and Excel. You don't have to use the software to get access to the Help file: Just use your system tools to associate it with the Help engine.

UNIX is rather too complicated to jump into here. Suffice to say that there are recompilers and other tools to help you make the transition. Specific advice depends on the flavor of UNIX you use.

Yet it is a tool that helps us design systems built around our users, rather than having our users adjust the way they work to our systems.

That should allow users to spend more time doing their jobs, and less time trying to wrestle the system into submission.

Isn't that the point of good system design?