« | Home | »

We Need a Scripting User Interface Evangelist

I had an epiphany at this year’s WWDC while listening to John Geleynse’s User Interface design talk. We need someone to evangelize Scripting Interface Design with the same passion and clarity that John Geleynse brings to Graphical User Interface design on the Macintosh.

During the course of his talk John gave a compelling series of examples, tips and references that left me believing that I could improve the UI of my products, despite the small size of my organization. Even more importantly, he clearly demonstrated the difference between a good and a bad graphical user interface, and the consequences of bad User Interface design for the user.

Because this year’s WWDC was largely a repeat of last year, I spent more time in the introductory AppleScript, Automator and Cocoa Scripting sessions than I normally would. I left these sessions with the impression that developing a scripting interface was a difficult and error prone exercise. The Q&A questions at the end of these sessions confirmed for me that the audience was not clear on how to proceed. Everything that was said in these presentations was technically accurate, but I came away uninspired.

Interestingly, I believe that the issues John Geleynse so ably discussed (user centered design, identifying objects and tasks that matter to the user, knowing when to use certain widgets, etc.) are the very same issues that a Scripting User Interface designer must consider.

Several years ago, Cal Simone tried to fill this role. Cal and I differed on the specifics, but it has to be said that he was effective at motivating developers to “do the right thing”, and at keeping Apple focused on the problem. Since Cal left the scene, Apple has been left to do this for itself and it has not really risen to the challenge.

Scripting User Interface design is not about Cocoa, Cocoa Scripting, Objective-C, or even AppleScript. It’s about designing a programatic interface for an application that mirrors the user’s view of the application’s data model and functionality. Very often the user’s view of the application is not the same as how the application works internally.

There are features of Leopard that are going to make each application’s scripting user interface much more prominent (my NDA with Apple prevents me from giving specifics), and so this issue is going to become more important as time goes on.

Developing a Scripting User Interface is not that hard. I’ve built some large scripting interfaces over the years (Illustrator 7/8, Visualizer, Script Debugger 3, and now FaceSpan 5), and there is a method to it. But you need to approach it with as much care and forethought as you do with your Graphical User Interface design.

Apple’s Tech Note 2106 is a start, but it does not go far enough. This document is too much about code and not enough about process. For instance, It does not give a methodology for developing a scripting user interface.

Somehow developers need to be made to understand the why and the how of designing and implementing a compelling Scripting User Interface. As Brent Simmons once said, designing User Interfaces for the Mac is the “The Show”. If you are going to play, do it well.

Finally, I think Scripting User Interface design should be considered when scoring entrants in Apple’s Software Design Awards.


About this entry