3.只有在线文档
与前一点想反，只有在线文档也是不好的。有些项目在完成时并没有同步打包放出符合规范的文档。
以搜索引擎Solr为例，它有一个非常完善的在线wiki文档。遗憾的是，可供下载的2200多页文档都是通过javadocs自动生成的。唯一的一份提供给用户的文档只是一个单页教程。
PHP语言包里并没有提供任何文档，如果你想要的话，你必须去指定的页面获取。更糟的是，只有核心文档才能下载，有些很有用的用户提交的注解文档(详见下面的“不接受用户的注解”)并没有提供给用户下载，而且他们并没有像在线文档那样易于查找导航。
你不能假设用户在需要文档的时候可以连接到互联网。飞行模式还是存在的。 即使如此，你也不能期待用户依赖于你的项目网站总是在线的。 在过于的几个月里我至少遇到了2次Solr的百科页面不能访问，而且是在工作日，我当时只是在查阅一个很小的配置问题。
做的最好的网站是Perl 和她的CPAN 模块。 每个模块的文档都可以很容易的在search.cpan.org 和 metacpan.org找到。 为了离线的需要，每个模块的文档都嵌入在源码本身里面， 当你安装这个模块到你的操作系统时，文档会自动的加载到你的本地帮助文档里面。 用户也可以使用：
得到文档。 由你来选择在线还是离线。
4. 没有提供随包安装文档
这个问题通常是软件包创建者的败笔，而不是项目作者的。比如，Ubuntu Linux中，Perl语言的文档是分离于语言本身软件包的可选软件包。用户必须知道她得显式地安装文档，就像安装核心包一样，否则当她需要文档时就没了。这种做法换取了几兆字节的硬盘空间，却牺牲了文档随时在手边的便利，对每个人都用处不大。
5. 缺少屏幕截图
截图能更好的抓住潜在用户的注意，描绘出一个合适的使用方式。 一图胜千言。对于互联网来说这点更重要，因为你都不能让用户可能读到一百个字。
截图对于让用户持续不断理解你的介绍是无价的，用户会根据的截图来做正确的事情。 一个截图能够让帮助用户判断他的结果和文档里面的截图是否正确。
很多优秀的项目在网站上用视频来介绍这个项目，这种情况正变得越来越普遍。更深入的视频介绍复杂的步骤。举个例子来说，Plone有个专门的网站来介绍他们的项目。不管怎么样，视频都取代不了截图。如果一个用户只是为了快速的了解一些你的界面，他是不愿意观看整个视频的。视频不能够被google的图片搜索搜索到，而截图却可以。
