In this post I am going to explain how Silicon Designer is built to support the most demanding online editing solutions in the world. We are at a point in the evolution of this product that I am truly proud of, and I am deeply grateful to our incredibly talented developers and other participants in its success. Go here for some history of how it came about: in this post we will talk about what it is and how it works.
What it is: an end-to-end, completely customizable, online editing solution
Silicon Designer is a highly customizable, end-to-end solution for editing documents online. If you make a business card at Printing.com, or many other sites, you are using Silicon Designer. Here is a brief explanation of the product:
No two Silicon Designers look the same
This is by design. The intent is to facilitate the entire spectrum of editing experiences, across the entire spectrum of document types.
As far as user interfaces, we have clients who want constrained or form-based editing at one extreme, and clients who want “InDesign on the Web” at the other. Our core process doesn’t care: user interface is neatly abstracted to be something that we can easily change quite radically. We don’t tell our clients what to do, generally, but instead we let them define the UI they want, then configure the product to support it. You can look at this blog post to see some of the spectrum of UI demands we encounter, and the considerations that go into choosing the type of interface you want for your end users.
We are going to support all document types
No, we’re not there yet, and it will be years. “All” is kind of a high bar to aim at, but the point is that our document model is extremely generic and all-purpose at its core.
We have supported more than 1,000 document types, from greeting cards to door hangers to dimensional products (with 3D interactive preview) to ads to large format signage to brochures to newsletters to school handbooks to insurance documents to book covers to mail merges to variable data campaigns to… you can almost name it.
It is interesting to me that HTML5 is both a curse and a blessing in terms of this product. Flash had some wonderful features related to text, but they were truly abandoned by Adobe when they gave up on Flash, and old-school HTML had always been better than Flash in terms of tables, lists, and several other long document features. We pulled code from our early 2000s HTML editors and are now using HTML5 to provide the same sort of long document features, this time with the pixel-perfect, pagination-perfect rendition that has only recently become possible.
At the moment our sweet spot is business collateral and consumer personalization. In terms of technical documents, books, and complex variable data, we have the fundamentals and can customize for nearly anything. The final frontier is really interactive content, a wonderfully changing game as devices proliferate and standards evolve.
We are going to support all device types
We did not embrace Flash originally without resistance. In fact, we worked with SVG to the exclusion of Flash for years (I tech edited SVG Unleashed in 2002 and I have been owner of the SVG Developers group for many years), until the writing was on the wall that no browser vendor would support SVG quickly (surprisingly, even “standards-loving” Apple did not rush to the challenge). At the point in 2006 where Flash had relative ubiquity and was showing signs of developing advanced typography (with the Adobe acquisition) we accepted that Flash was a legitimate tool. The first Silicon Designers were all Flash-based.
After a painstaking rewrite of our code in the “write-once, debug-everywhere” world of HTML5, we miss the convenience of Flash but we do not miss its limitations. HTML5 is finally fulfilling its promise as devices, browsers, and standards have made true progress. Perhaps it is the simple absence of a dictator like Steve Jobs or Bill Gates pushing proprietary approaches to ridiculous levels, but we finally see standards-based codes working more places than it doesn’t work. Designer is expanding across legacy platforms like IE 11 while it extends to support new browser features like Open Type fonts, CSS Exclusions, and WebGL.
How it works: by means of a rendition engine-agnostic document model
The functionality of Silicon Designer is to “round-trip” a document, meaning it starts in InDesign, it turns into a web document, which (after edits) then turns back into an InDesign Document (using InDesign Server). Back in the early 2000s, we defined an XML structure to support online editing, which described a document sufficiently to enable an editing experience on the web. We wrote code to interrogate a document set up in InDesign and emit this XML. Our web application would then ingest this XML, render the document on the web where users could edit the content, and save the results of their editing (again in this same XML structure) back to the server. The second piece of InDesign code would load the original InDesign document, and make changes based on the XML that had come from the editing experience.
The other thing we had to do was manage the different sorts of image required by web vs. print. In the same process that emits XML from InDesign, we also generated “proxy images”: low-resolution images appropriate to a web site. We retained the original high resolution versions for final print output.
While our process has not changed much, the XML structure has been growing and growing in complexity over time, getting more and more comprehensive in terms of document features. We were minimalistic in our initial approach, using the InDesign document as something of a crutch. We really only need XML for those things that would be edited: the rest could be left in InDesign, since the server would re-load that and change the images or text the user had altered. After years of enhancing the model, we reached the point where today, the entire back-end composition process no longer needs an InDesign document. It does create a new one, but it does so entirely from the XML and referenced images.
This actually came as a surprise to me: I was telling a client that we had to have the InDesign files on the server, and my colleague Ole informed me, “no, not anymore.” It pays to hire people smarter than yourself.
The importance of being SDXML
Around the time our document structure reached industrial quality, it got a name. In 2010 we named our XML “SDXML” as in “Silicon Designer XML” and it helps immensely in describing how this works. There are other XML models for documents, and we probably know all of them at least a little bit. InDesign used to have INX, then it got IDML, which happens to have been invented in large part by our staff that were then at Adobe. There is tremendous confusion about IDML and its use: a naïve programmer will think that IDML is a good model to use for web-t0-print solutions. No, it is not. SDXML is far different.
In the first place, we need to support metadata at different levels (on page objects, on text ranges, on the document itself) related to how things are edited. So there is more to it than just the rendition of the document in a design sense. But as much as we love InDesign, we are not InDesign-centric in our approach to this. SDXML is about describing a document in a way that allows multiple rendition engines to render it, and we have flowed SDXML into five different engines so far (InDesign, Illustrator, Scene7, Flash, and HTML5). SDXML is rendition engine-agnostic. It does not care what renders it.
The three worlds of a web-to-print solution
There are three main parts of a Silicon Designer implementation:
Content authoring, where designers create templates for the documents that will be edited
The runtime environment, the deployed web site where users edit documents based on templates
The composition process, which may or may not be tightly coupled with the runtime
As you can see below, SDXML is critical to all three:
In the authoring phase, designers use what we call our “Template Editor”, which is a plugin to Adobe InDesign, to apply metadata to InDesign templates. Like the web front end, the template editor is built to be very different for very different clients. It is a single codebase for all, but it is highly configurable. On loading the InDesign document, the Template Editor inspects the objects in the document and lists them out, providing an interface through which any metadata can be applied to any object.
Markup can indicate almost anything required for a document editing experience: the only universal element that needs to be defined for pretty much everyone is which objects are editable. Beyond that, you can indicate almost anything you could dream of: should this field be edited with a date-picker control? Should this object be something that can be moved, scaled, rotated, colorized? Which image gallery might be applicable to a photo? What is the color palette and font list for the document? What form of copy fit logic would apply to a particular text frame? It lets users define variables, which can be vector or raster images, entire text frames, or ranges of inline text. We have had a large range of use cases that have made the Template Editor extremely flexible, yet we turn off those features not needed with configuration and preferences, so it looks different for different customers.
When the designer is done defining how the template will behave in the web experience, they choose “package” from the callout menu of the Template Editor panel, and the magic happens… Our code generates SDXML reflecting all of their changes, while creating proxy images used for web links. This is all zipped up and uploaded to the web server, where the template becomes available for online editing.
The runtime environment is where the user does the editing, through an interface that we customize for each client (like the Template Editor, this is done in a layer quite independent of the core code base, which is now common for all clients).
The runtime itself has three components: the front end (which is Flash-based for old browsers and HTML5-based for new ones); the services layer; and the back end where SDXML is stored and which may be used for server-based rendition (i.e., for page or document thumbnails).
As you can see, SDXML is critical to this process. Most of the service calls are loading or saving SDXML. As the editing is all in real-time on the client, there is not an absolute need to have any composition calls at all, yet some users either want thumbnails to be generated on the server or to provide the high resolution print output in real time.
When the user has completed the editing session and is ready to purchase what they’ve designed, there is a back-end composition process. The SDXML reflecting their document will be loaded in InDesign Server and rendered: metadata in the SDXML may also define production processes such as binding, stock selection, die cutting, or spot color. The composition process is typically 100% automated.
We are happy to have created this product and we look forward to continuing its evolution. As I said elsewhere, it grew organically, it was not created the way startups are creating software products these days. Instead, it came after years and years of building similar solutions over and over. Now that we have attained the level of quality we were aiming at, we intend to spend more time sharing with the community what we have learned from this experience. It was certainly the wonderful programming community that made this possible, and we are very thankful to the cool people who automate InDesign around the world, and those who moved web standards forward (eventually) to open up the HTML5 frontiers now before us.
The world leader in automating web-to-print and multichannel publishing with Adobe InDesign, we deliver best-in-class solutions for some of the world’s top brands including Nike, Google, Amazon, Hallmark, Adobe, and Disney.
100 Pine St. Suite 1250
San Francisco, CA 94111
Join Our Newsletter
Stay up-to-date on our products and evolving technologies in our fast-moving industry.