It started with beer.
It was the year 2000, and I’d just taken a job with the Developer Technologies group at Adobe. I’d been working on InDesign scripting as a contractor, but now I was a full time employee. This meant, among other things, that I had to respond to scripting questions from developers.
Most of the questions were quite basic. How do I make a new document? How do I enter text? Then, unexpectedly, a question came in that involved moving text from an HTML page on a web server into an InDesign (1.5 or 2.0?) layout using Visual Basic.
The guy asking the question was working for the Saranac brewery in Utica, New York. The brewery offers custom labels for special events—birthdays, graduations, wakes, and so on. Customers can go to the brewery’s web site and enter the text they want on their label, view a proof PDF of the label, and order beer for their event.
You can see an updated version (with fewer label templates than I remember) here:
http://saranac.com/shop/product/custom-label/
The script, the copy of InDesign, and the web page all lived on a server in the brewery’s office. The arrangement wasn’t ideal—the desktop version of InDesign (which was the only version that was available at the time) wasn’t made to handle multiple requests from multiple scripts at once. But the custom orders were infrequent enough that they rarely overlapped. (This may be the way the system works to this day. If so, they shouldn’t tell anyone.)
This seemed to me like a great way to use InDesign—I’d always dreamed of fully-automated publishing with professional quality typesetting, graphics, and color features. Automated publishing before InDesign had always involved poor typesetting capabilities, and limited color and graphics support. Using InDesign as your publishing automation platform could solve all of these problems at a stroke.
There was a problem, though: it struck me that this use of InDesign almost certainly violated Adobe’s End User License Agreement (EULA) for the product. I decided to go through “proper channels” and find out if there was a way that Adobe could create a license for this sort of use of InDesign. Even better, could we create a “server” version of the program—a version that could run without a user interface, and run multiple instances on a single CPU?
Literally a year’s worth of email correspondence with Adobe’s Chief Corporate Counsel followed. The biggest question was always: Wouldn’t such a product “cannibalize” InDesign desktop sales? I didn’t think so, as I thought that users who wanted template-based creation of business cards, newsletters, and flyers are do not tend to be natural InDesign buyers. I believed that making the InDesign format ubiquitous could result in a great competitive advantage—recall that, at the time, InDesign was making slow headway against QuarkXPress. InDesign could follow something like the PDF path to success.
We proceeded through a kind of Socratic dialog, working out what was allowed and what was not allowed by the EULA. The InDesign EULA, at that point, was based around the idea of one person operating one copy of InDesign on their computer. Could a customer, visiting an InDesign user’s office, sit down and enter text in an InDesign template? That would be allowed. Could you create a script for your email program that would take the content of a message from a customer and enter that text in an InDesign template? That would be allowed, provided you (the InDesign license holder) pressed a button or double-clicked the script to initiate the process.
Are you seeing a pattern, here? I asked if you could create a script that would watch your incoming email and trigger the process of entering the data for you. No. That would not be allowed.
And there we had it. Everything in the process could be automated, but the key step of making something happen had to be initiated by a human.
That seems like an odd way to accomplish publishing automation, to say the least.
As I asked around, I found that I wasn’t the only person at Adobe thinking about an “InDesign Server.” The InDesign team was already at work separating the user interface and “core” parts of the plug-ins that make up the product. The late, and wonderful, Whitney McCleary and I talked about exposing all of InDesign’s capabilites via a web interface. Her idea was that we’d put “Powered by InDesign” buttons on everything. It would have been great.
All the same, Adobe had always had a problem creating server-based products, and had a string of failed server-based publishing applications to show for their efforts.
The problem, I think, lies in the assumptions software companies typically make when they approach the topic of automation. They assume that if you want automated publishing, then you don’t care about type, color, or graphics. I believe that this assumption lies behind the failure of Adobe’s earlier server products.
I’m not sure where the above assumption comes from, but it’s as difficult to stamp out as it is wrong—like some kind of noxious weed. I want automated publishing that produces output that looks as good as it possibly can—as good as it could if had been laid out by a skilled InDesign user.
As we feared, when the powers-that-be at Adobe got around to designing a server-based version of InDesign, their first thoughts were how to limit its capabilities. The entire scripting object model would not be exposed. Instead, some limited set of “wrapper” functions would be provided.
Luckily, that approach failed (it’s too long a story to relate here, and would probably result in hurt feelings and/or legal difficulties if I were to tell it). I believe that InDesign’s document object model (DOM) itself argues against limitation. When Adobe eventually rolled out InDesign Server, the entire DOM was there. Anything a user could do with the desktop version of InDesign could be replicated in InDesign Server.
InDesign Server was presented to system integrators in a “some adult assembly required” fashion that included a requirement to buy a certain number of copies of the desktop version (as a sop to those who feared “cannibalization”). But it was enough. Silicon Publishing and other companies took the software and began building automated, high-quality publications for an enormous range of customers.
This is brilliant. InDesign, with all its faults, is the best publishing program that has ever existed. (No, really. This doesn’t mean that it’s done, as some at Adobe seem to think—just that it’s better than the competition. I’d say that they’re about halfway there.) Making it possible to connect the capabilities of this page layout and typesetting engine to scripting was great; making it available as a multi-instance web server appliance is even better.
These days, InDesign Server powers a universe of publishing solutions. When you go to Shutterfly, for example, to lay out a printed book of family photos, you’re using InDesign Server. If you order a cruise from Royal Caribbean, they will send you (via the web) a personalized cruise booklet composed with InDesign Server. If you design a book cover on Amazon’s createspace.com, you’re using InDesign Server.
Far from decreasing the sales of the desktop version of InDesign, I believe that InDesign Server led to increased sales by becoming a key part in automated publishing workflows worldwide. This meant more sales of InDesign desktop, as it was the program needed to create templates for this kind of publishing.
I meant to mention—there’s always the fear that automation will cost people their jobs—that InDesign Server would take work away from graphic artists. I don’t think that it’s worked out that way. Companies use InDesign Server to automate publishing tasks that could never be done by humans in any practical economy. Disney, for example, would be crazy to hire 20,000 graphic artists to create custom itineraries for their cruise line’s customers—every night. If this publishing task could not be automated, the company would simply not produce these documents.
InDesign Server provides new work for graphic designers—as the creators of templates for automated layout. TemplateCloud, for example, essentially re-sells template designs uploaded by their users. When a customer on their web site orders a print job based on a template, the designer gets a cut.
The Saranac brewery’s early use of InDesign as a web-connected publishing platform didn’t directly lead to the creation of InDesign Server, but it did help push Adobe down that path. Someday, I’d like to visit their brewery—but not to see if they’re still using the same method of making custom labels. I’d like to try their beer.