Nathan M. Andelin   October 2016

IBM i Modernization - The User Interface

(Part 3)

Part 1 and Part 2 in this series addressed constraints in IBM i-centric tooling that is commonly used to move green screens to browser user interfaces. I highlighted options that ensure an improvement in user experience and the type of infrastructure and tooling that facilitates web application development.

Comments and feedback surfaced during Linkedin discussions that merit further review. In this piece, I'd like to address the topic of Front-End-Driven Applications (FDAs) and Single-Page Applications (SPAs).

Single-Page Applications

A good definition of single-page applications is found in Wikipedia. It delineates both pros and cons. Key traits include:

  • Content fits in a single page.
  • Resources are downloaded in connection with an initial page request.
  • May dynamically download additional resources that update page content.
  • The initial page is never replaced.
  • May give the impression of loading additional pages.
  • May incrementally update the page in response to UI events.
  • May incrementally update the page in response to push events from servers.
  • Employs standard browser technologies (HTML, CSS, JavaScript, AJAX, Web Sockets).
  • May provide a user experience similar to desktop applications.

Front-End Driven Applications

The key trait of front-end driven applications is that of providing a user experience similar to desktop applications. They may adopt platforms such as Microsoft Silverlight, Adobe Flash, and Adobe Flex in addition to HTML5, etc.

FDA's may be embedded in a single page. But proponents add that the applications tend to be self-contained and developers attempt to reduce or altogether eliminate server dependencies.

FDA and SPA Frameworks

FDA and SPA frameworks often include extensive client-based infrastructure (i.e. model-view-controller or model-view-view-model), large libraries of script-based UI widgets, developer APIs, and associated tooling.

Some vendors of IBM i screen-scraper and open-access tooling try to position their products as SPA frameworks, presumably to generate positive buzz. The emulator (JavaScript applet) that they download to browsers has some SPA traits. But the interfaces actually have substantial differences.

JavaScript applets are not really frameworks. Frameworks are not really applets. Frameworks include developer components and programming APIs. Applets implement runtime environments. SPAs are client-centric. The display-file paradigm is server-centric.

FDA and SPA Developers

Developers and proponents of FDAs and SPAs tend to:

  • Prioritize and base application design on and around the end-user experience.
  • Acquire, develop, and deploy platforms and frameworks that have a similar orientation.

IBM i developers tend to be loyal, traditional, nostalgic, and focused on product domains. FDA and SPA developers tend to be geeky and focused on trending client technologies.

IBM i developers and FDA/SPA developers often differ because the IBM i platform is comprehensive, server-centric, database-centric, multi-user centric, and cohesive.

An SPA developer recently characterized me as living in the old paradigm where the server generates and controls the UI. Those who have read the pieces in this modernization series that precede this one should know - that's not an accurate depiction of me. I advocate for designs that enable browsers to be fully utilized while providing rich end-user experiences. On the other hand, I view myself as an IBM i-centric developer too.

Balance

In my opinion, it's possible with IBM i and browser technologies to strike a nearly ideal balance between:

  • Platform-centric design and development.
  • Data-centric design and development.
  • Domain-centric design and development (object-oriented).
  • Client-centric design and development.

There appears to be a tendency for developers to become dogmatic about one of the orientations listed above, even though they all have pros and cons. I find extremes in every community. The platforms and frameworks that support FDAs and SPAs tend to be uber-geeky and overkill. It's better to strike a balance.

The Problem with FDAs and SPAs

Wikipedia article delineates the following issues with SPAs:

  • Search engine optimization.
  • Browser history.
  • Analytics (what and how much is being used).
  • Size and performance of initial page load.

Given the context of IBM i application modernization, I would add:

  • Not well suited for broadly scoped functionality.
  • Not well suited for multi-user data concurrency.
  • Not well suited for reports.
  • Popular frameworks tend to be uber-geeky.

In the remaining sections, I'd like to share a few tips in regards to achieving a balance between IBM i-centric technologies and browser technologies.

Multi-User Broadly-Scoped Applications

FDAs and SPAs may be great for running narrowly-scoped applications. But what about applications that entail working with dozens if not hundreds of shared data objects concurrently?

IBM i is exceptionally suited for this type of application. The implementation of such often entails many program calls, many data objects, and many screens within a single session (JOB) as users require options for sharing, navigating, and working with complex relational databases.

A browser-based implementation of a complex application might entail a URL such as the following:

https://mydomain.com/path/{{session ID}}.ext?appID='at-your-service'

Each part of the URL is relevant. However, in the context of this treaty - notice the {{session ID}} and the "appID" parameters. The {{session ID}} enables the request to be routed to an individual IBM i JOB that provides stateful services for only one individual client. And the "appID" parameter enables calls to any number of individual applications.

The interface enables individual browsers to invoke any number of "applications" - all associated with a single session. There's no limit to the number of program calls, open data paths (data objects), or UI content that may be provided by the server.

The interface requires a web portal for launching any number of "sessions" from menu items, some infrastructure for routing requests to the corresponding IBM i servers, and a utility for automatically invoking any number of applications when an "appID" changes.

Individual applications may embody many of the traits of SPAs while the application is in use. But the interface also supports calls to other applications that may output new pages. Thus keeping applications modular, manageable, and easily extendable.

Middle Ground

It's both interesting and troubling to see the pendulum swing back and forth between client-centric and server-centric technologies. I believe that a nearly-optimum balance lies in the middle.

Rather than tasking browsers to download and host large FDA and SPA frameworks (which are essentially platforms themselves), developers can create applications that incrementally download modest amounts of HTML, CSS, and JavaScript, that deliver similar results as SPAs, while using modest amounts of browser cache and browser scripting capabilities.

Criticism and Feedback

This piece evoked some criticism and feedback that:

  • I'm mistaken about FDAs and SPAs.
  • I don't understand FDA and SPA Frameworks.
  • Frameworks are required to create UIs
  • Any UI will be obsolete after a few years.
  • Lack of UI standards is a mess.

I'll leave it to readers to do their own research about FDA and SPA frameworks and determine for yourselves whether I misunderstand them. I may provide detailed hands-on examples in future pieces that may clarify my perspective.

In regards to there being a lack of standards, and UI obsolescence after a few years, I have only found that to be true in regards to GUI widget frameworks that are typically written in JavaScript, and present a UI that is quite different in look and behavior from standard HTML elements.

I encourage shops to settle on CSS styling applied to standard HTML elements, and share the CSS file across all applications. That practice endures well.

Summary

The topic of moving from green-screens to browser user interfaces often evokes polarized debate between proponents of platform-centric, data-centric, domain-centric, and client-centric alternatives. FDAs and SPAs are client-centric options.

Much of the dogma surrounding alternative design and deployment options is not only polarizing; it's misleading and unhelpful. In my experience it is possible to achieve a nearly-optimum balance by an appropriate pairing IBM i-centric, data-centric, domain-centric, and client-centric options.

Continued in Part 4.