这些天帮助文件的处理是什么？

Question

我在用户的观点中添加了这个问题在SuperUser 。

所以我在Delphi或.NET中创建一个可以在桌面系统上运行的应用程序。一些不错的GUI，具有各种功能和不错的功能。它运行良好，测试告诉我它几乎没有错误，我即将部署它......

等待！它需要一个帮助文件，因此用户可以从应用程序中调用上下文相关的帮助！

不是吗？这些天帮助文件真的是桌面应用程序的必需品吗？他们真的需要对上下文敏感吗，让用户的手告诉他们，他们必须填写标记为“出生日期”的字段中的出生日期？或者帮助文件变得有点过时了？

这是我想知道的，这有点主观，所以相反，我会向开发桌面应用程序的所有人提出一些不同的东西：你（仍）提供上下文敏感的帮助文件吗？

是，或者不，请。随意添加一些主观文本，但对我而言，重要的是了解现代开发人员是否仍在为其GUI应用程序添加上下文相关的帮助。

（顺便说一下，我自己已经转移到非上下文PDF文件，可以手动打印。维护起来要容易得多。）

Answer 1

是的，我知道。

原因： 我不能指望用户知道程序是如何工作的。好的，描述必须被输入“出生日”的内容。字段有点极端，但软件系统中通常有更复杂的东西。我今天必须为我们的成本会计系统编写一个帮助文件，描述用于确定应该用于计算的价格的系统如何工作。我不认为任何用户会知道如何使用此帮助文件配置系统。

Answer 2

以用户身份发言，而不是开发人员 - 是的，我想要一个上下文敏感的帮助文件。

例如 - 我目前正在评估第三方控件是否包含在新项目中。具有良好上下文敏感帮助的控件（即您可以在属性窗口中选择属性，或在代码中选择关键字，然后按F1直接进入帮助主题）可以更容易学习和使用。

Answer 3

我们目前没有，但我们不会编写很多Windows应用程序。大多数是基于网络的。我们的大多数Windows应用程序都相当小，并且在帮助文件之外有详细记录。

此外，我们还有最终用户在开发过程中编写文档，因此文档是他们可以理解的。

但是，如果我为很多用户（不是内部应用程序）编写大型应用程序，我会包含一个上下文相关的帮助文件。我过去为一些较大的应用程序做过，在非内部情况下，它非常有帮助。

实际上，我们现在正在设计我们的网站以获得“需要帮助”。功能是上下文相关的，该功能已被广泛接受。无论是对于我们公司的网站还是内部网站，我们现在都将其整合到我们的所有Web开发中。

Answer 4

没有帮助？对于那些有技术倾向并喜欢玩新软件的人来说，这很好。但是，如果您的软件将被那些不懂技术的人使用，那么帮助是至关重要的。以你的约会为例。如果你有一个国际市场，你最好说清楚该计划需要什么。美国人使用MM / DD / YYYY格式，但大多数国际用户使用DD / MM / YYYY;你需要说明程序需要什么。

我和很多开发人员合作过，他们对最终用户及其运营方式一无所知。例如，坚持他的新公司的CTO应该废弃可打印文档，而不知道他们的客户每次有更新时都会打印所有PDF和大多数帮助主题。您必须了解最终用户和市场。不幸的是，太多的开发者生活在泡沫中，被其他开发者所包围。

开发人员应该写帮助吗？可能不是。除非你真的能像典型的最终用户一样思考，否则让技术作家将技术信息分解到最终用户所需的水平。

Answer 5

在最近的一个应用程序中，我们没有提供上下文相关的帮助。这有技术原因而不是其他任何东西（帮助文件本质上是一个多语言的docbook文件，理论上支持上下文相关的帮助，但它不能很好地工作）。它为应用程序中的每个窗口/对话框提供了一个页面，并解释了所有控件。但是，每个控件还具有相当全面的工具提示，这大多消除了对其他帮助的需求。每个对话框都有一个帮助按钮，用于显示特定于对话框的页面。从历史上看，您可以将工具提示文本存储在帮助文件中，但这似乎不适用于最近的帮助系统。而且无论如何它们都存储在资源中。

