The Art of Translation - IBM i

Posted by Trevor Perry on Nov 20, 2012 1:38:00 PM

   

As green screen developers, we are a community with blinders on!

So that is a controversial way to start a blog entry, but it is my world. As a consultant, teaching modernization, there is more than technology to teach. Given I am not a qualified therapist, all I can do is to offer some sensible thoughts on modernization outside the technology, and understand that it won’t always stick.

Show me your face.

Let’s begin with a little facing. Choosing the design of a modern application is often difficult for traditional green screen programmers, even though they have been using GUI and web applications for a couple of decades now. In 1991, Al Gore invented the internet - er.. wait, he actually never said that. He did, however, introduce the High Performance Computing Act of 1991, which was the vehicle that turned the internet into the World Wide Web.

Given that we have had the WWW since 1991, most of us have watched it evolve. A reasonable example of that evolution can be made by comparing Amazon’s first web page in 1995, with their current web page in 2012. Here are the snapshots to compare:


Amazon2012 1995

And Windows has been in our world for a long time, with Windows 3.0 being the first graphical OS from Microsoft in 1990. What a difference 22 years makes - compare Windows 8 here:

Windows2012 1990

By now, with two decades of being users of graphical and web user interfaces, it should be possible that when we build such an interface to our applications, new, refaced, or repurposed, our designs consider all that we know as a user. Yet, it does not happen, and this is where the blinders come in.

(Note, for those outside the US, blinders is the US equivalent of blinkers - not to be confused with those things on cars that are used only when the radio is too loud.)


Getting Started.

Now for the facing - starting with the Sign On screen. Can you find a web page where the application refers to it as a “screen”? This terminology is truly outdated, and is a developer reference. Even then, given that we often display multiple record formats to make up one green ‘screen’, we are simply adding confusion when we use this word. Users know about web ‘pages’, and even though that is better terminology

Next, can you find a web page where there is a “Sign On”? Certainly, there is a lot of confusion about what a user is doing at this point, and many websites will require a user to Sign In, Log In, Log On, Logon or Login. The correct answer in this case is to use the same terminology for all your applications company wide. Obviously, you must consider what you are asking the user to do - should they login from the Log In page, or should they log in from the Login page? Which is the noun (the page title), and which is the verb (the user action)? This concept applies to more than the first page, and it should be applied to all forms in all applications. The key purpose is to be correct in terminology, and the underlying theme is consistency.

What is it called?

The next step is to look at the terminology being used in your applications. Our green screen blinders need to be removed from the user interface design. Having become familiar with terms over many years of application development, we tend to ignore things that are otherwise meaningless to new users. If your audience is to a user base that is primarily being upgraded from green screen to a modern application, they will have an advantage of being familiar with the terminology you have forced upon them over many years. If any part of your audience is not familiar with your green screen application, then you are adding a step of translation for every one of those new users. Any time you add translation to the user experience, you are slowing that user down by fractions of a second - if you add up those fractions for every time it occurs, you are ensuring the user experience is degraded on any given day.

Here are a few examples of terminology that will confuse the modern user experience.

1. Spooled files.

A new user, upon encountering this term, may think it is something about fishing or knitting - some kind of activity where a thread or line is involved. They would never know what a spooled file is until someone educated them on the terminology. Even then, it may be written as ‘spooled file’, ‘spool file’, ‘SPLF’, ‘spoolf’, ‘splfile’, or another of the hundreds of inconsistent abbreviations used by green screen programmers.

To choose the correct terminology, research what application output is called in other applications. Spooling the output for later printing does not mean it should be referenced as ‘printed’. The most common and obvious answer is to reference this output as ‘reports’, and from there, a consistent naming can be used across all company applications.

2. Work With.

This verb was introduced by IBM into the OS/400 operating system to aid the developer and the operator. Normal end-users do not “work with” customers, or “work with” inventory.

The simplest solution is to remove this verb from the places where it is found - usually menu options and screen titles. When a user wants to look at the customers, they are going to find a button or menu option that indicates ‘Customers’. From there, knowing it is a button, they will know if they click, they will be able to see their customers - and therefore, perform all the ‘work’ necessary.

3. Job.

If you ask a user for the definition of ‘job’, they will be more likely to talk about their employment, rather than one or more IPO tasks running on a computer server somewhere. When they feel this way, they may be very confused if you were to tell them to ‘submit your job’, ‘cancel your job’, ‘end your job’, or, as we know so well: ‘kill your job’.

In this case, it is not even about the particular terminology. There is absolutely no reason at all for a user to know anything about the undercover work being performed on the server. If your server is tuned well - that being, it is tuned to suit the business requirements, then telling the users anything about jobs is redundant. They should only need to be told when their report is ready, or their workflow process is complete, and all that can be done without mentioning, “Your submitted job is complete”. In this case, removing the functionality of accessing system jobs from the user is the best solution.

4. Subfiles.

At the beginning of the history of green screen application development, the trend was to shove as much functionality on to the one green screen as possible. This was to counter the very slow servers running the applications. The design approach was to collect as much information from the user before sending it to the CPU for processing, then perform everything at once while the CPU is prioritized to that user’s job. Upon return, bring back as much information as possible to show the user, so they spend a lot of time analyzing manually, to reduce the workload on the server.

It is rare to have such significant performance problems with modern servers. It is time to dust off that old design approach that we have forgotten, and add it back to our repertoire: ‘one panel, one function”. Since we have trained our users to ask for MORE information on EVERY screen, we are going to have to understand the user experience much better. Designing modern applications requires some changes to our thought processes. For example:

(Green screen) We used Fold/Unfold to allow the user to see the main information about multiple line items, then see more information about a few of those line items on the press of a key. If the user needs all the information, they must type a number or letter for the line item and press another key.

(GUI/web) We show the user the main information about multiple line items, then on one click they see ALL the information about a specific line item.

Another example:

(Green screen) We show the first page of the subfile, regardless of what information the user will need. This first page will take some time to display, thus the user is slowed down even on the first time they selected the menu option. To filter the list, we pop up a window to ask for the filter criteria upon the press of a key, then on the press of another key, we apply that filter to the subfile. We also have another special process to position a list at a certain location in the list, and when used, the user is prevented from moving backwards in the list without re-applying the filtering process or pressing another button for refreshing the page.

(GUI/web) We show an empty page with one or more filter choices at the top of the page. The user adds filter criteria, and clicks on one button to see the information they require. There may be one button for refresh, but the concept of ‘Position To’ is not available.

 

What next.

These examples show only a few of the changes that have to be made by green screen designers and developers to their own techniques. Modernization of our own skills is required. Learning new disciplines, such as graphical design and user experience, are key to having a future in I.T. While it is rare for a single person to be skilled in all these disciplines, it is important to understand them well enough to be able to communicate with other team members who do have these skills. And, communication with the users is always the most important skill to improve. Understand what they need, rather than deliver a fait accompli solution where they must perform their workflow processes with a system designed and built by someone who does not understand their workflow processes.

It is already twelve years into the 21st century. Are you still developing with a methodology you learned and honed in the 1990s? Adopting new methodologies, learning modern techniques of design and development, and understanding the user requirements is going to improve the applications, improve the user experience, reduce the maintenance effort, and provide business benefits far beyond saving I.T. costs. It is time to remove the blinders!

Topics: IBM i, GUI