关闭

软件如何去获得好的评价

标签: 文档产品microsoft工具file测试
1232人阅读 评论(0) 收藏 举报

转自ZDNET

从定义上来说,共享软件和其他形式的试用软件都是销售产品的方法,它们不是程序的种类。因此,不管你喜欢与否,在某种程度上你不得不放弃程序员的保守的眼光而用市场的眼光来看待它。毕竟作者一般都有两个目的:一是写出好的程序,二是取得一定的回报。如果你能让用户和评论者用积极的态度面对你的软件,你成功的机会将会更大。

在共享软件面世之初,粗糙的程序就是标准,而不是例外。但是那个时期的大部分用户会毫无顾忌的把你的软件贬得一文不值,即使你的软件有一些可取之处。当今得用户和软件市场处于一个完全不同的位置和时期,特别是现在流行的在线服务和互联网已经让成很多人钟情于使用共享软件和下载买前试用的软件。

写这篇文章是为了帮助共享软件和试用软件作者记住一些取得成功不可或缺的细节。当我们评论者评价一个程序时,我们会用典型的用户的眼光,因此如果你给我们留下很深的映象,很有可能下载你程序的人也会欣赏你的成果,并且会用注册作为对你的回报。因此你要知道我们不是在这里瞎忙,我们自有我们的道理。

一、给你的table带来新的东西

让你所选的程序在同类程序中与众不同。花一些时间查找并看一下类似的程序,注意它们的特征和不足之处。用实用和易用的特征给你的程序一个新的全貌来让它超过同类其他程序。认真考虑一下设计和功能——你的程序仅比类似程序好出10%吗?只因为你能够开发一个“其他程序”就应该开发它?

二、设计一个清晰的界面

你的程序受新用户欢迎的方式决定它是成功的还是毫无用处的。下面是一些取得成功的要素:
1、用一个有吸引力的启动画面会立刻给别人留下有利的映象,例如引导画面、快速启动或第一次启动时的向导;
2、建立一个直观而富有逻辑性的界面,因此你的用户不用费神凝视你的文档去理解它——自动弹出的解释会帮助用户学习工具栏图标和其他功能;
3、把最常用的功能放在最表面,不要在菜单里把功能设在四级以下。另外,不要把不重要的东西与重要的东西并列放在工具栏里;
4、用清晰简单的语言描述它的功能或特征;
5、使用清晰易读的字体;
6、查看你的颜色选择和不同分辨率下的界面以及用非标准的配色方案来证明它们在不同配置下的清晰性;
6、用直观和标准的键盘快捷键;
7、最后,认真考虑使用标准界面事件而不是用自己定义的模式的无穷价值——Windows的长处是它的普遍性,因此你一旦使用了一个程序,其他的看起来就很相似了。

三、评估功效

完成一个最常用的功能要点几次鼠标、敲几次键盘?用直观的、成组的、富有逻辑性的工具栏以最小的气力去达到最容易的使用。如果可能的话,考虑一下为常用任务添加键盘快捷键,为常用数据设置下拉菜单选项。简而言之——帮助你的用户走捷径完成手边的工作。

四、从文字角度检查你的程序编码

检查你程序的拼写,不仅仅是文档。错误使你的程序看起来很业余,并且会导致用户怀疑你对细节的注意程度。如果英语不是你的母语,考虑让你的程序编码和并行文档被检查和编辑。翻译通常是不清楚的,会成为用户理解你的程序的挡路石。

五、在安装之前显示你的程序信息

什么能比在程序安装之前显示系统需求和安装信息更有用呢?如果你觉得你必须分发一个单独的 EXE 文件,至少要在安装过程开始而不是结束的时候显示你的用户需要知道的信息。大部分对用户友好的文件至少包括下面的三个文件标准之一,在用户确认安装之前是可见的:

◎Readme.txt
这是一个提供你的程序的简短而友好的介绍和更新信息的机会,可以告诉用户在运行Setup.exe时会看到什么。考虑一个很大的可能性即你认真编写的文档会被忽视,这是唯一在用户使用程序之前能与你交流的机会。这也是一个列出你的需求的好的位置,例如操作系统、支持库等独特需求、其他软件环境或专门的配置。同时告诉用户它值多少钱、是否有广告支持,或者如果它是免费的,列出Demo版的限制(如果有的话)。

