Time limited demo, 2 angles of attack, both foggy...

[gyroscope]

Hi, I've spent a while trying to script for a time limited demo and now I'm getting nowhere fast! I guess I'm trying to "reinvent the wheel" with this, as I'm sure there's a definitive way of going about it.

For the first angle of attack, I decided that for my first project, there'd be a certain number of times that the app could be opened. So I thought that the best thing would be to save the amount of times opened in a preferences file. I realised then that anyone could easily open the preferences file and change the number again, so I'm now not sure if that's the best approach. Here's my attempt at the end (For the last ten minutes I've been juggling lines, so it probably doesn't make much sense now, but gives the idea of what I was trying to achieve).

Code: Select all

on preOpenStack
   put the effective filename of this stack into tStackPath
  set the itemdel to "/"
  delete last item of tStackPath
  set the itemdel to comma
  set the defaultfolder to tStackPath

if tCount <16 then
  put the text of field "CountUp" into tCount
put tCount + 1 into tCount
  put tCount into line 1 of URL ("file:preferences.txt")
put tCount into field "CountUp"
    put the text of field "CountUp" into line 1 of URL ("file:preferences.txt")
 put line 1 of URL "file:preferences.txt" into field "CountUp"
     end if

    if tCount = 15 then
       set the enabled of button "Try" to false
       end if
end preOpenStack 

The second angle of attack which I'll want to use for future apps would be so many days. I've learned that this would involve putting "the seconds" into a variable, but how do I save it that the user has opened it for the first time, so that I could then start to add the days every time the app is opened? and where would this info be saved, other than a preferences file (which could be changed by the user? ) Very confused there...

Apologies for such a long post and so many questions but if anyone could lead me out of this fog, i'd be most grateful, thank you!

[Mark]

Hi Gyroscope,

A demo consists of two important features. First, it communicates its strengths to the user and, second, it shows which features of the application cannot be used until registration. As soon as the application can no longer be used, the demo no longer communicates and the features are no longer visible. You don't want to close your showroom after a user has been showing serious interest in your products for several hours or even longer: you want the potential customer to come back and eventually buy something.

I would advice you to not disable the programme after a certain period has passed. Instead, make sure that the programme can be used, while anything produces with the programme is useless. E.g., if you print, show "Unregistered" over the printed text and if you play a movie, make it skip the first few second, for example. There are many ways to disable features, while keeping the programme as a whole accessible.

Saving information in a preferences file is fine. You might want to hide the preferences file or give it an unrecognisable name. Even that is often not necessary, because most regular users won't mess with preferences files, while "advanced" users will find a way to keep using your demo. However, if you simply disable all core features of your application until it is registered, you don't need to keep any information in the preferences file. Only the registration information needs be saved, once the user buys a license key.

Best,

Mark

[gyroscope]

Hi Mark

Thank you very much for your info, that's certainly cleared a bit of the fog away! "Keeping the showroom open" as you recommended, makes perfect sense to me, so I'm going to go with a program that can always be opened.

However, if I disabled even a couple of features of my first project, the user wouldn't get a full understanding of its potential. (I don't want to "give the game away" at this stage as to what sort of app it is but when I post the finished app to gauge people's reactions, perhaps you might agree that I've made the right decision...) Because of this, I've decided to work it the other way around, i.e to still have a time-limited full working app but after the trial period, then disable features in a still-accessible app, as per your recommendation.

Saving information in a preferences file is fine.

That's good news Mark, thanks! So I'm still left with my prob of how to register the info that the user has opened the app for the first time, so that I can then "time" it from there, whether it be max amount of openings or max amount of days. Any sort of script guidance there, please?

Another question: is it relatively straightforward to save the preferences file as a plist file and place into the Preferences folder on a Mac? And, not being that familiar with Windows/Vista OS, where would I store a plist file on this type of OS (and is it called a plist here?)

Any help/guidance there would be appreciated please!

[Mark]

Hi Gyroscope,

