F
fcputao
Unregistered / Unconfirmed
GUEST, unregistred user!
How To Get Better Software Reviews
==================================
Shareware and other forms of trialware are, by definition, ways of marketing a product;
they're not categories of programs. So, like it or not, at some point you have to take off your programmer's beanie and put on a marketer's hat. After all, authors usually have two objectives: to write a good program and make a few bucks as a result. If you can create a positive attitude toward your software in the minds of users and the reviewers who write about it, you have a better chance of reaching your goals.
In the early years of shareware, rough programs were the norm, not the exception. But those were also the days when most users were techies who didn't mind wrestling a program to the ground if it had a good heart. Today's users and the software market are from a completely different place and time, especially now that popular online services and the Internet have made shareware and try-before-you-buydo
wnloading the sport of millions.
This checklist was written to help shareware and trialware authors remember some of the details that are appreciated and can be necessary for your success. When we reviewers audition a program, we put our Typical User hats on, so if you impress us favorably, it's a fair bet that those whodo
wnload your program will also appreciate your effort and may reward you with a registration. Just so you understand we're not just being fussy, we've included a short reason for each.
Bring something new to the table
Make a real difference in the category of program you've chosen. Take the time to search for and look at similar offerings to note their features and failings. Bring a new perspective to the genre with useful and easily accessible features that make your product stand out from the others. Give serious consideration to design and function - will your creation be just 10 percent better than similar programs? Just because you can create "yet another ..... program"do
esn't mean that you should.
Design a clear interface
The way your program welcomes a new user can be the difference between success and the byte bucket. Here are some key ingrediants to success:
Create a favorable impression right off the bat with an attractive welcome, tutorial, quick-start, or wizard on first launch.
Make the interface intuitive and logical, so a user need not pore overdo
cumentation to understand it -- pop-up descriptions can help users learn toolbar icon and other functions.
Keep its most-used functions near the surface, anddo
n't bury features and functions four levels deep in your menu. On the other hand,do
n't put non-essential elements in toolbars alongside the important functions.
Use clear and simple language to describe functions or features.
Use fonts that are clearly readable.
View your color choices and interface at different resolutions and using non-standard color schemes, to verify their clarity at all settings.
Make use of intuitive and standard keyboard shortcuts.
And finally, strongly consider the immense value of using standard interface methods rather than inventing your own paradigm - a strength of Windows is its commonality, so that once you have used one program, others seem familiar.
Evaluate for ergonomics
How many mouse clicks or keystrokesdo
es it take to get at the most commonly used functions? Use intuitive, logically grouped toolbars to make use easiest with the least effort. Consider adding keyboard shortcuts for common tasks, drop-down menu selections for frequently used data, if applicable. In short -- help your user make short work of the task at hand.
Check the program text for literacy
Check spelling in your program, not just yourdo
cumentation. Errors make it look amateurish and cause users to question your attention to detail. If English is not your mother tongue, consider having your program text and accompanyingdo
cumentation examined and edited. Often, translations are not clear and can get in the way of a user's understanding of your program.
Make program information available before installation
What could be less helpful than information on system requirements and installation that isn't available until after the program is installed? If you feel you must deliver a lone .exe, at least display the information a user needs to know at the begin
ning of the installation routine rather than at the end.
The most user-friendly files include one or more of the three file standards that follow, and are accessible before a user commits to the program installation:
? Readme.txt
Here's your chance to provide a short and friendly introduction and overview of your program, and to tell users what to expect when they run Setup.exe. Consider the strong possibility that your carefully writtendo
cumentation will be ignored, and this may be your only chance to communicate with users before they try your program. It is also a good place to list requirements such as operating systems and any unique need, such as support libraries, other software programs, or specialized equipment. Also tell people how much it costs, whether it is supported by advertising, or if it's free, and state the limitations of the demo, if there are any.
? PAD or other vendor-oriented file
Including a vendor-oriented file can also be a good idea, since, when properly completed, it puts all the "need to know" information in one place. ZDNet recommends that you use the PAD (Program Application Description) system offered by the Association of Shareware Professionals.This file will expedite our online posting and review processes. Programs that contain PAD or equivalent files are generally processed in about half the time as programs without them, so it is to your benefit to include one whenever possible.
? File_id.diz
This simple little file can be the best way to get your message across and make your file stand out in a long listing of new files. It is also helpful in distinguishing Xyz234.exe file from others in a crowdeddo
wnload folder, and may save it from being zapped. Go long if you want, but make sure the first three lines say enough to make clear the file's purpose and attract potential users. While the bulletin board services that adopted this standard have faded mostly into the sunset, many Internet software collections continue to rely on the "Description in Zip" file as a dependable and automated way to obtain a quality file description.
Use recognized file extensions
Make it easy for users to get at your support files. Use common formats that users are sure to have - not every user has support for Word 2000, Adobe Acrobat, and other formats, so stick with WordPad-compatible, text, HTML, or standard Help files to be sure yourdo
cumentation can be easily read. ASCII files should have .txt extensions, .doc extensions only if they are Microsoft Word or WordPad, and .wri extensions only if they are the original Windows 3.1 Write format.
Use standard version numbers
? Number each release
Release numbers give users and file librarians a way to quickly compare and choose releases, if two are available. Give each release a version number, and keep it up to date in your File_id.diz and Readme.txt files. Remember that archive file dates are not always preserved when usersdo
wnload and subsequently upload them.
? Version numbering is a subjective science, but there are general guidelines:
Use whole-number changes (i.e., 1.x to 2.x) only to indicate major additions or changes. If you've added many useful or noteworthy additions to features but the releasedo
esn't justify a whole-number jump, consider a .5 (if appropriate). In any case, include the word "Major" in your descriptions and File_id.diz file.
Use x.1 releases to denote minor updates and additions to features along with routine bug fixes.
Use x.11 or x.1a releases to cover bug fixes only.
Don't go beyond two digits after the decimal point;
usersdo
n't need your build history. If you are issuing a x.0012, reconsider whether it needs releasing.
Detail the version history in yourdo
cumentation
Don't miss this great marketing opportunity -- create a Version.txt, History.txt, or Whatsnew.txt file to tell users "What's New" and show them that the software product in which they're considering investing has a track record of continual improvement by a responsible author.do
n't include every minor bug fix or tweak, butdo
give reviewers and repeat users an idea of new features and major fixes.
Include a "New in This Version" section in the Help or Readme
In addition to a version history, include a "New in This Version" section in the Help file or Readme.txt of any upgraded product. This section should provide a quick tour of the important new features, without mentioning bugs or minor improvements. It makes it easy for users (and reviewers) to locate new features, and further reinforces that you are on top of fixes and making improvements.
Include a convenient ordering method
Put your pricing and purchase methods in an Order.txt, help, or otherdo
cumentation file, and be sure the user can copy the data to another format.do
n't force users to writedo
wn information from an "About" box or splash screen, or make them go online to navigate a potentially unavailable Website. Hiding or making your opportunity to make money inconvenient to users is unwise.
Employ a professionally and courteously prepared install program
Use a quality installation package that:
detects currently installed support files anddo
esn't overwrite them without regard to version numbering
gives users the option to back up files replaced during installation, or lets them decide during the installation process
offers a Start menu shortcut and (optionally) a desktop shortcut
doesn't cripple other applications
lets the user choose the installation folder
Include an uninstall function
Make sure your uninstall routinedo
esn't remove files it didn't install, and can optionally leave shared support files behind. If youdo
n't include an uninstaller, at leastdo
cument what your programdo
es to a system so it can be manually uninstalled. Some authors seem to feel that "if theydo
n't want to keep and register my program -- the heck with them!" Bad idea. They may not need your program just now, but may try a future release or recommend it to a friend who needs it, so it's wise to leave a good impression.
If your program employs advertising technology, explain any special procedures for uninstalling it.
Include common support files
While many users may have common files required to support your program, unless they are a part of the original, required operating system, include them with your installation routine. If supporting files are required, the programdo
cumentation should say so before the install starts.
Provide sample data, if applicable
A small sample database, entries, files, or other data may help a new user get off the ground and understand your system "hands on." By shortening the learning curve, you not only improve your chances of use and registration, but you may reduce support calls. Be sure the sample data file is large enough to show off the program's features.
Provide strongdo
cumentation
? Supply detaileddo
cumentation with the program
Strongdo
cumentation and a good overview are critical to your new users' satisfaction. As software developers flock to the Web, product information has increasingly migrated to the Website, sometimes leaving a hole in the product itself. Remember that users may not have convenient Web access or may not want to dial up their connection when they need a simple question answered, and your site may be temporarily unavailable. You should always include basic if not thoroughdo
cumentation with a program. If that is not practical, at least provide some introductory data and clear directions to further information and help. If your product is not a Web-oriented system, consider that it may be installed on machines with limited or no Web access, leaving your user completely stranded.
This being said, a link to a continually updated FAQ on your Website can be an excellent idea. The nature of your technical support inquiries may teach a valuable lesson about the weaknesses of yourdo
cumentation in both content and structure.
? Provide integrated help begin
ning with a clear overview
Think of built-in help as an integral component of your software. It's not an optional extra, and thinking of it in that way greatly limits the reach and usefulness of your programs.
Integrated help can also be a powerful marketing tool. In particular, the overview offers a great opportunity to tell users what the program is, what itdo
es, how to use it, and why they need it. If they understand how the program can benefit them, they're more likely to buy it.
? Be clear and literate
Make sure you check it for spelling and grammar, and ask someone unfamiliar with your program to "beta test" your instructions to see if they are clear. If writingdo
cumentation is not your strong suit, or the language unfamiliar, consider having someone write it for you. When indo
ubt, farm it out. It is important to look at thedo
cumentation from two perspectives of use:do
es it provide a good start for a new user? and, Are the answers to ongoing questions easy to find? Keywords are one of the most important components of help files.
? Use a friendly tone
It's fairly obvious that people prefer to buy from someone they like -- did you ever buy a car from a salesperson that rubbed you the wrong way? Write yourdo
cumentation and other files wisely, not as a wise guy, being careful to be friendly and not offend.
Anddo
n't over-hype your application, raising expectations that will only result in a letdown. And be honest - we aren't impressed by Software MegaCorp International Conglomerate names and attitudes with a guy in his garage behind it. Many of us work out of our spare bedrooms, too.
Offer and clearly spell out convenient support options
Provide an easy way for potential users to contact someone with questions. If youdo
n't have an email address or Website for support, you're behind the times. We live in an impatient world that wants immediate answers, and part of your job is assuming the role of customer service to patiently satisfy all levels of users. A "Frequently Asked Questions" section in yourdo
cumentation may help stem the tide of calls, and references to areas of your help file can be a sufficient reply.
Allow sufficient evaluation time and a smart registration incentive
? Consider offering the standard 30-day trial period
The 30-day evaluation period is standard and gives users enough time to fully vet the product and decide whether they want to keep it. A shorter evaluation period may be appropriate in some cases, but for some programs 15 days or 20 uses just isn't sufficient.
? Avoid setting expiration dates
If youdo
n't give users a fair chance to try your software, they may not purchase it. There are many schemes, and your choice may depend on the type of product. Some companies that issue software oriented to the Web use expiration dates for software (especially betas) instead of controlling usage through programming tricks. If you eventually disable your software, opt for a generous actual usage measurement. Otherwise, a user may install your product and not get around to trying it until after the date-based trial period is over. You both lose.
If you absolutely must put a drop-dead date in your trial software, place notice prominently in a File_id.diz or similar text file. Instead of relying on an expiration date, consider strong messages based on system dates to encourage a visit to your Website for an updated version.
?do
n't leave a Registry key that precludes future reviews
Make certain your time-limiting and uninstall routinesdo
n't prevent use of a future release. What may not suit someone today may be perfect tomorrow, and program enhancements may attract renewed attention. If your clever time-out scheme stops users from trying your program again, you will have effectively locked yourself out of a potential registration. If someone is so pathetic as to uninstall and reinstall your program every 30 days in order to avoid registration, let it be -- either you will eventually get a registration or you never would have anyway, so why hurt your chances with other potential users.
?do
n't hold back so much as to cripple your chances
While youdo
want to provide a strong incentive, holding back key features that help sell your program's usefulness can work against you. If a potential registrant can't use and appreciate a feature, it can hurt your chances. We've seen some programs that omit the help file, the logic of which completely baffles us.
?do
n't nag your user to the point of interrupting their appreciation of your program
They know you want them to register if you tell them occasionally. However, if you interrupt their use of the program to the point of annoyance, chances are they may not give it enough use to be impressed.
?do
n't require users come to your site for an evaluation key
Wedo
n't want to leave you our address so you can bombard us with marketing email, and most of us are going to give you bogus demographic information anyway -- we just want to check out your program. Put your marketing efforts into the program by making us want to use it, and by enthusiastic and well-written overviews anddo
cumentation.
Clearly Establish Distribution Rights and Licensing
It is extremely important to clearly state in yourdo
cumentation that the trial version of your software is available for distribution by any party. It is also imperative to state that the software is a free or trial version (evaluation, demo, shareware--whatever term you prefer). The main point is to establish that the software is free for individuals todo
wnload and use for a given period or under certain conditions, which can be established else
where in your text or in the program itself. Programs that lack these critical bits of information as clear statements cannot be posted in the Software Library.
Your statement can be as simple as, "XYZ is a shareware program. This means that you may test it free of charge. You may also distribute it freely to others so they may try it."
Copyrighted material = Lawyer letters
MIDI or other representations of copyrighted music and lyrics cannot be distributed without permission. Neither can certain support files, fonts, etc. It may be cute to include a drawing of your favorite cartoon character, too, but you may find a letter from a lawyer in your mailbox. And ZDNet can't post your creation. Our lawyersdo
n't want to hear from their lawyers.
Don't release a product until it's stable and polished
Few things are more annoying than encountering obvious bugs in an evaluation product.do
the proper testing before releasing your product. Make sure all the program functions actually work, include the proper error trapping, and know how the program's use of system resources may affect concurrent processes. If the product is still in beta, call it a beta. Once the product is ready for release,do
n't rush bug fixes or feature enhancements out thedo
or;
give other glitches and brilliant additions a chance to surface, and consider the embarrassment of a .1a, .1b, .1c, etc. -- they justdo
not inspire confidence in users.
Price competitively and wisely
Research the market and price your product based on an honest evaluation of the competitive software marketplace. Measure your product against other programs in the same category, and price it accordingly. There must be a reasonable balance between price and value to users. It is better to receive 500 registrations at $10 apiece than 50 registrations at $20 each.
Remember one important thing
Whendo
wnloading your program, we users desperately want it to be our solution - we want you to succeed. Take the time to finish off those little details. Consider the fine points of your packaging as the electronic equivalent of an attractive box - make us want to take your product off the shelf. It will be to your benefit when we take it to the cash register.
这是从ZDNET上摘录的一篇关于"获得好的软件评价"的文章.有人愿意翻译一下吗?
==================================
Shareware and other forms of trialware are, by definition, ways of marketing a product;
they're not categories of programs. So, like it or not, at some point you have to take off your programmer's beanie and put on a marketer's hat. After all, authors usually have two objectives: to write a good program and make a few bucks as a result. If you can create a positive attitude toward your software in the minds of users and the reviewers who write about it, you have a better chance of reaching your goals.
In the early years of shareware, rough programs were the norm, not the exception. But those were also the days when most users were techies who didn't mind wrestling a program to the ground if it had a good heart. Today's users and the software market are from a completely different place and time, especially now that popular online services and the Internet have made shareware and try-before-you-buydo
wnloading the sport of millions.
This checklist was written to help shareware and trialware authors remember some of the details that are appreciated and can be necessary for your success. When we reviewers audition a program, we put our Typical User hats on, so if you impress us favorably, it's a fair bet that those whodo
wnload your program will also appreciate your effort and may reward you with a registration. Just so you understand we're not just being fussy, we've included a short reason for each.
Bring something new to the table
Make a real difference in the category of program you've chosen. Take the time to search for and look at similar offerings to note their features and failings. Bring a new perspective to the genre with useful and easily accessible features that make your product stand out from the others. Give serious consideration to design and function - will your creation be just 10 percent better than similar programs? Just because you can create "yet another ..... program"do
esn't mean that you should.
Design a clear interface
The way your program welcomes a new user can be the difference between success and the byte bucket. Here are some key ingrediants to success:
Create a favorable impression right off the bat with an attractive welcome, tutorial, quick-start, or wizard on first launch.
Make the interface intuitive and logical, so a user need not pore overdo
cumentation to understand it -- pop-up descriptions can help users learn toolbar icon and other functions.
Keep its most-used functions near the surface, anddo
n't bury features and functions four levels deep in your menu. On the other hand,do
n't put non-essential elements in toolbars alongside the important functions.
Use clear and simple language to describe functions or features.
Use fonts that are clearly readable.
View your color choices and interface at different resolutions and using non-standard color schemes, to verify their clarity at all settings.
Make use of intuitive and standard keyboard shortcuts.
And finally, strongly consider the immense value of using standard interface methods rather than inventing your own paradigm - a strength of Windows is its commonality, so that once you have used one program, others seem familiar.
Evaluate for ergonomics
How many mouse clicks or keystrokesdo
es it take to get at the most commonly used functions? Use intuitive, logically grouped toolbars to make use easiest with the least effort. Consider adding keyboard shortcuts for common tasks, drop-down menu selections for frequently used data, if applicable. In short -- help your user make short work of the task at hand.
Check the program text for literacy
Check spelling in your program, not just yourdo
cumentation. Errors make it look amateurish and cause users to question your attention to detail. If English is not your mother tongue, consider having your program text and accompanyingdo
cumentation examined and edited. Often, translations are not clear and can get in the way of a user's understanding of your program.
Make program information available before installation
What could be less helpful than information on system requirements and installation that isn't available until after the program is installed? If you feel you must deliver a lone .exe, at least display the information a user needs to know at the begin
ning of the installation routine rather than at the end.
The most user-friendly files include one or more of the three file standards that follow, and are accessible before a user commits to the program installation:
? Readme.txt
Here's your chance to provide a short and friendly introduction and overview of your program, and to tell users what to expect when they run Setup.exe. Consider the strong possibility that your carefully writtendo
cumentation will be ignored, and this may be your only chance to communicate with users before they try your program. It is also a good place to list requirements such as operating systems and any unique need, such as support libraries, other software programs, or specialized equipment. Also tell people how much it costs, whether it is supported by advertising, or if it's free, and state the limitations of the demo, if there are any.
? PAD or other vendor-oriented file
Including a vendor-oriented file can also be a good idea, since, when properly completed, it puts all the "need to know" information in one place. ZDNet recommends that you use the PAD (Program Application Description) system offered by the Association of Shareware Professionals.This file will expedite our online posting and review processes. Programs that contain PAD or equivalent files are generally processed in about half the time as programs without them, so it is to your benefit to include one whenever possible.
? File_id.diz
This simple little file can be the best way to get your message across and make your file stand out in a long listing of new files. It is also helpful in distinguishing Xyz234.exe file from others in a crowdeddo
wnload folder, and may save it from being zapped. Go long if you want, but make sure the first three lines say enough to make clear the file's purpose and attract potential users. While the bulletin board services that adopted this standard have faded mostly into the sunset, many Internet software collections continue to rely on the "Description in Zip" file as a dependable and automated way to obtain a quality file description.
Use recognized file extensions
Make it easy for users to get at your support files. Use common formats that users are sure to have - not every user has support for Word 2000, Adobe Acrobat, and other formats, so stick with WordPad-compatible, text, HTML, or standard Help files to be sure yourdo
cumentation can be easily read. ASCII files should have .txt extensions, .doc extensions only if they are Microsoft Word or WordPad, and .wri extensions only if they are the original Windows 3.1 Write format.
Use standard version numbers
? Number each release
Release numbers give users and file librarians a way to quickly compare and choose releases, if two are available. Give each release a version number, and keep it up to date in your File_id.diz and Readme.txt files. Remember that archive file dates are not always preserved when usersdo
wnload and subsequently upload them.
? Version numbering is a subjective science, but there are general guidelines:
Use whole-number changes (i.e., 1.x to 2.x) only to indicate major additions or changes. If you've added many useful or noteworthy additions to features but the releasedo
esn't justify a whole-number jump, consider a .5 (if appropriate). In any case, include the word "Major" in your descriptions and File_id.diz file.
Use x.1 releases to denote minor updates and additions to features along with routine bug fixes.
Use x.11 or x.1a releases to cover bug fixes only.
Don't go beyond two digits after the decimal point;
usersdo
n't need your build history. If you are issuing a x.0012, reconsider whether it needs releasing.
Detail the version history in yourdo
cumentation
Don't miss this great marketing opportunity -- create a Version.txt, History.txt, or Whatsnew.txt file to tell users "What's New" and show them that the software product in which they're considering investing has a track record of continual improvement by a responsible author.do
n't include every minor bug fix or tweak, butdo
give reviewers and repeat users an idea of new features and major fixes.
Include a "New in This Version" section in the Help or Readme
In addition to a version history, include a "New in This Version" section in the Help file or Readme.txt of any upgraded product. This section should provide a quick tour of the important new features, without mentioning bugs or minor improvements. It makes it easy for users (and reviewers) to locate new features, and further reinforces that you are on top of fixes and making improvements.
Include a convenient ordering method
Put your pricing and purchase methods in an Order.txt, help, or otherdo
cumentation file, and be sure the user can copy the data to another format.do
n't force users to writedo
wn information from an "About" box or splash screen, or make them go online to navigate a potentially unavailable Website. Hiding or making your opportunity to make money inconvenient to users is unwise.
Employ a professionally and courteously prepared install program
Use a quality installation package that:
detects currently installed support files anddo
esn't overwrite them without regard to version numbering
gives users the option to back up files replaced during installation, or lets them decide during the installation process
offers a Start menu shortcut and (optionally) a desktop shortcut
doesn't cripple other applications
lets the user choose the installation folder
Include an uninstall function
Make sure your uninstall routinedo
esn't remove files it didn't install, and can optionally leave shared support files behind. If youdo
n't include an uninstaller, at leastdo
cument what your programdo
es to a system so it can be manually uninstalled. Some authors seem to feel that "if theydo
n't want to keep and register my program -- the heck with them!" Bad idea. They may not need your program just now, but may try a future release or recommend it to a friend who needs it, so it's wise to leave a good impression.
If your program employs advertising technology, explain any special procedures for uninstalling it.
Include common support files
While many users may have common files required to support your program, unless they are a part of the original, required operating system, include them with your installation routine. If supporting files are required, the programdo
cumentation should say so before the install starts.
Provide sample data, if applicable
A small sample database, entries, files, or other data may help a new user get off the ground and understand your system "hands on." By shortening the learning curve, you not only improve your chances of use and registration, but you may reduce support calls. Be sure the sample data file is large enough to show off the program's features.
Provide strongdo
cumentation
? Supply detaileddo
cumentation with the program
Strongdo
cumentation and a good overview are critical to your new users' satisfaction. As software developers flock to the Web, product information has increasingly migrated to the Website, sometimes leaving a hole in the product itself. Remember that users may not have convenient Web access or may not want to dial up their connection when they need a simple question answered, and your site may be temporarily unavailable. You should always include basic if not thoroughdo
cumentation with a program. If that is not practical, at least provide some introductory data and clear directions to further information and help. If your product is not a Web-oriented system, consider that it may be installed on machines with limited or no Web access, leaving your user completely stranded.
This being said, a link to a continually updated FAQ on your Website can be an excellent idea. The nature of your technical support inquiries may teach a valuable lesson about the weaknesses of yourdo
cumentation in both content and structure.
? Provide integrated help begin
ning with a clear overview
Think of built-in help as an integral component of your software. It's not an optional extra, and thinking of it in that way greatly limits the reach and usefulness of your programs.
Integrated help can also be a powerful marketing tool. In particular, the overview offers a great opportunity to tell users what the program is, what itdo
es, how to use it, and why they need it. If they understand how the program can benefit them, they're more likely to buy it.
? Be clear and literate
Make sure you check it for spelling and grammar, and ask someone unfamiliar with your program to "beta test" your instructions to see if they are clear. If writingdo
cumentation is not your strong suit, or the language unfamiliar, consider having someone write it for you. When indo
ubt, farm it out. It is important to look at thedo
cumentation from two perspectives of use:do
es it provide a good start for a new user? and, Are the answers to ongoing questions easy to find? Keywords are one of the most important components of help files.
? Use a friendly tone
It's fairly obvious that people prefer to buy from someone they like -- did you ever buy a car from a salesperson that rubbed you the wrong way? Write yourdo
cumentation and other files wisely, not as a wise guy, being careful to be friendly and not offend.
Anddo
n't over-hype your application, raising expectations that will only result in a letdown. And be honest - we aren't impressed by Software MegaCorp International Conglomerate names and attitudes with a guy in his garage behind it. Many of us work out of our spare bedrooms, too.
Offer and clearly spell out convenient support options
Provide an easy way for potential users to contact someone with questions. If youdo
n't have an email address or Website for support, you're behind the times. We live in an impatient world that wants immediate answers, and part of your job is assuming the role of customer service to patiently satisfy all levels of users. A "Frequently Asked Questions" section in yourdo
cumentation may help stem the tide of calls, and references to areas of your help file can be a sufficient reply.
Allow sufficient evaluation time and a smart registration incentive
? Consider offering the standard 30-day trial period
The 30-day evaluation period is standard and gives users enough time to fully vet the product and decide whether they want to keep it. A shorter evaluation period may be appropriate in some cases, but for some programs 15 days or 20 uses just isn't sufficient.
? Avoid setting expiration dates
If youdo
n't give users a fair chance to try your software, they may not purchase it. There are many schemes, and your choice may depend on the type of product. Some companies that issue software oriented to the Web use expiration dates for software (especially betas) instead of controlling usage through programming tricks. If you eventually disable your software, opt for a generous actual usage measurement. Otherwise, a user may install your product and not get around to trying it until after the date-based trial period is over. You both lose.
If you absolutely must put a drop-dead date in your trial software, place notice prominently in a File_id.diz or similar text file. Instead of relying on an expiration date, consider strong messages based on system dates to encourage a visit to your Website for an updated version.
?do
n't leave a Registry key that precludes future reviews
Make certain your time-limiting and uninstall routinesdo
n't prevent use of a future release. What may not suit someone today may be perfect tomorrow, and program enhancements may attract renewed attention. If your clever time-out scheme stops users from trying your program again, you will have effectively locked yourself out of a potential registration. If someone is so pathetic as to uninstall and reinstall your program every 30 days in order to avoid registration, let it be -- either you will eventually get a registration or you never would have anyway, so why hurt your chances with other potential users.
?do
n't hold back so much as to cripple your chances
While youdo
want to provide a strong incentive, holding back key features that help sell your program's usefulness can work against you. If a potential registrant can't use and appreciate a feature, it can hurt your chances. We've seen some programs that omit the help file, the logic of which completely baffles us.
?do
n't nag your user to the point of interrupting their appreciation of your program
They know you want them to register if you tell them occasionally. However, if you interrupt their use of the program to the point of annoyance, chances are they may not give it enough use to be impressed.
?do
n't require users come to your site for an evaluation key
Wedo
n't want to leave you our address so you can bombard us with marketing email, and most of us are going to give you bogus demographic information anyway -- we just want to check out your program. Put your marketing efforts into the program by making us want to use it, and by enthusiastic and well-written overviews anddo
cumentation.
Clearly Establish Distribution Rights and Licensing
It is extremely important to clearly state in yourdo
cumentation that the trial version of your software is available for distribution by any party. It is also imperative to state that the software is a free or trial version (evaluation, demo, shareware--whatever term you prefer). The main point is to establish that the software is free for individuals todo
wnload and use for a given period or under certain conditions, which can be established else
where in your text or in the program itself. Programs that lack these critical bits of information as clear statements cannot be posted in the Software Library.
Your statement can be as simple as, "XYZ is a shareware program. This means that you may test it free of charge. You may also distribute it freely to others so they may try it."
Copyrighted material = Lawyer letters
MIDI or other representations of copyrighted music and lyrics cannot be distributed without permission. Neither can certain support files, fonts, etc. It may be cute to include a drawing of your favorite cartoon character, too, but you may find a letter from a lawyer in your mailbox. And ZDNet can't post your creation. Our lawyersdo
n't want to hear from their lawyers.
Don't release a product until it's stable and polished
Few things are more annoying than encountering obvious bugs in an evaluation product.do
the proper testing before releasing your product. Make sure all the program functions actually work, include the proper error trapping, and know how the program's use of system resources may affect concurrent processes. If the product is still in beta, call it a beta. Once the product is ready for release,do
n't rush bug fixes or feature enhancements out thedo
or;
give other glitches and brilliant additions a chance to surface, and consider the embarrassment of a .1a, .1b, .1c, etc. -- they justdo
not inspire confidence in users.
Price competitively and wisely
Research the market and price your product based on an honest evaluation of the competitive software marketplace. Measure your product against other programs in the same category, and price it accordingly. There must be a reasonable balance between price and value to users. It is better to receive 500 registrations at $10 apiece than 50 registrations at $20 each.
Remember one important thing
Whendo
wnloading your program, we users desperately want it to be our solution - we want you to succeed. Take the time to finish off those little details. Consider the fine points of your packaging as the electronic equivalent of an attractive box - make us want to take your product off the shelf. It will be to your benefit when we take it to the cash register.
这是从ZDNET上摘录的一篇关于"获得好的软件评价"的文章.有人愿意翻译一下吗?
