Thinking of building an online toolset - opinions on how I'm thinking of dividing pay version from free version wanted.

[Michael Morris]

I'm starting to sketch out some ideas for an online tool set of my own for use with fantasy RPGs. I'm going to be focusing on details that computers can track that people cannot easily like randomized weather patterns, celestial movements and the like. I've been thinking on how I'd divide the free version from the pay version and this is what I hit upon.

All current browsers support a storage mechanic known as localStorage. This allows a domain to store up to 5MB of data as key value pairs. This should be more than enough for what I have in mind, and even if more is needed then it should be sufficient for demos.

The thought is, the limitation on the free version is it would be entirely reliant on local storage, and this would be made clear to the user. Local storage lasts until the user clears the browser cache. So if you want to work with the app and not worry about accidentally nuking your campaign data with an errant cache wipe, you'll need the pay version.

I got this idea off of icomoon and it works well enough there. Thoughts?

 

[Umbran]

I am not familiar with icomoon, but broadly speaking - if your product isn't stable to *other* issues with the person's computer, that will be considered a flaw by the users.

Imagine that someone starts having problems with EN World - buttons start showing up funny, just after Morrus does an upgrade. It is probably a caching issue, and we'd recommend to clear cache and cookies. Now the user has a choice - not be able to use EN world properly, or lose their campaign data. Do you want to put users int hat position?

 

[Janx]

I think LocalStorage is segregated from the Clear Cache function in most browsers, thus negating Umbran's concern. But I don't use it to confirm that as all my apps use DB storage on a server.

also consider that you'd have to make your app handle a fork in storage resolution Free = read/write from LocalStorage, Paid = read/write from DB.

Granted, the nice perk is that DB storage costs you money, the very thing users would be paying for. But having to write (and test) your code resolving to either doubles your work.

You could just put ads on the Free version, but that's lost real estate for UI and nobody's going to click an ad for viagra while trying to enter campaign stats...

The free=local idea has merit. If you can be sure of how the data is protected from a basic cache clearing, it keeps things simple on where the dividing line between free and paid is.

 

[Jan van Leyden]

I don't like this idea at all. Software with an unreliable saving mechanism is a no-go for me, even in a free version. Frankly speaking, it's so bad I wouldn't even start to consider paying for it.

 

[Michael Morris]

I think LocalStorage is segregated from the Clear Cache function in most browsers, thus negating Umbran's concern. But I don't use it to confirm that as all my apps use DB storage on a server.

also consider that you'd have to make your app handle a fork in storage resolution Free = read/write from LocalStorage, Paid = read/write from DB.

It's not that large of an issue. Local storage is primary, and the system silently copies whatever is in local storage back to the server when a save occurs if a connection is available. Another advantage I'd like to aim for - the app can run without a connection.

Still, it's musings at this point. What I would like to do and what I have time to do aren't the same.

Granted, the nice perk is that DB storage costs you money, the very thing users would be paying for. But having to write (and test) your code resolving to either doubles your work.

There are frameworks already out there that handle this process.

You could just put ads on the Free version, but that's lost real estate for UI and nobody's going to click an ad for viagra while trying to enter campaign stats...

The free=local idea has merit. If you can be sure of how the data is protected from a basic cache clearing, it keeps things simple on where the dividing line between free and paid is.

True, I've done cache resets without affecting icomoon. So I'm guessing its a per browser situation.

 

[Janx]

I don't like this idea at all. Software with an unreliable saving mechanism is a no-go for me, even in a free version. Frankly speaking, it's so bad I wouldn't even start to consider paying for it.

I wouldn't sweat this concern just yet.

Umbran raised the technical concern that cache clearing MIGHT whack the HTML5 LocalStorage which would destroy the basic idea.

However, MM's testing implies that's not the case. It's basically something to verify before going forward, but it's probably not an issue.

And some common sense applies. it would be very retarded for HTML5 to define a space for client-side apps to store real data if the browser could trivially trash it during what is a pretty common task.

Single page javascript based applications using HTML5 and AJAX are a thing nowadays (the PalmOS that HP killed was based on the concept). So it is critical that LocalStorage be protected from general cache clearing as these kind of apps rely on it to store the user's data (which would end up in the user's profile in Windows, and thus be backed up if the user is applying a proper backup strategy.

 

[Asmor]

Clearing cache actually doesn't clear localstorage.

The biggest issue you'll run into is that people are going to want to access their stuff from different devices, and you can't do that with localstorage. There are other options, though. If you make it an extension for Chrome, you can use Chrome's storage, which is synced among devices. You can also use Firebase or Dropbox for syncing data. Firebase, in my experience, is easier to set up and it's nice because it has builtin support for several different oauth providers. It also makes it possible for you to share data among users, and see how people are using your app. Downside with Firebase is that the free version is limited to 50 concurrent users, and the next step up is $50/month for 200 concurrent users.

I don't think Dropbox has any limitations on concurrent usage, since each person is using their own personal Dropbox for the storage, but on the flipside you also don't have any direct access to their data. And, of course, it requires them to have a dropbox account.