autocratic for the people.

Automator for the People.

Automator is one of those OS X features that everybody likes but nobody uses. This seems to surprise pundits, but anyone familiar with the history of GUIs should've seen it coming; because at its core, Automator is just another well-meaning but disappointing attempt to provide a drag-and-drop interface to a programming language. There's a lot of spit and polish, sure, but in the end Automator is still programming .. but with a mouse.

The official explanation is of course more compelling: "In Automator, you create workflows to automate whatever task you need done. (...) You add actions in sequence to your workflow until you've outlined the steps needed to accomplish the tasks you want done." And that is certainly the case: Automator uses a linked-list metaphor in order to break a complex task into smaller steps. Here's a screenshot of an Automator workflow that performs a fairly complex task:


Example workflow


This workflow grabs the text from the web page I'm currently looking at, turns it into an audio file using text-to-speech, encodes it into AAC in iTunes, and syncs it to my iPod. Although I certainly agree that it's of borderline usefulness, this workflow nevertheless performs a pretty complex task – and I put it together from scratch in about two minutes just by dragging a bunch of actions into a list.

And that brings us to the big problem with Automator: the limited number of actions. Although most Apple applications include a wide variety of default actions, and although many third-party apps make an effort to at least provide some basic ones, the attitude for the most part is, "Well, if you need an action that isn't provided, you'll have to make it yourself."

As it turns out, I did need one that wasn't provided, so I decided to make it. And what an ordeal it was, because creating an Automator action is definitely not as easy as using one. To create one, you need to:


1. Lay out a custom UI



2. Write some Applescript



3. Edit the build target



4. Edit the metadata


And then compile the code. Assuming it all works, you then get to flip the build config to Release and actually create a usable Action.

This is ridiculous. It took twelve hours! This is how I'd expect developers to create actions, not users. And yet there it is, at the bottom of this page: "Expand your library by downloading new Actions from third-party developers or create your own using AppleScript." Yeah, right.

In contrast, another Tiger feature, Dashboard, also has a steep development learning curve, but that difficulty is being addressed in the next OS release through a combination of a dedicated development environment and a drag-and-drop method for end users. Totally cool, and totally worthwhile. It'd be great to see a similar set of apps for Automator, or even just a more approachable XCode template.

Automator's a good idea, but its utility is directly proportional to the number of actions available. Users will make this app their own once they can create their own actions. Make it happen, Apple.





*AppleScript, for the unfamiliar, is a lightweight programming language in OS X most often used to "glue" different programs together. Its main claim to fame, aside from its incredible usefulness, is its English-like syntax. Here's an actual line of AppleScript code: tell application "iTunes" to activate. Cool.

posted by avixe @ 11:15 PM