The ISV that published the program in question found the blog posting and explained the company's reasoning for displaying the popup screens in the trial version. This is the part that really got me thinking about the trail version for SMTP Diagnostics.
I didn't like the trial mode model used in SMTP Diagnostics when I first released it and I still don't like it. For starters, it is too confusing. In trial mode, the software will disable itself after 10 runs or 30 days which ever occurs first. While I'm not a fan of nag screens, which I prefer to call marketing screens, I believe just such a screen makes more sense for SMTP Diagnostics over disabling the software.
I would love to hear your thoughts. What would be YOUR preferred approach to encourage users to buy the product without interfering too much with the user experience?
Here's one idea I am playing with in my head: Eliminate the current model all together and instead use marketing screens. The user will see the marketing screen every 5 times that the program is run. Also, the user will see the marketing screen every 5 times a test mail is sent within a single run. Lastly, the test mail will include a tag line at the end of each message saying something like "Sent using the trial version of SMTP Diagnostics."
The benefit of this approach is that the program will continue to work even if it has been installed for months. The current approach does not allow for that. Under the new model, users who rarely use SMTP Diagnostics can get away with running the trial and clicking OK to close the marketing screens. Users who use SMTP Diagnostics on a regular basis will hopefully agree to buy a license to eliminate the popup screen and remove the trial version tag line in the email message.
What do you think of this approach? Or is there an approach I should consider? posted by Kirby | 18-Aug-2005 11:29 PM | comments (6)
I hate nag screens.
I hate advertising.
I hate time-outs.
So, guess that leaves giving away fully functional software for free :) he he he
What I really find most "acceptable" in trial software is if the software is functional, but some of the more "powerful" features are disabled or partially cripple/limitted. But, it depends a lot of the type of software how well limitations fit.
The SMTP program could simply not save/load profiles unless purchased. That way, it works 100%, but the user has no way to easily save multiple-conigs. They can fully test, and if they like, they will pay for save/load. Also, once your "batch" (command-line mode) is fully up and running, you could disable/limit that feature in part too.
I have tried a few commercial software titles that use this approach, including things like Maya/Carrara/3DS (graphics programs) that limit the number of vertexes in a drawing and/or disable the Save feature. Be sure your software is very stable before such a thing though, since some of these vendors instantly turned me off when I coulnt not Save, and then their product Access-Violated and all my work is lost (sad way to sell a product).
Thoughts?
Thanks for the feedback Mike. I hear what you are saying, but I'm not a fan of crippleware. What about this?
Fully functional for the first 15 days then display carefully placed marketing screens afterwards. Instead of disabling the open/save features a marketing screen will popup before the user can open or save a profile, and the market screen will also popup after every 5 times a test email is sent. Lastly, a tag line of some sort will also appear at the end of each test mail message, which is removed for licensed versions. The marketing screens would also be removed for licensed versions.
This approach leaves the program fully functional and does not disrupt the user experience when sending a test message.
I could also take it one step further to say after some period of time, say 90 days; the open/save features are disabled. I'm still not sure I like this because like I said I'm not a fan of crippleware.
That approach is similar to WinZip and GetRight, 2 programs which I use all the time. Winzip start up with the "splash" screen where you have to pick the "Use Eval Version" button.. kind of annoying but not so much so. I think after you work with a lot of archives you even get a dialog box stating that you use the program a lot and should consider buying it. getright (if I remember correctly) simply added marketing windows to a few places with an OK button that took 5 seconds to become enabled. I do not believe any features were disabled.
It really does come down to the specific software though and how it is going to be used.
I'm not a fan of crippleware, nor do I think everything should be free, but unfortunatly its a tough area for a small, specialized utility like this.
Yep, I totally agree.
Speaking of free, I'm toying with the idea that personal use is free while commerical use costs $11.95. An individual can get a free license in exchange for his or her name and email address. I need to think about it more.
Good luck dertmining who is using it for "commercial" use vs individual.
I don't personally like crippleware, but I think it is the only way to protect yourself. In my years of consulting and such, I have seen so many places abuse shareware licenses. Most every place (including some major companies) treat such licensing as "FREEware" instead. Thus, if you don't cripple some aspect of the program, it WILL be used in commercial environments without you ever seeing a dime. Guaranteed.
The idea of placing marketing screens in there after X number of days MAY be an OK way to encourage use. But, how do you handle such a thing when you implement command-line interface???
I'm sorry, but I still say, if a user wants it enough to EVER pay, they will pay whether you cripple something like save/load or not. That is such a straight forward aspect of the program to cripple -- it does not leave the user wondering what "Advanced" features work like that they can't get to or such.
So, I don't call your app "crippled" if save/load is disabled anyhow... I just call it slightly less optimal for the end user. It works in its entirety as far as functionality goes, less the ability to save (which, is just a convenience). Just more thoughts on this.
Mike, you mean to say individuals working for a corporation will use the personal version for free even through there is a commercial version available for a small cost? Okay, all joking aside, you are right. The likelihood of someone buying a commercial version is very slim. That idea is out. But you do hit a very good point with your comment "But, how do you handle such a thing when you implement command-line interface???"
I have been thinking about this all week. If an un-licensed user uses the command line interface from a scheduled task that is running under a different account than the one currently login then the marketing screen popup, a.k.a., nag screen, will display and wait for user input AND the user will not know what happened [how's that for a run on sentence]. The user experience will be one that makes SMTP Diagnostics appear locked when scheduled or running as a background process. Needless to say, there can be no popup during command line mode or the popup must have the ability to self close after a period in time. However, self closing defeats the purpose of a marketing screen.
I will think about this more this weekend, and the feedback thus far has been great. It seems I need to do a combination of things...fully functional for a short period of time then restricted functionality afterwards. Command-line is definitely something that needs to be disabled for obvious reasons and the open/save might be a good candidate as well. I still want every user to have the opportunity to try these features but it probably makes sense to disable them after the trial period.
Users can continue to run manual scenarios after the trial period, which will be helpful to those trying to resolve a critical problem. And yet there will still be a reason to buy for other users.
Thanks to all who posted feedback and sent feedback via email. I now need time to think about the right choice for SMTP Diagnostics.
Add Your Comment