◎PAD 或其他适应销售的文件
包含一份适应销售的文件也是一个好主意,因为彻底完成时它会把所有的“需要知道”的信息放到一个地方。ZDNet推荐你使用共享软件专业协会(the Association of Shareware Professionals)提供的PAD(Program Application Description,应用程序种类)。这份文件将会加速我们的在线过帐和评价过程,含有PAD 或类似文件的程序一般是没有这类文件的程序的一半时间,所以在可能的情况下加上这个文件对你是有好处的。

◎File_id.diz
这个简单的小文件可能是获取你的信息和使你的软件在很长的新文件列表中脱颖而出的最好方法。这对区分你的程序和其他一堆下载文件也很有用,它可以防止你的程序被击败。只要你想就可以尝试一下,但是要确保前三行能说清楚文件的用处,并能吸引潜在的用户。当采取这个标准的公告牌服务衰落为夕阳产业时,许多的因特网上的软件收集继续依靠压缩包里的描述作为包含一份优质的文件描述的可靠的自动化方法。

六、使用易识别的文件扩展名

让用户容易打开你的支持文件。使用用户一定有的普通格式——不是每个用户的计算机都支持Word 2000、Adobe Acrobat 以及其他文件格式,所以使用写字板、文本、HTML 或是标准的帮助文件格式来确保用户轻松读取你的文档。ASCII 文件就用.txt 扩展名,.doc文件只能是Microsoft Word或写字板文档,.wri文件当然只能是原始的Windows 3.1书写文档。

七、使用标准的版本号

◎每次发行的编号
发行编号提供给用户和文件库一个办法来快速比较和选择发行,如果两者都在手边的话。每次发行用一个新的版本号,保证在你的File_id.diz 和 Readme.txt 里更新数据。记住在用户下载和上传时把文件数据存档不是总能保存得很好。

◎版本号是一个主观感觉,但是也有一些一般规则:
用整个数的变化(如1.x到2.x)来表示大幅度的增加或修改。如果你增加了很多有用的或值得注意的特征,但是这次发行不是正好跳过一个整数,考虑用一个 .5(如果合适的话)。不管什么情况下,要在文件描述和 File_id.diz 文件里加上“大幅度”的字样。
用x.1发行表示小范围的更新及功能添加和为常规的 BUG 修正。
用x.11或x.1a只表示修正了一些 BUG 。
不要使用超过小数点后2位的版本号,用户不需要你的制作史。如果你在发行x.0012版本,建议你重新考虑一下是否有发行的必要。

八、在你的文档里详细列出版本历史

不要错过这个巨大的销售机会——建立一个Version.txt、History.txt,或Whatsnew.txt 文件来告诉用户“What's New”,并让他们知道他们考虑购买的软件有一个负责的作者从不间断的改进的足迹。不要包含每一个小的BUG修复,但是要让评论者和重复的用户知道新特性和大的BUG修复。

九、在帮助文件或Readme里面包含一个“该版本的更新”部分

除了版本历史外,记得在每次升级软件时在帮助文件或Readme里面包含一个“该版本的更新”部分。这部分应该提供一份新特性的快速预览,不要提到BUG修复和小的改进。它使用户(以及评价者)容易找到新特性,进一步强调你在修复和改进之中。

十、包含一个方便的购买方法

把你的软件价格和购买方法放在一个Order.txt、帮助文件或其它文档,确保用户能够把这些信息复制为其它格式。不要迫使用户从一个“About”对话框或启动画面中记录下这些信息,或是让他们联机导航到一个潜在的无效网页。对用户隐藏你挣钱的机会或使它不方便是不明智的行为。

十一、使用一个专业且谨慎的预备安装程序

使用一个包含如下功能的高质量的安装包:
检测当前安装支持文件,不要不管版本号就覆盖它们;
安装时给用户选择备份替换文件的选项,或者让他们在安装过程中决定;
提供一个开始菜单中的快捷方式和(可选的)桌面快捷方式;
不能破坏其他应用程序;
能让用户选择安装路径。

十二、包含反安装功能

