The alternatives, the Pitfalls, the Opportunities
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 behaves like a high-school dance. The pretty girls get to dance, and the MultiDimensional world WANTS TO DANCE. So for us to dance, we need to get dressed up.

A new sytem?
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 the Oracle solution may only provide 50% of the functionality required.

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 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.

The Alternatives:
1. Retrofit your existing pick code to incorporate GUI extensions by Accuterm or others
2. Visual Basic screens with ODBC connectivity to your Pick data structure
3. "Screen-Scraper" to provide a pretty display without the functionality of GUI
4. Web Browser Interface
5. The short, direct path - RAD support for the Graphic User Interface
6. Become an Oracle Programmer after you sell management on a conversion.

Retrofit
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 that make it difficult to debug and costly to support?

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.

Visual Basic
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 got into Pick from college where you learned VB, there may be a steep learning curve to overcome. VB isn't a perfect tool for multi-programmer environments, where numerous programmers will be required to spend a great amount of time co-ordinating their efforts every few days to make sure their variable naming and typing stay in synch. 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 NNF2 (Pick) database.

What makes VB really fun, is that the business rules reside independently, on each PC. In VB,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? In the MultiDimensional host-centric model, the INSTRUCTIONS reside on the host and there is only one place where you have to do your debugging.

In Visual Basic, 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 initally, eliminating per-seat costs of Termite or Viaduct or Wintegrate. 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 additionial 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. "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.

.NET is another option. Very pretty, very sexy, but consider for a moment how complicated this environment could be to integrate with your MV data. Oh yes, the rules you developed for your original applications must be "re-factored" to fit in the .NET world. There may be some "divergence" in how things work, and there will be a significant learning curve for staff. Staff who initially learned .NET (C#) in college, will have to learn Pick data structures. Experienced Pick developers will have a bit of a learning curve to contend with, in addition to their regular work load of supporting the "production" environment.

Bear in mind the "habit" of Microsoft to change the rules when an upgrade of Visual Basic, or .NET or whatever "flavor of the day" appears to be, which may require significant code changes and occasionally, a major re-write.

A 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 the numerous dumb terminals used in the warehouse, on the maintenance floor or on order desks (used by parts clerks with greasy fingers)... You are then faced with the maintenance of two (or more) pieces of code that will over time tend to diverge. As the code diverges, and provide slightly different functionality, the business rules tend to get out of synch, the update procedures tend to change and potential for data corruption creeps in. This requires management to get involved and usually involves accounting staff and potentially involves inside and outside auditors to resolve issues. Oh, did we mention Sarbanes-Oxley?

Screen Scraper
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 based on defined label and field locations. 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 any consistency of operations that a modern application demands. A screen scraper merely re-formats a display and does nothing to provide additional functionality or user friendliness. It will also complicate support amd application maintenance.

Web Browser Interface
The implementation of a web interface although quite 'sexy', is little 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 distributing 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. There is also an extensive alphabet soup mix of CGI, PHP, PERL, CSS, and Ajax (not the cleanser either).

The web browser interface is great for collecting data on the Information SuperHighway, but becomes rather complicated to support and implement for the whole of an on-line user population.

The short direct path
We at Binary Star have wrestled with the issue of the Graphic User Interface now for more than eight years. We have been down every road and have explored most every pathway. We have built Visual Basic screens and Web Browser based applications. Our mission was to give our core product, Nucleus, 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 was developed from the ground-up as an event driven environment, we realized that the integration of a Graphic User Interface with the Nucleus IDE was both a practical and logical step.

We began our experiments with Termite. We passed on Winnix. We danced with ViaDuct. We wrestled with Wintegrate. 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 put on the plate before us, was a feature-rich set of GUI objects that could be incorporated into our standardized code, with a very low per-seat cost for Accuterm, and NO increase in application complexity.

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 creates the screen that you can see in the screen which follows it, with a picture of Bullwinkle J. Moose.

020 SHUSERS USING WINSCREENS,TEMP.SHUSERS 021 USERID 022 HEADING "User Registration" 023 POINT(12) 024 PAGE(Projects) 025 WINDOW(69,14,3,1) 026 @(1,0) "Valid Projects......." 027 @(1,1,13) PROJECTS PROJECT.DESC 028 @(25,0) CURRENT.PROJECT 029 PAGE(Gallery) 030 @(1,1) PICTURE(25,10,0,0) PHOTO1 031 @(1,13) HOLDPOINT 032 @(1,14) D.PHOTO1 033 @(27,0) VLINE(15) 034 @(30,0) LAST.NAME 035 FIRST.NAME 036 EMAIL 037 @(30,3) LINE(35) 038 @(30,4) SERVICE.CLASS TCL 039 @(30,6) LINE(35) 040 @(30,8) BREAKKEY 041 @(30,9,4,N) ACCOUNT.ACCESS 042 * 043 HIDE PASSWORD HIDE PASSWORD.DATE 044 WIDTH.FACTOR(1.1) 045 DEPTH.FACTOR(1.6) 046 SET-TABGROUP(OK,CANCEL,APPLY) 047 ID-INLINE 048 * 049 COMPILE SCR.TEMP.SHUSERS

Ten minutes to GUI

How and why
The above code supports both 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.

Binary Star took the approach, that there are, and will continue to be many companies with large investments in dumb terminals, who appreciate the simplicity of dumb-terminal support. We saw that many VAR's were losing out on sales because their applications did not offer the "sizzle" of a GUI environment. We realized that many buyers demand both a graphic user interface (GUI). and dumb terminal support.

We also saw that many sites were being forced out of their Pick environments by more colorful but ususally 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 incorporating both GUI and character based formats. We maintained the 'host-centric' methodology of Pick, where the rule-sets reside on the Pick host ensuring reliability and providing a comfort level for Pick developers.

In Summary
While many roads lead to Rome, some are far faster, easier to travel and have fewer bumps than others. Unlike any other application environment, Nucleus does support a Graphic User Interface, dumb terminals and a Web Browser interface with ONE set of rules. Nucleus can also support .NET through the same ruleset. Nucleus is currently (October 2007) adding support for Web Objects and other exciting 'new' technologies. Of course, backward compatibility is ensured with Nucleus.

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".

As one individual from the UK said about NRG
"It's too good to be true, and you can quote me on it" - Simon Carter, Datalex.

I won't go on, but if you are curious and would like to see how Nucleus / NRG can work for you, please contact the author of this article, toll free at 866-882-1888 or +1 954/791-8575 to arrange a no-obligation review of Nucleus technology via the internet.

NRG - Nucleus Rapid GUI.

Please feel free to visit the Binary Star website for additional information and follow-up articles on NRG. Your comments are welcome.

About the author
Lee Bacall is the President of Binary Star Development Corporation where he is involved in both marketing and technical development. Lee is a past president of the Pick Users of Florida (93-94), and has contributed numerous technical articles to the PUOF and OSDA news letters as well as having served as Vice President, Treasurer and Membership chairman.