Every system administrator deals with repetition. There are certain tasks I do every day, over and over, mostly with little change. So like most of my compatriots, I've become adept at automating. Life is too short to sit there and do the same things over and over—mindless repetition is a mind-killer. Over the years, I've learned that automation is valuable in almost any application. And these days, I get extremely annoyed when I see things that aren't easily automatable.

If an app doesn't have built-in automation options, it tells me that the developers are somewhat short-sighted—if not outright lazy. Automation allows an application or service to be extended; it creates functionality that wouldn't exist otherwise. It gives the people buying and using an app the ability to not only solve problems themselves but to figure out things that the dev didn't think of during development. After all, a dev and a user are different people with different brains looking at things through different eyes. To put it bluntly, a lack of automation tells me that the dev has little respect for their customers' time. They don't see a problem in making someone do the same task over and over for as long as that person uses the application.

Four letters save tons of time

Let's look at the first benefit of automation—extending existing functionality. One of the things that a good automation implementation does is give the user of the application the ability to do things that the dev may not consider important. Every developer has to make choices about what their app will and won't do. But if we aren't restricted to just the UI, we suddenly have options. Consider the Apple Mail of the past and its rather bizarre inability to import its own data. Prior to Mountain Lion (or possibly even Lion, and in Snow Leopard for sure), the individual message files for an IMAP account cache were labeled as .imapmbox files. That's not a big deal in and of itself, but it meant that importing this data back into Mail was rather difficult to do in large quantities. (This makes no sense to me, either. I cannot for the life of me imagine the logic in an application that cannot import its own data. But that's Mail for you.)

This isn't something you run into a lot, but let's say that you're changing mail services. Even if both your new and old service supports IMAP, the sheer size of most people's mail stores and the slow nature of IMAP to IMAP copies makes "just doing an IMAP copy" a losing proposition. Other factors can limit things further—the new mail service could be a hosted service (like Gmail) where you have no direct access to the server. So much for just copying the mail store from server A to server B.

In this situation, it is an option to take the existing IMAP cache and import it locally—just not by copying it from the server, because that would take a lot of time. You could yank the IMAP cache and reimport it locally, and while it would take some space, it would be temporary. The IMAP cache could be deleted once the import is done, and—because this would happen at hard drive rather than network speeds—it would take less time. Significantly less time.

Clearly, this is not a use case Mail's devs thought of, because that's why you use IMAP, right? If you need it, you just get it from the server. It's when you have a case of "the server is going away" that suddenly this limitation becomes a pain. In trying to solve this problem, I looked at Mail's AppleScript implementation, but I couldn't get it done with that. I poked around a bit more and realized that the only "difference" between .imapmbox files and .mbox files was "imap." Score— things became easy.

The solution begins by writing a script that takes the unix find command to build a list of paths to every .imapmbox file in a folder. You then pass that list to the Finder and use a line of AppleScript to change the filename extensions. The time to process thousands of e-mails in different folders? Seconds. Thanks to automation in other apps, the limitations of Mail (eventually fixed starting with Lion) were no longer any kind of problem.

Turning the page(s)

OK, the Mail example doesn't really count. The problem has been resolved and I was automating around Mail, not using Mail's automation capabilities directly. Let's look at another example. For whatever reason, I prefer Outlook 2011 to Mail. But I also really like using Pages for most of my word processing needs. While Pages is quite good at sending things via Mail (as in Mail.app), it's not so good at using a different e-mail application. However, thanks to a solid scripting implementation in Pages, that limitation disappears.

When I'm writing a document I know I'm going to want to e-mail as a PDF via Outlook, the fact that Pages doesn't directly support this functionality in the UI means nothing to me. I have a script that converts the current document to a PDF and opens a new e-mail message in Outlook with that PDF file as an attachment. Apple may one day implement better e-mail client support in Pages, but it may not. The point is that I don't have to care. As long as Apple maintains the automation features of Pages, the number of e-mail clients it directly supports can be anywhere from zero to "all of them." I've already routed around the problem.

Pages is nicer than Word for simple documents like invoices; it's also scriptable. This lets me create a rather nice workflow that I use for invoicing sponsors of my podcast, "Angry Mac Bastards." I have an AppleScript-based service that presents me with a list of current sponsors. I select the one I'm invoicing and the service opens up a new document in Pages based on the invoice template. It autofills the sponsor data into the correct text box. All I have to do is make sure the amounts, period being invoiced, and invoice number are correct, and I'm done. I save the document and run another script that creates a PDF version of the Pages file. This action also opens up a new outgoing message in Outlook for me with the invoice as an attachment. I type a few lines to personalize it and hit send.

For any given invoice, this process saves me a few minutes. But over the course of a year, for invoice after invoice, that time adds up. Instead of me doing the busywork, I'm letting the computer do it for me. I only get involved where appropriate. I'm a fan of Pages because of its scriptability and ease of use for simple documents. In fact, were Pages not scriptable, I'd convert all my Pages scripts to Word and stop using Pages altogether. I have things to do that don't involve hoping a developer decides my feature request is important enough to implement.