Thoughts on Extending the Creative Suite

Adobe must have the most extendable pro applications on the planet, and I think that has a good deal to do with their success.

Here’s just some musings on the methods available:

Currently there’s three basic technologies available: (C++) plugins, Application scripting (in either Javasript, VB or AppleScript — with support varying from application to application), and Flex/ActionScript based extensions using the CS SDK and Extension Builder. Each technology has its advantages and weaknesses, but a recent comment by Gabriel Travidis (the product manager of Extension Builder) prompted me to write this post to help articulate my thoughts on the subject.

While showing the (very impressive) new capabilities of Extension Builder, he was giving an overview of the technology as well as how C++ and classic scripting fits in. As Gabriel stated, C++ is necessary for deep integration into the applications. The downside of C++ is the learning curve and development time necessary to create C++ based solutions. Defining the ups and downs of scripting vs. CS SDK is a little more difficult. When describing the scripting support offered by Extension Builder, Gabriel said something to the effect of scripting being supported “for legacy code”.

Now, I realize that Gabriel was probably talking in a specific context and it’s not fair to take it out of context, but those words just struck me wrong. The words make it seem that classic scripting is no longer relevant. This is about as far as you can get from the truth.

Don’t get me wrong: I’m a strong proponent of the CS SDK and Extension Builder. I was from the first adopters of the technology and many of my suggestions helped shape its features. I use it all the time on many projects and there’s an awful lot you can do with it that’s difficult (at best) using other technologies. I’m a moderator on the Adobe CS SDK forum and I’ve written a Cookbook post on it.

On the other hand, I still use scripting as well — all the time!

I think I’m sufficiently familiar with both technologies to give my 2¢: Scripting is still very much alive, and I hope Adobe has no plans on trying to kill it!

CS Extensions or Scripting?

CS Extensions has many advantages over classic scripting: The most obvious advantage is native panels. You can develop native panels using the CS SDK that act like an integral part of the apps really quickly. In fact I recently developed a panel for a client that incorporated both XMP info panels and a CS Panel for InDesign that populates documents based on metadata (bidirectionally) in a total of about 15 hours of work. Start to finish. The panel gets populated dynamically as you switch through documents just like you’d expect, etc. Prior to the CS SDK, doing something like that in anything approaching this amount of time was unheard of. It’s simply amazing!

The advantages go much deeper. CS Panels have the full power of AIR applications. If you are familiar with AIR, you know what this means. Basically, both networking and local native processing are a piece of cake. SQL is built in. You can go on and on. The capabilities are incredible, and the developer resources for Flex and AIR are enormous.

It even goes beyond AIR APIs. The CS SDK includes APIs to facilitate cross-application communication and event handling specific to the CS applications. The CS SDK team is even working on APIs to facilitate communication to outside of the CS applications enabling some really wild stuff!

So why do we need scripting?

I’m going to leave Visual Basic and AppleScript out of the discussion. The strongest argument for both of those language is for cross-application scripting. Some of the arguments below for Javascript apply to these languages but not all.

Well, let’s start with one of the touted advantages to the CS SDK: Strong typing. Strong typing allows “intellisense” and proper code hinting which lets you browse the DOM as you are working. Cool stuff! Same goes for your own custom classes, etc.

Of course strong vs. dynamic typing has been a debate among programmers for years, and I’m not going to argue the sides now. Both sides have been argued many times by people who are bigger experts than I.

The fact remains that there’s advantages and disadvantages to both strong and dynamically typed languages. I’m pretty comfortable both ways, and I lean towards dynamically typed. In terms of automating CS applications, there’s really two basic arguments for classic scripting over the CS SDK.

The first argument is the learning curve. ActionScript is much more of a “real” programming language than Javascript. A lot of scripters approach scripting from the perspective of a designer. They might have never taken a class on programming in their life. They don’t know what a Class is, or even a Type for that matter. You simply can’t start programming in ActionScript without understanding a lot of the basics. For Javascript, you can really get a script working without understanding very much at all. A little knowledge on how to write a loop and a basic understanding of the DOM, and you’re ready to go! ActionScript is much less approachable.

The second argument is efficiency. I can literally write a script in about 20 seconds. That’s less time than it takes to package a CS Extension. Let’s leave compiling issues aside right now. The overhead for writing the same functionality in the ActionScript is tremendous. You need to create a new project. You need to create classes, declare all your variable types, only declare them once, worry about type conversions and all the bugs that it causes, etc. Even if you are on the strong typed camp and believe in catching bugs in the compiler, you have to admit that for straightforward projects it’s much less of an issue.

But what about “intellisense”?

For who? Let’s break scripters into three categories:

  1. Non-programmers
  2. Experienced Creative Suite programmers who are familiar with the DOM.
  3. Experienced ActionScript programmers who are not familiar with the DOM.

Category #1 will not be programming in ActionScript because it’s out of their reach. Category #2 already knows the scripting DOM, so the code hinting is nothing more than a convenience which is easily offset by the programming efficiency of dynamic non-compiled scripting. For the third category, I can see it as a real advantage which can be used as a tool to learn the DOM (and maybe ultimately using it for classic scripting!).

But There’s More

But let’s move beyond the point of dynamic vs. strong typing. There’s also the question of functionality. What? Functionality you say? How can scripting be more functional than CS Extensions?

