By: Tony Marston, Director, Research & Development, Geoprise Technologies Licensing

GM-X is an enterprise resources planning (ERP) system which was first created in January 2007 and went live at the first customer in June 2008. It was designed from the ground up as a Web application comprising a group of interconnected subsystems, and was developed using the RADICORE framework which I built in 2002 and published in 2006. GM-X has been continually enhanced and new subsystems added since its debut. Today it has 17 subsystems.

Each subsystem has its own database and its own collection of tasks (user transactions). Currently there are 389 tables, 759 relationships, and over 3,000 tasks of which 2,720 have visible screens. Others use portable document format (PDF) output, comma-separated value (CSV) output for use in spreadsheet software such as Excel, or have no visible screens at all.

Recently, Geoprise introduced a completely new responsive Web user interface for our GM-X ERP for Blockchain application suite using the Bootstrap library. Unlike traditional enterprise resources planning (ERP) applications which were designed exclusively (or primarily) for use on desktop computers, GM-X is now the world's mobile-first ERP. How this was achieved is the subject of this article.

What Is "Responsive Web?"

Here is where we need to delve into the recent history of mobile device capabilities. The Apple® iPhone®, launched in 2007; and the iPad®, launched in 2010, were the first mobile devices to really gain traction in the consumer marketplace. Not coincidentally, these were the first devices to combine the color graphical user interface (GUI) found on personal computers (PCs) with touchscreen interaction (no stylus required) plus automatic screen rotation.

Before then, with the exception of mobile barcode scanners, virtually all business applications used conventional desktop layouts and a color GUI which worked equally well on desktop PCs and laptops, using mouse (and occasionally touchscreen) interaction but no automatic screen rotation. This meant that most screens for business applications could be designed using a single static form or table which fit inside a standard computer monitor.

The introduction of smartphones and tablets changed all that. Now, the same Web application can be displayed on at least 3 different screen sizes (desktop, tablet, smartphone) and 2 different orientations (vertical and horizontal, for tablets and smartphones). In order for the application to be just as easy to use in one mode as in any other, an adaptive user interface design requires a multiplicity of static layouts to deal with different combinations of screen sizes and orientations.

It is possible to display a Web page incorporating a static layout designed for desktops on a tablet or smartphone, but the browser will shrink the content to fit depending on the screen size and orientation. This often makes screens unusable without zooming in to make the contents legible, and to make touchscreen interaction practical. But most people (especially those who suffer from fat finger syndrome) complain that applications are cumbersome to use when they have to zoom in and out.

Mobile-First Principle

It’s a fact of life that small screens are the hardest to design. Consider a screen with more than 50 possible functions that can be executed when the user touches or clicks an icon, hyperlink, button or control, all designed to fit on a 1024 x 768 resolution display (108 square inches on a 15-inch monitor). An equivalent set of functions would also need to fit inside 10½ square inches on a Samsung® Galaxy S4 smartphone, either vertically or horizontally, and should be just as legible and easy to use as a desktop display. The resulting number of functions per square inch is 6.2 on a smartphone versus 1.7 on a 15-inch monitor — almost four times the density.

To make full use of new device capabilities, best practice evolved into two competing schools of thought:

• Progressive enhancement (“mobile-first”) assumes that mobile design, which is the most difficult, should be done first. This means that the smallest screens will have only the essential functions. Additional, less-essential functions are exposed as screen size increases.
• Graceful degradation is the opposite. All functions are included for the largest possible screen size, and then the less-essential functions are removed as screen size decreases.

“Mobile-first” is generally considered better practice because mobile devices have the most constraints; therefore designing within these constraints forces the ruthless prioritization of content (i.e. “mobile-first = content-first”).

This principle however only makes sense for use cases which require the content and functions to be delivered satisfactorily regardless of device size and orientation. This frequently isn’t the case for business applications. For example, mobile barcode scanners used in warehouses must follow a “mobile-only” principle because you’ll never find warehouse personnel lugging PCs or laptops around when they pick or put away products. On the other hand, in a business setting, intensive data entry screens would almost never be used on anything other than a traditional desktop PC having a full keyboard with numeric keypad, because:

• Operator mobility is not a requirement;
• Even though they are much bigger than tablets and smartphones, PCs and laptops are frequently much cheaper, so there is no economic incentive for using mobile devices; and
• The virtual keyboard available on tablets and smartphones is simply not as productive, especially when the virtual keyboard conceals some of the content.

In general, I think the “mobile-first” principle is most appropriate for use cases which consume content — for example, reading data in tables, tree views or read-only forms, after looking it up using a search form — but is often (yet not always) inappropriate for use cases which create content, as is the case for data entry forms unless, for example, you are using mobile scanners in a warehouse or approving employee timesheets while traveling. So the basic approach we took when creating the Proof of Concept (PoC) was to focus primarily on the performance of screens which consume content, regardless of screen size or orientation.

