Smooth out the bumps in your workflow with desktop scripting tools

I love new software—when I order something new, such as the latest iLife suite, I eagerly check the UPS website to see if the package has been delivered, and I race home to try it out.

Of course, it is only a matter of days, or even hours, before the new glow has worn off and I begin to grouse about the things I wish they had done and I grumble about the nit-picky little bugs that are always there.

Even when the program works perfectly, we often want to use it in a work flow, using each program for what it does best.

Work flow is inherent in the kind of work that we do when scanning, indexing, searching, filing, tagging, and backing up all of our documents, photos, music, and video. Once you are committed to digital media, you will find that you often need to cobble together different programs in order to do away with some of the tedious manual labor.

Scripting tools can be as simple as macro recorders, as fancy as drag-and-drop pipelining tools, and as complex as full programming languages. Choose one that fits you and use it to bridge the gaps in your work flow.

An Example

I have never had a harsh thought about my sheet-fed scanner, the venerable ScanSnap S510m. But one thing has always annoyed me about the software package they provide: you can’t start scanning a new document until the OCR process is complete on the first.

What happens is this: you scan in a document; ScanSnap Manager receives it as a PDF and immediately passes it to Abbyy FineReader for OCR. All is good at this point.

But, the OCR process can take anywhere from 10 seconds to a few minutes, and if you were to scan in another document, FineReader complains:

This is where a little bit of AppleScript magic smoothed over this minor work flow annoyance.

I found that you can attach a bit of AppleScript as a “folder action” to a folder, and when a file appears in that folder, your AppleScript gets called. All I needed to do was figure out a way to get AppleScript to do the following:

• Wake up when a file appears
• Grab the first unprocessed PDF file
• Tell FineReader to start up, if it isn’t running
• Tell FineReader to open the file
• Wait for the processing to finish
• Go back to step 2 until all files are done.

It wasn’t exactly trivial—FineReader doesn’t actually have any special AppleScript support built in. But after a few experiments (i.e. a full weekend of fussing around) it was working smoothly.

Now I can scan as many documents as I want, knowing that OCR is happening at its own pace in a totally different flow.

Some day, when I have cleaned up the embarrassing bits of the code, I will share it here for fellow ScanSnap users.

What scripting tools are out there

The automation tools you use will depend on what software you are working with and what operating system you are using. On the Macintosh side, AppleScript and Automator will probably cover the bases. Things aren’t so pretty on the Windows side, but if you are willing to get a little dirty, Windows scripting can work miracles.

Whatever tool you use, I recommend finding as many simple examples on the Web as you can and running them and tweaking them slightly until you make them do what you want.

I am not an AppleScript programmer; I simply downloaded other people’s sample scripts that did file manipulations and poked and prodded them into shape.

AppleScript

In the Macintosh world, the old standby has always been AppleScript, with its quirky syntax that attempts to look like English. It is surprisingly easy to do some fairly heavy lifting with a minimal of effort.

In fact, though I find its syntax challenging and condescending at the same time, I heartily recommend AppleScript. The key is that Apple has built in AppleScript support to most of the main Macintosh applications.

For a taste of what AppleScript can do, here’s a whole mess of cool scripts for automating iTunes.

Imagine running a script that builds playlists for you or tags files automatically or finds duplicates and marks them.

This is the main AppleScript site, and here’s a tutorial from Apple.

Automator

Another Macintosh product, that provides a more graphical approach to hooking your apps together, is Automator. Here is an article that gives a good overview of the tool.

This is what a simple work flow looks like in designer mode:

You can see more or less what is going on here: You use a predefined set of actions, on the left side, to build up a pipeline on the right side.

In this case, the new automation action will get the selected documents, sort them, combine them into one PDF document, and then open that document in a PDF viewer.

I have always been a little confused with the utility of this product: it’s great if your application provides Automator actions, but what do you do if your app is like FineReader, with no special hooks built in?

