2 Interviews: The guys behind ExtendScript ToolKit, SwitchBoard + PatchPanel
Adobe AIR, Adobe Flex Builder, Adobe Illustrator, Adobe InDesign, Adobe PatchPanel, Adobe Photoshop, Adobe SwitchBoard, ExtendScript ToolKit, ExtendScript', Flash Panels, Flash Plug-ins Add commentsAutomation + Expanding our Creative Capabilities
In 1994 I remember the first time I came across the need to automate my creative workflow. I was freelancing as a visual effects artist working on a commercial and we needed to do some complicated compositing that required creating traveling mattes and manually de- and re-interlacing the footage in order to get clean mattes. I was able to streamline the process using QuicKeys to record and then playback redundant tasks and after that I was hooked on the concept. At the time, I wanted to push it further and actually get under the hood of the plug-ins in order to customize them and make them my own, so to speak. However, at the time, if I wanted to develop plug-ins, I would have had to go back to school. I was making a decent living creating visual effects for broadcast and video games so it remained just that, a dream.
14 years later, we now have 6.5 development tools to help ActionScript developers make the transition to creating our own applications as well as Flash plug-ins that drive the Adobe Creative Suite applications. By using a mixture of Flex Builder, SwitchBoard, PatchPanel, CSXS, AIR and ExtendScript ToolKit – as well as Flash in conjunction with the last 3 options – my dream has come true. Adobe plans to release an article I am working on that will make sense of what tools to use when you are trying to extend the Creative Suite, but for now, I would like to introduce you to two of the main players behind several of these technologies and explore how the technology came to be. It’s the type of story that I find as interesting as the technology they created, due to all of the events that had to fall into place before we ended up here. I am sincerely grateful for their time and willingness to participate.
An interview with Michael Daumling
At the Adobe development summit in the spring I had the privilege of meeting Michael Daumling, a Principal Scientist in the ETG Core Technology group, who is the creator of ExtendScript and the main driving force behind ExtendScript ToolKit and most things related to extending the Creative Suite. Over the course of several beers, he was kind enough to tell me his great story. Unfortunately for me, I rarely drink so there were a couple of holes in my memory about his story, [blush] but he helped fill in the blanks below.
Dr. Woohoo: In the pdf Adobe Intro to Scripting, it defines ExtendScript (ES):
Adobe has developed an extended version of JavaScript, called ExtendScript, that allows you to take advantage of certain Adobe tools and scripting features.
I imagine this description simplifies major shifts in development plans, individual and team responsibilities and some risk involved as well. Can you tell us a little about how ES came to life?
Michael Daumling: ExtendScript goes way back, to the old days where small start-ups like GoLive GmbH in Germany could make some money with a product called Cyberstudio. Back then (late 90s) I was a contractor for this company. Their product (which was later known as Adobe GoLive) needed an SDK, and I had a toy JavaScript interpreter which I had written in my spare time. I have always liked interpreted languages; among the ones I wrote was StarBASIC, which back then was the scripting language (and infrastructure) of Star Division’s StarOffice, which later became OpenOffice. Or a nice app that ran a somewhat obscure language called Logo, but which was (and still is) quite popular among students as an educational language.
To make a long story short: my JavaScript engine became the beating heart of GoLive’s SDK. This came to the attention of the After Effects team. They thought that it would be cool if people could attach JavaScripts to their frames so they could move and change objects between keyframes; a concept that seemingly many people found attractive. Soon after that, a bunch of cool kids in Burlington, MA was tasked with the creation of a Flash authoring tool, so they sat down and created something called LiveMotion (another Adobe product long gone). They needed an ActionScript engine; they approached me, so I sat down and added many ActionScript specific goodies to my engine (back in these days, ActionScript was a sort of slightly crippled JavaScript, not this big beast with classes and more).
So, all of a sudden, I found myself having two additional clients. Which made Adobe move me over to the Core Technology division, and they let me hire two people, so I became an own team. I had to leave GoLive, and was now reporting to someone in San Jose.
Who was next? Do you remember Atmosphere? That was a product intended to create virtual worlds, mostly for chatting, where people could create cool avatars of themselves and roam virtual landscapes. For a lot of reasons, this concept never took off, but there was a great game and physics engine that was entirely ExtendScript driven. The product survived, and became Acrobat 3D.
At that time, Photoshop and Illustrator had scripting interfaces for Applescript and VBScript. The CoreTech team that wrote this scripting code thought that it would be a cool idea to add JavaScript to the code, and after a while, ExtendScript became part of Photoshop and Illustrator. This made me seemingly more important; Adobe made an offer to move me over to San Jose from Hamburg, Germany, which I found impossible to refuse.
The only remaining big applications that did not support ExtendScript were Acrobat and InDesign. Acrobat lived quite well with its JavaScript engine, which they had borrowed from the Mozilla Foundation, and they were quite unwilling to change their engine. At InDesign, program management was not convinced initially. InDesign was designed from the ground up with emphasis on extensibility, including the scripting languages VBScript and Applescript. Unfortunately, these languages are platform dependent, so I thought that ExtendScript would be an ideal fit as a cross-platform scripting language. InDesign’s extensibility architecture made it easy to add ExtendScript; as a matter of fact, it took InDesign’s then-scripting guru Peter Boctor and me just a week to get it up and running.
Then someone had the grand idea to combine Adobe products into a suite. Creative Suite was the name. However, how could Adobe show that these products were integrated at all? Well, guess what the glue was: ExtendScript. Adobe created the Bridge application, which originally was a file explorer built into Photoshop. As an own product, it was Adobe’s first C+++/ExtendScript hybrid. It contained gazillions of lines of ExtendScript code.
A stand-alone explorer is nice, but useless unless you can have other applications talk to it, or send back some results. We needed an interapplication communications mechanism. It should be platform independent, so COM or Applescript was not a good idea. Bridge’s Rob Corell and I sat down and invented this mechanism, which allows applications to send ExtendScript code to each other. This technology quickly became the backbone of the Creative Suite integration. I guess that without ExtendScript, the Creative Suite would not exist as it does today.
In the meantime, ExtendScript has spread to other locations and applications. Some use it internally only, to drive their APIs and modules for testing purposes, while others expose their objects to 3rd party scripters.
An interview with Bernd Paradies
In the fall of last year, thanks to the capabilities of ExtendScript and ExtendScript ToolKit, I was able to create a Flash Plug-in for Illustrator that mashed up Flickr with the Color Analytic work I had created for In The Mod in order to quickly extract colors from images and save them directly to the Swatches Panel. You can see it in action here. It was definitely a hack, but the proof-of-concept worked. Then it happened.
Apple launched Leopard, the new Max OS, in the winter of 2007 and redefined how the redraw in windows worked – similar to the one the Flash Plug-in used. This effectively killed the hacked approach I was using and so I shelved the concept of Flash plug-ins and moved on. Around January, John Nack, the Principal Product Manager, invited me to play in Adobe’s sandbox and suggested that I take a look at the work that Bernd Paradies, a Senior Computer Scientist with the ETG Core Technology group at Adobe, was working on. What I saw was beautiful! It was a dream come true.
Here was this small team within Adobe creating two SWC libraries for Flex Builder – SwitchBoard and PatchPanel (in beta) – that could be used to extend the Creative Suite applications (with the Leopard issue resolved). I mean, imagine it. If you take the number of 3rd party plug-in developers that currently exist for Adobe products and add to that the legions of ActionScript developers who can now create their own AIR applications and Flash plug-ins that drive the Creative Suite applications, the potential is mind blowing. When the smoke settles, it should be very interesting to see the new creative tools that are developed. It might take some time, but the designers will inevitably benefit in the end.
Dr. Woohoo: How did you end up at Adobe and on the ETG Core Technology group working with Michael?
Bernd Paradies: Michael and I met the first time at StarDivision in Hamburg, Germany, which was eventually bought by Sun in order to annoy Microsoft by giving away OpenOffice for free. I was responsible for the text composition engine of StarWriter (some of my old code might still be in use in the OpenOffice version). Michael was all over the place at StarDivision. A lot of his code including Easter eggs have survived in his StarCalc component of OpenOffice – you should ask him about the Easter eggs!
Either way, I left StarDivision for P.INK, which developed software for magazines and newspapers. My job was exploring new technologies including a new version of PageMaker from Adobe. The code name of Adobe’s future generation layout program was “Shuksan”, which eventually became InDesign etc. Well, P.INK went out of business and I got an offer from Adobe (I guess because of my deep Shuksan knowledge), which I happily accepted. I had to move to Seattle and brush up my English, though.
After the collapse of P.INK the CEO picked the best developers of P.INK and founded a new company called GoLive. Yes, that’s the GoLive that got acquired by Adobe a few years later and that’s how a lot of my old P.INK buddies became new colleagues again. Michael left StarDivision for GoLive and got merged into Adobe. While Michael was developing the scripting infrastructure for Adobe over the following years I stayed with the InDesign team for almost 9 years. Of course Michael and I stayed in touch over all those years and when the scripting team had an open position he encouraged me to throw my hat into the round. The rest is history: I took over BridgeTalk, Adobe bought Macromedia, and then came SwitchBoard and PatchPanel, which try to bring Adobe and Macromedia technologies closer together.
In general I love working for Adobe and personally I prefer working at CoreTech instead of a product team like InDesign. In CoreTech I get more in contact with other departments and technologies inside and outside of Adobe. Working with Michael? He is just brilliant. He is enormously productive and I often find myself in a position where he delivers long before I find time to pick up his latest work.
Dr. Woohoo: Where did the idea come from in regards to building SB & PP and how did SB & PP come to life?
Bernd Paradies: Michael and I had been working on prototype for integrating ActionScript and ExtendScript that we eventually had to abandon. After that Michael sent me off to explore another idea: Why not using the FlashPlayer as a black box and ExternalInterface as the transport mechanism (“plumbing” as we called it)? We already got the DOM information through the CS Scripting Dictionaries and he suggested that I could generate ActionScript wrapper files from OMV XML files. That’s how PatchPanel started. BTW, we didn’t have a good name until Ben Bauermeister suggested “PatchPanel” to show that this technology is a companion to SwitchBoard.
Finding a name for SwitchBoard was the smallest problem. Michael came up with it shortly I presented the idea of “BridgeTalk on AIR”. Everybody loved the idea – even my bosses. But they also were concerned about my workload and suggested that I should either work on PatchPanel or SwitchBoard. Well, I did both. The importance for having SwitchBoard was pretty clear to Michael and me very early on. We wanted to support the AIR platform and knew that AIR developers wanted to talk to CS apps. I met with the AIR team and it became pretty clear that the AIR runtime (that gets installed with every AIR app) was taboo. That’s why I had to come up with a solution that involved services.
Cool stuff! Thanks for sharing these interviews!
[...] If you’re interested in how PatchPanel, SwitchBoard and ExtendScript Toolkit came to life, check out this interview with the main guys behind them: 2 Interviews: The guys behind ExtendScript ToolKit, SwitchBoard + PatchPanel [...]
[...] Incidentally, if you’re interested in how Adobe’s app automation layer came to be (and where it might be headed), check out Drew’s 2 Interviews: The guys behind ExtendScript ToolKit, SwitchBoard + PatchPanel. [...]