Conflict Catcher 8.0.3 Update Released — Casady & Greene last week released Conflict Catcher 8.0.3, a free update to Conflict Catcher 8 that correctly labels original items when performing a Clean-Install System Merge. Version 8.0.3 also manages the Internet Search Sites folder that stores Sherlock plug-ins, has better 68K support, and includes additional system merge information. The download is 1.8 MB. [ACE]

<http://www.casadyg.com/products/conflictcatcher /8/>

Palm Buddy Update Adds Converters — PalmPilot or Palm III owners who use Macs can download Palm Buddy 1.1, Florent Pillet’s invaluable utility for backing up and installing PalmPilot files (see "A New Buddy for PalmPilot Users" in TidBITS-436). The new version adds plug-ins for two Palm-based database programs, JFile and MobileDB, which enable you to install tab-delimited text files by dropping them onto Palm Buddy’s window on the Mac. Version 1.1 also adds the capability to drop folders onto Palm Buddy, enabling users to restore a previous backup in a single step. Numerous bug fixes, support for faster serial connections, and plug-ins for non-Roman languages round out the update. The $20 shareware program is a 1.2 MB download; upgrades are free to registered owners.

<http://perso.wanadoo.fr/fpillet/>

<https://tidbits.com/getbits.acgi?tbart=04956>

In related PalmPilot news, a public beta of the new Macintosh Palm Desktop 2.0v2 will appear in early November, according to Doug Wirnowski of Palm Computing/3Com. The software is built upon Claris Organizer, which 3Com bought from Apple (see "Palm Organizer for Macintosh: Details Emerge" in TidBITS-432). [JLC]

<https://tidbits.com/getbits.acgi?tbart=04915>

Electronic Phoenix Project Mailing List Formed — Several people have volunteered for the Electronic Phoenix Project (EPP), my proposed organization whose mission would be to adopt orphaned software. The idea received wide interest, even resulting in an article in the Dutch newspaper Het Parool. To facilitate further discussion, I’ve created an open mailing list. To subscribe, send email to <[email protected]> and to sign off, send email to <[email protected]>. The list is not moderated, so try to limit discussions to creating and operating the EPP. (Suggestions for programs to adopt aren’t necessary – many have already been suggested in TidBITS Talk.) I look forward to seeing what emerges. [ACE]

<https://tidbits.com/getbits.acgi?tbart=05141>

<https://tidbits.com/getbits.acgi?tlkthrd=424>

Graphic designers hit a stumbling block a few years ago when the Web threatened to become The Next Big Thing. It had been acceptable to pack as much detail as possible into every row of pixels in a huge image. But designers who took on Web work discovered that images needed to be as small as possible. Compression became the holy grail of Web design.

Although this quest led to the creation of a new industry and a disproportionate number of how-to books, only recently has attention focused on optimizing the HTML files that make up every Web site. Two utilities have emerged to shave even more bytes from your Web files. Mizer, from Antimony Software, and VSE HTMLTurbo, from Voget Selbach Entertainment, can reduce the size of HTML files without harming their functionality.

Don’t Byte Me If I Strip — Image compression relies on two notions: either replace repeating values with a shorter description of those values (known as "lossless compression" and used in GIF files), or remove unnecessary information without revealing noticeable degradation (known as "lossy compression" and used in JPEG files). (For an overview of image compression, see "A Closer View of Web Graphics" in NetBITS-007.) You can’t apply lossless compression to HTML files because Web browsers aren’t designed to read, decode, and display compressed text files. That leaves lossy compression: strip out unnecessary information but leave the content and HTML tags intact.

<http://db.netbits.net/getbits.acgi?nbart=04458>

So what’s expendable? Without trying to say what’s worthwhile on the Web, there are unnecessary elements in a typical HTML file. Line breaks, tabs, and spaces that aren’t used in the page content are the most obvious; they consume space despite being invisible. Although HTML purists (and validation programs) may object, most Web browsers can correctly interpret pages without some elements, such as quote marks around tag attributes (like <IMAGE HEIGHT="50">) and tags added by some HTML editors (like <NATURALSIZEFLAG>).

You could also attack comment tags (which don’t appear in a Web browser but are used to embed notes, represented as <!– COMMENT HERE –>). However, some Web servers add preexisting content from templates or perform an action dictated by commented commands, making this option potentially dangerous.

