Hide full article
Last week in TidBITS-347, the first part of this article described CE Software's QuicKeys (QK) and mentioned a new feature of the recent 3.5 release: toolbar triggers. Here, we conclude with some serious evaluation.
Creative Constraint -- For QK to be usable, the process of creating or editing a QK action must be simple and convenient. You want to spend your time using the computer, not configuring a program that makes it easier to use. Many actions are going to be spur-of-the-moment, ad hoc creations; if you're copying a series of pictures to the Scrapbook, you won't add automation to the process unless that's faster and more convenient than just finishing the job by hand.
Nonetheless, QK users over the years have had to put up with varying degrees of inconvenience and confusion in the interface used to create and edit actions. QK actions come in various types, and the desired type must be chosen from a poorly structured hierarchical menu. Many action types are created and edited via awkwardly designed dialog boxes, which often lead to other dialogs, all of which are modal and block one's view of things on the screen, including each other. (In 3.5, the main dialog is now movable and resizable, but it's still modal, and since windows behind it don't update, moving it is pointless.)
Once you've made a QK action, it isn't easy to know what it does without opening and editing it (and here come those dialogs again); you can't give an action an informative name. In some cases you can change its name, but you're limited to a few characters. In other cases you can't change the name at all. For example, an action that chooses the Close menu item and another that chooses the same menu item while pressing the Shift and Option keys (Close All in Nisus Writer) are both called Close. You can include a comment, but the comment isn't visible in the main window - you must click an action's comment icon to read it.
Assembling actions into sequences is even more daunting. In the sequence editor, you can't drag & drop an action to change its place in the sequence, and it isn't even intuitively obvious how move it by cut and paste. There's the same problem of non-descriptive action names, aggravated by the fact that there are no comments at all in the sequence editor! I don't understand why CE doesn't look at the interfaces of programs that do a successful job of letting you build sequences of editable action types; FileMaker Pro comes to mind.
For much of its history, QK sequences lacked any programming constructs, such as looping and branching; apart from calling one another (or themselves, infinitely), sequences were linear. Some clumsy if-branching appeared in version 2.1.2, and was much improved in 3.0. Version 3.5 improves the Jump command, and adds one new looping construct, the Batch Processor, which runs through all the files in a folder, opening each one and running a sequence on it. Note, though, that this won't help if what you need to do to each file doesn't involve opening it. All the branching commands remain limited as to what things QK is able to test for, and are clumsy and inconvenient to use.
OSA, Can You CE? History lesson: In 1991, System 7 introduced Apple events, which enabled inter-application communication (IAC) for those applications that understood how to send and receive them. In 1992, System 7.1 added the Open Scripting Architecture (OSA), which made it possible to create alternate programming languages that operated on Apple events. And in 1993, Apple released its own such language, AppleScript.
CE responded to System 7 by incorporating into QK 2.1 an extension, CEIAC (get it?), that allowed QK to send and receive Apple events. But bare Apple events are hard to use, and the important change came in mid-1993 when QK 3.0 made three major innovations:
It replaced CEIAC with a faceless background application, QuicKeys Toolbox. This application, among other things, responds directly to some useful AppleScript commands.
It added the ability to perform AppleScript scripts. Thus a QK action can be a place to store, and a way to trigger, an AppleScript script.
It included its own recordable OSA dialect. An application that executes OSA scripts (such as Frontier, HyperCard, or Apple's Script Editor) could now talk QK's language. Instead of triggering a previously defined QK action or sequence, it sends QK a script for the action or sequence. So, from within such an application, you can take advantage of QK's "invisible user" powers to script applications that aren't AppleScript-savvy.
For instance, I had an AppleScript script that copied multiple pictures from QuarkXPress and pasted them into Microsoft Word, but on the way I wanted to pass them through GraphicConverter to reduce their bit depth, and GraphicConverter isn't scriptable. So as my script handled each picture, it talked to Quark and Word in AppleScript, but in between, it talked in QK's language to make QK choose menus and click buttons in GraphicConverter.
Unfortunately, the integration between QK and other scripting dialects isn't very good, because QK has no variables, so it's hard to pass information back and forth.
For example, when I had to use Pegasus Mail, which was not scriptable, I wanted to make it automatically download each message in my mailbox from the Novell server to my hard disk, and then delete it from the server. With QK, I could select the next message and choose Save; but at this point I was faced with a blank Save dialog, and, lacking variables, there was no way QK was going to type a different filename for each message ("Temp1", "Temp2", etc.). So I had to drive QK from some other scripting application which could generate the successive filenames. I chose HyperCard. It worked, but it was tricky. On each pass through the loop, HyperCard had to let QK know the next filename; conversely, when all the messages were deleted, QK knew it (the "Save" button was no longer active), but it had to alert HyperCard to stop the loop.
Since I wrote that script, the world has progressed, but QK has not. I now handle such tasks with PreFab Player. Player has no interface: it isn't a way for the user to trigger actions and sequences directly, as QK is. But as a way for a scripting application to drive non-scriptable applications, it's better, because Player's commands are AppleScript or Frontier's UserTalk commands, so you can seamlessly use the variables and looping constructs of either of those languages; you don't have to hand any information across the OSA dialect boundary, or change dialects at all.
<http://www.tiac.net/prefab/player.html>
It Might Have Been -- For many years, QK has been a reliable workhorse in my Mac stable; I call upon it constantly to modify and automate my Mac's behavior. A computer, I am fond of saying, is to program; or at least, it is the user who should command the computer, not the other way round. QK has helped defend me from operations and application behaviors that smelt of inconvenience, of routine, of liturgical action and response, and that threatened to make me the automaton instead of the computer.
QK has long been acclaimed as a top-ranked, essential Mac tool. Yet CE was not content, in the past, to rest on its laurels. Successive releases of QK have always had an air of fiddling and tweaking, as if CE were seeking, while improving the experience of established users, to attract new converts by increased ease of use. QK 3.5, however, aside from the toolbars feature and the batch processor command, is basically a maintenance release. It's disappointing to think that, after a silence of three years, this is the best CE could come up with. In the interim, what else might CE have been doing?
CE might have resolved the nature and extent of QK's programming power. It might have improved QK's internal programming constructs, perhaps adding variables and arithmetic operations; conversely, it might have better integrated QK with existing scripting dialects. Instead, QK remains weak as an independent scripting tool and has been surpassed by PreFab Player as an AppleScript- or UserTalk-dependent one.
CE might have decided to educate and assist the user with improved manuals. Instead, the manual, which has gone steadily downhill since the sparkling clarity of the 2.0 edition (by the redoubtable Fred Terry), is now flimsy, ugly, poorly produced, skimpy, and uninformative; all printed reference information has been abandoned in favor of online help, which is in sluggish, clumsy, inappropriate Apple Guide format.
CE might have made 3.5 widely usable, but instead has cut off perhaps half the installed base by restricting this version to System 7.5 or higher.
CE might have increased QK's basic abilities. Here are some possibilities:
Allow QK's if-branching to "see" and test for a larger repertoire of features of a dialog. For instance, PreFab Player can see icons and read static text.
Allow QK to "see" the contents of a list box in a dialog, so it could select a particular item. To take an example: if you're using something like MacJanet, where you connect over the network to a server but not through the Chooser, you must bring up a dialog, pick a zone from one list, pick a machine from another list, then click OK and type your name and password. The list of zones and machines that are online changes constantly, so you can't automate this procedure unless QK can somehow read the lists.
Allow QK to take a screen shot within certain coordinates and compare it to a template. This would allow QK to "see" and test for graphic screen features it can't get at in any other way. Tempo (a rival macro program) and Ivy (a Virtual User plug-in) can do this.
Allow selection from a non-QK menu to be a trigger. For instance, Alessandro Levi Montalcini's NoDesktopCleanup can interfere when you select any menu item in any application, put up a confirmation dialog, and, if you click Cancel, prevent that menu item from carrying out its usual function. QK could expand on this technique, invoking an action or sequence before, or instead of, the application's response to its own menu. This would essentially make any application "attachable."
<ftp://mirror.aol.com/pub/info-mac/gui/no- desktop-cleanup-121.hqx>
Finally, CE might have made some genuine improvements to QK's interface. The new look of the main dialog and sequence editor is mere window dressing; what's needed is a rethinking of the interface, from the ground up.
In the End -- QK remains a staple; I can't imagine myself doing without it. QK owners running System 7.5 or later will probably wish to upgrade, if only to take advantage of any bug fixes I don't know about. However, after three years' hiatus, both new and long-standing users deserved a more full-featured release than 3.5 has turned out to be.
<http://www.cesoft.com/quickeys/qkhome.html>
[We hope to publish reviews of the main competition for QuicKeys, WestCode Software's OneClick and Binary Software's KeyQuencer 2.0, in the near future. -Adam]
CE Software, Inc. -- 515/221-1801 -- 800/523-7638
