我在 SuperUser 处添加了这个问题以供用户查看。
所以我在 Delphi 或 .NET 中创建了一个将在桌面系统上运行的应用程序。一些不错的 GUI，具有各种功能和不错的特性。它运行良好，测试告诉我它几乎没有错误，我即将部署它......
等待！它需要一个帮助文件，因此用户可以从应用程序中调用上下文相关的帮助！
或不？如今，帮助文件真的是桌面应用程序的必需品吗？他们真的需要上下文相关，握住用户的手告诉他们必须在标有“出生日期”的字段中填写出生日期吗？还是帮助文件变得有点过时了？
这是我想知道的事情，这有点主观，所以我要问一些不同的问题，给所有开发桌面应用程序的人：你们（仍然）提供上下文相关的帮助文件吗？
是，或者不是，请。随意添加一些主观文本，但对我来说，重要的是知道现代开发人员是否仍在向他们的 GUI 应用程序添加上下文相关的帮助。
（顺便说一句，我自己已经转向可以手动打印的非上下文 PDF 文件。它更容易维护。）
是的，我愿意。
原因：我只是不能指望用户知道程序是如何工作的。好的，描述必须输入“出生日期”字段的内容有点极端，但软件系统中通常有更复杂的内容。我今天不得不为我们的成本会计系统编写一个帮助文件，描述用于确定应该用于计算的价格的系统是如何工作的。我认为没有这个帮助文件，任何用户都不会知道如何配置系统。
作为用户而不是开发人员说话 - 是的，我想要一个上下文相关的帮助文件。
例如 - 我目前正在评估 3rd 方控件是否包含在新项目中。具有良好上下文相关帮助的控件（即您可以在属性窗口中选择一个属性，或者在代码中选择一个关键字，然后按 F1 键直接进入帮助主题）非常容易学习和使用。
我们目前没有，但我们没有编写很多 Windows 应用程序。大多数是基于网络的。我们的大多数 Windows 应用程序都相当小，并且在帮助文件之外都有很好的文档记录。
此外，我们让最终用户在开发过程中编写文档，因此他们会理解文档。
但是，如果我正在为很多用户编写一个大型应用程序（不是内部应用程序），我会包含一个上下文相关的帮助文件。我过去曾为我们的一些较大的应用程序这样做过，在非内部情况下，它非常有帮助。
实际上，我们现在正在设计我们的网站，使其具有上下文相关的“需要帮助”功能，并且该功能已广受欢迎。我们现在将它整合到我们所有的 Web 开发中，无论是用于我们公司的网站还是内部的。
没有帮助？这对于那些有技术倾向并喜欢玩新软件的人来说很好。但是，如果您的软件将被不精通技术的人使用，那么帮助是必不可少的。以您的日期为例。如果你有一个国际市场，你最好说明程序需要什么。美国人使用 MM/DD/YYYY 格式，但大多数国际用户使用 DD/MM/YYYY；你需要说明程序需要什么。
我曾与许多完全不了解他们的最终用户以及他们如何运作的开发人员一起工作。例如，一位 CTO 坚持他的新公司应该取消可打印文档，却不知道他们的客户在每次更新时都会打印所有 PDF 和大部分帮助主题。你必须了解你的最终用户和你的市场。不幸的是，太多的开发者生活在泡沫中，被其他开发者包围。
开发人员应该写帮助吗？可能不是。除非你真的能像典型的最终用户那样思考，草拟笔记，但让技术作家将技术信息分解到最终用户需要的水平。
我从来没有在应用程序中提供过上下文相关的帮助，也没有看到它在任何其他应用程序中实现得足够好，以至于我自己也无法使用它。在我看来，要做到这一点所需要的努力超过了收益。
在我参与的最后一个必须做出此决定的应用程序中，我们在应用程序中使用了工具提示气球，当用户将鼠标悬停在每个控件上时，它会显示一个文本气球。我们还提供了一本传统的手册，其中大部分是带有大量分步截图的演练。
一段时间后，用户厌倦了气球并使用我们提供的复选框将其关闭，但它似乎确实有助于初学者入门。
我给你个人意见，没有任何其他事实支持我的个人品味。
在过去，一切都是新的，在线资源稀缺，编写帮助文件很有用。今天，大多数计算机用户通过直接探索来学习。工具提示形式的上下文帮助非常有用，并且强烈鼓励：它为这种探索性学习提供了提示。
带有大量可点击链接的帮助文档怎么样？好吧，这显然很棒，但我猜很少使用。在大多数情况下，用户可以通过适当的谷歌搜索获得答案。而且，这种文档是昂贵的。它不能由开发人员编写。您必须为此雇用或分配特定人员，并具有技术写作和清晰度作为相关技能。
如果我必须做出这个决定，我只会为您的应用程序非常深奥和特殊（我会说独特）的那些功能提供完整的文档。在任何情况下，我都会倾向于在线教程，而不是上下文帮助文件。这具有额外的优势，可以提供有关使用您的应用程序的难度以及最常请求的热点是什么（通过评估您的在线文档的点击率和引荐来源搜索查询）的信息。
在最近的一个应用程序中，我们没有提供上下文相关的帮助。这有技术原因，而不是其他任何原因（帮助文件本质上是一个多语言 docbook 文件，理论上支持上下文相关帮助，但效果不佳）。它为应用程序中的每个窗口/对话框提供一个页面，并解释了所有控件。但是，每个控件也有一个相当全面的工具提示，这在很大程度上消除了对额外帮助的需要。每个对话框都有一个帮助按钮，用于显示特定于对话框的页面。从历史上看，您可以将工具提示文本存储在帮助文件中，但这似乎不适用于最近的帮助系统。无论如何，它们都存储在资源中。
但是，它并不是适合所有人的应用程序。由于可以通过应用程序管理的网络系统本身就是一个复杂的话题，因此无论如何都要对用户进行专门的培训，并且应用程序的设计是让您了解网络系统，您也了解应用程序。换句话说，应用程序模型与用户模型非常吻合，因此不需要全面的帮助功能。这应该是任何应用程序开发的目标。
帮助文件中有关控件的大多数信息实际上并不比工具提示中已有的信息更多，因为没有人需要更多信息。
Office 和 Visual Studio 解决的问题非常相似 - 按帮助会打开整个对话框的帮助页面，而不是单个控件。
如果您有一个对话框的一部分非常复杂以至于需要额外的解释（并且鉴于您无法重新设计它以使其更容易），您可以将解释放在控件旁边。这在许多特殊情况下的应用程序中使用，因此工作流程不会因为用户必须查找（例如必须如何编写特定文本）而中断。
我们所有的应用程序都以工具提示（类似于 Office 2007 提示）的形式为应用程序的所有关键功能提供上下文相关帮助。
虽然我们不提供传统的、全面的帮助文件，但我们肯定有一个我们会定期更新的知识库。这是通过电话、电子邮件等向客户提供的关于任何和所有问题的所有帮助的集合，分类正确且易于搜索。这最终会成为最好的帮助，它或多或少包含客户所寻找的东西，而不是我们最初认为他们可能需要的东西。
虽然一些客户总是在没有看知识库的情况下联系我们，但它仍然帮助我们一次又一次地重新发明轮子。
随着工具提示和用户计算机能力的普遍提高，一些应用程序在没有帮助文件的情况下也能正常工作。但是，某些应用程序需要帮助文件，包括一般主题信息和应用程序使用情况。例如，在照片应用程序中，您可能想要解释 jpeg 压缩并在帮助文件中包含一些示例，即使用户操作是不言而喻的。
在我看来，无论是好是坏，微软都是导致上下文相关帮助下降的原因之一。首先，Visual Studio 中的帮助系统，说得委婉些，使用起来很痛苦。其次，Visual Studio 帮助系统的易用性明显下降。我将省略咆哮，但我只想说需要更多的点击和滚动才能在 VS2008 帮助中获得相关信息。这往往会为应用程序中的帮助系统设置较低的标准。