Take advantage of enhanced AppleScript and Automator support: operate on image selections (in addition to projects and albums); filter for the “pick” of each stack; automate the export of master files with associated XMP metadata.
Whether you call it AppleScript or Automation, it seems that Apple is at long last embracing automation in its Pro applications, or more precisely procedural automation. The distinction is important, as Apple has, via increased use of XML as its base file format in more and more applications, increased its use of file automation.
XML allows you to automate a great many processes since the format is reasonably open and able to be modified with relative ease. However, that doesn’t automate the process of creating the XML. Yes, you can create most XML in almost anything, but as the XML gets more complex, creating files outside of their “normal” application can get more difficult until it’s not worth the effort.
What AppleScript does is let you automate the procedures that create the final output, or really, any procedures supported by the application’s scripting implementation or dictionary. AppleScript is the default language for Apple’s Open Scripting Architecture, or OSA, which is the framework behind inter-application automation at the Cocoa/Carbon level in Mac OS X.
To illustrate how critical AppleScript has been to Apple, it is not much of an exaageration to say that Quark Xpress, and the massive amount of AppleScript workflow saved Apple’s bacon in the publishing industry during the mid to late ’90s.
However, Apple has always had a very fractured attitude toward AppleScript. A few years ago, it was pretty bad. At one point, Apple only had two non-OS applications that supported AppleScript, or were scriptable. This rapidly got better on the consumer side, and is one of the reasons that iLife applications work so well together.
On the Pro side though, the answer was usually a variation of “You can’t automate creativity,” to which the reply was “Even a Final Cut artiste does a lot of monkey work.” It seemed that Apple’s Pro applications teams were simply never going to understand the importance of AppleScript, even though other “creative” application vendors, like Adobe, had learned this lesson starting around Photoshop 6 or so.
However, thanks to more users of Pro applications seeing how things like iDVD could be automated to handle the basic monkey work, or to help speed up interactions with other applications, and thanks to Automator, which is a more visual way to implement AppleScript, Shell, and even Cocoa actions without having to learn any language syntax, Apple’s story on AppleScript has gradually been getting better. Aperture, Soundtrack Pro, and Shake all support AppleScript, Perl, and other automation languages.
Automation support is important for two reasons. First, it makes it easier to use the application in a production environment. Think about all the things that happen on your network. Now imagine doing all of them completely manually. Scary.
While you always will have that creative use that requires direct input from the human, the truth is, you can take almost any job category in a typical SMB or Enterprise company and find a lot of things that are repetitive and almost rote. Automating those processes not only helps them run more reliably, but also frees people up to do all the long term, or single shot, or creative projects that they’ve had to delay for the monkey work.
Secondly, and perhaps more importantly, it leads to applications and tools being used in ways that the developers, be they ISVs or in-house, cannot, and might never have anticipated. I’m pretty sure that the X-10 people never thought of their devices being used as cat repellent, but, with one of those, an animated piggy bank, and some imagination, you can keep cats well away from your laser printer.
Adding AppleScript and automation support to an application does increase the development time, but it makes it easier to get the most use out of the application in ways that make sense to the end user, be they a traditional “user” or a sysadmin. The more I can use an application, the easier it is to write the upgrade checks.
There’s no way to predict what anyone will do with the AppleScript/Automation support in Aperture, but I know that when my designers need a new application, automation support is quite high on the list of requirements, because I know that such support will help me make their lives easier, and that is a rather important part of any sysadmin’s job: Making life easier for the end user.
The more Apple, or any Mac OS X developer helps me to do that, the more of their stuff I’ll buy. Seems a pretty good reason to support it to me.