As it turns out, the original philosophy of the RADICORE framework on which the GM-X application was built lends itself perfectly to a “mobile-first” approach, even though it was never conceived for this purpose. I posted this reply to a question in April 2006 —  before the advent of the iPhone and iPad:

I avoid the situation where I try to pack as much information as possible into a single screen for the following reasons:

• It becomes slower to build the screen due to the amount of data that has to be retrieved.
• As well as the data for each zone you may also need a separate scrolling/pagination area or each zone, which adds to the clutter on the screen.
• Although a small number of people like to see everything on a single screen, most other people complain that the screen is ‘too busy’, and that the information they are looking for is lost amongst all that ‘noise’.
• Some people seem to think that having to navigate to different screens to see different sets of data is a slow and cumbersome process. Such people have not experienced the navigation buttons within Radicore.

The Radicore philosophy is to keep each screen as small as possible so that it loads fast, and use navigation buttons to quickly jump between associated screens.

In another place I wrote: “The Radicore philosophy is to have a large number of small and simple components instead of a small number of large and complex components.”

I think everyone can agree that “graceful degradation” is impossible to achieve without a massive amount of manual effort when all the content and functions are packed into a single, complex screen. But “progressive enhancement” (i.e. “mobile-first”) is straightforward, and can be accomplished with relatively little manual effort when you are starting out with screens that were deliberately kept as small as possible from the get-go.

Note that some “progressive enhancement” design decisions were made when developing the PoC. For example, smartphone-sized screens the static English text “You are logged in as:” as well as the last login date, time of day and user time zone do not appear — only the user name is displayed. This avoids wrap-arounds on vertical orientations without eliminating any functionality, particularly since most smartphone devices display the current time of day just above the screen anyway. The print and noprint icons were removed from the top right of small screens as they are irrelevant for mobile devices. As the screen width increases, the desktop-style “You are logged in as:” as well as the last login date, time of day and user time zone will appear along with the user name, print icon and noprint icon.

Another example of “progressive enhancement” is the use of hamburger menu (bars) on small or narrow screens instead of navigation buttons. As the screen width increases, the hamburger menus will disappear and individual navigation buttons will be displayed instead.

The third example of “progressive enhancement” is what happens when tables are displayed on screens which are narrower than the minimum width of the table’s columns. This makes each row become a table in itself, but only as wide as the screen, and each column is displayed as a separate row. As the screen width increases, the table will display in the standard row-column format familiar to desktop users.

Responsive Web Design Approach

The differences between responsive and adaptive design are discussed in GM-X: The No-Page Web Application. For the PoC a decision had to be made between using the responsive or adaptive approach, and the responsive design was the winner. For further insight see Responsive vs Adaptive Design — Which is Best for Mobile Viewing of Your Website?.

For Geoprise the most important factor is that, as far as we can tell, the adaptive design approach doesn’t work when you rotate a tablet or smartphone screen, because:

• Tilting the device won’t cause a page to be reloaded; and
• When deciding which layout to load, the server can only tell the screen size but not the orientation.

While testing our responsive Web design we could see that screen appearance and behaviour may differ between horizontal and vertical orientation – something which is not possible using an adaptive design approach.

Proof of Concept

It all started in May 2017 when Nelson Nones, the Founder of Geoprise, demonstrated to me a hypertext markup language (HTML) document which he had created as a PoC. This document was originally generated by the GM-X application, but had been amended to incorporate references to the Bootstrap library. He showed how, by changing the size of the browser window, the document automatically resized the controls so that they were readable whether you were using a full-sized desktop monitor, a tablet or a smartphone.

HTML=XML+XSL

The modifications to the original unresponsive HTML document included adding links to a series of cascading stylesheet (CSS) and JavaScript files as well as modifying certain HTML tags in order to reference the necessary CSS and JavaScript elements. The GM-X application currently contains over 2,700 HTML forms, so it would appear that converting all of these forms would be a major exercise requiring huge amounts of man-hours. However, this was not the case as the application was written using a model-view-controller (MVC) framework in which every Web page is constructed at run-time in two steps:

1. Construct an eXtensible Markup Language (XML) document containing all the relevant application and framework data.
2. Convert this document into HTML using an eXtensible Stylesheet Language (XSL) stylesheet.

This is explained more in GM-X: The No-Page Web Application.

The uninitiated may assume that every single web page requires its own XSL stylesheet as each page has different content, but they would be mistaken. While this was indeed true in the original development of the framework, by refactoring all the duplicated code so that it could be instead referenced from a shared library I gradually reduced the amount of code in each stylesheet to such an extent that by 2004 I had 12 reusable stylesheets which could produce any page required by the application. Yes, that is correct — all 2,720 forms are produced from just 12 stylesheets.

LIST view and DETAIL view

