Saturday, February 7, 2009

The Answer to Grandiose Help

Q: What have you used to create help files for your applications?

A: It's not exactly a model of perfection, but for Foxhound I am heading toward a static website simply because Google can be used for searching; e.g.:

heartbeat site:risingroad.com/foxhound
Right away you can see that individual page titles need work... but at least the content's there.

I also ship the *.HTML files with the product so they can be browsed offline if absolutely necessary. I am not going to attempt custom offline searching.

I used to be a fan of *.CHM but it is so difficult to develop, and the searching is so 1980s.

If you want to see what does NOT work, see Microsoft Office Help. I'm sure it requires wetware-centuries of effort to develop and maintain, but it is absolutely impenetrable... BECAUSE of the so-called ease-of-use. They made so many great improvements in Office 2007, I don't understand why they keep going in that direction for the Help. When I have an Office question I use Google:
"get external data" "excel 2007" site:microsoft.com
Foxhound does attempt a kind of context-sensitive Help using frames; click on one of the several tiny "?" images in the working frame to scroll the Help frame to the appropriate section.



If Foxhound was a "normal" GUI (end-user data entry, etc) then I would not bother with context-sensitive at all. If someone needs to be told that the Date of Birth field "contains the employee's date of birth" they probably can't figure out context-sensitive Help either, and it's time for some classroom instruction.

However, Foxhound is a funky app where highly condensed data is blasted onto the screen... at least in the performance monitor section. So, I needed some context sensitivity to tell people where the data is coming from and what exactly it means... and does not mean. And nobody's going to offer a Foxhound class.

The last thing I want to do is let the Help authoring process itself affect the project in the following negative ways:
  • slow down the addition of new, valuable Help content, and

  • slow down application development by requiring simultaneous Help-related changes to the GUI.
The answer to grandiose Help is not "build a complex framework to assist the authoring and presentation processes" but "stop doing it".

Note that Foxhound is a web app itself... but I would probably take the same approach for a desktop executable. Exactly the same original HTML content is served up three ways:
  • the website Help for Foxhound,

  • local HTML files delivered via start - All Programs - Foxhound1 - Help which is a simple shortcut to foxhound_contents.html, and

  • Help frame content served up from the local SQL Anywhere database via web services as part of the Foxhound GUI.

No comments: