Alissa Whitney and I have been building online publishing solutions since the 1990s (and since the year 2000 as Silicon Publishing). But it wasn’t until 2009 that we (along with Aaron Hodges, who had recently joined us and immediately lobbied for “a real software product”) coined the name “Silicon Designer” and decided that our solution was actually worthy of being sold as just such a software product. We could feel the web (an increasingly mobile web, as the iPhone was then taking the world by storm) tugging at desktop applications: it was becoming a powerful place for users to create first-class documents and graphics.

In the fall of 2009, Aaron and I bravely headed to the “Print 09” conference in Chicago, investing in a press release announcing our fledgling product to the world. Thus began the growth of Silicon Designer, which has since taken on a life of its own, generating billions of documents for millions of end-users. Today it is fielded by some of the leading brands on the planet.

Web-to-Print Missing Link

“Web-to-Print Missing Link Revealed in Chicago” – the initial Silicon Designer press release in 2009 led to great things.

Our dream eventually came true: as of 2021, people are now editing online much more frequently, using tiny devices that we could barely dream of back then. More users than ever before are using today’s Silicon Designer.

We have come a long way, yet the constant advance of mobile and graphics technology still points to an uncharted future. Let’s consider how we got here, and where things may be heading.

The necessary challenge of 2009: client-side editing

The evolution of our online editor is a bit peculiar, because it actually started with the most challenging technical approach, and then worked its way towards simplicity. This is because, as of 2009, composition servers performed very poorly. But thanks to Moore’s law, that is no longer the case.

The chasm between web and print

Why would you need or event want a “composition server?” Well, you certainly might not if you were just making a simple raster image intended for viewing on a screen. But in the higher end of online editing, where the focus is on creating documents that print well, it becomes quite a fine art. It is amazing how print and web graphics have been so poorly reconciled by standards bodies and proprietary companies. But to this day, you either get one, or you get the other.

Have you ever printed a web page? That is where you notice the chasm between the “print” mindset and the “web” mindset. To this day, desktop tools like Adobe InDesign offer rendition capability far superior to the direct output of web browsers and mobile applications. I have sat with the CSS working group, and the browser teams from Apple, Google, and Mozilla. I have met the InDesign and Illustrator teams at Adobe. It is absolutely stunning how the web and print paradigms manage to be so different.

Web and Print are different worlds

Web and Print are different worlds

The reason that we base Silicon Designer on Adobe InDesign Server (IDS) is because of the superior print quality, and the perfect interoperability with the preferred formats in print, including EPS, .SD, .AI, and PDF job options. Someday this may change, but when Adobe released InDesign Server in 2005, suddenly there was no longer an excuse for substandard print documents coming from the web. It is true that some still bend over backwards in their attempt to produce nearly comparable print output using alternative approaches; but more often than not, such approaches fail. With InDesign Server, we have always delivered perfect output quality.

Wait for it…

Yet back in the day, the greater challenge was server speed. In 2007, I attended the Adobe MAX conference in Chicago, where they unveiled their first “Web to Print” prototype – the “Dandelion” project – in a technology sneak peak. I was extremely excited: after all, this is what we had been prototyping, ever since IDS was first released. We even had a successful editing solution deployed. Surely Adobe could do better?

They demonstrated editing a menu via a Flash interface (Adobe had purchased Macromedia, the creator of Flash, a year earlier), and, upon entering the prices and choosing an image, the user hit a button, in anticipation of a proof. An hourglass spun on the screen…

Early InDesign Server was slow.

Early InDesign Server was slow.

Those five seconds of watching the hourglass spin were painful to watch. It was also obvious that they were not doing anything magical, but were simply passing a bunch of information to InDesign Server, and letting it take its own sweet time rendering the page.

“Form-based” vs. “WYSIWYG on-canvas” editing

Hour-glassing the user has never been our approach. No user wants to wait five seconds to see a preview.

The underlying approach of that failed demo was known as “form-based” editing. In the form-based world, users entered information (such as the pizza’s price and description) into a form and submitted this information to InDesign Server. IDS then updated an InDesign document with the fresh data, exported an image, and after a short wait, returned everything back to the web browser.

Form-based vs. WYSIWYG

Form-based vs. WYSIWYG

What we had done, instead, was  known as “WYSIWYG on-canvas” editing. We put the entire experience of editing directly inside the web browser. No forms were submitted, and no server was called. Users simply worked with text directly on the web page, just as you would in InDesign itself, with realtime updates to the content being immediately visible.

Crossing the chasm

This was not something we had done casually: it had taken years of engineering to get it just right.

Think about the challenge: the Flash text engine was not the same as the InDesign text engine. The graphic models were not the same, either. We coded intensely to “round trip” between the two, so we could load an InDesign document into Flash, make edits to it, and save it back to InDesign on the server.

