The Flight InDesign Plugin that we developed a year ago is getting renewed attention recently, including an update for 2017 and new, easier, installers. I spoke at the Canto DAM Summit last week, and in preparation I explored a new cool feature that we’re slating for the next release, made possible thanks to the gradual evolution of Adobe CC Extension technology. Related to that is a better way of expressing the value of our core Silicon Connector technology, which can be seen by looking in a bit more detail at the other, bad alternatives to it. Below is my presentation from the Canto DAM Summit Americas 2017.
Seven years ago, Silicon Publishing stumbled into an opportunity to connect Adobe InDesign to remote assets in a very powerful and efficient way. Through the work of our developers, several of whom were part of the original team that built InDesign, we were able to make a very direct connection from InDesign to remote assets via URLs. InDesign DAM Connectivity has become a significant part of our work.
While other approaches rely on technologies such as WebDAV, which is known for latency and headaches, our direct approach has proven itself to be far more efficient, and is now the way that most leading DAMs handle such connectivity. We have over 20 DAM partnerships so far, with more on the way.
This post talks about 10 of the Connectors we’ve built, specifically those with partners who also have booths at the upcoming DAM NY 2017 conference. They are in chronological order, and nothing here is intended to say that one is better than another, but simply to talk about the unique characteristics of each as we’ve seen them in the context of connectivity from the Creative Cloud applications.
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.
Historically, Silicon Publishing has delivered publishing solutions across a gamut of communications channels. In the first place, our Silicon Paginator product (first released in 2005 as the “XML Formatting Engine”), is a platform for flowing data through InDesign templates. As in traditional XML publishing, Paginator generates web, email, print and mobile app output from a single rendition-agnostic content source (or from diverse, orchestrated, content sources).
Multi-channel rendition, connectivity and interfacing are persistent themes in our practice, ever since the late 1990s when “multi-channel” became a buzzword to deer-in-the-headlights printers faced with the need to generalize into “communications” from the too-physical, too-easily-commoditized, craft of print.
I remember a channel called “CD-ROM” and now face channels such as “WebVR”, “IoT”, and “geolocated social” – the only constant is change.
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.
For 16 years 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.