You could do all this by hand if you had the time, but since no one does, instead check out the aforementioned utilities to have the work done for you. The stripped files look awful without the tabs, line breaks, and spaces that make the text easy to read. That’s why the creators of both Mizer and HTMLTurbo recommend HTML compression happen just before uploading. That way, the smaller files reside on the Web server, while your editable copies remain on your hard disk. Apply necessary updates to your local files, then replace the server files with new optimized copies.

Getting Wiser with Mizer — To process a file using Mizer, drop it onto Mizer’s application icon. You end up with three files: the optimized HTML file, a backup copy of the original, and a log file reporting the amount of compression achieved. You can modify those and other options by launching the program directly and choosing Preferences from the File menu. Mizer also includes a setting called Tag Optimization that removes closing tags such as </LI>, </HEAD>, and </HTML>, even though that’s against official HTML rules.

In addition to compressing individual files, Mizer can crunch an entire folder of Web files dropped onto it, enabling you to process a local copy of your Web site in one shot.

Mizer also optimizes JavaScript text, though it’s important that the JavaScript syntax be correct (unlike HTML, which browsers often display even if broken). Specifically, statements must be properly terminated with semicolons, not just returns (which some Web browsers acknowledge as functional code).

Mizer is scriptable, so you can incorporate it as an automated step within your Web page creation process. For instance, a sample script provided with Mizer optimizes files then uploads them to your Web server using Fetch.

Blasting Text with VSE HTMLTurbo — Like Mizer, HTMLTurbo involves a drag & drop operation to optimize HTML files, but it offers more configuration options. For example, from the Preferences dialog box, you can specify that comment tags and <META> tags be stripped (you can also remove just the <META NAME="generator"> tag).

HTMLTurbo can notify you when it encounters errors in your HTML code, but its implementation is crude, popping up a dialog box that stops processing until dismissed. Fortunately, you can turn this option off.

HTMLTurbo can display a Results window that uses the amount of bytes saved to estimate how much bandwidth you can save over a period of time. By selecting a file and typing in the approximate number of hits that page receives, HTMLTurbo reports average savings by day, month, and year. I wouldn’t classify this as hard data, but it’s interesting to see the effect of your efforts, especially if your Web hosting fees are based on actual bandwidth used.

Do They Work? I tested a variety of HTML files on both utilities, ranging from small text-only pages to complicated layouts using numerous JavaScript elements. In both programs I kept the default compression settings. Understandably, the more complicated files yielded the best results: in one case, a 45,532 byte file was reduced to 39,486 bytes by Mizer (a savings of 6,046 bytes, or 13.3 percent) and to 40,448 bytes using HTMLTurbo (a 5,084 byte savings, or 11.2 percent). The macro-generated HTML file for TidBITS-452, however, produced minimal gains: from an original size of 32,983 bytes, Mizer came up with a 32,586 byte file (saving 1.2 percent) while HTMLTurbo created a 32,432 byte file (saving 1.67 percent).

I threw two complete sites at the programs. The larger one, weighing in at 22,713,440 bytes (22.7 MB) was reduced to 21,589,258 bytes (saving 1,124,182 bytes, or 4.95 percent) by Mizer, and 21,488,988 bytes (saving 1,224,452 bytes, or 5.39 percent) by HTMLTurbo. Note that these figures represent the entire site, graphics and all. The second site, which was much more modest, shrunk 14.8 percent from 134,236 bytes to 114,265 bytes (Mizer) and 15.5 percent to 113,445 bytes (HTMLTurbo).

Compression Quibbles — Overall, I was pleased with the 5 to 15 percent compression I saw in my informal results. I wasn’t able to identify any page elements that broke due to the optimization, and in several cases load times seemed to improve. However, despite both programs’ enthusiastic claims, real-world speed differences are influenced by outside factors such as Internet traffic, your computer, and your method of Internet access.

In fact, the problems I found with each program were related more to interface and action, rather than results. My largest gripe about Mizer relates to processing a folder of several HTML files. Although the program makes backup copies of the original files, they’re scattered within the original directory instead of in a new folder; this meant that for my large site example, which contained 1,466 files in several nested folders, I had to separate the compressed versions from the originals manually.

