|
Thousands
of applications have been written for Multi-Value-based systems over
the last 30 years. The Multi-Value environment has proven to be a
very flexible, productive environment for real-world business
solutions. These applications embody an enormous amount of
experience, which often translates to very robust applications.
Because of its heritage, the Multi-Value environment is still
closely associated with a dated “terminal interface” as the main
means of interacting with application users. Although other
mechanisms, such as ODBC and HTTP, are now available, the majority
of Multi-Value applications still use the old character-based PRINT
& INPUT for their user interface.
There is an abundance of legacy code that is still being maintained,
and that code was designed around the only interface available at
the time – the simple character-based interface. Even new
applications continue to use the old character-based interface,
perhaps because this interface is conceptually simple for
developers, and does not require learning new, complex technologies.
The downside to this continued use of this outdated character-based
user-interface is twofold. First, application users, now accustomed
to the sophisticated user-interface available with Windows and other
GUI environments, expect their mainstream application to have
similar functionality and flexibility. Users become frustrated with
the limited editing features of the common INPUT statement and
limited navigational capabilities of many traditional
character-based interfaces.
Equally important is the problem of perception. Even if an
application is otherwise first-class, if it has an unattractive user
interface, it is often perceived as outdated, limited, and difficult
to use. The perception problem is especially important when trying
to market the application, either commercially, or internally to
corporate decision makers. When compared to (possibly less capable)
competitive applications employing a modern (Windows-like) user
interface, a favorable first (visual) impression may open the door
to further consideration, whereas the application with an
unattractive user interface is eliminated without a fair evaluation
of its underlying capability.
In response to the deficiencies of the traditional character-based
interface, developers have taken several approaches to resolve the
problem. One approach is to abandon the Multi-Value application code
entirely and redevelop the application from the ground up on a
different platform (Visual Basic, SQL, Java, etc.) This always
requires an increase in development staff because the VB/SQL/Java
environment is far more complex. This approach typically requires a
large investment in time and money, and the desired result is not
always realized.
Another common approach is to adapt the application to use a new
mechanism for interacting with the user such as ODBC, HTTP or Web
Services. The user-interface component is then developed as a Web
page and accessed by the user’s browser, or as a Visual Basic or
Java application accessing the Multi-Value application data using
ODBC or similar technology. While less resource intensive than a
total rewrite, this approach requires a significant development
effort.
There are less drastic approaches to resolving the outdated user
interface problem. This article explores several alternative
solutions. While centered around using AccuTerm as a key component
in the solution, many of the techniques discussed apply equally well
to real terminals, and other terminal emulators which accurately
emulate those real terminals.
AccuTerm GUI Video Tutorial
new!
Pages: < 1 - 2 - 3
- 4 >
|
