Two developments aim at improving the Helix end-user experience

14 July 2003--As a company doing business primarily from a web site, we believe that if something a user needs is too hard for them to find, then we’re not doing our job as well as we can. This assumes a sort of social contract in which the user will at least make a serious attempt to locate the information he or she needs.

That effort should always begin with The Helix Reference, which is available on our web site, in every Helix 5 installer, and on every Helix 5 CD we ship. It is a freely distributed resource. That having been said, there are occasional inaccuracies in any documentation. And due to the lack of a current User Guide, there’s also precious little in the way of "how to" information available for Helix users either.

In the beginning of April we posted a request for comments on some ideas we had for paid user service plans. The proposed plans were laid out in the Forums. As always, we were trying to kill as many birds as possible with the smallest number of stones. Sometimes that approach can be problematic, but it at least gave us a jumping off point in our discussion.

In that best of all possible worlds, the one where Helix is a serious player on the application development stage, the one where we’re already in macOS and we’re already in Linux and Windows, we anticipate that the need for a comprehensive package of User Services will be much greater than it is today, when Helix is struggling up the hill to the next milestone. That milestone is clearly in sight now, and we need to focus our efforts more than ever to succeed. Yet at the same time, we can never afford to ignore a call for help, because in every attempt to contact us lies the seed of something good for the caller and for Helix.

Nonetheless, answering those calls takes time, which ultimately takes money away from development. It’s no secret that we’re running on a very tight budget and that we do not have funds available to keep our engineers working 40 hours a week. In fact, none of us is working 40 hours a week; we limit out time to just doing the tasks necessary to keep the company going, attempting to divert every possible penny to engineering. But interest began to pick up when we released 5.1 last winter and things have really taken off since the 5.2 release and this resurgence has brought about an increase in the 'overhead' required to keep our customers happy. It’s a good problem to have, but we must face the fact that the time we now spend fielding support calls is seriously impacting our development schedule. An hour spent on the phone helping a customer install Helix 'costs' us one hour of engineering time. This unpleasant reality has 'forced our hand' and we have determined that we must begin charging for support services to keep from slowing the development effort any further. We aren’t happy about it, but we’ve come to the realization that the longer we put it off, the further and further away Helix 6 slips into the distance.

Fielding such calls and deciding which ones are chargeable is always going be a judgment call. The best we can do is try to be consistent in our use of judgment. Our intention since introducing the concept of paid Helix services has been clear and simple: do as much as we can for free by doing it as efficiently as possible, supplementing our efforts with expanded information on our web site. That way, we don’t waste time and resources getting to Helix 6. But when we get into areas that require more diversion of our effort, we lose time and money, so we need to at least recover the money so we can still pay for the time we’ll need. Clearly, if we can 'break even' on support costs we can allow development to go forward unimpeded.

We’ve distilled all the feedback and analyzed the results and the new 2003 User Service program can be read on our User Services home page. It takes effect immediately.

Paid services and better access to information, though, are only two of the three critical keys to user success with Helix. The third is better preventive maintenance.

Ever since Helix first shipped back in 1984, the Update Collection utility has been included with each new version of Helix so that the internal structure of collections could be modified to be compatible with each new version. Because of the nature of what Update Collection does, it has always had the bonus feature of being able to diagnose problems in the structure (i.e. the icons) of a collection.

Interestingly, the name Update Collection has itself been a source of confusion, leading some users to think they only needed to use it when updating their collections to the latest version of Helix. In fact, Update Collection should be run on a regular basis to make sure the collection’s structure remains sound. While Update Collection has never actually been able to repair damaged structure, it has always served a useful function in warning users about problems.

More critically, however, running Update Collection provides no information regarding the integrity of the data in a collection. In 1986 the Helix Utility was introduced to address this issue, and from that point on, users were at last able to ensure both the structural and data integrity of their collections.

Unfortunately, optimal use of these utility applications, combined with a rigorous program of back up, is a daunting task for the average Helix user. Collection maintenance is often neglected, as it is both a time-consuming process and a difficult one for network administrators to teach users how to do properly.

Into this breach stepped DataBright Management, a Helix consulting firm owned by Lenny Eiger. In 1993, Lenny conceived of a program called Database Checker. Later known as Database Chequer, DataBright’s utility put a user-friendly face on the Helix tools and enabled the scheduling of automatic backup and maintenance of Helix collections. Even better, it freed the user from the sheer drudgery of waiting around while the tools performed their tasks.

Over the years since its inception, Helix has benefitted from improvements in both substance and technique suggested and conceived by Lenny Eiger. Database Chequer was simply another tool Lenny had devised to make the Helix experience more productive and efficient. It fulfilled a crying need and grew to become perceived as an actual part of Helix by many users.

But Database Chequer was not owned by Helix Technologies and as such never received the widespread exposure necessary for it to become "a hit." At the same time, AppleScript (the underlying technology that made DataBase Chequer work) was being revised with every new Mac OS release, and DataBase Chequer broke each time a user upgraded their OS. With the Helix world appearing to contract significantly, when OS 9 shipped, things changed so dramatically that Lenny determined that the potential market for his product did not justify the huge expense required to make it work with OS 9. It was a frustrating decision to be sure, but in truth, it was the only practical course he could take.

People often write or call to ask when Database Chequer will be updated. We always regret having to tell users that it will--to the best of our knowledge--never be updated and that a proper backup and maintenance routine must tbe endured without the help of this valuable tool.

This has been on our minds for quite a while, so when we were working on Helix 5.2, we took the time to add the hooks to Helix that Lenny needed to do Database Chequer right. It’s too late for Database Chequer, but Lenny’s great contribution to the Helix user experience will live on as we announce today the successor to DataBase Chequer, the Helix Maintenance Manager.

HMM is scheduled to ship this fall for $100.00 US. It will be the first visible fruit of our macOS labors. It will provide users with all the functionality implemented and envisioned by Lenny for Database Chequer, including things he was never able to do because the support he needed wasn’t there. It will provide a selection of "canned" functions and be expandable for user-created functions. More details about the Helix Maintenance Manager will be published here in the weeks to come.