 Users must not be able to type
over or change display-only data. |
+Display data in common units according
to cultural standards. For instance, miles
per hour is the accepted unit for speed
in the US, however most of the rest of the
world uses kilometers per hour. Make units
consistent across the entire application.
+The displayed data should be directly
usable. For example, do not display a field
in feet when the user needs yards or meters.
If more than one unit is used, display data
in all used units (see Section 2..3.1.1).
+Labels and data should be in words
familiar to users.
 Maintain consistent formats across displays.
Use consistent wording and grammatical structure
for data and labels both within and across
displays. Titles and headings should not
change across multi-page displays of the
same table or form.
Ensure that field labels are consistent in word
choice, format, and style with the presented
information. For instance, if the label
for a field is "Last Name, First Name:"
the data displayed in the associated field
should be presented "Smith, William" not
"William Smith."
Display only data relevant to the user's task.
Do not place extraneous data on the display.
Locate the most frequently requested information
early in the display sequence.
Each display should provide sufficient context
to interpret the display. Practically, this
means that certain information must be repeated
to help the user maintain his orientation.
| One measure of visual clutter is screen
density. Screen density is determined
by the percentage of character positions
on the screen containing data. Typically,
screen density measures are used for
character-cell terminals. The concept
can be extended to the GUI environment
by assuming that a "screen" is a "window,"
and density is measured by the percentage
of pixels filled instead of percentage
of character positions filled. While
screen density is a crude way to evaluate
visual clutter it is a useful rule of
thumb. |
+Density levels should usually be
no higher than 40% (Tullis, 1988).
Items and groups of items should be perceptually
distinct. For example, distinct elements
should not touch each other. A button's
label should not touch the button's border.
Explanations of good practices in design
can be found in Section 4.4 of this document.
Organize the data in the client area into
semantically related groups. Some common
grouping techniques, see data groupings
are:
- Sequence of use
- Function
- Importance
- Frequency
- Chronological
- Alphabetical
+"Sequence of use" is the most important
grouping technique. Format displays alphabetically
only for large sets of data (i.e., more
than 20 items) or as a last resort.
+An optimal size for data groups
(not continuous text) is about five degrees
of the user's visual angle. Five degrees
of visual angle corresponds roughly to 7
lines high, and 14 characters wide (assuming
a 10 point constant-width font such as Courier).
Note: Obviously, it is unreasonable
to assume that all data groups could or
should meet such a constraint. However,
when design permits flexibility, this recommendation
should be taken seriously.
+Use data organizations and formats
that users are familiar with. For example,
the sequence name, address and phone number
is more familiar to users than address,
phone number, and name.
+Use of abbreviations in labels
is not recommended. Exception:
Abbreviations are acceptable if they will
be understood by all users and/or there
are serious space constraints.
+When abbreviations must be used:
- Ensure that all abbreviations are unique
and understood by all users;
- Choose common (familiar) abbreviations,
but
- If no abbreviation set exists, design
the abbreviation set according to a consistent
rule. Vowel deletion (e.g., POLICY becomes
PLCY) is usually the best choice for headings
and labels. User testing of all the new
abbreviations is strongly recommended
before they are included in the application.
Truncation (e.g., POLICY becomes POL)
is usually best for when users have to
type in entries.
| Do not punctuate abbreviations. Exception:
Punctuation is acceptable for the sake
of clarity. |
+If abbreviations are used, you
should provide the user with an electronic
listing of all the abbreviations in use,
perhaps through the help facility or on
a floating palette.
2.1.2.1. Purpose And Use
| Highlighting makes critical
or important information perceptually
salient to the user. There are a number
of ways to highlight information, for
example using color, shape, or text
attributes. As important as how
to highlight something is when
to highlight something. |
+Use highlighting when:
- focusing users' attention on unusual
data values
- specifying information that needs to
be changed
- calling attention to high priority fields
or messages
- indicating next data or command entry
areas
| Coding refers to the differentiation
of levels of a variable or properties
of data so that the user can make decisions
based upon the coding. For example,
in a list box unavailable items should
be grayed out or italicized and available
items should be in the regular system
font. |
1.2.2. Recommendations
+No more than 10% of the display
should be highlighted at any one time.
+Provide users with a legend explaining
the highlighting and coding. A floating
palette is one way to provide such a legend.
Highlighting and coding are most effective when
used sparingly.
Table 2-1 presents a summary of the highlighting
and coding recommendations.
| Highlighting/Coding Technique |
Pro |
Con |
Use for |
Blinking
(Blink rate should be 2-3 hz, and
the "on" cycle should be at least
20%.) |
Excellent attention-getting capability |
Reduces readability
Distracting |
Highlighting situations requiring
urgent attention and a quick response.
Note: Be sure to turn off blinking
when user responds. Do not
blink the whole word or phrase on
and off. Instead blink the item in
by alternating normal and high brightness.
Or use an item (e.g., an asterisk)
that is not part of the critical item
and blink that item on and off. |
High brightness (i.e., boldface)
The brighter item should be at least
two times brighter than the normal
item. |
Good attention-getting capability
Least disturbing of all highlighting |
Can be difficult to discriminate
between brightness levels |
Highlighting errors or differing
screen components
Note: No more than two levels
of brightness should be used. |
| Reverse video |
Good attention-getting capability |
Can reduce legibility
Use sparingly |
Highlighting errors or important
screen objects |
| Color coding |
Good for showing relationships among
screen elements. Colors have stereotypical
meaning to users (see Section 3.3.1.) |
Can be difficult to discriminate
between colors (see Section 3.3.1) |
Coding data
Note: Limit the number of colors
to four or fewer.
Note: Because as many as 8%
of users may be color deficient, use
color coding redundantly with another
coding method, e.g., shape. |
| All upper case characters |
Salient in text display of mixed
or lower case fonts |
More difficult to read than mixed
case |
Displaying labels |
| Mixed upper and lower case characters |
Best for readability |
None |
Displaying headings and labels |
| Different fonts |
Unobtrusive |
Can be difficult for the user to
notice. Fonts have no stereotypical
meaning to users; all associations
have to be learned. |
Differentiating between application
displayed (i.e., unchangeable) text
and user-entered text and for coding
items in lists and tables
Note: Limit the number of different
fonts for coding to three. |
| Italics |
Unobtrusive |
Has marginal stereotypical meaning
to users (i.e., "this is special");
meaning has to be learned. |
Coding items in lists and tables |
| Underlining |
None |
Poor attention getting
Reduces readability |
Do not use |
| Double size characters (must be
at least 20% larger than next smallest
size) |
Good attention getting quality;
not visually disturbing |
Consume screen space |
Displaying titles and headings |
Table 2-1: Highlighting and
coding techniques.
| A label is a descriptive title,
phrase, or word, consistently placed
with a control or group of controls
that identifies those controls. |
| All controls must be labeled. Follow
guidelines in Section 4 and later in
this section when labeling. |
| All labels must be distinctive from
each other within and across windows.
For instance, "Number" must not mean
phone number on one display and social
security number on another. |
| Use the standard system fonts and sizes
for labeling all interface objects.
Most system fonts are sans serif fonts. |
+Use different font styles to differentiate
between text the application displays and
text the user controls. In general, serif
fonts are more readable than sans serif
fonts, and are thus recommended as user
fonts. Times, Roman, or New Century Schoolbook
fonts are recommended.
+In text boxes that require entries
of a specific length, use a constant width
font (e.g., Courier, Monaco, Geneva); make
the text box only accept entries of the
specific length. Note: This eliminates
errors by constraining user input to only
those entries that conform to the length
requirements.
+The minimum stroke width of a font
should be 2 pixels.
+Font sizes should never be less
than 10 point.
+Recommended character heights (as
measured from the top of an upper case "H"
to the bottom) as a function of viewing
distance (in inches) are as follows:
| Viewing Distance |
MAX |
Best |
MIN |
| 12 |
0.09 |
0.06 |
0.02 |
| 16 |
0.11 |
0.08 |
0.06 |
| 20 |
0.14 |
0.10 |
0.08 |
| 24 |
0.17 |
0.12 |
0.10 |
| 28 |
0.20 |
0.14 |
0.11 |
| 32 |
0.23 |
0.17 |
0.13 |
+Recommended character widths (as
measured from side to side of an upper case
"H") as a function of viewing distance (in
inches) are as follows (Since the width
of a font is proportional to the height
of the font increasing the font height automatically
makes the font wider. Thus, a font 9 pixels
high will have a width of 6 pixels; a font
8 pixels high will be 2 pixels wide.):
| Viewing Distance |
MAX |
Best |
MIN |
| 12 |
0.06 |
0.02 |
0.04 |
| 16 |
0.09 |
0.06 |
0.02 |
| 20 |
0.11 |
0.08 |
0.06 |
| 24 |
0.13 |
0.09 |
0.07 |
| 28 |
0.12 |
0.11 |
0.08 |
| 32 |
0.17 |
0.12 |
0.10 |
+The recommended space between letters
in a word is .004 inches (or roughly 2 pixels).
+The recommended space between lines
(i.e., the baseline of one font and the
top of the next line) is .020 inches (or
roughly 10 pixels).
More reading
+Users should be able to search
for specified strings in large bodies of
text or long lists. Expert users might wish
to search on special characters (e.g., carriage
returns) or formats (e.g., italicized text).
+When searching, upper and lower
case letters should be treated as equivalent
in search unless explicitly noted by the
user.
+Users should be able to globally
search and replace one string with another
without requiring confirmation for each
change. Also allow them to undo all
changes immediately following the replace.
+The case of the replace string
should be the same as the search string.
Tables are a critical means by which data
are presented to users. Figure 2-1 below
shows an example of a table.
Figure 2-1: Example of a
table.
2.2.1.1. Layout
2.2.1.1.1. General
+In tables that contain more than
seven rows, place a blank line or a subtle
underscore after every fifth row. Note:
This greatly improves readability by facilitating
horizontal scanning (see Figure 2-1).
+When the table has only limited
display space available, but there are many
columns that can possibly be displayed,
either
- establish multiple views of the data
and allow the user to select among them;
- give the user the capability to determine
the data columns that show up in the table;
or
- enable horizontal scrolling to display
other columns. In this case, fix the key
column (i.e., the leftmost column(s))
and scroll the other columns.
If two or more data items must be compared on
a character-by-character basis, place one
item directly above the other.
2.2.1.1.2. Labels
+For columnar data, place the label
flush left above the column (without a colon)
for alphanumeric data and flush right for
numeric data that are anchored on a decimal
point (see Section 4.3.1.2).
+When numbering rows or columns
or numbering items, start with the number
"1" not "0."
+Place units of measure (in parentheses)
directly below the label or, if space permits,
to the right of the label. For example,
2.2.1.1.3. Organization
+Display the reference (sometimes
called the "key" or the "index") column
as the leftmost column in the table. For
instance, if the table is organized alphabetically,
make the name column (sorted properly) the
leftmost column. Display the rest of the
columns from left to right according to
their significance to the task.
Construct the table so that it matches the organization
the user requires or expects (e.g., because
of a matching paper form).
If possible, do not separate columns that will
be frequently compared.
2.2.1.2. Spacing And Justification In
Tables
| Numeric columns of data that do not
contain decimal points must be right-justified;
numeric columns of data that contain
a decimal point must be justified with
respect to a fixed decimal point. Maintain
all significant zeros after a decimal
point. |
| Alphanumeric columns of data must be
left-justified; alphabetic data columns,
alphabetic must never be centered. |
+Use consistent spacing between
columns and groups of columns.
- Maintain at least three spaces between
the longest entry in one column and the
beginning of the next. Note: With
proportional fonts, a "space" is the equivalent
to the width of the letter "N."
- When the columns are grouped, place
at least five spaces between the groups.
Intergroup spacing be greater than intragroup
spacing by at least two spaces (Figure
2-2).
+Column spacing should be consistent
from one display to the next, when similar
data are being presented.
Figure 2-2: Table spacing
and justification.
2.2.1.3. Navigation
| If numbering of items in a list exceeds
the available display and the area is
paged or scrolled, items must be numbered
continuously from the first item in
the display. |
| Maintain column and row headings when
paging/scrolling through tables that
extend beyond the available display
area. |
+If users must compare items on
the display that cannot be viewed in the
same window at the same time, allow the
user to split the window into several panes.
2.2.1.4. Highlighting And Coding, Tables
Items In Tables
See Section 2.1.2.
+Provide distinctive coding to code
items requiring user attention. Color and
text attributes are effective when you need
to code items in tables. For instance, important
information might be presented in boldface
and unavailable information should be grayed
out or presented in italics.
Data records display (view only) sets of
labels and data fields, such as in Figure
2-3.
Figure 2-3: An example of
a data record.
2.2.2.1. General
| When the same display is used for requesting
data entry and for presenting a data
record, use the same labels and sequence
for each. |
+Make the layout of corresponding
data fields consistent across displays.
For example, do not present first name,
last name in one display, then last name,
first name in another display.
Often it is necessary to present long passages
of text to the user. Be aware that reading
times are significantly slower on a computer
display than with hard copy. Below are presented
some requirements and recommendations that
improve reading times for computer-displayed
text.
2.2.3.1. General
If users must read a substantial amount of text
on-line, provide the ability to print out
the specific page as well as the option
of printing the whole document.
2.2.3.2. Layout
| Do not justify the right margin of computer-displayed
text. |
| Separate all paragraphs with one blank
line. |
| Use mixed upper and lower case. Do not
use all upper case. |
+When presenting several paragraphs
of text, make the display size of a text
box between 4 and 17 lines in height. Ideally,
use line spacings of 1.2 or 2 for text;
avoid single spacing for long text passages.
+For optimum reading speed, make
line lengths between 20 and 78 characters.
Continuous text should be displayed in no
fewer than 20 characters per line. It
is better to display a few long lines of
text than several short lines. (In general,
avoid using double columns of text on a
computer display.)
+Use headings and formatting to
set off important sections of text.
2.2.3.3. Wording And Style
| Do not hyphenate text. |
+Use normal punctuation.
+Avoid the use of contractions.
For instance, use "will not" rather than
"won't."
+Use short, simple affirmative sentences.
+Use the active voice. It is much
easier to read text written in the active
voice than the passive voice.
| When the text describes a sequence,
the word order of the text must reflect
the sequence of the task. For instance,
"Enter Password before running applications"
is better phrasing than "Before running
applications, enter Password." |
+When a critical passage or word
must be emphasized, highlight it by using
one of the conventions (e.g., boldface)
presented in Section 2.1.2.
+Use headings to introduce and set
readers' expectations for the text that
follows the heading.
Put the topic sentence of each paragraph at
the beginning of the paragraph.
2.2.3.4. Text Lists
+Display related items in a rather
than in continuous text. For example, the
following columnar representation:
Illinois
Indiana
Michigan
Ohio
Wisconsin |
is easier to read than the paragraph representation:
"States: Illinois, Indiana, Michigan, Ohio,
and Wisconsin."
+Generally, as long as scrolling
is not required by the user, presenting
a text list in a single column is better
than multiple columns. For instance, it
would be better to present a long list of
20 items than a two column list of 10 items
each. But, not all lists can be presented
in a single column.
+When presenting a in more than
one column, order the items vertically within
each column. For instance, use this ordering:
rather than this ordering
(the tab order should follow the item ordering).
Adopt the user's logic when ordering the . If
there are a lot of items to be ordered or
if no other principle applies, order the
list alphabetically.
2.2.4.1. Purpose And Use
| Flowcharts are diagrams that
illustrate sequential relations among
elements or events. |
Use flowcharts for schematic representation
of sequence information.
2.2.4.2. General
+Flowcharts should be presented
in a logical order; that order will be (almost
always) the sequence of steps required to
perform some task.
+In general, it is best to conform
to established conventions for presentation
of individual elements. For instance, if
you are presenting a data flowchart use
conventional shapes for elements as defined
by national standards organizations.
| When the user selects a displayed object
to perform an action, highlight the
item. In PICT-based graphics programs
this is done by placing "handles" around
the object. You might also highlight
the object by using reverse video. |
+Users should be able to get detailed
information about a particular flowchart
object by picking the object and selecting
a "more information" option on a menu, or
perhaps just double-clicking on the object.
This information should contain an explanation
of what the object is, what it does and
how it is used, as well as context-sensitive
information.
2.2.4.3. Layout
+Lay out the flowchart so that it
can be read from top to bottom and left
to right.
+If at all possible, adopt the convention
that "yes" always leaves from the right
side of the box and "no" always leaves from
the left side or bottom of the box.
+Only place one decision at each
step. Do not combine multiple decisions
into one decision box.
+Use coding in flowcharts with a
purpose, such as to distinguish different
types of elements or elements out of normative
range. For example, color might be used
to demonstrate particular paths in the flowchart.
Color is a good method of coding in flowcharts,
but be careful not to use more than five
levels of color coding. Because of the need
for redundancy when using color coding,
you should also alter the line/border width
or use dashed rather than a solid lines.
| User guidance is on-demand
information, such as "help," or system
capabilities that aid the user's interaction
with the application. |
User guidance can be implicit or explicit.
| Implicit guidance is integrated
into the interface through well- designed
menus, thoughtfully constructed client
areas, and properties of screen objects.
Much of this document is geared toward
improving implicit user guidance. |
| Explicit guidance is available
on request, explains the current object
or command, and provides application
information. |
Explicit guidance is the subject of this
section.
| Allow the user to get help at any time,
through either Help menus or help buttons. |
+Provide specific information relative
to the task context rather than generic
messages. For example, if the user entered
information in the wrong format say "Format
is MM/DD/YY" not "Invalid format."
+State the consequences of an action
before describing the action. For instance,
say "To delete file, press Return" instead
of "Press Return to delete file."
+If a task has sequential steps,
present the task in the order required to
perform the task.
2.3.1.1. Style And Grammar
User guidance that requires the presentation
of large amounts of text should follow the
guidelines in Section 2.2.3.
| Do not use anthropomorphisms;
that is, do not personify the computer.
For example, instead of "I will continue
when you press Return" say "To continue,
press Return." |
+Words used in user guidance should
be common, meaningful, unambiguous, and
complete (i.e., no contractions or abbreviations).
Avoid computer terminology, unfamiliar,
or esoteric terms.
+In general, use positively rather
than negatively worded statements; negative
statements, however, are appropriate for
conveying exceptions to rules.
+Use the active, rather than the
passive, voice; use consistent grammatical
construction; state messages in short, simple
sentences.
+Points (or facts) that must be
remembered should be at the beginning of
the message.
+Place a period at the end of each
sentence.
Use drawings or pictures to illustrate text
whenever possible.
2.3.2.1. Preventing User Errors
A well-designed application minimizes the
number and severity of errors. The closer
the application matches the user's task,
the more likely that errors will be prevented.
The use of interface objects like radio
buttons, check boxes, and pop-up menus serve
to prevent errors, because the application
relies on the user to make a choice from
pre-defined sets.
| Require users to take some explicit
action to enter information (e.g., on
data forms with more than one required
text box the user should have to press
an OK or other affirmative
button to complete the dialog.) |
| If the user takes some action that will
cause the loss of contents of a current
work display, prompt the user as to
whether to save the current information,
cancel the requested action or proceed
without saving. (See Section 3.4.3 for
common dialog boxes.) |
Make the application tolerant of common, predictable
misspellings and typographical errors. For
instance, if the user types Chicsgo, the
application should suggest choices to the
user as to the correct or intended entries
without the user having to re-key the entry.
2.3.2.2. Detecting And Correcting Incorrect
Entries
| Errors include malfunctions
to hardware or software and user inputs
that are not recognized by the application. |
| Error detection is the application's
edit checking capability; it tells the
user that an error has been found and
the conditions that caused the error
and effects of the error, if possible. |
| Error correction is the application
providing information on the cause of
the error and recovery procedures. For
instance, the application may require
the user to re-enter the name of a file
if the application cannot find a file
by the user-supplied name. |
| When an error is detected and requires
the user to change information, all
previous information that was correct
must remain intact. In other words,
the user must never be forced to re-enter
previously correct information. |
| If a user's action may have unintentional
or destructive consequences, such as
loss of data, present the user with
a warning or confirmation message making
the user confirm or cancel the action
before executing the command. |
+Detect errors immediately after
an explicit OK, Send or other appropriate
action is taken by the user to dismiss the
error dialog box.
+When the application detects an
error present an error dialog box describing
the error; post the dialog box, if at all
possible, in such a way that it does not
obscure the item(s) that caused the error.
When the user confirms that he has read
the message (by pressing OK), the
dialog box disappears and the application
highlights the offending field(s) and the
cursor is placed in the left-most and top-most
field.
This section addresses the variety of messages,
status information, and user queries.
2.3.3.1. Error Messages
| Allow the user to access help directly
from an error message. |
| The documentation must include a listing
and description of all error messages. |
+Make error messages:
- Brief, but informative.
- Convey what is wrong, where the error
is, and what corrective actions can be
taken.
- Provide information specific to the
task rather than generic (e.g., "Invalid
data" is a non-specific, unhelpful error
message).
- Non-judgmental; do not accuse or patronize
the user; do not personify the computer
or attempt humor.
- Go away as soon as the error is corrected
or the user dismisses the error dialog
box.
+When successive user actions result
in the repetition of the same error message,
re-phrase the error message for the third
and all subsequent times. Additionally,
for the third repetition of the error message,
the application should beep twice before
presenting the error message.
+If the set of valid inputs is small,
present the set of alternatives with the
error message.
+When the error involves a logical
unit of input (e.g., a text in a text box),
the offending entry should be highlighted
when the dialog box is removed.
+If there are multiple errors, tell
the user there are multiple errors. All
fields containing errors should be simultaneously
identified to the user.
2.3.3.2. Information Area
| The information area is a read-only,
non-scrolling display located at the
bottom left of a primary window where
non-essential, informative messages
appear (before the user actually
selects the object or action) about
an object or a selection. For example
in Microsoft Excel, if the user posts
the "File" menu and passes the pointer
over (but does not select) "Open" the
information area presents "Open saved
document." |
+Most primary windows should have
an information area.
| Use the information area for information
that the user is not required
to see. It should not be used for critical
information -- use a dialog box instead. |
+When the cursor is on a command
(a menu item or button), use the information
area to present the results of the user
action if the command is selected.
+When the cursor is on an object,
use the information area to suggest the
default action, the most appropriate action,
or how to perform available actions.
+When the cursor is on a list box,
use the information area to tell the user
how many items they can select, e.g., "Select
one item" or "Select as many as apply."
+Pass messages to the user about
the normal completion of an action in the
information area (e.g., file was
successfully saved).
+Allow the user to turn the information
area on and off through a menu choice (e.g.,
under the "Windows" menu; see Section 3.4.2).
+Remove the message from the information
area when it is no longer relevant.
More reading
- IBM SAA CUA AIDR, p. 119-120.
On-line help provides directions,
explanations, and information to the
user:
- directions for: executing a command,
accessing and using an application's
capability, accomplishing a specific
goal, and handling error conditions.
- explanations of concepts associated
with a task or interface components,
and commands or dialog components
and the actions they perform.
- information on the syntax required
to do a task, a listing of available
commands or options, and a statement
of valid ranges for a field.
|
Users access help by simple consistent
actions: in Apple by pressing the HELP
key or COMMAND-?; in Windows by pressing
the F1 key or the SHIFT+F1
keys; and in Motif by pressing the F1
key.
In general, users will come to help in
one of two instances. First, users will
request help when they have a specific problem
and want a specific context-sensitive answer.
Alternatively, many users consider help
a safe and efficient means of learning the
application. Thus, users will browse help,
just to get a feel for the application,
with no specific goals or problems in mind.
The primary purpose of on-line help, however,
is to provide context- sensitive solutions
to user problems.
Context-sensitive help is information
based on the location of the pointing
cursor on the screen, the active application,
the current step in a dialog, most recent
error message, etc. Context-sensitive
help, context- sensitive is applicable
when:
- Users need to request help that
is specific to a current task or
object.
- The task has sequential steps.
|
Facilitating browsing help
is done by presenting the user with
a help index; the user enters a help
topic or picks from a list of available
topics. Browsing help, browsing is applicable
when:
- There is no context available
for context sensitive help for a
selected object.
- Users may have trouble accurately
specifying the help topic without
assistance.
|
| Users must be able to initiate a help
request whenever they want, get help
on any topic they desire, control the
type of help information, and exit help
at any time. |
+It is strongly recommended
that on-line help remain visible until the
user explicitly removes it.
2.3.4.1. Style
+Keep the writing simple, concrete,
and natural.
+Provide information that focuses
on the task -- include all needed information,
be sure all information is correct, and
exclude anything that is not needed. The
best way to ensure that help is helpful
is to review and test help with target users.
+Use a lot of white space. In general,
no more than 40% of the pixels should be
occupied by words and figures.
Anticipate the reasons for the confusion and
how the help text will address that confusion.
Write on-line help with the user community
and the specific application tasks in mind.
Users often access help because they are
unsure about something.
If the users can enter a term for which they
want help, the application should accept
(non- technical) synonyms and close spelling
matches.
2.3.4.2. Content
+The following headings and descriptions
are strongly recommended for field-level
help and window-level help:
- Purpose - Begin explaining the
purpose of the screen or field, and when
and how the information on this display
fits into the business purpose.
Follow this description with descriptive
and procedural information as required
by the task.
- Concept - Use the concept
heading only for complex or confusing
fields, such as "Internal wiring:"; it
does not seem likely that a concept statement
for "Street Address," for instance, would
be needed. For example, does the application
require information to be entered in a
particular order or is certain information
pre-populated and where does the application
get the information to populate the display?
- Syntax - Explain to the user
all the elements of the display in terms
of the computer objects (fields, lists,
etc.). Answer questions like: How do I
get out of this display?
Describe the syntax or the form of the
entry that is required in fields. Also
report on the edit checking that the application
does on this field. One reason users access
field-level help is because an edit check
has flagged the field. Help should tell
the user how to correctly enter information
so that the user is capable of entering
the information properly.
- Examples - Provide examples of
how commands or functions are used. Use
concrete examples to explain abstract
topics. Examples are one of the most important
parts of help.
- More Information - Provide cross
references to closely related topics that
can be accessed through on-line help.
Note: on-line help must sufficiently
explain the concepts because the manual
may not be available when the user requests
help.
- Notations - If at all possible,
provide an editable field with each help
topic for users to make annotations for
their own reference later on.
Feedback is the perceptible
response from the application that results
from user actions. Feedback indicates
the current state of system hardware
or software, such as available applications,
modes, processes, etc.
Examples:
- The tracking of the pointer when
the mouse is moved.
- "Shrinking" a document into an
icon when the user "Minimizes."
- Removing the drop-down menu when
the user selects a menu item.
|
< TR>
| Every user action should produce perceptible
feedback from the application. Most
interface objects have feedback built
into their usage. |
The application must provide feedback
(e.g., a message dialog box) must be
provided when:
- there is a 2 to 12 second delay
in processing a command entry --
change the cursor shape (see Section
3.2.1.).
- an operation will take 12 seconds
or longer -- provide a progress
indicator dialog box.
- the processing time delay is unknown
-- change the cursor shape (see
Section 3.2.1.).
- users have minimal training or
are infrequent users of the application
-- use the information area liberally.
|
| Show all characters (and control characters
that are ignored) that the user types
on the display, except for passwords
and for other security reasons. |
+It is strongly recommended that
the application anticipate system failures
and report them to users; therefore, provide
a dialog box telling the user of the impending
failure (e.g., "Running out of memory-Save
and close windows now").
+Following an application interrupt,
provide feedback assuring the user that
the application is still working and returned
to its previous state.
+Make system responses fast. Target
times are as follows:
- Movement between fields on the same
screen, less than 220 msec.
- Cursor tracking following mouse movement,
less than 20 msec.
- Keystrokes in a text box, less than
100 msec.
+Provide status and error information
on requests sent to a remote machine, e.g.,
printer or database retrieval.
Feedback should be non-intrusive and not detract
from the task. For instance, the pointer
change in text entry or periods of delay
are not intrusive and blend directly into
the task.
If possible, make feedback accommodate the skill
level of user. Novice users need more qualitative
feedback than experts.
Integrate feedback into how users work with
the task. For example, if the user is likely
to be looking away from the display, and
the application needs attention, the application
should beep
|
Output
elements