Much has been said about the legacy look of Multi-Dimensional systems. While Pick based systems usually win the test of functionality against ‘windows’ based systems, their un-sophisticated look and feel has traditionally left much to be desired.
The issue of ‘Not Pretty’, unfortunately has a number of side effects, which causes most of us in the Multi-Dimensional world to suffer. The suffering we receive is a double edged sword. We are perceived as having a ‘solution’ that lacks appeal. You can’t get a board of directors to approve an ugly building – ergo, they won’t approve a system with an ‘image’ which doesn’t support their ego’s
Perception is often the key to the door of opportunity. If management doesn’t perceive the beauty of a system immediately (and perceptions are often founded on a first look), your development group doesn’t get the project and management may opt for the Oracle, Visual Basic or some other ‘main stream’ solution – not necessarily better, certainly not cheaper, but usually much prettier. After all, sizzle sells, and if what you are showing to management doesn’t sizzle, you may not get a second opportunity.
So, armed with the foregoing picture in our minds, we can look at how one might address leveling the playing field and being evaluated on more than our looks. Business unfortunately, often operates like a high-school dance. The pretty girls get to dance, and WE WANT TO DANCE. So for us to dance, we need to get dressed up.
A new system?
There are a number of alternatives for providing a more ‘with it’ look. The first is to buy a new system with that fresh new look. Sure, it looks nice on the outside and there’s no dirt on the engine, but does it have room for all the ‘stuff’ we need to store? If it has room for all the stuff, how hard will it be to convert the existing data to the new system? Oracle is an easy solution here, management is pleased when they get to brag that they spent 2.5 million dollars for their new solution and it didn’t even include the new hardware which was necessary. Not to mention the fact that it may only do 30% of the work necessary.
Oh, but you want to retain your MultiDimensional system, since that’s how you earn your living supporting the users and writing the reports and building the maintenance screens and doing the month end processing and answering tech calls and making sure that everything runs properly.
Well, in that case, you are going to have to realize a few things. You can’t do everything by yourself anymore. You are likely already overworked. We know that you are probably underpaid – especially when you consider that SAP and Oracle professionals often get upwards of $250/hour with 10 hour day guarantees and 6 day weeks, 6 month minimum contracts – do the math.
A few things are going to have to change, in order to provide ‘pretty’. You are either going to have to ‘make time’ to climb the learning curve and do the extra work, hire a consultant to do the work required to ‘get pretty’, and/or find a product which makes it easy to implement ‘pretty’. Part of the project in getting there also involves in learning how to sell management on the idea that they will need to spend some money.
How far can you go, how far do you need to go?
Moving from a traditional green-screen or dumb terminal to a PC with a terminal emulator that provides color can be a good start. Unfortunately it’s usually not enough to get the vote of confidence from management. When viewing a screen with a blue background, management says, “So what’s the difference? I still have to pick field number 1 to change the Description and still have to type over the entire description to change the spelling of a word.”
What’s often necessary, at minimum, is a character based environment for high-activity functions that incorporate color, pull-down menus, choose windows, function key and arrow key support as well as in-field editing.
It’s going to take some work
To provide a true graphic user interface or GUI which incorporates mouse support and the look and feel of a Windows environment is going to take some work.
- Retrofit of your existing pick code to incorporate GUI extensions by Accuterm or others.
- Visual Basic screens with ODBC connectivity to your Pick data structure.
- Screen-Scraper to provide a pretty display without the functionality of GUI.
- Web Browser Interface.
- The short, direct path – RAD support for the Graphic User Interface.
- Become an Oracle Programmer after you sell management on a conversion.
To retrofit the requirements of a Graphic User Interface into your existing legacy code structure is often a daunting project. It can possibly be done using extensions available from Accuterm, Termite, Viaduct, or Winnix. It will likely result in a major re-write of your entire system. You will experience a major paradigm shift, as the GUI environment requires that EVERY field be ‘event driven’. What’s that you say – just take every mouse click and then shift or re-focus the cursor to the ‘clicked’ field position. That’s the basic idea, but it is complicated work and involves a lot more, such as pre-field, post-field processing, conversions – both output conversion and input conversion, and possibly correlative processing. What about selection windows, lookups, btree searches. Remember, you are contemplating moving from a top-down to an event driven programming style.
If you are going to integrate GUI extensions with your existing code you should consider some of these issues.
- What’s involved in making the changes?
- What impact will adding GUI extension calls to the existing code have on the maintainability of the code? i.e. how much more complex is the code going to become?
- What shape is the code in now? Is it clean and easy to modify, or is it full of GOTO’s and RETURNTO’s which make it imposible to find out what’s going on?
- Does the code currently support the needs of the business?
- Are there issues which are not properly addressed in the current system?
- Is a major re-write in order?
- Do you have source code so that you can actually make the changes?
- Will you have to maintain support for both GUI and dumb terminals?
- Do you or someone on staff have the necessary skills to implement the modifications required in the GUI paradigm?
- What are the costs involved for each ‘seat’ or user?
- If you need to bring in help to make the modifications, is there a budget to pay for the help?
How much work is it going to be to maintain the changes and add new features that may be required and / or discovered during the specification phase of a re-write? If spaghetti is part of your code mass, expect to spend many frustrating hours attempting to integrate an event driven procedure in your code.
An option that many have tried is Visual Basic. VB looks great, develops quickly and provides a true GUI. What’s involved in making VB work for you? Start with a learning curve. VB is a true event driven environment, and unless you either got into Pick from college where you learned VB, you will have a steep learning curve to overcome. VB isn’t great for multi-programmer environments, where multiple programmers will spend a great amount of time coordinating their efforts every few days to make sure their variable naming and typing stay in sync. Then there is the connectivity issue where you have to deal with some form of ODBC to pass data back and forth between the VB objects and your Pick database.
What makes VB really fun, is the fact that all the code that is written has to live on the ‘client’, or the PC of the user who is addressing the Pick database using the VB application. Do you see the forest? Are the trees getting in the way? Just think about an environment with 150 users on dumb terminals and all the code resides on the host and there is only one place where you have to do your debugging. In the VB environment the business rules reside independently, on each PC.
You have to be SURE that the distributed code is the same on EVERY PC in your network. If a programmer has made a change to a piece of code, that code MUST be delivered to EVERY PC on the network or you will certainly have a problem on your hands.
What’s more, if anyone installs a program on their PC (like an old copy of Word) and an old DLL (Dynamic Linking Library) gets installed OVER one that your VB application uses, be prepared for late nights. It can be confusion at least, disaster at worst.
The Visual Basic front end may appear to be cheaper initially, eliminating per-seat costs of Termite or Viaduct or Winnix. However, the long term costs of WRITING Visual Basic programs, DISTRIBUTING Visual Basic programs and MAINTAINING Visual Basic programs will generally far exceed the cost of purchasing additional seats for any terminal emulator.
We have spoken to many people who have taken the VB route and have realized that the costs of implementation and the costs of maintenance usually outweigh the benefits of the pretty face. My mother used to tell me, “Pretty is as pretty does!” What we often hear, is “the costs of VB implementation were far greater and the time was far longer than anyone ever anticipated.”
We won’t bother to get into a complicated discussion about record locking in the Pick database, from the VB environment. Think about what may happen without proper record locking.
The most compelling reason to avoid Visual Basic applications in conjunction with your Pick database occurs when individuals in the organization require the use of a legacy application to support their dumb terminal. You are faced with the maintenance of two (or more) pieces of code that will over time tend to diverge and provide different functionality and often manage the business rules and the data differently causing complications and possibly data corruption.
Screen Scraping refers to a methodology where the elements that exist on a legacy screen are ‘converted’ to reformat the display in a more appealing way. The underlying code generally stays the same. The problem with a screen scraper is that it does nothing to manage choice lists, selections, or providing a consistency to operations that a modern application demands. A screen scraper merely re-formats a display and does nothing to provide additional functionality or user friendliness.
Web browser interface
The implementation of a web interface, although quite ‘sexy’, is nothing more than a refinement of the old 3270 protocols where one ‘submits’ a page and then the host system parses the returned form and determines whether to accept it or return it for corrections. Web applications can work quite well for some things like collecting data or disseminating data via the web, but they are wretched when it comes to interfield interactions. In addition the development of web browser based screens require talents which most Pick people don’t have such as an understanding of web events, graphic design talents and knowledge of HTML (Hyper Text Markup Language) which is essentially a formatting methodology.
The web browser interface is great for collecting data on the Information SuperHighway, but becomes rather complicated to implement for an online user population.
The short direct path
We at Binary Star have wrestled with the issue of the Graphic User Interface now for about four years. We have been down every road and have explored most every pathway. We have built Visual Basic screens and Web Browser based screens. Our mission was to make our core product, Nucleus, have the look and feel of a windows application while utilizing a single rule set (or set of code) to manage both character based and GUI screens.
Since Nucleus is an event driven environment with standardized routines which process every function from pop-up windows to data display, we realized that a Graphic User Interface could be completely integrated in the Nucleus IDE to a set of objects on the windows side.
We began our experiments with Termite. We progressed through Winnix. When we heard that Pete Schellenbach who is the principal behind AccuTerm, was going to offer a set of GUI tools as part of AccuTerm, we jumped at the opportunity to integrate the two products. What AccuTerm 2000 offered us, was a feature-rich set of GUI objects that could be incorporated into our standardized code.
Simplicity is truth
The Nucleus IDE (Integrated Development Environment) allows a developer to create character based and GUI screens which utilize a common foundation of data dictionaries and share a common rule set. Nucleus builds both a presentation layer and a separate data management or rules layer. These layers are bound in an easily-managed English like script. The following script created the screen that you can see in the accompanying advertisement from Binary Star Development (with a picture of Bullwinkle J. Moose on it).
How and why
The above code supports both the GUI and character based screens. Not only does it support character based screens on a PC with color display, but it also supports more than 30 types of dumb terminals without any changes other than TERM-TYPE.
Binary Star took the approach that there are, and will continue to be many companies who have large investments in dumb terminals, and like the simplicity of being able to just take one out of service and plug another in. We saw that many VAR’s were losing out on sales because their applications did not support a GUI environment and their applications did not have the ‘pretty face’ that management wanted to see when making a decision to buy.
We also saw that many user sites were being forced out of their Pick environments by more colorful but usually less productive environments.
We saw an opportunity in being able to provide for the Pick marketplace an Integrated Development Environment capable of supporting enterprise level systems utilizing both GUI and a character based format. We maintained the ‘host-centric’ methodology of Pick, where the rule-sets reside on the Pick side ensuring reliability and providing a comfort level for Pick developers.
All roads lead to Rome, although some are far faster, easier to travel and have fewer bumps.
Having shown the Nucleus / NRG environment to numerous developers we have been gratified by the response from our customers and prospects. We have heard things like, “Is that all it takes?” “That’s amazing!” and lots of “Wow”. I won’t go on, but if you would like to see how Nucleus / NRG can work for you, please contact the author at 954/791-8575 to arrange a showing via the internet.
NRG – Nucleus Real GUI
Please feel free to visit the Binary Star website for additional information and follow-up articles on NRG. Your comments are welcome.
Simon Carter from DataLex in the UK said, “It’s too good to be true, and you can quote me on it”.
About the author
Lee Bacall is the President of Binary Star Development Corporation where he is involved in marketing and technical development of their Integrated eCommerce Environment (ICE). Lee is a past president of the Pick Users of Florida (93-94), and has contributed numerous technical articles to the PUOF and OSDA newsletters as well as having served as Vice President, Treasurer and Membership chairman.
Return to Technical Articles