May 96 Crabbs Apple
Volume Number: | | 12
|
Issue Number: | | 5
|
Column Tag: | | Crabbs 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 customers 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. Clariss 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, were likely to be up to our keisters in OpenDoc. And the software update mechanisms that we and Apple have in place just arent up to the task that this plethora of smallware will bring.
Todays Updates
How do you keep your customers up-to-date now? Lets 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 dont 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, its expensive and doesnt 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, its 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 Apples) and how to get them. One of the best of these sources is Level 6 Computings 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 dont send your update information to Level6, I urge you to do so.
Posting information to the various Apple newsgroups (Guy Kawasakis 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, MacWorld, and Mac Home Journal among others.
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 well 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 hadnt 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 dont 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 dont 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 dont give me that stuff about the version number meaning anything. Ive 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 its not a freebie).
Only after weve 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), youll win the gratitude of their customers, as well as yours (and youll make a few bucks along the way).