لطفا منتظر باشید ...
The Last Word
This chapter began with the built-in .NET Framework support for Help, and then began to expand on it with integrated help and animated agents. In the process, the chapter delved into the old world of ActiveX components, demonstrating that COM is far from gone, even after the .NET revolution.Help strategies and systems vary widely depending on the intended audience and the application design. In this chapter we toured the wide and diverse world of Help programming. None of the solutions examined here can be used in every scenario. Instead, it helps to keep some basic principles in mind:
A help file should describe the purpose of various settings, not how to use common controls. No one needs an explanation about how to click a check box. Instead, users need to know why they should click the check box.
The best affordances are descriptive labels, not instructions. No dialog box has the space or formatting power of a printed document.
The best error is one that doesn't happen. It may take more effort in your code to disable or hide invalid options, but it prevents dozens of common mistakes in the input fields.
Help must be context-sensitive. A confused user won't search through a Help file to find a relevant topic—a printed document is better at that.
Perform usability tests. When writing a program, you design based on who you believe the audience is. At some point, you need to bring in some new users, and find out what their capabilities really are.
