Nebula Research and Development

GUI Development

 

We strongly suggest that you include Nebula R&D in your decision making process about which parts of the application to GUI-enable and when. We will gladly respect non-disclosure agreements. Overly ambitious expectations lead to project failures. Moderation and properly phased projects lead toward success.

GUI Enablement

Nebula R&D now provides services for development of Graphical User Interfaces for Pick/Multi-Value Business Applications. Using a variety of tools, chosen uniquely for each project, we can create a new GUI front-end to augment or replace your existing green screen / Character-based User Interfaces (CUI). GUI for web might be done with tools like DesignBais, FlashCONNECT, or ASP.NET. GUI for thick clients may be done with tools like mv.NET, Java, GTK+, or a variety of other tools and languages depending on the specific business needs.

Conversion? Migration? If the goal is to get away from CUI, then yes, GUI Development is a conversion or migration. We believe that there is value to maintaining a CUI even after the GUI has been implemented, but maintaining two code sets can be difficult. For this reason, rather than looking at development as a migration away from something that already works, we consider GUI development to be an enhancement to the existing code. This ideal isn't always attainable, as you'll see below, but we approach every project with the goal of preserving the value of the CUI, rather than simply replacing it as an old "legacy" interface.

Why GUI?

The answer depends on the goals of the developers, resellers, and end-users. In fact, some applications should not be migrated to GUI. Many argue that there is nothing functionally better about a GUI, but the bottom line is that a GUI application will frequently sell faster than a CUI. Chief decision makers will often insist on GUI even when they understand that their end-users may lose productivity, and that GUI maintenance is more expensive than CUI. At Nebula R&D, we will discourage needless development where possible (even if it costs us business) but we will fully support the final decision that is made, and we will do our best to implement the solution which matches the objectives of the decision makers.

Technologies

The solutions used depend on the problem at hand. If the only tool the builder knows about is a hammer, then all problems begin to look like a nail. At Nebula R&D we understand that developers have different needs and so do end-users. We strive to use the right tools to fit each task. Here is an example of technologies we use, but we do not lead with these "hammers" for every "nail" that is presented. Please feel free to ask about other tools.

.NET

Microsoft .NET can be used for thick clients via Windows Forms or for thin clients via ASP.NET or XML SOAP Web Services. .NET is also ideal for PDA's, Smart Phones, and other portable devices. Integration with non-MV legacy software written in Fortran or COBOL may be possible with languages like FORTRAN.NET COBOL.NET - all possibilities are considered. It is also possible to develop for Unix and Linux using technology compatible with .NET. Like Microsoft .NET, Project Mono is an implementation of the Common Language Infrastructure (CLI) which is an open standard via both ECMA and OSI. Mono runs over both Windows and *nix. In other words, code written in C# (and to some extent in other ".NET" languages) can be used for both Windows and *nix platforms. This is of course all still in development but the technology is now production quality.

mv.NET

A GUI can be designed with or without these tools, but these toolkits simplify much GUI development for MV DBMS platforms. Deployment depends on many factors including cost, OS preferences, and the technical skills of the application developer who needs to maintain whatever code we write.

DesignBais

This software appeals particularly to Pick developers who are not familiar with more mainstream tools, and/or those migrating from SB+ and want a web UI. The browser-based development and deployment model is ideal for applications being deployed in an ASP model. DesignBais applications can also be used by some handheld devices. More information on DesignBAIS will be published on this site soon. E-mail for a presentation CD and more information.

Other Thick and Thin Client Tools

We can use VB6 or Java to develop a thick GUI, minimizing network traffic for data validation and other functions. For browser-based deployment, we can use Flash, Shockwave, and Java Applets in conjunction with FlashCONNECT and/or Perl, PHP, and other technologies.

XML

Occasionally we are asked to provide only the communications components, and leave the user interfaces to other developers. In this case we can use XML in conjunction with technologies mentioned above, including Web Services, SOAP, XML-RPC, or proprietary protocols developed at Nebula R&D or elsewhere.

The Process of GUI-Enablement

The first step is to identify which processes should be GUI-enabled, and when. In many cases only the CFO or other decision makers will actually be seeing a GUI, so the only target may be management reports. In other cases management wants all inquiry programs to be in GUI, but they understand that data entry done in-house can be done much faster in a character interface. The rule is to not "throw out the baby with the bath water" - don't put a new user interface on screens that no one can or will use. Sometimes the goal is in fact to GUI-enable all screens, but reasonable, phased deployment schedules must be planned.

The next step to putting a GUI on an application is to modularize the code. Most Pick BASIC code is procedural code - that is, the code is written in the order that processes are expected to happen. For example:

GET.COUNTRY: *
PRINT @(0,10) : "Enter Country ": @(-4) :
INPUT COUNTRY.ID
READ C.REC FROM F.COUNTRIES,COUNTRY.ID ELSE
   PRINT @(0,23): "Invalid, try again":
   GOTO GET.COUNTRY
END
PRINT @(30,10) : C.REC<1> ; * Show the country name
GET.PHONE: * …

This sort of code mixes the user interface with the business rules. Modularized code has no user interface, GUI or CUI. For example:

VALIDATE.COUNTRY: * Subroutine assumes value is already available
COUNTRY.NAME = ""
ERR.MSG = ""
READ C.REC FROM F.COUNTRIES,COUNTRY.ID THEN
   COUNTRY.NAME = C.REC<1>
END ELSE
   ERR.MSG = "Invalid Country ID, try again":
END
RETURN
VALIDATE.PHONE: * …

In this case, the job of the "business rule" is to return the name of the country, given an ID, or to return an error message. The user interface has no idea how the data is being validated.

There is no silver bullet that will turn procedural code into modular code, but many developers continue to wait year after year for such magical technology. Modularizing code is a time consuming manual task, but once it is done the business rules can be used by any UI, including a CUI or a GUI using any of the technologies listed above or any others. Your code may already be modularized! Schedule some time with us to investigate.

"When" the new UI is written depends on the project. When the business rules are modularized, there is no user interface. UI development may occur simultaneously with modularization or it may occur afterward. Of course, code with no UI isn't very useful.

Nebula R&D can take part in any or all phases of GUI-enablement, including simple consulting to keep your own development efforts on-track with no development being done by us.
We can help with project management.
We can modularize the procedural code.
We can replace the CUI.
We can add one or more GUI's using technologies that properly suit the purpose.
We can provide training to ensure that you can continue to maintain your own code.

 
 

© 2009 Nebula Research and Development

Home | About Us | News | FAQ | Products
Services | Articles | Contact Us | Search Site

E-mail for Product and Service inquiries.
Please report site issues to . Thank you!