This article originally appeared in TidBITS on 2004-08-30 at 12:00 p.m.
The permanent URL for this article is:
Include images: Off

The Story Behind Take Control Updates

by Adam C. Engst

As you know, we offer free minor updates to our Take Control ebooks to customers; it's a great way for authors to keep their ebooks up to date with new software releases, to respond to feedback from readers, and to fix any mistakes that slipped in. From what we can tell, readers appreciate the service, so it's a great example of how publishing electronically helps everyone.

Helping customers learn about and download the updates has been challenging, however, and in this article I tell you what we've done, what we've learned, and what we're doing now. Even if you're not a Take Control reader, you may find it interesting to read about the pros and cons of different methods of distributing updates to digital products.

On Saturday we released three updates, version 1.1.1 of Glenn Fleishman's "Take Control of Your AirPort Network" (to fix a few typos that slipped into the 152-page ebook and add a $10-off coupon for Sustainable Softworks' IPNetRouterX), version 1.1 of Joe Kissell's "Take Control of Email with Apple Mail," and version 1.1.2 of Joe's "Take Control of Spam with Apple Mail" (to address changes in Mail 1.3.9, add clarifications, provide new screenshots, and more). It took some time, for sure, but the fact that we could do three updates in such a short time is an indication that we've come a long way from our start 10 months ago. In fact, in that time, we've tried four different approaches to providing free updates with varying levels of success; the lessons we've learned may prove instructive to others providing updates as well.

< mail.html>
< mail.html>

Password-Protected Archives via FTP -- Our first approach seemed sensible enough on the surface; we'd inform customers of an update via email and give them an FTP URL which they could use to download the update. To restrict the URL to customers, we protected the StuffIt archive containing the update with a password, and our email included that password. The approach worked fine in our testing, and it undoubtedly worked for many people, but it fell down in a number of ways:

eSellerate Coupons -- One of the core tenets of Take Control is to do more of what works and less of what doesn't, so we quickly changed gears. Our second approach to providing free updates was to send email to every customer of an ebook giving them a special coupon code that, when used in an eSellerate order, gave them a free copy of the ebook in question. This method worked quite well, due to a few advantages:

However, there were still some problems that made us unhappy with this method of providing updates.

eSellerate Redownload -- In an attempt to reduce the amount of effort and keep the unnecessary data out of our database, particularly with very small updates, we tried a third approach. eSellerate allows anyone who orders to download the file they've bought up to three times (the email receipt contains a URL that leads to a Web page with various after-order services, including another link leading to a Download Now button). By allowing three downloads, eSellerate makes it possible for people to work through problems they have downloading, but the download URL can't be posted in public. We had a tiny update ready, so we replaced the file appropriately in eSellerate, and then sent email to everyone who had bought that ebook, telling them how to download it. It was a big mistake, for many reasons:

Luckily, it's easy for us to solve customer problems; after a quick check to verify that the person is a customer, Tonya usually sends them a copy of the ebook they're having trouble getting. Readers seem to appreciate this fast solution to the problem at hand, but we'd of course rather avoid the problem altogether. The amount of work this method caused was insanely higher than any other approach, so we clearly needed to rethink the entire process if we were to move away from the free coupon strategy.

Check for Updates Button -- After talking about all sorts of crazy ideas, including an application that could store the differences between two PDF files and use that information to update an original PDF, I realized that I was thinking about the problem all wrong. In many ways, ebooks have a lot in common with software, and if a developer had asked me how to handle updates, I would have said to build update checking into the application, automatically downloading and installing available updates with user assent. Obviously, since we distribute PDF files, not full-fledged applications, there's a limit to what's possible, but enabling the user to check for updates from within the ebook itself was within the limits of possibility.

The trick for us is that we're now running Web Crossing, which, along with its many other benefits, is an entirely programmable system. With some help from Sue Boettcher of Web Crossing, I created what is essentially a CGI (Web Crossing calls it a "macro") that accepts as input data embedded in a URL and returns a Web page that tells the user if an update is available, and if so, provides a protected and obfuscated link to download the update. The advantages are numerous:

The system isn't perfect yet, of course. Certain download utilities have trouble with the way I serve download URLs through a CGI, and we discovered that if you use Acrobat Professional 6.0, you must set the Web Capture preferences to open Web links in your Web browser, not in Acrobat. (Otherwise, Web pages are added to your ebook, and the download link won't work.) I'm sure other issues will crop up, but as long as handling new quirks remains less work than any of the other systems we've tried and discarded, it's good for everyone.

Obviously, the particular system I've developed isn't portable outside of Web Crossing, but I hope that anyone who needs to provide updates to users can learn from our experiences to do it in as clean and efficient a way as possible.