IBM i Modernization - The User Interface

This piece offers opinions about options for moving from green-screens to browser user interfaces. It focuses on IBM i-centric alternatives as opposed to the migration of applications (or the UI portion of applications) to other platforms.

 

Our definition of "other platforms" includes language and runtime environments which run in PASE, because PASE is really a subset of AIX. Though interesting as they may be, the scope of this blog is limited to IBM i-centric options (ILE languages).

 

Organizations which are reviewing green-screen alternatives are often in a critical phase wherein the risk of failure is high. The loss of confidence which follows a modernization failure often leads to a negative stereotyping of IBM i developers, distrust of the IBM i platform, and costly migrations of applications to other platforms.

 

Quite a few vendors and branded products fall within the scope of IBM i-centric alternatives. We will not name them, nor review them in detail. But we will offer opinions about architectural constraints within most of them, and compare them to alternatives which have fewer constraints.

 

Display Files

A number of products support the traditional display file paradigm and extend it to browsers. The lure is that it is alleged to provide the easiest path for developers who are steeped in display files, and the fewest changes to existing code. The display-file paradigm includes "screen scrapers" and open-access handlers.

 

Experience suggests that the risk of failure of the display-file paradigm is high. End-user expectations in regards to UI modernization often differ from the interests of legacy-application developers. Display files have a number of constraints, and products which extend the paradigm to browsers generally impact the end-user experience in a negative way more than they improve it. Many users cling to green screens after trying an alternative. Others express disappointment.

 

Downsides from an end-user perspective include:

 

Size of data streams increase from 1K-2K, upwards to 30K-100K per request.
Loss of cursor movement.
Reduction in keyboard control.
Shifting back and forth between keyboard and mouse.
Net reduction in end-user productivity.
Increased latency between client and server.

 

Downsides are partially offset by a richer set of UI components, including drop-down lists, check boxes, push buttons, colors, and fonts.

 

The opinions of IBM i developers are mixed. They confirm that such transitions to browsers requires few changes to existing code. But they cite a loss in productivity by having to maintain traditional display files in addition to GUI extensions, using separate tooling.

 

More concerns are raised by web application developers who are experienced in UI design (using HTML, CSS, JavaScript, AJAX, responsive design and such). They view the display-file paradigm as a severe architectural constraint.

 

Open-access-based tooling generally includes a browser-based (JavaScript) applet which implements an interface comparable to a 5250 emulator (except the data stream is more verbose). The applet overrides the traditional browser interface, and introduces constraints. Some of these constraints will become more clear in subsequent sections.

 

Request-Response Cycle

Normally, web browsers initiate requests, then handle server responses. The display-file paradigm overrides this normal request-response cycle, and replaces it with a pattern of writing "records" to a "display", then reading "records" after "waits". This is problematic in that in many cases the user experience may be improved when browsers are allowed to initiate:

 

Requests from multiple in-line frames.
Requests from "timer" events.
Asynchronous background requests.
Requests from toggling UI elements, such as check boxes, radio buttons, and such.
Long polling requests.
Requests from keyboard events (i.e. Google Suggest).

In other cases, the user experience may be improved by enabling custom-written JavaScript to handle events which might otherwise require server logic and resources under the display-file paradigm.

 

Functionality and user experience is also enhanced when interfaces support push-notifications to browsers for such things as alerts, messages, and changes to screen content.

 

When evaluating user-interface options, please consider traits delineated in subsequent sections.

 

Fixed Positioning vs. Responsive Design

Beware of tooling which enables developers to drag, drop, position, and set properties of GUI elements (i.e. tables, input elements, etc.). In most cases, the tool enforces fixed positioning and sizing of elements, and page-at-a-time processing.

 

A better alternative is tooling which supports relative positioning and automated sizing of UI elements, and supports incremental updating of UI elements in response to asynchronous background event processing.

 

Responsive design is a fairly broad topic which could take several book chapters to summarize. In our opinion, it's an important practice and something which is NOT found in most IBM i-centric UI products.

 

Stateful vs. Stateless

