Scripting for Lawyers > Timeline

In my last post, I promised an example of a script that uses rb-appscript instead of AppleScript. Well, remember that screencast that showed how to add events to Timeline? I wrote that script in rb-appscript.  Click here for the script.

I chose Ruby for this script instead of AppleScript because Ruby processes text much more efficiently than AppleScript. In this example, I ask the user to choose a data file, then I use a third-party library (FasterCSV) to parse the data file line-by-line. For each line, I add an event to my timeline.

I also chose Ruby because the syntax is much more concise. To process text in AppleScript, you typically have to write several more lines of code than with Ruby or another language. This can lead to considerable time savings while developing a script.I note that this script is not complete. I need to add better error handling and I’d also like to check each line for data consistency. But for demonstration purposes, this script works.

I’d like to hear your comments about moving forward with Ruby or sticking with AppleScript as our scripting language of choice. I’ve heard from a few people and the vote is split. One advantage of sticking with AppleScript is the large amount of existing scripts floating out there for you to examine and learn from. Because rb-appscript is relatively new (but very mature as it’s built on top of Apple Events), the number of existing scripts is small compared to AppleScript. Just another thing to think about before we move forward. 

Before we get to our first script, I thought that I’d post a quick screencast of a script in action. This screencast shows some of the power of scripting. In the screencast, I grab some data from a text file, parse that data, then send the data to Timeline to create a beautiful timeline.

Click here to view the screencast

As you can see, I’ve used this script to create a timeline of events in a litigation context. In this case, I used a simple text file as my data source, but you could also use a database like FileMaker Pro or a spreadsheet like Microsoft Excel to hold your data. (Not that there’s anything wrong with plain text, mind you.) More importantly, however, I saved valuable time by not having to enter the data twice–once into my data source and again into Timeline. And I can use the script over and over again, saving more time every time I use the script. I timed the script execution to around 2 seconds. I then manually entered the events to create the timeline and finished in 240 seconds. Every time I use this script, then, I save almost four minutes of my time. This is the power of scripting.

On to our first script!

Open Script Editor and type the following text into the editor pane:

say "Hello from AppleScript!"

Now click the “Run” button or press Command+R. You should have seen the text change color and then you should have heard your computer speak the words, “Hello from AppleScript”. Cool!

So what happened? When you clicked the “Run” button, Script Editor secretly compiled the program first. When Script Editor compiles a program, it checks for errors in your code, then converts your code to machine code for the computer to read. Here, the translated code sent a command—the “say” command—to the computer along with an argument for the command—the text string “Hello from AppleScript—and the computer obeyed your command and said the words, “Hello from AppleScript”. The key lesson to remember is that, in AppleScript, you “tell” your applications to do things using “commands”. Who’s the boss, now?

How do you know what commands you can send to an application? For that you need to know about AppleScript dictionaries, the subject of the next post.