A History of Scene7 Web-to-Print
Nine years ago I got a call from Adobe, asking if we could help build a brand new product for them, for a division that was being created out of a company they had just acquired, Scene7. While not entirely unfamiliar to us — we had worked on the periphery of several Scene7 implementations —this began our immersion in the technology, and it has never quite stopped.
We have watched the Scene7 technology reposition itself in concert with other Adobe technologies over the past nine years, and working with a spectrum of Adobe Scene7 technical and business people during that time, we have gained kind of a unique perspective on the core Scene7 product, as well as the Web-to-Print feature set that only came about post-Adobe acquisition. Here I will do my best to describe the pre-Adobe history, then lay out the history from the Web-to-Print perspective from 2007 to the present.
The pre-Adobe History
While Adobe was perhaps the leading graphics technology player when the web was born, it took them quite some time to understand what a server was, and to appreciate the value of server-based imaging that Scene7 came to be so good at providing, and which ultimately made Scene7 such a natural acquisition.
The Scene7 tree has several roots:
- Picture This Home, a spinoff from Autodesk in the mid 1990s, eventually sold to Brøderbund (which changed the name to GoodHome.com in 1999), brought the pseudo-3D (“two and a half D”, as S7 reps would call it) visualization of how your kitchen would look if you changed the type of counter top. Scene7 was born in 2001 out of the ashes of GoodHome.com, when that ill-fated dot com was forced to restructure and re-brand, expanding in vision beyond decorators and furniture companies.
- In 2002, Scene7 acquired the “Image Pump” technology and key personnel from Xippix, another image-serving competitor from the late 90s/early 2000s.
- In 2003, Scene7 acquired the assets of Engage, a workflow and prepress company that was facing Chapter 11.
- Also in 2003, Scene7 bought one of their major competitors at image-serving, True Spectra.
With these acquisitions, Scene7 emerged as the leader in “image serving” (which had been around quite a long time), and which became especially meaningful with the advent and evolution of the web.
“When preparing and deploying a large number of images to the Web, companies are facing problems such as the bandwidth/image quality dilemma, image resizing, and the need to conform to the image display capabilities of disparate viewing devices. These difficulties are being addressed by image servers,”
— Lia Schubert, research analyst, InfoTrends Research Group, 2002
The Scene7 product matured into a powerful combination of the technologies they had built and acquired, with the fundamental workflow for image serving (in which just the right pixels were quickly served up from a high-resolution “PTIF” — Pyramid Tiff — image) fed whatever was needed for the web page or device, combined with the “fabric on the sofa” visualization feature that had evolved out of the original GoodHome.com technology.
In the mid 2000s, Scene7 began to move from a model in which they sold servers to their clients (who in turn used these to serve up images) to a hosted, SaaS model. It certainly didn’t happen overnight: I remember that even after the Adobe acquisition, there were still clients running their own servers with Scene7 software. The software ran on Windows and Linux and was Java-based. The hosted form of Scene7 represented a natural culmination of the technology, which seemed like a natural progression for Adobe.
The Challenge of Print and Vectors
While certainly there was plenty of vector information under the hood, until Scene7 was acquired by Adobe in 2007, Scene7 servers had only served up raster images. This is because they were primarily targeting the Web, and while their tools were capable of high-resolution raster output that could be printed fairly decently, the high-quality print output for which vector graphics make so much sense was not relevant to the vast majority of Scene7 use cases.
As of 2007, Adobe was just becoming interested in server-based technology. This had been one of my frustrations during the previous decade, having wanted a Photoshop Server since 1997. By 2000 I was begging, literally, for an InDesign Server. With their acquisition of Macromedia they had certainly made advances, for example finding themselves the proud owners of Cold Fusion through Macromedia’s earlier acquisition of Allaire. The InDesign group had eventually released a server product in 2005, yet it was far more InDesign than it was Server.
The Enlightened Acquisition
Some companies like EFI acquire companies to pillage their clients and let them rot. Adobe is far more enlightened, perhaps to a fault. When Adobe bought Macromedia, they elevated key Macromedia people to very high roles in the company (after all, Flash was going to take over the world). Similarly, with Scene7, when they first arrived they enjoyed the utmost respect and encouragement from their new owner.
As of 2007 Adobe had finally given us an InDesign Server, and had started to build an experimental Web-to-Print platform on top of it, code-named Dandelion. Because this represented server-based imaging, Dandelion was given to the Scene7 Sales Reps to manage. I bore witness to a bizarre collision of these two opposite perspectives on server-based rendition, coupled with diametrically different sales cultures.
InDesign Server was essentially the InDesign desktop product without a UI, with a slow response time and very little “server” functionality; although it could be invoked with SOAP or CORBA, that was about the only additional work beyond Model/UI separation done to it. It was met with ridicule by the Scene7 Engineering staff, who were immersed in the server side of imaging. The lack of speed was unforgivable, and the required layers of customization to approach the ease-of-use of Scene7 made it look old and clunky, from one angle.
From the other perspective, if you were seriously going to print something, raster imaging is rarely ideal. There are some use cases where it can work, and of course ultimately there is a final raster stage in print, but the print coming out of InDesign was superior to anything Scene7 could produce.
With the blessing of Adobe leadership at the time, Scene7 was given the chance to build their own alternative to InDesign Server. It didn’t hurt that “disruption” had probably reached its all-time peak as a buzzword around that year: when someone would question the value of Adobe competing with itself, the answer was a smug “sometimes we’re a little disruptive…”
Let the Plurality Begin
Our small company had established itself as an InDesign Server reseller, and we had built solutions with IDS that were already quite successful, but we were intrigued and excited at Scene7 itself (it was the closest we had seen yet to a Photoshop Server coming from Adobe), and very curious how this new energetic group would take on the challenge of PDF output.
I was grateful to witness the birth of this technology firsthand. We happened to be one of the few companies with a development agreement with Adobe, and they had us work on various pieces of this new form of Scene7, called “Template Publishing” or “Web-to-Print.” I am sure they chose us because we were one of the few companies on the list, at that time we were far less capable than we are now.
The engineers at Scene7 were brilliant, and having Adobe core tech at their disposal, they were like kids in a candy store. We saw it get better and better every week, and the speed and quality of PDF output was stunning. We started to build solutions on top of it, and when our Silicon Designer product was first announced, we offered both an InDesign Server version and a Scene7 Web-to-Print version. We were part of some very comical decision-making processes, in which our clients would choose between IDS and S7 with us awkwardly in the middle, trying to be like Switzerland in World War II.
When Scene7 Web-to-Print was released, it was clear that the range of document types it could cover was limited. While with InDesign, we could do “state-based” composition, where we flow text, see where it flows, and adapt accordingly, the approach Scene7 took had a much more rigid template concept: it initially had no copy fit or text flow across pages. Great for a business card or a greeting card, not so great for longer documents.
Beyond this limitation, Scene7 had not gone much further than the InDesign Server group had gone in making it easy to build a solution on the technology. There was a basic sample app, yet Web-to-Print use cases in the real world typically went miles beyond that. As with IDS, a solution layered on top of it was required, and this made a Scene7 Web-to-Print sale more involved, more complex, and riskier than a generic Scene7 imaging sale, as the base imaging was far simpler to deploy.
The Glory Days
The complex solutions required of Scene7 Web-to-Print were precisely the specialty of our company, Silicon Publishing. On its initial release, Scene7 Web-to-Print got huge interest, from both the large retail base of traditional Scene7 clients, and the Adobe client base that was starting to learn of Scene7. Scene7 Web-to-Print actually enjoyed a greater marketing/promotion effort than InDesign Server had ever experienced.
We consulted extensively in building and customizing applications built on this new platform, and some cases were home runs. It depended on how closely the goals of the client matched the natural sweet spot of the technology: relatively simple variable data, or online editing applications with documents that had minimal “flow.” WindsorVineyards.com, live to this day, is an example of Scene7 Web-to-Print at its best: users personalize wine labels online through a simple interface, and the output is beautiful. Previews are fast, with excellent print quality. Nearly as good as the wine.
We worked with Adobe to extend the platform to handle longer documents, and we improved the sample app and documentation to make it easier for clients to customize solutions themselves. It felt like this technology could go somewhere, but at some point the momentum slowed.
The Achilles’ Heel: FXG
The foundation of Scene7 Web-to-Print success ultimately turned out to be its undoing. While there were certainly challenges building a solution on top of it, at a fundamental level, the way this product had been built turned out to prevent its evolution.
The Scene7 group had pulled liberally from the Adobe technologies of the time: Illustrator, Acrobat, “Core Tech” (common code shared among Adobe applications), and even… Adobe Flash. Scene7 Web-to-Print depended on a standard called FXG, or “Flash XML Graphics” and this standard was at the heart of how Scene7 Web to Print worked.
By manipulating FXG and sending it to the server, you could dynamically create almost any sort of print-ready document. In one sense it was beautiful, though it was limited in terms of pagination and efficient use of whitespace, as it lacked the “state-based” functionality we were used to with InDesign Server. Still, we built several solutions on top of Scene7 Web-to-Print, some of which are churning out documents to this day. Had Flash taken over the world, as many expected in 2007, perhaps this foundation would have propelled Scene7 Web-to-Print to ubiquity. It was in many ways the server equivalent of Flash. New Flash features such as the Text Layout Framework could be used on both the client and the server.
There came a time when we felt the Scene7 Web-to-Print momentum dissipate, and it really paralleled the demise of Flash: with the death of Flash becoming more and more obvious each month, one had to question whether Adobe should continue to invest in FXG.
Adobe had two major acquisitions as well; Omniture in 2009 and Day Software in 2010, so even the core Scene7 product found itself out of “wonder boy” status and on to “what can you integrate with?” (and in what context). The daunting number of Adobe products left Scene7 Web-to-Print very obscure. It was something Adobe offered, but it became less and less prominent among their offerings.
InDesign Comes of Server, as S7 Web-to-Print Fades
In the years since 2007, pure server speed has increased exponentially, and with multi-core servers and the friendly “all you can eat” multi-instance InDesign Server license, whatever speed difference there had been between Scene7 Web-to-Print and InDesign Server had gone away by 2012. Either one could serve up highest-quality rendition near instantly. InDesign could do so with greater flexibility across a much broader range of document types. And InDesign Server did not have any of the stigma of Flash, which by that time had been abandoned even by Adobe.
Perhaps it had not been so brilliant for Adobe to “disrupt” itself. The greater power of InDesign, combined with the inevitable (for both technologies) significant integration/customization system, made Scene7 Web-to-Print the lesser of the two equals. This at a time when Adobe’s attention was divided across a wider product offering than ever before.
As we saw Adobe pay less and less attention to Scene7 Web-to-Print, we stopped reselling it, and we moved our largest clients off of it and onto InDesign Server. As our Silicon Designer APIs evolved, we made them as easy to use as Scene7 URLs, so at this point in time there is no benefit I can think of that would make Scene7 Web-to-Print a better choice.
Between the lack of recent motion of the Scene7 Web-to-Print product (most of the core imaging seems alive and well in Adobe Experience Manager Assets) and the continued evolution of InDesign Server, it appears Adobe is also considering Scene7 Web-to-Print something to maintain but not advance. While AEM Assets seems to reflect most or all of the core imaging options of Scene7, integrated into the wonderful AEM DAM, we do not see Web-to-Print as an option there. I suspect many of the remaining S7 Web-to-Print implementations will eventually move to an InDesign Server platform for the documents themselves (keeping its core image-serving functionality inside of AEM Assets, which we interface with directly), and we’re happy to help with such migration.
What can be learned from this? It really was not so predictable, and in some ways Adobe simply hit a bad moment in the trajectory of technology. Adobe, as of 2007, did have every reason to believe Flash would take over the world, as they had yet to feel the strong rejection from Apple. Their attempts to get Flash to run on mobile may have actually succeeded, had they enjoyed support from such quarters. They could chalk up the FXG foundation as an accidental choice of technology that ended up not panning out.
Yet from our perspective, Web-to-Print solutions, in their entirety, may simply be greater scope than a “shrink wrap” software company like Adobe should go after. The InDesign Server model, where the last mile of the solution is left to third parties like ourselves or internal development teams, has been very well proven to work, with Adobe doing what they do best: core rendition software. The diversity of use cases, document types, and integration points demand a flexibility and extensibility that happens to have been provided really well with InDesign Server — inherited from brilliant sustained work over many many release cycles of the desktop product. Scene7 Web-to-Print was a beautiful vision and is actually still a very powerful technology, yet the future of Web-to-Print is clearly something else.
With their amazing engineering power and core technologies to manage graphics and documents, Adobe will inevitably provide new ways to render print-quality rendition from servers. I am surprised that we have yet to see InDesign Server as a pure SaaS service from them, so we work on this ourselves. We would certainly welcome non-IDS approaches to rendition, but as of today InDesign Server shines and looks to have surpassed this “disruptive” experiment.