Doing this meant that we had to painstakingly map the Flash graphic format to the InDesign graphic format. Although it wasn’t entirely perfect, we had worked tirelessly to figure this out, so that the users of Silicon Designer did not have to wait for some background process every time they made an edit. Instead, they edited on the screen directly, and the results were instantaneous.

Yes, we used InDesign Server for print output when editing was done. This was because direct output from Flash was not only sub-standard in quality, but violated the license agreement. But IDS output was either asynchronous (done in the background, rendering a preview that was ready after a short wait) or entirely after the fact. In other words, we rendered the finished output only after the user had finalized their edits, later running the print job overnight.

SDXML bridges web and print

Our document model, SDXML, can render to, and receive edits from, both web and print technologies.

The abstract document model

We accomplished this by means of an abstract document model that we called “SDXML”. It was an innovative graphic format that defined the document for expression in either in Flash or InDesign. An InDesign document would be distilled into SDXML, which was then rendered and edited in Flash. The user would make edits, which updated the SDXML, and these would then render as needed with InDesign Server.

Here is the demo we brought to Print 09:


This approach worked great! Our press release was well-received, and soon we had more clients than ever. As of early 2010, Designer looked to be taking over the world. We weren’t the only ones doing this, of course. Others had either arrived at the same approach, or were scrambling to copy us with this or somewhat similar methods.

2010: the death of Flash and the birth of the mobile web

Did someone say 2010? Well, success is rarely instant or easy. We had built our solution in Flash, because as of 2005, Flash had the capability to make a robust web applications, a.k.a. “rich Internet applications”. Meanwhile, web standards had languished. We hadn’t adopted Flash in defiance of standards; rather, we had labored long and hard over SVG, XSL-FO, and other “open” approaches. But in the early 2000s, Microsoft and other browser vendors did a great job of quelling standards and impeding Open Source. Internet Explorer 6, at the time, was the most popular browser for desktops. This contrasted with Adobe’s experimental “SVG Viewer” that had to be installed by rare geeks like myself who dabbled in such fringe technologies. (SVG would eventually take its revenge).

Steve Jobs slays the upstart technology

On April 29, 2010, Steve Jobs penned his “Thoughts on Flash” which made it quite clear that Flash would not be on Apple phones or mobile devices. So there we were, a 20-person company devoted to the hottest Flash application on the planet: thanks, Steve! Where was your love of standards when you built the $85 power supplies? Standards showed up in Steve’s life when he saw a proprietary virtual machine threaten his walled garden. But that’s a story for another time.

He was right, of course: Flash had its issues, and we SVG geeks had opposed it for a good reason. It was also a good thing for the W3C to dig itself out of its foggy stupor, and focus on the needs of the web. HTML5 rose to the occasion relatively quickly. Within a few years, developers had gained a powerful way to code web applications, and it was finally standards-based.

The amazing overlap of web standards

Yet this new reality was a huge challenge to those of us building online editing applications. HTML5 encompassed several overlapping technologies. There was Canvas, CSS, and SVG, which often represented different approaches to the same goal. One example is that a given piece of text could render identically, using any of these techniques. We saw people focus on a single approach, often to their peril. A pure SVG editor would not have the text power of CSS, while a pure Canvas-based editor suffered with text editing and vector art. On the other hand, pure CSS was just plain challenging. It didn’t cover all graphic capability, yet it clearly enabled an optimal text editing experience.

We eventually figured out a hybrid approach, after taking each possibility to its extreme. The end result was an editor that rivaled anything previously done in Flash. SDXML offered quite a head start towards this goal. It had never said “InDesign” or “Flash” (we had prototyped rendition in four or five other flavors). After some fine-tuning, it was ready to emit and ingest HTML5.

The Return of the Server

Ironically, in the 10 years we spent perfecting pure client-side editing with HTML5, server-side composition with InDesign Server was slowly but surely offering a far better user experience. We had continued to build that imperfect flavor of online editing, without productizing it, but simply to meet client demand. As the world’s largest reseller of Adobe InDesign Server, we were called upon to help deliver such solutions over and over. We did this, even though they were not particularly exciting. What the “form-based” approach lacked in terms of user experience, it made up for in ease of development. A total beginner could built such a solution, which was easier to deploy and maintain, as well.

Around 2015, we noticed that form-based was becoming surprisingly fast. “Is that cacheing?” we wondered, as we encountered the improving response times of applications running on newer, maxed-out servers.

InDesign Server is now Fast.

InDesign Server is now Fast.

Pure client-side editing provides an incredible user experience, as there is zero latency, but it comes with overhead. WYSIWYG solutions require rigorous font management, including the licensing of client-side fonts, and often depend upon a proxy image workflow. For example; referencing a native .AI file in the InDesign template, but manipulating a parallel SVG file on the web. Companies with a design department didn’t have trouble with such details, but it was impractical for many smaller organizations.

