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.
Totally agreed. I wrote about this in a similar way last year:
http://www.red-sweater.com/blog/195/we-need-a-hero
Is this where we nominate you, or the esteemed Bill Cheeseman?
“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)”
Don’t worry, Mark, Apple have already publically indicated that they’re pushing Scripting Bridge for ObjC, Python and Ruby:
http://developer.apple.com/leopard/overview/apptech.html http://www.apple.com/macosx/leopard/technology/unix.html
so as long as you don’t discuss details you’ll be fine.
I absolutely agree that Apple needs a full-time scripting interface design guru to provide advice and education to application developers, not least Apple’s own. e.g. I just posted criticisms of Safari 3’s new object model over on AppleScript users (starting here) – a really, really basic design problem which they’ve had years to work on, and they still manage to flub it. And if developers can’t get a simple relationship structure like that right, what hope for more complex applications?
I think there are two issues here:
Even having someone available online to go through the proposed dictionary design before anything gets implemented – pointing out what works and what doesn’t, and where, where, why and how they should do things differently – would, I think, be greatly appreciated by both developers and their end users. e.g. Having looked at the Safari 3 dictionary, it’d take me thirty seconds and the back of an envelope to come up with the right design for it. I’m going to file a bug report on it later, but at this stage (beta) it’s almost certainly much too late for it to be rectified now, meaning users get stuck with yet another confusing, buggy scripting interface in an application which should be best of breed.
preferably in twenty foot-high flaming letters, because until developers get this, they are going to be thinking that Apple event IPC is just another object-oriented system like COM or CORBA. There may be sufficient similarities that you can sort of limp along on a broken understanding, but this has consequences for end users when the resulting application’s scripting interface is confusing, buggy, or just doesn’t “feel right”.
Really, the only material I’ve ever seen that discusses how AppleScript & co. really work are the following papers by William Cook (one of the original designers):
http://www.cs.utexas.edu/~wcook/papers/AppleScript/AppleScript95.pdf http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf http://www.cs.utexas.edu/~wcook/presentations/CookLANG.NET2006.pdf
While they don’t go into the practical details of implementing scriptability or good UI design (that’s not what they’re about), they do provide considerable insight into the concepts and motivations (and some of the flaws too) behind the technology. So until Apple (or anyone else) provides more targeted material, I’ll say these a must-read for any developer working in this area, because until you understand what makes AppleScript tick you’ll be stumbling around in the dark trying to write code for it.
FWIW, as someone who’s had to learn all this stuff the hard way, I have tried to promote some small degree of understanding through the design and documentation of appscript (high-level, open-source Apple event bridges for Python, Ruby and ObjC), but not nearly as much as I’d like (it’s hard to justify the additional work when you’re not being paid for it, and hey, who ever reads documentation anyway?:p). It’ll be interesting to see how Scripting Bridge does in this department – I was sorely disappointed by RubyOSA (hence the Ruby appscript port), but hopefully the engineers and tech writers behind SB have done better. We’ll see in a few months’ time.
has (apologies for length, etc.)
http://appscript.sourceforge.net http://rb-appscript.rubyforge.org http://appscript.sourceforge.net/objc-appscript.html
[…] Mark Alldritt: […]
p.s. I see the blog software ate my numbering (tsk), so to clarify: point 1 begins at “As you say, scripting interface design is user interface design” and point 2 at “Education, education, education.”
Scripting Interface Design now presumes an SDEF, so the first questions should be about the SDEF schema because that now defines everything.
One might very well ask: “What schema?”, because it’s only a DTD right now. As such, there’s a couple of loose ends that should be tied up because DTDs permit stuff that’s illegal in XML Schema and there’s a problem with that in sdef.dtd. The effect of dealing with seemingly insignificant details like this can have a ripple effect upwards on communicating scripting design. That’s because having an XML Schema will enforce the description to an unambiguous mechanical sensibility.
Does that sound like a limitation? Well no, not for AppleScript. It will actually be an enhancement. Take a look at the XML Schema data types http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#built-in-datatypes, and regular expression possibilities http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#regexs for starters.
When a language can be expressed like that, it follows that the ensuing implementation, and the possibilities it presents are clear. Hence explaining scripting interface design will not be limited to the realm of the guru, but rather more the territory of advanced users. That is how it should be because it increases the chances that dictionary designs will be harshly critiqued and from that, better guidelines evolved.
Beside the gory details though, there’s also the question of what the SDEF DTD-schema doesn’t have defined. Like extensibility, adaptability for other implementations, and annotations (appinfo in particular). And this last bit should be of some concern for all those dealing with an AppleScript implementation in their applications because having it be extensible with room for custom calls will make things very flexible.
What is needed is a bridge for PHP. Laugh all you like, but this can stil be done and there is so much leverage out there for programmers that learnt PHP for whatever reasons and and now find the whole learning curve for application programming incredibly steep (the philosophy is completely different).
eduo: “What is needed is a bridge for PHP.”
If you know a programmer competent in PHP and C who would be seriously interested in porting appscript to PHP, tell them to drop me a note (same applies to any other language, though no time-wasters, please). I’m planning a C-based ‘bridge’ API for objc-appscript that will make it easier to implement appscript-style bridges on other languages, so this’ll be a good time for anyone interested to get involved.
“the philosophy is completely different”
It’s the nature of the beast (RPC+queries), and it’s something you have to deal with regardless of the language you use. The advantage of having a bridge to your platform of choice is that at least you don’t have to deal with the schlonky AppleScript language as well.
Mark,
Your article calling for a Scripting User Interface evangelist is excellent, as are many of the comments here.
Why is AppleScript implementation so hard? It feels like writing a compiler blindly. You have to invent constrained, English-like input that is clear, clear, clear and you have to figure out how to use it to get machines to do something. But you’re blind because you have to do this in an opaque world that requires lots of trial and error, lots of feeling your way along dark corridors.
The best first step is creating your app’s constrained, English-like language: the scripting user interface. One of the initial goals of AppleScript was making scripting as much like natural English as possible. This is still extremely important!
Why not start AppleScript implementation by writing scripts? Really clear, English-like scripts. It should almost be like Star Trek: “Computer, read my mind and synthesize the perfect ray gun.” “Working… Ray gun complete.”
Be a user. Talk to your application, temporarily ignorant of its inner workings. Or better, get a non-technical person to talk to your app. Write down what they say, the English words they use to make it do what they want. This is your script. It should be clear, simple and natural.
We’re talking basic customer oriented business. Who is the customer? The scripter. Or the user you can entice into scripting because your scripting UI is so great. What does the customer want? A really clear, simple to use tool. The abilitiy to use the tool their way, the way that is natural to them.
Creating such an interface requires exceptional communication skills. Verbal skills.
We love programming, partly because of the way it spans the technical, mathematical, problem solving issues AND the artistic, creative, communicative issues. With scripting interface design, you really have to put on your lucid communication, literary hat. I know: It don’t always fit so good. But you or someone has to do it. It’s key.
Naturally, I think that Chapter 20 of my AppleScript book is already a major component of the document you’re looking for. It lists mostly things that are wrong with existing scripting implementations (as displayed in the dictionary), so it’s largely a “what not to do” document; but by extension, that tells you “what to do”.