确保你的反安装程序不会删除不是它安装的东西,并能留下其他程序共享的支持文件。如果没有卸载程序,至少向系统注册你的程序以便它能被手工删除。有些作者感觉“如果他们不想保留和注册我的程序——给他们留一些麻烦吧”,这绝对是一个坏主意。可能他们现在不要你的程序,但是可能会试试下一个版本或是向需要的朋友推荐它,因此给他们留下一个好映象还是明智的。

十三、包含公共的支持文件

尽管很多用户可能有需要支持你程序的公共支持文件,除非它们是原来的操作系统需要的,最好在你的安装程序里带上它们。如果需要支持文件,程序文档应该在安装开始前说明。

十四、如果可能的话,提供一个实例数据

一个小的实例数据库、入口、文件或其他数据能帮助新用户成功启动,并完全理解你的系统。通过缩短学期周期,你不仅提高了你的程序使用和注册的机会,还减少了技术支持要求。请确认实例数据文件是足够强大的,它能显示你程序的特征。

十五、提供强大的文档

◎为程序提供详细的文档
强大的文档和好的概述是让新用户满意的关键。由于软件开发者集中到网络上,产品信息就逐步迁居到网页上,有时就给产品本身留下一个漏洞。记住:用户不一定能方便的访问网络,也可能不愿意在需要简单的问题答案时进行拨号连接,你的网页也可能暂时无效。你应该总是包含一个程序的基础文档(如果不全面的话)。假使你不这么做,至少提供一些引导数据来说清进一步的信息和帮助。如果你的产品不是面向网络的系统,考虑一下它可能被安装在有限制或没法上网的计算机上,这样就会把你的用户彻底晾在一边。
据说你主页上的不断更新的 FAQ 是一个极好的主意。关于你文档内容和机构的脆弱性,你的技术支持调查的本质可能会给你宝贵的一课。

◎提供一个以清晰的概述开始的整体帮助
考虑内置帮助文件作为你软件的一个完整组成部分。这不是一个可选的附加选项,如果那么想将会大大限制你程序的目标和有用性。
整体的帮助也是一个强大的市场工具。特别是概述,它提供了一个很大的机会告诉用户这个程序是什么、它能做什么、如何使用它、为什么人们需要它。如果他们知道这个软件能给他们带来哪些好处,他们是很乐意购买的。

◎清楚并且书面化
确定你进行了拼写和语法检查,请一些不熟悉你的程序的人来“二次测试”你的指导,看他们是不是清楚。如果写文档不是你的强项,或者你不熟悉这门语言,那么考虑让其他人帮你写。疑惑的时候,也把它给别人干。从两个使用的角度看待文档是很重要的:它为新用户提供了一个好的开始么?进行中的问题的答案容易找到么?关键字也是帮助文件的重要组成部分。

◎使用友好的语调
很明显,人们宁愿从他们喜欢的人那里购买东西——你曾经从一个对你不客气的售货员那里买汽车么?明智的写出你的文档和其他文件——不是让你做一个自作聪明的人,而是友好一点不要冒犯别人。不要过高的吹嘘你的程序,期望越高只会导致失望越大。老实说——我们没有按照Software MegaCorp International Conglomerate的的命名对你留下映象,也不会因为你很有名气而用不同的态度对你。我们每个人都有自己的判断能力。

十六、提供并清楚拼写出方便的支持选项

为潜在的用户提供一个简单的方法联系负责问题解答的人。如果你没有留下Email地址或网页提供支持,你落伍了!我们生活在一个烦躁的世界,所以希望快速的回答。你工作的一部分就是承担一个客户服务的角色来使不同层次的用户满意。文档里“常见问题”一节将缓解一些求教,帮助文件的参考区域应该是一个足够的回答。

十七、允许足够的评估时间和一个明智的注册刺激

◎考虑提供标准的30天试用期
30天的评估期是很普遍的,这使用户有足够的时间来彻底检查这个产品并决定他们是否保留它。某些情况下短一些的评估期可能是适合的,但是对有些程序来说15天或20天显然是不够的。