The best of both worlds: a platform for the future

In 2017, Adobe approached us with surprising news. The Scene7 Web-to-Print platform was slated for extinction, and they asked if we were game to replace it with an InDesign Server-based product. We accepted this challenge, and soon found ourselves immersed in the long-avoided universe of form-based rendition. Scene7 Web to Print was a relatively unknown server-based rendition platform that rendered high-quality images and PDFs from web requests. It had enjoyed a period of love from Adobe management following its year of inception. But soon afterwards, it quickly faded as other cloud-based acquisitions took priority over Scene7.

The main thing you need to know about S7 web to print (yes, it is extinct now, and we did effectively replace it) is that it rendered previews from requests really really fast. Faster, even, than InDesign Server as of 2017 (which was certainly offering decent speed for the time).

We had our work cut out for us. We put huge engineering effort into optimizing IDS response time. This was something we really hadn’t considered to be imperative. Our product had been WYSIWYG to avoid fighting such an uphill battle. Between our efforts, and the continued advances in server speed, we attained response times & throughput that would have been unimaginable 12 years earlier. Maybe that Chicago MAX demo was actually a peak into the future?

Hybrid and pure approaches to editing

When 2019 came to a close and our clients were live on the new platform, we had two very different products on our hands. These were Silicon Designer, our WYSIWYG offering, and the new, form-based, “Silicon Designer for Web to Print,” which offered unparalleled InDesign Server response times. Yet we considered this division a temporary situation. With so much in common between the products (such as scaling and managing InDesign Server, managing jobs, logging, etc…) it was clear that we had been architecting for their inevitable unification from the very beginning.

2020 was a year of assimilation and integration, as well rest, since the effort had been absolutely exhausting. In its 2021 iteration, “Silicon Designer” now represents a synthesis of the WYSIWYG and form-based approaches. It is available in three different flavors:

  • Pure WYSIWYG, in which all edits appear in real-time on the canvas,
  • Purely form-based, with image updates from the server providing the sole source of preview graphics, and
  • Hybrid implementations that integrate WYSIWYG and form-based approaches into a unified user experience.

You might be surprised

You might think that a hybrid approach would just permeate online editing, like the “synthesis” evolutionary victory over a thesis and its antithesis. But in reality there are legitimate use cases for all three approaches. Moving forward, we intend to keep the Silicon Designer platform flexible, in order to accommodate the broadest range of client needs.

To understand this, consider the way a hybrid solution can come about, starting from a form-based or WYSIWYG base:

  • A form-based application might be perfect in terms of text entry. Because selecting text on a document preview can actually be more challenging than entry through a form, the independence of text from formatting might actually offer the user experience of choice. Meanwhile, uploaded images, for example, might really benefit from being cropped and scaled in the context of the document. This is not only a valuable editing feature, it’s one that doesn’t require anything special in the way of font licensing or management. This is the sort of “mild hybrid” that is likely to hit the sweet spot of many less-complex solutions.
  • A WYSIWYG application could benefit from a set of design functionality that can’t be mapped perfectly between InDesign and HTML5. One example is InDesign’s subtle and amazing “text on a path.” Even if we could perfectly map InDesign’s text on a path between HTML5 and InDesign Server, those who have edited text on a path in InDesign will immediately recognize form-based entry as the superior interface. With a near-instant server response, this adds powerful imaging to the WYSIWYG experience.

The future is what you make it.

At this point in time, Silicon Designer is more extensible than at any point in its history. It provides the highest-quality graphic and document output attainable, interoperating with both standards-based and Adobe proprietary formats. Additionally, Designer’s user interface is fully open to customization. The application is completely abstracted from the user experience. To our knowledge, no other design tool is even 1% as flexible.

Designer is deployable at any scale, and with any level of concurrent usage/document throughput. The limitations exist only in the imaginations of those deploying solutions built on top of it. Silicon Designer is a malleable and powerful tool, yet it requires vision. It succeeds proportionally to the creativity of those who use it.

After 15 years of development, Designer is, in our estimation, ready to market:


This post is a bit technical, and dwells on our product and its history. But I wanted to provide some meaningful background before we embark on marketing this relatively obscure product. We are just beginning to promote Designer enthusiastically. I think that we have finally lived up to the 2009 press release, after rolling with the punches of mobile, HTML5, responsiveness, AI, WebGL, Web Components, etc. As everyone knows, technology isn’t exactly sitting still, but we are no longer seeing the level of disruption experienced after the initial launch.

How should we market Silicon Designer? We’d love your feedback, and of course if you’re interested in the product, let us know.


Share This