Green screen applications have one single advantage over any other kind of application available today - they appear to be quite fast.
Historically, this was not always the case, and response time was something that users would complain about regularly. As the servers running IBM i applications have increased in performance, regardless of how bad (or good) the underlying code is, performance appears to have improved, and quite substantially. Having been a speaker on performance tuning a decade ago, and watching the shenanigans played by so-called performance experts, I always ask when speaking at conferences about how many people have performance issues on their IBM i. The count used to be almost every attendee, today it is rarely more than one attendee occasionally.
That still does not excuse poor performance, but maybe the requirements have changed somewhat? A user who expects sub-second response time on a green screen application seems quite willing to wait three or five seconds for a response on a mobile device. Even on a desktop PC, an internet application is never expected to be quite as responsive as a green screen application. It seems that the users expect a level of responsiveness to which they have already become accustomed.
A recent solution required me to automate an order entry application. The users spent some time navigating around the order entry function to enter the order, and deal with the idiosyncrasies of an application written by programmers who did not consider user experience - at all. My task was to collect all the order information in one place, and automate the navigation of the required green screens without the user doing more than one click to start the process.
The green screen order entry function went something like this.
Menu - type 2, press Enter.
Order prompt - type 1, press Field Exit, press Field Exit, type customer number, press Enter.
Order popup#1 - type X, press Field Exit, type 1, press Enter.
Order popup#2 - press F3.
Order popup#3- press Enter.
Order detail - type PO number, type request date, press F13.
Order shipping - type ship to number, press Field Exit, press Field Exit, press Field Exit, type Attention To, press F8.
Order date override - type Request date, type Ship Date, press F6.
Order detail - press F14.
Order billing - press Field Exit, press Field Exit, press Field Exit, type ABC, press F6.
Order detail - press F15.
Order inventory - press Field Exit, press Field Exit, press Field Exit, type INPABC, press F6.
Order detail - now, start entering products on the order.
Switch to an internet browser, navigate to the product page on the company web site. Copy required information.
Switch to the original green screen session.
Order detail - Paste required information.
Switch to another green screen session.
Menu - type 7, press Enter.
Product inquiry prompt - type 8, press Field Exit, type product number, press Enter.
Product inquiry list - press Field Exit multiple times (until Product is reached), type 5, press Enter.
Product inquiry detail - determine of product is available.
This entire process would take between 30 and 60 seconds to get to the point where the user could enter the order products. Cut to the future...
Menu - click Order Entry icon.
Order Prompt - Type customer number, press Tab, type Ship To customer number, press Tab, type PO number, click Create button.
Order detail - now, start entering products on the order.
Order detail - type product number, press Enter, view product information and availability on same page.
The process is automated in several ways. First, the usual order default values are saved and reused, instead of being retyped for every order. Second, the green screens are navigated automatically from the Order Prompt to the Order Detail, saving lots of keystrokes for the user. They are not shown to the user, instead an animated GIF identifies that something is happening. Third, when the user types a valid product number, the application retrieves the product and availability information and displays them on the same Order Entry page. Fourth, any time there was another window opened to collect information - green screen or browser, the modernized application was able to retrieve that information on a single click, and allow the user faster access to determine what they need. Either a link was available to directly open a web page, or a list
I knew, when building this application, that the time taken to navigate all the screens between the Order Prompt and Order Detail would require some time - the IBM i server needed to respond to the client for all the possible screens - up to a total of 20 screens. If you consider the usual green screen response time of about 1/3rd of a second, this could take up to 7 seconds. For a complicated order, the user saves at least 60 to 90 seconds for each order. Their productivity is improved dramatically, and their customer support should be more effective and timely.
I discussed this with the team leader, and he told me that the response of up to 7 seconds would be accepted by the users, since it was saving them much more time. He assured me they were well aware of the improvement. I suspected that we were going to reset the user expectations, and in a couple of months, they would be asking for an improvement in the response time of the lag between Order Prompt and Order Detail. However, only four days into the implementation of the solution, I received an email asking if I could improve the performance of the application.
In the fast moving world we live - a world of computing, technology and gadgets, our users are a far different breed than our traditional green screen user ever was. While they love the fact that the elapsed time of their overall order entry process has been reduced, any - and I repeat, any - lag is frustrating. Although there are somewhere between six and twenty screens during that lag, the user only sees three - Prompt, Timer, Detail. To them, this is now a slow application.
One of the lessons here is that users must be engaged in the entire process, and this means more than one. Using one super user as the main interface to the user team will work for most of the communication, but often, this super user will not need an explanation of every piece of functionality, will not need much guidance, and will not ask every possible question that should be asked. A mix of users, from super user to average to bumbling, needs to be engaged in both the design and testing of the application.
However you build your application, consider that users are the reason we are in business. We need to consider their requirements, from application functionality to individual screen. We must consider the lowest common denominator before our application will be usable by every user. And, we must consider that when replacing green screens, an entirely new paradigm must be considered. A new skill must be added to our toolbelt - that of understanding user expectations.