May 96 Crabbs Apple
Volume Number: 12
Issue Number: 5
Column Tag: Crabb’s Apple
Software Updates and OpenDoc 
By Don Crabb
How many of you are happy with your mechanisms for updating software for your
customers?
For that matter, how many of you are happy with the mechanisms that Apple uses
to update your customer’s System software?
And what happens once OpenDoc makes an impact on your business? What
happens when your own containers and your parts have to be updated? when other
parts from other vendors that your customers will want to use with your containers
have to be updated?
While we all might complain that the number of OpenDoc parts and containers is
currently on the sparse side, we also know that this is going to change. Claris’s plan to
make the next version of ClarisWorks an OpenDoc container par excellence will drive
the creation of a lot of parts. And you can expect other major non-Microsoft Mac
vendors to follow suit. By the time of the first customer release of Copland, we’re
likely to be up to our keisters in OpenDoc. And the software update mechanisms that
we and Apple have in place just aren’t up to the task that this plethora of smallware
will bring.
Today’s Updates
How do you keep your customers up-to-date now? Let’s consider their pros and cons:
• Mailings to those who send in their reg cards. You might get 50% of your
installed base that way, if you are extraordinarily lucky and persevering and
happen to sell a killer product. But that other 50% misses, and that ultimately
costs you money.
• A Web/FTP site. This works well for your more advanced customers, especially
corporate or higher ed customers with the high-speed Net connections needed to
suck down updates regularly and the IS staff to make sure they get paid for and
redistributed among their Mac users. Web sites work less well if you have a
substantial SOHO or K-12 user base, as they often don’t have the time or money
or Net expertise to make the daily Net connections needed.
• Dealers. This can work if you mostly sell through large computer or consumer
electronics superstores and you only expect to issue major upgrades. Otherwise,
it’s expensive and doesn’t have a lot of reach.
• Mail-order dealers. Pretty much the same advantages and caveats hold as for
large non-mail-order dealers. With catalog space at a premium for mail-order
dealers, it’s likely to get even more expensive to update parts that way.
Keeping Track Now
Your customers, of course, can avail themselves of other sources of information about
your latest wares (as well as Apple’s) and how to get them. One of the best of these
sources is Level 6 Computing’s monthly software update report. It costs $150 per
year ($97 per year for independent consultants) and comes as a comprehensive
24-page printed report, a disk with vendor contact information on it in setext format
(along with clickable FTP sites and URLs), and a Web site
(www.webcom.com/level6/). You can contact them at update@level6.com. If you don’t
send your update information to Level6, I urge you to do so.
Posting information to the various Apple newsgroups (Guy Kawasaki’s Semper Fi
and MacWay lists of course, as well many others), to TidBITS, and to the Info-Mac
lists is also a must do, as well as notifying the usual suspects - MacWEEK, MacUSER,
But even when you use all of these methods for keeping your customers updated,
even when you make multiple methods available to them for obtaining those updates,
the simple truth is that you end up missing a lot of them. And the smaller you are, the
more of a problem this is - it may even mean the difference between success and
failure. If you doubt this, just look at the latest reports from The Hartsook Letter,
InfoCorp, and other Apple-tracking agencies - these show that a small but nontrivial
portion of Mac customers are lost each year simply because they did not know how to
get software updates and assumed that updates were just no longer available on the Mac
platform - so they moved to Windows to get the latest version.
Future Updates
Web design and technology will get better, as will the availability of the high-speed
networking (ISDN, cable modems, ATM) necessary to bring all your customers to the
Web update trough. But even with slicker Web sites and better navigation aids to find
them, we still need a breakthrough in the way that we’ll deliver updates to our
customers without them having to even think about it.
That breakthrough - simply put - needs two things. One, we and Apple have to
simplify our upgrades. Just this past week I received update disks and several
CD-ROMs for a dozen different Mac products I use anywhere from daily to once in a
blue moon. But from the packaging these updates came in I hadn’t a clue which I should
apply immediately and which I should dump. Only after reading all the paper stuff in
the packages, the ReadMe files, and taking a good look at the files and installer
provided, did I have a clue as to the importance of each update. And I do this sort of
thing for a living. I don’t need to imagine how hard it is for others whose real jobs are
not bit-twiddling, but use their Macs to get their work done. I don’t need to imagine,
because I get a bunch of calls each day from these folks asking me what the hell they
should do with the SuperWhizBangPro V.3 Updater 8.12 they just got in the mail.
(And don’t give me that stuff about the version number meaning anything. I’ve had a
release 1.2.3.4 that was critical to my operation and a release 2 that was a total waste
of time.)
And two - we need a mechanism for better communicating the real point of an
update (and why customers should pay for it, if it’s not a freebie).
Only after we’ve done both of these can we focus on getting it to customers in a
painless and trivial way. My guess is that we need to look at the whole process as a
continuum and not as a set of discrete problems. Rather than divorce the installer
from the Web/FTP download widget from the email that was sent to the customer to
start the process, we need to figure a way to build the three parts together as an
“Update Object” that gets sent to the customer (via email, via a disk or CD-ROM in the
snail-mail, etc.) every time we issue an update.
This “Update Object” would have the mechanism for obtaining the full update
from its Net site, along with the chargeback method, and a clean, reasonable
explanation of why your customers need it and what it does. Once they say yes, a
simple button click would do all the rest. Pay for it. Download it. Scan their system
for its compatibility. Set the proper installation options. Do the installation. Then
test that installation went correctly (restarting, etc.), while fully informing the
customer on their screen what was taking place. For the wireheads among your
customers, the “Update Object” could also provide various manual interrupts or
single-step action.
I suspect that if any of you think about this problem for a bit, you could architect
the shell for this “Update Object”. I also imagine that if you license it to your fellow
developers (and to Apple), you’ll win the gratitude of their customers, as well as
yours (and you’ll make a few bucks along the way).