When writing software the aim is to reduce the amount of code which is written by making use of reusable components so that instead of writing another piece of code to perform a function you instead call a pre-written component from a central library which performs that function for you. In order to do this you must first identify repeating patterns which become candidates for insertion into the central library. Those of you who have built many Web forms should recognize that when displaying application data there are basically two views, a LIST view and a DETAIL view.

The LIST view displays data from several database rows in a table. On a screen designed for desktop and laptop monitors, each row’s data goes horizontally across the page. Above these rows is a single row of labels (column headings), as shown in the following diagram:

The DETAIL view displays data from a single database row. On a screen designed for desktop and laptop monitors, the row’s data goes vertically down the page with labels on the left and data on the right, as shown in the following diagram:

It is also possible for several pieces of data to be displayed on the same line in a DETAIL view, as shown in the following diagram:

But wait; there is more. In a DETAIL view it is also possible to have labels and/or data spanning more than one line, as shown in the following diagram:

Each web page contains more than just application data. It also contains a series of zones or areas, each having a different purpose and filled with data which is extracted at run-time. The following diagram shows the various zones in a simple LIST view:

The various zones in a DETAIL view are shown in the following diagram:

These zones may be used for read-only forms, and also for data entry forms which insert, update or delete database rows.

Other transaction patterns used for GM-X screens have different mixtures of both DETAIL and LIST views in the same screen, but is not necessary to document each and every one in this particular article.

Embed Each Screen’s Structure in the XML Document

Those of you who have dabbled with XSL transformations may be asking how is it possible to have a single XSL stylesheet which displays a different set of columns from different tables in the database? My biggest breakthrough when developing my reusable stylesheets was to discover how to embed the structure of the eventual HTML document within the XML document, and to have the XSL stylesheet process this XML data to produce the desired structure. This data in the XML document for a LIST view looks something like the following:

This tells the XSL stylesheet that data from table ‘x_option’ goes into the zone called ‘main’.

This data gets transferred into the XML document from the contents of a small screen structure script which is written in PHP, and which looks something like this:

This script also identifies which XSL file is to be used to perform the transformation.

The XML structure for a DETAIL view is slightly different:

The associated PHP script is also quite similar:

For the more complicated DETAIL view where each line of the screen contains labels and data for more than one column the structure details are slightly different:

While reading the bootstrap documentation I noticed that the column widths used in the DETAIL view could not be as varied as they currently were as, due to the way in which it was built, there can be no more than 12 cells to a row, and each cell must be a multiple of 1/12th or 8.33% of the current screen’s width.

Implementing the Change

Before I changed the software to access all the Bootstrap components we discussed how best to implement this change. Instead of making an irreversible global change we decided that, as some of our pages are very large and complicated and suitable only for a desktop monitor, we would make the switchover to be entirely configurable. To achieve this I amended the Menu Subsystem database to include a column called allow_responsive_gui (boolean) in both the Task and User tables. Unless both these switches are turned ON the screen will still be displayed in the old non-responsive mode.

As I had to make changes to my collection of XSL stylesheets in order to generate the different HTML output required by the Bootstrap library I decided to put all the necessary code, which includes the CSS and JavaScript (JS) files, in a separate directory called responsive-web. If any installation does not contain this directory then no responsive HTML can be generated.

As for application code, as I have stated previously all HTML output is generated at run-time by generating an XML document which is then transformed using an XSL stylesheet, and all this processing is performed in a single View object. Any changes to the contents of the XML document which are required by the responsive XSL stylesheet can be made in this single object and then be instantly available to the entire application. When this object detects that the responsive web option is available and has been turned on it can then add in the links to the necessary CSS and JS files. The biggest problem I had to address concerned the column widths in the DETAIL view as the Bootstrap library divides the screen into a grid having no more than 12 cells across. This means that each cell has a fixed width which is 1/12th of what is available in the current browser window. I then had to modify the contents of the <columns> element so that instead of this:

It included a new attribute called grid_size:

You should notice here that the sum all of the grid_size attributes is 12, and no cell is allowed to have a grid_size which is less than 1. All the other sizes have to be rounded down to the nearest 1/12th. Fortunately there is no such limitation on the LIST view so that you can continue to have any number of columns with any width.

I then to went through all the GM-X XSL stylesheets and modified the code for each DETAIL view so that it output the correct HTML required by the Bootstrap library. It took me one week to modify the first stylesheet, then once this was done it was a relatively simple matter to duplicate those changes in the remaining stylesheets. If I had a separate stylesheet for each of my 2,720 screens this would have been a mammoth task, but due to my development of reusable stylesheets this number was reduced to 12 (twelve).

That is why this task was completed in less than one man-month and not several man-years.

The only other task was to test each screen to ensure that when a column width was reduced to the nearest 1/12th that it did not become too small, otherwise I had to amend the screen structure script to specify a better width. This took a little longer, but was purely a cosmetic exercise.