就我这个外行的观点，过往的软件和网站设计中，帮助系统的设计无疑是最失败的，也是最受忽视却是最该重视的。
我所见过用过的软件和网站，在帮助系统的设计和编写上，绝大多数都犯下了不是严重忽视就是过分沉重的两个极端的错误。
我所能想到的最明显的忽视帮助系统的软件或网站，就是斗牛士（donews）。在它的blog首页上，至今你也只有在页面的最下方一段极不起眼的链接才能找到帮助系统的入口。而且那哪里是什么系统，就是一个简单的问题回答集。而在过往的斗牛士的博客里，有相当长一段时期，这个通向帮助系统的链接是哪里也接不通的。当然，刘韧是有理由忽视他经营网站的帮助系统的。因为他“伺候”的主顾都是IT业界的行家里手，给他们写帮助文件即是多此一举，更是一种大不敬。难道怀疑这些主顾不够专业吗？
至于过于沉重的例子我想起来的是微软。在这里先解释一下什么是过于沉重。我不知道你有没有过类似的经历。反正我经常经历这样的情况。我打开一个微软出品的一个软件的帮助文件。你不得不承认，这个帮助文件是极其详尽的，没有一处该注意的细节被落下了。但是很快我就从它的帮助文件逃跑了。为什么？一，几乎每一句话里都有若干我从未见过的看上去极为专业的词汇。而这些充满专业词汇的文本写得极其枯燥、平板，一丁点的阅读性也没有。二，这样晦涩枯燥的文本链接套链接、长得我望而生畏。总体上当我不无遗憾地关掉这个帮助文件的时候，总会有一个感觉：这个帮助文件不是让我来阅读它、从它当中获得我想获得的知识，而是让我极度讨厌它、然后以最快的速度离开它。只有一颗想要帮助别人的好心，而完全忽视要帮助人的特点，完全忽视帮助的方式方法，效果跟从不想帮助别人是差不多的。这就是我所说的过分沉重。
所以在我设计的RSS阅读器的帮助系统里，我将吸取以上我提到的教训。
我要把帮助子系统的设计当作我整个阅读器设计中最重要的设计。如果你不能像乔布斯那样，通过千百次的修改试验体验，最终获得一个优秀无比的软件UI，那么我就要奉劝你，在软件的帮助系统上下足功夫，让用户最快、最轻松的了解你的软件，进而主动适应你的软件。以此来和乔布斯的最佳UI抗衡。
具体的原则和措施如下：
一，首先让用户了解的不是帮助系统的具体内容，而是设计者设计这个帮助系统的理念和原则。
我觉得让用户了解设计者的理念和原则，是你能提供给用户的有关这个软件的最大帮助。
我会在用户第二次打开我设计的阅读器的时候，自动播放一段视频：有关设计帮助系统的理念和原则的。
具体内容是：设计者是把这个软件的帮助子系统的设计当作最重要的设计。对软件的使用者来说，这个子系统也是最重要、最有用的子系统。
这个软件的帮助系统分作两大部分。第一部分是一个完全独立的帮助子系统。惯用传统的分类加搜索的组织框架。但是在具体的分类上，我将以用户使用软件的进度为标准来进行分类。具体说就是：1，开始使用这个软件。2，对基本的操作已经熟悉，已经决定使用这个软件，想更进一步了解并使用这个软件。3，已经使用这个软件两三个月了。4，已经使用这个软件五六个月，并体验到许多深度的应用可能。......在这样的基本分类下，我当然还会进一步分类。就拿“3，已经使用这个软件两三个月了”为例。在它下面还会分类如下：a,已经使用两三个月了，你有了繁琐和不变的感觉。b,已经使用三个月了，你很想了解和使用更多的功能。c,软件似乎总出同一个毛病，好像有漏洞。d,有什么好的设想和建议，到设计者的网站留言，你也许会获得出乎意料的奖励。e,以传统的分类方式了解本软件。......在这个独立的帮助子系统里，将使用视频和文字两种帮助文本。视频要小、直观、干净、逻辑清晰。文本要通俗、简短、清楚。所有基本的重要的帮助内容都会使用视频。
第二部分是分散、跟随在整个软件的大大小小的部件上的。就是当你把鼠标附到某个按钮上会出现简短文字。与以往不同的是，我会想方设法夸大、突出这些跟随的简短文字。当然不可能一味的无限制的夸张、突出。而是在允许的范围内，我将这么做。而且我将在独立的帮助系统里，反复提醒用户要格外留意、关注这些跟随的帮助文件。此外，在一些关键的重要的部件上跟随的将是自动开始播放的视频。
二，让用户了解整个帮助系统的框架和布局，以及特点。以上都已经说明，不再赘述。
三，把通过反复的策划、制作、测试、修改的帮助系统架设到网站上，呈现在用户面前。
最后我要说一句，我知道的最好的帮助系统来自于一款游戏：《海滨嘉年华》。尽管它还有很多不尽人意之处。
