About Green Screens and mouse-clickable UIs

From Try-AS/400
Revision as of 22:46, 12 March 2020 by PoC (talk | contribs) (De-whiched)
Jump to navigation Jump to search

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[1] means: Apply some technology that hides the crude text UI behind a fancy web UI, running in any decent web browser.[2]
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.[3]

Let me add a third party and then clean up the resulting mess. Unix/Linux[4] Sysadmins as well as Linux Power Users usually insist on using the shell, that is 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 it's best[5]: 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.

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 that try 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)[6], 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) that need a lot of typing. This is somewhat leveraged by the advent of Autocompletion capable command shells.

Some (rare) tasks feature very high complexity that 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 that is true for every task in computing[7] and is not restricted to Unix environments.

How the AS/400 Text-UI works

The AS/400 was created as a business aid, that 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.[8] 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 that aids 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.[9]

If this facility also fails to provide proper enlightenment, one may press F1 at any time to invoke a context-sensitive[10] help text, that is almost always surprisingly helpful[11]. See CL Tricks for an overview.

These features are unique among text based UIs. The ubiquitous command shell of Unix, Mac OS X, Windows and others is restricted to commands to be entered, together with (sometimes mandatory) parameters. 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.[12]

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.[13]
  • 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[14] that translates 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, that provides 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.[15]

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.[16]

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.[17]

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 an IBM 3486 terminal that also provides facilities for duplicating text.

Footnotes

  1. ↑ Due to constraints of the money made available to achieve this goal.
  2. ↑ 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 (Un)known (un)knowns.
  3. ↑ 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 Tab-Key?
  4. ↑ 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.
  5. ↑ Or worst.
  6. ↑ 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.
  7. ↑ And in real life.
  8. ↑ 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.
  9. ↑ 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 F4-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.
  10. ↑ This means: The shown help text is different for different cursor positions on the screen.
  11. ↑ Compared to the help texts in early Windows operating systems.
  12. ↑ 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 that helps in completing the command line utilizing familiar graphical UI elements.
  13. ↑ Entering help 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.
  14. ↑ Usually available on http://your-as400-ip:5061/wsg after starting the appropriate TCP service.
  15. ↑ If you find out who took this decision, please let me know. I'd love to unload some serious cusses on him.
  16. ↑ Fortunately, the configuration is text based and saved in a database file.
  17. ↑ MUDders and Zork-Players: I know you will gasp now. Sorry, but you're really the opposite of usually. Don't take it personal.
Retrieved from "http://try-as400.pocnet.net/index.php?title=About_Green_Screens_and_mouse-clickable_UIs&oldid=813"