View source for 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 [[wikipedia:Editor war|Editor War]] EMACS versus vi or vim.

== Introduction ==
Some people insist that character based UIs are hopelessly outdated and '''must''' be modernized. That usually<ref>Due to constraints of the money made available to achieve this goal.</ref> means: Apply some technology that hides the crude text UI behind a fancy web UI, running in any decent web browser.<ref>Modern Web browsers incorporate so much more functionality than just rendering text and graphics, as it was in 1993. This fact is reflected in numerous fixed security holes in modern Web Browsers. There are so much more yet to be discovered, though. See also Donald Rumsfeld's musings about [[wikipedia:There are known knowns|(Un)known (un)knowns]].</ref><br />
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.<ref>Nowadays, people are expected to know how to use a computer. Training at company level isn't done anymore. This leads to even worse efficiency: How many times did you wince in silent pain when someone actually clicked into another field of a form instead of just pressing the <code>Tab</code>-Key?</ref>

Let me add a third party and then clean up the resulting mess. Unix/Linux<ref>To keep the text reasonably readable, I refuse to make a difference between UNIX (as in SystemV, BSD and whatnot) versus GNU Linux Systems. Today, both platforms are akin enough to justify this heresy.</ref> 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.<br />
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<ref>Or worst.</ref>: 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.<ref>Weird? I think so, also.</ref>

== 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)<ref>I want to emphasize that using a mouse is also a perfectly valid data acquisition method. One example is the refinement of pixel based pictures. Automatic methods work only to a certain extent and some pixel-modifications still are best done by a hand guiding an input device to steer a cursor on screen.</ref>, 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 [[wikipedia:Pipeline (Unix)|pipes]]), usually requiring a lot of typing. This is somewhat leveraged by the advent of [[wikipedia:Command-line completion|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<ref>And in real life.</ref> 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.<ref>Keep in mind that commercial and scientifical computing relied on punched card decks for input and paper prints for output right into the 1970s: Classical Batch Processing.</ref> 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.

[[File:Main-menu.png|thumb|right|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 <code>Enter</code> 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 <code>F4</code> 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 <code>F4</code> to be presented with ''another'' screen, listing allowed values for this particular parameter.<ref>Interestingly, there are situations when you are forced to enter data from your (brain based) memory into a field instead of the system letting the user choose from available choices on another <code>F4</code>-invoked screen. A notable example is when you want to create a ''line description'' configuration object, you’ll need to do a manual lookup of available hardware IDs before.</ref>

If this facility also fails to provide proper enlightenment, one may press <code>F1</code> at any time to invoke a [[wikipedia:Context-sensitive_help|context-sensitive]]<ref>This means: The shown help text is different for different cursor positions on the screen.</ref> help text, which is almost always surprisingly helpful<ref>Compared to the help texts in early Windows operating systems.</ref>. 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<ref>Depending on the terminal emulator, a scrollback-buffer can be configured to allow retrieval of older output messages within the GUI.</ref>.<br>
Any help for a command’s parameters must be invoked by separate facilities (e.&thinsp;g. invoking the command with a [[wikipedia:Command-line interface#Command-line option|parameter]] to show an usually terse online help, or by reading Unix [[wikipedia:man page|Man-Pages]]), and manually complete the command line by re-entering the needed command options.<ref>The only other known system with a comparable function is Apple’s legacy Unix system ''A/UX'': Double-clicking a command (as opposed to an Application Program) opens a modal graphical display box, helping in completing the command line utilizing familiar graphical UI elements.</ref> 

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.<ref>Entering <code>help</code> within a ''bash'' Linux Command Line prints overwhelming 46 lines of internal commands. The important lines how to actually get more help have scrolled out of the usual 80×25 window.</ref>
* 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
# just isn't implementable with hardware already bought by customers,
# existing applications would only take minor advantage of (if any!),
# it would upset system operators who mostly learned to love the text UI.

[[File:Main-menu-wsg.png|thumb|right|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''<ref>Usually available on ''<nowiki>http://your-as400-ip:5061/wsg</nowiki>'' after starting the appropriate TCP service.</ref>, 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.<ref>If you find out who took this decision, please let me know. I'd love to unload some serious cusses on him.</ref>

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.<ref>Fortunately, the [[IBM HTTP-Server for AS/400 Configuration|configuration]] is text based and saved in a database file.</ref>

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.<ref>MUDders and Zork-Players: I know you will gasp now. Sorry, but you're really the opposite of ''usually''. Don't take it personal.</ref>

== 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 [[wikipedia:Cut, copy, and paste|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 [[Using the Mouse on a Hardware Terminal|PS/2-Mouse to certain IBM terminals]], also providing facilities for selecting and duplicating text.

== Footnotes ==
<references />

[[Category: Musings]]