|
This series of screen shots shows the work-in-progress of a developer who has taken a one-step-at-a-time approach to AUI development. Rather than tackle too many graphical issues at once, this developer is taking a
slow, steady and incremental approach. By identifying the elements of his application that (a) will immediately and significantly benefit users if converted to a graphical look, and (b) those where common code and
regular routines makes the switch to AUI quite straightforward, the developer already is providing his users with an evolving look-and-feel as he also provides new functionality.
As with the other examples, please note that the two versions of the following screens come from the same program.
The two screen shots above illustrate a straightforward, step-by-step migration of a menu from text to partial GUI. Note the following points:
- The fact that the GUI elements (buttons, images, etc) can coexist with the plain text elements makes incremental
conversion possible. Purists may argue about the aesthetics, but the fact is, this hybrid offers a number of
advantages over the original, yet is fully compatible, and could be deployed into production sites on the same day
as the enhancements were implemented. In other words, the GUI enhancements can be handled just like any other program enhancements or fixes that you deploy on a day to day basis.
- The GUI version offers the same exact keyboard operations as the text version, but also offers the ability to click
on any of the selections (which have been presented as buttons to make this completely obvious).
- The retro "MADICS" banner has been replaced with a cleaner GUI version, which is nothing more than a
PRINT statement with a TAB(-10,x) command to select a larger font and the sunken panel.
- It can't be seen in this static screen shot, but the pyramid logo revolves, consisting of an animated AVI.
- Even though this appears to be a simple static menu, the bottom part involves a lot of runtime logic to present a
set of short cuts that is tailored to each user and circumstance. Switching to the GUI version allowed this feature
to be substantially expanded without using any more screen space by loading up several pages of a TAB control.
This is a good example of how a GUI version can offer benefits beyond mere aesthetics, and also a good example of the advantages of a GUI that can be dynamically constructed at runtime without any limitations
imposed by the need to pre-create the form design in an off-line tool.
 |
This pair, above and below, again illustrates the kind of simple, one-element-at-a-time enhancements that can be done within
minutes—and with little or no change to program logic. The multiple choice Sort By was changed to a set of radio buttons.
The Y/N fields became checkboxes. The field labels were turned into buttons, allowing the Any Change prompt to be hidden,
although its logic continues to be active, since in this case, clicking the buttons generates the same keyboard events as
ordinary typing. As with the menu, this means that the old keyboard interface continues to work, to the satisfaction of existing power users.
 |
 |
This pair illustrates how even the simplest text-to-GUI transformation can provide tangible advantage to the user. In the text
version, the table of payment types overlays the bottom half of the screen, obscuring the context in which the type code is
being requested. (In fact, it's not immediately clear what is even going on in the top screen.) The gui version below, by reducing the Pay Type table to a pop-up GUI table allows it to be displayed without covering up all the rest of the fields in the
lower half of the screen. And since the GUI version of the table can easily be scrolled, it can accommodate any number of
additional codes, whereas the text version would require additional logic to page among them. And of course it is clickable.
One might observe that although the GUI version offers some programming advantages, these necessarily require different
logic compared to the text version. However, since the GUI version doesn't require any additional costs (other than a different
emulator) there may be no particular need to keep enhancing the text logic. In other words, instead of looking at the GUI
conversion as a mere face lift where the object is to try to copy Windows, look at it as a way to simplify the programming of feature enhancements going forward.
AUI Samples 1
|
