2853 words on X.4 Overview
I did some playing with Automator this weekend. And some working as well. I’ll try to sum up my first impressions here.
My view towards Automator – while being generally positive – is a split one. The one side is that I’ve been a big fan of AppleScript for years and Automator looks like it will widen the path that AppleScript lets us go. On the other hand, I was afraid that Automator coming into existence might mean that AppleScript might receive even less attention in the future than it had so far. I am happy to say that the latter point didn’t happen – at least technically – while the former hope seems to have become true to a reasonably large extent.
At first let’s look at Automator from a User’s perspective. Despite being technically minded, I feel capable of doing that. I am at least as easily confused by hard to use stuff as any other person. The first thing I saw of Automator is its icon. It’s a very clever one in that it manages at the same time to look like a robot holding a pipe, thus flirting with our Unix friends and technically describing what it does and to look like a sweet robot holding a bazooka, which together with the Terminator-esque name makes it seem both funny, effective and worth using – if only for a laugh. While it’s sweet, it seems to be a bit too clever to me.
Next comes the double click… and then a long wait. In a way I should have expected that, it’s an Apple 1.0 version after all and we should be used by them being really slow in their first two revisions at least. After the long wait we see an ugly metal window with clumsy and oversized toolbar buttons and the main UI. The UI is reasonably easy to understand – you can select actions, read their descriptions and drag them to the work area where you can set them up and rearrange them. The speed of this is very poor, though. When typing ‘pdf’ into the filter field, for example I’ll need to wait a whopping three seconds for the text to appear in the filter field and the listing to be filtered. With at most a few hundred strings being compared here, this is just a bad joke. But even if it weren’t, it makes the filter field quite annoying to use.
The same performance problems are there when rearranging actions. As far as I can tell, the different actions are supposed to move around to make space for the new action that you are dragging. When I do it, it sometimes happens immediately and sometimes happens slowly. To make things a bit more tricky, the items are sometimes dropped at the wrong location.
My Powerbook is quite slow by today’s standards. And while these effects may be less visible on the latest G5s, seeing them on my computer not only discourages me from using Automator but also suggests that Automator isn’t as well programmed as iTunes (which filters through thousands of songs in less than second) or the Dashboard (which slides around widgets just fine and even makes a slick transition animation when dragging them from the Dashboard Dock) when it comes to performance. I’m sure we’ll see performance improvements there with time but I’d rather have them come with X.4.1 than a few years down the road.
Even right out of the box, Automator knows many actions and I guess that many applications will bundle their own before long. Even in the initial setup it may be hard to find what you’re looking for, so the filter field is important for efficient usage of the Automator application.
And while I’m bitching, let me also mention that it’s driving me crazy that those little crosses in circles to delete actions from a workflow are on the right hand side of the action’s title. This is a Mac. They should be on the left. I keep clicking those useless numbers. And it also irritates me a lot that the actions keep changing their (apparently always non-alphabetical) order depending on what you do. That makes it hard to find things. They’ll need to find a better way of highlighting the recommended ones – perhaps by highlighting them? Finally, every new window will have the bar that splits the list of applications (with short names) from the list with the actions (with long names) right in the middle. So after waiting for an eternity until the window opens, I still have to move things around to make it usable… but back to actually using the Automator application:
Despite the large number of actions, I found it quite troublesome to use Automator so far. A few things I wanted to do couldn’t be done with Automator – e.g. getting the contents of a Safari window (the existing actions all seem to re-download the page and thus don’t work when you’re offline or the page isn’t re-loadable). And others couldn’t be done because Automator can only handle really simple processes: There seems to be no way to gather information from two different places and merge them in one of the actions. That’s a shame – probably a tradeoff made for UI simplicity.
After trying to come up with useful stuff to do with Automator for a while I didn’t find too many things. While Automator has the whole infrastructure there to create contextual menu entries in the Finder, to make little applications, PDF plugins and so forth, I couldn’t come up with too many things that’d really make it shine. Particularly things that I couldn’t have done with AppleScript as well.
I still came up with one useful action. It’s an action that I could have done with AppleScript as well. But it was much quicker to do with Automator. From time to time I download the web pages of my blog to my computer, so I can also reference them while I’m offline. I was really looking forward to X.4 and Spotlight for these as finally there would be a way to quickly search my old posts without needing Google. While I’ll still use Google while I’m online simply because it’s much faster and has a much better display than Spotlight, having a way to search them while being offline was great.Unfortunately, Spotlight didn’t find anything in those files. Quite disappointing. An while there seems to be no easy graphical way to find out what went wrong, a few commands in the Terminal clarified the situation: My files don’t have a file name extension. And the system doesn’t seem to make the effort to look into the file to determine their file type. Instead they’re getting fairly general UTIs for which there is no Spotlight importer. So, while this points at a few shortcomings of Spotlight, which I may discuss another day, at least I knew how to get my files index. Just add a daft ‘.html’ at the end of their filenames and they will be indexed.
As the files span a few folders and subfolders getting this right manually might have required some thinking (or knowledge of perl or something), but it was very easy in Automator. A little four step action consisting of
While I found this action very useful, I also thought it was ironic that the only good use I could find for the one new and exciting tool on the computer was a shortcoming of another new and exciting tool.
I also tried to make some actions for Automator. It’s not difficult to make a basic action but it’s quite messy. XCode has a template that sets everything up for you. Start with that and you’ll be fine, particularly if your action is written in AppleScript. Technically the actions are pretty sweet. They use all the good Cocoa stuff we’ve gotten to know and love. You set up the minimal UI for Automator and will automatically have the entered values thanks to Bindings. Like in AppleScript Studio you can also mix and match the use of Objective-C and AppleScript to get the most of it. This will let you use low level system functions for the hard work while driving the UI with some simple AppleScripts.
What I found quite tricky about making the actions is that there are little strings all over your project containing the action’s name. And if you happen to change that your project should have another name (e.g. after copying a finished project to re-use stuff in that one to create another action), you’ll have to track down all occurrences of the relevant string and change them. It’s in the property list, it’s in the build settings, it’s in the executable settings. And it’s quite annoying. Perhpaps someone can come up with an Automator action to do this for us (Perl scripts will be accepted as well).
The next annoyance is that to make the Automator action reasonably well documented you need to write quite a few strings. Those are pre-inserted into the plist and strings files for you but I find their order and arrangement quite irritating. Having a window with a nice setup to handle all of those strings (including notes to remind you what exactly they’re for and autofilling the values you’ve used in other projects) would be a great help. And while I’m at it, XCode should also give error messages if you’ve managed to have a typo in your manually edited property lists – that can cause quite irritating instances of things not working and I recommend TextExtras to do the checking in the meantime.
For a simple action, right now the effort of creating the action is so high that I’d say it’s not worth it. If Apple can reduce the effort needed to turn a working AppleScript into a working action, people will be much more likely to bother creating actions.
Looking beyond AppleScript actions there’s still the rest of Cocoa. While AppleScript actions may be nice for those who can’t handle AppleScript, I’m just fine making a little script for myself and running it. But with Cocoa coming into play, actions can be much more powerful than AppleScript. To check that I programmed a little action that takes PDF files from the workflow and two strings, the file’s author and its title and then used the new PDFKit to insert those into the file as PDF ‘tags’. Those ‘tags’ being in place means that Spotlight can index the file more specifically.
And, well, it works. At least on the Automator side. PDFKit seems to destroy the file’s table of contents when adding the tags, so it should be used with care if you want to preserve those. That’s a shame, particularly as those tags aren’t particularly hidden in the PDF files and I imagine that they should be quite easy to write. It looks like this may be solvable by looking right into Core Graphics, but getting into that may too much time to be worth doing it.
As I only noticed that shortcoming of the PDF writing later on, I also dug a bit deeper and made an action that gets the selection from Bibdesk and another one, mixing Cocoa and AppleScript, that changes the metadata of the PDF files belonging to the publications listed in Bibdesk according to what’s stored in the BibTeX file. And after a bit of trouble – and the almost non-debuggability of AppleScript when run from Automator – that worked as well, with the caveat of potentially destroying your files again.
My conclusion from these experiments is that there is real power in Automator, but that there are many things that can go wrong and make creating the actions a pain. In addition Apple should make the ‘overhead’ part of creating and managing the actions easier as well as Automator itself more convenient for developing actions, e.g. by not forcing you to quit and restart it all the time. It will also be interesting to watch what happens with regard to localisation. Apple seem to have made a great effort to localise all actions. Which is important if you want to get people to use things. Most other actions will not be localised to the same extent. So things will look quite messy for those not using English as their system language. (Hmmm, AppleScript started out with support for different languages as well – but that never happened…)
For my personal use, I’d be quite happy to use AppleScript myself and have the power of AppleScript Studio with the ability to use Objective-C classes right there in the Script Editor without the hassle of having to create and manage a project in XCode.
I’ll dump the results of my action coding in a folder on our server, so you can play around with it if you want to. No guarantees though, and the advice to back up your PDFs before manipulating them. If you find a way to solve the table of contents problem for the PDF files, please let me know.
So how is the public going to use Automator? I’m not sure. I fear that many people who don’t do scripting also won’t use Automator either. And looking around on the web, many actions that you see popping up seem to be quite simple jobs, sometimes just seeming to contain a single AppleScript command. While having these may be important for novice users who don’t know AppleScript, it may also end up cluttering up Automator’s reservoir of actions without adding significant new features. I.e. I am a bit sceptical whether things will end up all cool and useful.
If you – as a part of the public – want to enlighten me, then please show me a simple way to make an action that works as a Finder plugin and displays the metadata stored for the selected files. My idea was that this should be a simple Get Finder Selection → run shell command → display output job. But that so didn’t work that I ended up doing most of the job in AppleScript which still doesn’t work properly when used as a plugin.
While I’m writing on automation in OS X, let me mention AppleScript as well. It has been updated to version 1.10 with X.4 and there’s quite a long list of changes hidden in the release notes. Some cleaning up seems to have been done, particularly in the area of strings and the handling of Unicode. And the dialog boxes that can be displayed should conform to OS X HIG now. Unless I’ve missed it when reading the release notes there is still no built-in sorting and no improvement for the whole separating/creating strings to/from an array thing.
text item delimiters-Я-Us.
The browser for AppleScript dictionaries looks different now. It offers a number of options for viewing the dictionary – none of which I like too much – and has a filter field, which is very handy if you know what you’re looking for and just need to re-view the exact documentation of a command or a class.
And there’s the AppleScript Utility now which consolidates a couple of system-wide Apple-Script related options for you, so you don’t have to look for them in different places. To me this’d look much more natural as a preference pane, but perhaps it’s not mainstream enough. One thing the utility will do for you is activate the system-wide AppleScript menu. This has been around for ages, but it hasn’t been used enough. It’s a brilliant tool. Activate it and set it up to not display the Library scripts (they’re outdated and useless anyway).
Then go to the ‘Scripts’ subfolder of your personal library folder and create a folder called ‘Applications’. Inside that folder you can add other folders with the names of applications and the Script Menu will display the items in these folders in the Script Menu when that application is active. Some applications like iTunes or Mail bring their own Script menus. Usually you just need to move the contents of their scripts folder over to the new one and then their script menus won’t reappear the next time the application is launched.
This way you’ll always have the right scripts accessible in one and the same location. And with the Script Menu also being able to deal with aliases graciously, you can easily add the same script to several applications without having a management nightmare. In addition to AppleScripts, the menu will also execute shell or Perl scripts for you. And - to return to my original topic – Automator workflows.
What did you do in AppleScript or Automator? And what would you like to do with it?
Thanks for the analysis. I’ve also been a bit puzzled about who will actually use Automator. You also mention, though, that you don’t see what can be done with Automator that can’t be done with AppleScript. I think that’s the point of the application: it’s just an interface for generating AppleScript for people who don’t know AppleScript, so you wouldn’t expect it to open up features that AppleScript can’t handle.
I used Automator to create a Finder plugin to add files as attachments into a new email message. Something like this should be part of the OS, imho. I still wish that the Mac had a better way to do GUI scripting.
What the FUCK gobbedy-gook is your Mac speaking?
How delightfully ignorant - it’s called a ‘foreign language’ … in this case I believe it’s German, or another similiar linguistic tool. Much prettier than your crass response.
Although we may have German to thank for at least one of those words in the “crass response”.
I began to mess around with making an automator action as well. The most annoying aspect was easily the rather opaque plists. Using the plist editor as opposed to editing raw xml made the experience a little bit better.
Tim: Let’s see how that works out. I’m not sure that non-scripting people will bother with Automator for too long. Particularly as it never takes me long to run into a dead end where the Action you need just doesn’t exist. And then you’ll have to use an AppleScript action you insert yourself, which is both a bit messy, doesn’t work too well… and seems to be slower than using pure AppleScript.
Neema: I usually just drag files to the mail message window. It’s good enough for the file sending I do. There also seems to be an action that compresses a bunch of files before adding them to an e-mail message… (via a action list by Alf)
Yup, the language is German… didn’t want to change my system language for the screenshots. It’s not all that hard to understand anyway if you know the menus on your computer.
Gherrit: I’m not a big fan of the Property List Editor. It can’t even to copy and paste.
For your more powerful Automator actions, you may want to check out my Shellac product:
It’s basically a GUI wrapper around some popular UNIX commands. 1.1 and future versions will feature even more of these commands, suggestions are welcome!
Thanks for the review. I found Automator’s performance very slow too — even on a G5. Several actions don’t function as they’re supposed to. Rumour has it that 10.4.3 will fix some of these. Automator could become ‘Applescript for the rest of us’, but it’s first iteration is a little disappointing.
Received data seems to be invalid. The wanted file does probably not exist or the guys at last.fm changed something.