About Green Screens and mouse-clickable UIs

There are plenty of resources online in the web regarding this topic. It seems to be something religious, like the Editor War EMACS versus vi or vim.

Introduction

Some people insist that character based UIs are hopelessly outdated and must be modernized. That usually means: Apply some technology that hides the crude text UI behind a fancy web UI, running in any decent web browser.
Others insist that point-'n-click-interfaces are a serious brake of true productivity. All this constant arm motion between mouse and keyboard does obviously lower the amount of information flowing back and forth between the user and the system: Arm moving overhead.

Let me add a third party and then clean up the resulting mess. Unix/Linux Sysadmins as well as Linux Power Users usually insist on using the shell, a character based UI in itself. It provides for the concatenation of simple tools to do tasks on files or data streams, or whole directory structures. This feature proved to be powerful for experienced users. Do a maximum of work with a minimum of effort.
These very same people see an (emulated) AS/400 screen and almost immediately the expected behavior kicks in: Old, outdated, legacy, you name it.

Seen from another point of view, the AS/400 is commonly perceived as ultimately boring. That is because the AS/400 is mostly running stuff considered boring (by geeks). Commercial IT at its best: Warehouse management, personnel administration, tracking account movements, to name a few. Stuff that makes sure civilisation as we know it won’t collapse, because money stops flowing, carriage of goods ceases, personnel isn't directed to where needed.

Then, there are also some people who argue that by keeping the green screen alive, the perceived outdatedness of the system to others is even more increased. They emphasize that this is doing great harm to the IBM i platform at large, because all effort to convince people that it's not about green screens anymore, is negated. So, interestingly, they’re not appalled against green screens because they don't like them themselves, but because they care about other people's perceptions over reasonable facts that green screens still have their use cases.

The Best of both Worlds

Well, almost.

• Graphical User Interfaces allow the users to point (either with a mouse or a finger/stylus on a touch sensitive screen) on and activate graphical elements on the screen, trying to resemble objects in our physical world. Icons can provide additional, non-textual information regarding the elements on the screen. Until one needs to actually enter data in a classical sense (by typing), everything can be done with just one facility: The translation tool between the physical world and the logical world, most often the mouse but increasingly often by using fingers or a stylus. The user can actually guess which steps to take to complete a given task by contextual conjunction of screen content with expected outcome. The given task is often accomplished step by step instead of one go.
• Command Line Interfaces aim to minimize often time consuming interaction between user and system and sacrifice this by expecting that the user knows which command(s) to enter for a given task to be done. Often a command is started and runs without intervention until the task is complete. Complex tasks usually result in long commands-with-options (or chained commands via pipes), usually requiring a lot of typing. This is somewhat leveraged by the advent of Autocompletion capable command shells.

Some (rare) tasks feature very high complexity which makes it almost impossible to create an user friendly Graphical User Interface to collect parameters, while maintaining a certain amount of intuitive UI design Graphical User Interfaces are praised for. Seen from another point of view: Graphical User Interfaces hide complexity and sacrifice that with less flexibility.

Use the right tool for the task in front of you. This is a fundamental statement holding true for every task in computing and is not restricted to Unix environments.

How the AS/400 Text-UI works

The AS/400 was created as a business aid. This comes down to efficient handling of structured data that has to be entered, processed, stored, reviewed and maybe printed. The system was designed to help people interact in a reasonably user friendly way with it with the then state of the art technology: Character based interfaces utilizing a keyboard for command and data input, and a CRT screen for immediate display of the system’s responses. But this doesn’t automatically equate to a command line interface.

The AS/400 has a unique feature that distinguishes it from other character based systems, like Unix: The whole UI revolves mainly around forms and menus, accompanied by static text. The layouts of these screens are somewhat standardized. AS/400 screens are very recognizable because of this.

German Main Menu after Signon.

The classic AS/400 green screen consists of numbered menu items with an input line beneath. One may enter a number and press Enter to pick a menu choice. Or someone may enter a command with accompanying parameters into the same space, if one knows what to enter. If one doesn’t know the exact parameters and allowed values of a command, a keypress of F4 invokes a full screen form for the requested command, aiding the user in choosing the right parameters for the desired action to be taken.

Sometimes, choosing a menu item reveals another menu. Sometimes a form with text input fields is displayed for the user to fill in needed parameters, so the command may be run with the desired outcome. Rarely no parameters are supported and the command just runs.

For every editable field on the screen, the user is allowed to place the cursor there and again press F4 to be presented with another screen, listing allowed values for this particular parameter.

