我写软件时间不长，可系统自己独立开发也有好几套了，每次开发系统的时候，帮助都是一个比较头疼的问题。以下有我列的出一些帮助：
一：最普通的 。比如windows的帮助系统，delphi的帮助系统 F1
二：动态的。比如office 2000的。 说实话，我对帮助系统的是比较重视的，好的帮助系统可以减少很打的培训量，并且一套软件的使用过程，对用户来说就是一个学习过程，好的帮助就是一套好的参考书，并且是最权威的参考书。但现在的问题是，大部分的用户根本不看帮助，试问各位，如果不是使用DELPHI等开发工具，你会去看帮助吗？对我来说，帮助看的最多的可能就是MSDN或者DELPHI的帮助。其它的，从来没有看过。这里面有帮助本身的质量问题，也有个人的心里问题。但我认为，最重要的是，一直没有出现非常好的帮助系统，所以导致用户在心理上就不怎么接受帮助系统。比如说，office 2000的动态帮助，仔细去看的话，还不错，并且是一个趋势 ，但现在的问题是，不停的，讨厌的，无用的，大量的狗屎信息同时出现，让用户心里产生反感。至少我很反感。
当然，不同的系统类型，说面向的客户是不同的，需求也是不同的。现在大家就讨论一下各自所擅长的系统的帮助需求吧。 所以，在目前我手上的一个项目即将完工的时候，我想问问各位高人，大家对帮助的看法，什么样的帮助是好的帮助系统，怎么开发好的帮助系统，好的帮助系统应该何时出现，应该包含什么样的信息。各位在开发系统的时候，写帮助吗，或者帮助系统占多大的分量。
一：最普通的 。比如windows的帮助系统，delphi的帮助系统 F1
二：动态的。比如office 2000的。 说实话，我对帮助系统的是比较重视的，好的帮助系统可以减少很打的培训量，并且一套软件的使用过程，对用户来说就是一个学习过程，好的帮助就是一套好的参考书，并且是最权威的参考书。但现在的问题是，大部分的用户根本不看帮助，试问各位，如果不是使用DELPHI等开发工具，你会去看帮助吗？对我来说，帮助看的最多的可能就是MSDN或者DELPHI的帮助。其它的，从来没有看过。这里面有帮助本身的质量问题，也有个人的心里问题。但我认为，最重要的是，一直没有出现非常好的帮助系统，所以导致用户在心理上就不怎么接受帮助系统。比如说，office 2000的动态帮助，仔细去看的话，还不错，并且是一个趋势 ，但现在的问题是，不停的，讨厌的，无用的，大量的狗屎信息同时出现，让用户心里产生反感。至少我很反感。
当然，不同的系统类型，说面向的客户是不同的，需求也是不同的。现在大家就讨论一下各自所擅长的系统的帮助需求吧。 所以，在目前我手上的一个项目即将完工的时候，我想问问各位高人，大家对帮助的看法，什么样的帮助是好的帮助系统，怎么开发好的帮助系统，好的帮助系统应该何时出现，应该包含什么样的信息。各位在开发系统的时候，写帮助吗，或者帮助系统占多大的分量。
比如所当一个用户进行了一个操作的时候不正确，除了给出提示showmessge之外，就是现实一个正确操作的动画给用户看。
最好是Agent的了，够形象
1、操作简单；
2、关键字丰富，支持模糊查询。
3、一些重要环节一定不要怕烦，详细一点。
4、如果能实时帮助就更好（就象： wudi_1982(简单就是美) 说的那样）
另外关于帮助文件的编写:如果公司分工比较细的话,我觉得应该是由测试小组在测试的过程完成,我个人认为作为程序开发人员,在设计和写代码的时候就已经形成了一个固有的操作方式,写出来的帮助不利用用户.至于点多大的份量那要看是项目还是产品化的东西,产品化的东西帮助对销售和后期维护都有相当大的影响.我上一个单位主要是写产品化软件,帮助在系统中一般都点到30%左右,每次帮助完成之后都要由一个没有参与这个产品开发和测试的人员根据帮助进行模拟用户操作,以检查帮助的可用性.
用delphi直接调用
Application.HelpFile :='help.hlp';
Application.HelpCommand(HELP_FINDER, 0);
就和普通的帮助相同了
是件头疼的事，
我最怕了些帮助了。
而且一旦修改程序，又要修改。
尽量把可能的问题都分门别类的列出来
只要培训一下就可以了。
Delphi和Office的帮助是很多人做的。不是我辈少数几个人能做出来的。
中国开发者网络
http://www.chinadevelopernetwork.com
对于同时有多人使用的情况可以考虑象ViaVoice那样区分用户来实现。