Script Debugger 5 on Mark Alldritt

Script Debugger Pricing

Fri, 05 Dec 2014 14:24:27 -0700

A comment appeared on my Script Debugger 20th Anniversary post asking a question that has arisen many times over the years:

I don’t know how many times I’ve downloaded demos of SD over the years, but I’ve never actually jumped the hurdle of that $199 price tag to purchase it. I wouldn’t hesitate to pay $50 or so, and even with AppleScript getting less attention these days, I can’t believe I’m alone.

I’m not (just) complaining here, I’m really interested in your thinking in setting such a high price point. It’s hard to believe you wouldn’t have made more money over time if you were willing to target more casual scripters. Did you make a deliberate choice to cater only to the most hardcore and/or professional users, or was it really a profit-maximizing decision based on real market analysis? Or am I missing something? (Of course I understand that you put a lot of work into it and that the scripter universe is a relatively small market overall.)

I have resisted answering this type of question publicly because it seems like a no-win for me. Yes, Script Debugger is expensive. Yes, I could have lowered the price but I have not. Am I missing an opportunity - maybe - we’ll never know. I thought I would turn my response to this question into a post so it won’t be overlooked.

I see Script Debugger as a tool that makes professional developers money by saving them a lot of time. Those that really need Script Debugger know it and would pay much more because of this simple equation. In fact, if I had more courage I would raise the price even further.

The problem with the make-it-up-on-volume model is that the market for AppleScript tools (development tools in general) is very small and fragmented. I don’t believe that simply lowering the price by 3/4 on its own would generate 4x+ sales volume because I don’t think 4x+ customers ready to buy at $50 exist. I would have to market more to reach those customers that do exist and that costs. I would have to become involved in justifying and marketing AppleScript (as I once was) to create new customers which costs. Then there are the added costs of supporting a 4x+ user community. And finally, it lowers the perceived value of my software. I have developed many spreadsheets trying to model this over the years.

There is presently a rant raging on the AppleScript User’s mailing list regarding AppleScript’s future. It is clear that for those that have discovered AppleScript and tamed it, it is powerful weapon. However, the days of AppleScript being the only game in town (as it was before Mac OS X) are long gone. Many alternatives exist that better AppleScript in lots of ways. AppleScript remains the best tool for controlling scriptable Mac applications, but its a bear to master – hence the need for Script Debugger. Apple’s moves to improve AppleScrpt in Mavericks and Yosemite are somewhat encouraging. However, any marketing effort I might mount is never going to move the needle on AppleScript’s presence in the automation market place and Apple’s view of it. Apple’s priorities lie elsewhere so I’m not likely to get any cover from them.

As for maximizing profit, no. I’ve made a living over the years from Script Debugger, but its a base-hit at best. It makes enough money to keep me working on it, but not enough for me to retire or even hire any help. I could have earned more money from consulting but I enjoy being an indie developer and accept the financial consequences.

Back in the 1.0 days, we aggressively pursued sales volume. We had a lower price then, and signed up as many sales channels as we could. We purchased ads in MacTech and MacWorld. Our sales volume steadily rose, but our net revenue started to fall.

Script Debugger's 20th Anniversary

Thu, 04 Dec 2014 01:34:15 -0700

While I was distracted with my late wife’s illness, Script Debugger’s 20th anniversary came and went.

Script Debugger 1

Development on Script Debugger 1.0 started in 1993. Version 1.0 was released in late 1994 and was introduced publicly at MacWorld in San Francisco in January 1995. We shared a booth with FrontMost (later renamed FaceSpan) by Software Designs Unlimited.

Here’s how Script Debugger looked back then.

Interestingly, Script Debugger 1 may never have been a product. I was very uncertain about how to market and sell what was really a $129 piece of shareware. BBEdit was the only model of how this could be done by an independent developer. Remember, the Internet was not as it is today. Software was shrink wrapped in boxes containing floppy disks and printed manuals. It took serious cash to produce product. I had 2000 copies made at a cost of CDN$20,000 (1994 $s). The packing boxes filled an entire room in my basement. Software was sold through mail order outlets (MacTech, Apple’s Developer Central, and others) and trade shows like MacWorld and WWDC. The Mac had no presence in computer stores at that time.

I vividly recall standing outside the MacTech booth at WWDC 1995 in San Jose watching people walk up and purchase Script Debugger. I just could’t believe it was actually happening after all the work that had gone into getting those shrink-wrapped packages onto the MacTech shelves. I developed such an appreciation for how things as mundane as a can of soup get onto a store shelf.

Our daughter was born in 1995, and Gerry left her job to work full time with me. We were so naive. We had no idea what we were signing up for.

Script Debugger 2

