High quality labeling within your EASAP will go a long way towards allowing your users to understand its usage and to learn to use it quickly.

A little extra typing spent by you during the production of an EASAP may save much more of your time later responding to users’ questions. A few extra words used in your labels can make the difference in whether a label’s meaning is properly understood by a user. The figure below shows an example of labeling that might be considered too terse or vague by users:

The figure below provides an example of a clearer, more detailed set of labels.

A good habit to develop is the use of consistent labeling. A few areas of concern in creating consistent labels are as follows:

• Vocabulary
• Capitalization
• Structure

Consistent vocabulary in labels revolves around your choice of words. To be consistent, you should avoid two things:

1. Avoid using different words for the same action or thing. If you use different words for the same action or thing, users may mistakenly assume that the actions or things will be different.
   
   
2. Avoid using the same word for actions or things that are really different. This suggestion avoids the opposite problem to number 1, that is users will assume sameness when in reality actions or things will be different.

The idea with consistent capitalization is not to vary your approach for labels of the same type. For example, if you capitalize all words for the tab label of one tabbed pane, you should do the same for all your tabbed panes. Likewise, be consistent for SUB PANE's and data entry boxes.

Consistent structure of labels involves the consistent use and ordering of nouns and verbs. To illustrate this concept, let’s look at the following example showing first an inconsistent approach and then a more consistent approach.

Dimensions

Specify Flow Conditions

Report Formatting

Specify Dimensions

Specify Flow Conditions

Format Report

Note that the consistent set of labels all have the structure of Verb + Object. Another option would be to assume that the verb would be implied and therefore could be removed from the labels resulting in:

Dimensions

Flow Conditions

Report

Either option may work fine. The point is to pick one and use it consistently.

One of the most important ways that you can meet the needs of your users is to speak to them in their own language. In fact, discussing labels with potential users and letting them help you determine their wording may prove very beneficial.

In general, use of terminology specific to the underlying software applications should be avoided in EASAP labels, unless the users of the EASAP will already be very familiar with this terminology. The problem is that this terminology will present something new for the users to learn, and often this is unnecessary. Some examples of terminology to avoid are:

• “solver type”, “number of mesh elements”, “mesh element type”, “convergence criteria”, “discretization scheme”, “time step”, etc.

In most cases, the terminology given above can be avoided by you making decisions on behalf of users for these types of settings and not giving them the opportunity to provide these inputs.

If you must get software application specific information from users, the goal is to translate its terminology into more common terms. You should work out the fundamental reason for the input being labeled and reword the label in those terms.

Note: It may not be enough to just modify the label of an input. You may also need to change the form of the input and then manipulate it back into the appropriate form (see Manipulating User Inputs).