Re: Writing for on-line

[Scott Miller <smiller -at- CORP -dot- PORTAL -dot- COM>]

The idea of thinking about getting content from a database, and
developing content separately from format, is a good one. That's how I
managed single sourcing between print and help at my last job. It was a
very efficient way to save on writing time and translation, but we still
found that single sourcing wasn't the best way to go.

The problem wasn't so much that we couldn't create quality docs. The
help won awards, and the printed docs were... OK. They weren't great,
but they sufficed. (Since we developed the help first, and created the
printed book from that, there wasn't always a good fit going from a
formless web of info into a structure based on chapters.) However, it
seemed pointless to repeat the same information in the help and in the
printed manual, so we decided that the best thing to do was to not
single source, but instead create the help, and also create a print-only
getting started guide.

The getting started guide was going to be (I quit before I actually
wrote it) short, with just the basic tasks, and a bunch of concept
information. Some of the concept information was stuff that would fit
nicely into a book, but not so good in online help. For example, (this
was for an e-mail program) the getting started guide was going to
include some information about email etiquette, tips for using email,
and so on.

The point I'm getting at is that even if you have the tools to single
source print and doc, you might help the user more by creating separate
help and print docs. It depends on what you're documenting. If you keep
the print doc short enough, the overhead is minimal. In fact, there were
a number of things that made it easier and cheaper to not single source.

- Scott Miller
Portal Software
smiller -at- portal -dot- com