HTMLTurbo introduced its own variation of this problem: it tosses every processed file into one directory – if you compress more than one file from different sites on your hard disk, you must sort them out (hoping that none share the same name, like index.html). Another quibble with HTMLTurbo is its complete lack of information on exactly what it strips from HTML files. Some people may not want that level of detail, but I want to know what’s being done to the HTML I’ve labored over (this is also why I’m often dubious about WYSIWYG HTML editors). Mizer, though slightly less flexible, makes up for it by precisely explaining its actions in the ReadMe file.

Please Squeeze the Cheese — For designers who want to squeeze the most out of their HTML, both utilities are well suited to the task. Mizer 1.2 is available for purchase through TidBITS sponsor Digital River for $69.95; although a demo is not available, Antimony Software guarantees a full refund within the first 30 days. VSE HTMLTurbo is available as a 1.2 MB download. The demo version is fully functional for 21 days, after which it costs $79.95 to obtain a registration code.

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

<http://www.vse-online.com/>

For more than ten years, Apple’s HyperCard has been a seminal product, single-handedly defining scripting and authoring, spawning a host of imitators, and enabling users to do astonishing, one-of-a-kind things with their computers simply by trying. Few things are closer to the true spirit of the Macintosh than HyperCard.

Now, without warning, Apple appears to be pulling the plug on this software original, just on the eve of its rebirth as a sophisticated QuickTime authoring tool. Explaining HyperCard’s predicament means backtracking through a bit of history, but also reveals HyperCard’s fundamental vigor is as intact today as it has ever been.

And So It Begins — HyperCard is one of the most difficult-to-describe software programs ever conceived. Most applications perform a particular set of tasks: word processors manage text and documents; databases store and retrieve information; spreadsheets store data and perform calculations; Web browsers display online content. These programs have well-defined, concrete purposes: most Macintosh users could explain what these programs do and why someone might want to use them.

Not so with HyperCard: it’s abstract. It can be made to do virtually all the functions handled by the applications above – some better than others – and many more tasks besides. It’s one of the first true authoring programs, enabling users to organize information (graphics, text, sound, movies, and more) and use strong built-in navigational features and scripts to create unique functionality for precise needs. If this sounds suspiciously like programming, it can be: HyperCard includes HyperTalk, a pioneering English-like scripting language that serves as many people’s introduction to programming even today. HyperTalk enables scripters to create everything from multimedia games, kiosks, and presentations to address books, custom invoicing systems, product demonstrations, online help, and much more, Plus, HyperCard has been quick to support key technologies like AppleScript, PlainTalk, QuickTime, and (importantly) WorldScript.

<http://www.apple.com/hypercard/>

Who Are You? HyperCard’s flexibility has been its greatest strength, and its abstractness has been its greatest hurdle. What does HyperCard do? Is it a playback engine? Yes. A development tool? You bet. A personal information organizer? Sure. A database? Indeed. A scripting environment? Yes. Many other things? Always.

But is HyperCard a multimedia authoring tool? Sort of. When HyperCard debuted in 1987, it was one of the first multimedia programs. Those were the days of expensive black-and-white Macs, and HyperCard’s then-inspiring presentation capabilities owed a great debt to its primogenitor, Bill Atkinson, creator of QuickDraw and MacPaint.

But HyperCard’s presentation and graphics are grounded in that black-and-white world, and to this day the HyperCard application still can’t think in color. Over the years, third parties and finally Apple grafted extensions onto HyperCard that display color pictures, colorize interface elements, and support QuickTime. These add-ons attest to HyperCard’s flexibility and let it serve as the basis for products like the wildly popular Myst. But these gizmos have major omissions, are often awkward, and can’t disguise the fact that HyperCard is essentially a penguin in a technicolor dreamcoat.

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

With extensive effort HyperCard could be rewritten to think in color, but that opportunity has never appeared. With 1991’s HyperCard 2.0, organizational and business constraints intervened, partly because HyperCard was moving to Claris and becoming commercial. At Claris, HyperCard languished and was returned to Apple where it languished some more. Meanwhile, products like SuperCard and Director evolved into mature, color-capable authoring environments. HyperCard’s developers eventually added numerous enhancements – including the capability to build standalone applications, plus AppleScript and WorldScript support. But the needed rewrite for full color was never within reach.

What Do You Want? Then, Apple’s QuickTime 3.0 project began. Three years ago, QuickTime was Apple’s success story in a cacophony of falling profits, dwindling market share, and eroding customer confidence. QuickTime was setting the standard for digital video, and Apple was betting heavily on QuickTime’s success.

