Does Automator Add Anything to Scripting?

Having spent the last nine months getting up to speed again on AppleScript and learning a few shell script techniques, I’m wondering what Automator brings to the party. The question is really quite simple:

Does Automator make it possible to do things that AppleScript and Shell Scripts cannot do or does it just make some of those easier to do?

Hmm, I would posit that in and of itself, Automator today does not bring anything new to the table that couldn’t be accomplished through scripting alone. That said, Automator is marketed by Apple (something they never did for scripting which is a shame and a topic for a rant some other time) and, as such, it has a higher profile as being the easy way to automate your Mac.

With this higher profile, developers may be induced to create Automator actions for features of their applications that are not available through the application’s scripting API. So, depending on what third-party developers implement, Automator may create automation opportunities that scripting can’t match.

That said, scripting is so much more versatile and useful for larger scale inter-application workflows. I see Automator today similar to QuicKeys: it has a lot of quick hit benefits for users with nearly no learning curve but, to do truly impressive automated workflows, and to go beyond the basics, scripting is the way to go. Incidentally, scripting does not necessarily mean AppleScript as you can use other languages as part of the Open Scripting Architecture (OSA).

While I can see the appeal of Automator, I hope that it doesn’t drive developers to reduce their applications’ scriptability. This is actually the main reason I support MacScripter and the scripting community in general (code examples on my website, etc.): it is in my best interest for AppleScript to be more widely used to ensure that developers keep supporting it so that I can continue to automate the systems that are mission-critical to my livelihood (this is also why I find it so disheartening that AppleScript is, by all accounts, an orphan at Apple – every bit of my current income is directly related to my ability to automate my Mac through scripting). If you encounter a productivity application that isn’t scriptable or that only makes itself amenable to automation through Automator, I strongly encourage you to contact the developer to get them to add script support.

Jon

Extremely well said Jon, and I concur wholeheartedly. I noticed after putting together some workflows (trivial stuff) last night that I almost always had to revert to a little scripting (either AppleScript or Shell) to get at the system or, much more important, to make a decision and branch. As long as Automator (like QuicKeys whose branching ability is at best impaired) doesn’t include decent loop and if-then-else structures, scripting will always be required to do something meaningful.

Having said that, since Automator is quite easy to use for simple processes, it seems to me that it might actually encourage more scripting. As a QuicKeys user from day one years ago, I was appalled when QK made the transition to OS X as a shadow of its former self, and on discovering that I could embed scripts in my shortcuts, promptly took up AppleScripting after a long hiatus. Now, my few remaining QK shortcuts (most have been migrated to pure AS stored as scripts with hot keys under FastScripts) almost all contain AppleScripts and many of those embed "do shell script… " stuff as well.

I’m hopeful. For example, just as OXen have substanially extended the functionality of AppleScript to regions where nothing but a core language like C would accomplish the desired functionality or where the means of doing something in AS were clumsy and slow, I think there’s an opportunity here to develop AppleScript/Shell Script “tools” for use in Automator Workflows which unlike AppleScripts themselves can be saved as Finder plug-ins, for example.

Yesterday, for example, I found this on MacOSXhints: http://www.macosxhints.com/article.php?story=2005091721191684

Get Selected Finder Items
Run Shell Script -- see below for content
for i in "$@"; do if [ -d "$i" ]; then
  i="${i%/}"; f="${i##*/}"; p="${i%/*}"
  [[ "$f" = "$p" ]] && p="."
  [[ $f == *.fpbf ]] && n="${f%.fpbf}" || n="$f.fpbf"
  mv -v "$i" "$p/$n"
fi; done

Great little function: for a selected folder, running this (control-click on a selected folder because the workflow is saved as a Finder plug-in) it toggles the folder and its contents to burnable or normal (by adding or removing the .fpbf extension). Nice for backup to a DVD burner, no?

You’re asking the wrong question here. It’s not the “what” that’s significant, it’s the “how”.

Automator is essentially the GUI version of a traditional text-based command line. The original MacOS GUI replaced the CLI’s interactive functionality, but didn’t provide any equivalent to the CLI’s automated batch processing facilities. Automator addresses that original omission, albeit 20 years later.

Look at tools such as Automator and Quartz Composer, and one starts to wonder if Apple is developing an interest in the visual programming paradigm. Not that visual programming tools and languages are a new concept (even Apple have experimented with it before; see Cocoa, aka KidSim), but while visual programming has found some success in specialised markets (e.g. LabVIEW) or in limited form (e.g. HyperCard’s graphical stack editing tools) they’ve never managed to hit the big-time. Whether Apple is merely dabbling around the edges for fun or gradually laying the foundations for far bigger plans is anyone’s guess, but it will be interesting to see how things go.

As a frequent user of LabVIEW for machine controls and virtual instruments some years ago, I found that the visual paradigm was sometimes rather overworked and that using LabWindows as a GUI to some straightforward C programs was substantially more direct. From the perspective of Automator, the equivalent functionality is in the use of AppleScripts and Shell Scripts embedded in workflows and Automator provides the interfaces for doing just that.

Having said that, I certainly agree that it will be interesting to see how things go.

Indeed. But look at it from Apple’s point of view. They want to sell product (in this case computers). To do that, they need to add features that will appeal to lots and lots of people. Command lines and AppleScripts and shell scripts appeal to geeks, but that group is only a small part of Apple’s total audience. What can Apple do to add value for everyone else?

The traditional Mac GUI environment is good at enabling users to easily manipulate their data manually, but completely sucks for automating even simple tasks. As the amount of data increases, manual management becomes more onerous and the ability to automate becomes more valuable. The cost/benefit ratio of learning how to automate tasks via AppleScripts and shell scripts is too high for most folks, i.e. the amount of time and work saved in the long term isn’t worth the amount it’ll cost in the short term. However, if Apple can lower the cost of entry then more people will be willing and able to use it, and, hey-presto, they’ve added a brand new Unique Selling Point to their product; one more reason to buy a Mac.

Obviously, Automator wants to appeal to sections of the geek audience too, as a userbase containing a mix of experts and novices can support itself through mutual sharing of knowledge and code - and therefore thrive and grow - much better than an audience consisting of novices alone. But Automator is not about giving the geeks just one more fun toy to play with till they get bored and move onto the next shiny thing, it’s about giving all the non-geeks - who till now have been left in the cold - a chance to get their foot in the door at last. Just as AppleScript was the gateway drug for folks like me who were previously frightened off by rude, cryptic ‘Real Programming’ languages like C, Automator obviously hopes to do the same for folk for whom even AppleScript is too scary and intimidating.

For average users, the question is “How can I do X, Y or Z more easily?” For Apple, the question is “How can we enable average users to do X, Y or Z more easily, and therefore make them want to buy our product even more?” I think Automator is something of a test, to see if they’ve discovered a useful answer to that question or not. In technological terms it’s small potatoes when compared to the cutting edge research work in this field, but this is the first time the general principle of ‘non-programming’ programming has been tested right in the middle of the mainstream by a major commercial vendor. It’s a learning process for Apple too. Will it prove commercially valuable, or will it not? If it does, where could it lead next? If it doesn’t, what other avenues will they explore instead? Interesting times.

Very well said, Hamish.