帮助文件（或用户手册）死了吗？

Question

回到Unix的时代，如果不先阅读手册页，你甚至不能close a software。然后Mac和Windows具有一致的菜单布局和键盘快捷键，但您仍然看到了收缩包装盒中附带的纸质用户手册，其中描述了应用程序中可能的每一项操作。在Internet之后，帮助文件变成了html文档。

现在使用 Web 2.0 应用程序，您几乎看不到帮助。即使是if it's there，他们也只是描述了一些具体的任务。换句话说，应用程序更多地依赖于用户群的常识或don't-make-me-think因素。

多年前，微软提出了一个名为Inductive User Interface的概念，它基本上告诉程序员对应用程序本身进行说明，但我不确定这个想法有多受欢迎。

帮助文件，用户手册和上下文相关的在线帮助与F1键死了吗？如果用户无法从UI中找到要做的事情，我是否失败了？如果没有，我应该提供多大程度的帮助？ （适用于桌面和网络应用）

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

Answer 1

关于帮助的三个注释：

1. F1 /独立的上下文相关帮助总是注定失败。它默认是隐藏的，因此最需要它的人最不可能阅读它。曾经有希望我们能够训练用户在遇到麻烦时总是打F1，但是太多的应用程序没有有用的上下文敏感的帮助......结合太多奇怪的帮助界面......几乎被杀死此。
2. 手册与以往一样重要。没有那么多印刷手册了，但在线手册比以往更好。 wiki-as-a-manual系统的激增在这里有所帮助，降低了创建良好在线文档的前期成本。当然，很多人就是不读 ......
3. 使用网页作为应用程序界面的美妙之处在于，可以将有用的上下文相关帮助与UI相结合，为新手和其他无法打扰的人解除障碍当他们被卡住时获取相关信息。

当然，仍然有很多应用程序，甚至是在线应用程序，设计有钝角接口和某个角落的小小帮助图标，可能希望后者减轻前者。可怜他们。

Answer 2

没办法。你看看MS提出的文件，培训和营销支出的数量......你会得到你的答案。 尝试使用别人的产品，你将学习文档的真正价值 - 我现在正在学习Godiagrams .. :)
所以我可以毫无疑问地说.. NO，它永远不会......无论用户界面多么直观......超出一定规模，你需要帮助和培训。但是通过了解用户和他需要完成的工作，你可以设计它，以便他/她需要学习系统来执行他/她的日常任务的时间很短。

Answer 3

  

如果用户无法从UI中找到要做的事情，我是否失败了？   如果没有，我应该提供多大程度的帮助？ （适用于桌面和网络应用）

他们应该能够使用您的应用从UI做基本的事情。例如，对于图像编辑器，他们应该能够创建一个新图像，并绘制一些线条，然后通过查看UI来保存它。

最好通过以下常见布局（例如在菜单栏中使用新文件，打开并保存文件，以及使用标准的打开和保存对话框）来完成。

同样适用于webapps，人们在没有阅读文档的情况下能够做基本的事情，但是对于更高级的功能，人们仍然会阅读文档。 （例如，大多数人会阅读说BB代码的文档，或者至少有时会降价，但他们希望能够发布而不必了解它们）

  

帮助文件，用户手册和上下文相关的在线帮助F1键死了吗？

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

Answer 4

我一直在将上下文敏感的截屏视频合并到我的应用程序中。我发现这有助于非技术用户快速掌握应用程序，而无需寻求实时帮助。

Answer 5

白痴/假人的书必须做得很好。想象一下，如果标准应用程序帮助与那些书籍一样好。许多应用程序的标准F1帮助非常糟糕。

帮助死了吗？不，但有些应该被取出并拍摄。