As leading resellers of the product, we are asked time and time again to help people to try Adobe InDesign Server, and how to install the trial or licensed versions of the product. We have distilled simple instructions here for trying the latest version, and installing the licensed version once you're certain you wish to buy it. We love this product and want others to enjoy it.
Silicon Connector is enjoying huge popularity, and as we build out more and more implementations (12 Connectors and counting!) the product is becoming more clearly defined, while the product roadmap is also taking shape. While the main feature of "connecting InDesign to URL-based assets" is itself quite enough of a product to save large authoring groups immense amounts of time, the "nice-to-have" features have taken on a life of their own, and become common to most new implementations. Here I will clarify the ways the product definition is being extended, now and into the future.
I hope to explain:
- What we originally meant by the term "Silicon Connector" and how this was consistently rather poorly explained by us, and in turn how it was often misinterpreted by the world.
- What we mean now by "Silicon Connector". How to understand what this product is, and what it does.
- Where the product and its many variants (AEM Connector, the InDesign Plugin for Flight, the Widen InDesign Plugin, WebDAM CC Connector, etc.) are headed.
In places, this post quotes heavily from the original blog post about Silicon Connector that came out when we first announced this product in 2010. At that point of time we had a narrow perspective on the product. Six years later, it has grown quite organically and evolves in response to feedback from thousands of users worldwide, as it connects InDesign to a diverse and growing array of over 10 Digital Asset Management systems.
Since the year 2000, we at Silicon Publishing have carried on a tradition we first encountered from our former life at Bertelsmann Industry Services (a now defunct company with its own 20-year history): database publishing. We automate the flow of data through templates, producing the entire spectrum of documents that can be generated from data:
- Financial statements
- Insurance documents
- Report cards
- One-to-one marketing pieces
- Practically anything you can think of...
The diversity of "data-generated documents" has surprised me ever since I started working in this business. 20 years ago, we were still producing internal phone directories for companies such as Chevron and Mobile, large organizations that spewed forth paper to communicate information before the web took over.
SVG certainly crashed and burned before it rose like a phoenix from the ashes...
Sometime in 1998, a former co-worker who had gone to work at Adobe came by my office at Bertlesmann to inform me of a brand new technology that she knew would excite me: PGML, or "Precision Graphics Markup Language." This was the Adobe flavor of XML for Vector Graphics. As Jon Warnock put it at the time:
"The PGML proposal solves a growing need for a precise specification that enables members of the Web community to readily and reliably post, control and interact with graphics on the Web."
I fell for it, hook, line and sinker, and ever since that time, I have followed the standards for XML-based vector graphics closely. PGML (mainly from Adobe) and VML (mainly from Microsoft), as well as a few other similar efforts (Web Schematics, Hyper Graphics Markup Language, WebCGM, and DrawML) soon merged into a "real" W3C standard, called Scalable Vector Graphics (SVG). This promised to serve as a format for rendering interactive vector graphics in Web browsers, which at that time (the era of Netscape Navigator 4.7 and Internet Explorer 5) was only possible with Macromedia Flash.
Completely obvious in the year 2000
What made SVG so cool? It could almost be considered "PostScript for the Web," so it certainly made sense for Adobe to sponsor and support it in its infancy: with SVG (as with PostScript), art was primarily described via vectors, a method far more efficient (and more naturally "scalable") than using raster images.