我正在为桌面应用程序（Win32）实现一个帮助系统，并且正在寻找如何设计它。
帮助系统应该有什么样的结构，对用户有什么实际帮助？例如，帮助系统是否应该是一大堆常见问题解答（office 2010 的帮助似乎是这样的）？还是应该是一个功能列表，记录和描述所有功能（这可能仅在用户不确定他们已经知道的功能如何工作时才有用）
我应该期望最终用户拥有什么样的知识？在帮助文件中写入File->Open Project关闭当前项目（如果存在）并打开现有项目可能有点贬低。
我在这里寻找的是一些指导，任何好的帮助系统都应该具备的一组功能，以及一种以用户可以找到的方式组织主题的方法。
“打开项目”也可以作为参考项目定义的好地方，以及与项目打开有关的其他更一般的描述和程序。
一般来说，CHM 帮助可以通过上下文相关帮助（这是典型的文件->打开案例）和通用目录、全文搜索和索引来访问。大多数最近的应用程序似乎只为每个容器创建一个帮助页面（对话框或下拉菜单），它们在其中列出该屏幕上的所有项目（例如通过带注释的屏幕截图），而不是每个项目的引理（复选框，菜单条目）图形用户界面。更少的混乱和导航，许多点只需要相当简短的描述
除了上下文相关的帮助外，还可以通过帮助系统浏览帮助。
CHM 有点像电子书，具有目录 (TOC)、索引和可选的全文搜索支持。
索引和全文搜索是用户搜索内容的方式。主要区别在于索引更受您的控制，并且全文搜索在启用时基本上是自动的。
TOC 是节点的树状视图，其作用类似于书中的 TOC，并且应该固定“电子书”的一般结构。常见问题解答通常是本 TOC 的附录。
除此之外，还有一个默认的“入口”页面，就像一个网站的主页。它应该将用户导航到最常搜索的主题。
与 Microsoft 产品进行比较时要小心。他们有时会使用尚未供最终用户/开发人员使用的系统。
好的帮助使用所有这些元素。
大致有两种风格的帮助：基于参考的（即这个复选框是什么意思？）和基于任务的（我如何实现 XYZ？）。
您可能最好先创建一个基于任务的教程，如有必要，由常见问题解答支持。