Feb 98 Viewpoint
Volume Number: 14
Issue Number: 2
Column Tag: Viewpoint
by Eric Gundrum
Scripting is Part of the Interface
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 )".
Talk to your Mac
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. ;-)
In This Issue
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.