The usual solution to this problem is context sensitive field help. Developer tools for writing user help in Notes have improved over the years, but field help is still pretty dismal. While the main advantage of Notes field help is that it's tied programmatically to the field, it has several problems:

• You often need a lot more space than the 70 characters that field help provides. If you write multilingual applications, you're advised to limit this to 55 characters;

• The user might have field help turned off;

• Even if field help is turned on, the user might not notice it because there's no visual connection with the field;

• If you use a computed field with, say, a button to set the field values, the user can't get at the field help;

• Field help doesn't work on the Web.

In this article, we'll explore the idea of using dialog boxes to solve the context sensitive field help problem in the Notes client. I'll show some examples to give you an idea from the usability perspective. Then I'll show you how to construct a help form and the code used to call it. Along the way, we'll cover design techniques and conclude with a few ideas for enhancements.

Pros and cons
The help dialog approach has several powerful advantages, but, like most things in Notes, there are significant trade-offs. One of the first things you'll notice is that dialog boxes are modal, which means the user can't complete the form with the dialog box open. To solve this, we use the fact that a dialog box opens the current document with a different form. So you can put the actual document field on the help form, right next to your explanation. This really holds the context together. The user opens the help, completes the field, and presses OK. Then the user is returned to the main document with the field updated.