What's the problem with saving the seconds to the preferences file when the user starts the application for the first time? Just write the seconds to a preferences file and read them the next time. When you read the value, you need to check that it is an integer and if not generate a new value. You also might want to make sure that the date is e.g. between 2006 and 2009.

Code: Select all

-- when starting the application
put url "file:preferences.prefs" into myVar
put line x of myVar into myStartDate
if not (myStartDate) is an integer then put the seconds into myStartDate

-- and later:
put myStartDate into line x of myVar
put myVar into url "file:preferences.prefs"

If course, you need to find out the right location for the preferences file. On Mac OS X this would be

Code: Select all

specialfolderpath("preferences")

and on Windows you might use

Code: Select all

specialfolderpath(26)

I think this number works with Vista as well, but you might write a simple repeat loop to check all numbers between 0 and 64

I am not sure whether to recommend saving a preferences file as a plist file. As far as I know, plist files are created by XCode and you can add some stuff there yourself, but this is unnecessary complex and you might be running into a mine field with this. I always use simple straightforward files for my preferences, even if I save them in a binary format. Of course, you could use (pseudo) XML for your preferences, but I don't see how that would help you.

I do have a very nice preferences management system myself, which I use for commercial projects. It reads or saves the global variables I need with just 1 command and I can use it across different versions of my software. I believe it would go too far to explain this here, though.

For a game, I think it is normal to enable the first level only, or to allow playing for only a particular amount of time. Another possibility is to pause the game every 2 minutes, showing a window with the message "Register to get rid of this annoying message" and an OK button.

I hope this gives you some ideas.

Best,

Mark

[FourthWorld]

A demo consists of two important features. First, it communicates its strengths to the user and, second, it shows which features of the application cannot be used until registration. As soon as the application can no longer be used, the demo no longer communicates and the features are no longer visible. You don't want to close your showroom after a user has been showing serious interest in your products for several hours or even longer: you want the potential customer to come back and eventually buy something.

Wise and well said, Mark.

gyroscope, you might consider taking this a step further to switch from a time-limited or usage-limited demo mode to a feature-limited one.

If you could identify a subset of features that are useful in themselves but still have enough others worth paying for, your demo app will likely get downloaded and installed much more frequently. The free subset should be something that's valuable on its own, and while it may sound like giving away the store if your app has enough other features worth paying for it's more like just giving away free samples, which encourages folks to use and enjoy and rely on your software, building the trust so essential to closing a sale.

This can also simplify the reg-checking code, since it wouldn't need to keep track of time or the number of uses. You can put that time into features and marketing, and you get an app that can build a reputation for being a hot commodity.

I don't know the specifics of your app, but if it lends itself to this you might be quite pleased with the results.

[gyroscope]

Hi Mark

That code will help me enormously, thank you again! I haven't had time to try it out yet but I'm sure it'll be perfect. My only experience with preferences files has been with the tutorial preferences file stack, which used the .txt extension and was saved with the stack/app folder. But now I understand that I can put preferences with a prefs extension in the System folder, and not have to worry about plist stuff (which by the sound of things is beyond my capabilities at the moment), I'm almost home and dry there, excellent stuff!

You also might want to make sure that the date is e.g. between 2006 and 2009.

For interest Mark, why is the first year 2006 in particular?

For a game, I think it is normal to enable the first level only, or to allow playing for only a particular amount of time. Another possibility is to pause the game every 2 minutes, showing a window with the message "Register to get rid of this annoying message" and an OK button.

I hope this gives you some ideas.

One of my future projects will be a game, so this has certainly given me some ideas, thank you very much.

Hi Richard

you might consider taking this a step further to switch from a time-limited or usage-limited demo mode to a feature-limited one.

Excellent advice there, but although my first project isn't exactly a one-trick pony, there still aren't enough features to disable, to leave enough working for the user to be satisfied with.

Thank you for the advice though, it is appreciated: I will more than likely go this route for a future project which would be leaning more towards a major app.