I am a self-funded Indie (lone) developer. I made a number of classic business blunders on the FaceSpan 5 project. I broke the golden rule: never (never!) rewrite a software product. I massively underestimated the effort required to complete the product. I set off without having sufficient resources to complete the project. Because I took so long to complete my work, the market moved on — AppleScript’s importance to the customers I intended to target declined. Some may argue that the market was never really there to provide a return for a product of this complexity. Finally, I didn’t pull the plug soon enough. Hindsight its great.

Not all was lost. Some of the code I developed for FaceSpan 5 found a home in Script Debugger 5.

A Little History

Many years previously I developed FaceSpan 3 under contract for its owner. As part of that effort I became impressed with FaceSpan’s power and simplicity. FaceSpan 3 was successful, for a development tool, and even received an Apple Design Award at that year’s Worldwide Developers Conference. Sadly, after my involvement with the product ended, FaceSpan fell into disrepair and did not make the leap to Mac OS X. FaceSpan’s developer finally produced FaceSpan 4 which was to little to late and not as successful as hoped for.

I acquired FaceSpan 4 in 2006 and, after a period where I tried to fix the most serious issues with the product, I concluded that FaceSpan 4′s dependance on AppleScript Studio was its core problem. FaceSpan 4 had great integration of a visual UI bilder and coder editor, but lacked a good runtime environment and debugging.

Work on FaceSpan 5 began in 2007 with the aim of freeing FaceSpan from AppleScript Studio and restoring the classic FaceSpan’s attractiveness. By the time I stopped FaceSpan’s development I believe I was well on my way to achieving my aims. Two great Mac developers helped me with the project:

• Adrian Ruigrok, who now works for Apple, developed much of the FaceSpan 5 IDE code.
• Matt Neuburg acted as a sounding board for my ideas and developed the initial FaceSpan 5 documentation.

The project turned out to be too ambitious given my resources. Additionally, FaceSpan revealed a number of AppleScript issues and problems in Apple’s Cocoa Scripting framework which I was ultimately unable to overcome.

What Is (Was) FaceSpan?

FaceSpan 5 was an integrate tool for building Cocoa applications using AppleScript. Many people saw similarities to Apple’s HyperCard. FaceSpan provided a visual UI builder, an AppleScript editor, an AppleScript debugger and a runtime environment designed to take the best advantage of AppleScript’s strengths and provide a collection services and UI widgets out of which applications can be built. Matt wrote this description of FaceSpan 5 back when the project was active.

The FaceSpan 5 runtime environment wrapped Apple’s Cocoa Frameworks in a sanitized and simplified AppleScript focused programming interface. This allowed one to build fully Cocoa-native applications using AppleScript without having to learn anything about Cocoa. The intent was for Cocoa to be an implementation detail rather than the programming interface.

We’ll never know if the FaceSpan 5 approach was actually better than the AppleScript Studio interface offered by Apple. My hope was that FaceSpan’s approach was actually simpler, and not simply a substitution of one complicated programming interface for another.

Since FaceSpan 5 was abandoned there have been several developments in the area of AppleScript GUI tools. Firstly, Apple transitioned from AppleScript Studio to AppleScriptObjC. Shane Stanley has released his ASObjC Runner which can display progress dialogs. And then there is the long lived Appearance OSAX from 24U Software.

The Last Build

When I stopped developing FaceSpan 5, a lot of people came out of the woodwork looking for a copy of the software. I was not willing to make the software available at that time, but I am now. I’m doing this now because I think it might be interesting for those of you who were/are curious about what I was working on to get a chance to play with the product.

Keep in mind that this build predates the release of Xcode 4 and there are some interesting similarities. Apple had to be developing parts of Xcode 4 during the same period so its fascinating to me how common ideas arrise in different places.

Before you download the software, please keep the following conditions in mind:

• This is Alpha-Stage software. This means that it is buggy and its not feature or UI complete. Expect it to crash and fail. If you stick to the examples included with the documentation, you should be okay.
• THE FACESPAN SOFTWARE IS PROVIDED AS-IS FOR EVALUATION PURPOSES ONLY. USE AT YOUR OWN RISK.
• PLEASE DO NOT FILE BUG REPORTS. I’m not going to produce another build.
• PLEASE DO NOT ASK ME TO OPEN SOURCE THE PROJECT. This product shares a lot of code with my Script Debugger product and I’m not willing to release the code.
• RTFM. Seriously, you are on your own.
• The software should run on Snow Leopard (10.6) or Lion (10.7). I have no idea if it will work on Mountain Lion (10.8) or beyond.

View Matt Neuburg’s Alpha Documentation. More FaceSpan 5 information and screencasts.

Download FaceSpan 5.0.

