在Unix时代，如果不先阅读手册页就无法关闭软件。然后是Mac和Windows，它们具有一致的菜单布局和键盘快捷键，但是我们仍然可以在收缩包装盒中看到纸质的用户手册，其中描述了该应用程序中可能进行的每一项操作。上网后，帮助文件变成了html文档。

如今，使用Web 2.0应用程序，我们几乎看不到"帮助"。即使在那里，他们也只是描述一些特定的任务。换句话说，这些应用程序更多地依赖于用户群的常识或者不让我思考的因素。

几年前，微软提出了一个名为"归纳用户界面"的概念，该概念基本上是告诉程序员在应用程序本身上放置指令，但是我不确定该想法有多流行。

F1键的帮助文件，用户手册和上下文相关的在线帮助是否已失效？如果用户无法从UI中找到要做什么，我是否会失败？如果没有，我应该提供什么程度的帮助？ (适用于台式机和网络应用程序)

编辑：文档/帮助文件如何与敏捷开发方法相结合？例如，开发人员是否应该在UI更改(可能会使一堆屏幕截图过时)之前三思而后行？

解决方案

回答

决不。我们甚至可以查看MS提出的文档，培训和市场营销费用的数量。我们将得到答案。
尝试使用其他人的产品，我们将了解我正在学习Godiagrams的文档的真正价值。.：:)
因此，我可以毫无疑问地说..不，它永远不会..无论用户界面多么直观，超过一定大小，我们都需要帮助和培训。但是，通过了解用户及其需要完成的工作，我们可以对其进行设计，以使他/她学习系统以执行其日常任务所需的时间最少。

回答

Have I failed if user could not find out what to do from the UI?
  If not, what degree of help should I provide? (both for desktop and web app)

他们应该能够使用应用通过用户界面执行基本操作。例如，对于图像编辑器，他们应该能够创建新图像，并绘制一些线，然后仅通过查看UI即可将其保存。

最好通过遵循常见的布局(例如，在菜单栏中具有"新建"，"打开"和"保存"在文件下，以及使用标准的"打开和保存"对话框)来完成此操作。

对于Web应用程序来说，情况也是一样，人们期望无需阅读文档就能进行基本操作，但是对于更高级的功能，人们仍然会阅读文档。 (例如，大多数Pople会读文档中的BB代码或者降价促销，至少有时是这样，但他们希望能够发布而不用知道它们)

Are help files, user manuals, and context sensitive online help with F1 key dead?

他们仍然有自己的位置。人们将使用它们来学习如何最好地使用各种功能，例如markdown或者bbcode，或者如何使用滤镜在图像编辑器中获得某些效果。

回答

关于帮助的三个注意事项：

• F1 /独立的上下文相关帮助始终注定要失败。默认情况下它是隐藏的，因此最需要它的人最不可能阅读它。曾经有一次希望，我们能够训练用户在遇到麻烦时总是按F1键，但是太多的应用程序没有有用的上下文相关帮助...再加上太多奇怪的帮助界面...几乎被杀死了这。
• 手册现在和以往一样重要。印刷手册不再那么多了，但是在线手册比以往任何时候都更好。 Wiki即手动系统的普及在此有所帮助，从而降低了创建优质在线文档的前期成本。当然，很多人只是不读...
• 使用网页作为应用程序界面的好处在于，我们可以将有用的上下文相关帮助与UI结合使用，从而消除了新手和其他人的障碍，而这些人否则就不会在卡住时寻找相关信息。

当然，仍然有很多应用程序，甚至是在线应用程序，其设计都采用钝角界面，并且在角落的某个角落有一个小小的帮助图标，大概是希望后者能缓解前者的麻烦。可怜他们。

回答

我一直在将上下文相关的截屏视频合并到我的应用程序中。我发现这可以帮助非技术用户快速获取应用程序，而无需寻求实时帮助。

回答

傻瓜/虚拟书一定做得很好。试想一下，标准应用程序帮助与这些书籍一样好。许多应用程序的标准F1帮助非常糟糕。

帮助死了吗？不，但是应该将其中一些拿出并开枪。