如今帮助文件的情况如何？
我从用户的角度添加了这个问题在 SuperUser。
因此，我在 Delphi 或 .NET 中创建了一个将在桌面系统上运行的应用程序。一些不错的 GUI，具有各种功能和不错的特性。它运行良好，测试告诉我它几乎没有错误，我即将部署它......
等等！它需要一个帮助文件，以便用户可以从应用程序调用上下文相关的帮助！
或者不是？如今，帮助文件真的是桌面应用程序所必需的吗？他们真的需要上下文敏感，握着用户的手告诉他们必须在标有“出生日期”的字段中填写出生日期吗？或者帮助文件变得有点过时了？
这是我想知道的事情，而且有点主观，所以我要向所有开发桌面应用程序的人问一些不同的问题：你们（仍然）提供上下文相关的帮助文件吗？
请是或否。请随意添加一些主观文本，但对我来说，重要的是了解现代开发人员是否仍在向其 GUI 应用程序添加上下文相关帮助。
（顺便说一句，我自己已经转向可以作为手册打印的非上下文 PDF 文件。维护起来要容易得多。）
I added this question at SuperUser for the user's perspective.
So I create an application in Delphi or .NET which will run on a desktop system. Some nice GUI with all kinds of functionality and nice features. It works well, tests tell me it's nearly bug-free and I'm about to deploy it...
WAIT! It needs a help file, so users can call upon context-sensitive help from the application!
Or not? Are helpfiles really a requirement for desktop applications these days? And do they really need to be context-sensitive, holding the hands of the user to tell them they have to fill in their day of birth in this field labelled "Day of birth"? Or are helpfiles becoming a bit old-fashioned?
This is something I wonder about and this is a bit subjective, so instead I'm going to ask something different, to all of you who develop desktop applications: Do you (still) offer context-sensitive helpfiles?
Yes, or no, please. Feel free to add some subjective texts but to me, what is important is knowing if modern developers are still adding context-sensitive help to their GUI applications.
(Btw, I myself have moved to non-context PDF files that can be printed as manual. It's a lot easier to maintain.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
是的，我愿意。
原因：
我只是不能指望用户知道程序是如何工作的。好吧，描述必须在“出生日期”字段中输入的内容有点极端，但软件系统中通常有更复杂的内容。今天我必须为我们的成本会计系统编写一个帮助文件，描述用于确定计算所用价格的系统如何工作。我认为没有这个帮助文件，任何用户都不知道如何配置系统。
Yes, I do.
Reason:
I just can't expect the user to know how the program works. Ok, describing what has to be inputed into a "Day of birth" field is a bit extrem, but there's normally more complex stuff in a software system. I had to write a help file for our cost accounting system just today, describing how the system for determining the price that should be used for the calculation works. I don't think any user would know how to configure the system withoug this help file.
作为用户而不是开发人员发言 - 是的，我想要一个上下文相关的帮助文件。
例如 - 我目前正在评估第三方控件是否包含在新项目中。具有良好上下文相关帮助的控件（即，您可以在属性窗口中选择一个属性，或在代码中选择一个关键字，然后按 F1 直接转到帮助主题），学习和使用起来要容易得多。
Speaking as a user, not a developer - yes, I want a context sensitive help file.
For example - I'm currently evaluating 3rd party controls for inclusion in a new project. The controls that have good context sensitive help (i.e. you can select a property in the properties window, or a keyword in code, and press F1 to go straight to the help topic) are much, much easier to learn and use.
目前我们还没有这样做，但我们并没有编写很多 Windows 应用程序。大多数都是基于网络的。我们的大多数 Windows 应用程序都相当小，并且在帮助文件之外有详细的文档记录。
另外，我们让最终用户在开发过程中编写文档，因此文档是他们能够理解的。
但是，如果我正在为很多用户编写大型应用程序（不是内部应用程序），我将包含一个上下文相关的帮助文件。我过去曾为一些较大的应用程序做过此操作，并且在非内部情况下，它非常有帮助。
实际上，我们现在正在设计我们的网站，以提供上下文相关的“需要帮助”功能，并且该功能受到了好评。我们现在正在将其纳入我们所有的网络开发中，无论是我们公司网站还是内部网站。
We don't currently, but we don't write a lot of Windows apps. Most are web based. Most of our Windows apps are fairly small and well documented outside of a Help file.
Also, we have the ends users write the documentation during the development process, so the documentation is something they will understand.
However, if I were writing a large app for a lot of users (not an internal app) I would include a context-sensitive help file. I've done it in the past for some of our bigger apps, and in a non-internal situation, it's very helpful.
Actually, we're now designing our web site to have a "need help" feature that is context-sensitive, and the feature has been well-received. We're incorporating it into all of our web development now, whether for our company web site or internal.
没有帮助吗？对于那些有技术倾向并且喜欢尝试新软件的人来说这很好。但是，如果您的软件将由不懂技术的人使用，那么帮助就至关重要。以你的日期为例。如果您有国际市场，您最好阐明该计划需要什么。美国人使用 MM/DD/YYYY 格式，但大多数国际用户使用 DD/MM/YYYY；你需要阐明该程序需要什么。
我曾与许多开发人员合作过，他们对最终用户及其操作方式一无所知。例如，一位首席技术官坚持认为他的新公司应该取消可打印文档，但他不知道他们的客户每次更新时都会打印所有 PDF 和大部分帮助主题。您必须了解您的最终用户和市场。不幸的是，太多的开发人员生活在泡沫之中，周围都是其他开发人员。
开发人员应该写帮助吗？可能不会。除非您真的能够像典型的最终用户一样思考，否则请起草笔记，但让技术作家将技术信息分解为最终用户需要的级别。
No help? That is fine for people who are technically inclined and like to play around with new software. But if your software is going to be used by people who are not tech savvy, help is essential. Take your example of dates. If you have an international market, you better spell out what the program needs. Americans use a MM/DD/YYYY format, but most international users use DD/MM/YYYY; you need to spell out what the program needs.
I've worked with a lot of developers who had absolutely no clue about their end users and how they operate. For example, a CTO who insisted his new company should do away with printable documentation without knowing that their customers printed all the PDFs and most of the help topics every time there was an update. You have to know your end user and your market. Unfortunately, too many developers live in a bubble, surrounded by other developers.
Should developers write help? Probably not. Unless you can really think like your typical end user, draft notes but let a tech writer break technical information down to the level the end user needs.
在最近的应用程序中，我们没有提供上下文相关的帮助。这有技术原因而不是其他原因（帮助文件本质上是一个多语言文档文件，理论上支持上下文相关帮助，但效果不佳）。应用程序中的每个窗口/对话框都有一页，并解释了所有控件。然而，每个控件还有一个相当全面的工具提示，这基本上消除了对额外帮助的需要。每个对话框都有一个帮助按钮，用于打开特定于对话框的页面。从历史上看，您可以将工具提示文本存储在帮助文件中，但这似乎不适用于最新的帮助系统。无论如何，它们都存储在资源中。
但它并不适合所有人。由于可以使用该应用程序管理的网络系统本身就是一个复杂的主题，因此无论如何都要对用户进行专门的培训，并且该应用程序的设计目的是，如果您了解网络系统，那么您也了解该应用程序。换句话说，应用程序模型与用户模型非常吻合，因此不需要全面的帮助功能。这应该是任何应用程序开发的目标。
帮助文件中有关控件的大多数信息实际上并不比工具提示中已有的信息多，因为没有人需要更多信息。
Office 和 Visual Studio 解决的问题非常相似 - 按帮助将打开整个对话框的帮助页面，而不是单个控件的帮助页面。
如果对话框的一部分非常复杂，需要额外的解释（并且您无法重新设计它以使其更容易），您可以将解释放在控件旁边。这在许多应用程序中用于特殊情况，以便工作流程不会因为用户必须查找（例如必须如何编写特定文本）而中断。
In a recent application, we did not provide context-sensitive help. This had technical reasons rather than anything else (the help file is, essentially, a multi-language docbook file, which in theory supports context-sensitive help, but it didn't work well). It has one page for each window/dialog in the application, with all controls explained. However, each control also has a fairly comprehensive tooltip, which mostly removes the need for additional help. Each dialog has a help button to bring up the dialog-specific page. Historically, you could store the tooltip text in the help file, but that does not seem to work with recent help systems. And they're stored in resources anyway.
But then, it's not an application for everyone. Since the network system that can be managed with the application is a complex topic in itself, there's a special training for the users anyway, and the application has been designed so that if you know the network system, you also know the application. In other words, the application model lines up with the user model so well that comprehensive help features are not needed. This should be the goal of any application development.
Most information in the help files about the controls is not really more than what is already in the tooltip, because nobody needs more.
Office and Visual Studio solved the problem rather similar - pressing help opens the help page for the entire dialog, not for the single control.
If you have a part of a dialog that is so complicated that it needs additional explanation (and given you can't redesign it to make it easier), you can put the explanation right next to the control. This is used in many applications for special cases, so that the workflow is not interrupted because the user has to look up e.g. how a specific text has to be written.
我从未在应用程序中提供过上下文相关的帮助，也没有看到它在任何其他应用程序中实现得足够好，以至于我自己也无法使用它。在我看来，做好这件事所需的努力超过了收益。
在我参与的最后一个必须做出此决定的应用程序中，我们在应用程序中使用了工具提示气球，当用户将鼠标悬停在每个控件上时，它会显示一个文本气球。我们还提供了一份传统手册，其中大部分是演练，并带有大量分步屏幕截图。
一段时间后，用户厌倦了气球并使用我们提供的复选框将其关闭，但这似乎确实帮助了初学者入门。
I have never provided context-sensitive help in an application, nor have I seen it implemented well enough in any other application to ever use it myself. In my opinion, the effort required to do it well exceeds the benefit.
On the last application I was involved in where this decision had to be made, we used tooltip balloons in the application, which displayed a text balloon when the user hovered over each control. We also provided a conventional manual which was mostly walkthroughs with lots of step-by-step screenshots.
After awhile the users got sick of the balloons and turned them off with a checkbox we provided, but it did seem to help the beginners get started.
我们所有的应用程序都以工具提示的形式提供上下文相关的帮助（类似于 Office 2007 提示），以提供应用程序的所有关键功能。
虽然我们不提供传统的、完整的帮助文件，但我们肯定有一个定期更新的知识库。这是通过电话、电子邮件等方式向客户提供的有关任何和所有问题的所有帮助的集合，正确分类且易于搜索。这最终成为最好的帮助，或多或少包含客户寻求的内容，而不是我们最初认为他们可能需要的内容。
虽然一些客户最终总是在没有浏览知识库的情况下联系我们，但这仍然有助于我们一次又一次地重新发明轮子。
All our applications have context-sensitive help in the form of tooltips (similar to the Office 2007 tips) for all critical features of the application.
While we don't offer the traditional, full-blown help file, we definitely have a Knowledge Base which we update regularly. This is a collection of all help provided to clients via telephone, email, etc, on any and all issues, properly categorized and easily searchable. This eventually ends up being the best help that contains more or less what clients look for rather than what we initially think they may need.
While a few clients invariably end up contacting us without as much as a glance at the Knowledge Base, it still helps us from reinventing the wheel time and again.
我给你个人意见，没有任何其他事实支持我的个人品味。
在过去，一切都是新的并且在线资源稀缺，编写帮助文件很有用。今天，大多数计算机用户通过直接探索来学习。工具提示形式的上下文帮助非常好并且强烈鼓励：它为这种探索性学习提供了提示。
带有大量可供点击的链接的帮助文档怎么样？嗯，它显然很棒，但我猜很少使用。在大多数情况下，用户可以通过适当的谷歌搜索获得答案。此外，这种文档成本高昂。它不能由开发人员编写。您必须为此雇用或分配特定人员，并具备技术写作和清晰度等相关技能。
如果我必须做出这个决定，我只会为那些对您的应用程序来说非常深奥和特殊（我会说独特）的功能提供完整的文档。无论如何，我倾向于在线教程，而不是上下文帮助文件。这具有额外的优势，可以提供有关使用应用程序的难度以及最常请求的热点的信息（通过评估在线文档的点击率和引荐来源网址搜索查询）。
I give you a personal opinion, not supported by any other fact that my personal taste.
Writing help files was useful in the past, where everything was new and online resources were scarce. Today, most computer users learn by direct exploration. Contextual help in the form of Tooltips is great and strongly encouraged: it gives hints for this explorative learning.
What about help documentation with a lot of links to click around ? well it's apparently great, but used very seldom I guess. In most cases the user can obtain answers with a proper google search. Moreover, this kind of documentation is expensive. It cannot be written by a developer. You have to hire or allocate specific people for this, with technical writing and clarity as relevant skills.
If I had to manage this decision, I would provide full docs only for those features that are very esoteric and special (I would say unique) for your application. I would in any case tend towards an online tutorial, instead of contextual help files. This has the additional advantage to provide information about how difficult is to use your application, and what are the most requested hotspots (by evaluating the hits and referrer search queries to your online docs).
随着工具提示和用户计算机能力的普遍提高，某些应用程序无需帮助文件即可正常运行。但是，某些应用程序需要帮助文件，无论是一般主题信息还是应用程序使用情况。例如，在照片应用程序中，您可能想要解释 jpeg 压缩并在帮助文件中包含一些示例，即使用户操作是不言而喻的。
在我看来，无论好坏，微软都是上下文相关帮助下降的罪魁祸首。首先，温和地说，Visual Studio 中的帮助系统使用起来很痛苦。其次，Visual Studio 帮助系统的易用性显着下降。我将省略咆哮，但足以说明，需要更多的点击和滚动才能在 VS2008 帮助中获取相关信息。这往往会为应用程序中的帮助系统设定较低的标准。
With Tooltips and a generally increased computer ability in users, some applications do just fine without help files. However, some applications need help files, as much for general topic information as for application usage. For example, in a photo app you might want to explain jpeg compression and include some samples in the help file, even if the user operation is self evident.
It seems to me that Microsoft is a contributor to the decline in context-sensitive help, for better or for worse. First, the help systems in Visual Studio are, to put it mildly, a pain to use. Second, the ease of use of Visual Studio's help system has gone downhill significantly. I'll omit the rant, but suffice it to say that it takes many more clicks and scrolls to get relevant info in the VS2008 help. This tends to set a lower standard for help systems in applications.