Take Control of Customizing Tiger: Automator

Editor’s Note: The following article is an excerpt from Take Control of Customizing Tiger, a $5 electronic book available for download from TidBits Electronic Publishing. In a May 2005 excerpt from the book, Matt Neuburg looked at Spotlight —this article focuses on Automator.

The ultimate purpose of a computer is automation. Even when you’re doing something as simple as editing text in a word processor, you’re automating actions that would be terribly tedious if you had to perform them yourself, one at a time. (If you don’t believe me, trade your computer in for a typewriter. Slam the carriage return at the end of every line; remember to add extra space before every paragraph; get all the spelling right; make a mistake and retype the whole page—no thanks!)

Nevertheless, your computer doesn’t know in advance everything you will want to do, and there are times when you probably find yourself performing the same actions over and over again. Or perhaps there are things you don’t do, because, although you know how you could do them, the prospect would be too tedious and time-consuming. This is a bad state of affairs. It means that the roles have been reversed: you, the human being, are being automated, instead of the computer.

Since the dawn of computer time, the traditional way to solve this problem has been to write a new computer program that performs the repetitious or tedious actions. But writing a brand new program shouldn’t be necessary when applications you already have on your computer can perform the desired individual steps. The problem is to get those applications to perform those steps themselves, rather than your having to do it one step at a time. This is why Apple created AppleScript, which lets you assemble a sequence of actions that your existing applications can perform, and then set that sequence going whenever you like.

However, AppleScript is a programming language, and many users have an aversion to programming languages. So Apple introduced, in Tiger, a new automation technique—an application called Automator, which lets you, the user, assemble a series of steps (called actions ) into a single sequence (called a workflow ) without doing any programming at all. A workflow can be saved as a document, so once you’ve created a workflow, you can open it again later and perform the same sequence of steps, in a single move.

Tiger comes with a number of Automator actions; these actions are stored in /System/Library/Automator. You may also expect that many third-party actions will be written as Tiger matures; as you acquire such actions, you’ll store them in /Library/Automator or in your own user ~/Library/Automator.

It is also possible for a third-party application to be written in such a way as to include its own actions; in a case like that, its actions will be available in Automator, but you won’t see them as individual files. For example, when you update to the latest version of BBEdit, about 20 new actions for manipulating text will magically appear in Automator.

Extra for experts

An application that responds to AppleScript (that is, a scriptable application) is a good candidate to be the target of an Automator action, and behind the scenes, the heart of an Automator action that targets a scriptable application typically is an AppleScript script. So, when you construct a workflow in Automator, you may well be stringing together a series of AppleScript scripts—except that you don’t need to know AppleScript; the scripts are already written, and you never see them.

Make an Automator workflow

Using the actions included with Tiger, you can start stringing actions together to form workflows right now, in ways that will allow you to do things you may previously have thought impossible. Automator workflows may well become an important part of your customization of Tiger.

To illustrate the process of making an Automator workflow, let’s pose ourselves a task, for purpose of illustration. Our example will be extremely simple. I’m not trying to teach you all about Automator; I just want to show it to you so that you’ll understand the basics and won’t be afraid to experiment on your own.

Often, I’ve seen people say this on an Internet newsgroup: “I have a folder full of files, and I want to list the names of those files in a word processor. How do I do it?” Now, you can solve this problem in a number of ways. You can use Terminal—but many people don’t like Terminal, or are afraid of Unix commands. You can use Bare Bones Software’s freeware TextWrangler —but perhaps you don’t realize that. Anyhow, the real question is: How can you solve this problem for yourself?

This is the sort of situation where you ought to turn to Automator and see if the applications and actions on your computer can help you perform the desired task. Let’s do it!

Step 1: Start up Automator. (It’s in the Applications folder.) A new workflow document opens.

Let’s look at what we’re seeing. On the left are listed all the Automator actions (the Action column). The list can be filtered in two ways: you can select one or more applications in the Applications list (in the Library column), to show only the actions that apply to them, and you can type in the Search field at the top of the window. On the right is a big blank area where you’ll drag each action you want to use, arranging them to form a top-to-bottom sequence.

Step 2: Think about the problem. How does it start? “I have a folder…” So your sequence’s first step is to specify the folder. Click Applications in the Library column (because we want to search all actions), and type

folder

into the Search field, to help you find actions having to do with folders.

Step 3: The first found action is Get Selected Finder Items. Click it to read more about it in the pane at the bottom of the left side. The description says: “This action gets the selected items and passes them to the following action.”

