The Importance Of Self Updating Applications
Image via WikipediaThose
of us whose wares exist outside the browser are faced with the question
of how we update existing installations in the field. I agree with Scott Hanselman’s post
in that applications, wherever possible, should update themselves as
gracefully as possible. Across the spectrum of desktop applications,
there is a sliding scale of automaticity with respect to updates. In
order of ascending shinyness:
- No update functionality. It’s up to users to check your site for updates. They should be grateful they’re getting updates at all. Who’s with me?
- Updates are announced by email or RSS, but it’s the customer’s job to go and get the installer, and to install it.
- The application itself checks some version info at your website, and notifies the user that an update is available. Customer then manually downloads and installs it.
- New versions are automatically downloaded, and the installer runs with minimal user interaction.
- New versions are silently installed, and the user is notified upon completion.
The option you pick will depend on your technology and your market.
In
a highly locked down (anal) enterprise environment, autoupdates simply
might not be an option. Updates need to be managed by an administrator,
and there’s simply nothing you can do to influence that. Even so, in
these instances, there’s no reason you couldn’t send out updates via
email or RSS.
For desktop applications as typically used by
Mom&Pop / power users / small businesses, the dial can be turned up
for updates. The further the better in my opinion. How far you can turn
it may depend on the technologies you’re using, and how much time you
want to invest in it.
For example, if you configure your
InstallAware installer to look for web updates, it uses the WIndows
scheduler to periodically (say once per day) ping your website to see
if there’s a new version, even when you’re not using the app. The
installer will then be downloaded and installed, usually with no user
interaction at all.
My personal favourite, and the one employed on Home Document Manager (not RTM yet) is ClickOnce. Using the ClickOnce APIs,
when the application starts up, a background thread checks for a new
version. If there is a new version, it is silently downloaded and
installed. When installation is complete, a little balloon pops up in
the notification area stating that an update has been installed, and that the changes will take effect when the app is restarted. No effort required.
Particularly if your users are Mom&Pop. they simply don’t care about updates. So why make them think about them?
Why
waste time answering emails about issues that have been fixed in the
latest version? Pumping out the latest versions to your users is a good
way of keeping your plate spinning antics to a minimum, by allowing you
to focus on supporting the smallest possible number of versions.
If a major upgrade is available, having your app intelligently recognise this is a good way of selling upgrades too.
As
with all application shinyness, it’s a good idea to have the ability to
turn this off. Bury it deep if you want, but make keep the uber
controlling power users happy.
Does your desktop app auto update?
We have a home grown auto-update mechanism, that works much like
what you’re doing. When the application runs, the thread kicks off,
checks, and if there is something, balloon tip.
The problems we’ve run into:
We offer a choice: Install now. Remind me later. Skip update.
Why did we do that? Well, because we figured this mechanism would
not just be for bugfix updates, but also for major upgrades where we
would change upgrade fees. But IMO it’s a mistake to offer the choices.
We should just do the install of bug fixes and minor version updates…
For major version upgrades ($), we should probably alert them and give
them a link to a landing page that sells them the benefits of
upgrading. Let that be manual download and installation.
Despite putting a message in during the major upgrade process
explaining that continuing with the installation would require $$, we
created significant anger and frustration out of users who thought we
were trying to bilk them out of money for updates.
Second issue, giving people a chance to skip the update results in
people not installing fixes. Then you get support calls that would be
resolved had people just updated.
We’re in the home user market BTW.
Here is another thing to consider. Lifetime updates or only minor
version updates? How about if they bought version 2.2, and 3 weeks
later version 3.0 comes out. I think these are other topics that you
should explore ahead of time and make good decisions on.
If you don’t have lifetime updates, then you’ll be supporting two or
three versions of the product in the field, and getting support calls
for bugs that were already fixed, and feature requests for features
that are already implemented in newer versions had the person just
upgraded. You have to figure out the profit made from upgrades and
compare it to the costs of all of those support calls. (IMO, lifetime
updates is the way to go. It’s just worth it to have everybody as
up-to-date as possible.)
Lifetime updates also eliminates issues that arise from people who
bought and then a new version comes out and they want a free upgrade.
Alternatively, there is the subscription model, which you can offer
people the latest version as long as they maintain their subscription.
Alternatively, you can change your model so that new features are
delivered via “add-ons” rather than major version upgrades. So that you
can keep people up-to-date with the latest version of the core product
(essentially lifetime updates there), while delivering new features via
“add-ons” that they would pay for separately.
These last two alternatives seem the best of choices. They allow
automatic, silent updates, reduced support calls, money from existing
customers who buy from you again and again, and I imagine, the happiest
customers who always feel like they are getting their money’s worth.
Man, did I just ramble or what!