但是，它并不适合所有人。由于可以通过应用程序管理的网络系统本身就是一个复杂的主题，因此无论如何都要对用户进行特殊培训，并且应用程序的设计使得如果您了解网络系统，您也会知道应用程序。换句话说，应用程序模型与用户模型很好地排列在一起，因此不需要全面的帮助功能。这应该是任何应用程序开发的目标。

有关控件的帮助文件中的大多数信息并不比工具提示中的信息更多，因为没有人需要更多信息。

Office和Visual Studio解决了相似的问题 - 按下帮助会打开整个对话框的帮助页面，而不是单个控件。

如果您的对话框的一部分非常复杂，需要进行额外的解释（并且考虑到您无法重新设计它以使其更容易），您可以将解释放在控件旁边。这在特殊情况的许多应用程序中使用，因此工作流程不会中断，因为用户必须查找例如如何编写特定文本。

Answer 6

我从来没有在应用程序中提供上下文相关的帮助，也没有看到它在任何其他应用程序中实现得足以让我自己使用它。在我看来，做到这一点所需的努力超过了收益。

在最后一个应用程序中，我参与了必须做出这个决定的地方，我们在应用程序中使用了工具提示气球，当用户在每个控件上方悬停时显示文本气球。我们还提供了一个传统的手册，主要是通过大量逐步截图的演练。

过了一段时间，用户厌倦了气球并用我们提供的复选框关闭了它们，但它似乎确实有助于初学者开始。

Answer 7

我们的所有应用程序都以工具提示的形式提供了上下文相关的帮助（类似于Office 2007提示），用于应用程序的所有关键功能。

虽然我们不提供传统的，完整的帮助文件，但我们肯定有一个知识库，我们会定期更新。这是通过电话，电子邮件等方式向客户提供的有关任何和所有问题的所有帮助的集合，正确分类和易于搜索。这最终成为最好的帮助，包含或多或少的客户所寻找的内容，而不是我们最初认为他们可能需要的内容。

虽然一些客户总是在没有看到知识库的情况下最终联系我们，但它仍然有助于我们一次又一次地重新发明轮子。

Answer 8

我给你一个个人意见，不受我个人品味的任何其他事实的支持。

过去编写帮助文件很有用，一切都是新的，在线资源很少。今天，大多数计算机用户通过直接探索学习。工具提示形式的上下文帮助非常棒，并且受到强烈鼓励：它提供了这种探索性学习的提示。

如果有大量链接的帮助文档可以点击？它显然很棒，但我很少用。在大多数情况下，用户可以通过正确的谷歌搜索获得答案。而且，这种文档昂贵。它不能由开发人员编写。您必须为此聘请或分配特定人员，并将技术写作和清晰度作为相关技能。

如果我必须管理这个决定，我会提供完整的文档，仅针对您的应用程序非常深奥和特殊（我会说是独特的）功能。在任何情况下，我都会倾向于在线教程，而不是上下文帮助文件。这样做的另一个好处是可以提供有关使用应用程序有多困难的信息，以及最受欢迎的热点（通过评估点击和引荐来源搜索查询到您的在线文档）。

Answer 9

使用工具提示和用户普遍增加的计算机能力，一些应用程序可以在没有帮助文件的情况下正常运行。但是，某些应用程序需要帮助文件，一般主题信息和应用程序使用情况一样多。例如，在照片应用中，您可能想要解释jpeg压缩并在帮助文件中包含一些示例，即使用户操作不言自明。

在我看来，微软是上下文敏感帮助下降的贡献者，无论好坏。首先，Visual Studio中的帮助系统是温和的，使用起来很痛苦。其次，Visual Studio的帮助系统的易用性显着下降。我会省略咆哮，但足以说它需要许多更多的点击和滚动来获取VS2008帮助中的相关信息。这往往会为应用程序中的帮助系统设置较低的标准。