Script Debugger 2.0 was introduced in 2000, and went on to win the Mac World Eddy for best development tool (we were up against BBEdit that year - I think Rich and the guys promised Gerry a bottle of champaign - I was at home looking after our 4 year old daughter). I was bummed because I later discovered the presenter that year was John de Lancie who played one of my favourite Star Trek Next Generation characters “Q”.

Here’s a little of how Script Debugger 2 looked at the time:

The big advancement in Script Debugger 2 was the object model explorer which let you see an application’s live scripting interface. This was huge at the time, and to this day, sets Script Debugger apart.

After Script Debugger 2 was released, Apple had its near death experience and our business simply stopped (literally went to zero) in the space of 3 weeks.

During the period that followed, we developed an Adobe Illustrator plugin that made Illustrator scriptable from the Mac with AppleScript and from Windows with Visual Basic. Adobe later purchased this code from us and this went on to form the genesis for the scriptability found in Illustrator, PhotoShop and Acrobat (InDesign had its own killer scripting implementation before we arrived on the scene). The product, named ScripZ, was demoed by Sal Soghoian at that year’s MacWorld Jobs led keynote. We were in meetings with Adobe to conclude the sale of the software right behind the black curtain beside the stage as the keynote was taking place - crazy.

Script Debugger 3

In 2002 we released Script Debugger 3.0. Script Debugger 3 had pretty much the same look and feel as 2.0. We went on to be the runner up for that years MacWorld Eddy for best development tool (I think CodeWarrior got it that year).

The big news for Script Debugger 3 was native Mac OS X support and the integration of our JavaScript scripting system into the product.

Script Debugger 4

In 2006, Script Debugger 4.0 was released. Script Debugger 4 became a Cocoa/Objective-C/C++ application (previously it was a THINK Class Library/C++ application) and received a UI overhaul which adopted the Mac OS X look and feel, and introduced concurrent script execution where scripts open in different windows could be debugged at the same time.

Script Debugger 4.5

Then in 2009 we released Script Debugger 4.5. Like Script Debugger 3, this was an evolutionary released which built on Script Debugger 4.

Script Debugger 5

And finally, in 2012 we released Script Debugger 5.0. Yet another UI overhaul. JavaScript was dropped (irony). Tabbed windows were introduced. Yet another rewrite of many internal components to make the product more maintainable and drop legacy Mac OS stuff, much dating back to the Classic Mac OS days.

Along the way there were other products: ScripZ (the Adobe Illustrator scriptability plugin acquired by Adobe), TagOn (an Adobe InDesign plugin for importing QuarkXPress documents), Affrus (A Perl IDE/Debugger) and of course the ill-fated FaceSpan 5. Then there were the freeware items: XML Tools, XSLT Tools, Plist Tools, Record and List Tools, JavaScript OSA and others I cant remember. All in all there have been more than 40 Script Debugger releases (major and maintenance releases).

While I did all the development on Script Debugger, it was not me alone. Gerry was there throughout the ups and downs running the business, executing the marketing and sales plans. She and I worked together in the same office for most of these 20 years. Matt Neuburg has been there throughout producing all our documentation (amazingly taking over from our first tech writer and creating the SD1 manual in 3 weeks!) and serving as my sounding board for so many years. Other lesser known individuals include Frances Hunter (she produced the original Script Debugger 1.0 printed manual), Lorin Rivers doing marketing and Bryan Bell did all the icons starting with Script Debugger 3. Adrian Ruigrok developed much of FaceSpan 5 and went on to work for Apple on some of the cool iThingies we all love today. And of course the invaluable support of other developers like Rich Siegel, Jon Pugh, Stephan Somogyi and many many others.

And finally, there are all the relationships that developed with customers through all these years, many dating back to the initial release of Script Debugger 1 (Shane, Ray, Jon, Chuck).

Wow, 20 years of my life involved in developing Script Debugger. My daughter is 19 now and attending college.

I hope I have all these dates more or less correct.

P.S. Here are some interesting facts:

The impetus for Script Debugger came from difficulty I experienced trying to automate Claris FileMaker and Claris MacProject Pro using Apple’s Script Editor. Oddly, these two Claris applications were very scriptable at that time.
Script Debugger 1.0 was developed on a Mac SE/30 with 4MB RAM using Think C
Script Debugger 1.0 easily fit on 1 800K floppy disk. Script Debugger 5 is a 14MB download.
Script Debugger was ported from Think C/TCL/C++/Classic Mac OS Toolbox to Symantec C++, then to CodeWarrior, then to Carbon on Mac OS X, then to Cocoa/Objective-C using Project Builder and now Xcode. Along the way, the TCL (Think Class Library) had to be ported to Carbon. Parts of the TCL are still in use in Script Debugger 5 (CFile/CResFile/CDataFile).
Script Debugger has out lived several of the products used to build it (THINK C, Symantec C++ and CodeWarrior). Only BBEdit continues to flourish.

