Let’s Stay Together (An update from the trail…)
It’s time to exhale, find a cozy chair and put on some music …
22 June 2007 If you’re one of those Helix news junkies out there who feel that these reports from the trail are just too verbose, we suggest you ‘turn your sets off now.’ Although we have been updating our macOS Transition Report page fairly regularly, and we’ve already presented our new pricing information, we haven’t given you any kind of meaningful update on Helix itself here since mid-January. A lot has happened in the four months that have zipped by since then, so it’s not going to be quick. If, like some people, you enjoy listening to music while you read … and in keeping with the subtext of that January edition, get yourself a copy of Ike & Tina Turner’s version of the Creedence Clearwater Revival classic, Proud Mary, because as the famous line from the song says: this is going to start out nice, but end up rough.
In deference to those among you who either don’t like to read, or don’t like music, here’s an ‘executive summary’ of what’s in this edition of The Latest Word… First we’re going to talk about what’s been going on since January, to try to give you a feel for where we’ve come to, how we got here and some of the hurdles we’ve overcome. Then we’re going to talk about the new Helix that will soon be in your hands and show you some pictures of what it looks like so you can begin to get a feel for how it will differ from the Helix you have known so well for so long.
Oh, and by the way: all the section titles in this article are references to Tina Turner songs. This is not an official endorsement of Tina Turner or her music. We started out with just the Proud Mary theme and once we got going … well, it sort of all fell together that way.
How far we’ve come (or 3 O’Clock In the Morning Blues)
On more than one occasion, we’ve found ourselves trying to explain the extraordinarily long struggle to get Helix to macOS by saying that the work we had to do to make this all possible was work that should have been started in 1996. What was never said, and what probably could never have been said before, was how long it was going to take.
Life can be quite ironic, especially where Helix is concerned. In 1994, Helix lagged behind it’s competition because it didn’t have a version that ran on the PowerPC chip. Here we are thirteen years later, finally caught up to where the world was back then. All of Helix is PowerPC native, some of it already runs in macOS, but the Macintosh world is moving on to Intel-based machines. About the only thing that’s really clear is that if Helix hadn’t languished in the late 1990s the way it did, cranking out upgrades that provided minimal improvements, while causing it to lag further behind, we’d probably be working on features right now and this whole macOS thing would be a rapidly disappearing speck in our collective rear view mirrors.
But it isn’t. And if we’ve learned anything since we started this, it’s that keeping software on schedule is a practically meaningless exercise. Getting it to work? That’s another thing altogether, and altogether a much more important thing.
In December of 2005, following the successful debut of the macOS native Helix Server, we described what we were doing as dipping our toes in the water. A great deal of sweat went into making that product and the results have been quite satisfying. Many of those who have taken the plunge and put Helix Server to work in their businesses say that it is the most stable and dependable version of Helix yet.
Once the Server was out the door, we set about the next task, that of bringing Helix Client and Helix Engine to macOS. Although the Server, the Utility and Update Collection all feature minimal macOS interfaces, none of them actually provide an interface that lets you work with your data. But once we knew that the underlying database engine was solidly working in macOS, we were ready to move on and produce tools that would let Helix users actually work natively in macOS. It was an exciting time, but it was equally terrifying because it was ‘put up or shut up’ time. As confident as we were in our strategy, no one can ever really say anything with 100% certainty until they actually see it work. And that day was still a long way off.
We had hoped that sales from the initial release of the macOS Server would be enough to carry us through the completion of this next phase. And if everybody who is using Helix 5.3 had upgraded to 6.0, it very may well have been. But there is a large segment of Helix users who simply won’t upgrade until the rest of Helix runs natively in macOS. By October, we were running on fumes. This is the principal reason that there’s been so little news. We couldn’t justify spending much energy on our web site when we could barely keep up production of that which the website promotes.
Whenever we’ve faced this situation before, we pulled up, drew the wagons into a circle and refined our plan, coming up with creative ways to make the most out of our meager resources. That’s when we began soliciting input about what parts of Helix users depended upon most. A lot of sound and fury was associated with those surveys and subsequent discussions, but the upshot of the whole process was that it gave us a clearer picture of what users wanted, needed and could live without — for the time being anyway — and that information in turn enabled us to better prioritize the work that still lay ahead of us.
As fall turned to winter, we finally began to see some light at the end of the tunnel. Little parts of Helix started to work in macOS. At first they were very few and far between, but as time went by and days got colder and wetter (and icier), we came over the hill to the ‘land of alpha,’ where we have been these past several months. Every week or so, and more recently, every few days, we pull our resources together and get a glimpse of the next generation of Helix products, and with a few horrifying exceptions, the experience improves regularly.
Change Is Gonna Come
Along the way to where we are right now, we made a few critical decisions. One was not to continue down the old Helix road of creating our own home-grown, knock-off versions of interface elements. Gertrude Stein may have said ‘A rose is a rose is a rose,’ but she didn’t know Helix! Many of Helix’s interface elements, which Helix users have long taken for granted, are not what you think they are. For example, in a Helix view, a button (aka: command rectangle) is not a button: it is a rounded rectangle drawn on the screen that highlights when you click on it and initiates an action. It may act like a button, but it is really a clever bit of sleight of hand. This is why, when OS 8 introduced the Appearance Manager and every other program’s buttons suddenly sported a nifty 3-D grayscale appearance, Helix buttons continued to look like System 6 era rounded rectangles. For a while Helix looked like a duck, walked like a duck, and quacked like a duck, but eventually it was exposed for the chicken that it was.
What was true about Helix buttons was also true for popup menus, radio buttons, checkboxes and more. We saw the choice before us: continue to create ‘near replicas’ that would need constant attention or sacrifice some of Helix’s non-standard features. The former would continue to chain Helix to the past. The latter would let us get out of this pit that makes updating for a new OS so hard, at a cost of giving up some features that make Helix unique. We chose the latter route, and we stand by that decision as the right one for the future. But one unhappy result of it is that the operating system simply doesn’t do everything the way Helix does, and that means change must come.
When we started to see how radically this would alter the look of Helix collections, we started conducting surveys. We wanted to know which Helix features were indispensable. If you haven’t participated in our surveys, a good example is the one related to buttons. It shows all of the things Helix buttons can do and which ones macOS requires that we give up. It also gave users a chance to tell us how important these features are — answering the daily question: should we take time to find a way to work around this OS limitation or not? (If you do participate in our surveys, be sure to check back after they close to see the results and a summary of what we learned from them.)
Some of the decisions we made were frankly imposed upon us by our limited funding. When we got certain interface elements working at a level that satisfied the majority of the survey respondents, we stopped, sacrificing some of the user’s control over the way elements appeared in exchange for moving on to the next piece of code. For instance, macOS interface guidelines dictate that checkboxes be labeled with the ‘System Font’ (Lucida Grande in macOS) and at one of three sizes. We hope to find a way around this limitation someday, but for now we take it for what it is and realize that for some, the new look you are greeted with when you open your collections in macOS will take some getting used to. Just keep in mind that some of these changes are temporary and we will be listening closely to our customers to determine where we need to overrule the OS and restore the uniqueness of Helix’s feature set.
If you’re resistant to change, this next bit may be a little disquieting… (Better Be Good To Me)
After several months of in-house testing, we’ve become quite familiar with how Helix will ‘look and feel’ in macOS. And we’ve also become quite familiar with the places where Helix butts up against immovable boundaries imposed by the requirements of the present. Some things you’ve come to know and depend on have changed, maybe forever. In most cases however, we think those changes are for the better.
Back in December we showed you the new and improved Login dialog, as well as a look at Quick Query and a how making styled text changes will differ from that to which you’ve become accustomed. You’re still going to have to wait until RADE is converted to macOS to see how different the ‘innards’ of Helix will be, but there are some things that you can see in both Design and User modes and we’re going to take a look at some of those now.
For starters, here’s a look at how the Export options dialog has morphed into modernity. On the left we see it looking about the same as it has always looked (qualified by the changes that occurred with the debut of Apple’s Appearance Manager when the black-and-white dialogs became gray and acquired the illusion of depth — but even there you can see the classic Helix problem in that the group boxes didn’t acquire that 3-D look). Several months ago, we discovered that our slot machines (those scrollable lists that are called selection lists or list boxes in modern terminology) — a commonly used device in Helix for selecting such things as fields, abaci, font sizes, colors, etc. were badly broken. Helix packed those list items into as tight a space as was possible (remember: Helix began life on Macs with 128KB of RAM!) and Xcode simply does not allow that. At first we felt a huge sense of loss and despair. But then we realized that this ancient interface wasn’t what made Helix so user-friendly; rather, it was what you did in those dialogs. Setting out on a different footing, we came up with the new macOS look for Import and Export options that you see on the right. The dialog performs exactly the same functions, but in a more macOS-like appearance. This is a look-and-feel you should start getting used to, because when we do at last start to show you a new RADE, many of the screens you now see when working inside any icon inside a Relation will be taking on an appearance very similar to this.
We think you’ll agree that the new design is neater, more compact and certainly more macOS-like than if we were to merely repeat the same old design in a macOS window frame.
Now let’s take a look at a place where the change is a bit more radical: the Sort Order command. Sort Order is one of those features that is often overlooked in Helix; it gave collection designers the ability to provide users with one list that could have several different indexes attached to it instead of making another report simply to show the same information in a different order. You can always tell a collection where the designer was unaware of this feature. It has menus full of reports with names like "Customer List by Last Name," "Customer List by Company Name," "Customer List by State and City," etc.
When it was added (in the late 90s) it wasn’t an automatic feature: to put it to use you had to open the collection in Design Mode and put each list view into show setup mode in order to select multiple indexes. Then you had to either add the Sort Order command to every user’s menu or put Sort Order into a sequence and put buttons on the appropriate views. Based in part upon our survey information, and our understanding of how Helix users work, we’re pretty confident that most people who only work with Helix in User Mode have never even seen it.
In macOS we’ve made the Sort Order command automatically available to everybody. Like the Quick Query command, Sort Order can still be accessed by all the Classic means, as described above, but it is also now found in the toolbar. (Open the toolbar by clicking the ‘chicklet’ on the right end of the view’s title bar.) Of course, the toolbar, is intelligent enough to know which type of view it is on, showing the Quick Query for entry views and Sort Order for lists.
The new Sort Order respects the collection designer’s choice for which indexes are available, so those of you who suddenly find a ‘new feature’ in Helix can start bugging your collection designers to add sort options to your list views.
So where’s the rough part in all of this? (or I Smell Trouble)
The shortest explanation is that while you won’t have to run Update Collection to use collections in macOS, you may still have to update your collection. That is to say: depending on the way your views are designed, you may have to go into RADE and make changes to your template layouts. Tightly arranged templates will probably translate to awkward looking views in macOS.
We’ve worked hard to keep those types of disruptions to a minimum — and we are continuing to refine this as we work on Helix — but the reality is that some adjustments will be required of some of you. What you may see when you open your collections in macOS is that some of the clever interface things you may have done before may no longer appear so clever. Designs made with Classic Helix in mind may look awful in macOS, or they may be hard to follow. Some might be incomprehensible. Folks — like us — who work overtime tweaking templates to look ‘just right’ in Classic Helix may be particularly chagrined to see that those perfect layouts now need substantial reworking. If you fall into this camp, please understand: we feel your pain.
To help ease into the transition that many of you will face, we thought it wise to present you with some screen shots of some extra troublesome layouts we have encountered. We present these in order to give you a jump start toward rethinking your form designs. If nothing else, it should give you something really productive to do while you wait for the real macOS Engine and Client to debut.
For instance, Classic Helix allows you to use any font and size in interface elements (popup menu, checkboxes, etc.) but macOS only shows them in the standard System font and size. So a design that uses non-standard versions of these elements — like sample on the right — will look quite different in macOS.
In some cases, this is merely annoying; others might need some adjustment to look right in both OS 9 and macOS. In this sample, label rectangles were stacked and filled with various colors to create a shadow effect. The translation to macOS is rather poor.
However, with a little work, we can turn this view into something that not only looks acceptable in Classic Helix, but looks great in macOS. This redesign took less than 5 minutes. Just don’t forget that Classic Helix will still be around for a while, particularly for Client/Server users where it is impractical to replace every old Mac at once. Your view design may need to consider both types of users.
Another place where designs will look quite different in macOS is on templates where framed border rectangles are used, particularly if they are part of the overall design of the form. In macOS border rectangles are drawn using the group box interface element. Consequently they automatically gain rounded corners, a light gray background, and a subtle 3-D effect. Using a different color or line thickness is out.
And as the ‘Insane Nesting’ screenshot shows, nested group boxes take on darker and darker shades of gray. They really make a macOS view quite attractive, but if your design isn’t ready for them, you’ve got some work to do. Unframed border rectangles continue to be invisible, and all border rectangles still provide the function of controlling field tab order.
(Oh, and did you notice that underlined data fields lose the underline when they are undefined?)
As you approach the job of revising your templates, bear one more thing in mind: Since Helix has been around for such a long time, a lot of Helix collections are loaded with views that were designed to fit inside the 9" screen of a Mac Plus or an SE. macOS applications expect to operate in an atmosphere with plenty of space. Lots of space. As a result, ‘space efficient’ (but ugly) designs like this one end up with elements jammed together and even clipped short. An overall good guideline for updating your collections is to give them room. Spread out. If you have things really close together, they will look constricted and squeezed in macOS.
We are still working to make the transition as painless as possible, and the images shown here are from an early version of the macOS native Helix. [Ed. Note: Much improvement has been made!] These simple examples should give you an idea of some of the work you may have to do once you make the jump to macOS.
When the Heartache Is Over
At the time of our last edition of The Latest Word, we hoped to begin beta testing by now. When we wrote that, we had totally forgotten that dynamic popups still needed quite a bit of work. The good news is that most of that work is now done and now we really are very close to starting beta testing.
As soon as we are ready, the initial beta will be limited to a small group of testers. Then that net will gradually expand. Engineers will be standing by to help evaluate issues we uncover in the process and to fix them as they arise. In keeping with our historical approach to beta testing, the first version the testers see will be far along the road to finished. (Gil and Matt have a combined 40 years of Helix beta testing between them, so they do a pretty decent job of doing the ‘first round’ of beta testing on their own!)
We know it’s been a long and rocky ride, but smoother sailing is on the horizon. To those of you who have supported the effort financially to this point, thanks for hanging in there with us. For those who haven’t yet, thinking you will upgrade when release time comes around, don’t wait. Do it now. Save yourself some money. The future we’ve been hoping for is around the corner.
Find Previous — Find Next