In QuickTime 3, a "movie" is fundamentally just a container for various data types and can hold discrete objects – like a button – that might not have anything to do with audio, video, or traditional media. As long as these objects could receive events like mouse clicks, there was no reason they couldn’t respond to actions from the user or other objects. That was the germ of the idea behind QuickTime Interactive (QTi); all QuickTime needed was a way to specify how objects should interact with the user and each other. QuickTime needed a scripting language.

Apple already had a scripting language and authoring tool in HyperCard, and it was soon a done deal. HyperCard 3.0 would be re-implemented on top of QuickTime using QuickTime data formats, turning HyperCard 3.0 into an editor for interactive QuickTime movies. Projects authored in HyperCard would inherit all of QuickTime’s color capabilities and would work in any application – and on any platform – that supported QuickTime. The beleaguered, enervated HyperCard group became part of the high-profile, well-funded QuickTime group, and HyperCard aficionados rejoiced.

Apple has shown HyperCard 3.0 repeatedly over the last few years. The demos have been promising, with HyperTalk scripts embedded in QuickTime objects, HyperCard stacks running in Web browsers via QuickTime, and HyperCard displaying Internet content within stack windows. Many people have seen versions of HyperCard 3.0 in action and heard Apple representatives express their commitment to shipping HyperCard 3.0, although no firm release dates were given.

In 1997, Apple quietly informed developers it planned to ship QuickTime 3 without QTi. Since QuickTime 3 was the first fully cross-platform release, it made business sense to establish QuickTime 3 as soon as possible. Apple pushed QTi back towards QuickTime 4.0 but repeated its commitment to QTi and HyperCard 3.0. In the meantime, the HyperCard team released updates that brought HyperCard up to speed with Mac OS 8 and then rolled in QuickTime 3 scripting capabilities, along with a few other features.

Why Are You Here? In the last two weeks, however, troubling news has filtered out of Cupertino. Although HyperCard engineers have long worked on QuickTime itself- in part to ship QuickTime 3 and lay the necessary groundwork for HyperCard 3 – as of a few weeks ago the entire HyperCard team had been moved to QuickTime development. Right now, there is no HyperCard team, there are no plans for a HyperCard team, and no work is being done on HyperCard. According to reliable sources, Apple’s Vice President of Worldwide Product Marketing Phil Schiller announced at an employee meeting in late October that HyperCard would no longer be developed. Despite a sustained hue and cry from the HyperCard community, Apple has made no official statement on HyperCard’s future.

Why would Apple abandon HyperCard 3.0? Theories abound, but those that make the most sense to me involve QuickTime, not HyperCard. With QuickTime 3, Apple introduced an enormous, cross-platform media architecture that has been adopted as the basis for the ISO MPEG-4 standard. That’s a substantial achievement, and one of only a few areas where Apple clearly dominates a portion of the computer industry. Estimates place QuickTime on more than 24 million Macs worldwide, and a survey by Media Metrix estimated that QuickTime was installed on almost 70 percent of the 35.3 million Intel-based PCs in the U.S in March 1998 – and that was before QuickTime 3.0 shipped.

<http://www.mediametrix.com/corp/press/press_ mm58.htm>

Thus, QuickTime is subject to more industry buffeting and machinations than other Apple technologies. Microsoft has long fought QuickTime’s dominance, particularly in Windows. Materials from the Microsoft antitrust trial reveal how Microsoft may have pressured companies to drop support for QuickTime and attempted to inveigle Apple into splitting the digital media market. Regardless of the truth of these allegations, it’s clear that Apple spends considerable time and effort protecting the ground QuickTime has captured.

<http://www.seattletimes.com/news/technology/ html98/appl_102998.html>

<http://www.seattletimes.com/news/business/ html98/micr_092098.html>

Given these pressures, I wouldn’t be surprised if Apple had to make concessions to digital media developers – most of whom develop for both Windows and the Mac – to secure their support for QuickTime. One of those concessions may well have been a promise not to compete with QuickTime authoring and production software from third parties. Since HyperCard 3.0 is, in essence, an editor for interactive QuickTime movies, developers like Macromedia, Adobe, Sorenson Vision, TrueVision, Equilibrium, and Electric Image might balk at Apple developing and marketing an interactive QuickTime movie editor. Conceptually, the situation may not be dissimilar to Apple’s rock-and-a-hard-place conundrum with Emailer: abandon the product and alienate your users, or press forward and alienate your developers.