If this facility also fails to provide proper enlightenment, one may press F1 at any time to invoke a context-sensitive help text, which is almost always surprisingly helpful. See CL Tricks for an overview. These features are unique among text based UIs.

The ubiquitous command shell of Unix, macOS, Windows and others is restricted to commands to be entered, together with (sometimes mandatory) parameters. Commands are entered into the last line of the terminal window. Output from commands appears over this line and scrolls to the top until it’s out of sight.
Any help for a command’s parameters must be invoked by separate facilities (e. g. invoking the command with a parameter to show an usually terse online help, or by reading Unix Man-Pages), and manually complete the command line by re-entering the needed command options.

Concluding: The AS/400 is located somewhere in between GUI and CLI. As one might see now, intuitive user interfaces must not necessarily equate to being graphic (pixel-based).

• CLIs are unintuitive because their cursors blink at the user, patiently waiting for a command to be entered but hinting no clue what to type.
• AS/400 menus, forms and GUIs present structured information to the user that (hopefully) guide the user to take the right steps for completing a given task. They interact with the user.

Why still text, then?

Someone might object that if there's no operational difference between GUIs and AS/400 menus/forms regarding intuitive handling of the system, why does the modern AS/400 still lack a GUI? Well, only IBM can answer this question without making guesses. If I should make a guess, I'd say: Because it would be a change that

1. just isn't implementable with hardware already bought by customers,
2. existing applications would only take minor advantage of (if any!),
3. it would upset system operators who mostly learned to love the text UI.

Main Menu shown in a browser's window through Workstation Gateway.

IBM tried to make the AS/400 more click'n'pointy. There is a facility called Workstation Gateway, translating AS/400 screen elements on the fly into their HTML counterpart, if existing. It basically works and it's clickable but it looks gross compared to modern standards: No icons, no color, no eye candy.

There's a program called Operations Navigator that comes as a Client Application, running (only) on Windows, providing graphical equivalents of some operating system commands/tasks. Some things (like the management of the integrated CIFS/SMB-Server) could be configured solely with OpNav but not with Green Screen commands and forms.

Also, the Configuration of the IBM http server is done via Web Browser, and CGI-Programs running on the AS/400. Unfortunately, this facility is painfully slow, at least on a 150. Not exactly the best promotion for IBM, trying to convince programmers and system administrators to abandon text interfaces in favor to Web Based Applications.

So, the main reason for IBM retaining the text interface is compatibility. For the rest of us, the fact that they're displayed very quickly with a lot less of resources (memory, data transfer speed, cpu cycles) needed when compared to a graphical UI is possibly of equal importance.

Concluding, the majority of information we humans consume is still text. We look at web pages, word processing documents and read PDF files in the digital world. Graphical UIs make it easier to fake screen output into looks like a book, with nice fonts, screen antialiasing and very high resolution displays like Apple's Retina Display, first introduced on the iOS platform. And it truly makes a difference! Reading long texts is easier from paper or such screens compared to a typewriter page. Or a monospaced terminal screen, be it 5250 or VT100. But reading long texts isn't what's usually be done in terminals.

Pros and Cons

… regarding AS/400 forms and menus versus GUIs:

• AS/400 forms and menus run in a space constrained area with an adressable matrix of either 80×24 or 132×27 characters. Larger screens provide larger characters but not more usable space. This is different with GUIs. Larger screens usually (can) display more pixels and as such (can) display more information concurrently. The former can be seen as a challenge for programmers to concentrate on necessary information for the immediate task at hand while omitting or postponing less important information to screens later in the necessary sequence. This could lead to improved clarity of the application's UI, and/or to the user losing overview by no longer seeing information that may be important for a given step of a task at hand.
• AS/400 forms and menus are built from tiny chunks of data compared to graphical UIs. So they can be transferred and displayed very fast. In environments where client and server are connected through high latency networks, GUIs perform poorly because of lagging response from the UI. Also, GUIs graphical representation must be built by program code running in part on the displaying client's CPU and GPU. Just displaying characters on a CRT can be done with comparatively tiny resources (a few kiB of RAM, and a processor clocked in the single-digit Megahertz range).

The only feature the AS/400 UI itself lacks is Copy & Paste. So by utilizing a terminal emulator on current GUI based desktop systems to connect to the AS/400 terminal session, one can benefit from the best of both worlds. Also, one may connect a PS/2-Mouse to certain IBM terminals, also providing facilities for selecting and duplicating text.