Seven Minutes in Helix Heaven? Part Fantasy/Part Reality
5 September 2002-Three Minute Fantasy Check:
How big are the objects in your rear-view mirror?
Do they appear larger than they actually are? Smaller? Or exactly the right size? Is it worth taking the time to find out? In the next three minutes, you might find out something you’d really like to know.
A frequent topic discussed among Helix aficionados is the scale of Helix. What size is Helix best suited for? What size is best suited for Helix? Should I use Helix in a workgroup of 25 people? 250? 2,500? 25,000? Is bigger really better? Is smaller truly inadequate? Should you really use an elephant gun to kill a mosquito? Should you really use a fly-swatter to kill an elephant?
Let’s face it, for a lot of simple applications, there are better tools than Helix. If all you want is a portable contact database, you may really be better off with a Palm Pilot or Visor than a laptop connected to a custom-designed remote database via TCP/IP or Timbuktu.
And we are constantly reminded by people who scrape away at the Helix facade that Helix is not the appropriate tool for very large scale systems. Usually, however, the problem is not that you can’t create the application; the problem is that you can’t maintain it reliably with large numbers of users, obscene amounts of data or both.
So where is Helix most appropriate?
For starters, as a tool for an individual to interact with his or her information, there’s nothing better. It’s very clear from the mail and calls we get that people who use Helix for their personal data management are among its most fanatical devotees. Even though single-user applications don’t bring the company the kind of money it gets from client/server licenses, and even though developers rarely get involved in helping individuals write their Helix Collections, if you’re a reasonably intelligent person who wants to exact control over their personal information, Helix is far and away the best tool for the job.
Client/Server situations are different. Helix, as noted above, can be skillfully used to create virtually unlimited types of applications, to build virtual castles in the air, if you will. The meat of the issue is how many users and how much information. And again, we’re trying to make some very broad generalizations. A system where hundreds of users opening a non-graphic, one- or two-Field entry form presents an entirely different performance issue than one where that many users are trying to fill in a form with hundreds of Fields, graphics, conditional popups and other devices on it.
The only thing that can be said conclusively about Helix in a Client/Server setting is that Helix seems to shine best when functioning as the central nervous system of a small workgroup of 50 or fewer users. On what basis can this be said? The facts. The fact is that most of the existing Helix licenses are in this range. Beyond that, there’s no data to suggest that a 50-user application performs any better or worse than a 10-user application. And for the most part, these are happy customers.
Are we suggesting that Helix developers or prospective business purchasers stay away from large projects involving hundreds of users and mountains of data? No. The reason you see Helix in so few such situations is far more than technical, as we all know far too well.
But it just so happens that by a fortunate coincidence, there’s an enormous market for Helix: American small businesses, the "Land that Microsoft Forgot." America is full of small, businesses that need a handful of "departments" to be able to work together, inexpensively.
Four Minute Reality Check:
What’s coming through the front window?
OK. Our three minutes of fantasy are up. You were forced to endure this diversion so could we put you in the proper mood to sneak a little real news to you. Clearly you felt it was worth the time or you wouldn’t be reading this sentence. Maybe you spent a little more or less time getting here. Vive la difference!
The question of scale for Helix would be moot if Helix were to disappear. Twelve weeks ago we came on line and told you that we sincerely believed that Helix would not disappear. At that time, we also made three promises:
- We will help you get what you need in the way of product, upgrade, services and support.
- We will provide you with information, even if that information is simply to tell you that there’s nothing new yet.
- We will make a conscious effort NOT to raise your expectations unless we believe there is a solid basis upon which to do so.
That having been said (again), let us begin what we’re about to reveal by asking you to attempt to keep your expectations in check.
An old expression has it that you’ve got to crawl before you walk, and you must walk before you run. And another has it that the journey of a thousand miles begins with a single step.
With those concepts in mind, this summer we began to put together a team to help take Helix into the future. Everything this team has done to date has been done with an eye on the plan for Helix that has never changed.
For those of you who may have forgotten what The Chip Merchant set out to do with Helix nearly four years ago, there were three initial objectives:
- Fix all the defects in the product.
- Make it run under TCP/IP (and yes, we know it’s not quite there yet).
- Make it platform independent.
The emergence of macOS last year forced that plan to change. But all good plans must adapt to changing conditions or they will fail. We are all clearly of one mind on the importance of finishing the carbonization project.
As you have all heard repeatedly, one thing that makes this job so overwhelming is the huge, ancient code base that needs to be updated, refined, improved and slimmed-down... Rather than let more time slip away, we began that work this summer.
What began as an exercise in seeing if we could build Helix on a shoestring has resulted, thus far, in a very high degree of confidence in our ability to do certain things well. As we continue to work and learn more about untangling the beast that is the Helix codebase, we’re going to begin tackling the more ambitious aspects of the project. As more resources become available, more will be applied, but the process is again in motion.
At this point, we’ve focused almost entirely on bringing diverse parts of Helix code up to modern Apple interface standards. This has resulted in a modest cosmetic overhaul of some Full Mode Helix devices, enough to warrant the creation of a Maintenance Release of Helix. In-house testing has thus far proved the work stable enough to begin beta testing. The first fruits of this labor will appear shortly under the name of Helix 5.0.3beta1.
Changes in 5.0.3 include wider scrolling selection lists in lookup tile dialogs, view and post icons, expanded information in the Get Info window, larger dialogs (many Helix dialogs were designed to float in the center of the screen of a Mac Plus), redesign of some dialogs to better take advantage of the bigger spaces, movement of some menu commands to conform to current design standards and more.
There’s also a small handful of minor bug fixes, and we’ve included an improved Apple event called "Quit with Saving," and included a ready-to-go AppleScript to put it to use, which is an important function requested by many network administrators. This script will quit all clients on a network and save their structures.
When 5.0.3beta eventually (sooner we hope than later) becomes Helix 5.0.3, it will be available in place of Helix 5.0.2. Users who already own 5.X will be able to upgrade to it for free. Those using 4.5.5 or older versions will be able to upgrade at current upgrade prices.
Please note, however, that while the many cosmetic enhancements that make up version 5.0.3 will make the Full Mode experience a generally better one, there are no new features or performance improvements in this version.
As we get ready to begin beta testing, we thought we’d try to make good on another promise we’ve made on more than one occasion, that is to solicit your opinion. Click this link and you’ll be able to give us some feedback that, if received quickly enough, can influence some of what you’ll see in 5.0.3.
Correction:
In our last message, we accused Dr. Henry Spotnitz of being the Chief of Surgery at New York’s Columbia Presbyterian Hospital. Perhaps my fondness for the place as the locus of my appearance on the planet some 50 years ago overshadowed my penchant for accuracy. Dr. Spotnitz has informed us that he is actually Vice Chair for Research and Information Systems in the Department of Surgery. In spite of his modesty, Dr. Spotnitz remains a reasonably big fish in our little pond. We apologize for the error. [since corrected]