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.
With the CC2015 launch, Adobe finally announced the inevitable, which many of us expected from the moment they acquired Fotolia, and some of us imagined much earlier: Adobe Stock. This has been a very long time in coming, and it completes an initiative from many years ago, one that we have witnessed from the beginning and participated in. There is nothing new about the concept of Adobe Stock, but the technology underpinnings and business model have both gone through some changes.
2005: Adobe Stock Photos is Launched
If you have been around a long time, you may remember the Creative Suite 2 launch, of April 2005. The announcement is not so different:
Adobe Stock Photos is a new service introduced with Adobe Creative Suite 2 software. Offering one- stop shopping from within your favorite Adobe applications, Adobe Stock Photos is an efficient and convenient way for creative professionals to search, try, manage, and buy high-quality, royalty-free stock images. Adobe Stock Photos provides access to over 230,000 photos and illustrations from some of the world’s leading stock image libraries including Photodisc® by Getty Images, Comstock Images® by Jupitermedia®, Digital Vision®, imageshopTM royalty free by zefaimagesTM, and amana®.
Silicon Publishing was out in force at PePcon 2015 in Philadelphia, and as usual it was a true joy to meet pretty much all of the brilliant and talented InDesign developers from around the world: Gabe Harbs (In-Tools) came from Israel, Kris Coppieters (Rorohiko) represented New Zealand, Ferdinand Schwoerer (Movemen) from Germany; our own Olav Kvern joined us from Seattle, and three Adobe InDesign engineers travelled all the way from Noida, India. It seemed that all of the serious InDesign-related companies were represented: MEI, Typefi, Teacup Software, you name it. The cool thing about the InDesign ecosystem is that knowledge is shared freely among InDesign developers, without competitiveness.
We have just completed our eighth Silicon Connector, and over the coming months you will see some amazing new advances in connecting InDesign to remote assets, across the DAMs with which we have just finished integration. Because Connector lets InDesign talk directly to assets living in cloud-based DAMs, it is becoming very popular recently.
We have just identified the DAM that will become the ninth Silicon Connector. We chose Alfresco because, based on past experience, we know it is a solid system, and we see the user base growing recently. Alfresco is not just a DAM, it is a CMS, but our initial work is going to be just getting InDesign to talk to the assets using Silicon Connector. CMS integration has potential as well, but asset connectivity comes first, and this is very easy for us given the Connector foundation.
I was writing a press release recently, and I was just about to write a heading that has been something of a mantra the past 20 years: "Standards are the Future". But I paused, realizing the product I was describing is completely standards-based, thanks to recent technology advances. I corrected the title, and I think now is the right time to declare victory for web standards over proprietary technologies and walled gardens.
As of 2015, web standards-based approaches at last make complete sense for the majority of software use cases, at least those that our company works with on a daily basis. Sure, there are places where walled gardens and native software have a valid reason to exist, but those have become the exception rather than the rule.