# Show The Format Required *

When attempting to enter data into an input field, the user needs to know the format that is required, but may have difficulty in understanding this if it is formally expressed, and will resent having to look this up in documentation.

The problem is really to make the format required appear obvious.  That is;

• the type of characters accepted (numeric, alphabetic, alphanumeric, case, etc.),
• the combinations allowed (e.g., first character must be alphabetic, followed by alphanumerics),
• the size of the field.

By example

This is an obvious solution if there is a default value that may be given.  The default value appearing in the field input space makes the sort of input required explicit, though it is important to indicate to the user that this is merely a suggested value, and that they can change it.  (This is explored in the pattern: GIVE A DEFAULT VALUE (#).)

Alternately, an example can be part of a prompt for the input field, (PROMPT FOR INPUT (#)).

GUI components such as; buttons, check boxes, radio buttons, list boxes and spin buttons, restrict the type and range of data that can be input.  There is an overhead for the user in learning how to manipulate these components, which must be considered, (GRAPHICAL USER INTERFACE (#)).

A number of possibilities exist here; the appearance of the input field (border, background colour, font size, dimensions) could be used consistently within an application to differentiate different input data types.

The length of the data item should be indicated by the size of the input field.  It is important that the input field must not be longer than the data item.  If the input field is shorter than the maximum length of the data item, then an indication of this should be given, and the field must scroll to allow entered text to be seen.  Making the field explicitly scrollable, by the addition of scrolling controls is one possibility.

The cursor shape could be changed consistently to indicate different data types (e.g., an I-beam for text, and a block for numerics).

Input fields for data items having a rigid and complex structure (e.g., manufacturers part numbers) should indicate the structure by divisions within the input field, or alternately, segmenting the data item between a number of fields.  E.g.,  Volkswagen part numbers have the structure (using a COBOL like notation):  X99999999AAXXX, where the first three character indicate the model type, the next three the location in the vehicle, the next three the part identification, the next two a supercession code, and the final three a colour code.  This would be an obvious candidate for segmentation into five input fields.

Visual prompting should be treated as redundant reinforcement of explicit format instructions available elsewhere.

This may be done in several ways;
 
• As part of a prompt (i.e., text displayed adjacent to an input field)
• In tips (i.e., short messages that appear when the cursor pauses over a control for a short period)
• On a message bar (i.e., a display field, typically at the bottom of a window, in which a sentence describing required input, error messages, etc., is shown).
• In help text (both on-line and in paper documentation).
Given that, typically, space for prompts is limited (and is often restricted to a field name), as both semantic and syntactic information must be given, and over time, the user may learn the syntactic details but will need the semantic information, semantic information should predominate in the prompt.

Tips could be used to give syntactic information.

As message bars and help texts have increasingly less restrictions on size, they can contain fuller explanations of both semantic and syntactic information.

Give the user details of the format required of input data both explicitly as examples and textual explanation, and implicitly through the appearance and behaviour of an input field.

To support disabled users, alternative modes of signalling this information should be dynamically available — THE MODEL-VIEW-CONTROLLER ARCHITECTURE (#).  This pattern should be implemented in conjunction with PROMPT FOR INPUT (#)  . . . .