回到Unix的时代,如果不先阅读手册页,你甚至无法关闭软件.然后Mac和Windows具有一致的菜单布局和键盘快捷键,但您仍然看到了收缩包装盒中附带的纸质用户手册,其中描述了应用程序中可能的每一项操作.在Internet之后,帮助文件变成了html文档.
如今,使用Web 2.0应用程序,您几乎看不到帮助.即使它存在,它们只是描述一些特定的任务.换句话说,应用程序更多地依赖于用户群的常识或不让我思考的因素.
几年前,微软提出了一个名为" 归纳用户界面"的概念,它基本上告诉程序员在应用程序本身上发出指令,但我不确定这个想法有多受欢迎.
F1键是否有帮助文件,用户手册和上下文相关的在线帮助?如果用户无法从UI中找到要做的事情,我是否失败了?如果没有,我应该提供多大程度的帮助?(适用于桌面和网络应用)
编辑:文档/帮助文件如何与敏捷开发方法相结合?例如,开发人员应该在UI更改之前三思而后行,这可能会淘汰一堆屏幕截图吗?
F1 /独立的上下文敏感帮助总是注定失败.它默认是隐藏的,因此最需要它的人最不可能阅读它.曾经有希望我们能够训练用户在遇到麻烦时总是打F1,但是太多的应用程序没有有用的上下文敏感的帮助......结合太多奇怪的帮助界面......几乎被杀死这个.
手册与以往一样重要.没有那么多印刷手册了,但在线手册比以往更好.wiki-as-a-manual系统的激增在这里有所帮助,降低了创建良好在线文档的前期成本.当然,很多人只是不读 ......
使用网页作为应用程序界面的美妙之处在于,您可以将有用的上下文相关帮助与UI相结合,消除新手和其他人在其卡住时无法查找相关信息的障碍.
当然,仍然有很多应用程序,甚至是在线应用程序,设计有钝角接口和某个角落的小小帮助图标,可能希望后者减轻前者.可惜他们.