In the Wheelhouse: F3=Exit Stage Left

  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

If we're going to keep putting on a show, then we need to give the crowd reasons to keep paying to see it.


In the LinkedIn IBM i Professionals group, Seamus Quinn's blog entitled "Green Screen of Death" seemed to bring out a lot of discussion from many different perspectives about the viability of green-screen interfaces in today's modern world. This week, I'll offer you my take on the subject.

Modernization Matters

Personally, I have to agree with much of the article, other than the statement that "Big Blue never foisted a native GUI onto their big systems." I'll clear that up very quickly so it's out of the way.


With regards to systems management applications, IBM Navigator for i is a GUI. It's native, meaning that it runs on an IBM i HTTP server. The "no native GUI" argument is untrue when describing about 99% of systems management tasks. 
You do hear that "native GUI" comment from time to time. This got me thinking about what's really "native." Maybe the term "native GUI" means there is a longing for a "desktop" environment on IBM i akin to Windows, OS X, KDE, Gnome, or many other user graphical user interfaces people are familiar with when managing their systems. Is that what the IBM i community wants? I really don't think so. And if IBM wanted to produce this, I'm sure they would've done it many years ago.


When I think of a "native" application, I think of any application that I can run on IBM i. To me that means everything from an HTTP server to an IBM Domino application served on IBM i either through the Web or via an IBM Notes client (the Domino NSF application is hosted through the Domino server on IBM i). That also covers WebSphere, PHP apps through Zend, RPG Open Access, and a slew of other options running on IBM i that offer a graphical user interface. A native GUI? To me, that's any application with a GUI on IBM i. This does not equal a traditional character-based green-screen interface or the more modern equivalent of IBM i Access for Web's 5250 emulator. While IBM i Access for Web (as a whole) is an HTTP GUI offering modern ways to submit commands, access databases with SQL, view and export spooled files to PDF/TIFF files, and much more, the IBM i Access for Web 5250 emulator component utilizes and puts a better face on the same data stream. It's real easy to create the server and deploy to users compared to IBM i Access for Windows. I'll admit I'm certainly a fan. With that being said, the 5250 component alone is not a true GUI to IBM i data and it's definitely not a better alternative to solid custom GUI design.


There are those who think that there's no better environment for "heads-down data entry" than traditional green-screen interfaces. In actuality, that opinion may have been accurate when there were no viable alternatives for it. In fact there are, and have been over the years, many solutions available to eliminate a lot of manual and repetitive collection of information. This kind of data entry should be the least of our concerns in 2013. It's not a valid point anymore. Yes, we'll probably always need keyboards and people interacting with a system manually, just not to the extent that the majority of their workload is spent banging out records so much that there's muscle memory in their fingers. The workload of data entry clerks is actually, and dare I say this word, an indicator that perhaps we could be more efficient in the manner our organizations collect information.


A simple real-life example is invoice processing. Invoices can be automatically submitted into a system (via scanning, email, SSH, etc.) with much of the data programmatically extracted and queued for approval without the need of keying. A human proofreader can see the original document (i.e., in PDF or image) on screen right next to the system-generated record, along with fields that the program may not be 100% sure are accurately transposed highlighted in another color. The user could then quickly approve and/or edit reams of records and then automatically initiate a workflow process in the time it would take multiple clerks to just read and input the data with traditional "heads-down data entry."


The modern method reduces the opportunity for mistakes and streamlines any related approval processes. I've seen shops that manually key a week's worth of invoices in local offices and then courier them to major offices for a manual signoff on each physical invoice before they're processed. The processed invoices get catalogued into file folders (Look, Mom! More manpower!) inside metal cabinets that take up a growing storage space for seven or ten years before another person gets to find them and shred them. When I think of this, I think I'm watching an episode of Mad Men. But it still happens. This butterfly effect starts first with the green-screen processing of invoices. This kind of processing is more effective? Hardly. This is where that "heads-down data entry" argument starts getting really thin.


There are obstacles to getting that kind of automation, of course. I'm not saying you can turn a key, pay a check to an ISV, and have an immediate return on investment in a week. It does take a bit of time and a minor to moderate financial investment in order to solve this invoicing example problem. Maybe you need to tie into some of the existing business logic written in RPG or COBOL. The return is most certainly achieved by data-entry staff reduction and savings in salary in a very reasonable amount of time, and it continues to pay for itself year after year.


A realistic view for all modern organizations should be that their processes could always be better. It starts at the beginning of said process, usually where the log-in screen is. Heck, even that could be interpreted as a place for improvement. You can use Kerberos with the fantastic, zero-cost Enterprise Identity Mapping (EIM) for user authentication on everything from green-screen to IBM HTTP applications in order to eliminate manually logging into IBM i, but I digress. If a process starts with a green-screen in order for someone to plug data all day, then we have to be honest with ourselves and ask "can we do this better?" We can! We need to view the concept of "heads-down data entry" as a relic and make a push for a spend to integrate some automation and modern workflow. Of course, it will not eliminate green-screens entirely, but projects like these eliminate some of them. And it makes the business run better. And it saves money. Those savings can be used for the next modernization project.


Modern interfaces are not just appealing to look at. There's much value in there, not just from a feature and accessibility point of view, but it also helps in crafting positive experiences and perceptions for our users. Clicking on an address that automatically launches Google Maps isn't a silly feature. It's what's expected, and continuing to promote interfaces that look old and that interact with a user in older ways does hurt us.


From "Green Screen of Death":


A senior IT guy at a multinational is bemoaning the demands of his users from both above and below. "They just want a nice, pretty GUI," he says, the latter part in little girly voice. The group all chuckle at this knowingly.


I can almost guarantee you that when that "IT guy" isn't around, a much larger group of users chuckles at the "old system."


No matter how modern the features of IBM i are, or the fact that IBM and ISVs have provided us with tools to create modern interfaces for one of the most—if not the most—secure, stable, and scalable operating systems in the world, the aforementioned "IT guy" may face a serious problem.


One day, he just may have to justify purchasing a hardware upgrade for that "old system" to one of the chuckling users. Maybe that user is a big fan of the other shows in town.


Then he wonders why he has an uphill battle ahead of him.