Automator - My comments

Automator - A critique

Since there are a number of gushing reflections about Automator on the web I felt a reality check is needed. Don’t get my wrong I think Automator is a useful addition to Mac OS X but it also has a serious limitation that hamper its functionality.

There is no flow control.

What does this mean?
Well there are two main areas. The first is that you cannot make decisions about which action should get which files in any one workflow. For example, You cannot set up a workflow that could do the following:

If you have a folder full of images, lets say some of the images use the cmyk color space and others use the rgb color space. Lets say you want the cmyk images to be given to an action that will prepare the images for a brochure, and to give the rgb images to an action that will prepare the images before uploading to a website. You can’t do this. You cannot split the workflow so that some image files are given to one action, while other images go to another. (You could write two workflows, where each workflow ignores the files it shouldn’t be dealing with and then run both workflows over the same set of files)

The second main area and to me is even more important is the lack of looping over a number of Actions.

Lets take Ben Waldie’s Photoshop Actions as an example. His actions will either work on references to photoshop documents or the image files, and each action has the option of save and close. What he is trying to do here is get around one of the major weaknesses of Automator.

If you created an Automator workflow that scaled images, applied unsharp mask and then applied a brightness and contrast filter to each image all using photoshop. You would build the workflow by having a scale action, followed by a unsharp mask action, followed by a brightness and contrast action. You can then configure these actions to either save and close the file after each one, and the next action has to then open the file, or you can pass the photoshop document reference to the next action. Neither is a good solution, why?

If you save and close after each action is finished then the workflow is slowed down by each action having to open, do its thing then save and close the document. This is a significant hit on performance.

OK you say I wont save and close after each action is finished except for the last Photoshop action in the workflow. Think about this, Automator is about automated processing. Dealing with large number of files should not be a problem. If you don’t close those photoshop documents what happens when you dump a few thousand image files on your workflow. The first photoshop action in your workflow will attempt to leave a few thousand photoshop documents open. I think even the most maxed out Mac will grind to a halt as it runs out of memory when photoshop tries to deal with all these open documents.

Kevin

Funny Enough, I just watched Ben Waldie’s demo and then I came over here to pose the question about repeat loops.

I’m assuming Kevin’s comments are correct?

I haven’t had a chance to check out Automator yet, but this sounds like a bummer.

-N

If a coconut falls to the ground on a deserted island, does it still make a sound? It would work much better if the image did not need to be opened (in the GUI) but still have all the things happen to it, then save this data? If something is going to be automated, are you not setting up the workflow so that things happen when you are away from the computer? So yes you have to go the slow route.

Automator is for the person who has little tasks they do everyday. Tried using applescript. Got frustrated and gave up. The hardcore automation will still be for Applescript or some other kind of script language.

What will make Automator a success are the application developers writing Automator actions for their applications or allowing plug-ins for Automator to use in their applicaiton. Also, users, will make it a success by requesting actions that they can combine for a workflow. You are showing faith for innovation by having Automator actions available for your application. Automated Solutions, LLC. is doing the same for Adobe Products. No doubt the future will look good for developers to get fee based work for making Automator Actions/Plug-ins.

I responded to Ray’s post announcing Tiger’s release last month on this very subject. I thought Automator was attempting to replace AppleScript or offer an option to… not so. It really is more of a bridge for those who don’t know scripting but still want to take advantage of simple automation. Until they release “Automator AI” I say polish up on your syntax and BE THE BALL (or the coconut, whichever you prefer).
SC

Kevin,

I’ve been using and studying Automator for about six months now. First, let’s remember that Automator is designed to be the bottom end in poiwer and the high end in ease of use for a large number of scripting/programming tools available to the OS X user. We also have AppleScript, the shell, Perl, Python, Ruby and even Java and C++ all available. We also have applications with a fair amount of controllability. For example, the best way to process a thousand files in Photoshop is to start by writing an action inside Photoshop and then use use another tool to control Photoshop. This gets over both the shortcomings you discussed. The other thing to remember is that if you are going to be processing a thousand Photshop files it’s certainly worth spending an hour or even two writing custom PS actions and special AppleScripts to get your job done.

You also have to remember that Automator workflows can be run from within AppleScripts or shell scripts and an Action can use AppleScript and thefore call out to any of the other scripting languages. Therfore you can place decision making in one of the called out routines. You can also write a loop in something else and then call a workflow. I have a shell script that loops to call a workflow in which one of the actions is written in AppleScript and decides to call another workflow according to the output of the diff command.

So don’t diss a pocket knife for not being a power saw. Most of the people who live in MacScripter are going to be writing Actions rather than workflows.

Further, you won’t see the real power of Automator until most applications are pushing out Actions.

Finally, you can bet that the engineers responsible for Automator will be watching to see how people use their tool and any real shortcomings in the current version will not last long - having talked to some of them at conferences and tech briefings there are some exceptionally smart dudes behind the product.

Tony

Tony,

All I was wanting to do was supply some balance to some of the gushing reviews about Automator, I have yet to see a review that describes the limitations of Automator propertly. My comments are not about slamming Automator or condemning it to the wastebin. If something is hyped too much then users expect too much of it.

I wouldn’t have written 4 Automator Actions to use with iMagine Photo if I thought it was useless.

I still haven’t found a solution for the looping problem by just using actions.

The safe way (The way that wont bring your computer down) is to make sure that all files to be processed are opened, saved and closed within each action. If the files are left open then unless some limit on the maximum number of files is provided some user will try to use Automator to process large number of files in one go. For many applications like photoshop and iMagine Photo this will bring the computer to its knees when trying to process these files if the files are left open between actions.

But this is problematic for JPEG files because the image data will be repeatedly decompressed and recompressed gradually reducing the quality of the original image.

I cannot find a solution to this within the idea of keeping it simple within Automator, I can’t rely on all users choosing not to start the Automator workflow with a few hundred files or more.

Kevin

Browser: Safari 125.1
Operating System: Mac OS X (10.4)

Kevin,

Your comments are accurate and I do understand what You are after. And “flowcontrol” should be always in program- or in this case in action/workflowstructure when the action/workflow/process is done.

And what comes to JPEG´s, one can always make an action witch changes JPEG´s temporarely into TIFF format, do the magic gestures and changes TIFF´s back to UNCOMPRESSED JPEG´s (if possible) at the end. By trafficing TIFF´s You can use ICC-profiles for some specific magic also.

If You do ANYTHING to JPEG´s You have to save it at the end, so losing information is a disadvantage of using JPEG´s at “both ends of workflow”.

But oh hey, this is so me:

Space :smiley: