Hide full article
For many years, FileMaker Pro has been one of my standard tools for storing and retrieving structured information: with FileMaker, it's easy to build yourself an address book or a guide to your music collection, and its thorough scriptability makes it splendid for exchanging data with other applications. Version 3.0, dating from 1995, introduced relational database capabilities; but subsequent versions offered so little (and cost so much) that I never upgraded further. Then recently version 5, instead of improving core features, introduced some vastly higher pricing, and I wondered whether I hadn't backed the wrong horse.
<http://db.tidbits.com/article/05576>
Around this time I learned, with surprise, that Odesta's Helix was still alive. I had used Helix briefly in 1991, but then lost track of it. Helix (soon re-dubbed Double Helix) had been one of the earliest Mac products, dating back to 1984. It was ahead of its time, but was sent down an unproductive development path - basically, much time and effort went into creating a VAX-based server for Helix, whereupon personal computers suddenly got faster and cheaper than a VAX would ever be (can you say Mac IIfx?) - and the company split up in 1992. The product was renamed again, as Helix Express, and more or less languished. Now it has been taken over by The Chip Merchant, which is run by a Helix enthusiast, and is being subjected to the nightmarish process of modernizing ancient legacy code, fixing memory leaks, and squashing bugs. Meanwhile, amazingly, the basic Helix product, now renamed Helix RADE (Rapid Application Development Environment), is free.
<http://www.helixtech.com/>
<http://www.helixtech.com/history.html>
In the Nucleus -- Helix RADE (I'll just call it Helix) is an environment for designing databases and then working with the data (inputting, viewing, querying and sorting, exporting, printing). The design process is unusually visual and object-based, revolving around icons and windows, in ways somewhat reminiscent of Prograph (see "Get Your Hands on Prograph" in TidBITS-312). The terminology is also rather quirky, so bear with me.
<http://db.tidbits.com/article/01160>
A database file created by Helix, containing the database structure and the data, is called a "collection." Only one collection can be open at a time. It is represented initially as an empty window, into which you drag icons to represent relations; each relation is a table of data, where all the records (the rows) will consist of the same fields (the columns) - what FileMaker would call a database. Thus, a one-relation collection is a flat-file database; a two-or-more-relation collection can be a relational database, as I'll explain later.
Double-click a relation icon, and another empty window opens, into which you drag more icons. These are of many different types:
A field is a category of data that each record is to have, such as "last name" or "age".
An index is an instruction that a sorted order be maintained for one or more fields.
An abacus is a calculation, such as "first name followed by space followed by last name".
A template is like a FileMaker layout, where you arrange fields on the page.
A view is like FileMaker's browse mode; it portrays some particular template, but is where you actually enter and view live data.
A query is a form, attached to a view, which you can open to change what subset of the data is shown in that view.
A post is an action to be performed automatically when you do something in a view, such as entering data; chiefly, it's a way of maintaining automatic integrity of data across relations. I'll talk more about this later.
Each icon, once dragged into a relation window, just sits there until you do something with it. First, you name it, just like naming a file in the Finder. Then you double-click it to open its window and edit it. In a field's window, you specify its data type and validation rules. In an index's window, you specify what field(s) to sort. In an abacus's window, you describe the desired calculation: this too is completely icon-based, as you drag icons representing operations and fields into the window and arrange them in a dataflow diagram. For example, to say "first name followed by space followed by last name", you drag in a "followed by" icon, then drag the "first name" field into its first part and set a space character as its second part; then you drag in a second "followed by" icon, feed the output arrow from the first one into the second's first part, and drag the "last name" field into its second part.
A template window starts out as a blank sheet of paper with some rectangle drawing tools. What you draw is crucial, because a view, you recall, is the only place where you enter or examine any actual data, and every view is a representation of some one template; so if you ever want to be able to set directly the value of a record's "last name" field, that field must appear in a template!
Templates come in two forms. A template showing fields for one record at a time is an entry template; in a view that uses an entry template, you navigate records via Next/Previous Record menu items. A template showing fields for all records at once is a list template, and is established by drawing a repeat rectangle around the data to be listed. For example, if you draw a repeat rectangle around the "last name" field in a template, then a view that uses this template will list the last name values for all the records at once. (By "all", I mean "all that this view shows"; you can limit or order the set of data shown, with a query or index attached to a view.)
A list template can appear within another template. For any view that uses the outer template, you specify a field in each template's relation; the inner template will then list only those records of its relation where the data of those two fields match. This is how you make your database relational. The display of the inner template material is extremely flexible, so that Helix's implementation of relationality is extremely powerful: for example, you can specify the sort order of the inner list; you can specify a query further limiting the inner list's records; and you can nest list templates, for additional layers of relationality.
Helix runs in two modes, developer mode and user mode. Developer mode is what I've been talking about all this time. In user mode, you see only certain views and menu items, and have only certain types of access to those views, as predetermined in developer mode. Surprisingly, this can be useful even if you are your only user; when you are done designing, it's nice to switch to user mode, eliminating extraneous windows, and just enter and retrieve your data.
Acid Test -- To test Helix for this review, I reproduced, as a Helix collection, the structure, data, and functionality of a system of related FileMaker databases that we used when I was editing a Mac programming magazine. This system had proven almost too much for FileMaker to handle, and I wanted to see if Helix could do better. I will now provide some gory details, so skip the next couple of paragraphs if you have a weak stomach.
The system tracked articles submitted and published, plus payments to authors. An article could comprise more than one "fragment" (for example, in our Readers Tips column, each tip was a fragment); so there were no authors of articles, only authors of fragments. And a fragment could have more than one author. So far, that's three databases: articles, fragments, authors. For every article, we needed a list of author-fragment-payment triplets. But how, in FileMaker, could a portal in the articles database show authors? Authors had no direct relationship to articles, and portals could not contain portals, or be limited through a query.
Our solution was an extra database, an intermediate "link" pairing fragments with authors (and payments). The articles database could have a portal on this fragment-author database; but how would it know which fragment-author pairs to list? Clearly, the article database's key must match an article key in the fragment-author database. But where would that key's value come from? There were no articles in the fragment-author database; articles were paired with fragments in the fragments database! So we forced each record in the fragment-author database to learn what article it was a part of, through a lookup on the fragments database.
This was just one of many complex portal/lookup tricks we used to hook up the information. The problem here was not the extra fragment-author database (that's standard procedure with many-to-many relationships), but the dreadful fragility of the data's integrity. Lookups in FileMaker were not live, so we had to keep running a script in the articles database that made the link database refresh its lookups. When creating a new article, tasks had to be performed in the right order, to ensure that the fragment-author database was updated correctly behind the scenes; despite precautions, it could easily acquire invalid records, and had to be double-checked often by hand.
The Helix version turned out to be far simpler and far more robust, and took me just two days to create after reading the documentation; it would have been much quicker for an expert. To list fragment-author pairs within a view of an article still requires the fragment-author relation, but in a much more straightforward way: an articles template holds a fragments list template, keying on the article, which in turn holds a fragment-author template, keying on the fragment. Integrity is maintained behind the scenes through a post: when you enter an author for a fragment in the fragments relation, Helix automatically creates a new record pairing them in the fragment-author relation - but only if they are not already paired.
The Helix version is also far more comprehensible to a developer. FileMaker hides crucial information in various modal dialogs: the Define Fields dialog and its Options sub-dialog, the Field Format dialog, the Portal Setup dialog, ScriptMaker and its Script Definition sub-dialog. In Helix, on the other hand, everything is a top-level entity, an icon in a window, and no icon window is modal, so you can open and study many at once - indeed, in an icon window you can double-click another icon's name to open that icon's window! You can view a relation window as a list (like Finder Name view), showing useful information about each icon. Each icon also has a Get Info window, where you can enter a comment and see the names of all icons that use this one. Finally, Helix prevents or warns you if you perform any invalidating action, such as trying to delete an icon used by another.
Helix derives great fluidity and power from the object-based independence of its entities. Consider calculations. In FileMaker, a calculation is basically a kind of field. In Helix, an abacus is just an abacus, and so you can use it however you like: it can provide data or validation for a field, a sort order for an index, a limiting query for a view or for a field entry pop-up menu. On the other hand, things that don't need to be entities, are not. In FileMaker, relationality between databases is one more setting to be reached through a series of dialogs; but Helix knows that this is just a way of looking at data, so it's merely an aspect of a particular view. The general feeling in FileMaker is that you start with a database and drill into it from various places to access its parts; in Helix, you start with the parts, and tie them together to form a database.
Under the Electron Microscope -- Helix is not for the faint of heart. The manual (fortunately due to be rewritten) is a massive series of PDFs, more a specification than an explanation: it has some typos, and the pictures are mostly indecipherable, a serious flaw for a visual language. It fails utterly to teach you the Helix way of thinking, the peculiar culture and tricks handed down by past masters. The learning curve is hyperbolically steep; either you'll suddenly have an "Aha" moment and pop past it, like bursting through a wall, or you'll fall off the mountain.
Helix still has some bugs - I crashed several times - and many faults. Revision continues, so some of these may soon vanish; but at present, the new user is likely to find Helix quirky and fossilized. Over the years, Helix has grown like Frankenstein's Monster; new bits were sewn on without touching old bits, many of which date back all the way to 1984 - and they feel like it, especially the interface, which incorporates no modern elements such as balloon help or tabbed panels.
Navigation is a big problem. There is no Window menu (a dreadful omission), no hierarchical outline view of your collection, and no way to navigate upwards (from an Index window to its containing Relation window, for example). So you spend most of your time lost; even if you can see an icon's name and open its window, you may not know what relation it is part of, so you have to drill down into every relation looking for it.
Certain crucial windows are incomprehensible unless you're very experienced or looking at the manual, and often present their information in a clumsy piecemeal fashion. The View Setup window, where you create the relationality between an outer and an inner template, is atrocious: the space is too narrow for the names you're trying to read, and if you add another inner template the dialog forgets all its previous settings.
You cannot edit data in a list view - though you can double-click a listed record (or multiple selected records) to open it in an entry view where you can edit. Inner lists don't scroll, or support multiple selection. On the other hand, list views support user-selectable sort orders, while entry views don't - a curious asymmetry.
Here's a final miscellany. You can only have eight colors. A multiple-choice field can't be represented as radio buttons. There aren't enough menu shortcuts, because the Command key is the only modifier. There is no way to learn which record of the current found set you're looking at. An abacus has no find-and-replace functionality, so sometimes you have to export your data, munge it, and re-import it.
Replication & Evolution -- Helix is internally scriptable, via menu items or buttons in views; but the only scriptable actions, besides opening views, are those normally available as menu items. That's very weak compared with FileMaker, but posts often make a script unnecessary, and buttons can implement a form of branching and looping, which scripts themselves lack.
Helix can't run AppleScript scripts, so any inter-application communication must originate externally. It responds, not to AppleScript, but to some rather oddly structured Apple events; you'll need a program like Frontier to send them. The repertoire is very limited - fetch a record, load a record, delete a record - but you could probably manage by arranging your database cleverly beforehand, perhaps with an occasional boost from QuicKeys or OneClick. So if the question is, "Can Helix act as a CGI application behind my Web server?" the answer is: Maybe, but not alone, and not easily.
I have not seen the commercial Helix products; there are two. Helix Converter ($500) turns your database into a stand-alone application (in permanent user mode). Helix Client/Server lets multiple users access a database via AppleTalk. It might be preferable for serious CGI work, and without it you can't run two copies of Helix on the same local network. It starts at $300 for two clients and goes up from there.
My exploration of Helix has certainly made me an addict, if not a convert. Once bug-squashing ends, the next big step will be a feature release. It isn't clear what this might include - a truly modern Helix might benefit from an overhauled interface, fuller scriptability, and TCP/IP and ODBC awareness - or what the future pricing model will be. But the present pricing model is unbeatable: a powerfully relational database program at no cost. You have nothing to lose but your dependence on FileMaker.
Helix requires a PowerPC-based Macintosh running System 7.5.5 or later.
<http://www.helixtech.com/download.html>
[Note: This article owes much to the generous personal attention and informative guidance of Matt Strange of Helix Technical Support.]
