> Curious what products people are using to build and maintain
> their online help and printed user manuals.
>
> I've tried all the popular tools (Doc2Help, RoboHelp,
> ForeHelp, WestWind HTML Help Builder, Help&Manual) and
> haven't been psyched about any of these products (or their
> prices). Other suggestions or a rabid endorsement for one
> these products?
>
> What's your approach to delivering online help? Anyone using
> more than one format?
I use CHM because it's as close to "one format that does it all" as I
can see out there. I especially like that web pages can be brought up
within a CHM file to extend it's contents. I dislike how CHM editors (at
least RoboHelp) generate Word Doc files for printing - requires too much
'touching up', but there's also such a fundamental writing style
difference between writing a book that's intended for top->bottom
reading and a hyperlink heavy CHM file.
Before FoxPro (in mainframe-land), I used IBM's Script/VS product for
years, and grew to like it a lot for book-writing, but for FoxPro I
first picked up on WW Help Builder, and used it for a while, but
eventually switched to RoboHelp because it has more features. I really
do miss the intimacy Help Build has with FoxPro, e.g. document generator
for classes is a big one.
As to the rationale for writing doc at all, first I'll say that I
absolutely agree about the use of video clips for showing users how
things work, but there's much more to project doc then that. I regard
project doc as a vitally necessary clearing house for every topic that
relates to the project, beginning with the requirements for the project
and then on through every topic I can think of that relates to the
project.
When I'm working, I always have both the project being worked on and
it's related project (CHM) file up. I view the software and it's doc as
integrated and switch back and forth between the two all the time.
The overall organization (main TOC) of the help/CHM file is something
that I've changed a few times and never seem completely comfortable
with, because at the highest level I've never been convinced that anyone
has nailed a universally useful software project outline. OTOH with
online searching being integral, the need for "proper" TOC organization
is less important than the ability to find relevant topics when they are
needed.
Yes, doc writing is tedious and expensive, BUT, after the work is in
progress - and given the effort it requires, the results become more and
more worthwhile. The reasons are many, beginning with the most obvious,
that the doc describes (and helps to preserve!) the product's
architecture beginning with it's requirements and feature's list and
test plans (which I store in a grid/matrix that serves as a high-level
checklist but also has links to detailed plans). It also contains screen
shots of every form in the system for rapid perusal and Visio charts for
complex processes. One liberty I've taken with (I think) excellent
results is the inclusion of scanned pages containing drawings (e.g. from
the back of napkins). A while back, I wouldn't include such material
until I took the time to polish it into, say, a visio chart, but now I
just scan the (napkin) and put it where it belongs. Later, if there is
time, I might go back to make it pretty, but I really like the fact that
I still have the napkin - that it's in it's place makes it far more than
a napkin. Another thing I include (in the appendix) is edit/browse
screen shots of sample data which I find is useful. I like having these
collections of screen shots in one place for rapid perusal.
The organized mind works on the simple principle that "everything has a
place and everything in it's place". But software components are, by
definition, put in places prescribed by the tool, VFP in our case, but
each language organizes it's libraries according to the tool designer's
ideas for how it needs to be organized. That we use classes, for
example, is a wonderful programming technique, but is only so relevant
to a project's business organization. Perhaps some super-duper program
will exist one day that we can have a conversation with and it spits
software and doc for us, but until that happens, we need some form of
doc system that let us organize our work in a way that we can easily and
rapidly relate to. From what I can see, CHM is still the best choice.
Bill
>
> 1. Windows HLP (winhelp)
> 2. Windows CHM (htmlhelp)
> 3. Standalone HTML files
> 4. Word DOC or RTF
> 5. PDF
> 6. Website based help system
> 7. Home grown help system
> 8. None ("documentation is for pussies<g>")
>
> Finally: Any one still delivering printed user manuals with
> your products? By default or as an extra cost option?
>
> Thanks,
>
> Malcolm
>
>
[excessive quoting removed by server]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