FaceSpan 5 Blog Posts.

To get you going, check out this post: Dock Icon Changer.

Have Fun!

For v2, I added the conversion to grayscale. I took this opportunity to add a Settings menu to the app’s Action Bar which toggles between Color and Grayscale display. Finally, I found that I needed to retain the Color/Grayscale setting in the app’s preferences so I added that as well.

You can download the source code for this application here:

PolaroidII.zip

I came across the Premium Pixels site which offers a series of attractive free UI design elements. I decided to start with their Pretty Polaroids example and try and implement it as an Adroid application.

This sample Android application allowed me to experiment with the android.graphics objects.

Here’s how the Premium Pixels UI mockup looks:

Here’s how my Android implementation of this UI turned out:

You can download the source code for this application here:

Polaroid.zip

Downlaod TimePicker.zip

This project is an attempt to implement David Cristian‘s Hour Picker UI design (which I found via UI Parade) as a Cocoa View. Here is how David’s UI mockup appears:

When I first saw this UI design I found it visually compelling, and it really seems like a nice solution to the problem of allowing the user to quickly pick periods of time in 1/2 hour increments. When I began turning it into a functional UI a number of issues concerning how users interact with the UI begin to surface:

1. This mockup shows only 6 hours. The UI needs to scroll in order to show the full 24-hour day.
2. I chose only to implement click and drag to select time ranges. I imagine that shift-clicking might be desirable. I didn’t attempt to handle keyboard input.
3. At first I though the 1/2 hour grid was self evident. However, when I began using the UI, I decided I needed duration feedback while dragging to know exactly how long the selected period is.

Here’s how my implementation looks while the user is dragging the mouse:

There are limitations to this UI:

1. Time can only be selected in 1/2 hour increments.
2. Time can only be selected within a single 24-hour day.
3. Auto-scrolling while dragging is problematic. It may be that auto-scrolling needs to slow down, or more rows need to be made visible in the scroll view.

Requirements

The project requires Xcode 4.2, and the Mac OS X 10.7 SDK.

Download

Release Notes

Among the changes in the Script Debugger 4.5.7 maintenance release is a fix for crashing bug when opening or creating documents on Mac OS X 10.7 (Lion).

A big thank you to all the folks who downloaded the various Script Debugger 4.5.7 Beta builds. I really appreciate all the great feedback and bug reports I received.

UPDATE: Script Debugger 4.5.7 has been released.

As was the case with Script Debugger 4.5.5 and 4.5.6, I am struggling to resolve some stability problems that appeared following the release of Mac OS X 10.6 (Snow Leopard). Resolving these issues has been very difficult as I am not been able to reproduce the crashes on my own systems.

To help me determine if I’ve resolved the stability issues (or at least improved things), please allow Script Debugger to submit ALL crash reports. I know that this may slow you down a little, but it will help me as I work to resolve the stability problems.

Requirements

• A Script Debugger 4.5 registration number
• Intel or PowerPC Macintosh
• Mac OS X 10.6, 10.5, 10.4

Download

Script Debugger 4.5.7b4 (12MB)

Installation

• Quit Script Debugger if it is running
• Mount the ScriptDebugger4.5.7 disk image
• Copy the Script Debugger 4.5 application from the disk image to your Applications folder (or any other place on your disk)
• Restart your Macintosh to ensure all caches are flushed

I recommend keeping your copy of Script Debugger 4.5.6 around in case you need to revert to that build. Note also that this BETA build expires on October 1, 2011.

Script Debugger 4.5.7b4 Changes

• 15112 [Crash] Script Debugger co-exists with installations of the forthcoming Script Debugger 5.0.
• 15101 [Crash] Script Debugger no longer crashes when creating new documents on Lion (Mac OS X 10.7).

Script Debugger 4.5.7b3 Changes

• 15108 Addressed a problem where the Dictionary/Explorer control in the Dictionary window was not updated to ‘Dictionary’ following a search.
• 14862 Added support for ASObjC scripts by allowing ‘class “ClassName”‘ constructs to compile.

Script Debugger 4.5.7b2 Changes

UPDATE: Script Debugger 4.5.7 has been released.

As was the case with Script Debugger 4.5.5 and 4.5.6, I am struggling to resolve some stability problems that appeared following the release of Mac OS X 10.6 (Snow Leopard). Resolving these issues has been very difficult as I am not been able to reproduce the crashes on my own systems. The Script Debugger 4.5.7b2 build addresses some additional problems that I hope will further improve stability.

To help me determine if I’ve resolved the stability issues (or at least improved things), please allow Script Debugger to submit ALL crash reports. I know that this may slow you down a little, but it will help me as I work to finally resolve the stability problems.

Requirements