<https://tidbits.com/getbits.acgi?tbart=05129>

So, now HyperCard has no development team, and QuickTime Interactive’s capabilities are available only in small part as a set of low-level APIs for QuickTime application developers.

<http://developer.apple.com/techpubs/quicktime/ qtdevdocs/REF/tp_qt3sprite_wired.htm>

Where Are You Going? Remember how HyperCard got into this situation: lack of integrated color, which seriously hinders its utility for multimedia authoring. This is a classic example of how HyperCard’s abstract nature is its greatest liability. HyperCard fills a myriad purposes for many Macintosh users without authoring a moment of multimedia. For example, HyperCard holds TidBITS together: all of our automation for subscription management, issue distribution, database management, Web site production, and mailing list archiving is built in HyperCard. Adam even distributed the first 99 issues of TidBITS in HyperCard.

People regularly hire me to work on HyperCard projects for business, education, and home users. Few of these projects use multimedia capabilities. They provide access to information and serve as tutorials for students learning to program or learn foreign languages; tie together applications in ways AppleScript can’t handle alone; control laboratory devices; and much more. One of my largest HyperCard projects is Golem, an Internet robot that performs URL verification and Web page analysis for private clients, including big industry names like Microsoft. Others use HyperCard for everything from customized databases and contact organization to Web site management, television subtitling, molecular modeling, and content development for CD-ROM and Web-based projects. For startling examples of HyperCard’s flexibility, read some of the HyperCard stories submitted to Jacque Landman Gay’s Web site. In many cases, these projects were the sole reason Macs were purchased in the first place.

<http://www.hyperactivesw.com/HCStories/ stories.html>

Some may argue HyperCard has outlived its utility: more modern programs can perform many of its functions. Utilities developers can dive into the fast-moving REALBasic. Scripters who integrate applications can build interfaces with FaceSpan. People accustomed to HyperCard can try multimedia authoring in the color-savvy SuperCard, which IncWell is reviving after purchasing from Allegiant. HyperCard users who need cross-platform capabilities can look at MetaCard, which can deploy to Windows, Unix, and the Mac. Scripting geeks can investigate Userland Frontier’s automation and Web publishing capabilities. Of course, multimedia authors can plunk down a heap of money on Macromedia Director, the 400 pound gorilla of the multimedia industry, and those who want to plumb QuickTime 3 can build interactive movies with products like Totally Hip’s Web-oriented LiveStage.

<https://tidbits.com/getbits.acgi?tbart=05043>

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

<http://www.incwell.com/SuperCard/SuperCard.html>

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

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

<http://www.macromedia.com/software/director/>

<http://www.totallyhip.com/Link/ ProductsLiveStage.html>

As good as some of these products are, none fully match HyperCard’s flexibility, although many far exceed HyperCard’s multimedia capabilities. Most of these products can’t use the myriad externals available to HyperCard. Many have minimal or non-existent support for AppleScript or other OSA scripting languages. Some have restrictive scripting dialects, few offer HyperCard’s integral navigation and data storage capabilities, and (to my knowledge) none offer the WorldScript functionality so important to international users. HyperCard remains in a class by itself.

What Can You Do? Today, HyperCard’s fate is unclear. If HyperCard matters to you, let Apple know how and why you use it. If Apple sees that HyperCard sells Macs, offers unique Macintosh capabilities, and helps keep Macs in places where they would have been replaced by PCs long ago, Apple may better understand HyperCard’s unparalleled value to the Macintosh industry.

Jacque Landman Gay of HyperActive Software has organized a snail mail campaign to explain to Apple Interim CEO Steve Jobs how HyperCard is important to Mac users. (An email campaign would be tantamount to mail-bombing; no one likes to be mail-bombed.) Numerous well-reasoned, polite letters from HyperCard users should be effective for putting HyperCard’s status back on the table, which in turn should give Apple’s HyperCard engineers – many of whom have worked thanklessly for years to sustain the product – the leverage they need to secure HyperCard’s future. Everything you need is on HyperActive’s Web site; the rest is in your hands.

<http://www.hyperactivesw.com/SaveHC.html>