Script Debugger 5.0 Released

Wed, 06 Jun 2012 11:54:48 -0700

I’m pleased to announce that I have finally completed Script Debugger 5.0. After an extremely long development period, it is finally done and I can take a breath.

A Better Text Find & Replace User Interface

Fri, 31 Dec 2010 16:20:24 -0700

I have never been happy with the Text Find & Replace panel in my applications (Script Debugger and Affrus). I started with a version of the Find panel that first appeared in Apple’s Text Edit and many other early Mac OS X applications. Here’s an example from the currently shipping version of Script Debugger 4.5:

The problem here is that the user has to switch their focus away from the text they are editing to the Find & Replace panel. They have to manage the Find panel window by summoning it, closing it, and moving it out of the way if the text they search for lies behind the window.

Then, Xcode came along with its Find & Replace panel integrated directly into the text editor window (similar to how Safari integrated its text search directly into the web browser window):

I came to admire this UI in my day-to-day development and copied it for Affrus 2. However, very quickly my Tech Writer and collaborator Matt Neuburg complained that he didn’t like it because he could not easily see or control the find options (Regular Expressions, Match Words, Ignore Case, etc.). I had a search field popup menu that provided access to these features, but it was not obvious and was clumsy to use. To solve this problem I expanded the inline find panel a little to make these options visible and easily changed. Here’s how this appears in Affrus 2 Alpha:

The problem here is that the inline Find & Replace panel is starting to use up too much valuable vertical space in the window and there are a lot of tightly packed small controls that are difficult to use.

As I was working on a related problem in Script Debugger 5, I came across an idea. Script Debugger 4.5’s dictionary window has a search field in its toolbar. This search field includes a popup menu where the user can control the scope of the search:

This UI was a total failure. The users who were lucky enough to discover these search options found the menu difficult to use as they had to make several trips through the menu to configure the search.

I came across Matt Gemmell’s MAAttachedWindow NSWindow implementation which gave me the idea of placing the search options in a window that only appears when keyboard focus is in the search field:

While I still am not totally happy with the popup window’s appearance and reability, its functionally is dramatically better than the Script Debugger 4.5 approach. The problem of users failing to discover these options totally goes away.

Applying this design to the inline Text Find & Replace, I came up with this:

This design seems to allow one to have a minimalist Find & Replace panel within an editing window while still offering a usable and discoverable range of search options to the user.

Script Debugger 5: Dictionary Redesign Prototype

Fri, 31 Dec 2010 14:01:41 -0700

I have been plugging away at a redesign of the Script Debugger 5 dictionary window, and by extension the value viewer that appears throughout the Script Debugger user interface.

The focus of the redesign is to remove the need for multiple windows unless you want them, to simplify navigation between dictionaries and through large dictionaries/object models, and to take better advantage of wide-screen displays. I’ve also tried to modernize Script Debugger’s appearance and make the presentation of dictionary information more consistent.

Rather than say too much more I’ll leave you to check out the screencast and just say that this is a very rough cut at what may or may not appear in Script Debugger 5. All icons are placeholders, etc, etc.

Best viewed full-screen at 720p

I realize that you may not be able to say too much without being able to actually use the software, but I’m very interested in feedback on the changes. In particular, are there obvious omissions/problems? Am I heading in the right direction or is this the wrong thing.

AppleScript Profiling

Wed, 27 May 2009 09:05:03 -0700

An Script Debugger feature that I’ve been pondering for a long time is a profiler. Given that Script Debugger’s debugger has the ability to track each statement executed, I can capture quite a bit of data about time spent in handlers, and even particular statements. I can also track AppleEvents back to the statement that initiated them.

A little bit of this information is presented in the existing Script Debugger interface. Firstly, the script timer (bottom of result drawer) displays the number of AppleEvents sent and breaks execution time down into time spent executing in AppleScript and time spent waiting for AppleEvents. The AppleEvent Log window’s contextual menu lets you go to the source statement that generated a particular AppleEvent.

My experience is that most AppleScript performance issues can be traced to inefficient sending of AppleEvents to other applications. As a result, my curiosity is in the tracking of events sent to other applications. But my usage patterns tend to avoid implementing anything but the most trivial algorithms in AppleScript due to its poor string handling and list performance. I also tend to avoid the use of script objects because of they are quite buggy in my experience.

Given all this, what are the questions you need an AppleScript Profiler to answer? Feel free to add a comment to this post or email me directly with your thoughts.