Building a Better Shareware Image
Building a Better Shareware Image
Introduction .................................................. 1
The Problem and the Goal ...................................... 1
How to Reach the Goal ......................................... 3
Guidelines for Professionalism ................................ 4
Specific Requirements ......................................... 5
What the Requirements do not Cover ............................ 5
Requirement Exceptions ........................................ 6
Doing Your Part ............................................... 6
Introduction:
-------------
The "image" of shareware is extremely important to the
Association of Shareware Professionals and to each of us as
shareware authors. In order to build the best image of
shareware, especially of shareware produced by members of the
ASP, the following information and guidelines are presented.
The Problem and the Goal:
-------------------------
Shareware. What image does that word carry? Unfortunately, far
too frequently it carries the image of poorly written software,
poor user interfaces, beg screens, annoying distractions geared
towards forcing you to register just to get rid of the annoyance,
mailing a registration payment and never hearing from the author,
weekend programmers greedy for your money, and many other bad
images. In the eyes of many, the picture is not pretty.
Remember Michael Covington's article in PC World (July '88)?
What could prompt an article like that? Top quality software
with support that's among the best in the industry? Authors
responding quickly and positively to the needs of their users?
Not a chance! Any negative image is fostered and nurtured by
DemoWare, CrippleWare, NagWare, and worse.
Every year more and more people are placing their programming
efforts into the shareware market to see what will happen. In
the process they are making it harder for those of us to whom
shareware is a profession.
RRS Guidelines Page 1 of 6
Building a Better Shareware Image
Greed for squeezing every possible dollar from the public is
driving some authors to use practices which hurt the shareware
image and, in fact, fail to produce the intended results. Some
shareware authors are literally spending more time and expending
more energy, devising ways to force the user to register, than
they are on developing the software itself!
Some shareware authors sweat over ways to annoy and badger the
user into registering. Others sweat over ways to make their
program the best it can be so users will WANT to register. Some
shareware authors promote sales by scare tactics, misinformation,
and pure fabrication. Others compete by providing better
support, better responsiveness, more power, more flexibility, and
a genuine concern for their users.
Which will be spoken well of in the media? In the user groups?
In the offices and homes? Which will pass from hand to hand and
spread the fastest and the farthest? But most importantly, which
approach will stand the test of time? Which authors and programs
will be around years down the road?
As professionals we must be concerned with the long term effects
of what we are doing today. If shareware and the ASP are to
survive, then we must change the image of shareware. We must
combat the bad images, the horror stories, and the tasteless
registration inducement tactics. We must improve the image,
allay the fears, and promote professionalism.
How are we going to do this? We can talk until we're blue in the
face. We can make official statements and public announcements.
We can mount a massive public relations campaign. We can do all
this and more, and it won't make a bit of difference.
There's only one way to improve the image of shareware, the ASP,
and ourselves - we must put our proof in our code.
If we want people to have a positive image when they think about
ASP shareware, then we have to build that image with our
programs. If we want to be viewed as professionals, then our
programs will have to look professional. If we want users to
have confidence in ASP software, then ASP software must do
NOTHING to erode a user's confidence.
If a program has to rely on harassing the user in order to
generate revenue then that program doesn't belong in the
shareware market. The registration incentive should be the
quality of your program, not the user's desire to get rid of
annoying practices.
RRS Guidelines Page 2 of 6
Building a Better Shareware Image
How to Reach the Goal:
----------------------
As shareware professionals we must promote professionalism,
quality, and respectability. Users should think highly of our
programs, even if they don't register! Satisfied users are more
likely to promote a product by word of mouth and by passing out
copies, than unsatisfied or annoyed users.
Why do people register software? They feel comfortable with it.
They have confidence in it. It's easy to use. It meets a need.
It's well written, powerful and flexible. And more.
What does NOT encourage users to register? Forceful registration
screens. Built in time delays. Intrusions and interruptions in
the normal use of the program. The need for missing functions
(DemoWare). And more.
Shareware programs have been successful with no registration
reminders at all!
Aside from producing good quality, easy to use software, most
other registration encouragements have major weaknesses.
* Execution counters and date based registration encouragements:
How do you know how long a program has been installed? What if
the user doesn't use your installation program? What if one user
installs a program, uses it for a few weeks, and copies the files
from his hard disk to a floppy for someone else? The program is
already installed, so the other user uses it as is (the counters
are not reset). That person might pass it on to others, upload
it to BBS's, etc. At any given point in the chain it's very
difficult to tell how long a particular user has been using it.
It's very difficult to tell how many times a particular user has
executed the program.
It is not uncommon for someone to acquire a shareware program,
use it a couple of times, and set it aside for months before they
get a chance to come back to it.
* Time delays for registration reminder screens: No user in
their right mind will read a registration screen every single
time they use a program during evaluation! Why would you want to
force him to? Faster and more powerful computers are being sold
everyday because people simply do not like to wait. If you
deliberately force them to wait they will not appreciate it.
* User interruptions and multiple key-press checkpoints: These
tactics don't help users to feel comfortable with a program and
they don't help to build confidence in the software. Do you want
RRS Guidelines Page 3 of 6
Building a Better Shareware Image
the user to register because the program is worth registering, or
do you want to annoy the user into registering?
Guidelines for Professionalism:
-------------------------------
By now you should have a pretty good overview of the problem, the
alternatives, and the effects those alternatives can have. Here
are some guidelines that can help you to ensure that your
software will appear professional and courteous to those who use
it.
Registration Reminder Screens: A Registration Reminder Screen is
a reminder which requires user response, or which delays the
normal execution of the program while it is displayed.
You do not have to use Registration Reminder Screens. They are
strictly optional. However, if you choose to employ such a
screen, there are a few details you should keep in mind. These
screens should not attempt to intimidate or annoy the user into
registering. Registration Reminder Screens are REMINDERS that
registration is required if they continue to use the program.
Registration Reminder Screens should be employed with the user in
mind. Perhaps you want to display a Registration Reminder Screen
when the program starts, or when it ends, or both. Perhaps you
want to leave the text on the screen when the user returns to
DOS. If your program is a TSR, you might want to display the
screen the first time the user pops-up your program.
You should avoid minimum delay periods where the Registration
Reminder Screen takes control of the computer and forces the user
to wait. In any event, a minimum delay period must not exceed 3
seconds.
The "Press any key to continue" approach is preferred over the
delay period approach - it leaves the user in control, which they
will definitely appreciate. However, when taken to the extreme,
the keystroke-to-continue approach can get annoying too. You
don't want to interrupt the user over and over again to "Press
any key to continue". You also don't want to require the user to
enter some random number or string to get past a particular
point. It should never take more than two keystrokes to get past
a Registration Reminder Screen.
There are many ways a Registration Reminder Screen can be used
without interfering with the use and evaluation of your program.
RRS Guidelines Page 4 of 6
Building a Better Shareware Image
------------------------
Specific ASP Guidelines:
------------------------
Registration Reminder Screens should:
1) be displayed no more than twice each time the program
runs (or twice per day for long-running programs such as
TSR's).
2) not require more than two keystrokes to bypass.
3) not have a forced minimum display time of more than three
seconds. In other words, the RRS itself should not take
control of the computer away from the user for more than
three seconds.
Practices such as creating undocumented hidden files or printing
a registration form without the user's knowledge or consent are
prohibited.
What the Guidelines Do NOT Cover:
---------------------------------
1) Registration reminders may be displayed anytime the user
specifically requests registration information.
2) Simple messages such as a status line stating
"Unregistered" or "Evaluation Version" are acceptable as
long as they require no interaction from the user and do not
hinder the normal functioning of the program.
RRS Guidelines Page 5 of 6
Building a Better Shareware Image
Guideline Exceptions:
---------------------
If your program falls within these guidelines then you will be
helping to improve the image of shareware. You will be part of
the solution rather than part of the problem.
It is absolutely essential that the ASP protects its image and
reputation. Because of this, if you feel that you need to
stretch the limits of these guidelines, or go outside of the
guidelines entirely, then you will need approval from the Board
of Directors, or from a committee set up by the Board for the
purpose of handling these issues.
The ASP has no desire to control your life or your business, but
the ASP has a responsibility and duty to its members and users.
The image and future of shareware demands that the responsibility
be taken seriously.
Doing Your Part:
----------------
Think carefully about the implementation and appearance of any
registration reminders you intend to employ. Get feedback from
other members, from your beta testers, and from your users. Find
out how others feel about your approach.
Let's send a message to the computer industry. A message that
says shareware authors are serious. Shareware authors are
talented, capable, and professional. Let's send that message
through the programs we market. Thanks for helping to make
shareware the best it can be!
These requirements were voted into effect on January 12, 1991
during the ASP's Annual Meeting on CompuServe. All programs
produced by ASP Author Members must conform to these
requirements.
RRS Guidelines Page 6 of 6
Comments
Post a Comment