Simple, right?

 

Since I hadn't created a help file in many years, and since my last HTML Help project was unpleasant (for reasons I won't go into here except to say that the software I used was difficult to use), I decided to have a fresh look as to what Help-Authoring software tools might be available now that could help make the process considerably more efficient.  I had that look, and carefully reviewed the features (and prices) of a number of products out there.

 

Some products were "high end" and had elaborate features that I would probably never use.  One of these in particular had reviews on it with more complaints about the company (not the product) than praises for the product.  In this high end group, most the prices were way outside my budget anyway.  Of the remaining Help-Authoring tools, there were a large number that automated parts of the process.  Most of them had features like "variables" and WYSIWYG layout capability, and most of them generated compiled help as well as HTML files, and some other variants such as PDF.

 

I kept thinking to myself, "If I spend an extra 2-3 days really finding the RIGHT software tool for my project, it should save me at least that amount of time in the project itself right?"

 

Finally, one of the Help Authoring tools really stood out as being focused on the EFFICIENCY of the process.  Simultaneously the normal output of this product followed my own philosophy of how I thought an HTML Help File should look, and how it should "flow" for the reader.

 

I downloaded the trial version of this software and begin studying its Help file in sequence.  To my delight, the Help file was well organized, and easy to study, and covered basics FIRST.  What was also very interesting was that the Help file was created by the Help-Authoring tool it was documenting!  To me that means that the makers of that product really believe in their own product, and are probably expert Help-File makers themselves.

 

To really find out if it was going to give me the efficiency I was looking for, I started into my Help project, and was up and running with a great deal of work completed already within the first day.  Every 15 to 30 minutes I would run into yet another feature of this software that made my work more efficient.  After a day, I could tell this was the tool I was going to adopt and use for this project and many more in the future.

 

It's been a long time since I have been genuinely excited about a software product.  I myself am a software developer, so I am probably biased about these things in many ways.  I know what it takes to make a slick, functioning piece of interactive software that both pleases the end user and makes his/her work significantly more efficient.  When I am the end user, the author(s) of that software have to have really gotten a lot of things right, and if I am using the application and find something I need to understand better, I want to hit the F1 key, read, and feel I have come up to speed on whatever it is that I was looking for.  But not only did I like this product, but I found myself delighted to be using it.  The number of times this has happened to me in the last 20 years I can still count on one hand.

 

When I am delighted about a new product I encounter, I want to tell others about it.  And this is exactly what I am doing with this article.

 

The product:

 

 

 

The next day of the project, I started the day by finishing studying the rest of Dr.Explain's Help file -- some of the more detailed parts of the software.  And then I continued producing my Help file.

 

Having the urge to tell others about it, I decided to keep a narrative log of two things as I went through my project:

 

1.     each step that I took doing the project, and lessons I learned along the way, and

 

2.     things that continued to delight me while I was using Dr.Explain.

 

#1 I did in part because if I needed to create another help file in 6 months or 60 months from now, I could refer back to it to refresh my memory and get back up to speed quickly, or simply use it as a checklist. However, I also created this log because in my searches on the web, I found very little that was worth while in terms of articles about "How to Create an HTML Help File". So I decided to blaze a trail and leave a map that others could follow, and published it as a series of articles:

 

 

How to Create an Index (for a Large Help File, Document, or Book),

 

Adding Context Sensitive Help to Your VB.NET Application, and

 

Customizing Some of Dr.Explain's Screen Capture Behaviors.

 

Finally, #2 I published as a product review for Dr.Explain:

 

Dr.Explain Product Review.

 

 

Before venturing into these articles, please carefully review the key terms on the following page that I used throughout these articles.

 

Enjoy, and happy Tech Writing!