Nevertheless, with Automator, you can do some pretty fancy things with many common tasks such as file management, email, and browsing. And there are plenty of custom Automator actions out there for the downloading.

Both Automator and AppleScript are Macintosh OS X built-ins.

For the serious Mac user, there is Bash Unix shell scripting, but that’s all I’m going to say about that. It’s there if you want it!

Windows Scripting

Things are somewhat different on the Windows side.

On the positive side, I believe that Microsoft’s COM object architecture makes it possible to script some pretty fancy things using off-the-shelf software.

In addition, the Office suite has amazing macro facilities that have been used by many as a full programming language, as the core of many successful commercial products.

But Windows just doesn’t seem to have anything analogous to AppleScript for gluing things together without getting your hands too dirty.

As a trivial example of the power of the Windows COM architecture, this short script will launch Excel, create a fresh spreadsheet, and automatically feed in some data. To try it out, save the script to your desktop and double click it.

This is what I saw on my machine when I ran the script:

Just like AppleScript on the Macintosh side, many Windows applications provide hooks for scripting.

The down side is that the scripting language is much more like a programming language, so it’s more comparable to writing shell scripts than to using a drag-and-drop automation tool like Automator.

But when you do the same thing over and over every day, it may be worth it to roll up your sleeves and get down and dirty with some VBScript.

An added benefit of this approach is that the language shares much of its functionality with Visual Basic for Applications, found in Word and Excel macros. If you are writing standalone Windows scripts, you can also write very complex Word and Excel macros. You also have the ability to do much of the same application automation within Word/Excel macros.

AutoIT

This is a freeware tool that many use for scripting their applications.

From the product website:

• Easy to learn BASIC-like syntax
• Simulate keystrokes and mouse movements
• Manipulate windows and processes
• Interact with all standard windows controls
• Scripts can be compiled into standalone executables
• Create Graphical User Interfaces (GUIs)

What more could you ask for?

Closing Thoughts

There are other tools out there; don’t be afraid to check them out and try some of the examples. If you can automate just one annoying task that you do every day, it may be worth the hassle of spending a weekend writing the script.

Epilogue

Yesterday at work I finally rolled up my sleeves at work to tackle a nagging document problem that had been lingering for months.

We have a large quantity of PowerPoint slide decks that have critical company information embedded within. I work in the pharmaceutical industry, so many of those PowerPoint slides had chemical structures for various drug molecules embedded within as OLE objects.

The problem was that we wanted to extract that knowledge (the molecule files) electronically and text mine the slides, but our tools did not support PowerPoint. They did, however, support Microsoft Word.

How could I convert the slides to Word documents? There are dozens of ways on the Net to go in the other direction, but the only way to do what I wanted resulted in the OLE objects being converted to pictures—no good for my purpose. I did find that a copy/paste of each molecule from PowerPoint to Word worked correctly, but who wants to do that by hand with hundreds of documents?

After weeks of trying to find a real Microsoft developer at work to do the task, I finally gave in and tried my hand using VBScript and the Windows Scripting Host. In four hours I had the basics of a script going.

My simple VBScript file does the following:

• Prompt the user for a PowerPoint file and target directory
• Launch PowerPoint and Word in the background
• Loop through every slide, inspecting any OLE objects found within to see if it was created by ChemDraw or IsisBase Sketch, two common chemistry editor tools
• If any such molecules are found, the following happens:
  • All of the “shapes” on the slide are copied to the clipboard
  • A new Word document is created with “Slide (1..n)” appended to the file name
  • The clipboard contents are pasted into the document

Sure, there are plenty of warts to work out, but I was happy to be able to run my script and watch as it magically consumed huge slide decks and spit out Word documents containing the exact data I was looking for. Windows Scripting Host is a powerful tool, as good as, if not better than AppleScript.

[Update: Added epilogue singing the joys of Windows Scripting Host]