Discussion of User Interface Requirements

Introduction

This document is intended as a discussion document of the requirements for a user interface in a business environment within Openbravo ERP.

You are encouraged to add comments and content to the document. However please do not delete content just because you do not agree with it.

The current (2.35MP1) Openbravo user interface is attractive, colourful and logical. However when used for long periods it can be cumbersome and tiring. This document aims to discuss possible improvements in efficiency to reduce operator fatigue.

Some General principles

The Interface should aim to:

• Aid the operator
• Be efficient
  • Presenting the data the operator needs to complete their work
  • Provide buttons to aid the flow of work
  • Reduce switching from keyboard to mouse if possible
• Intuitive
  • An indication as to what to do next should be on the screen

Discussion

Aiding the operator

The interface can aid the operator by responding with data that the operator is most likely to need.

Blank forms are not helpful

The interface should not present a blank form or a form with no data when data exists.

• An example of this in Openbravo (2.35MP1) is as follows:
• Click on the menu list: Sales Management/Sales Order
• click New
• Click the Business Partner field icon, leaving the field blank

This produces, in effect, a blank form.

Since the operator did not fill in any name or part name in the field, they probably have no idea what partners there are existing on the system.

Therefore the most sensible data to present them with is the full list of relevant partners.

The most relevant partners in this case would be a list of customers, which is what will happen if they click search without entering any selection data.

This saves one more operation, bearing in mind that for every request there is a pause while the system responds. It also provides a more positive response.

If the list is very long the system does not need to display more than a screenful. Faced with a long list the operator can use the search criteria at the top of the search window to narrow down the list.

Remember the Operators preferences

If the operator changes the width of the columns in a list, they do not want to do change the widths again the next time they display the same list. If the operator needs to see several columns of information before deciding which list item to choose, having the columns reset to some pre-ordained width every time the list is displayed is extremely frustrating.

The complexities of saving the settings for every list on the system for every operator are appreciated. Until that can be achieved a useful compromise is to adjust the column width to the width of the heading. By judicious use of heading length quite pleasing results can be achieved. For example a document number is usually fairly short compared with a text field. Giving it the heading "Document Number" will result in the column being too wide. Using a heading "Doc No." will give a more realistic width.

Help the Operator remember

When presenting lists, it is essential to provide headings for each column of data. If the list is longer than the screen and scrolling is required, the headings must be visible during scrolling.

Currently Openbravo (2.35MP1) does this in some places only.

For example:

Master Data Management || Product || Product grid view maintains the headings when scrolling.

Keep it on the island

"Keep it on the island" was a frequent cheer at football match when the ball kept going into touch.

In the user interface context this refers to the design size of the screen

The current version of Openbravo (2.35MP1) does not begin to fit on a 1024 x 768 screen. It appears to be designed for a 1280 x 1024 screen resolution and the current version does not always fit on that. The result is that a horizontal scroll is introduced by the browser, which wastes valuable screen real estate. In addition to this Openbravo's response to saving a record is to display a huge green or red box at the top of the window and this displaces the window contents down by 2cm resulting in a vertical scroll.

An example of a screen that does not fit horizontally at 1280x1024 is:

Master Data Management || Business Partner Setup || Business Partner Category  || Business Partner Category - grid view

Status results should be displayed in fixed area of the screen so that their display does not affect the existing display. There is plenty of room for this in the current design to the right of the record control arrows.

A screen resolution of 1024 x 768 is fairly common now without resorting to buying new equipment. Therefore designing the system around a screen size of 1024 x 768 would be preferable. Using a design size of 1280 x 1024 is going to require the purchase of 19 inch or 20 inch screens in order to cater for average eyesight. Not all operators have 20/20 vision.

Design for overflow

Some forms have a large number of tabs and the surplus tabs are displayed underneath. This results in white text on light grey background which is not very readable. An example of this is:

Master Data Management || Business Partner  ||  Business Partner  >>  Customer

Volume Discount is barely readable. While closing the menu window fixes the problem, the operator does not necessarily want to keep doing that.

Providing an efficient interface

Provide general case data by default

When the operator requests to search for an item for a list, provide the list of all items that qualify in the circumstances. For example clicking the icon to the right of the partner field on the Sales Order window currently serves up a blank screen. In this circumstance the search screen should display with a list of customers that match whatever was typed in the field. If the field is blank all customers should be listed.

Place the cursor in the first mandatory field

It is very tiring to have to always position the cursor at the start of a form. It is usually very obvious where the cursor needs to be viz. the first mandatory field on the form. The operator can then move around the form using the tab key. Every time the operator has to switch from the keyboard to the mouse it breaks the momentum or rhythm of work.

