Understanding the new help features R5 includes three new context-sensitive help design features. Together, these features make it easy to create context-sensitive help for your users.
OpenHelpDocument command To help you with writing code for the event, R5 includes a new @command called OpenHelpDocument. This @command lets you specify a help topic to display in response to an event.
Help window The OpenHelpDocument command displays help in a separate, small window with a customized menu that provides only relevant help functionality for your users. For example, one of the menu choices, View - Always On Top, lets users display help and work in the application at the same time.
Before you start The following are decisions that you have to make before you begin building context-sensitive help:
OpenHelpDocument: the syntax Before you create help, you should be familiar with the @command OpenHelpDocument. This @command is similar to @DbLookup in that it looks up a document in a view using a key that you specify. OpenHelpDocument goes one step further: it opens the document found in the view. The following is the syntax for the OpenHelpDocument formula: @command([OpenHelpDocument]; server:database; viewname; key) server is the name of the server where you put the help database. If this argument is a blank string or if you do not include this argument, Notes looks for help on the user's local hard drive. To use the name of the current server as the server name in the formula, use @Subset(@DbName; 1). This way, you don't need to know the name of the server on which the application resides, you simply need to make sure the application and help database are on the same server.
Examples The following example opens the topic Main_F in the (Help) view of the current database when the user presses F1.
This next example opens the topic All_V in the (Help) view of the database discdoc.nsf, which resides on the same server as the application.
Creating context-sensitive help -- the basics Now that your planning is complete -- you did create that outline, didn't you? -- and you understand the syntax for OpenHelpDocument, you are ready to get started. The steps below detail a version of context-sensitive help in its simplest form. Perhaps that's all you'll need for your application; however, if you find you need more complexity, there is an Advanced section below that discusses additional ways to create context-sensitive help.
Advanced topics Now that you understand the simplest way to create context-sensitive help, let's talk about more complex context-sensitive help features. As mentioned above, there is nothing special about the HelpRequest event. It works just like any event by executing code that you write. The only limitations are that it uses only the Notes formula language (no LotusScript or JavaScript) and does not work for forms displayed in dialog boxes, for example with @DialogBox. Other than that, you can design a complex help system that uses any of the features supported by the Domino Designer. The following sections provide some ideas for more complex help systems. You can use them as is or modify them to meet the needs of your organization. These features are also included in the sample database.
Creating field-level help How many times have you been frustrated by an application when trying to figure out what to enter in a field? You press F1 and the help system tells you how to fill out the form. You know how to fill out the form, but what the heck are the parameters for the xyz field? If you want, you can use JavaScript to create field-level help; however, you cannot use JavaScript to respond to a HelpRequest event (that is, when the user presses F1). For information on using JavaScript to create field-level help, see the article "Creating field help for your Domino applications". If you want to display field-level help whenever a user presses F1 in an application, you can use both the field Entering event in LotusScript and the HelpRequest event for the form to provide application context-sensitive help. Here's how to do it:
Displaying a list of topics for a design element If you want to give users a choice of topics when they are using a form, view, page, or folder, simply use @Prompt to display the list of choices when the user presses F1. Then, after the user makes a choice, use OpenHelpDocument to open the document.
You can see an example of this in the sample Discussion database when you read or edit a Response document.
Creating context-sensitive help for Web applications Since the browser does not capture when users press F1 in an application, you must program a button or action that displays help for Web users. If your application serves a dual-purpose for Web users and Notes users, you will want to hide the button or action from Notes users. Creating context-sensitive help for Web applications is as easy as programming that button or action using the OpenHelpDocument command. Here's an example of the Main topic form that includes a Help action button:
Using additional keywords for searching As you probably already know, full-text search displays topics that contain a word in the document. This makes it difficult for users to search for synonyms. For example, if you use the word “personnel” in your help topics and users use the word “staff” when searching for those documents, they won't find the documents. One way to correct this problem is to add synonyms to a hidden field in the document. When a user searches for the synonym, Notes displays the topics that contain the synonym in the hidden field. We added a field named "Synonyms" to the Topic1 form in the sample help database. This field is not available in the system help template that you can download from the Web.