Previous | Table of Contents | Next |
Screen real estate is a lesser, but still important, component of integrated systems design. Developers should ensure that the users screen does not become overcrowded with panels, screens, or other kinds of activity. A large number of panels, or newly generated panels that cover up others, becomes unmanageable. Screen management and screen real estate can make or break the integrated system, even though they do not directly affect the systems actual functioning.
Similar consideration should be given to the interior layout of each window. When the widgets (e.g., menus, buttons, scroll bars, etc.) inside a window are arranged counterintuitively on the screen, the user needs more time to sort out all the information on the window. When this happens, the user ends up spending more time trying to comprehend what he or she is looking at than actually dealing with the business at hand. Common types of information should be grouped together.
Team members must also consider the function of the widgets the actual conduits to the functions of the integrated system when choosing from the various types of widgets available in graphics packages. If these conduits either implicitly or explicitly mislead the user, the system will not function properly. Books on windows and window design explain the appropriate use of the different types of widgets.
Appropriate color choice provides the finishing touch to an open system. Color helps separate the different functions implemented in the integrated system. For example, the functions to add, modify, or delete records in a database can be color-coded in the following manner: buttons for the add function can be colored yellow to indicate that the user can perform the function but should proceed with care; the button for the modify function can be orange to indicate that anything done can be undone; and red can be used for the delete function to indicate that a record removed is gone forever and using this function may be dangerous.
Colors should also be selected with aesthetics in mind. Human beings work more easily and happily when what they are looking at is pleasing to the eye. Color can also delineate separate sections of a window to aid the user in interacting with the system. Finally, colors selected should be easy on the eyes. Screens with strong, bold colors or highly contrasted colors next to each other are difficult to view for long periods of time and can cause eye strain. In more ways than one, the integrated system should not create headaches for the user.
Replacing a legacy system with an open system solution further complicates systems integration. For the purposes of this discussion, legacy systems are considered those that were developed in a nonwindows environment. So a legacy system is one that relies on linear menu selection rather than on the ranges of selection available on window-type panels. The platform may be mainframe or PC, but it does not allow for the branching out of applications functions or for simultaneous display of panels.
By definition, a legacy system has been around for a long time. If it did the job reasonably well for the user, the new open system must do it better; if the old system never fulfilled the users needs, a successful replacement is critical. The worst thing that can happen for users and developers alike is for a new application to have less functionality than its predecessor.
It therefore becomes essential that navigation of open systems windows be a primary consideration in the design of a new system or of a legacy systems replacement. Where once users had no choice but to follow their own linear thinking when running a mainframe system, the open, integrated system gives users many path choices. The system designer should consider logical flow: namely, which panels can parent a subsequent panel (the child process), and which panels would be a final child in what becomes the tree structure of insatiable window-upon-window navigation. At all costs, the development team should avoid creating a confusing mass of windows that users will never be able to navigate.
Another consideration related to window navigation is the actual number of window processes that should be running at any given time. Although integrated systems can support several simultaneously running processes, a benchmark should be established for the number of processes that should be running within the system at any given time. The system should never crash, but it should perform within reasonable expectations. Consideration of the these points can make the difference between whether users accept or reject a legacy system replacement.
Replacing a legacy system also involves consideration of how much, if not all, of the system to replace, even if the original hardware remains. In some cases, a legacy mainframe system is ideal for housing large volumes of data, for example, but it is not really suited to providing that data to the user in a digestible way. The integrated, open system then becomes the suitable front end, and the remaining issue is that of communication between the client/server hardware and the mainframe.
A similar scenario results if the existing system contains a mainframe component whose accuracy, reliability, and performance cannot be replicated and should therefore not be replaced. Work done well on the mainframe can be communicated to the client/server platform and vice versa.
The intricate, laborious, and expensive process of integrating legacy systems into an open system environment yielded seven rules of integration:
Previous | Table of Contents | Next |