Software Promotion & SEOThis blog covers a range of topics concerning the SoftTester Shareware/ Software Download site. Topics include software product releases as well as SEO and software development information and tips.

This post if a follow-up/ response to The Lost Benefits of Handling Serious Errors post.

Whenever a problem is corrected in a software product, I assess whether a new release is necessary.

If a release is necessary, how many people will benefit? When I’m talking about benefit here, I really mean “How many people will come across the error and be inconvenienced enough to report the problem to me?”

There’s no easy way to make this assessment. Things I consider are:-

1. How long was the software package in circulation before the error was spotted?
2. How serious is the error?
3. How close is the next planned upgrade?

If a package has been in the field/ in use for quite a while, I am likely to only make a new release to the customer reporting the problem. Too many releases can be off-putting for people.

One thing I do is “push” releases. I email all registered customers to tell them a new release is available for download. I don’t wait for them to check for updates.

by ML

You’ve read the title, your thinking this is one of those lessons in putting error traps and user friendly messages.

Wrong.

You’ve probably read all that stuff anyway.

You probably know that the key to designing a web site, is to regard it as your 24 hours sales person. It should handle everything for you, without your intervention. Answer customers’ questions and provide online ordering.

But do we treat our software as it should have a 24 hour support person?

Probably not.

So the user gets an error, then what?
They look in our help file for support information, if they can access your program, what if they can’t.
A shortcut to the help file on the start menu would handle this.

So they find the information in your help file or on your web site.

What if it’s the middle of the night?

Most likely you won’t be accepting calls or replying to emails from upset users.

What can you do?

Well finding the problem is the biggest problem, I haven’t come up with a neat way to tackle this.

My idea caters for those occasions when the user gets an error, which you’ve already solved.

You’ll need to write a check for updates feature.

Then when the user gets an error, rather than quit the program or tells them to download and re-install, display your check for updates feature.

The user can download the latest version with your fix.

This will also give the user confidence if anything were to happen in a bought version.
Well, providing they aren’t put off by the error.

You may well think, why not just put the time into testing your software for a bit longer instead of writing a check for updates feature.

Well you could do this, in fact I believe developers should never stop testing their software even after release. But unless you work for NASA (who have people who spend all day and night reading through code) you stand a chance that you have a bug in your software!

On another point, I’d like to write a bug reporting feature.
If anyone has any experience of ideas on this topic post it here too.

Have fun making great looking masks with our Software!

by JM