The history of the Mac is paved with Apple's attempts to enable ordinary users to tap the programmable power of their own computers. Apple events allowed applications to tell each other what to do. AppleScript allowed users to harness Apple events in an English-like programming language. AppleScript Studio allowed an AppleScript script to be wrapped in a Cocoa interface. But the Grail has remained elusive. The vast majority of users don't want to deal with a programming language. Pre-written scripts exist, but what if you don't know that, or can't find one that does what you want? The problem is that it's impossible to know in advance what you, the user, would like to do - that's the point of putting programming power in your hands in the first place.
The challenge, then, is to provide you with the "building blocks" you need, in such a way that you can assemble them, yourself, to do what you want - without your having to know a scripting language. With Automator, Apple rises to this challenge.
A Piece of the Action -- Automator's "building blocks" are files called Actions. Tiger comes with over 200 Actions pre-installed; they do things such as create an iCal event, compress the images in a PDF, or rename the files in a folder. When you start up Automator, you're shown all the installed Actions; using simple drag-and-drop, you arrange the ones you need into a top-to-bottom sequence called a Workflow. You can then run the Workflow to execute the sequence in order; you can also save the Workflow so that you can conveniently run it again later, send it to your friends, and so forth.
It isn't just the sequential execution of Actions that gives a Workflow its power: an Action may accept input from the previous Action in the sequence, and may produce output which is passed to the next Action in the sequence as its input. Furthermore, an Action can have an interface, where you specify ancillary settings. For instance, in the Action that sets the iTunes volume (loudness), the new volume value comes from a slider in that Action's interface. You can set that slider in advance, as you're creating the sequence within Automator; alternatively, you can postpone the decision and have the slider presented to you in a separate window at the time the Workflow actually runs. In some cases, indeed, an Action's entire purpose is to request input from the user at runtime.
A Workflow thus involves a clever interplay between data flowing from Action to Action, on the one hand, and the user's input, on the other - where the user's input can be provided in advance or as the Workflow runs. Here's an example to illustrate. Suppose I have a folder of 100 images, and I want to rename them Image001, Image002, and so forth. (That's genuinely useful; people frequently ask how to do this sort of thing.) An Automator sequence to accomplish this might go as follows:
Step One: Ask the user where to create a new folder. (The idea is that we're going to copy all the files into this folder before renaming them, just in case something goes wrong.)
Step Two: Ask the user for the source folder that currently contains the image files.
Step Three: Get a list of all the files in that folder. (This step accepts as input the folder from the previous step and produces as output all the files in that folder.)
Step Four: Ask the user where to copy those files to - the user should specify the folder created in Step One - and copy them. (This step accepts as input the list of files from the previous step and produces as output the copied files.)
Step Five: Rename the copied files. (They are the output from the previous step.) The Rename Files Action presents lots of options for how the renaming should work; one of these is a constant prefix (with the user sets as "Image") followed by a sequential suffix with a fixed number of digits (which the user sets as 3, to get suffixes like "001").
Ease of use is a slippery concept, but that sequence really was easy to create. I set it up in Automator spontaneously, without forethought - when I started, I wasn't even sure what I wanted to do, or what Automator would let me do. When I introduced the Rename step, Automator itself suggested I add the Copy step before it, as a safeguard; through warnings of this sort, and by checking to see that one Action's output is legitimate input for the next, Automator assists the naive user.
An Action is a terrific way to package scripting functionality. It takes about two minutes to turn an AppleScript script into an Action. As an AppleScript programmer, I'd much rather send you an Action than a bare script, because you can incorporate it into your own sequences and customize it through its interface without having to know any AppleScript yourself (and without relying on me to modify it for you). It is also possible to write an Action in Objective-C. Furthermore, an application bundle can contain Actions, which automatically make themselves available to Automator without further installation; thus, for example, by simply running BBEdit 8.2 (a free update for BBEdit 8 customers), you'll see two dozen text-processing BBEdit Actions magically appear in Automator.
Given all this, I expect to see a spate of further Actions in the near future - big developers will bundle them into their applications, scripters will use them to repackage their existing scripts. As that happens, end-users, I suspect, will quickly discover that Automator is the fulfillment of a dream: at long last, anyone can program the Mac.