If you have a large HTML Help system, it can take a few minutes to compile.

Say you make a change to a topic and you just want to check quickly that it'll work correctly within the compiled help. For example, the topic might reference a JavaScript file that only works in the context of the Help Viewer, so if you just open the topic in a browser the page doesn't look and/or behave like it does within the help system. So you need to check it in the help system, but you don't want to recompile the help system.

The solution is simple. Just open the existing .chm file, right-click the title bar and choose Jump to URL.

In the Jump to URL dialog box, enter the path to the file you want to test:
 

Click OK.

The topic is displayed in the Help Viewer just as if you compiled it in there.

Where I work we have a core system upon which software "solutions" are built. The core system was built as a product in its own right but functions as the platform that is used to build these solutions - each of which serves a different purpose for a different type of user doing a different job.

So we have a legacy help system (which I created about six years ago and the content of which is mainly still my work) which is supplemented by context-sensitive help (CSH) for each solution. One of my tasks for the coming months is to make sure that the topics in the core help system work equally well in the context of each solution. The tricky bit is that these solutions are designed to be integrated, so while one customer may only have Solution B, another customer may have Solutions A, B and C all integrated together within the same system, with some of their users only getting access to one solution, but others seeing all three. And the help topics need to allow for this without: a) requiring any coding (because no development effort is available for user assistance) or b) turning into a maintenance nightmare by creating a web of conditional behaviour.

But thinking about how this might be done led me to consider how important this core help system is. And in my opinion, from the user's point of view, the importance of assistance is largely measured in relation to how immediate it is. This is, of course, balanced by how useful it is and the nature of the assistance they need, but number of clicks away from where I am now is a big factor. So it shapes up like so:

1. What's in the user interface (labelling and messages).

2. What the user sees first when they click Help.

3. What they see next.

4. If they're still looking, what they see next.

Tech writers don't get involved enough with point 1 (Graham and I were just discussing this yesterday). It's something we could really help out with but are rarely asked to contribute to. Now I'm not saying that a good tech writer is necessarily a good usability analyst, but I know from experience that we're often more sensitive to usability than the programmers who often get left to write user interface text.

Point 2 might be a CSH topic with the information the user needs, but sometimes (e.g. when there are lots of things you might be doing on that particular dialog box or form) it's not possible to cover all the bases in a short, snappy help topic, so you need to use a landing page topic with questions that will branch out into information topics.

Point 3 is either a topic within the help system (if 2 was a CSH topic) or a CSH topic (if 2 was a landing page).

Point 4  is a topic within the help system, and because it's so far removed from what the user was looking at, he/she may never get here. Help is all about getting an answer and getting on with what you were doing as quickly as possible. Nobody but a really desperate user - or a tech writer - browses a help system.

So I think we need to really focus our attention on the context-sensitive help: the CSH information topics and any landing page topics we need to use. Yes, we should try to make the core help system as comprehensive in its coverage as we think genuinely represents value for money and a good use of our time/effort, but I believe we should only do this after we're happy that we've made a really good job of the CSH.

I guess it's the tyranny of the majority again. We're spending a lot of effort crafting really well targeted, clear, concise and correct topics for the majority of users who never get past one or maybe two clicks into the help. And inevitably, in doing so, we're going to have to sacrifice some of the requirements of the minority of users who occasionally go looking for information in the core help system. For them, I believe, we should concentrate in getting the information in there for them. It might not be pretty. We might not have spent so long crafting it to be easy to digest. But it's better to have information in there that you have to read twice to work out what it means, than not to have the information in there at all. We can comfort ourselves, perhaps, with the thought that users who are prepared to go digging in the help system may be more capable of understanding information that might be a little bit raw.

If you're in the UK and you write create HTML Help (i.e. .chm files) you might have noticed that your Related Topics links display in a big clumsy dialog box instead of a neat little popup.

This is thanks to a stunning piece of incompetence on Microsoft’s part. They managed to break the hhctrl.ocx Active X file that controls the related topics popups. After about version 4.7 of this file, related topics always appear in a dialog box unless the language of your project is set to US English.

The workaround for RoboHelp is to open the .hhp file in a text editor (e.g. UltraEdit) and make sure the Language is set as follows in the [OPTIONS] section of the file:

Language=0x409 English (United States)

The chances are there won’t be a Language setting, in which case just add this. Save the file and, when you next compile the project, the related topics are displayed as popups.

If you've imported your RoboHelp project into Flare, go into Project > Project Settings and make sure the language is set to English (United States), then recompile the .chm file.

I just stumbled across the ESRI's WebHelp for ArcGIS. Very, very nice!

http://webhelp.esri.com/arcgisdesktop/9.2/index.cf...

I particularly like how they've done the Print/Email/Feedback links in the title box for each topic, and the way they've done Related Topics.

Some really good ideas and a nice design. I wish I'd seen this a few months back before I got so far down the road with the WebHelp I'm currently working on.

A while back I had a problem with glossary pop-ups I'd designed for the online help system I'd been working on. The content in these pop-ups was dynamically extracted from a central XML file and everything worked fine in HTML Help and in WebHelp when opened directly, but not when the WebHelp pages were served up over HTTP. I solved that problem (see Making XMLDOM ActiveX control work over HTTP) but then I found that RoboHelp pop-ups had the same symptom, apparently caused by something else (since the RoboHelp JavaScript doesn't use the XMLDOM ActiveX control).

Anyway, while searching Google for an answer I came across this article about RoboHelp in a blog by someone called Ryan:

www.youknowwhatpart.com/archives/2005/03/productivity_to.html

It's an interesting blog and I spent a bit of time there, but it left me wondering: who is this guy? How come he knows about RoboHelp and Madcap and Framemaker? Is he a technical writer? The blog gives nothing away. The "View my profile" link goes to a blank entry on Technorati.

But then I thought, my blog probably says nothing about who I am either!