帮助文件(或用户手册)死了吗？

Question

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

如今,使用Web 2.0应用程序,您几乎看不到帮助.即使它存在,它们只是描述一些特定的任务.换句话说,应用程序更多地依赖于用户群的常识或不让我思考的因素.

几年前,微软提出了一个名为" 归纳用户界面"的概念,它基本上告诉程序员在应用程序本身上发出指令,但我不确定这个想法有多受欢迎.

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

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

Answer 1

关于帮助的三点说明:

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

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

Answer 2

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

他们应该能够使用您的应用程序通过 UI 执行基本操作。例如，对于图像编辑器来说，他们应该能够创建一个新图像，绘制一些线条，然后只需查看 UI 即可保存它。

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

对于网络应用程序来说也是如此，人们希望能够在不阅读文档的情况下完成基本的工作，但对于更高级的功能，人们仍然会阅读文档。（例如，大多数人会阅读 BB 代码的文档，或者至少有时会阅读 markdown，但他们希望能够在不了解这些代码的情况下发布内容）

帮助文件、用户手册和 F1 键的上下文相关在线帮助是否已失效？

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