My garden will never make me famous, I'm a horticultural ignoramus, I can't tell a string bean from a soybean, Or even a girl bean from a boy bean.
--Ogden Nash
I think that I see an undiscovered product niche. It's a vertical product niche, with thousands of potential customers and the prospect of multiple sales to each customer. The niche is virtual shrubs.
Macintosh-Aided Design magazine recently ran a good article on landscape design, 3-D graphics, and vegetable verisimilitude. Daniel Earle's "Three-Dimensional Representation of Plants in Landscape Design" (June, 1990) described how landscape designers and architects can use 3-D modeling tools to produce the perspective views of trees and shrubs necessary in their work.
Current 2-D object-based approaches, according to Earle, allow creating libraries of plant symbols, and freehand drawing programs produce acceptable freehand results; but 3-D modeling approaches have not been impressive: Present computer approaches that create plants that look like lollipops, rockets, or shaped concrete do not adequately satisfy planting design considerations. It's necessary that plant forms exhibit freedom, variety, and organic form, otherwise they look like extensions to the hardscape around them, rather than offering a contrast.
Earle proposes using 3-D graphic tools to model trees and shrubs, rather than just patching together a few geometric forms. He identifies essential elements of structure and form of plants, and shows how to develop, without excessive effort, workable plant forms.
It struck me as I read the article that it ought to be possible to do better than workable plant forms and that it ought to be easier. Earle's approach definitely leads to better-looking trees and shrubs, but it's ultimately not different in kind, but only in degree, from the 2-D plane geometry models he criticizes. Trees aren't really made up of plane geometry objects and conic sections. Why not use fractals?
As I've pointed out here before, fractal geometry, the new branch of mathematics that Lucas films has used to produce pseudonatural forms in science fiction movies, is remarkably good at modeling natural forms such as coastlines, mountain ranges, and foliage. Certain classes of fractals are particularly good at mimicking trees and shrubs. This is because, so far as I can understand it, the recursive growth pattern of the fractal reflects a similar growth pattern in nature. Fractals know some of Nature's algorithms.
My own explorations through the maze of these shrubby fractals have run up against two thorny hedges: performance and predictability. Fractal algorithms are viciously recursive, and any more than a few levels of recursion takes unacceptably long to execute on my hardware (and more to the point, in my code, but improving the code will only shift the performance barrier back a few levels). Further, although I have generated some attractive and natural-looking plant forms, the process is hit-or-miss: I don't know the relationship between the parameters I can manipulate and the defining features of the sorts of plants I can model.
For the needs of landscape designers, it seems to me, the performance problem is not critical. Their needs are for simple but evocative and recognizable images. A picture should be recognizably a birch tree or a particular variety of succulent, but rich detail is not desirable. Even the simple algorithms and implementations I've played around with should be able to meet these performance requirements.
If the predictability problems were solved, fractals would, I think, take over the field. The advantages are compelling:
So I think that somebody is going to make money selling libraries of virtual shrubbery. Libraries of natural-looking trees and shrubs ought to speed the landscape designer's work, and ought to sell well.
The simplest implementation of the idea would be to set up a plant plant (wait, make that a virtual shrubbery nursery), and to crank out libraries of plant forms in a standard 3-D format. This approach, though, would lose some of the benefits of using fractals. The desired amount of detail could vary, and a fractal generator function can lay on as much detail as you can sit still for. Perhaps a better distribution model would be as a smart picture; some sort of object, containing the generator function, an interface allowing the input of a recursion level, and the minimal code required to execute the generator function, to unfold the function into a graphic image. The recursion level would control the degree of detail in the resulting image.
By creating such smart plants, one would belie the old saying, "You can speed up horticulture but you cannot make it think."
After three years we still don't know what HyperCard is, but it's now a full-blown product category. I don't mean stackware; I mean -- well, that category of uncategorizable tools that people are using to do product prototyping or to produce online help systems, front-ends to remote databases, stand-alone kiosk systems, as well as simple databases of text, pictures, sounds, and code. Apple's HyperCard, Silicon Beach's SuperCard, Symmetry's Plus, Asymmetrix's ToolBook: I've taken to calling these tools hypermedia authoring systems, a pompous-sounding expression that is, at least, nebulous enough to capture a lot of their uses.
And they have a lot of uses; or better, people are putting them to a lot of uses. These products, including ToolBook, which is only a few months old, have bent to winds from all quarters. ToolBook is already in use, for example, in hardware and software firms; Mac developers, traditional DOS vendors, and mainframe software vendors; multimedia software vendors, database companies, and compiler vendors.
The mere fact that people are using them for a wide variety of purposes doesn't mean that they are good tools for any of those purposes. In fact, an argument could be made that -- within certain limits -- widespread use of a development tool is evidence of its unsuitability for serious development work. There are, after all, only so many serious developers in the world, and any tool being used by more people than there are serious developers is ipso facto not a serious development tool. The argument is slippery, but the conclusion it reaches is one that most serious developers would accept: HyperCard and its ilk are not serious development tools.
I can't challenge the conclusion head on, but there are degrees of seriousness, and I'd like to present the case for an important increase in the seriousness of these tools. I have just finished writing reviews, for various publications, of the latest versions of all four of these products (the latest version was also the first version in the case of ToolBook). My cumulative impression after doing all the reviews is that the current versions of these products represent a new level of seriousness for the product category; that's my impression, and I'll present the evidence so you can decide.
Apple took a long time in releasing HyperCard 2.0, but managed to justify the wait. If you are familiar with HyperCard 1.x but haven't seen 2.0, you should appreciate the new features. If you are unfamiliar with HyperCard, you may be surprised at the essential elements of a development tool that it was missing. Either way, it should be clear that the new version is a significant improvement.
First, HyperCard now gives much greater control over the user interface. Formerly, it restricted you to the HyperGhetto of a single window of fixed size, menu structure, and appearance. You could always spot a HyperCard application. Now, you can create arbitrary-sized and -shaped windows, open several windows (hence several stacks) simultaneously, and control the menus completely. You can create external windows (more about that momentarily) and floating palettes. You can also trap all keyboard events.
Second, the development environment is more serious. HyperTalk is now compiled, the script editor is more useful, and there's an integrated debugger.
The modal dialog box that served as a script editor in HyperCard 1.x was one of its more annoying features. HyperCard 2.0 has a new script editor that fully supports the edit menu, horizontal scrolling, multiple script editing windows, search and replace, and triple-clicking to select a line. You can comment or uncomment blocks of code automatically. The script editor uses document windows, so you can move freely between the card window and the script editor window. HyperTalk code is now compiled to RAM rather than being interpreted, and only source code is saved on disk; the script editor always loads the script from disk to edit it.
The script editor is integrated with a debugger, and errors now bring up a dialog box allowing you to jump to the offending line in the script under the script editor or under the debugger. The debugger supports setting multiple permanent or temporary breakpoints, and there are two windows for tracking the values of variables and all messages sent. You have some options in what messages get tracked: Unused and idle messages are by default not tracked, but can be.
Third, there's a new external command (XCMD) interface, which Apple used to create the new development environment. The script editor, debugger, message watcher, and variable watcher all are XCMDs. As a result, you can replace any of them with third-party tools simply by changing the name of a global variable. The new XCMD interface is different enough that existing XCMDs that make assumptions about memory allocation may not work with HyperCard 2.0. But the new interface is such an improvement that most existing XCMDs probably ought to be rewritten to take advantage of its new features, anyway.
XCMDs can now run concurrently with each other and with HyperCard. You can set an XCMD's priority by specifying the time between idle-time calls to the XCMD. Note, too, that HyperTalk scripts now run in the background under MultiFinder.
XCMDs can now create and manage their own windows. These new external windows can be document windows or windoids, and can use color if color QuickDraw is available. Any event pertaining to the window, such as mouseDown or activateEvt, will be passed to the XCMD that created it. The standard HyperTalk get and set syntax for properties has been extended to external windows. Mostly, the XCMD controlling the window should handle the properties of the window, but HyperTalk will handle the loc and visible properties of an external window if its XCMD doesn't. A separate tool, freely available but not packaged with HyperCard 2.0, will support the creation of palette windows.
Fourth, the language has been enhanced in many ways that increase programming flexibility and power. The message hierarchy can be modified. The do command now handles multiline containers. The commands start using and stop using manage the addition and deletion of stacks to the message-passing hierarchy; up to ten stacks can be added between the present stack and the Home stack. And there is now syntax in HyperTalk for checking for the existence of an object, similar to SuperTalk's exists function.
Commands that in the past brought up a modal dialog box and therefore could not be automated have been changed to allow dialog box choices to be passed as parameters. Dialog boxes now size themselves to the text supplied (up to approximately 240 characters). In the case of the ask command, this applies to the prompt string and the default response. And all dialog boxes can be dismissed by Command-period.
ToolBook has capabilities that make it particularly interesting, partly the result of its knowing how to use DOS and Windows capabilities. While I've enjoyed playing with the toy applications Apple supplied to developers to demonstrate the interapplication communications capabilities coming someday in System 7, I've actually written ToolBook applications that message one another via DDE, doing today what Apple is promising for next year. And ToolBook's DLLs are a step beyond even HyperCard's new XCMD interface.
Like so many other things, this category of software has been made more significant by the release of Windows 3.0. HyperCard stacks will soon be portable to ToolBook format, ToolBook runtime is being bundled with Windows, Zenith is bundling ToolBook with all its 386 machines. If there was a market for the products you develop with these tools, and there was (it just wasn't the market a lot of people thought it would be), then the market is suddenly an order of magnitude larger. I'm taking it seriously enough; as I've mentioned here before, I've been putting together a newsletter for users of hypermedia authoring tools, and the first issue is finally about to go to press. Working on the newsletter, talking to the developers, I began to see that something is indeed afoot. ToolBook was released at a press conference featuring 26 third-party developers and has already spawned a dedicated newsletter; and HyperCard 2.0 comes out the chute with three books, and more to come (my HyperCard bookshelf has over two dozen volumes).
Of course, given the memory demands of these tools, one could argue that it's Macintosh, System 7 and Microsoft Windows that are giving them credibility, by forcing everyone to install more memory.
For more information on fractal horticulture, see Daniel Earle, "Three-Dimensional Representation of Plants in Landscape Design," Macintosh-Aided Design, June, 1990; A.K. Dewdney, "Mathematical Recreations: Creating Fractal Landscapes With a Home Computer," Scientific American, May, 1990; or Mike Swaine, "Fractals: A New Dimension in Scripting," HyperLink magazine, November-December, 1989. Or send for Barnsley's book, Fractals Everywhere, or his book-and-disk system, The Desktop Fractal System, both from Academic Press.
For more support for my argument on the maturation of hypermedia authoring tools, see my article, "Author! Author!" Personal Workstation, August, 1990; my reviews of the latest versions of SuperCard, Plus, and HyperCard, slated for the October issue of MacUser magazine; or issue #1 of my new hypermedia authoring journal, HyperPub. For details, write to "The Prose Lab," Dept. DDJ, 31 Patrick Road, Santa Cruz, CA 95060. Or call me at 408-459-8564.
Now, apparently, the predictability problem has been solved. Michael Barnsley, co-founder of Iterated Systems, Norcross, Georgia, has found that by starting with a digitized natural image, say, of a coastline, and mapping segments of it to a large library of standard fractal-like transformations, you can turn the image into a formula that does a credible job of reproducing the image, at an acceptable video rate, with a compression ratio of perhaps 500:1! Barnsley has turned the insight into a business, but he doesn't seem to be filling the niche I think I see, and the basic insight is not proprietary.Is Compiled Hype Faster than Interpreted Hype?
Further Reading