旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커 � HomeCraft's Small Business Journal 넴 � SPECIAL ISSUE 넴 � The 1992 Summer Shareware Seminar 넴 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸� 賽賽賽賽賽賽賽賽賽賽賽賽賽賽賽賽賽賽賽賽� 旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커 � 넴 � NEWCOMER'S TRACK SESSIONS 넴 � 넴 � Writing Better Software 넴 � 넴 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸� 賽賽賽賽賽賽賽賽賽賽賽賽賽賽賽賽賽賽賽賽� MODERATOR (Bob Ostrander): The first panel here today is on writing better software. We've got some people that plain have written good software, and who know what good software is. I'd like to introduce them from the left, Eric Isaacson, author of A86 and Zip Key, two of the most successful and most popular programs out there. Both of them nominated for the shareware industry awards in their category -- and A86 nominated for Best Overall Software. Next, Tom Guthrey with the Animated Education Series, also nominated for a Shareware Industry Award in the educational division. His software has been raved about because it is exactly what the kids needed. It's aimed at the audience so well, so easy to use, and quite successful. It's been about two years since it was released originally, and has become the power in the educational community in shareware. On my immediate right, Paul Mayer, Z-Pay Payroll Systems. He's been around since day one, two, of Shareware. PAUL MAYER: 1978. MODERATOR: Back in the Commodore days, etc., etc. His main program is Grab Plus and Win Grab -- which you found a nice niche for software and exploited it very well. The odd-"man"-out is Marsha Meier, the main software reviewer at PBS. Doing more of the software reviews than anybody else at PBS - so I guess I should explain that we've got five people reviewing software in Public Brand Software. Most of them have other jobs, but Marsha just sits there. When you send in your software the odds are that Marsha's going to look at it rather than anybody else, so be nice to her. She does like scotch... As a result she can tell you what we look for in software; what makes a good piece of software; what will be successful; what is interesting to people and will go into the catalog. There is the one other ground rule for the seminar, by the way. This is all being taped. The rooms are pretty large, there's a lot of people here. We encourage questions. A lot of this is going to be questions and answers this weekend. I'm gonna ask all these people to do a few minutes about why they were successful; what they did to make their software good -- or in Marsha's case, what we look for in software. Feel free to ask questions. But because we're taping it, and because it is a large room, etc., feel free to come up to the microphone and ask your questions there. That way it will be on the record for the transcript later. I realize that might make some of you less likely to come up and ask questions, but please feel free to. We want a lot of interaction. If you can't come to the microphone or don't feel that you can, raise your hand and I'll get to you and repeat the question here. Off we go, let me give it over to Eric first to expound a little bit about what he thinks software is, what it looks like when it's good, and why this is. ERIC ISAACSON: The first thing I wanted to say is, I've been to a number of these gatherings of shareware authors. There's only been one Summer Shareware Seminar before this one, but we've had a number of meetings of shareware authors in which the big guns give good advice about how they became the giant shareware businesses that they are. The Marshall Magees, the Jim Buttons, those guys have built up million dollar a year companies out of shareware, and they are really marketing experts. They've gotten to that level by really having a flair for marketing their products. They had good products, just as good as mine or anyone else's to begin with, but they took it to the million dollar level with marketing. The message you'll hear from those guys, that I've been hearing for years, is that marketing is essential, that marketing is the main thing, that you can have the best program in the world, but it won't succeed unless you know how to market it, and I'd just like to give a little bit of a dissenting opinion on that topic. I sort of feel like I'm not a very good marketer. I'm mainly a programmer -- that's what I think of myself as being good at doing -- and I think of myself as being mediocre at marketing. My strategy has always been to concentrate on making my programs as good as they can be and letting them market themselves. I'm never going to make it to the million dollar a year level, just because of that, but I am making a comfortable living for myself. I think it's primarily because I've concentrated on making my programs good, so this is a minority viewpoint. Everybody else will tell you, "No, no, you have to have a flair for marketing, and Eric, you're really better at marketing than you think you are," but I really feel that an advantage of shareware is that the programs are out there for people to look at. If the programs are really, really good, they will spread themselves, and you will succeed, and if your program isn't making you a living and you think it's a good program, then you might want to rethink just how good is it. I think a good program has to meet several criteria simultaneously. It has to meet a real need for people; it has to have a good user interface - people have to be able to figure out how to use it; I think it's important that the program execute quickly; I think the documentation is part of the program itself -- if the documentation is poor then the program probably won't succeed. And there are a number of little things that can kill you: like a program that puts out brown text on a blue screen or some little thing like that. Those just make people drop it, right off the bat. I think it's important to know the difference between a programming tool and a product. Some little thing that you write for yourself - that meets your needs individually, but doesn't necessarily meet the needs of your potential audience - that's a programming tool. There are a lot of people out there that will use your program in ways you can't even imagine or will want to use your program in ways that you can't imagine. You have to envision those things and make sure that you've taken into consideration all the people who are going to want to use your program. Basically, I've talked for my few minutes, I guess. I'll turn it over to someone else. Next. MODERATOR: I fully agree with you -- an editorial comment here: I fully agree with you that a good program will sell itself; as long as it hits the distribution channels; as long as it gets out to enough BBSs to reach critical mass; and as long as it is mailed to disk vendors to help it get that print publicity. A good program, #1) is necessary, and #2) will rise to the surface. Like you said, you're not going to make the million dollar mark without the marketing, but then by the same token you don't have to go out and hire marketing people and do packaging and things like that either I guess. ERIC: Absolutely. MODERATOR: Tom, go ahead. TOM GUTHERY: Well, I guess to start I'd just like to echo the dissenting opinion, which - I guess - because that's what I've found too. That's why I come to these things. To find out about marketing. I take lots of notes, and then I get home and write code because that's what I like doing. In fact, I have a little game, the thing about sending out press releases - my personal little game is to see how much press I can get without doing it. I mean one day I probably will, because it's the thing to do and I have everything in place to do it when I go do it. But actually it's kind of fun right now to see how much I get when I do without press releases. And it's just amazing to me, because I sent in my program to the disk vendors just like other submissions from nowhere -- like the thousands and thousands that they get -- and it got noticed. That was just a big shock. It was a big shock to read Shareware Magazine and read, "this is the big pick of the issue," and I didn't even realize it was because I couldn't find Shareware Magazine on the newsstand. But I saw it last year, and it was like, here I am out of nowhere and here it's the pick of the issue. "Oh, really? Oh, really?" So I guess they can float to the top, which is real good news. On the subject of this session, which is what we're supposed to be talking about... It sounds kind of funny: "how to write good software". Like I know! But apparently somebody has decided that I do. The trick I used when I started -- I just downloaded hundreds and thousands of programs and looked at them. Not hundreds of thousands... hundreds and thousands. I don't want to get too extreme here. But I really just downloaded tons and tons of stuff. I'm like 90 percent of the computer users in that I didn't know about shareware for a long time. And when I found out - my neighbor gave me a catalog that was completely out of date - I was amazed! All this software? Great! And then I got a modem. I live in Austin, Texas and there's over 200 bulletin boards that I know about. You could get on them any hour each day. You could spend your entire life on the bulletin board systems there and never look at everything that was there; there are a few LARGE boards. There's one board that gets larger all the time. Especially starting out with a 1200 baud modem, you could spend the rest of your life downloading - even at 2400 you could. So anyhow, when I discovered that world - I mean, at the time it was what I thought of as "free" software; I mean, "Wow! All this stuff and you just get it." I just went nuts. I was a file demon. It was like - I mean, this was a while back - how many 360K floppies can I fill with this stuff, man? Wow! And in fact I have huge trays of stuff that I filled with it. I finally got to the point, after a while, where I stopped saving everything I downloaded. At 1200 baud it's kind of precious to you, because it takes you a while to download. Anyhow, I looked at tons and tons and tons of stuff, and probably - like Marsha in that situation - became a little bit of a shareware reviewer, because, #1) I'm trying to figure out what am I going to spend my time downloading, and #2) how much time am I going to try to spend figuring out how to run the program? So I got kind of the point that, if I can't figure this out right away, or if there's a tech problem, boom, I've got 20 other things that I've downloaded. I'm not going to waste my time with it. I just don't have time to mess with it. And I do something else that I've heard that shareware reviewers do, which is: run it without the docs, because it's faster if you don't read the docs. But then you find out real quick just how friendly it is. In my case, the stuff that I do is for pre-readers, so docs aren't real helpful for pre-readers. <> The latest program I did does, sort of, in a way, have docs, because it has speech capability. That way I can tell them what to do. What I've done on mine is follow the principle of "Keep It Simple, Stupid." I also hide some of the features, because you don't want the kids going in there and doing stuff you don't want them doing. So I segregated. I have a section where it's real obvious how the program works. If it's Animated Alphabet, and the kid's trying to figure out letter "A" goes with "Acorn", then he's not going to be helped a lot by a paragraph describing how to run the program. You make it to where, if the kid accidentally does the wrong thing, it would be fine. He would see all these funny letters on the screen. He wouldn't have any idea what it would mean, he could hit another key and it would go away, but the parents, hopefully, would know what it meant. In my case, we are talking about preschool software, so how complicated should it be to run? I think the most complicated thing I have, as far as what the kid has to deal with, is the mouse. When I first started doing the mouse, it had a picture of a mouse and it had a picture of a keyboard and they had to push one or two. That was for animated mouse, so I thought they probably could handle it. Nowadays what I'm doing is: the first time the software is run I expect a parent to run it. They do a set-up. The set-up is saved in the configuration and the kid never sees it again. The program just goes to where the kid wants to play. I also don't have a lot of docs on "these are all the features of the program." When you get in the program, you'll see what all the features of the program are, if it's interesting enough. So any help I have is going to tend to be on-line and be displayed when you first get on. If you run it without the docs - which is fine and which is how I try to design it - one of the first things you'll probably see is "Help." If you hit "Help," it will tell you how to run the program, and in my case, how to run the program for preschoolers... That's one thing that made me nuts. There's a program by a famous company that has a big, yellow bird. One of their programs is called Astro Grover. I couldn't' figure out how to run that thing. I mean, you had to use a keyboard overlay and keyboard combinations, and man, I couldn't run it. And it's preschool software, and I think that's a problem. So, again, in my case, I don't tell them more than they need to know. Another fact is that kids have an underground network. If you've ever watched them play Mario, they know where all the hidden stuff is - so they have fun, kind of finding out what it does. They want to try the Tyrannosaurs and the Brontosaurus and see what they do and tell their friends, "Look-it, the Triceratops is the best one" and so the word gets around in the kid underground network. Another thing about docs is they can get lost in file transfers and free packaging. You know how that works. So it's better to have it so it will run without docs, if that is possible. One of the two big things, as far as what always made me nuts when I was looking at tons of shareware, is not knowing how to quit the program. So on mine I have a menu bar on the screen that's just about visible all the time. It gives you access to "Help" so you know how to run it. And at least tells you how to quit, so you know how to quit. Because on an XT, if you have to quit by pushing a CTRL-ALT-DELETE, you might as well go out for a drink and a smoke before you come back and it's still not done. MODERATOR: Definitely, the programs have to be able to be run without the documentation. Good documentation does help, but it should be able to run without the documentation. Very, very important, I think. Paul Mayer, continue on this path... PAUL MAYER: Early this week I noticed it was almost time for the SSS, so I put some notes down on things that I think will help to write better software. Number one on my list is to listen to your users. These are the people who will give you the best input. You can isolate yourself in your code and think you've got a real dynamite program, but if the world don't think so, it's not going to fly. Listen to suggestions. If you get more than two or three suggestions for the same item, incorporate it in your program, add it in, add the features in. Also, listen to your users. This goes with documentation. If you've got a lot of tech support calls on a particular item, look at your program to see what you can do to change it so the tech support calls won't come in for that item. If people are stumbling through certain procedures, and you can change that procedure to make it more automated or easier to use, do it. Yes? QUESTION FROM THE AUDIENCE: Can you speak a little louder? PAUL MAYER: That's what I was afraid of. Last night I pumped a little too much beer in my throat and it's real raspy. You know your program too well. You wrote the code and you think it's easy to use, but your user may not. So if they call up with problems, listen to them and see what you can do to make it different. Standardize things. Look at your programs, like he was telling you, where he looked at hundreds and thousands of programs, and see what the standard interface is. Don't use the F1 key to exit a program when everyone else is using it for "Help." It does happen. Also, when you're going to create a new program, look around and see what's out there. We've got little terms like "YAM": "Yet Another Menu System." Don't write something that 3,000 other authors have already done, because you're competing against a multitude of programs and it's not going to work. Who wrote your manual? A couple of years ago I submitted to Public Brand a program for which I wrote the manual. I knew the program real well, so I wrote it the way I would use the program, not the way the user would. The program was rejected by Public Brand. The next year I rewrote the program and I had a professional write the manual and it got a trophy because the person who wrote the manual wasn't familiar with it. He took it step by step, piece by piece at a time and put the documentation together, where I took the program for granted and missed a lot of parts. 袴袴袴袴袴袴袴袴袴袴袴袴袴� ADVERTISEMENT 袴袴袴袴袴袴袴袴袴袴袴袴袴� 旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커 넴 INTEGRATE your products with Pinnacle Software's "SEE Utilities" 枋 넴 -- our indispensable collection of FREEWARE utilities designed 枋 넴 specifically for the shareware author and vendor. Menus. Date 枋 넴 alignment. Documentation. They're all there for you -- and you 枋 넴 can use them for FREE! 枋 넴 枋 넴 To obtain a copy of SEE from CompuServe, GO IBMSYS - download 枋 넴 SEE212.ZIP 枋 넴 枋 넴 For complete information, contact Timothy Campbell at Pinnacle 枋 넴 Software. CP386 Ville Mont Royal QC, Canada. CIS: 70154,1577. 枋 넴 GEnie: T.CAMPBELL11 Support line: (514) 345-9578. FREE files 枋 넴 BBS: (514) 345-8654 (9600 bps) 枋 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸 Installation programs: this is really important. If you give them a disk full of zip files - which is my next month's article for Shareware Magazine or next issue's - tell them how to unzip programs. Most people don't know how to unzip programs, or how to install things in different directories, and things like that. Bob was telling you he's got some disks with some installation programs on it. Can these installation programs do things? Does your program have to go into a certain subdirectory? Does it need modifying the AUTOEXEC and CONFIG SYS? If it does, ask permission, don't just go ahead and modify it. That's the problem with Windows programs nowadays. Everybody's using the WIN.INI file now. When you remove a program after evaluating it, you have to go searching all these files and find out what was put on your drives and where they hid these little things. You have a question back there? QUESTION FROM THE FLOOR: <> MODERATOR: The question is: if you are sending your software to a distributor - for instance in a PKZIP file - they should be sending it out with a PKZip or Unzip, and the instructions to unzip it. Yes, that is definitely true, and we're going to be talking about that in the session tomorrow, definitely. PAUL MAYER: Yes, I would suggest a GO.BAT file. Use it to give them instructions on how to unpack the file. PERSON ON THE FLOOR: <> MODERATOR: OK, he's complaining about shoddy vendorship. Basically, if I could interject here, what I've found is that a good disk vendor will - if you have a good install file that takes you possibly from a self-extracting file and explodes it out onto the proper subdirectory - if it's a good install file, the distributor is going to use that install file and put it out the way that you send it in or the way you want it that way. If your install file's no good at all, or doesn't work on DOS 2.0 or doesn't work on hard disks greater than G, etc., etc. -- a lot of time we see this and a lot of times the disk vendor will repackage with their own instructions and their own install file. They really will. PAUL MAYER: The good ones. He just brought up a couple of points that are really important, too, in installation programs. Don't force it to install only from A drive, you know? A lot of us have A and B, and we don't use A drive because it's 3.5 and we just got a 5.25 disk which is our B drive. MODERATOR: Or you copy it to your hard disk first thing and install from a subdirectory. PAUL MAYER: Right. Have instructions that have GO.BAT or README.1ST that tell them how to run the installation program. In the installation program, it doesn't hurt to have good HELP screens along the way telling them step by step what's happening. You know - we're going to allow you to pick a drive to install the program on, here's a default directory. Is this the name you want to use or do you want to change it? After you're all done, have a screen that tells them how to actually install the program and run it. Programming tools. You don't have to reinvent the wheel. There's an awful lot of tool boxes out there, even in shareware, that are standardized more or less because so many people are using them now. Windows. Standardization. Everybody learns the same commands. They don't have to relearn every program they have. If you have 25 programs you use every day, and they're all different, it's kind of rough. It slows your work down instead of increasing productivity. With these proven tool boxes, you don't spend your time debugging, because they're already bullet-proof and debugged. Always think on the lowest possible level of your user; like he said over here, "Keep It Simple, Stupid," - you know, "KISS." If you listen to your users, write for your users. Don't write for yourself as a programmer because you're used to DOS commands and things like that. Try and make things as simple as possible. Pull-down menus with help screens; help lines; things like that. Make it intuitive, where each step, as you go down the line, should be expected. Don't make them guess what they have to do next. Have it just flow nicely like a program should. And that's it for me. MODERATOR: Marsha, what did they forget? MARSHA MEIER: Nothing. Just let me reiterate what everybody else has said. Eric is absolutely correct, a good program will find its way into the marketplace and be successful. Advertising certainly helps, but I agree with that viewpoint. No question about installation -- any drive, any directory, let the end-user do his thing. Don't mess with my AUTOEXEC and CONFIG file or anybody else's for that matter. If I were an author I'd keep in mind that spending four months on a program doesn't constitute it being a good program. What you really ought to do is look at the marketplace: what's already there, and what is the need that needs to be filled. Yet another menu system. Quick Menu proved another one can come along and do real well. In the mailing list managers, Pironna Mail came along and showed us something better could be done. So there are programs that are there, but they can be improved. So you need to look at what's there, and ... who was it? Was it Tom who said if he couldn't get a program to run, the user will give up? The reviewer can't give up. We're stuck with trying to figure it out. And that's it. We ought to answer your questions as well. MODERATOR: I'd like to add to that. If you are going out and writing a program, look at the other programs. You are competing with other programs if your program isn't unique, and really darn few programs are unique. Look at what else is out there. Don't try to compete with them on price. All the time, we get people that say, "but you should put my program in the catalog rather than this other one because my registration fee is only $15.00 and their registration fee is $30.00." If your program isn't better than their program, that doesn't mean a thing. And if your program isn't substantially better than their program, you're not going to be competing with an established program successfully. You need to have more features or combination of features - or less features. Write a simpler program than what's out there. Single focus programs are quite successful, quite often. The tack that Paul has taken, of having a range of programs within one family, also works. His program, for instance, is an envelope printer. In its simplest form, it can just pick the address off the screen and print it on a laser jet, which is neat; which is useful to a lot of people; and a lot of people register for that function alone. That can be one product. He has another product where it takes it out of a data base and prints it on an envelope. This leads to a mailing list manager, etc., etc. A range of products can be built off the main engine, if you will. Then he's got one for Windows and that's a whole other story there. You can produce more than one product and give people the features they want for their particular application. You're much more likely to see the checks rolling in that way, I feel. On documentation, I wanted to add on having a full set of documentation and also a short - just two or three page - quick-start documentation. Tell them how to start the program up. Tell them what the program does. And give them everything they need to know - if they're an experienced user of computers - give them everything they need to know in just a page or two. I've done this with my DIMPLIS program. It is one page with no installation instructions really, except all you have to do is put it in the subdirectory and run it. But that is followed by three examples of how to use the program to do this task - or this task, or this task - that are each really one paragraph with two or three instructions. I've gotten a lot of response back from people who say, "This is a very easy program to look at to test and evaluate." You can aim your program at shareware distributors and try to get it into their catalog, but really, all we're doing is the evaluation that your customer will be doing, but we're doing it first. We're doing it for them to some degree. The potential customer, the guy who's got the program in his hands, he's the one you've really got to impress and he's the one that you've got to get to. I'd like to ask the guys on the panel here what you've done with beta-testing? How you've done beta-testing? PANELIST: Well, I have three kids. I mean, not being entirely facetious, I do. And I have a whole neighborhood full of kids - so in my case, I'm the magic computer shop for the kids. Especially when we were watching after-school kids. I don't know so much as far as beta-testing [is concerned], because I have kept the "how to run it" information pretty simple. Like I said before, the "kid underground" gets the news around pretty quick. I use that a lot to figure out what they like and what they don't like. For instance, anything with dinosaurs they like. Turtles are good, if you want to pay for the licensing fee or else go to jail, so I don't do Turtles. As far as real legitimate beta-testing ... early on, I did it myself. And boy, that makes you really sick of that program. I mean, just real, real, real sick. I mean, Animated Alphabet I can't even look at anymore because I get flashbacks. But for the latest one, where I had to do sound, there were technical reasons I to worry about beta-testing. With the Sound Blaster Adlib card you go out and find an ADLIB card, if you can't special order one, to see if it really does work with one. And by this time, I now have a lot of friends, and I ask, "May I put this on your computer?" and just test it, and test it, and test it. I also have eight folks that beta-test it, but they're never going to catch everything. I guess I'm talking more here about hardware problems that you might run across, so what I do is a limited release to my registered users and let them be beta-testers of the next product, not the one they registered. If you put out a product that's shareware and you find out, "Oops! A bug!" -- that's a problem. One big "oops" I almost did was the sound on this will run on the PC speaker, but it turned out it wouldn't run on the PC speaker unless you had a Sound Blaster installed. That's sort of a problem, because most people that had the Sound Blaster wouldn't use the speaker. And that's something I didn't find out until I had a beta-tester who didn't have a Sound Blaster installed. So if you get a shareware program out there, boy, it's really hard to retract. Especially if you send out 100 copies or something like that. So that's the one I really worry about is the shareware version. MODERATOR: About how long would you say you -- time wise, months or weeks or whatever -- between the time that you gave it to someone to beta-test and the time you sent it out to BBSs and distributors and etc.? PANELIST: Usually two or three months. It's usually a multi- tiered thing. What I'll usually do is get some registered users to use it. The deal is I can control the vector there. Even if I go, "Ok, this is cool, this is set.", and I've started direct selling it to the preregistered users - which is just an excellent idea because you get a lot of quick cash really quickly. But the deal is, if you do have a problem, they'll tell you about it. Also, what I've found is there are a certain number of registered users that the minute they find out you've got a new program, I mean U.S. mail never went so fast, they've got the check right back to you and they want it right away. And those people are going to be real understanding, if you have a boo-boo, which does happen. But at least you know who they are and you can send out "Oops, I'm Sorry, Here's the Fix" packages. You take care of it because they're your Number One customer. You're not going to want to mess with them. On the other hand, I can't afford a hundred beta-testers. So I get them to do it. And absolutely, if there's any problem, I fix it, and they don't seem to mind. I mean they're kind of with me on it - they're big fans, big supporters. QUESTION FROM THE FLOOR: <> MODERATOR: The question is, "Is there reduced registration fee to the registered users in order to get them to beta-test?" PANELIST: Well, they don't know that they're beta-testers. I'm just real honest, I'm just real righteous about it, I guess... MODERATOR: If you find a problem, you send them an updated disk. PANELIST: Man, like a shot, and they don't seem to mind. That's gonna happen, you know? QUESTION FROM THE FLOOR: <> PANELIST: Oh, yeah, well I test with real beta-testers. I mean, six folks or eight folks and they sit there for hours and they try it. But, you're just absolutely not going to catch everything. Even if it's something simple like a kids' program. And it's usually some dumb thing. But if you send out 100,000 dumb things, it's not so funny any more. MODERATOR: Paul, do you have anything to add on beta-testing? PANELIST: What I usually do is I use my present user base and look for the people who are the knuckle heads. The ones that have had the most problems in the past; wrote the silliest letters to me; and didn't really understand it. Those are the ones I write a letter to, or call them on the phone and say, "Gee, would you like to beta-test a new version?" Because, if anybody's going to find something wrong with it, these people do. That, and on Compuserve. I have a bunch of users on Compuserve in the ASP forum. You'll probably hear about ASP more later on, we have a little library that we can upload beta versions to. This way I get immediate feedback. When I update a version on Compuserve, they download it, then beat the heck out of it, and then send me an E-Mail right away that says, "Paul, something's wrong here. What do you think it is?" "Well, I think it's something you're doing wrong because it does work here." Usually if there is a problem, I can fix it, upload the new version and they beat the heck out of it again. QUESTION FROM THE FLOOR: Well, I'd like to add a caveat on using your present user base for a beta-test. I did that on my next-to- the-last release. I was using the INI file to keep the registration information. And all the people who beta-tested were current users. Well, as soon as it went out and found a new version INI file it started nagging them about having a shareware version. PANELIST: I had the same exact problem. I shipped a few people my latest Windows version. I was testing it and didn't look at the shareware screen. Later on I was testing it, after I sent out the disks, and the shareware screen didn't display properly. MODERATOR: These people both have a screen that comes up when you start the program that says, "Hello, this is a nonregistered Shareware version. If you would like to use it, you have to send me money." If you're sending that out to someone who's previously registered and say, "Please install this," they shouldn't be getting that screen - is what they're saying. Eric, you had some problems early on with Zip Key and beta-testing, I remember. PANELIST: You were my primary beta-tester. Bob essentially requested the Zip Key program. He was sitting and chewing the fat with me one night and said, "Well, what I'd like to see is a program that pops up in the background and looks up a zip code for you and sticks the results in your application." And I said to myself, "Yeah, that sounds like a good money maker." I sat down and in two to three weeks I had a prototype of the look-up window that looks up the zip codes. In about another six months I had the real product. That's a real illustration of the difference between a tool and a product. The main thing you think of Zip Key as doing is looking up zip codes. I had that written in two or three weeks. But to turn that into a product, it takes another order of magnitude of effort as far as time is concerned. Just all the diddly little details that you don't consider part of the central function of the program, but are essential to the product. Things like configuration and the order form section of the program where the program is selling itself. Especially important is getting it out there on other people's systems and dealing with the problems that result. Bob's company was on a network that was a little bit cranky about memory resident programs. It was a little bit of a struggle to get it to work on his system. So it is important just to get it out there on different peoples' systems. If you're not real confident about how solid it is, then you can kind of gradually ramp up. With Zip Key, I made the first release and I called it 0.7. I wasn't even confident enough to call it 1.0. I released it only on my local bulletin board system in Bloomington. I figured that it would spread a little bit from there. I didn't put any restrictions on it. It could go wherever it wanted, and I guess I mailed it to one or two distributors. PBS had it, but it was sort of limited. That gave me some feedback before it really spread all over the place. Another thing I did, which was really helpful, was I got my next- door neighbor - a woman who had not seen Zip Key at all, and was not tremendously computer literate - I got her to sit down -- and I actually paid her to do this -- to go through my manual; read my manual and play with my program at the same time. I sat behind her and watched her do this and saw the problems she was having with following my manual, and following my program, and figuring out what was going on. I got lots of real good input about how I should adjust things -- and it was mostly the manual I was adjusting, but a little on the user interface as well. Just sitting there and watching somebody who had never seen your program before at all is a real revelation. MODERATOR: Marsha, it's real easy for people to sometimes use professional software reviewers as pseudo-beta-test. Is this generally a good idea and do you end up getting a better... PANELIST: Not from PBS. The answer is yes and no. Let me see if I can give you a good answer. It only works if you're a flexible author, and you're really interested in putting out the best possible program. I have beta-tested about four programs, two of the four are in our library. Three out of the four authors said, "Yes, that works."; "No, that doesn't work."; "Oh, I didn't think of that."; "What other feature," etc. The fourth author decided, "Well, you're not really a programmer; you're just a reviewer; you don't know what you're talking about." And it loses something. Those kinds of people are hard to work with. But if you're open and receptive -- and you don't have to do everything your beta folks tell you to do -- but like Paul says, you need to listen. I mentioned to one author, "It will take between six months to a year for your program to do really well." He got mad and hung up the phone. That's fine. That happens frequently. <> Well, it really does, that's part of the job, and a year later this author called back and said, "Hey, lady, we got ten registrations this month." And I said, "Yeah, that's right, that's how it works." But you've got to listen to the people who are out there and know what they're doing. And this poor man has had his hand up three times, you ought to at least get to ask your question even if we can't answer it. QUESTION FROM THE FLOOR: I was wondering, perhaps it's obvious, I have now several versions of my product out in shareware. As I develop new versions I keep the one that I have been using as my registered version and put it in Shareware. MODERATOR: That's called the Olderware concept. Take the new version and send it to the registered user, send the older version out into shareware. My personal feeling is: that is looked upon by the potential customer that is registering your product as, "Okay, he's letting me try this out. And he's got another program with more features that he'll sell me." Sometimes that can be successful. Sometimes that can work against you, if the potential customer gets annoyed by the fact that you haven't trusted him to look at the whole product. But that's a topic for another panel, on registration incentives, later on. QUESTION FROM THE FLOOR, SAME PERSON: That means that what I put into shareware, I know works. MODERATOR: That definitely does that for you. Yes. Yes. QUESTION FROM THE FLOOR: First I'd like to ask, is there a convenient source for BBS lists around the country? MODERATOR: Boardwatch Magazine has a good list all the time. The Computer Shopper Magazine. The ASP BBS list, which is on some BBSs and is available. Talk to the people at the ASP booth tonight. Most BBSs have a list, either the Darwin list or the USA list - I think Darwin is pretty well disappearing now. There's The List. Most have a local BBS list. Also, for BBSs in your local area, contact your user group. A user group in your local area will usually have a list of the BBSs in town. But Computer Shopper regularly prints a big -- page after page after page -- of lists. PANELIST: I, for the first time, just send out a hundred programs to BBSs - prior to that I'd only done a few, because I didn't know where they were and I didn't have a 9600 baud modem and I didn't have somebody else's money to spend on the phone calls. There's a list put together by a guy named Bob Ostrander in PC Computing's Guide To Shareware, in the back. It worked for me. It's kind of narrowed down to a hundred, unless you plan on doing mail-outs to a thousand BBSs - lots of fun. MODERATOR (BOB OSTRANDER): I didn't know that. I've got to read that book. <> QUESTION FROM THE FLOOR: To Ms. Meier. What are the top three criteria that you look for when rejecting software, that come to mind? PANELIST: Oh, gee. I guess the first thing would be easy installation. I said it last year and another man sitting here - I don't know, are you going to pay me this year - WinGrab and all the Wilson Window-Ware are just good, fun examples of easy, easy installation programs. Second criteria is - it depends on what category - but if it's a game, for example, it needs a mouse. And not everybody agrees with that. MODERATOR: To some degree, pizazz. PANELIST: But in games it's easier. I'm not gonna sit there and do that arrow key business when I've got a mouse over here and I can go faster and easier. Any time you can do a toggle - a sound toggle; an upper and lower case toggle; a color toggle -- to give people a choice. I know! Along with Charlotte, I'm hearing impaired. You get these programs with beeps and whistles and geesh! But you get to be a nervous wreck! I can't afford to be a nervous wreck when I'm working on something serious. So give me a chance to, at least, turn the bells and whistles off. Give me a chance to use upper and lower case, which is better for my eyes. And the third thing is that I would talk to you about registration and author support. I look for it, even when I review. It ought to be easy. I have called authors and said, "I'll send you my $50, but I've got something planned for Wednesday and I need it on Monday. Will you send it? And they say, "Yes." The worst that can happen is the author is going to lose some money. The likelihood is that they're gonna get a sale. I like registration numbers that work on updates. ICON Master is a good example of that type of program. I have my eight digit registration number and every time I update I can keep the same number. It makes it easy for me. And I like authors that will talk to the end user. You call Paul Mayer, he'll talk to you. You call Eric.... <>. MODERATOR: He publishes his own number and answers his own phone. PANELIST: If he gives me another pie this year, I'll be nice. MODERATOR: You had another question. QUESTION FROM THE FLOOR, THE SAME PERSON: There are three operating systems on DOS compatible computers. If you are carrying versions for each, how does this proliferation of operating systems affect your development? MODERATOR: It does make sense to have a program written for DOS, a companion program for Windows, and sooner or later it may make sense to have a companion program for OS/2. I'm not sure. As far as publicity: right now Windows is where it's at. As far as the user base, or the potential customer base, there are far more people using DOS without Windows than are using Windows. So, in the long term it looks... There's an argument that DOS is what you should be writing for because there's more potential customers. But for publicity purposes, Windows is very active and people are switching over and becoming real boosters of Windows. And buying new programs for Windows. So that's a very hot area there also. So put them out for both. Paul has the right idea. We're just about out of time, but I do want to ask one more question. What language do you write in and what tool boxes do you use? PANELIST: I write in GRASP - the Graphical Animation System for Professionals. Which is from Paul Mace and started out as shareware and is now commercial and is real hard to find. It's an interpreter language that's kind of like basic. What it is, is a bunch of "C" libraries that are already put together for you. It's written in "C" and assembly. It's an easy language designed specially for doing animation. And since that's the excuse I have for doing children's programs, it works real well for me. The tools that I use are Deluxe Paint and Animator as an animation enhancement tools. But I don't use any programming tools, just GRASP. MODERATOR: Paul, I know you write in Turbo Pascal. PANELIST: Right. Turbo Pascal and Turbo Pascal for Windows. And the tool boxes I use are from Turbo Power, which puts out B-Tree Filer - for both DOS and Windows. They put out Object Professional, which has just about every routine in the world you can think of. You don't have to re-invent any wheels. There's some new stuff on the horizon, I can't talk about, for Windows. It's unbelievable. PANELIST: I use just two products. Both are shareware. Brand new. Click Bar has every button imaginable. Has a very reasonable registration of $35.00, I think. And S-B Install, which will create a Windows install program for you. You ought to look at those. PANELIST PAUL MAYER: One last thing. If you are going to develop Windows programs, I found out on Compuserve when I did my first version of WinGrab, I had not really played with Windows. It was on a shelf for over a year. I never used it or anything and wasn't really familiar with Windows programs. A couple of my beta-testers were the sysops from the Windows forum. And, boy, did they give me some great input. I mean they put the program together for me. << end of this session >>