• A Script Debugger 4.5 registration number
• Intel or PowerPC Macintosh
• Mac OS X 10.6, 10.5, 10.4

Download

Script Debugger 4.5.7b2 (12MB)

Installation

• Quit Script Debugger if it is running
• Mount the ScriptDebugger4.5.7 disk image
• Copy the Script Debugger 4.5 application from the disk image to your Applications folder (or any other place on your disk)
• Restart your Macintosh to ensure all caches are flushed

I recommend keeping your copy of Script Debugger 4.5.6 around in case you need to revert to that build. Note also that this BETA build expires on July 1, 2011.

Script Debugger 4.5.7b2 Changes

• 15107 Script Debugger no longer attempts to compile scripts when saving changes to an existing Text (.applescript) document.
• 15106 Script Debugger no longer causes AppleScript to convert “reference” to “specifier” when compiling scripts.
• 14862 Added support for ASObjC scripts by allowing ‘class “ClassName”‘ constructs to compile.

Script Debugger 4.5.7b1 Changes

UPDATE: Script Debugger 4.5.7 has been released.

As was the case with Script Debugger 4.5.5 and 4.5.6, I am struggling to resolve some stability problems that appeared following the release of Mac OS X 10.6 (Snow Leopard). Resolving these issues has been very difficult as I am not been able to reproduce the crashes on my own systems. The Script Debugger 4.5.7b1 build addresses some additional problems that I hope will further improve stability.

To help me determine if I’ve resolved the stability issues (or at least improved things), please allow Script Debugger to submit ALL crash reports. I know that this may slow you down a little, but it will help me as I work to finally resolve the stability problems.

Requirements

• A Script Debugger 4.5 registration number
• Intel or PowerPC Macintosh
• Mac OS X 10.6, 10.5, 10.4

Download

no longer available

Installation

• Quit Script Debugger if it is running
• Mount the ScriptDebugger4.5.7 disk image
• Copy the Script Debugger 4.5 application from the disk image to your Applications folder (or any other place on your disk)
• Restart your Macintosh to ensure all caches are flushed

I recommend keeping your copy of Script Debugger 4.5.6 around in case you need to revert to that build. Note also that this BETA build expires on May 1, 2011.

Script Debugger 4.5.7b1 Changes

• 15090 [CRASH] Resolved a bug in the Balance command that could result in crashes if compound AppleScript statements (tell x to y, if x then y) appear within a block style comment.
• 15094 [CRASH] Another attempt to resolve the intermittent crashes which began with the release of Mac OS X 10.6 (Snow Leopard).
• 15093 Resolved a problem where the Dictionary window fails to display dictionary descriptions for multiple items selected from the browser.
• 15092 Resolved a problem where application bundles saved as 32-bit appear as PowerPC applications in the Finder.
• 15091 Fixed a typo in the property definition clipping.

Shane’s book has become the most comprehensive documentation for AppleScriptObjC available. If you are attempting to use AppleScriptObjC to put a User Interface around your AppleScript code, this is a resource you must look into.

Part of the problem is that you cannot easily use an NSBrowser delegate if you are also using bindings and an NSTreeController to drive the browser (at least on Mac OS X 10.6). For instance, you are prevented from using the -[NSBrowser browser:willDisplayCell:atRow:row column:column] delegate method to customize the cell presentation as you might do in an NSTableView or NSOutlineView.

I worked around this problem using a custome cell approach. When you bind the Browser’s Content Values binding to the NSTreeController, NSTreeController calls the browser cell’s setObjectValue: method. If you subclass NSBrowserCell and override setObjectValue:, you can assign the cell’s text and image. Here’s my NSBrowserCell subclass:

@interface MyBrowserCell : NSBrowserCell { }

- (void) setObjectValue:(id) value;

@end

@implementation MyBrowserCell

- (void) setObjectValue:(id) value {
    if ([value isKindOfClass:[NSDictionary class]]) {
        [self setStringValue:[value valueForKey:@"name"]];
        [self setImage:[value valueForKey:@"image"]];
    }
    else
        [super setObjectValue:value];
}

@end

Next, you need to configure the NSBrowser to use this cell. The simplest way to accomplish this is with NSBrowser’s setCellClass: method:

[browserView setCellClass:[MyBrowserCell class]];

Finally, you need to make your bindings model return a value that’s appropriate for MyBrowserCell. Here’s my nodel’s value getter method which is bound to the NSBrowser Content Values binding:

- (id) browserValue {
    return [NSDictionary dictionaryWithObjectsAndKeys:
                            [self browserName], @"name",
                            [self browserImage], @"image",
                            nil];
}

Note that you’ll need to make sure that will/didChangeValueForKey messages are sent for browserValue when browserName or browserImage change.

Here’s the result in my application: