It’s summer in the U.S., which means many kids are out of school. Why not use the time to teach them programming? Matt Neuburg reviews Stagecast Creator, a visual programming environment geared toward kids but entertaining enough for adults. Plus, Adam suggests an alternative to Apple’s confusing naming schemes, and we note the release of QuickTime 4.0 and updates to FileMaker Pro and Synchronize Pro. Finally, you can now read TidBITS in Russian!
TidBITS Available in Russian — Thanks to the diligent efforts of Leif Halvard Silli, Zoia Nikolskaia, and a few others, you can now read TidBITS in Russian. Several issues are available on the Web now, and if you want to receive future Russian issues in email, send a message to <[email protected]>. Please help spread the word to other Russian-speaking Macintosh users! Leif and Zoia can also use additional translation help, so if you’d like to volunteer, check out the Web site for details and contact information. [ACE]
Apple Ships QuickTime 4.0 — Apple Computer has released the final version of QuickTime 4.0, the company’s all-encompassing cross-platform media playback and authoring software. QuickTime 4.0 is powerful technology, supporting an enormous variety of data formats used for video, audio, images, and other data (including MPEG, Windows AVI, Photoshop images, PNG, and FlashPix) along with a slew of compression and transport technologies. QuickTime 4.0’s most prominent new features involve streaming media such as live broadcasts or pre-recorded audio and video. Apple is seeking to extend QuickTime’s dominance in digital media production to real-time Internet-based content, competing against RealNetworks’ well established RealPlayer and Microsoft’s Media Player. QuickTime 4.0’s most visible new features, however, revolve around radically redesigned playback and application interfaces designed to look like consumer electronic devices. Apple’s QuickTime 4.0 announcement claims the new controls are "stunning" and "intuitive"; nonetheless, the revised look and feel has drawn consistent criticism – see Isys Information Architect’s evaluation of the QuickTime Player interface for a cogent example.
QuickTime 4.0 is available for free via the Internet for both Mac OS and Windows; on the Mac OS, QuickTime 4.0 requires a 68020 or better processor running System 7.1 or higher, although several features operate only on PowerPC-based systems. The installer itself is a scant 380K, but then you must choose which QuickTime components you wish to install, with typical selections entailing another 6 to 15 MB of downloaded data. QuickTime Pro 4.0, which adds authoring, editing, export, and enhanced playback capabilities, is available from Apple for $30. If you previously purchased QuickTime Pro 3, you can upgrade to QuickTime Pro 4.0 free of charge. [GD]
FileMaker Pro 4.1v2 Does Four-Digit Years — FileMaker, Inc. has released a free 1.2 MB update to FileMaker Pro 4.1v2, which enhances the way FileMaker copes with two-digit years in dates. Essentially, all dates that specify a two-digit year are now converted to dates with four-digit years, including dates in field displays, printed output, find requests, and other areas of the program. These changes help remove some ambiguities in FileMaker’s date handling create confusion amongst FileMaker Pro users and developers, especially with the approach of the year 2000. (See "Parsing Like It’s 1999" in TidBITS-475 for a discussion of Y2K issues on the Macintosh.) The update also fixes a handful of bugs and date-related importing issues, plus offers stricter validation options for date, time, and numeric values entered into fields. The FileMaker Pro 4.1v2 updater operates with the Worldwide English edition of FileMaker Pro 4.1v1; it doesn’t work with localized versions of FileMaker Pro or with any version of FileMaker Pro 4.0 or earlier. Thus, the FileMaker Pro 4.1v2 update leaves some folks in a lurch, since many existing FileMaker Pro users didn’t feel the ODBC features that appeared in FileMaker Pro 4.1 were worth paying $150 (with rebate) to upgrade. (See "FileMaker Pro 4.1 Does ODBC for a Price" in TidBITS-447.) [GD]
Synchronize Pro 4.0 Syncs over Internet — Qdea has released Synchronize Pro 4.0, an update to its industrial-strength synchronization utility that now works over the Internet. (See "Tools We Use: Synchronize" in TidBITS-482 for a review of Synchronize Pro’s sister utility.) Synchronize Pro enables you to back up, synchronize, or mirror files using TCP/IP; as a result, local network operations perform faster than using AppleTalk. Copying or comparing files can be automated and scheduled. The utility can also initiate and close AppleTalk Remote Access connections, mirror AppleShare privileges to other file servers, and shut down the computer or put it to sleep. A limited version of Synchronize Pro 4.0 is available as a 1.8 MB download and works for free on folders of 10 MB or less. The unrestricted version of the program costs $100. [JLC]
Back in late 1993, I teed off on Apple for the proliferation of Macintosh models that were then appearing. That was around the time the Performa line (which often had models identical to the LC line) expanded beyond understanding, with model numbers sometimes indicating nothing but different software bundles or retail outlets. I based my complaints primarily on the fact that the huge number of models available made technical support far more difficult than it had been before. Makers of software and peripherals also suffered, since they had to create slightly different products for different models and somehow convey to customers which version was necessary for any given Mac. In short, by releasing many different models of the Mac, Apple caused confusion, and confusion costs money.
Recently, Apple has slimmed the product line to just a few machines in a four-cell product matrix, with the Power Macintosh G3 and the PowerBook G3 serving the desktop and portable professional markets, and the iMac and the long-forthcoming consumer portable serving the desktop and portable consumer markets. Unfortunately, Apple has over-simplified, creating new problems to replace the old ones.
Incoherence Through Simplicity — Apple’s mistake in 1993 was being too specific. Every Mac received a new model number, even if the difference was that it sold in Sears instead of CompUSA. In attempting to rectify this mistake, Apple is now erring too far in the other direction, applying the same name with no differentiating model number to machines that have significant technical differences. Apple even admits the mess, devoting Tech Info Library articles to how to identify the different machines.
Consider the PowerBook G3. In 1997, Apple released a machine called "PowerBook G3" in a case that looked like the PowerBook 3400. Then, in 1998, Apple introduced a range of PowerBooks with different processor speeds and different screens, collectively called the "PowerBook G3 Series." In 1999, Apple confused the issue further by releasing another ‘PowerBook G3" that sports USB ports and a bronze-colored keyboard (which Apple officially refers to as "PowerBook G3 Series [Bronze Keyboard]" – more specific, yes, but quite a mouthful). The original PowerBook G3 uses different memory modules from the PowerBook G3 Series or the bronze keyboard PowerBook G3. And the bronze keyboard PowerBook G3 can’t accept batteries or media bay devices from the earlier PowerBook G3 Series.
Alternatively, think about the iMac. At least here we have colors to offer a little help. The original Bondi blue iMac actually came in two versions, Rev A and Rev B. The Rev B iMacs came with Mac OS 8.5, Adobe PageMill, a different video controller with more video RAM, and a few other minor changes like a different location for the reset button and support for larger amounts of RAM. Then Apple introduced the second generation of iMacs in five colors, which had faster processors and eliminated the infrared port. These iMacs are referred to in some places on Apple’s Tech Info Library as Rev C iMacs, though an article on Apple’s developer Web site explicitly says they are not Rev C and instead calls them iMac 266s. Since then, Apple has increased iMac CPU speeds again without changing anything else.
Finally, we have the Power Macintosh G3. Before January of 1999, there were three Power Macintosh G3 form factors: Desktop, Minitower, and All-in-one, all in platinum (more commonly called beige) cases. Then Apple released a completely different Power Macintosh G3 in a curvaceous blue and white case. Differentiating the models is of course trivial, but Apple has chosen to refer officially to the new machine as the "blue and white Power Macintosh G3." The recent revisions to the line were only processor speed increases, but what happens in the future if Apple decides to release new case colors, along the lines of the iMac, or worse, changes something significant without changing the case color? What then is a "blue and white Power Macintosh G3?"
A Modest Suggestion — This situation is spiraling out of control. Devoting Tech Info Library articles to how to identify different Macs with the same name borders on lunacy. Apple and the Macintosh community need a coherent way to refer to each different model of Macintosh without having to resort to describing it physically or knowing when it was purchased. I propose that Apple adopt a model numbering scheme from the software side.
Software packages are updated frequently, with version number changes indicating the relative importance of the changes. Major releases garner integer increases, so a major release would increment a version number from 2.0 to 3.0. Minor updates, perhaps those that are released for free, generally increment the number after the decimal point, so a small feature changes could bump 3.0 to 3.1. For the purposes of argument, we’ll ignore the bug fix updates that would take a version from 3.1 to 3.1.1.
What if Apple were to apply this standard numbering scheme to their computers, purely as an aid to identification? Case changes or changes that affect hardware compatibility would pick up integer releases, with decimal releases being reserved for minor changes. So if a PowerBook changes its case or takes a different RAM module from a previous model, that’s an integer change. If, on the other hand, a newer iMac gets a different video controller with more video RAM, that warrants only a decimal change.
Under this model, the original PowerBook G3 would be a 1.0 product, the PowerBook G3 Series would be a 2.0 product, and the PowerBook G3 with the bronze keyboard would be a 3.0 product. These integer releases would be warranted because the case designs and other internal specifications differ significantly from model to model.
Speed increases wouldn’t warrant a number change at all, since they affect only performance and have little impact on the system’s fundamental capability or compatibility with other software or hardware products. Plus, speeds often appear anyway. So the platinum Power Macintosh G3s would be 1.0 machines (still separated by Desktop, Minitower, and All-in-one), and the blue and white Power Macintosh G3s would be 2.0 machines. Put it all together and you could have a Power Macintosh G3 2.0/300 to indicate a 300 MHz blue and white Power Macintosh G3.
The system shines with the iMacs, since the Rev A original Bondi blue iMac would be 1.0, with the Rev B Bondi blue iMac at 1.1. The five-color iMacs would then be 1.2, since the changes were still minor.
Keep It Simple — This system should not be a marketing tool. Version numbers should appear only as a sticker on the back or bottom of the machines instead of being integrated into case designs or marketing materials. It’s also important that the numbers remain strictly sequential. With software, many companies co-opt version numbers for marketing purposes, jumping several decimal numbers to reflect the fact that an upgrade has a fair number of new features, though not enough to warrant an integer change. Since these proposed hardware version numbers would exist only to simplify Macintosh identification for the purpose of buying RAM or getting tech support, Apple would have no reason to play marketing games with the numbers.
It may be too late to repair the confusion caused by the existing similarly named Macintosh models, but if Apple acts quickly, they can avoid exacerbating the problem, as it will every time a new Mac is released without any unique identifying features. And if Apple fails to address the situation, my next book will be entitled "Identifying the Species Macintosh: A Field Guide."
About three years ago, when the financial picture at Apple Computer was at its bleakest, a series of austerity measures resulted in the elimination of many cool employees and the long-term projects on which they were engaged. Such advanced but still nascent technologies as the Dylan programming language, OpenDoc, and ScriptX were aborted before seeing the full light of day. Among the victims was Cocoa, a wonderful program – aimed particularly at children – for constructing simple animated games. Cocoa was cool both for what it did and for how it was written: originally prototyped as KidSim in Apple’s own Sk8 authoring environment (another sad loss), Cocoa was rewritten in Prograph, a visual programming language that matched Cocoa’s own visual approach.
Apple proudly featured Cocoa in a Macworld Expo keynote speech, and several enterprising youngsters even went into business with Cocoa-based Web sites. Then it faded from sight. But Cocoa wasn’t dead, or even dormant: it was metamorphosing, at the hands of its inventors – Allen Cypher, longtime advocate of programming by demonstration, and David Smith, inventor of (among other things) icons and dialog boxes – within a new private company headed by Apple’s former Chief Scientist, Larry Tesler. Now, like a butterfly, Cocoa has emerged as the cross-platform, Java-based Stagecast Creator.
Setting the Stage — Imagine you have a rectangular grid of invisible squares; they can be any size and number, but let’s say a square is 36 by 36 pixels, and let’s say the total grid is ten squares high and fifteen squares wide. The grid holds a background picture, which you import from a GIF or JPEG image. This is the stage on which your animation takes place.
A character in your animation is a rectangle of pixels, which you can edit in a paint window. This rectangle’s dimensions are multiples of the stage’s unit squares, with a typical character being exactly one unit square; so, in our example, a character could be 36 by 36 pixels. You paint a character, and place it in a square of the stage’s grid, where it is automatically drawn with masking in front of the background (so that even within the character’s square, the background appears around the character’s outline).
Now we’re going to construct our animation, like the successive frames of a cartoon. At regular intervals, a clock will tick, and the next frame will be generated by asking each character on the stage whether it wants to change anything about how it is drawn. For example, a character might wish to be redrawn in the square to the right of its current square; if this happens over the course of several frames, the character will appear to move in a straight line to the right. Or, since each character can own many images (or "appearances"), a character might want to change its image. So, for example, if a character has an appearance where it is facing right with its right leg forward, and another where it is facing right with its left leg forward, then by alternating those appearances while also being redrawn in successive rightward squares, the character will appear to walk to the right.
Animation Rules — So far, I could be describing any sprite-based animation system. What characterizes Stagecast’s approach, though, is the way you tell a character what to do when the animation runs: you show it, by physical demonstration, the rule you want it to obey. You choose the "rule tool," click a character on the stage, and a special border appears around this character; you stretch the border to show the character the relevant area, and move the character within that area to show it what to do. For example, to tell a character to move to its right, you stretch its rule border, so that the border embraces the character and the empty square to its right, and slide the character into the square on the right. When the animation runs, the character makes that movement of its own accord.
What makes the animation tell an interesting story is that every rule has an implicit conditional component. Even in the simple example of moving the character one square to the right, the character remembers its own appearance, and the fact that the square to the right was empty, and performs the action only if both conditions are met. If you want character A to move rightwards into a square occupied by character B, you need a different rule: you must place the characters next to each other and make the rule border embrace them both, so that character A sees character B as involved in the rule. To build your animation, then, you give each character several rules, corresponding to the situations in which the character finds itself. The character tests each rule’s conditions in turn and obeys the first rule whose conditions match its situation. The art of making an animation is the art of giving each character the right rules, in the right order, so that all the characters behave correctly.
There is much more to making rules, and there are many more effects you can achieve. Characters can make other characters appear and disappear. They can make sounds. They can substitute a different background picture. They can react to key presses, or to mouse clicks, for a degree of user interactivity. Characters can have variables; they can change the value of a variable, or test a variable’s value as part of a rule’s conditions.
Clearly, then, what you’re doing as you teach a character its rules and arrange them is programming. You’re programming in a visual language, within the circumscribed environment of a little cartoon world; but you are programming. And since each character has its own rules, while multiple copies of a character share the same rules, you’re doing object-oriented programming. Thus, Stagecast is a way for children of all ages to absorb the principles of programming while enjoying the instant creative satisfaction of bringing a cartoon world to life.
Exploring the Character — It really does work. I’ve shown StageCast to some children, and they’ve caught the basics right away. They enjoy creating even the simplest character and making it move, and the notion of teaching a character its rules by demonstration presents no difficulties. Stagecast comes superbly documented with a brilliant interactive online tutorial full of wonderfully amusing animations (who can resist Bungee the jungle boy, beset by camera-clicking tourists who descend from a helicopter?), plus a printed manual in large type and simple language, and a construction kit that guides you through building an entire animation from scratch. Between the tutorial examples and the extra clip art that’s included, you can easily assemble an original animation without doing any drawing of your own. Thus, it’s easy to get started, easy to delve deeper as the mood takes you, and fun the whole time.
Delving deeper means exploring the Stagecast programming language’s higher levels. In particular, the basic algorithm which says that a character performs its first rule whose conditions are met on every frame is too limiting, so Stagecast lets you combine rules within "boxes" that obey other algorithms. A box can shuffle its rules before executing (so you won’t know the order in which they’ll be tested), perform all its rules in succession, or attempt to perform its next rule cyclically on each successive frame. By combining boxes within boxes, you can generate sophisticated algorithms. It’s easy to debug a character’s behavior, because Stagecast has a test mode where it shows you, with red and green lights and squares, which rule it will obey in the current situation, and why.
Although I can’t say enough in praise of how ingeniously Stagecast’s programming language is implemented, you’re still limited to the constructs that the language supplies, and you must learn to think within them. To give just one example, such an elementary notion as "or" cannot be expressed at all; you must make separate rules covering each case, which is painful to do and even more painful to maintain if the "or" is part of a larger set of "ands." As a result, you must be ingenious yourself, resorting often to tricks and workarounds to achieve the effect you’re after. I worry that young users will become either frustrated or imbued with undesirable programming habits. Plus, the physical nature of Stagecast’s programming environment has its drawbacks; as rules become more complicated, with boxes or multiple conditions, it becomes harder to manipulate the images on screen to see what you’re doing.
Rough Venue — This physical clumsiness, which often obtrudes itself, stems from Stagecast’s one great drawback: it’s a Java application. Although this lets Stagecast run identically on Windows and Mac, and over the Internet, you might as well not be using a Mac at all. Everything happens within a single large window – that is, it had better be large; an 800 by 600 monitor is not large enough to use Stagecast with any comfort. Stagecast’s menus appear inside this window, which is particularly hard to get used to (and on my machine, accidentally choosing a normal menu from the Mac’s menu bar causes a crash). Within this window Stagecast also draws its pseudo- or "child" windows. The whole thing feels like Virtual PC: you’re essentially simulating an alien machine within a single window.
The simulation is not particularly fast. Animations run quickly enough, but on my fastest computer, a 250 MHz Power Mac G3, actions such as starting up, quitting, and opening or (worst of all) dragging a window, are so painfully slow that you think the computer has locked up. Kids are more likely to have hand-me-down computers than the fastest G3s, so the performance problems are especially troubling.
Nor is the simulation particularly pleasant. Unfamiliar interface elements such as scroll arrows that point the wrong way and lack scrollbars, tab rectangles that reveal or hide regions of a window, and colored corners that you drag to change a window’s size, are clumsy devices, ill-behaved and too tiny to click comfortably. Type is too small as well. There are few keyboard shortcuts; everything must be done by clicking and dragging. I understand why the Java implementation was chosen, but I can’t bring myself to like it.
Still, I don’t want to leave the impression that Stagecast is other than delightful. This program is both educational and engaging; it’s also a testament to its makers’ ingenuity and originality. It’s the perfect blend of programming and play: how could any child not be attracted to it? Personally, I enjoy making animations, and then I enjoy playing with them or just watching them. And so can you. Even if you don’t buy Stagecast Creator, you can use Stagecast Player, a free 2 MB download, to run Stagecast animations, and even view them in your browser (Macintosh users must use Apple’s Macintosh Runtime for Java (MRJ) 2.1, which limits the field to Internet Explorer). You can download sample animations; I’ve even posted one of my own, a little entertainment easily cobbled together from pieces provided with the program, that I call "Beachdog". (Be patient downloading it, it’s 350K.)
Stagecast Creator retails for $60 and comes on a hybrid Mac/Windows CD. Installation requires 35 MB, plus 11 MB for MRJ, which is included. StageCast Creator is available for PowerPC-based systems only; a fast machine with Mac OS 8.1 or better is recommended. A trial version is available for download.