设计帮助系统

Question

我正在为一个桌面应用程序(Win32)实现一个帮助系统，并且正在寻找如何去设计它。

帮助系统应该有什么样的结构，对用户有什么实际的帮助？例如，帮助系统应该是一个很大的常见问题列表(office 2010帮助似乎是这样的)？或者它应该是一个记录和描述所有功能的功能列表(这可能只在用户不确定他们已经知道的功能如何工作时才有帮助)

我应该期望最终用户具备哪些知识？在帮助文件中写入File -> Open Project关闭当前项目(如果存在)并打开现有项目可能有些贬低。

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

Answer 1

“开放项目”也可以很好地引用项目的定义，以及与项目开放相关的其他更一般的描述和程序。

一般而言，CHM帮助可以通过上下文相关帮助(这是典型的文件->打开案例)访问，也可以通过常规目录、全文搜索和索引访问。大多数最新的应用程序似乎只为每个容器创建一个帮助页面(对话框，或pullodwn菜单)，在那里他们列出了该屏幕上的所有项目(例如，通过带注释的屏幕截图)，而不是GUI中的每个项目(复选框，菜单项)的引理。更少的混乱和导航，许多点只需要相当简短的描述

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

CHM有点像电子书，有一个目录(TOC)，索引和可选的全文搜索支持。

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

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

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

在与Microsoft产品进行比较时要小心。他们有时会使用终端用户/开发人员还不能使用的系统。

Good help使用所有这些元素。

Answer 2

大体上有两种类型的帮助:基于引用的(即此复选框意味着什么？)和基于任务的(如何实现XYZ?)。

你最好先创建一个基于任务的教程，必要时再用FAQ辅助。