Rapid Prototyping
Volume Number: 14
Issue Number: 2
Column Tag: Programming Techniques
by John Schettino
An Object Oriented Approach to Using FaceSpan and
AppleScript to Prototype Applications
Software Development 101
Just the other day I read a posting to a Macintosh programmers news group that asked
a simple but powerful question. What design methodologies do most Macintosh
programmers use? As I stared at the phosphors of my monitor, I recalled my years of
formal study in Software Engineering. I learned all the state of the art (in the late
80s) software design methods when I was getting my Masters degree -- but what do I
actually use in practice?
The answer is a bit surprising. It turns out that I usually use a technique called either
incremental development or rapid prototyping. This approach relies on my own
expertise in ad-hoc design and the fact that I'm usually working alone on a project. It
doesn't hold up quite so well for large programmer teams. The basic idea is to quickly
implement a subset of the application, use it -- or better yet let the customer use it,
see what works and what doesn't, and then repeat the cycle. Each time through the cycle
refine:
• the requirements (what the application is supposed to do)
• the interface (how the application looks)
• the behavior (what the application does), and
• the design (how the application is structured)
For this approach to succeed, using tools that support very fast implementation of
successive versions of the prototype is critical. Discarding the prototype once it has
served its purpose is also critical. This prevents overattachment to the initial
version's implementation. It also keeps me from over-polishing the prototype! For
these reasons I've selected AppleScript and FaceSpan as my Rapid Prototyping
Environment.
The Tools
AppleScript is the Macintosh's bundled scripting language. It is a reasonable
programming language for prototyping, since it includes basic block-programming
constructs, subroutines, and several data types. It supports classes with data and
member functions, and fairly complex data structures. There is also a wide array of
scripting additions on the Internet that I use to round out the language. AppleScript is
close enough to Java, C, or C++ to allow me to re-implement the prototype in any of
those languages. It also reads a bit like psudocode so it can be used as a specification
language for the final implementation. The big plus for AppleScript is that it can call
on third-parties to perform complex tasks. That means databases, emailers, text
editors, and even the Finder can be called on to perform major portions of a prototyped
application. The big minus with AppleScript is that it completely lacks any
capabilities for interface creation.
FaceSpan is a product from Digital Technology International that works as an interface
tool with AppleScript or other OSA scripting languages, such as Frontier. Using
FaceSpan I can create interfaces for AppleScript prototypes. The interface consists of
several different styles of windows containing standard Macintosh interface elements. I
then attach scripts to the windows and elements to process the events they generate. All
the windows and scripts are contained in a single project file. I run the project within
the FaceSpan environment while I'm developing it. Once it is working correctly, I save
the project as a standard Macintosh executable file. In many ways it's simpler than it
sounds.
The combination of AppleScript and FaceSpan is similar to HyperCard with several key
advantages. Most important is the elimination of the Card/Background/Stack metaphor.
In FaceSpan each window and it's window items behave as a unit, with their own
message hierarchy. This yields "Mac-like" prototypes instead of "HyperCard-like
prototypes. FaceSpan also fully supports color, QuickTime, Drag and Drop, and other
key Mac technologies. It has a rich set of interface elements to choose from. I've done
pretty fancy interfaces with FaceSpan, creating and destroying window items on the
fly, implementing direct manipulation interfaces, and so on. Some of the more
interesting effects require a bit of script code, but at least that code is easily reused in
other projects.
The Method
I like methods. A method is a little less formal than a procedure. It is a general
description of the steps needed to get something done. If there is something in this
method that doesn't work for you, then just work around it. The primary reason I
develop a prototype is to refine my understanding of the application I'm creating. I also
use it to get end-user feedback early in the design and implementation process while it
is easy to make changes. The method I use to meet these goals with FaceSpan and
AppleScript is quite simple:
• First, create the static portions of the interface.
• Second, add enough AppleScript to animate the interface at the most basic
level.
• Finally, add more AppleScript to implement as much of the application
behavior as is needed for the prototype.
This three-step approach is not specific to FaceSpan and AppleScript. It's the same
method I use in any language. When using these tools it is just a lot faster to complete
each step. Depending on the goal of the prototype it is usually possible to stop before
completing all three steps. For example, a UI designer might simply want to draw a
possible interface and add a bit of AppleScript to animate it. The prototype could then
be handed over to users and its usability could be assessed.
Drawing Interfaces in FaceSpan
Begin with whatever you know about the desired application's look and behavior and
start creating windows in FaceSpan. This is a good time to review the Macintosh Human
Interface Guidelines, also known as the human-computer interface (HCI) guidelines.
I'm a big fan of following these, because applications that follow the guidelines are
easier for users to learn and use. The FaceSpan Window Editor is a great environment
to experiment with different layouts, but even more so, it's a place where the
developer can see first hand the effects of following (or ignoring) the HCI guidelines.
Here's a simple example. There are detailed rules for laying out the elements of a
modal dialog box. The first dialog box below follows these rules to the letter, the second
does not.
Figure 1. Conforming and Non-conforming dialog boxes.
Although the two contain the same buttons, the first conforms to the HCI guidelines.
The default push button is in the right location, there is a correct amount of white
space between the window items and the window border, and the icon is placed
correctly. The result is a dialog box that is instantly recognizable to a Mac user.
FaceSpan encourages this type of consistency throughout the application, but it by no
means enforces it.
FaceSpan's Window Editor creates three different types of windows. Document windows
are used for main windows. They can be resizable, closeable, and zoomable. Their
optional titles are distinct from their name, as used in scripts. Modal windows can be
titled or untitled and, unlike Document windows, must be closed before any other
windows can receive events. The last window type is floating Windoid. These are
windows that float on top of all Document windows. They are usually used for tool
palettes.
A window contains zero or more window items. The upper limit of window items is
330. There are 14 different types of window items, and these types are further
customizable using Forms. For example, the Button window item can have either a
standard or a 3-D visual representation.
The Window Editor consists of a pair of tool palettes. The window under construction is
displayed almost exactly as it will appear. New window items can be dragged onto the
window, or drawn on the window. Window items have several properties that control
their behavior. For example the visible and enabled properties determine if a
particular window item is visible, and usable. If its enable property is false, it
displays in a grayed-out style.
Figure 2. The FaceSpan Window Editor.
Figure 2 shows a complex preferences Modal window in FaceSpan's window editor.
This window uses several window items, including labels, textboxes, boxes,
checkboxes, and buttons (called push buttons by FaceSpan.)
In addition to the window editor, an application has full control over the menu bar.
Basic menu capabilities are supported, as well as limited (single level) hierarchical
menus. The menu bar support is the weakest portion of FaceSpan. Applications can
have only a single menu item in the Apple menu and have no access to the Help menu.
Animating the Interface