In This Edition: Introduction Stability And Speed 789… Updating Learning Progress What’s Next?

Open Hand

18 August 2014 — As the summer sun begins to wither, we wonder, whither summer? How have we managed to come so far down the road without so much as a brief dispatch?

We hang our collective head in shame and come up, momentarily, for air. We did promise, after all, more than a decade ago, to provide information, even if all there was to tell was that there was nothing new to tell. But in fact, quite a bit is new, and thus the time to tell is upon us once again.

The trip to Helix 7 and beyond is well underway. While that statement has been true since late this past winter, and while this “journey of a thousand miles” did begin with a single step, it just wasn’t the first step, but rather the first step from which there was no turning back. That first step really happened only recently, right after we shipped Helix 6.2.4. That step was to break the critical bond that prevented us from moving forward with new feature development: to change the Helix collection file structure itself. To break definitively with the past.

That work got underway before we even asked you to spend your $10,000 on new features. Remember that before we could even present you with the questions, we spent a considerable amount of time whittling each request down to its essence, and then placing it alongside other, related items in a logical, if nonetheless imposing, order.

The months of preparation were well worth the effort. When that survey was complete, we got a much clearer picture of how badly you wanted the numerous things you wanted and why.

Next, we had to break each item down to determine what we call “how hard/how long.” How hard refers to the level of difficulty of the task. How long is exactly that: how long each item on the list will take to spec, build, test and complete. This step is critical to determining what we will actually do next.

At the same time as that was happening, our engineers were busy with the first, critical steps: modernizing how Helix manages graphics and documents, building the collection update function into Server, RADE and Engine and documenting all the things that have changed since Classic ruled the Helix universe.

Stability And Speed

Helix 6.2.4 was done because the relative instability of 6.2.3 and previous recent incarnations of Helix were unsettling denizens of our universe to a nearly intolerable degree. We had to face the fact that in spite of our accomplishment, Helix in macOS was still not quite there.

Then we saw the performance improvement we had achieved in pursuit of stability, and we were stunned, albeit pleasantly, of course. And since spreading open our hands and letting 6.2.4 go to the far corners of the globe, the feedback has been astounding. Not merely positive. Ebullient. Effervescent. Exciting! Triple E: a real comfortable pair of shoes to walk the Helix world, at long last.

Here’s a typical response (please bear in mind that this user’s numerical claims have not been verified, but hey…):

“Great release! On our large database, from my home, with maybe 30 users [logged in at the office], the posting operations — both from posts on entry and find and post alls — are BLAZINGLY fast. 500 percent faster. Lists openings are the same as before. Entry form openings are about 30% faster than the prior release. Stability seems strong. When I was in a VERY long post, others were able to use the program with a slight slowdown, but not a shutdown. That’s the news. Congrats!”

One of the most wonderful, if most transient, moments of doing this work is to be able to read that kind of email. But the most important thing for us was that 6.2.4 let us move forward. And if you are still not in version 6.2, what can we say? The water just keeps getting safer; even the rapids are smoother now…

789…

…maybe even smooth enough to contemplate the big question: What new features should go into the next Helix — and what gets left behind?

There were 247 separate feature requests covered in the survey. A core of 60 or so have been on the list for decades. There are literally so many features wanted by so many people that the proper allocation of them could span the next three major releases of Helix into a fourth.

The process of reviewing these requests has to be undertaken dispassionately: Regardless of what we may think of an idea, we have to treat it honestly. If someone puts a gun to our head and says, “I want popup menus to glow in the dark,” and he or she is prepared to pull the trigger, we need to know how hard it will be to do and how long it will take and be able to commit to that guess, or risk death. What we think of the idea has no bearing at this stage.

And neither do the relative numbers of votes for a thing; they come into play a bit later. At this point, we are like baseball scouts looking at potential future stars. We want to know what capabilities they would bring to Helix, how far along they already are, how much work might be needed to make them ready to perform on a professional level.

We set two arbitrary yardsticks for our parameters and then made ourselves abide by them. The first is the “how hard” yardstick. On a scale of 0 to 100, with 100 being the most difficult, we rate each request. The second is the “how long” yardstick. A number on this scale represents a man-week, the amount of work a man would do working for a full week. Less than a man-week is expressed decimally. Three days are 0.6 man-weeks.

The early discussions were often more contentious than the later ones. By the time we had gone through a dozen or so feature requests to make our estimates, we had become very much in sync. The words we used in discussion began to sound like numbers to us. When baseball scouts watch a player hit, look at each other and all say something like “10 and 1,” synchronization is achieved. In our collective heads, we now have a reasonable idea of how difficult a feature would be and how long it would take to implement.

