PHP and the i, Part 3

Tweet
This entry is part 3 of 3 in the series PHP and the i

PHP and the i

So far in this series we’ve discussed how PHP can be the perfect adjunct to an RPG-oriented business system providing the kind of high quality web pages that everyone feels they need. In the articles I’ve seen elsewhere on the web, the emphasis is always on how to connect PHP to RPG or vice versa. No one ever talks about how to create quality pages, what they should look like, how should they be structured, and so on.

The reason for that is simple: we don’t need no stinkin’ instructions for that! Everyone knows how to design good screens (opps, pages). That’s the easy part, right? Well, maybe not. We certainly don’t have to look far to find examples where that just isn’t true – pages, that if they were designed with efficiency and intuitiveness in mind, it’s hard to tell what mind they were playing to.

Of course, business pages are different from the pages that we may develop for a blog or website. It’s not that the way a page looks isn’t important, it is, but the way input fields are organized and the efficiency with which one can go through a page and enter data is very important for business pages. That is especially true for i users; the green screen that they are used to working with is unrivaled for speed and ease for hardcore data entry. As pretty as they can be, sometimes switching users to a GUI screen results in mixed reviews.

So, in this article I’ll talk about some things worth considering if you want to create quality, well structured pages (which we all do, right?).

Number of Switches

For my money, the number one thing to look at in designing business pages is the number of ‘switches’, times when you switch from the keyboard to the mouse or trackpad or scroll bar and then switch back. Every time you do that, you have to move your hands and change your focus, and there is nothing that causes errors and fatigue as much as changing your mental focus. As a result, we want to strive for a minimal number of switches.

You’re probably saying “yeah, no kidding.” It does seem like an obvious thing. But if you look at many pages out there, limiting switches does not seem to be the number one priority. One example that comes to mind is entering dates. In the green screen world, you can just key in the date 20130130 and keep going. If you key in 20130143 then an error message pops up. But in the web world, when you have a date field you get a calendar pop up and you get to select the date you want with the mouse or trackpad. All in all, it takes about three clicks and two switches to do this, more if you want a date that is not in the current month. It completely changes the focus of your mind from looking at characters to dealing with a graphical representation. It is cool and all, especially with the new CSS3 capabilities, but efficiency, not coolness, is the goal when working with business screens.

The example also illustrates how the business system environment is different from that of a more normal web page. Someone planning a vacation can really benefit from seeing dates in a calendar format. For them, the extra keystrokes pay off in terms of fewer errors, particularly errors that can’t be edited, like leaving on Wednesday instead of the Tuesday that you wanted. But in a business context I might be reading the ‘delivery date requested’ off a paper work order and don’t need to see no stinkin’ calendar. I just need a field were I can key in 20130315.

The enemy here is shifting focus. As much as we like to pretend, humans really aren’t all that smart. If we can concentrate on one thing at a time, like reading text and keying data into fields on a screen where the cursor moves as automatically as possible, we’re OK. It’s a one to one mapping, don’t you know. But when the entry formats start to change and get mixed, it becomes more difficult, which in turn makes us tired and more likely to make mistakes.

Mirror The Task, Not the Database

A long, long time ago, back when dinosaurs ruled the earth and before people lived in houses, developers would design a business screen to mimic the database that stood behind it. We would have a function that did Product Master maintenance because there was a product master file, and another one that did Product Structure maintenance because that was a file, and a third that set up routings to tell you how to make the product. The process of setting up a new product would involve three separate functions.

As time went on, people began to see that what was really important was not setting up a Product Master record, but rather setting up a product. As a result you would want to develop a function that resulted in a product being created. Yes, it updated the Product Master but it also allowed you to enter a variety of oddball fields in a number of other files that needed to tie into the Product Master in order to fully define a new product. In other words, the key thing became the business task and not the file that was being affected.

This is very important today as staffs shrink and more and more people become responsible for interdisciplinary tasks. When your user has a business task to do, the last thing you want is for them to have to go to two or more functions to get this done. As technical people we are very data base oriented but you really need to dig into what the user is doing and how you can accomplish that within a single screen or function. You have to understand what data they enter, what data they need, how often they do enter or use a given piece of data, and how the various elements relate to each other.

How do you do that? Well, you can ask, but just as crime scene witnesses are often notoriously unreliable about what happened, so too are many users not very good at remembering what they really need. You have to watch them in action, speak to a variety of people, get a solid understanding of the task, what its components are, and how it relates to the company as a whole.

Watch Out for the Fold

Does having data appear “below the fold” really impact the likelihood of it being seen? For business systems, the question becomes whether having data appear below the fold impacts the efficiency of the screen.

For regular websites, until a few years ago, having info below the fold was an obstacle to it being seen. Today, users are more sophisticated and understand that scrolling down is an essential part of the web experience. Business pages are a little different, of course. The user doesn’t have a choice to scroll or not to scroll, they must scroll down in order to finish their task. It becomes one more thing you have to do which shifts your focus and as such, it’s a nuisance… especially if you have to do it more than once.

If you put the extra data on a separate page then the user still has to click a link or button to get to it. So what can we do? Unfortunately, not much. The best you can do is put the most important and frequently used data at the top of the page to minimize the probability that the user will have to scroll down.

Most of all, you should watch the header you put at the top of the page. My bank loves to have their logo and other worthless stuff take up half the page, which means every time I check my balance or do a transfer, I need to scroll down. Think that doesn’t annoy the heck out of me?

Summary

If you have built a web site or two, and have done a good job of it, you may be saying everything here is important for regular web sites in addition to business pages. And you’re probably right. Maybe the real difference is that a pleasant appearance can encourage users to gloss over data-oriented problems on a web site, but on a business page, everything is right out there in front of you and you have to get it right.

Image via Fotolia

PHP and the i

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

No Reader comments