Hide full article
TidBITS not long ago discussed three macro programs: QuicKeys (beginning in TidBITS-347), OneClick (in TidBITS-350), and KeyQuencer (in TidBITS-351.) Consideration of these has led me to some reflections on the state of the Mac. In the best of all possible worlds, I think, we wouldn't need macro programs at all: the Mac would be easily scriptable without them. Until then, macro programs offer much-needed relief.
The Prison and the Promise -- Here's the problem: our software still rules us instead of the other way round. My Mac, full of "Grand Unified Applications" that compel me to adjust my work habits to their structures and my needs to their feature sets, sometimes feels more like a lair of corporate priests than a liberation of my individuality. The Mac has fallen short of the promise of Apple's famed "1984" commercial: despite the supposedly user-driven event loop, we remain prisoners of modalities and restricted choices.
One escape would be to write your own applications, but that would involve unnecessary reinventing of the wheel. (I do think the Mac ought to be much easier to program, but that's another story.) For most operations, programs you already own can probably perform all the needed tasks - if only they better understood your needs, or you could combine them as desired.
For example, a dozen times a day, after some Find-and-Replace operation with Nisus Writer, I press Command-S and nothing happens. Why? I'm watching the document, but the Find/Replace window is frontmost, and in Nisus Writer that disables the Save command. Now, wouldn't you think that after a while, the computer would get the idea? "Say, Matt, I notice you keep hitting Command-S with the Find/Replace window frontmost. I've been wondering - are you doing that because you'd like me to save?" Alas, the computer probably won't talk (or think) this way any time soon. So, if a program doesn't work as you want, you should be able to customize it.
[The closest attempt to this sort of agent technology is the shareware Open Sesame from Charles River Analytics, but in my testing in the past it never made any useful suggestions. If you're interested in programming by demonstration, check out Allen Cypher's Eager demos. -Adam]
<http://www.cra.com/products/sesame/ sesameinfo.html>
<http://www.atg.apple.com/Allen_Cypher/Eager/ Eager.html>
Mapping the Mess -- The ability to customize programs is not built into the Mac. Rather, each program's developers must write it in such a way that its functions are exposed to public control. Loosely speaking, this makes the program "scriptable."
But no standard for customizability has taken hold. In the Mac's early days, Apple lobbied developers to accept uniformity by voluntary convention: make windows look like this, make menus work like this, make dialogs work like this. They succeeded so well that Apple's Human Interface Guidelines significantly informed the look and feel of Windows and other graphical interfaces. But Apple did not insist upon scriptability, even after System 7 made it easier.
As a result, developers often don't grasp the importance of scriptability. The MACSCRPT mailing list is a place to watch veteran scripters slapping their virtual foreheads in anguish over developers who don't "get it" - such as when a major developer challenged readers to persuade them the next version of their program should be scriptable. (If you're interested in subscribing to the MACSCRPT list, send email to <listserv@dartmouth.edu> with the command "subscribe macscrpt <your full name>" as the body of the message.)
I take it as axiomatic that a computer is meant to be programmed, and so ideally every program should be scriptable. But how and how much you can customize a program's behavior varies immensely. Some programs expose all their functionality, some expose only a fraction, and some expose nothing. Then there's the "platform" from which a user is enabled to command an application: a program may include its own internal scripting language, respond to commands via the Mac's messaging system (Apple events), or a mixture of both. Then there's the degree to which one may detach the program's interface from its functionality; for example, menus or dialogs might be customizable, or a program could perform tasks behind the scenes rather than in a window or in the foreground.
You can probably think of other measures of scriptability. The point is that if we made a scriptability map, existing programs would be scattered all over it. For instance, Microsoft Word 6 exposes all of its functionality through an internal scripting language (and some of it to Apple events as well), lets you customize menus, and even build new interface elements such as custom dialogs and palettes. Nisus Writer 4.1 only exposes some of its functionality through an internal scripting language (and not at all to Apple events), and its interface is only minimally customizable (keyboard shortcuts can be changed). MoviePlayer isn't scriptable. And so on.
Scripting in Tongues -- The Word 6 model of complete scriptability is the exception rather than the rule: scriptability in general is frustratingly incomplete. Nisus Writer won't tell me the font or style of the current selection, and I can't tell Eudora to select message so-and-so without opening it. Word's degree of interface detachability (where I get to decide what each of its menu items does) is even rarer - perhaps Mac OS 8 will make writing this style of application easier, but I'm not holding my breath. There are also internal scripting languages which can't be hooked to other programs at all: it's maddening.
Still, suppose that every internally scriptable program also had an external hook, so scripts written in an internal scripting language could at least be sent from another program. You might think that external scriptability would be better, because every internal scripting language is different (and may not be very good), whereas external scriptability can be based on one language, such as AppleScript. However, many internal scripting languages are superb (like Excel's Visual Basic), and, almost paradoxically, AppleScript-savvy programs can each introduce their own AppleScript syntax, so scripting those programs is still like learning a new language - or even harder because the syntax usually isn't obvious or documented. (How often I've seen letters to the MACSCRPT list from people stumped on how to make Eudora delete the selected message: the magic AppleScript formula 'move message 0 to end of mailbox "Trash"' isn't obvious.) Plus, external scriptability doesn't solve the fundamental problem: you're still at the mercy of any particular program as to how much functionality it chooses to expose.
Macro Management -- Customization should permit you to link a program's existing functions in new ways. It should also allow you to incorporate functions of other programs, combining the strengths of each in a milieu which can sense and respond to the state of each program, draw upon the power of the system as a whole, and support some basic programming using common types of information (such as numbers and text).
Until scriptability is more uniform, a system-level macro program is the best central command post for customization. The downside to system-level macro programs is that, no matter how well-engineered, they have the potential to expose problems and bugs in other programs or system extensions. For instance, if an application has troubles with window management, displaying a palette or a dialog box with a macro program might cause problems - even if the macro program does everything by the book. Nonetheless, a system-level macro program can type, click the mouse button, choose from menus, and generally simulate user actions so as to drive most non-scriptable or partially scriptable applications. It can intervene in normal operations, respond to user actions such as keystroke commands, deal with system information (such as what windows are present, what's on the clipboard, what files are in a folder), and talk back and forth with other scripting environments. Plus, ideally, it has genuine programmability, preferably in some easy but flexible form.
Of the three macro programs we looked at in TidBITS, WestCode's OneClick is the most programmable: its intuitive, elegant language has lots of user-simulating power, system-level functionality, and programming constructs. A comparison with HyperCard is apt because OneClick is more than just a macro program: it's a mini programming environment. The buttons you place on its palettes respond to clicks, display menus, and respond to your choices. Plus, OneClick buttons can accept text files via drag & drop; show or hide themselves; and display icons, textual information, or progress bars.
I currently resort to OneClick whenever the question pops into my mind, "Why can't this program do this?" For instance, Eudora's filters don't include an option to automate saving messages as text files based on their subject or sender: it was easy to write a OneClick button that does so. In Nisus Writer, I always had to peek at several menus to find out the font, size, and styles of the current selection: now, I have a OneClick palette that always displays that information textually. These are things that QuicKeys could never have done for me, so I've been able to dispense with QuicKeys (and other utilities as well).
<http://www.westcodesoft.com/>
Still, OneClick requires some compromises. Like other system-level macro programs, it operates at a low level and can come to loggerheads with some applications and extensions, at least on my machine. It's also somewhat in its infancy; that's great if you want to participate in the excitement of its evolution or invest time in developing your own tools, but right now it may not have the pre-made functionality you want.
KeyQuencer is the best choice for those who want a simple interface and minimal RAM requirements, or who particularly need some of its functions (such as its remote control of other machines, printer selection, cursor animation, and so forth). Binary Software, like WestCode, is very responsive to suggestions, so this is another chance to involve yourself in a program's growth process.
<http://www.binarysoft.com/keyquencer/ keyquencer.html>
For those who prefer something rather more tried and true - or would rather not learn a text-based language - QuicKeys remains an important option. Its use of dialogs and recording helps the user assemble functionality without feeling like any programming is going on. What's more, QuicKeys has been around and solid for a long time, and has learned to deal with many non-standard system extensions and user interfaces, though support for the product at CE seems to have weakened to a trickle.
<http://www.cesoft.com/quickeys/qkhome.html>
The important thing is that you can and should have a macro program so that you, not your computer, are boss. It's great so many options are available now, and you can't go really wrong with any of these programs. They can all drive unscriptable programs, they can all use Apple events to cooperate with scriptable ones, and they're all affordable. Your preference will ultimately be a matter of personal style or need. Treat yourself to one as a holiday present! You can even get more than one and combine them. Whatever you do, take control of your computer: don't let 1997 be like 1984.
DealBITS -- Cyberian Outpost's deal on KeyQuencer for $33.95 ($4 off) is still available from the URL below. Note that this page doesn't explicitly say it's a deal, but it is.
<http://www.tidbits.com/products/key- quencer.html>
Also, WestCode Software has set up a deal on OneClick for TidBITS readers. You can purchase it for $59.98 ($10 off regular WestCode pricing) through the URL below:
<http://www.tidbits.com/products/one-click.html>