Now comes the hard part: doing the math. How do you make the decision about which ones to do? Even the simplest of these features take time. And those less difficult tasks should only be undertaken once the more important ones are done. Furthermore, there are some things that simply cannot be done unless other things happen first. And some of those “other things” may be long and/or difficult to accomplish, given what we know about how Helix is built.

At the very least, when our analysis is finally complete, we will have something we have not had the luxury of having for many years: the Feature Game is finally over, the loose ends of the past are tied. Everything will have been considered, leaving us a fairly clear path through the next several versions of our product, where everything everyone has ever wanted to see will have its place in — or out of — Helix’s future.

Updating

The last three releases of Helix (6.0, 6.1 and 6.2) have been intercompatible. You could work on anything updated to Helix 6.0 with any of those products. But that ends with Helix 6.2. When Helix 7 arrives, your collections will be updated, as they used to be, and you will not be able to open that copy with Helix 6.2 or any earlier version.

In Helix 6.2, we separated the two functions performed by Helix’s Update Collection application, building the structure check portion of it into RADE, Server and Engine. But we did not bring the Update Collection routine in, largely because we really didn’t know what that update would entail yet, and because the update to 6.0 would handle 6.1 and 6.2.

Now we do, and we’re very pleased to report that our alpha versions of Helix 7 successfully update collections, even some pre-Helix 6 era collections! It may not seem like much, but it is a very significant milestone.

Learning

A key purpose of eduction is to lift things up, to improve the way people do things based upon knowledge that may not be readily available to them.

Though its history, Helix has been relatively easy to learn, but not so easy to document. The scope of what can be done with Helix is too vast to summarize in a simple step-by-step guide. Any attempt to create useful documentation of the User Guide type requires several leaps of imagination on the part of end-users.

When the Mac first came out, all software came with two books: the reference and the user guide. One was used to describe each component of the program, each menu, each command and what it did. The User Guide showed how to actually put all the pieces together and build something useful with it.

The last Helix Reference was published more than a decade ago. Since that time, subsequent sets of release notes have served as addenda to that volume, but no attempt has been made to update to original User Guide. Until now, that is.

That User Guide employed an example of a mystery writer’s book club called “The Plot Thickens” as its principal example of how to build an application, creating a member database, membership renewals, mailing lists and other functions to bring Helix Reference concepts to life. Although this barely scratches the surface of what Helix can do, it served the purpose for those who put in the effort to follow it.

Partly because it is clear that no single example will ever suffice, and partly out of nostalgia and respect for those who came before us, the 21st Century update of the original User Guide employs the same example. But so much has changed since 1984 that, to use an overused expression, the similarities end there. The new version will not be printed. It is a Helix collection, and its content will be available via a web browser whenever and wherever you need it.

Finally, the much-heralded Helix Code Library concept has been reborn as the Helix Code Exchange. It will provide access to reusable Helix objects, Helix AppleScripts and other applications that support and extend the use of Helix, both for free and for sale. At this point, the Code Exchange has exactly one item: an applet that simplifies the changing of fonts in your collection. Additional items have been submitted for our consideration, and should be appearing shortly. If you have a Helix-related product you would like to offer via the Helix Code Exchange, contact Gil to discuss the possibilities.

Now that we are preparing to break with the past, we also plan to bring back Helix training, both live and pre-recorded, create a new Helix Designer curriculum and explore, once again, the often-debated issue of Helix Designer certification. We want to do as much as we possibly can to support our loyal core of Helix users and attract a new generation to this technology that will help them realize their dreams.

Progress

While it’s all well and good to talk about what we’ve been up to, we thought it might be better to employ the old picture-is-worth-a-thousand-words wisdom to the effort. And a moving picture is worth even more. Please enjoy this short clip that should give you a taste of what is coming soon…

What’s Next

Given the great progress we have already made, we are planning on placing the next version of Helix in your hands before the end of the year.

The initial web interaction will be somewhat limited, but even within those limits, it will open large vistas of possible uses. At the very least, this version will save Helix users a ton of time by providing them and, in the case of business users, their customers, with even easier access to their data. Before now, a Helix network could be accessed from any Macintosh anywhere. Now, we expand that frontier to any device anywhere.

And over the next few weeks, we will be drawing the aforementioned lines to distinguish what will be part of Helix 7 and what will come later. Between now and then, we strongly urge those of you who have yet to upgrade to Helix 6.2 to get out there and do it, and those of you already in 6.2 who may have initially been scared away by some of the instability and slowness they observed in 6.2, 6.2.1, 6.2.2 and 6.2.3 to download 6.2.4 and give it a fresh look. We know you’ll be glad you did.