Help and User Support

Explaining Texts

Typically iViews should not have explaining texts on the screen. There may be exceptions, where special fields or status displays, alert or error indicators need explanation.

How to Make an iView Self-Explaining

iViews can be made self-explaining by using the following elements to include instructions or explanations:

iView title
group box headers
group headers
table or tree headers
charts or graphics, if used properly

Note: If these measures do not suffice, that is if your iView needs documentation, ask yourself whether it is really an iView! Either simplify your iView or make it an IAC.

Field Help

Currently there is no field help in iViews, although there is some delevopment on the way.

Value Help

Value help can also be provided by using dropdown listboxes instead of input/output fields, provided the number of possible values is small enough (typically less than 20 items).

Figure 1: Value help provided by a dropdown listbox

Error Handling

Beside help, error handling is an important aspect of user support. Error handling can help users to overcome problem situations and to continue their work.

Typically error handling is done by sending error messages that note the error, explain the reason for the error and - ideally - provide hints how to remedy the error situation.

Currently, there is no approved error handling strategy for iViews. See Messages for details.

Error Prevention Comes First!

However, before handling errors, you should first ask how errors can be prevented. See the paragraph below for a discussion of error prevention.

Error Prevention

iViews have little space for error messages, especially for messages that explain causes or provide hints for error recovery. This problem is counterbalanced by the fact that iViews typically have little functionality and that thus errors are less probable. This, however, is not a satisfying answer to the problem of error handling. Therefore, the route to go is: Design iViews so that errors cannot occur.

Preventing errors - instead of remedying them - has the following benefits:

Users cannot come into error situations - many users have problems with recovering from errors.
The users' work is not interrupted by error messages.
Users are not confused or puzzled by (often cryptic) error messages.
There is no need for a screen area that display errors.

Often it needs some rethinking and the giving up "old habits" to find design solutions that prevent errors instead of sending an error message after an error has occurred.

Do Not Let Users "Pay" for System Weaknesses

Many systems work the way that they need help from the users, not the other way round as it should be. For example, often users are required to enter data in a certain format, because the system otherwise cannot recognize the input as valid data. As a consequence, an error handling procedure is needed, because users make errors. Sometimes the system is even "nicer" to the users and also provides online instructions for them. So they can read how they should enter the data. Actually, even this does not help much - users still make errors and developers complain about their "stupid" users.

Actually, this way of thinking is on the wrong track! It is not the users who are the problem and who are too "stupid" to read the instructions and enter the data correctly - it is the system that requires users to act in a "system-friendly" way. If there would be - in our example - an "intelligent" input field that prevented users from entering invalid data, there would neither be a need for an onscreen instruction nor for an error handling procedure.

In the following we provide some ideas and examples that may stimulate your imagination when looking for ways how errors can be prevented.

Prevent Wrong or Invalid Inputs

Numeric fields: Prevent users from entering letters by parsing the input string.
Date and time fields: Provide "intelligent" date and time fields that are preformatted, or provide selection controls instead of input fields (dropdown lists, spin buttons, calendar controls).
Currency fields: Use preformatted fields.

Prevent Invalid Actions

Disable pushbuttons that cannot be used in the current context.
Do not offer functionality that is not needed.

Do Not Make the Interface Lie

Do not use screen elements where uses expect to use them in any order, if there are dependencies or if a certain sequence of steps has to be followed.
Example: Do not use tabstrips for views that depend on each other and cannot be viewed at random. At best, do not force users to perform steps in a fixed sequence.

Do Not Obscure the Screen and its Purpose

Often important information is hidden while unimportant information dominates the screen. In other cases users simply have no clue what a screen's purpose is. Thus, provide the necessary information and arrange it so that relevant things are recognized first - this way users realize what to do on a screen and how.

top