Developing context-sensitive Help and making it work in an application requires authors and developers to work as a team. A good way to facilitate this team effort is to create a plan that identifies what you need to accomplish and how you can implement it. Outlining a strategy for designing and implementing context-sensitive Help sets expectations and identifies dependencies, so both you and your developer can create well-designed information within the project time frame.
To devise a plan, take the following into consideration:
Platform: What platform is the application being developed for? Most authors are creating context-sensitive Help for Windows applications. However, you may need to create projects that run on other platforms such as UNIX or the Mac. The way you develop your context-sensitive Help depends on the platform the application supports.
User interface: Do you need to create Help for windows and dialogs or for particular fields and controls at dialogs? You need to determine whether you are creating window-level Help or What's This? Help. You might even need to create a combination of both.
Map files: Who will be creating the map files that are used to make context-sensitive Help functionality happen? Is the developer providing you with the files? Are you creating them in a text editor such as the Windows Notepad? Do you want RoboHELP to automatically generate them for you?
Topics: What are all the components in the application that require context-sensitive Help? When will you create the Help topics and how? For window-level Help and cross-platform Help, you create the topics in the WYSIWYG Editor. For What's This? Help, you can create the topics in RoboHELP as text-only topics. You can also use What's This? Help Composer to create them. (What's This? Help Composer is an eHelp program that is copied on your system when you install RoboHELP.)
Naming conventions: If you are creating the map files (or if RoboHELP is automatically creating them for you), what names are you going to assign the topic IDs? Do you need to assign map numbers individually? Or can your developer use map numbers automatically generated by RoboHELP? This is important to consider in advance because both you and the developer need to work with the same naming conventions.
Custom windows: If you are creating window-level Help, decide if you are creating a custom window to display the topics. Most likely, you will want the topics to appear in a separate window (other than the tri-pane Microsoft HTML Help viewer). After you design this window, your developer needs to know the name to code it into the application.
Testing: Who will test the context-sensitive Help and how? Who is going to fix the ones that do not work? You might need to work with your Quality Assurance team when testing and reporting errors. Are you going to test each topic individually by calling it from within the application? What if the application is not available? If you have RoboHELP Office, you can use BugHunter to test your topics and identify errors. This is especially useful if you are testing window-level Help topics and you do not have access to the application.
Maintenance: How will you know when changes are made in the application that affect your context-sensitive Help? Are there new dialogs to write about? Are there obsolete ones to remove? Have fields and controls changed at dialogs? You need to regularly communicate with your developers to keep up with the changes made to the application.