IBM i Modernization - The User Interface
(Part 2)

This piece is a response to comments in Linkedin discussions here and here, which included feedback to my first piece titled IBM i Modernization - The User Interface.

 

GUI Designers

One individual praised the GUI designer of one vendor saying that it was "drag and drop" and "easy". This caught my attention because I had just warned against tooling which enforced fixed positioning and other explicit (hard-coded) property settings pertaining to UI elements. Such tooling typically enforces page-at-a-time paradigms.

 

My main point was that it's better to allow the position, size, and other properties pertaining to UI elements to adjust automatically to screen sizes and resolutions, and to allow incremental screen updates rather than page-at-a-time updates.

 

There are other reasons for avoiding such GUI designers. For instance, how "easy" is the drag-and-drop paradigm when you can't find a UI widget in the "palette" which implements the attributes and behaviors which are called for in your design?

 

I'd like to share a few design patterns which enhance end-user productivity. But they're typically not found in GUI component palettes and page-at-a-time paradigms.

 

Split Screen (List and Detail)

A common design pattern under the green-screen paradigm enables users to browse lists of items, then optionally select items to show additional details and allow data editing. The "detail" screen is typically separate from the "list" screen due to row-column constraints in display files.

 

Web browsers aren't subject to display-file constraints. And it's often practical to combine scrollable lists and full-record displays in a single page.

 

Keyboard shortcuts and mouse clicks may be used to navigate list items. The moment an item is selected, the detail pane is updated. A process that normally requires two screens may be thus streamlined into one. And the toggling of "add", "change", "copy", "delete", "print" modes, and other options may not even require interaction with the server.

 

Filter Prompts

An extension of the split-screen pattern may provide pop-up prompting to enable users to filter list rows by criteria applied to any column in the data set. And again the pop-up behavior may not require any additional interaction with the server. The popup may be retained in browser cache.

 

List Rankings

Consider a process where users may optionally select list items, and rank them according to priorities. This may including toggling item-selection to one state or another. It may include automatically changing the rank of selected items when the priority of another is adjusted up or down.

 

It would be problematic if such interactions required a server to reorder and refresh entire lists when such toggling occurs in the browser. Best to handle this with browser cache and JavaScript.

 

Content Injection

Regarding the previous section on "list rankings", what if a user needs more information about an item in the list in order to prioritize? Additional details could be dynamically retrieved from the server when a row is clicked and "injected" into that row. There is no limit to row height in HTML tables. Additional clicking could toggle the display or hiding of details.

 

Graphical Representations of Physical Facilities

A simple example of this might be the configuration and depiction of classroom seating charts. A box which represents a "seat" in a "room" may contain a picture and name of a student assigned to the seat.

 

The amount of data entry which may be accomplished via graphical representations of physical facilities may surprise those who are steeped in the green-screen paradigm. Clicking on a seat to record attendance, to identify students who plan on participating in school lunch or any other type of activity. Clicking on a seat to activate a prompt for additional data pertaining to the item selected.

 

Calendars

Not to be confused with data pickers. Calendars can be used for scheduling any number of possibilities, and calendar navigation is intuitive.

 

Worksheets

Columns may represent data sets from one table; rows may represent data sets from another; intersecting cells may represent a third data set.

 

Worksheets may enable users to navigate cells with keyboard shortcuts, select blocks of cells, and update values in the most efficient way possible.

 

Touch-Screen Keypads

Particularly relevant to mobile devices, the user interface may call for a graphical keypad which overrides the device keypad and/or simulates say data entry for ATM or point-of-sale terminals.

 

Drag and Drop

Ironically the drag-and-drop behavior of GUI designers which may be praised by proponents was probably not implemented by the same. It required thinking (and working) outside of the box, so to speak.

 

Components Which Update the State of Another

A visual representation of a shopping cart, which is updated by clicking on an item, or by dragging and dropping the item into the cart. A point-of-sale system where items for sale are visually represented, and clicking on one generates a transaction.

 

Inline Frames

An email client may require inline frames representing multiple data sets such as email recipients, a sent mail list, new mail composition, and other data sets all on one screen.

 

The point is that the content of one frame may be updated independently of that in other frames. Or a change in one frame may trigger changes to others.

 

Multi-Step Dialogs

The point might be to cache the prompts in the browser along with entered-data until the aggregate is posted in the final step. Allow navigation back and forth between steps without interaction from the server in the meantime.

 

Dashboards

The point might be to push data from the server to the user for real-time updates. Or the point might be to facilitate the design of UI widgets which might not be part of preloaded GUI palettes.

 

Constraints

Preceding sections are intended to stimulate thinking - to help readers become more aware of the types of constraints which might be inherent in web interfaces which rely on GUI designers on the back-end; paired with runtime applets which are downloaded to browsers on the front-end.

 

Learning HTML, CSS, and JavaScript which enables developers to select from a variety of GUI widgets available in numerous frameworks, and/or design their own. This can be tremendously enabling, and liberating.

 

Summary

As indicated in Part 1, green-screen modernization may be a defining moment for organizations, where the risk of failure is high, and failure to meet end-user expectations can negatively impact the perception of IBM i and developers of legacy systems.

 

This piece touched on design patterns which align browser user interfaces with end-user expectations and ensures an improvement over interfaces which extend the green-screen paradigm (which normally don't meet end-user expectations).

 

GUI designers which include drag-and-drop widget palettes paired with a screen design surface may appear "easy". But they are actually impediments when user interfaces call for UI elements and design patterns which are not included in the palette.

 

This piece briefly addresses only a few comments which were posted in Linkedin discussion. This topic may call for a Part 3 (sigh).