Just a quick note to let you know that this issue of TidBITS is going out to exactly 40,000 people on our mailing list. Our list goes up significantly each day (between 50 and 100 people), although we also delete several hundred people each week due to mail problems. Still, we’ve been hovering around this 40,000 point for a few months and it’s nice to achieve it finally. [ACE]

Aladdin Sponsoring TidBITS — It is with great pleasure that I welcome our latest sponsor, long-time Macintosh developer Aladdin Systems. Aladdin ranks as one of the best-known small Macintosh developers, especially in the online world where their signature product, StuffIt, has become the compression format of choice. The reason for the ubiquity of the StuffIt format is simple – StuffIt started out as shareware and Aladdin has always maintained a full range of StuffIt products, some freeware (the essential StuffIt Expander), some shareware (DropStuff and StuffIt Lite), some commercial (StuffIt Deluxe, Aladdin Desktop Tools, CyberFinder), and some that span the gamut, such as the easy-to-use StuffIt InstallerMaker, which has a range of licensing options.

Aladdin has always been a strong supporter of the Macintosh online community. Many of their commercial programs are available for download and free trial, with lower prices for those who register online. In addition, various members of the Aladdin staff spend a good deal of time in a number of Internet and Macintosh mailing lists, and contribute their time, talents, and expertise to a variety of online projects and organizations.

Recently, Aladdin hired a new CEO, John Nesheim, who aims to help Aladdin manage its fast growth and expand its stable of products. We wish them the best of luck and are pleased that they’re helping to support TidBITS. [ACE]

<http://www.aladdinsys.com/>

Frontier 4.1 — Dave Winer, Doug Baron, and the folks at UserLand have released Frontier 4.1, an updated version of their Internet-savvy Macintosh scripting environment. Frontier 4.1 offers a revised user interface with new menus and a couple of "Navigators" designed to make key parts of the Object Database more accessible, a completely revised User Guide, new documentation for scripting Web sites with Frontier, and the ability to run MacBird cards (see TidBITS-309), which adds some custom interface capabilities. Frontier 4.1 also includes a flurry of bug fixes and changes contributed from Frontier’s active user community and – perhaps best of all – Frontier is still free.

Currently, an updater to Frontier 4.1 from 4.0.1 is available (about 2.5 MB), but a full "shipping" version of Frontier 4.1 should be ready by the time you read this. Be sure to follow the installation instructions (and back up your Frontier.root file!) and download a copy of the new Users Guide (about 1.1 MB). [GD]

<http://www.scripting.com/frontier/>

Corel WordPerfect 3.5.2 Updater — Corel has released an updater to WordPerfect 3.5.2, which reportedly fixes about a dozen bugs, some centered around printing envelopes. At the moment, the update is apparently only available from an overwhelmed Wildcat BBS system run by Corel; its FTP service is somewhat non-standard, and a number of Mac users have reported problems downloading and decoding the 2.5 MB update package, although I had no troubles using Fetch’s "text" mode. [GD]

<ftp://bbs.corelus.com/WordPerfectfortheMac/ wp35.hqx>

Seymour Cray Passes Away — This is not strictly Macintosh-related, but we wish to note the passing of Seymour Cray on 05-Oct-96, from injuries suffered in an automobile accident. Cray built the world’s first transistor-based supercomputer in 1958 and is widely credited with the concept of Reduced Instruction Set Computing (RISC), which is the basis for the PowerPC and other modern microprocessors. Although Cray’s business ventures weren’t always successful (Cray Research was sold to Silicon Graphics a few years ago), he will likely remain one of the most influential figures in high-performance computing for some time to come. [GD]

As we noted back in October of 1995 in TidBITS-297, the year-long publication of DealBITS was something of an experiment. We wanted to see if we could rethink the way advertising on the Internet works to make it positive force for the industry. DealBITS combined idealism with our practical need to earn a living with TidBITS. And, although in many ways it was a success, in other ways we found that we didn’t understand the world of advertising sufficiently to make the dent we’d wanted.

The basic problem with DealBITS was that it proved to be too much work for the amount of money it earned. Although it never had any trouble being profitable, it wasn’t a sufficiently profitable use of our, mainly Tonya’s, time. Perhaps more important, the act of creating DealBITS twice each month wasn’t inherently rewarding enough in and of itself to make up for the amount of money it earned. Hence our decision to put DealBITS on hiatus while we rethink both its concept and execution.

The most significant problem that DealBITS faced was that it never had enough deals to make a given issue something likely to appeal to any Mac user. We had initially, and incorrectly, assumed that charging a fraction of what advertising in print publications costs would encourage numerous companies to advertise without the work of selling them on the advantages of DealBITS. Were we wrong on that one! It turns out that soliciting advertisements is just another form of sales, and good salespeople are a breed apart. To succeed in the future, we’ll need to find a professional ad sales representative, the sort of person who knows everybody in the industry, can speak the language of advertising, and most importantly, who has the time to keep after advertisers constantly. Finding interested advertisers is only the beginning – after that comes the concerted effort to get the advertiser to submit the text of its ad and set up any deals.

The deals were another idealistic detail. Every ad had to in some way offer a deal that wasn’t otherwise available. That sounds like a great idea, but in retrospect it eliminated many potential advertisers, particularly larger companies. The problem is that large companies don’t sell their products directly – they only work through distributors and other channels. As such, it’s difficult or even impossible for them to offer deals that are in any way different from the norm. And, without large companies in the game, DealBITS lacked deals on many popular, mainstream products. This is another part of DealBITS that will simply have to change – we can’t afford to snub large companies that can’t work out unusual deals for risk of alienating their distribution channels.