Step 4: This sounds promising, but it would be more convenient not to have to start by selecting the desired folder; it would be better if a dialog would appear, asking what folder we want to use. Wait—the third action in the list is Ask for Finder Items. Click it and read its description: “This action lets the user choose Finder items in a dialog when the workflow is run.” Perfect! Drag Ask for Finder Items into the main area on the right (as shown in the screenshot above).

Step 5: As with many actions, this one has certain modifiable characteristics. (The action can be displayed by name only or with all its characteristics showing; to toggle between those modes of display, click the triangle at the left of the action’s title.) It turns out that Ask for Finder Items has a Type pop-up menu: we can limit the types of items to files, folders, or both. Excellent! We know we want to choose a folder to operate on, so change the Type pop-up menu to Folders. Also, we get to determine the prompt text that will show in the Open dialog; instead of “Choose a Finder Item:”, enter

Pick a folder to list:

.

Step 6: Part of the fun of working with Automator is that you can test your workflow right away, even before it’s finished. Click the Run button at the top right of the window.

A dialog appears and asks you to pick a folder! (Click Cancel or OK to dismiss it.) Our workflow is working. Of course, so far it doesn’t do anything with the chosen folder.

Step 7: Let’s fix that. Given a folder, we need to get all the files inside it. Look back at the list of actions. Hmmm… Get Folder Contents looks promising; click it and read the description. “This action gets the items from inside the specified folders.” Sounds good!

Step 8: Drag Get Folder Contents into the main area, after (below) Ask for Finder Items.

Look at what happens. The two actions join up in a specific way. An action can have input (data that feeds into it) and output (data that it produces). For one action to succeed another, you usually want the data produced by the first to be fed to the second. The join between the actions in Workflow shows this happening. Ask for Finder Items produces files and folders—the files and folders chosen in the dialog by the user. (In this case, it will produce just one item—a folder—because that’s what you’ll actually choose in the dialog.) Those files and folders are then fed to Get Folder Contents. This works because the output of the first step is the same type of thing as the input to the second step—files and folders.

Tip: This approach to programming is called a dataflow diagram; each step produces data which it passes to the next step, and the steps are represented visually as feeding one step’s output into the next step’s input. Unix programmers are familiar with the same concept through the notion of a pipe .

Step 9: The second step now gets the contents of your chosen folder, but it doesn’t display them. To help with this problem, Automator supplies a special action: View Results. Use the Search field to find it and drag it into the sequence at the end.

Step 10: Now run the workflow again. This time, Automator displays the contents of the chosen folder as a series of Unix paths, inside Automator itself. Having proved to yourself that that the workflow is working, you can click the X at the top right of View Results to remove it from the sequence if you want; but there’s no harm in leaving it there, since its output is the same as its input—it will pass along the folder contents, unchanged.

Step 11: Next, we want to capture the Unix paths produced by the previous step, in a text document. Type

text

in the Search field and look through the listed actions. Click each one so you can read about what it does. When you get to New TextEdit Document, bells should go off. It creates a new TextEdit document, and, even more important, it takes text as its input. So evidently it creates a new TextEdit document containing that text . Hmmm, so far, all we’ve produced in our dataflow is “Files/Folders”. What will happen if we follow that with an action whose input is “Text”? Try it and see! Drag New TextFile Document into the sequence as the last step. It joins successfully with the previous step! This shows that what we’ve done is acceptable; Automator will convert the data for us.

Tip: This ability of Automator to convert one type of data into another automatically is important, because it means you don’t have to worry very much about the type of data being handed from one step to the next. If Automator can’t convert one action’s output to the next action’s input, it will refuse to join them, the data types will appear in red, and you’ll know that your sequence isn’t going to work.

Step 12: Run the workflow. (The screenshot below shows the completed workflow.) It works! You choose a folder, and a TextEdit document appears, containing the pathnames of the files and folders within it.

That’s all there is to working with Automator. Every workflow is like this, a straightforward series of actions one after the other. There’s no complicated looping or decision-making.

To learn more, study the example workflows that are included (look under Example Workflows in the Library column), and look over the actions available to you (everything in the Action column). Think of workflows you’d like to create. And, as you use Tiger, ask yourself whether an activity you’re performing or would like to perform could be automated by expressing it as a workflow.

Extra for Experts

If you’re an AppleScript programmer (or you just play one on TV), an Automator action is a terrific way to distribute a script to other users, because it gives those users a little interface for modifying the script’s behavior, and because it lets them incorporate the script into a larger workflow. To get started writing your own Automator actions, see my online article at MacDevCenter.com.

[ Matt Neuburg is a TidBits contributing editor and the author of a variety of books about Mac software; his latest is Take Control of Customizing Tiger ( TidBits Electronic Publishing, 2005). ]