There has been a lot of buzz about the "stateless" nature of web interfaces. Don't take that to mean that your applications should be stateless. Quite to the contrary, complex applications require stateful resources such as filtered result sets (cursors), record buffers, and variables which hold unique values for individual users. From a developer perspective, the relevant question is what may be required (if anything) in order to manage state.

 

In regards to IBM i-centric alternatives, state may be maintained automatically via interfaces which launch new "JOBS" when new users request URLs which map to application entry points. Or perhaps new JOBS are launched when users click on menu items in a web portal.

 

Alternatively, programmers can write code which retrieves "session" properties at the beginning of the request-response cycle, updates them while processing requests, and saves them for possibly subsequent requests from the same user. In complex applications, this may not be a trivial exercise.

 

In our opinion, IBM i-centric interfaces should support both options for managing state, and especially the option of launching new JOBS which frees developers from a requirement of writing code to maintain sessions (they often have more important things to worry about).

 

The option of launching new JOBS when menu items are clicked is especially relevant to the development of complex, broadly-scoped applications. Partly because it frees developers to focus on application functionally rather than managing sessions via code. Partly because the request-response cycle is streamlined (i.e. CPU cycles are not not required to alternatively restore, then save session state.)

 

Does the interface enable end-users to "END" JOBS they started when they clicked on menu items? That's a key to operational efficiency. Does the interface enable administrators to configure a maximum inactivity limit for JOBS which may have been abandoned by users? Does the interface automatically "END" inactive JOBS when limits have been exceeded? Do users receive appropriately formatted messages when sessions automatically end?

 

IBM i actually provides unique value in its ability to manage thousands or even tens of thousands of processes (JOBS) concurrently. The value of this cannot be overstated; Particularly in regards to supporting broadly-scoped applications for thousands or tens of thousands of concurrent users on a single server.

 

Caching Resources in Browsers

User experience may be improved by interfaces which enable the caching of resources (i.e. HTML templates, JSON objects / arrays, JavaScript, CSS, etc.) locally (in browser cache). This facilitates certain types of screen updates without the need of making additional requests to servers.

 

This is essentially the opposite of display-file and page-at-a-time paradigms promulgated in screen-scraper, open-access, and other IBM i-centric tooling.

 

This is an essential trait of the single-page paradigm which was made popular by Goggle.

 

Web Portal vs. Roll-Your-Own

Web portals provide infrastructure which may be shared by all applications which run within them. By "infrastructure" think authentication of user credentials, single sign-on, automated recovery/reset of user credentials, user profile and user group management, group authorities, menu configuration, application configuration, and such.

 

Web portals enable the launching of any number menu items concurrently in tabbed frames, and toggling between application instances, as opposed to exiting from one menu item in order to access another.

 

Does the vendor offer a web portal along with developer tooling, or do you need to build your own?

 

Code Generation and Utilities

Does the tooling include code generation for basic inquiry, maintenance, and reporting? Are the generated user interfaces an improvement over existing green screens? Does the code implement an MVC design pattern? Is the code modular and easy to follow? Do generated applications make use of utilities for such things as automated pop-up lists and report parameter prompting?

 

The value of adopting a framework which dramatically improves a shop's code base cannot be understated. We believe that a framework which includes a mixture of and an appropriate balance between code generation and utility is an optimal modernization strategy.

 

Choice and Preferences vs. All-In-One

Does IBM i-centric tooling provide for alternative preferences and choices for generating/editing/debugging HTML, CSS, JavaScript? Are developers allowed to have preferences for JavaScript frameworks? Or are developers required to adopt a single all-in-one set of tooling?

 

Multi-Tenant/Multi-Environment vs. Single

Does the tooling automate and facilitate the generation of separate environments for development, test, and production? And/Or environments for multiple tenants, separate products, separate development teams, separate user-communities?

 

Summary

Developers and administrators in many IBM i shops have been pre-conditioned to think in terms of face-lifting existing applications instead of a modernization track which actually improves the end-user experience in addition to improving a shop's code base. Fortunately, there are alternatives.