◎避免设置终止日期
如果你没有给用户一个公正的机会来试用你的软件,他们是不会购买的。有很多种试用方案,你的选择应该基于产品类型。有些公司面通过向网络发布软件设置软件(尤其是Beta版)的终止日期,而不是在编程技巧上控制使用。如果你最后使你的程序无效,选取一个宽大的使用量度。否则的话,一个用户可能安装你的产品而没有时间试用你的软件直到基于日期的试用期结束。
如果你必须在你的试用软件放上一个引人注目的终止日期,请在File_id.diz或类似文件里说清楚。为了代替依赖终止日期的的方案,可以考虑使用基于系统日期的强大信息来鼓励用户访问你的网站获取更新版本。

◎不要在注册表留下阻止进一步评估的键值
确定你的时间限制和卸载过程不会阻止高版本的使用。今天不中意的人可能明天会用到它。程序的提高可能会吸引更新的注意。如果你的清晰的时间限制方案阻止了用户进一步试用你的程序,你已经把自己锁定在潜在用户的注册之外了。如果不幸有人每隔30天卸载并重新安装你的程序来逃避注册,由他去吧——不管怎么说要么你最终得到一个注册要么永远得不到,所以何必失去其他潜在用户的机会呢?

◎不要太优柔寡断而影响你的机会
在你想提供一个很强的刺激时,控制有助你销售的程序的关键特性将不利于你。如果一个潜在的注册者不能用或不理解某个特性,这就影响你的机会了。我们曾经见过一些程序忽略了帮助文件,这种逻辑完全令我们不解。

◎不要打断用户对你程序的欣赏而使他们厌烦
如果你偶尔告诉他们,他们知道你想让他们注册你的软件。然而,如果你打断他们使用程序而使他们不满意,他们充分使用和注意你的程序的机会就没了。

◎不要要求用户为了试用到你的站点
我们不想给你留下地址让你把推销Email不断发给我们,不管怎样我们中的大部分会给你假的信息——我们只想检查你的程序。把你推销的劲头放在程序里让我们想用它,用满腔的热情写出好的概要和文档。

十八、明确建立分发权和许可证

在你的文档里正式说明你的软件的试用版可以被任何团体散发,这是及其重要的。明确软件是自由的或是试用的(评估、Demo、共享——不管你提出什么术语)也非常有必要。主要一点就是定位你的软件可以被个人自由下载和试用一段时间或者在特定条件下试用,这可以在你的文本的别处或程序本身里说明。缺少这些关键信息的清楚声明的程序是不会被提交到软件库里的。
你的声明可以这么简单,“XXX是一个共享软件。这意味着你可以免费测试它,你也可以自由分发给他人。”

十九、有版权的材料=律师信

MIDI或其他有版权的音乐格式和歌词不经许可是不能散发的,支持文件、字体文件等也是。你的软件可能很漂亮,包含一个你喜欢的卡通人物图片,但是不久你的信箱里就会收到一封律师来信。ZDNet 不能提交你的产品,我们的律师不想收到其他律师的来信。

二十、不要发布一个没有稳定而完善的程序

在一个评估产品中细节往往比一个偶然遇到的明显的BUG更加烦人,请在发布你的产品前适当测试。确保程序的功能都可以实际工作,包含恰当的错误捕获,知道程序如何使用系统资源会影响并发进程。如果程序还在测试中就叫它Beta版。一旦产品准备发布,不要急着修复BUG或提高特性;给其他误操作和卓越的附加功能一个表面的机会,考虑一个.1a、.1b、.1c的窘况——它们不会激发用户的信心。

二十一、定价有竞争性且合理

调查一下市场,基于竞争激烈的软件市场根据真实的估算给你的产品定价。把你的程序和同一范围的其他程序比较相应地定价。在价格和用户地使用价值之间必须有一个合理地平衡。得到500份每份10美元的注册绝对比得到50份每份20美元的注册好。

二十二、记住一件重要事情
在下载你的程序时,我们用户非常想它会解决我们的问题——我们希望你能成功。花一些时间完成那些小的细节。考虑你的程序就是一个魔盒的电子等价物——使我们想从货架上取下你的产品。当我们用现金注册时它将给你带去利益。 

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:427160次
    • 积分:4676
    • 等级:
    • 排名:第7034名
    • 原创:72篇
    • 转载:121篇
    • 译文:2篇
    • 评论:39条
    最新评论
    友情链接