Rules Of Thumb For Shareware Design
From the first day you spend designing your program, you should try to keep the final goal in mind. When you release your program, you want it to be something the user will want to download, use, and hopefully register. From the writing of the very first lines of code, you will need to keep these goals in mind.
Writing a computer program is easy. Writing a useful program is hard. Writing a computer program which is so useful that people will want to actually pay for it is a very difficult thing to do. I've come up with several useful guidelines which I try to bear in mind when trying to design a program. You might find them useful as well:
"A shareware program must sell itself."
This is the single most important thing I tell people to bear in mind when designing their program. A professional shareware developer is a person who is trying to sell software. However, he or she can't be there with the prospective customer. He or she can't look over that person's shoulder and explain how to use the program. The developer won't be there to point out cool features to the user. Thus, the program has to be able to do that itself.
Once downloaded and installed, your program is going to have only a very short period of time, perhaps even just one run, to sell itself to the user. Users tend to be skeptical of any unproven shareware program, and your work has to do everything it can to convince the user that it is worth his or her valuable time.
What does this mean in practical terms? Run the program and watch it load up. Does it load quickly and cleanly? Is the first thing the user sees attractive and interesting? How about the second thing? Look at the interface. Is it clear? Is online help easy to find? Is it even there? What about your cool features, the things you're really proud of? Are they easy to find? Are they mentioned prominantly in the docs? Is there a Tip of the Day feature to point them out?
Your program should, if all possible, be aggressively helpful, aggressively easy to use, and aggressively interesting. Once you have a program the user actually wants to use, the battle is won.
"Shareware is around forever."
One big difference between shareware and store-bought, shrink-wrapped software is longetivity. All of the games on store shelves now will be gone a year from now (or returned in different, discount packaging). The business applications (like Office) will have disappeared, totally replaced by new versions. As time goes on, older software will disappear from the stores and the public's memory.
Shareware, on the other hand, once released, never disappears. Once it starts spreading its way around the net, landing on CD-ROMs and getting spots on BBSes, it will always be around, always be downloaded, and, if it's good, will always be bought. If you release a version with bad bugs, someone will always be able to get access to that version.
This is, in some ways, a bad thing. Your mistakes and missteps will always be there for someone to find. The advantages of this situation, however, far outweigh the disadvantages. The first game I released, Exile, first went out in late 1994. All through 1997, even though it was an old program, dated in several ways, and was competing against several superior sequels, its sales were still solid and constant. Even though there were many factors weighing against it selling well, old versions of it were still percolating their way around the Internet, reaching new people who have never heard of an Exile game.
If your program is good enough for people to pay for it, it will continue to earn registrations for a long time. The level will drop and eventually reach a low plateau, but there's a good chance it will stay at that level for a long time. This longetivity has an important corollary:
"A shareware program should be aimed not only at people today, but people several years from now."
Whenever you make a major design decision, remember that people two years from now will be looking at it, and that their money will still be good. This means that you should look at the current operating system situation, and try to write your program so that it will run on whatever OS people will be using two years from now (as a corollary: writing a game, or anything else, for DOS now is a very questionable idea).
Another way to use this principle is to not worry too much about download size. Many new shareware developers agonize about the size of the demo the user will download, trying everything they can to get the package smaller, even sacrificing quality to do so. Remember that it's not that bad a thing to make your download be a little bit hefty, if making it larger means a higher quality program. After all, modems are only going to get faster. Today's large download is tomorrow's small one.
"You can't do everything. Practice triage."
Developing a shareware program, polishing it, and getting it out to the market is a huge endeavor, and, for most people, it will be a part-time one as well. Time is always short, and every hour has to count.
A necessary and unfortunate side effect of this is that you won't be able to do everything you want to do with your program. Won't be able to do everything, that is, unless you want to delay its release for a very long time. It's very easy to get so focused on forming your perfect dream program that you never actually finish it. Your masterwork sits on your hard drive forever, and nobody ever gives you money for it. Better, instead, for you to compromise on some features and actually release it!
Compromise is a difficult thing. When your dream program is clearly drawn in your head, it's a tough thing to say "OK. I'm going to sell my vision short here. And here. And here." This compromise process, however, is almost always necessary if the product is ever to reach completion. I usually decribe this process as Design Triage.
Triage is a term from first aid and emergency health care. When faced with a large number of wounded and a limited number of doctors, it is necessary to perform triage, that is, to look at the injured and figure out which of them are most in need of immediate aid. The most wounded are immediately dealt with, and the less urgent cases wait in line for aid.
When looking at your program and seeing the things left undone, perform triage. Write the most urgent code first. Then the next urgent, then so on. Eventually, you will see some features that, while nice, aren't absolutely necessary. These include things like support for higher resolution and multiple monitors, or fancy extras that only tangentially affect the use of the program. These are good things to have, and should be included if possible. However, if you have a choice between supporting all kinds of different kinds of hardware and actually having time to finish and release the program, always choose the latter.
Back to Designing Shareware Page