Discovering Automator by Hanaan Rosenthal • Automator, A Mac OS X Tiger automation app for the rest of us
Chapter 4: Actions and Workflows
In some cases, workflows you’ll create will be a mere collection of unrelated commands, only associated by planned conditions. For example, one action can create a text file in Text Edit, and the following action can save the front document in Text Edit. While you can see how the second action will save the file document created by the first action, the actions don’t actually pass anything between them.
The real power of Automator, however, is in matching the output of one action with the input of the following action. It’s up to the action’s developer to design the action in such a way that it will take advantage of certain types of data, such as mail messages, text, or Finder items such as files or folders.
While the concept of connecting one action to the next may appear to be simple, there is more to this than meets the eye. This chapter discusses how to make sure one Action can use the input sent to it by the previous Action, why some Actions just don’t mix, and how exactly Automator tries to bridge the gap between data types that appear different but can actually fit together rather well.
Input and output like you’ve never tasted them before
In order to understand input and output better, lets try to equate an Automator to the steps you take when you make yourself an omelet. Lets follow the chain the food goes through from the time it gets to the restaurant up to the time it gets to your table (you can imagine the actions that follow, but you’re on your own with that…).
The first action in out imaginary workflow is specifying the ingredients required to make your meal. The action will be called “Specify Ingredients” and will have a list of the following items: A red Pepper, a bunch of mushrooms, and a Vidalia onion.
The second action will chop down all the ingredients. But wait, how will the second action know which ingredients to chop? This is where Automator shines: It has a special mechanism to pass information from one action to the other. In this case, the first action’s output will be the pepper, mushrooms, and onion, and the input of the second action will be these very same vegetables.
The result of the second action will be a mass of chopped vegetables, which will be the following action’s input. That action will take the chopped mass passed to it from the previous action, and toss it to the buttered pan. This food will pass from action to action, being modified a bit by each action before being passed to the next.
As the workflow ‘cook,’ it is your responsibility to know what comes out of one action, and how to match this output with the next action. For instance, you don’t want to have the “Put content of cutting board in trash” action follow the “Chop vegetables” action.
Getting down to business
As I always say: There are two kinds of people; those who do and those who complain. And now that you had breakfast, we can get going with something to do.
1. Start a new workflow.
Make sure that Automator is launched and that you have a new, clean workflow window ready.
2. Add the New Folder action.
The New Folder action is listed under the Finder category.
Enter “Test Folder” in the name field. Leave the Where popup set to Desktop.
3. Add the Label Finder Item action.
This action is also under the Finder category. Click the radio button next to the red label.
When you’re done with the previous steps, your workflow should look like the one in figure 1.
Figure 1: The workflow to this point.
Lets now run the workflow. After running it you should have a folder named “Test Folder” on the desktop with a red label applied to it.
What allowed the workflow to work is that the first action created a folder and passed a reference to that folder to the following action. The next action applied the red label to any file or folder that was passed to it. This happened to be the folder created by the first action.
Lets take a peek behind the scenes
While I’m assuming that you will take my word for all this input/result stuff, I do have a neat way to show you an action’s result.
To see the result of the first action in this workflow, you will add the “View Results” action after the first action. Follow these steps:
1. Add the “View Results” action.
The “View Results” action is found under the Automator category.
2. Move the “View Results” action between the first and second actions.
Click and hold the number at the top left of the last action and choose “Move Before ‘Label Finder Items,’” as shown in figure 2.
Figure 2: Move the “View Results” action before the “Label Finder Items” action.
The “View Results” action exposes the result of the previous action. Although it won’t change the flow of things, it may be a bit cryptic.
The results won’t always be that clear to understand since they are displayed as Apple Events rather than in simple English. A mail message, for instance, may show like this:
{message id 88656 of mailbox "INBOX" of account ".Mac" of application "Mail"}
Files and folders will show as AppleScript alias objects: the word ‘alias’ followed by the colon-delimited list of nested folders.
After moving the “View Results” action between the first and last actions, run the workflow again.
The content of the “View Results” action pane, as seen in figure 3, will be:
“{alias "Tiger:Users:hanaan:Desktop:Test Folder:"}”
This shows you that the result of the previous action is a reference to the folder named “Test Folder” on the Desktop.
Figure 3: The “View Result” action after the workflow ran.
Ignoring results
Sometimes an action allows you to choose if you want to use the result from the previous action as the input or not. While this doesn’t happen all the time, I would still like you to see how it’s done.
1. Start a new workflow.
2. Add the “Send Outgoing Messages” action.
This action is found under the Mail category.
The “Send Outgoing Messages” action you added to the workflow can do one of two things: It can send all outgoing messages, or, if a mail message is passed to it from the previous action, it will send only that message.
Lets say that we want this action to send all outgoing messages, regardless of the previous action’s result. What we can do is tell the “Send Outgoing Messages” action to ignore the result from the previous message.
You can do that with a feature that some actions have available.
Look at the input-indicator at the top left of the action’s pane; It currently says “Mail Messages.” It also has a little triangle pointing downwards. You can see it in figure 4.
Figure 4: The input and output indicator of the action.
Clicking that little triangle opens a popup menu that allows you to specify whether you want that action to use the result passed from the previous action, or if you want the action to ignore the previous action’s result. Figure 5 shows that popup menu.
Figure 5: The input indicator popup menu.
Note that not all actions have that popup menu. It is up to the action’s developer to specify whether to include this menu or not.
Input and output on the fly
Some actions sport more than one type of input or output. The type of input/output depends on changes the user makes to the action’s interface.
To see this happen, lets add the “Filter songs in iTunes” to whichever workflow happens to be open.
After adding the action, try to change the selection in the Filter popup menu. Notice that when you change the selection in the popup, both the title of the action and the input/output changes to reflect the choice you made.
Action-bridge
In some situations, Automator can help you bridge between actions that appear to have non-matching input and result.
Imagine for a minute having one action find songs in iTunes and the following action copies files to another disk. The result of the first action is a reference to iTunes songs, and the input of the following action is files and folders. While it appears that the two won’t work together, Automator manages to link them quite well, as seen in figure 6.
What allows Automator to link data types such as iTunes songs and iPhoto pictures is a hidden feature called connection-actions. These actions work transparently behind the scenes to link between data types that may appear to not work together, but actually do.
Figure 6: Notice how the iTunes songs result data-type matches perfectly with the following action’s Files/Folders input data-type.
What makes an iTunes song or an iPhoto picture the same as a file is the fact that both items have a file related to them. Every iTunes song has the song file and every iPhoto picture has a picture file attached to it. So, when one action passes an iTune song and the next requires a file, the second action actually gets a reference to the actual song files that were passed by the previous action.
The following exercise will help plant that idea.
Create a new workflow.
Add the “Get Selected iPhoto items” action. This action can be found under the iPhoto category.
Add the “New QuickTime Slideshow” action. This action can be found under the QuickTime category.
Note the connection between these actions. Even though one returns iPhoto items and the other requires image files, they merge well.
Action connection looks
There are three graphical representations that Automator uses to show you how well or how not so well two actions connect.
Good connections
When the input and result of two actions work, meaning, there’s good chemistry between them, Automator will draw their connection as shown in figure 7.
Figure 7: Two well-connected actions.
No input and/or no result
When an action has no result, or accepts no input, the connection between the actions will show simply as a space between the actions, as seen in figure 8.
Figure 8: When an action accepts no input, or returns no result, as the Eject Disk action, Automator simply leaves a space between the actions, and does not link them in any way.
Bad connection
When the result of one action isn’t compatible with the input of the following action, Automator displays the data types of the input and result in red, as shown in figure 9.
Figure 9: When the result of one action isn’t compatible with the input of the following action, Automator displays the data types of the input and result in red.
How important is it?
It seems initially that a good connection will work, and that red text is bad. This isn’t necessarily the case.
In many cases, you don’t need the actions to be connected well, and in other cases, actions that appear to work together well actually produce the wrong results. Examples of both situations will be discussed throughout the book.
Results that skip over actions
While many actions use the previous action’s result and pass their own result along for the next action, some simply don’t.
Imagine the Finder’s Launch Application action. It doesn’t require any input and doesn’t have any particular output. However, as you can see in figure 10, it shows the input and result data type as “Anything.”
Figure 10: The Launch Application action takes anything as input and returns anything as a result.
Anything goes
What is “Anything” supposed to mean exactly? Does it mean that the action will accept anything you pass to it and will figure out something to do with it? Well, sort of.
What “Anything” means here is that the action will simply take any input the previous action cares to pass to it, and will pass it right through to the next action, unaffected.
Lets test this situation.
1. Start a new workflow.
2. Add the “Get Specified Text” action.
Type “Lets play broken telephone!” in the main text field of the action.
3. Add the “Launch Application” action.
Leave the popup menu in this application set to Address Book.
4. Add the “New TextEdit Document” action.
After the workflow is built according to the steps above, run it. If all is well, a new TextEdit document has been created with the text “Lets play broken telephone!”.
What it means exactly is that the text from the first action passed through the second action right to the third action.
Also, I want you to look at the input/output data type indicators. Instead of saying “Anything” as they did earlier, now they say “Text.” You can see that in figure 11.
Figure 11: The data type indicator for input/output is now set to Text.
Damage prevention
As much as it is fun to create Automator workflows and watch them run, the damage that can be done by the “wrong Action at the wrong time” cannot be underestimated. This chapter discusses Automator’s built-in warning system for Actions that have the potential to permanently alter files or other elements affected by your workflow.
Read-up
Your first line of defense in preventing damage from badly placed actions is reading the action’s description. Action developers are encouraged to add warning text to the description of their actions. This text appears in the description area at the bottom left corner of the workflow window.
Read the action’s description, understand what it does, and test it on data or files you don’t care about.
Automator alerts
Built into Automator is a system of alerts designed to inform you when an action you’re adding to the workflow has the potential of causing irreversible damage. Lets take it for a spin.
1. Start a new workflow.
2. Add the “Get Specified Finder Items” action.
Drag any file from the desktop over to the workflow area in the workflow window.
3. Add “Rename Finder items” action.
Notice that as you add the “Rename Finder Items” action, Automator stops you with an alert, shown in figure 12.
Figure 12: The alert dialogue that explains the consequences of using this action and offers a way to avoid altering the files.
The warning dialogue offers to add the “Copy Finder Items” action before the “Rename Finder Items” action. Having the Finder items copied prior to renaming would ensure that the duplicate items were renamed and not the original ones.
The warning dialogue gives you three options: Cancel, Don’t Add, and Add.
Clicking Cancel will simply not add anything to your action. To add the “Copy Finder Items” action, as suggested by the warning, click Add. Click the “Don’t Add” button to only add the “Rename” action by itself.
It is up to the action’s developer to determine how ‘dangerous’ the action he’s creating is. The action’s developer is given three levels to assign to the action in regard to the level of warning it requires. The levels are: Harmless, makes reversible changes (such as renaming files), and makes irreversible changes, such as altering images.
Wrapping up
This chapter was mostly about input and output. It’s the action relationship chapter. As with people, an action’s life wouldn’t mean half as much without the ability to communicate with fellow actions.
In the next chapter you will be introduced to some special actions available for use in Automator. These actions allow you to communicate with the user while the workflow is running, and do other cool things such as run AppleScripts and even whole Automator workflows from inside a workflow! Stuff too cool to pass up!