What is Context Sensitive Help?

Context sensitive help has matured as content-rich, online help systems have matured. It even has its own acronym now: CSH. When something has its own acronym, you know it has arrived. It has proven its worth to help people learn complex software in diverse environments. Applications, whether web-based or locally hosted, have different types of context sensitive help available. Moreover, developers and help authors can set it up without a lot of trouble.

In old times, help often came in a CHM file that resided on your own computer. Context sensitive help was more impractical. You could incorporate it in your application, but it felt painful and just cumbersome enough that you generally wanted to avoid it, or keep it to a minimum. Now most HTML help files live on servers, so you can be more creative, even aggressive if you like. You needn't hang back because it feels hard.

Most people know what context sensitive help is. They rely on it, even if they haven't seen the phrase. Yet the concept can get away from you, especially when you try to define it from an engineer's point of view. For users, the idea is simple: you click a help icon or some other symbol to open help that pertains to your location in the interface. The context could be the entire screen, a dialog box, or a particular button. The big advantage of context sensitive help is that you don't need to navigate your way to information you need. The disadvantage, of course, is that CSH is not designed to explain an entire workflow, which may occur across a number of contexts in the interface.

For engineers and help authors - that is, for developers who work on the application's back end - context sensitive help may still seem a little difficult to deploy. That's especially true now that companies and service providers deploy applications in so many different environments. Consequently, engineers must test online help along with the rest of the software. That's why I wanted to write this article: to define CSH in a way that makes sense to engineers and product managers, and to discuss briefly the options help developers have when they think about how to implement CSH for their applications.

So here's a back-end definition, explained as you might see it in a design spec. CSH works because the application contains a link between the user's location in the interface, and help relevant to that location. More specifically, when a user requests help with a particular click, the application has to know which help file to serve. It knows because developers create a link between the user's context and the help file.

Help files and the clicks that call them are not part of the application's main work flow. Therefore developers generally add those files as they test the application and prepare it for deployment. When they add help files, they incorporate references to those files in the code. These links tell the software which help file to open, for each item users might click to request help.

The button might be a help button in the upper right portion of the page. In that case, CSH would open a help topic to give an overview of the page, or to orient users who may not be well oriented when they arrive. Alternately, an icon may be a question mark or information symbol, located at a place on the screen where users probably need guidance. Lastly, we have all learned to rely on tooltips that appear when you hover over a menu selection, a data field, or any other clickable item on a screen. Short as they are, these ubiquitous tips make up the most familiar form of context sensitive help.

If you need more space than a tooltip normally offers, you have a presentation choice to make. Do you want to present your material in a pop-up box, or take users straight to a topic in the online help? A pop-up is not a bad option: you can present basic guidance there, then include one or more links to more comprehensive help topics. If you take users directly to an online help topic for any context sensitive help request, make sure the content you show clearly relates to the clicked item. Users lose patience fast if they need information about a narrow point, and you ask them to scan blocks of text to find it.

Developers always seek good interaction between users, and what users see on the screen. When you open an application, you typically want to accomplish a specific task. You are eager to learn the correct procedure, if you do not already know it.  The learning process is enjoyable, as long as it proceeds efficiently. You do not want people to get stuck. Intuitive software integrates learning into the task.

When we say that software is intuitive, we mean that flow from one step to the next in a procedure feels effortless. You know what comes next. Sometimes a procedure is quite complex, or a new user needs reassurance. Sometimes an experienced user needs to learn a part of the application not used before. In all of these cases, context sensitive help may offer all the guidance people need, or initiate a productive learning process.

In the end, developers who incorporate CSH do so simply to integrate online learning resources as thoroughly as they can with their application. Opening a pop-up in response to a specific click is not technically difficult, but it does require more care, planning, and maintenance than building online help intended for launch as a standalone system. Standalone help has its place, too, but users are accustomed now to fast learning. For that, they require help resources that fit the just-in-time model: software supplies just the right information, at just the right location, exactly when the user needs it. Context sensitive help, in all its forms, lets you do that.