Well, I see it like this: Scripting and CS Extensions are approaching the automation game from two opposite frames of reference. Scripting offers an alternate interface to the program which can offer some user interaction. CS Extensions are really about supplementing the user interface with additional functionality. Case in point: Panels. That’s the most obvious selling point. In fact you cannot create a CS Extension without a UI. That’s a huge limitation. Of course you can create a UI and then hide it by moving it off screen, but that’s really just an ugly hack.

Startup scripts are incredibly useful creations. You can add menus, event listeners, and multiple scripts that interact with each other in just a few lines of code. They don’t put any real weight on resources, etc. In fact, scripts can be run from outside the application entirely to do the automation (most specifically using Visual Basic and AppleScript). That means there’s no need for a UI at all!

InDesign also has private scripting engines, so different scripts can run in different engines preventing any chance of conflicts. Looking at engines a bit differently, it allows different scripts running in the same engine to interact in ways that are much more complex using CS Extensions. You can load a central library of functions and have 20 different scripts all running the same code without any convoluted calls. This simplicity can be extremely powerful!

UI

When looking at CS Extensions vs. scripting user interfaces, it’s a mixed bag.

If you look to AppleScript or Visual Basic, you have the operating system tools for building UIs which can be very powerful. Those UIs obviously look native because they are built using OS specific tools.

For argument sake, let’s assume you want to write platform independent code, so we will leave the OS specific tools out of the discussion. This leaves us with a question of Script UI vs. Flex/ActionScript.

ActionScript based UIs offer a lot of freedom. You can build really complex UIs relatively easily. There’s almost no limit to what you can do in a Flash UI. They can really be entire applications. You have an awful lot of power there. Another advantage to Flash dialogs is the ability to change properties in InDesign’s DOM while a modal dialog is open. This is something not possible using Script UI.

On the other hand, Script UI has some advantages as well. While you can create great looking UIs in ActionScript, creating totally native looking UIs is really hard. Script UI dialogs look exactly like native dialogs so if native looking UIs are important, Script UI is going to be your first choice. The Extension Builder team is working on this issue, so it’s going to be interesting to see what they can come with on the CS Extension side.

Another plus for Script UI is speed in creating the UIs. Complex UIs can take quite a long time in Script UI, but for straight-forward UIs, it’s quite fast to build one. Yet another point to consider is that Script UI is a native component of scripting, so if deploying your solution as a simple single script file is important, that’s another point of the Script UI argument. For solutions that must support legacy apps (pre-CS5), you’re almost certainly going to have to go the Script UI route. Although it is possible to run a Flash UI inside a Script UI container, so that’s something to consider as well.

My approach to the Script UI vs. Flash question is to look at the requirements for a specific solution, and to decide what makes sense based on the requirements.

Bugs

Of course we can’t forget bugs. Having scripting available has been a very useful tool for me to use as a fallback when something is not working correctly in ActionScript.

InDesign Server

Another important point is that the CS SDK does not (currently) support InDesign Server, so if you need to automate InDesign Server, your only option is classic scripting (other than C++).

Both!

Now, I’m fully aware that Gabriel was not proposing that ExtendScript is redundant. Quite the opposite! He and his team are making a real effort to support scripting alongside the CS SDK with some really cool abilities to use the two technologies together in a meaningful way. I’ve actually discussed scripting and CS Extension communication with the team on numerous occasions.

The point to take away from this, is that if you want to be automating the Creative Suite in the best possible way, be sure to include both classic scripting and the CS SDK in your Creative Suite automation toolset! :)

Tags: , , , , , , , ,

7 Comments

  1. Marc says:

    Thank you for this great overview whose I appreciate the impartiality.

    (Just to quibble a bit: JavaScript is as much a “real” programming language than ActionScript, IMHO.)

    @+
    Marc

  2. Harbs says:

    That’s why real was in quotes. When used on an advanced level, I totally agree with you.

    My point was that in can be used on a very basic level by someone who does not have programming experience — something not possible in more rigid languages.

  3. Bob Stucky says:

    Nice article, Harbs. I’m in your camp. Use the right tool for the job at hand. Personally, I love the options that we have.

    The contact sheet script is a good example. Given that the UI has been in existence for a 6 or 7 years (ScriptUI), why change it? But then, I wanted to add a UI to help make ID contact sheet templates. AS was the way to go. Two different technologies used to deliver one product…

    As they say, when all you have is a hammer, all your problems start looking like nails.

  4. Hear, hear! Wholeheartedly agree. I need and want both ExtendScript and ActionScript – what I’d use and how much of it completely depends on the job at hand.

    Great post!

  5. […] 11, 2011 in Coding with 0 Comments // Having read the (InDesign developer) Gabe Harbs’ post on the subject, I’d like to add here a couple of personal points focusing on […]

  6. Trevor says:

    Nice article, Harbs, very clear.

    2 questions.

    1) Is there a significant difference in the speed the script will run between a js script and an as3 script? a) for a script that reads the properties of every character style range in a document – i.e. mainly retrieving information and b) for a script that does a lot of formatting etc. on the documents.

    2) Is the functionality of the as3 CS SDK more similar to js or the c++ SDK which has considerable more functionality and access to document properties than js?

    Regards Trevor

Leave feedback