动态帮助

动态帮助是一种嵌入式的帮助。和标准帮助不同，它不出现在独立的窗口中，而是在用户界面内。用户不用手动调出动态帮助，它是自动出现的。和静态的嵌入式帮助不同，当程序中的掩膜或者数据改变的时候，动态帮助会根据上下文调整其内容。图 1 显示的是最简单的动态帮助形式。它直接在要操作的位置上显示出具体的步骤。操作完毕后，帮助信息会再次消失。图 2 显示的是经典形式的动态帮助。它位于实际的程序窗口旁，但与其固定相连。它有相对较大的空间来显示内容，但是比显示在独立窗口中的标准帮助要小得多。 通常人们有意不将动态帮助称为“帮助”，而是像图 2 示例中那样命名为“建议” 或者“提示”。这样比较能吸引那些声称自己不阅读任何帮助的用户。

优点和缺点

若要确定什么时候采用动态帮助是真正合理的，什么时候会造成干扰，我们必须理解动态帮助的具体优缺点。

主要的优点有：

• 动态帮助直接在问题产生的地方，即所谓的 Point of Confusion 提供解答。
• 信息就在需要的时候直接出现在那里：时间正确，位置正确。
• 没有心理障碍：用户无需承认他需要帮助。
• 没有交互：用户不用自己主动去获取帮助。
• 因其语境敏感性，动态帮助始终与任务紧密相关。
• 动态帮助可以减轻其它文档部分的负担，让其变得更紧凑。

 

图 1 最短的动态帮助 来源：Open Office

 

图 2 经典形式的动态帮助 来源：Corel Draw

主要的缺点有：

• 动态帮助让屏幕更杂乱。如果用户不需要所提供的信息，他们必须在头脑中将其忽略。
• 动态帮助中没有结构安排，没有等级也没有顺序。
• 用于显示内容的空间很小。
• 只有少数几个辅助制作工具（Help-Authoring-Tools）明确支持创建动态帮助。
• 动态帮助的开发与链接需要 UI 设计、开发与技术编辑之间紧密协调。
• 和单纯的标准帮助相比，其制作投入和成本更高。

采用帮助的标准

当优点占据主导的时候，使用动态帮助即总是合理的。典型的情况有：

• 当真的经常需要用到信息的时候，也就是值得为此设置额外的空间，占用屏幕的时候
• 当信息是关键的成功因素，也就是特别重要的时候；这时候也值得为动态帮助预留出空间；
• 当信息单元都很短并且与语境相合时；当要传递的信息很适合采用动态帮助的形式时
• 除此之外不阅读任何文档的用户，这时动态帮助就更重要了
• 设备和程序的屏幕有充足的空间；否则就无法合理地采用动态帮助

尤其是在以下情况中：

• 在产品的使用初期；在用户还是新手的时候，其信息需求是很大的
• 仅是偶尔才使用的产品；在这种情况中多数用户永远无法脱离新手阶段，因为到下次使用的时候很多东西都已经又忘了
• 用户较少愿意花费力气去熟悉的产品，例如网页应用；如果在这里提供单独的文档，用户将不会去阅读
• 在需要输入特定数据的产品中；这里的信息需求特别大并且与语境的关联也很紧密

所以很多个人纳税申报程序都提供动态帮助功能，这种情况并非偶然：

• 这些程序只是偶尔使用，通常一年才用一次。
• 使用这些程序需要很多的参考信息：税务表格的各个区域要输入哪些数据？

 

图 3 程序端的动态帮助 来源：ELSTER

合适的内容

之所以需要对内容进行处理，主要是因为空间有限。移动设备上的技术文档即有类似的情况：

• 简洁的写作风格
• 不用大图片
• 不用宽表格，取而代之的是与媒介相适应的呈现方式，例如可扩展的段落
• 采用 80% 的规则，不追求完整性；集中于较早需要的信息、经常需要的信息和关键的信息上

动态帮助要提供什么内容，很大程度上取决于相关的产品及其目标群体。重点可能是参考信息以及操作指导。 但是，动态帮助通常无法说明任何全面的概念和流程。动态帮助同样也无法展示如何开始某个操作。因为只有当用户将相应的程序点调出在屏幕上之后，动态帮助才会出现。因此，在很多情况下必须通过标准帮助来补充动态帮助。

为动态帮助选择主题时，要采用以下基本规则：收录用户最可能用到的内容。此外，相对于可选的信息，优先采用关键信息，并且相对于过后需要的信息，优先采用在产品使用早期需要用到的信息。这些标准同样可以用作内容结构规划的基础：

• 将涉及最多用户的信息前置。
• 将关键的信息前置。
• 将特别早就需要用到的信息前置。

依据语境链接

