Limit Update screen

After having successfully used WyBuild for a couple of months, I'm planning to deploy limited updates, based on some payment scheme. The help given here is useful http://wyday.com/wybuild/help/limit-updates.php.But when users no longer have the rights to an update, there is a very unfriendly response:1. An error occurred / unloading failed.2. Details: a page was sent back from the server.

A more user friendly reply would be "You have no more rights to down load updates from ..., Please contact ... for more information". This requires digging into the sources of WyUpdate, and say checking for a magic text in the returned web page: "Download rights expired". This change would be welcome for **all** your users.

A more user friendly reply would be "You have no more rights to down load updates from ..., Please contact ... for more information".

We're considering a change like this. Right now the best way to do things is to prevent them from even launching wyUpdate from your app if you already know their update period has expired. That way you can show them a pretty error message.

Each user downloads a standard binary w/o user information, so we cannot hide particular user dates in the binary. The last recourse is to contact our web server for particular user dates, thus doubling the action of updating. Of course, Wyday clients have access to wyUpdate and thus could do this job themselves... if they are in a rush.

We'll consider this.

Thanks for considering this feature in upcoming updates.

Perhaps it can be generalized. In the WyUpdate code where you detect and report that a page is returned instead of a WYU file, it should be possible to check for a set of key phrases (such as "Download rights expired") defined in the WYP and to define a corresponding set of messages to display (instead of currently reporting that an error "occured"). If this looks "doable", please consider defining messages in the different locals handled by the WyUpdate user.

This would make your product even more end-user friendly, which keeps your users happy !

Any update on this "error occured" situation for limited-updating ?This feature is very interesting for wyday users to get paid for updates.But end users get a "silly" "error message".

Or am I the only wyday user using this feature ?

No, but most customers prevent the end-user from ever starting wyUpdate from within their app if the update lease has expired. So, for LimeLM they use the custom license fields. (See: Custom license fields, Example #2: SaaS or time limited restrictions).

So it works something like this: the company has a menu in their app that says "check for updates" (or maybe they do it automatically). When the end-user clicks "check for updates" the app first sees if the "update_expires" value has expired. If so, then don't run wyUpdate at all. Just give the customer some way to extend their subscription to the updates. Otherwise, if their subscription is still valid, then launch wyUpdate.

This way the customer gets actionable data. They can actually buy a renewal subscription. If we just provided a customizable error screen then the customer wouldn't get any real use out of it. Most customers don't really read errors. All they see is "Error: blah, blah, blah."

Even technically inclined customers don't read errors. You can scroll through some topics on this forum and you'll see a user posts an error that tells them exactly what's wrong and exactly how to fix it. And then they ask what's wrong and how to fix it (a shocking amount of people don't read the error they're posting).

So, what's my point? Don't wait until the customer is inside wyUpdate to show the error. Do it within your app, and give them an immediate option to buy more time from you. Isn't that the whole point? Make it easy for the customer to give you money. Don't make them copy and paste stuff from error messages.

"No, but most customers prevent the end-user from ever starting wyUpdate from within their app if the update lease has expired".

All Wyday customers have to build another separate way of knowing if limit date has been expired. wyUpdate already do this, but is just too unfriendly to be used in a production way.

Nope I don't intend to buy LimeLM : I'll probably find another (unfriendly) limit somewhere on.