Volume Number: 14 (1998)
Issue Number: 2
Column Tag: Viewpoint
by Eric Gundrum
Why do we need scripting languages? Why do we need more than one? I started working in the Mac industry years before we had AppleScript. Back then, a few of the more powerful Mac applications had their own built-in scripting languages, including the communications application I was working on. Then a scripting language was used to automate the internal functions of the application, freeing the user from having to watch over time-consuming tasks, or just assisting with mundane, repetitive work. We did not have anything like the shell script of Unix or the batch files of DOS to tie applications together.
With the release of System 7, AppleScript entered the scene. Apple had given us a very powerful core language, with all the essential decision and flow control features. Unfortunately, Apple's original release of AppleScript was seriously flawed. The underlying technology was great, but Apple didn't show us how best to use it. They were in such a hurry to get AppleScript out the door, that they hadn't had time to build it into the Finder. Developers often look to the Finder for ideas on how to best make use of Apple technologies, for better or worse. If we want an example of how the menus should look in an application, we look to the Finder. We do the same for ideas on the About box, Balloon Help and many other technologies. Apple did not provide developers with a rich example of how to implement a scripting interface to an application. Developers were slow to adopt AppleScript, and consequently, so were users.
Designing a clean scripting interface to an application is as important as designing a clean graphical interface to the application. Yet few developers are willing to invest even a tenth the time in the scripting interface that they invest in the graphical interface. Most scripting interfaces are implemented at the last minute, usually as the application is going to beta testers. By then there is not sufficient time in the development cycle to change the application to better support scripting. Furthermore, most scripting implementations are designed by programmers, usually with intimate knowledge of the inner workings of the application. They think in terms of the application's internal messages and data structures and figure they can use AppleScript to extend these to the user. Then the documentation folks have to figure out how to explain what the programmers mean by commands like "OpenConnectionToFTPServer( serverAddress, portNumber, showWindow )".
I prefer AppleScript because writing in the AppleScript language is like talking to my computer. Being the asocial geek that I am, I like the idea of my computer understanding me when I talk to it. When I can say things like "Computer, please tell the application "Finder" to open the window named "projects." Or, while in a QuickTime VR world: "Computer, pan left 90 degrees." This sure beats having to say "OpenFinderWindow( "projects" )". AppleScript provides a framework for communicating with applications this way.
The biggest mistake Apple made with AppleScript was in not giving developers the "Human Scriptability Guidelines," the AppleScript equivalent of the "Human Interface Guidelines." After all, AppleScript is an alternative interface to applications. For that interface to be easy to use, it must be well designed and consistent with other applications. We all know how much users benefit from consistency across applications. Many of us fought hard to convince unenlightened developers who, in the early days of the Mac, neglected to include an Edit menu, used the wrong command key for "Close Window," put the Preferences item in the wrong menu, or otherwise made mistakes in the interface. Making applications scriptable requires this same attention to detail, but the problems are more subtle, and the solutions less obvious. Without Apple's guidance, we are left to figure out for ourselves how best to design a scripting interface, and everyone designs a different look and feel.
In my experience designing the scripting interface before designing the code helps a lot. This way, you can factor your application, building in well defined objects that easily map to your scripting terminology. To help you design your terminology, start by talking to your computer; verbally direct your application to perform common tasks. Ask users familiar with what your application does to write the directions to common tasks as if they were directing a colleague to perform the task. These activities will help you identify the object that users think of when they perform these tasks. Those objects should be the main elements of your terminology. This will also help you think about all the features you must have in your application, and how to organize the underlying code. Then all you have to do is write it. ;-)
Two of the articles in this issue can help you design better scripting interfaces your applications. John Schettino's look at prototyping applications with FaceSpan provides suggestions on designing an application with scripting in mind. Cal Simone and Bill Cheeseman have designed a framework for judging just how scriptable is an application. Their article identifies the essential features of any scriptable application. You also will find articles about scripting environments other than AppleScript. In today's multi-platform world, Perl and tcl/tk are important technologies. In the past, the Macintosh versions of these tools have not kept up with their Unix counterparts. This is no longer a problem. As you will see from the articles, these Macintosh tools are very powerful.