根据语境链接动态帮助的时候，您可以分多个层次进行：

• 您可以根据程序页面控制动态帮助的主题，让动态帮助的内容随着每个新的窗口、每个新的对话框或者新的选项卡变化。
• 您可以根据栏来调整动态帮助的主题，一旦用户在新的栏中插入光标，即作出调整。
• 您甚至可以将动态帮助的内容与特定栏中的数值进行关联。

总的来说建议根据需要分散链接，但尽可能全局布置。通过这种方式您可以避免不断更换主题造成的过度不安，并且您也可以在动态帮助中描述跨栏的关系和相互作用。此外，主题越少，创建和管理支出就越少。

图 3 是程序页面（此处是一个税表）上的一个动态帮助。如果用户将光标放到某些栏，动态帮助就会显示关于这些栏的信息，见图 4。此外，并非每个单独的栏都要有自己的帮助页面。某些栏构成的组也可以共用动态帮助。

 

图 4 单一栏的动态帮助 来源：ELSTER

对于动态帮助内部的导航或者从动态帮助到标准帮助的导航，这里总结以下建议：

• 有节制地使用链接；通常少即是多，并且不要引导阅读者过早离开主题。
• 不要在文本内使用连接；将相关主题的链接集中到主题的末尾。
• 不要链接到动态帮助的其它主题；在程序中操作时，
• 这些主题总归会自动出现。仅链接到标准帮助的主题。
• 在一个单独的窗口中打开标准帮助。

图 5 是一个动态帮助示例，带有到附属的标准帮助的链接。

 

图 5 动态帮助中一个主题的结构与链接 来源：SoftwareDemo

优化设计

您还记得“Karl Klammer”那个神经兮兮的回形针吗，又名“Clippy”，几年前总是在人们最不需要它的时候在微软的 Office 软件中动来动去。Clippy 也是一种动态帮助。这个形象创意是失败的，因为它造成了太多的干扰。Karl Klammer 出现在屏幕上时的动画、它旁边显示的黄色会话气泡总是会吸引用户的全部注意力并打断他们的工作。从这个失误中吸取教训吧。

将您的动态帮助设计得不引人注目，使其不会分散人们对程序的注意力。一般而言这意味着，其设计要比程序的用户界面更有节制。选择较为柔和的颜色、使用较小的字体、弱化粗体设置，例如使用灰色取代黑色。不要使用多彩的图片和动画。 同时设计要与程序协调。由于程序与动态帮助总是同时可见的，所以这种协调性比在标准帮助中更重要。其它的要求是由十分有限的使用空间导致的：不要选择过大和过宽的字体，有意识地处理空白的位置。此外务必要为高阶的用户提供关闭动态帮助的途径。

创建和链接到软件

只有几个辅助制作工具（ Help-Authoring-Tools）支持创建与显示动态帮助：Flare（仅 DotNet Help Target），DocToHelp 和 HelpStudio。但使用其它应用程序您也可以创建动态帮助：

• 开发人员必须往软件中嵌入一个能够显示 HTML 页面的所谓 Control（控制器）。这类控制器有现成的可以购买。
• 您必须与开发部协调确定，控制器什么时候要加载什么 HTML 页面，也就是要加载哪些具体的动态帮助。在理想情况下，开发人员不用将文件名固定写入程序代码中，而是在执行的时候读取一个映射表。此类映射表可以是，例如以 XML 为基础的，并包含窗口与附属帮助页面之间的对应关系。和固定输入到程序代码中相比，它的优点是，您可以随时方便地更新对应关系。
• 您必须制作动态帮助的内容，也就是它的主题。最好是用您在维护标准帮助时使用的同一辅助制作工具（ Help-Authoring-Tools）和项目来制作内容。这么做的好处是，需要时您可以在动态帮助与标准帮助之间重复使用内容 - Single-Source-Publishing（单一来源排版）。此外，您还可在熟悉的环境下工作并且可以使用现有的格式模板。

如果您在辅助制作工具中生成一个网页帮助，您将得到 HTML 文件，文件包含您可以将其作为动态帮助显示出来的主题。但是在一些辅助制作工具中您还需避开一个障碍：在这些工具中，主题包含了一个 JavaScript，直接调用主题时，它会重新加载整个帮助的导航：目录、索引和查找。由于您在动态帮助内通常是不需要这一导航的，您必须找到可以将其再次移除的方法。有时候只要选择一个合适的皮肤就可以，有时候只要对 HTML 文件进行额外的再处理。若使用合适的工具，则不用花费什么气力也可以让这种再处理步骤自动化。合适的工具有， Text Workbench（大约 50 美元）， PowerGREP（大约 119 美元）或者 TextPipe（大约 199 美元）。