InDesign for the rest of us: the power of document model abstraction
Meeting the beast
I tried Adobe InDesign 1.0 roughly 18 years ago. I felt like I was in the cockpit of a spaceship, as I had felt before, when working with “professional” design tools: FrameMaker, Xyvision, QuarkXPress had been similar experiences. Working for one of the largest print conglomerates in the world, I knew that such a tool could produce flawless output worthy of the finest publications and the largest productions runs. I also knew how unlikely it was that I would ever produce documents with it by myself. Perhaps in collaboration with a professional designer or typesetter, but life was (and still is) too short for someone with my attention span to master such a thing without a compelling reason.
Fast forward to a year later, and I found my reason. As I’ve mentioned elsewhere, when we started Silicon Publishing we were faced with an awkward reality: unable to afford a true server-based composition tool for our new business, we latched onto InDesign 1.5 as our “composition engine.” I dove into the automation side of InDesign, and at least learned how to script it. Then we hired professionals we’d known in our former life to do all the composition and layout, letting them figure out the design side.
Two daunting dimensions
That was a very fun and challenging time. Our previous database publishing work in a decades-old organization had followed a very specialized workflow: we “programmers” would feed markup to the “typesetters” who would handle everything about layout, type styles, graphics, and settings to ensure proper output for print. They didn’t know what database denormalization was, we didn’t know what leading or kerning were, and both teams lived happily in our distinct worlds.
With our new found friend InDesign this was not possible, because the automation model didn’t provide for separation of content from presentation (as was more the case with FrameMaker, for example, or especially with Xyvision, the tool we used at the old company). When I dove into that other side, I found not only that the interface of InDesign was daunting, but even if I were to master that, the fine arts of design, typography, and print production represented challenges that might take even more lifetimes.
How do you drive the spaceship?
The user interface alone confused me. At that time, all I really knew was Microsoft Word, which was very easy to jump into. You simply started typing. But InDesign… this was more like “Word meets Photoshop.” Before you could type a single word, you had to create a text frame. Beyond that, there were (even in those ver. 1.5 days) many tools and settings, with an endless set of parameters that must mean something to somebody. I bought Real World InDesign and the Adobe Classroom in a Book. I stumbled, but as time allowed, I learned enough of the interface to get around.
Where do you want to go?
As I learned the tools and settings, I realized that as hard as it was to master this complex software, that was actually going to be the easy part. This is because I found that I really had no natural aptitude for design or layout. To a certain extent InDesign has artificial intelligence for things like properly implementing optical kerning, but that only goes so far. How big or small should a heading be in relation to body text? How much whitespace before or after headings? How do serif and sans serif fonts combine? I have gradually learned typography during the intervening years, but to this day it remains a matter of “knowing what I don’t know”. Instead of mastering arts for which I have little ability, I learned how to build systems that let designers design, programmers flow data, and end users edit content without any of them having to learn anything about those other domains.
The incredible power of templates
Say we had a catalog to automate: we would hire a designer to create a mockup of how the output should look, and in their Paragraph and Character styles, in the positioning of the text frames, we’d find the magic style that gave the document its soul. We would iterate a bit, sometimes creating features that InDesign didn’t yet have. Some examples: we created tables, bullets, and balanced columns before InDesign offered them. And we did this by following the instructions of the designers, for whom we had the utmost reverence. To the greatest extent possible, everything about page geometry and the style catalog would be in the document template. We found that as InDesign matured we needed ever less style-related code, allowing us to remove the training wheels, such as our clumsy home-built table model.
Once we handed off a database publishing project to a client, their designers were omnipotent. They could create any geometry, any style that they wanted, and the application would flow data to render the output just as they had intended. The one gotcha was in binding the data to the page objects. However, we’ve gotten better at this over the years, and even in 2000 we were creating great template-driven workflows. Applications ran for years (several for 10+) without requiring much intervention. Our database publishing work at that time eventually culminated in Silicon Paginator, which has powered some very large-scale publishing workflows, and which keeps moving forward today.
The heart of InDesign automation may be the template, but InDesign doesn’t tell you much about what a template can do. Adobe supports a special file type (.indt) that can be supportive of template-driven workflows, but the main reason for tools like Paginator to exist is found in the complex data binding required by parts catalogs, financial statements, cruise booklets, etc., because none of these document types was really considered in scope by the creators of InDesign. However, they did provide complete exposure to automation, and this is what has enabled third parties like Silicon Publishing to create tools appropriate to the range of situations commonly encountered in the real world of data-generated page composition. With Silicon Paginator, we help designers create their templates, (including page geometry and style catalogs), and then we show them how to bind data to page objects and text flows.
Abstracting the Document Object Model
When InDesign Server came out in 2005, I would have died happily: at that point in time we had attained what we’d set out to do. We had turned InDesign into a composition engine facilitating the highest-quality database publishing workflows possible, and with the server form of the product, it even had decent throughput. What, if anything, was left?
Demand from clients told us very clearly what was left. InDesign “server” demanded a web client of some sort. From the day InDesign Server came out, we were inundated with requests for online editing solutions. These fell into two categories: easy and hard.
The easy online editing solution: form-based
Doing something of great value regarding online editing was actually a trivial challenge. We would create a form on the web, let the user enter data into it, and post the form to the server, updating the text and images of an InDesign template. InDesign Server was a great tool for this in terms of quality, though back in the day you might have had to wait a while for a response. That is no longer the case.
The holy grail: on-canvas WYSIWYG editing
The form-based solutions made us yawn, but we implemented them over and over, and we taught people how to implement them over and over. The real challenge that hypnotized us was found in the interwoven complexities of the on-canvas forms of editing. “Can I select text on the document itself and edit it? Can I select a word and make it bold? Can I drag and scale the image inside its clipping path?” There is always something sexy about online editing, but it wasn’t easy to implement back then.
HTML as of 2005 was slightly too crude (the spec was imperfect: browser implementations disastrous) to serve as a decent editor, but there was this emerging technology, Flash, which offered fairly sophisticated typographical features, once Adobe had taken the product over from Macromedia. We dove in, and in 2006 produced a quite decent editor, which we made fully functional soonafter Adobe put the Text Layout Framework into Flex.
A renderer-agnostic document model
Key to our success was the approach we took. We created our own document model that was essentially a superset of the InDesign model. It included a document description similar to that of InDesign (something like IDML, which didn’t exist yet), but we extended it in crucial ways. Initially, it included information useful for rendering and editing in Flash, and HTML5 became an ever-more obvious option Parenthetically, let me emphasize that we never loved Flash: (see “The Fall and Rise of SVG” to understand that we were doing standards a decade before Steve Jobs pretended to embrace them for one single day of his entire life in April 2010). We turned to Flash as a last resort at a time when Microsoft, Apple and others were turning a squinted, hostile eye towards standards.
We created this document description called SDXML, which didn’t specify Flash, InDesign, Scene7, Illustrator or HTML5 (we’ve supported these 5 to date). It described the document, in a way that could be read or written from different engines. This is the basis of our Silicon Designer product, which powers many large-scale online editing applications, and is finally available in multiple SaaS (Software as a Service) flavors, lowering the cost of entry.
The simplest interface from the most complex work
And after all of this highly technical work involving 10+ expert developers around the globe over 8 years, the result is… a very simple thing. By abstracting out the document model from the specific editing interfaces and rendition engines, and leveraging templates to encapsulate the design intent of quality designers, we now have a product, Silicon Designer, that can let the most non-design-savvy people on earth (even me) create very high-quality documents.
The latest SaaS-based deployment of Silicon Designer is a case in point: Brandfolder Templating. The following video shows what can be accomplished through the help of document model abstraction.