From the very beginning we realized that we had to employ serious automation to make DealBITS possible. And, to a large extent, we did, but there was one problem that we overlooked. It turns out many advertisers didn’t turn in coherent and well-designed ads without some editorial help. We were certainly willing to help, but there was no way to automate the process, which claimed at least a full day of Tonya’s time for each issue. The back-and-forth editing process also proved stressful when companies missed deadlines for submitting copy and begged for more time. Suddenly we ended up with high-pressure Monday deadlines twice each month when DealBITS and TidBITS had to ship on the same day. In thinking about this problem, we have yet to decide on a solution. The possibilities seem to be binary: either we edit nothing and rely on technology (such as a Web page for submitting copy that can require essential elements and enforce a size limit on ads), or else we bite the bullet and continue to edit everything by hand.

Our publication schedule turned out to be problematic too. We didn’t want another weekly deadline along with TidBITS, but a biweekly schedule would have confused both billing and the prediction of when an issue would appear six months in the future for reservations. In the end, we decided to publish on the first and third Mondays of each month, and although that seems coherent, it proved confusing to at least the advertisers, causing missed deadlines and the aforementioned additional stress. Our feeling is that the eventual solution will be weekly or biweekly publication.

The final problem that DealBITS faced was that it never quite achieved the readership it needed to help attract more deals and to make advertising in DealBITS even more worthwhile. The DealBITS list was closing in on about 8,000 by the end, and between 1,000 and 3,000 people read issues on the Web. We hope to figure out some ways of increasing those numbers and may solicit suggestions or test some ideas via a Web survey in the future.

In the end, I think DealBITS succeeded as a publication. When we announced the hiatus, we received a number of messages from readers who were disappointed, and our long-time advertisers were rather distressed. DealBITS readers were good customers, and our advertisers didn’t want to lose touch with them. Small Dog Electronics, which sells hardware, software, and Mac systems, even set up its own informal list to keep in touch with DealBITS readers – to get on that list send email to <[email protected]>. Our task with DealBITS now is to solve the business problems and fine tune the other aspects of the publication such that it can meet all of its goals and help support TidBITS.

Last week, an article by Tom Abate in the San Francisco Examiner triggered an avalanche of speculation, wire service stories, and (as usual) semi-hysterical letters to TidBITS. The cause? The Examiner article seemed to claim Apple’s Chief Technology Officer, Ellen Hancock, was planning to sacrifice backward compatibility in future versions of the Mac OS.

<http://www.sfgate.com/cgi-bin/examiner/article.cgi?year=1996&month=10&day=04&article=BUSINESS15526.dtl>

The article quotes Hancock as saying "If we have to pick between backward compatibility and new functions, we’re voting for new functions." As amplified through wire service stories and untold generations of mailing list and Usenet postings, the popular perception now seems to be that Apple has said no current Macintosh programs will run under Mac OS 8.

That’s simply untrue, and understanding why is not much of an intellectual exercise. Apple would be committing corporate suicide if all existing Macintosh software ceased to operate under future versions of the Mac OS – this would actually be a worse decision than if Apple were to decide to abandon the existing Mac OS in favor of a version of Unix or Microsoft Windows. Developers would abandon the Mac platform in droves and, more importantly, many users would undoubtedly give up on Apple in disgust. After all, most Macintosh users prefer the Mac for one primary reason: the software. If that software all ceases to work, the Macintosh loses its most critical advantage.

So what is Apple saying? Basically, nothing new: incremental updates to the Mac OS will be released every six months or so, and as new features from Copland are introduced (such as pre-emptive multi-tasking, a new microkernel, a new file system, etc.) some Macintosh programs will have to be updated to run under the new system software. This is not news: Apple has been sending these signals since the developer briefings on Copland in 1993. Certain types of programs will be more prone to problems than others, the most notable being control panels and many extensions, plus applications that rely on undocumented system calls.

In the past, Apple has often bent over backwards to ensure existing applications run under the latest system software. Though this isn’t always possible, in a number of cases Apple has let a particular bug or undocumented behavior remain in the system because a major software program broke when the problem was fixed. The only shift in Apple’s stance seems to be that Apple may no longer allow its system software to be held over a barrel by applications and software that rely on undocumented calls or other chancy, non-standard programming practices. Apple has done this before with various components of the system software (including the Finder, Sound Manager, QuickDraw, and others), and although an uproar usually ensues at first, the operating system must move ahead somehow, and this is a time-honored method. So time-honored, in fact, it’s used by most other operating systems, including Unix, Windows 95, Windows NT, VMS, and others.

There has been speculation that the Examiner article is an indication Apple plans to substitute the BeOS for future versions of the Mac OS. So far as I can determine, the situation between Apple and Be is largely unchanged, despite numerous far-flung claims from both Apple and Be users. (See TidBITS-343.) In the meantime, Be has said (but not promised) single and multiprocessor versions of the BeOS for Power Macintosh should be available in early 1997.

If there’s anything to be learned from this incident (and similar recent media snafus regarding Apple), it’s that mainstream technical reporting regarding the Macintosh must be taken with a grain of salt. This is not necessarily a reflection on reporters or publications – I don’t know these people and do not wish to cast unwarranted aspersions. However, the process a mainstream story on Apple Computer goes through is analogous to a message passing through a line of twenty people by being whispered from ear to ear. More often than not, the message received by the twentieth person is quite unlike the message sent by the first. With the mainstream press, the line is comprised of reporters, editors, staffers, proofreaders, copy editors, and correspondents, and the Macintosh community is usually at the end of the line.

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