设计帮助系统

Question

我正在为桌面应用程序（Win32）实现帮助系统，并且正在寻找如何进行设计。

帮助系统应具有什么样的结构，实际上对用户有什么帮助？ 例如帮助系统是否应该是FAQ的重要清单（2010年办公室帮助看起来像这样）？还是应该是记录和描述所有功能的功能列表（这可能仅在用户不确定他们已经知道的功能如何工作时才有用）

我希望最终用户具备哪些知识？将帮助文件中的File-> Open Project写入帮助文件可能会略有贬义。关闭当前项目（如果存在）并打开现有项目。

我在这里寻找的是一些指导，任何好的帮助系统都应具有的功能，以及以用户可以找到它们的方式组织主题的方法。

Answer 1

“开放项目”也可以是参考项目定义以及其他与项目开放有关的更一般性描述和程序的好地方。

通常，CHM帮助可以通过上下文相关的帮助（对于文件->打开情况是典型的）或通过目录，全文本搜索和索引来访问。最新的应用似乎只为每个容器创建一个帮助页面（对话框或pullodwn菜单），在那里它们列出该屏幕上的所有项目（例如，通过带注释的屏幕截图），而不列出每个项目的引理（复选框，菜单项） GUI。更少的混乱和导航，并且许多点只需要一个简短的描述

除了上下文相关的帮助外，还可以通过帮助系统浏览帮助。

CHM有点像一本电子书，它具有目录（TOC），索引以及对全文搜索的支持。

索引和全文搜索是用户搜索内容的方式。 主要区别在于索引更多地在您的控制范围内，启用时全文搜索在很大程度上是自动的。

TOC是节点的树状视图，其作用类似于一本书中的TOC，并应固定“电子书”的一般结构。常见问题解答通常是本目录的附录。

除此之外，还有一个默认的“输入”页面，类似于网站的主页。它应该将用户导航到最常搜索的主题。

与Microsoft产品进行比较时要小心。他们有时使用的系统尚不适用于最终用户/开发人员。

好的帮助会使用所有这些元素。

Answer 2

大致有两种帮助样式：基于参考的（即此复选框是什么意思？）和基于任务的（如何实现XYZ？）。

最好先创建一个基于任务的教程，并在必要时通过FAQ进行备份。