Context-sensitive help is great. The reader was on a screen, needed help for that screen, and boom! There’s the appropriate help, with no need to wade through a Table of Contents or search results.
But as the help author, you now have this super-specific topic floating around your help file.
Here’s what I mean:
I worked on a product that includes a way to add an “access number.” A customer finds the “Add Access Numbers” screen, then clicks Help.
Since we know which screen the customer came from, we don’t have to waste a lot of time. The topic jumps right in with the first step for that screen.
Of course, we leave this topic out of the Table of Contents and Index. But, unless you’re using the very latest versions of a Help Authoring Tool (as of this date), Â then anyone who searches for Access Number will find the topic.
Those people will get frustrated when they see instructions for adding an access number without help about getting to the right screen.
So the choice seems to be:
- Add detail that will be obtrusive and redundant for most readers. Or
- Leave those details out, and annoy people who find the topic through Search.
Of course, I prefer a mix.
At the top of context-sensitive topics, I suggest adding a bit of dynamic text that, when clicked, expands to show how to get to the screen in question.
The reader who’s there from a context-sensitive link can get started on the steps right away, while the reader who’s not so sure can click to see more information (without leaving the page).
TIP: Make sure that dynamic text links are a different color (or otherwise distinguished) from regular blue hyperlinks.
The context-sensitive page opens:
At the top, we show a green link that most people can ignore.
The reader who wants more information clicks the green link, which shows more information in an expanding box.
How do you solve this problem? Or do you not think it’s a problem at all?