If you need to know how to do this, you are recommended to look at any of google's web pages, which always have the cursor in the first field.

There is also a tech web page:

http://www.itechies.net/dev/details_faq-sbres_id-222.htm

Which says:

How do I position the cursor on the first field of the first form when a page loads?

Description Using a named form and a named form field:

<body onLoad="document.myForm.myField.focus()">
<form name="myForm">
<input type="text" name="myField">
</form>

When the form and field names are not known then:

<body onLoad="document.forms[0].elements[0].focus()">
<form>
<input type="text">
</form>

Ask useful questions of the operator

This may appear a strange item at first, but all will be clear with an example.

The operator changes a value on a window and then needs to move to another screen to add further data. The system currently asks "There are changes in the current record. Do you want to continue?(You will loose your changes)" "OK" or "Cancel".

The system is really saying "If you want to keep this data, you must cancel and go back to the screen you are leaving and save the data and then re-request the move than you requested before" That is making the operator pander to the computer. An efficient interface panders to the operator. In this scenario what the system should be saying is "Do you want to save the current screen before moving on or drop the changes. The operator has already made the decision to move to another screen so it really is just a matter of whether to save the data or not.

Give meaningful error messages

Most operators can rectify simple errors if they understand what the error is. For example a message "Invalid OID" is meaningless to the operator. "Unable to link to document xxx" would be more useful.

It is probably a good idea to differentiate between internal system errors, which by their nature can be cryptic to everyone except the designer, and normal usage errors. It would also be useful if all error messages are numbered so that operators could report that they had a error "OB1234" on form "Sales Order".

There should also be a database of the locations in the code where each error number can originate. This would speed diagnosis quite a lot.

Making the interface Intuitive

This is often thought to be an unachievable "Holy Grail", but it is easier to achieve that most designers think since the industry now has 10 plus years of experience on web site design. There is an excellent book entitled "Don't make me think" by Steve Krug ISBN-10: 0321344758 which is essential reading for anyone designing web applications.

In the context of Openbravo here are some thoughts:

• Only display the action buttons that are relevant to the document's current status

Showing a button "Create Invoice" when the current document is still draft is probably not appropriate.

• Give the operator feedback

Change the appearance of buttons to indicate that they have been pressed and processing is progressing.

Summary pages

Operators often need a summary page to give them an overall picture of their work. Such a list should list the important details to identify the item (customer, product, partner etc) plus any relevant processing flags that indicate the progress or status of the item.

Then in the footer of the window there are processing buttons arranged for batch processing items at various stages of processing. These buttons should be arranged from left to right in order of process.

Each item should be clickable to obtain further detail in a separate window so that the operator does not loose the context of the main summary window. Especially the operators cursor/record position in the list.

Use of colour

Openbravo already has a colourful and pleasing design. However colour can often be used to great effect to give additional information without using more screen real estate.

This is best illustrated with a screenshot. This is not an Openbravo screenshot, but illustrates the point very well.

Note that this example screen fits on an 800x600 screen

In this example the post code is blurred to protect the privacy of the people named in the list.

In the name column the heading indicates what colours or backgrounds give certain information. So in this example customer name in red indicate a "Sold&Hold" status when there was no additional space in the window to indicate this extra information. Operator catch on to this very quickly with almost no training.

Note that this screen gives the operator the essential information they need at summary level viz.

• What - Document Number
• Who - Customer Name
• Where - Location for delivery
• When - Date of delivery
• Status information

The header and footer remain on screen when the list is scrolled.

The footer leads the operator through the stages required to achieve a smooth and consistent delivery service. The red buttons are red to indicate that they change the status of qualifying items in the list. The green buttons are green because they provide information usually a report that is repeatable without consequence. Again the operators learn very quickly that they need to pause for thought before pressing a button with red text.

Another feature of this type of summary list is that data items on the list can be changed by the operator to indicate a change of status in out of the ordinary circumstances.

O.K. this example isn't as pretty as Openbravo, but it does have some very useful features that I am sure Openbravo could benefit from.

Designer guidance Summary

When designing a new interface

Identify the operator's goals. Try to reduce the operator's work load by making the interface as simple and efficient to use as possible for the most common goals.

When testing the interface

Use real data and actually use the interface to enter data for at least an hour. If you find the interface tiresome to use, it needs more work.

Let the end users test the interface

Let the end users test the interface. If they have knowledge of the business domain they should be able to use it even without documentation. Observe what the end users did and make modifications based on the observations and feedback.