InfoMagic Standards 1993 July/Disc.iso/ccitt/1988/troff/10_7_02.tro

Text File | 1991-12-12 | 90.8 KB | 4,145 lines

.rs
.\" Troff code generated by TPS Convert from ITU Original Files
.\"                 Not Copyright ( c) 1991
.\"
.\" Assumes tbl, eqn, MS macros, and lots of luck.
.TA 1c 2c 3c 4c 5c 6c 7c 8c
.ds CH
.ds CF
.EQ
delim @@
.EN
.nr LL 40.5P
.nr ll 40.5P
.nr HM 3P
.nr FM 6P
.nr PO 4P
.nr PD 9p
.po 4P

.rs
\v | 5i'
.sp 1P
.ce 1000
\v'3P'
SECTION\ 3
.ce 0
.sp 1P
.ce 1000
\fBEXTENDED\ MML\ FOR\ VISUAL\ DISPLAY\ TERMINALS\fR
.ce 0
.sp 1P
.sp 2P
.LP
\fBRecommendation\ Z.321\fR
.RT
.sp 2P
.ce 1000
\fBINTRODUCTION\ TO\ THE\ EXTENDED\ MML\fR
.EF '%    Fascicle\ X.7\ \(em\ Rec.\ Z.321''
.OF '''Fascicle\ X.7\ \(em\ Rec.\ Z.321    %'
.ce 0
.sp 1P
.ce 1000
\fBFOR\fR  |
\fBVISUAL\ DISPLAY\ TERMINALS\fR
.ce 0
.sp 1P
.LP
\fB1\fR     \fBScope of the Section\fR
.sp 1P
.RT
.PP
This Section deals with man\(hymachine interfaces that take advantage of
the input and output facilities usually available on visual display
terminals (VDTs). The procedures described are not necessarily confined
to this type of terminal; they can also be applied to printer\(hyoriented
terminals, such as teletypewriters, within the limits imposed by the facilities
available at
those terminals, e.g., information entry through menu selection.
.PP
By maintaining consistency with Recommendations\ Z.311\(hyZ.317,
these Recommendations facilitate a transition from a man\(hymachine interface
using basic syntax and dialogue procedures as described in Section\ 1 to one
based on VDTs.
.PP
Diagrams and examples are used to clarify and illustrate the concepts explained
in the text. The diagrams do not include exceptional cases and do not specify
all possibilities available with the extended MML; those not shown
diagrammatically, but which are allowed in the text, are subjects for further
study and are not excluded from the extended MML. Similarly, the examples
shown are not intended to imply a particular system implementation.
.PP
The Recommendations cover aspects of VDTs that users see and use,
e.g.,\ data entry, data display, interactive control, user guidance,\ etc.
Specific terminal characteristics are avoided wherever possible.
.RT
.LP
.sp 2P
.LP
\fB2\fR     \fBOrganization of Section 3\fR
.sp 1P
.RT
.PP
Section 3 consists of the following Recommendations:
.RT
.LP
    Z.321
    Introduction to the extended MML for visual display
terminals
.LP
    Z.322
    Capabilities of visual display terminals
.LP
    Z.323
    Man\(hymachine interaction
.PP
\fIRecommendation Z.322\fR  | escribes many of the capabilities
currently available in VDTs. \fIRecommendation\ Z.323\fR focusses on actual
man\(hymachine interactions (i.e.,\ \fIhow\fR the capabilities are used)
by addressing various aspects such as dialogue elements, monologue outputs,
user assistance and interactive control.
.sp 2P
.LP
\fB3\fR     \fBHuman factors\fR
.sp 1P
.RT
.sp 1P
.LP
3.1
    \fIThe \fR \fIhuman factor view\fR \fI of the man\(hymachine interface\fR
.sp 9p
.RT
.PP
Human factor science characterizes the man\(hymachine interface as any
part of a system that the user comes in contact with \(em either physically,
perceptually or conceptually. The user's conceptual model of a system is the
knowledge that organizes how the system works and how it can be used to
accomplish tasks. The conceptual model forms an integral part of the user
interface.
.bp
.RT
.LP
.sp 1P
.LP
3.2
    \fIThe need for human factors considerations\fR
.sp 9p
.RT
.PP
The aim of human factors is to satisfy the largest possible
proportion of potential users rather than to tailor the system to one user,
particularly one with a detailed and sophisticated knowledge of the system.
Therefore a proper man\(hymachine interface takes account of the user's
needs as well as system requirements. Poor quality will show up as a high
proportion of input errors, loss of user confidence and motivation and
high training costs. A high quality man\(hymachine interface is based on
a truly representative user
model.
.PP
Recognized human factors literature has been used in the formulation of
Recommendations\ Z.322 and\ Z.323. Where appropriate, human factor aspects
have been incorporated into the texts.
.RT
.sp 2P
.LP
\fBRecommendation\ Z.322\fR
.RT
.sp 2P
.sp 1P
.ce 1000
\fBCAPABILITIES\ OF\ VISUAL\ DISPLAY\ TERMINALS\fR
.EF '%    Fascicle\ X.7\ \(em\ Rec.\ Z.322''
.OF '''Fascicle\ X.7\ \(em\ Rec.\ Z.322    %'
.ce 0
.sp 1P
.LP
\fB1\fR     \fBIntroduction\fR
.sp 1P
.RT
.PP
This Recommendation describes some of the capabilities which are
important to the user and which are commonly available on interfaces based
on VDTs. It is not an exhaustive list of capabilities. The use of additional
capabilities, not covered in these Recommendations, is not precluded. Not
all of the capabilities described need be present on a given system. Graphics
capabilities are for future study and are therefore not considered in detail
in these Recommendations.
.PP
System implementation of these capabilities may vary, depending for
example on the degree of intelligence in the terminal itself and the allocation
of responsibility for the man\(hymachine interface among system components.
.PP
Items covered are treated from the point of view of the importance
of their characteristics for designing the man\(hymachine interface.
Human factors are dealt with individually for each item.
.RT
.sp 2P
.LP
\fB2\fR     \fBScreen\fR
.sp 1P
.RT
.sp 1P
.LP
2.1
    \fICharacter definition\fR
.sp 9p
.RT
.PP
For further study.
.RT
.sp 1P
.LP
2.2
    \fICursor\fR
.sp 9p
.RT
.PP
The cursor is important in the operation of a VDT
because it directs the user's attention to that position on the screen
appropriate to the task at hand, e.g., where the next character will appear.
The cursor also allows the user to specify the location on the
screen where an entry or change is desired by the user.
.PP
A set of general cursor qualities include:
.RT
.LP
    \(em
    easily found by the user at any position in the display;
.LP
    \(em
    easily tracked as it is moved through the display;
.LP
    \(em
    does not interfere with the reading of the symbol that it
marks;
.LP
    \(em
    should not be so distracting as to impair the search for
unrelated information displayed elsewhere on the screen;
.LP
    \(em
    should be of a form that is unique and reserved for that
purpose only;
.LP
    \(em
    should be stable in respect to the position to which
it is addressed until it is readdressed elsewhere as a result of user
or system action.
.sp 1P
.LP
2.3
    \fIScreen partitioning definition\fR
.sp 9p
.RT
.PP
The following definitions describe the physical partitioning of the VDT screen.
.RT
.sp 1P
.LP
2.3.1
    \fIVisible display\fR
.sp 9p
.RT
.PP
The visible display is the entire physical screen of a VDT
(see Figure\ 1/Z.322).
.bp
.RT
.sp 1P
.LP
2.3.2
    \fIBorder area\fR
.sp 9p
.RT
.PP
The border area is that part of a visible display which is
physically unavailable for displaying or entering data
(see Figure\ 1/Z.322).
.RT
.sp 1P
.LP
2.3.3
    \fIDisplay area\fR
.sp 9p
.RT
.PP
The display area is that part of a visible display which is
available for displaying or entering data (see Figure\ 1/Z.322).
.RT
.LP
.rs
.sp 13P
.ad r
\fBFigure 1/Z.322, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
2.3.4
    \fIWindow and\fR
\fIwindow area\fR
.sp 9p
.RT
.PP
The display area can contain one or more windows. A window contains a collection
of related information. A window can consist of one window area or can
be partitioned into window areas.
.PP
The different characteristics and operations specifying windows and
window areas depend both on the system type and on the physical capabilities
of the terminal.
.RT
.sp 1P
.LP
2.3.4.1
    \fIWindow definition\fR
.sp 9p
.RT
.LP
.PP
A window is a collection of one or more window areas which can
occupy a part of the display area (sometimes the entire display area) and
it is used for entering and/or displaying data. The collection depends
on the
application. A window is dedicated to an application. More than one window
per application can be present at the samne time on the display area.
.RT
.sp 1P
.LP
2.3.4.2
    \fIWindow characteristics\fR
.sp 9p
.RT
.PP
The main characteristics of a window are:
.RT
.LP
    \(em
    its name: allowing it to be identified;
.LP
    \(em
    its location: relation to the other windows in the display
area. Windows are displayed independently of each other. Windows can appear
superimposed \(em\ one on top of another\ \(em or located side by side.
When a window is located on top, it can hide a window or windows that are
below it;
.LP
    \(em
    the list of window areas it can contain;
.LP
    \(em
    its size: its size expressed as height and width can vary;
.LP
    \(em
    its state: a window can be \*Qinteractive,\*U or \*Qnot
interactive\*U. Information entry can be performed only when the window is
\*Qinteractive\*U;
.LP
    \(em
     its visibility: a window is visible when it appears totally or partially
on the screen. It can be partially visible either because it is
overlapped by another window or because a part of the window is outside the
display area;
.LP
    \(em
     its limits: when it is visible, the limits of a visible part of a window
must be obvious to the user;
.LP
    \(em
    the application it is dedicated to.
.bp
.sp 1P
.LP
2.3.4.3
    \fIWindow area definition\fR
.sp 9p
.RT
.PP
A window area is a named part of a window that is dedicated for a specific
purpose depending upon the application.
.RT
.sp 1P
.LP
2.3.4.4
    \fIWindow area characteristics\fR
.sp 9p
.RT
.PP
The main characteristics of a window area are:
.RT
.LP
    \(em
    its name: allowing it to be identified;
.LP
    \(em
    the purpose related to it;
.LP
    \(em
     its presence state: a window area can be \*Qpresent\*U, or \*Qnot present\*U.
If a window area is \*Qnot present\*U, it can not be seen on the screen
whatever the position of the window it belongs to;
.LP
    \(em
    its position in the window: the relative location of the
window areas in a window should be fixed. This location can only be modified
by changing the presence state of other window area(s);
.LP
    \(em
    its size: its size expressed as height and width may vary;
.LP
    \(em
     its visibility: when a window area is present, it can appear or not appear
on the screen depending whether the part of the window it belongs to is
visible or not;
.LP
    \(em
    its limits: when it is visible, the limits of a window area
must be obvious to the user;
.LP
    \(em
    its text management: scrolling can be available in a window   area.
.sp 1P
.LP
2.3.4.5
    \fIGeneral rules for the display of windows and window areas\fR
.sp 9p
.RT
.PP
A window can appear anywhere on the screen totally or partially in a non\(hyrestrictive
manner.
.PP
Windows and window areas need not be displayed in all systems or in
all applications or all the time in a given system.
.PP
The limits of windows and window areas must be unambiguously clear to the
user. The techniques that may be used to achieve this include, but are
not limited to the following:
.RT
.LP
    \(em
    lines and boxes;
.LP
    \(em
    inverse video;
.LP
    \(em
     background colour. This use of colour should be distinguished from the
use of colour as a highlighting technique where colour should be used in
combination with other techniques.
.LP
.PP
Some examples of screens illustrating the use of windows and
window areas are given in Figures 2/Z.322 to 5/Z.322. In these figures,
windows are outlined by double\(hyline boundaries while the boundaries
between window
areas are depicted by single lines. Lines and boxes are used simply as a
concrete example that can be produced easily in print.
.sp 2P
.LP
2.3.5
    \fIField\fR
.sp 1P
.RT
.sp 1P
.LP
2.3.5.1
    \fIField definition\fR
.sp 9p
.RT
.PP
A field is a part of a window (sometimes the entire window area), which
is used for entering or displaying information.
.RT
.sp 1P
.LP
2.3.5.2
    \fIField characteristics\fR
.sp 9p
.RT
.PP
The most important characteristics, which may vary in time,
are:
.RT
.LP
    a)
    its position within the window area;
.LP
    b)
    its size;
.LP
    c)
    its type:
.LP
    \(em
     for entering information (input field): accessible for writing by user
and system (e.g.,\ default value);
.LP
    \(em
    for displaying information (output field): inaccessible  for writing by user.
.PP
The limits of an input field must be obvious to the user. There
may be one or several fields within one window area (see
Figure\ 6/Z.322).
.bp
.LP
.rs
.sp 47P
.ad r
\fBFIGURES 2 \*`a 6/Z.322, p.2 \*`a 6\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
2.4
    \fIPhysical characteristics\fR
.sp 9p
.RT
.PP
For further study.
.RT
.sp 1P
.LP
2.5
    \fIVideo attributes\fR
.sp 9p
.RT
.PP
Video attributes are used to emphasize certain important
information, e.g., a title, a message, a chosen item, in order to attract
the attention of the user. Video attributes work on the characters of the
information shown within an entire window or window area, a part of a window
or window area, an entire field or within just a part of the field.
.PP
The following video attributes may be provided singularly or in
combination:
.RT
.sp 1P
.LP
2.5.1
    \fILuminance\fR
.sp 9p
.RT
.PP
For further study.
.PP
Information can be displayed in different levels of luminance.
.RT
.sp 1P
.LP
2.5.2
    \fIColour\fR
.sp 9p
.RT
.PP
Information can be displayed in different colours.
.RT
.sp 1P
.LP
2.5.3
    \fIFlashing\fR
.sp 9p
.RT
.PP
Information can be displayed alternately as normal characters and as spaces
in the prevailing background colour.
.RT
.LP
.sp 1P
.LP
2.5.4
    \fIUnderline\fR
.sp 9p
.RT
.PP
Information can be displayed with underlined characters.
.RT
.sp 1P
.LP
2.5.5
    \fISize\fR
.sp 9p
.RT
.PP
Information can be displayed in different character sizes.
.RT
.sp 1P
.LP
2.5.6
    \fIFont\fR
.sp 9p
.RT
.PP
Information can be displayed in different fonts, e.g., italics,
bold.
.RT
.sp 1P
.LP
2.5.7
    \fIInverse video\fR
.sp 9p
.RT
.PP
Information can be displayed by inverting the image of the
characters, such as going from light characters on a dark background to dark
characters on a light background.
.RT
.sp 1P
.LP
2.5.8
    \fIConcealment\fR
.sp 9p
.RT
.PP
Information can be displayed as space characters, e.g.,\ secret
parts of a password.
.RT
.LP
.sp 2P
.LP
\fB3\fR     \fBOther output devices\fR
.sp 1P
.RT
.PP
For further study.
.RT
.sp 2P
.LP
\fB4\fR     \fBKeyboard characteristics\fR
.sp 1P
.RT
.PP
For further study.
.RT
.sp 2P
.LP
\fB5\fR     \fBOther input devices\fR
.sp 1P
.RT
.PP
For further study.
.bp
.RT
.sp 2P
.LP
\fB6\fR     \fBTransmission characteristics\fR
.sp 1P
.RT
.PP
There are two fundamental transmission mechanisms commonly employed and
referred to as \*Qcharacter mode\*U and \*Qblock mode\*U.
.PP
If a terminal uses character mode transmission, each and every
character input at the keyboard is sent to the controlling processor one
at a time. Thus, as is the case with the syntax of Recommendation\ Z.315,
if certain regular keys have special meanings ascribed to them e.g.,\ ;
or\ !, then they
can act as specific triggers to the controlling software which then performs
some process on the preceding information in accordance with the given
syntax rules.
.PP
If the same terminal uses block mode transmission, all of the regular typewriter
keys and some of the special purpose keys only have an effect local to
the terminal, i.e. the information input goes into the \*Qmemory\*U of
the
terminal and onto the screen normally, but not to the controlling processor.
The implication is, obviously, that special actions assigned to these keys
do not get processed until an explicit \*Qsend\*U action is made. A \*Qsend\*U
action by the user is only required when information is to be moved from
the terminal to the host processor.
.PP
The important point for the purposes of these Recommendations is that the
use of a \*Qsend\*U key is not explicitly shown at any time. It is recommended
that systems that employ \*Qblock mode\*U transmission either convey very
explicit instruction on when a \*Qsend\*U action is required of the user
or are designed to be able to accept and respond intelligently to incomplete
input, i.e.\ \*Qsend\*U
can be used by the user at any point without a fundamental disruption of the
dialogue. As far as possible this will shield the user from the effects
of the transmission mode employed.
.RT
.LP
.sp 2P
.LP
\fB7\fR     \fBControl functions\fR
.sp 1P
.RT
.PP
Control functions are those functions related to the man\(hymachine
interface that are applied by the user independently while in a dialogue
with the system functions. Control functions have no direct impact
on the system functions. Control functions are subdivided into cursor
control functions and interface control functions.
.RT
.sp 1P
.LP
7.1
    \fICursor control functions\fR
.sp 9p
.RT
.PP
A cursor is generally used as an indicator of the position where an action
will take place, such as a character being written on the screen \(em
either by the system or by the user. Cursor control functions do not directly
affect the overall system state, but assist users in selecting data entry
fields, editing fields,\ etc.
.PP
Examples include:
.RT
.LP
    a)
    \fIHome position of the cursor\fR
.LP
    Here \*Qhome\*U means a position in the display area to which
the cursor can be consistently moved, from any position, by a
single keystroke. The actual position in the display area which
represents \*Qhome\*U may vary according to the activity being
performed and the current layout of the display area.
.LP
    b)
    \fIMovement control of the cursor\fR
.LP
    Assuming that the VDT used supports direct cursor
addressing, the following types of cursor movement are
possible:
.LP
    i)
    by the system, and
.LP
    ii)
    by the user via cursor control functions. General
cursor control functions independent of dialogue are:
.LP
    \(em\ one line up;
.LP
    \(em\ one line down;
.LP
    \(em\ one place left;
.LP
    \(em\ one place right.
.LP
.PP
Ideally, cursor movement should be easy to accomplish by means of a single,
dedicated key for each function. Shifted characters should be
avoided. If a cursor positioning control key is used, it should repeat when
held down. Cursor movement may also be controlled by other input devices,
e.g.,\ light pen, trackball, mouse or joystick.
.bp
.PP
When cursor positioning is incremental by discrete steps, the step
size of cursor movement should be consistent in both right and left directions
and both up and down directions. However, the cursor may bypass inaccessible
fields.
.PP
When character size is variable on the display, incremental cursor
positioning should have a variable step size corresponding to the currently
selected character size.
.RT
.sp 1P
.LP
7.2
    \fIInterface control functions\fR
.sp 9p
.RT
.PP
Functions of this class are used to force specific actions relating to
the interface. They are invoked by various means, including pressing
dedicated control keys.
.PP
Examples of man\(hymachine interface control functions include, but are
not limited to:
.RT
.LP
    \(em
    send (other words for the same function are \*Qtransmit\*U
and \*Uenter\*U) [see \(sc\ 6];
.LP
    \(em
    editing control functions (insert character, insert line,
replace character,\ etc.);
.LP
    \(em
    capitals lock (the condition where letters are input as
capitals only);
.LP
    \(em
    select different font [see \(sc\ 2.5.6];
.LP
    \(em
    select different character size [see \(sc\ 2.5.5].
\v'6p'
.sp 2P
.LP
\fBRecommendation\ Z.323\fR
.RT
.sp 2P
.sp 1P
.ce 1000
\fBMAN\(hyMACHINE\ INTERACTION\fR
.EF '%    Fascicle\ X.7\ \(em\ Rec.\ Z.323''
.OF '''Fascicle\ X.7\ \(em\ Rec.\ Z.323    %'
.ce 0
.sp 1P
.LP
\fB1\fR     \fBIntroduction\fR
.sp 1P
.RT
.PP
This Recommendation describes \fIhow\fR  | nteractions should take place
between the user and the system from a logical viewpoint. It describes
how an effective man\(hymachine interface should appear to the user when
utilizing the
capabilities of VDTs as described in Recommendation Z.322. This Recommendation
supersedes Recommendations\ Z.311\(hyZ.317 for interfaces based on VDTs,
referencing parts of them where appropriate. Specific human factor guidelines
are included within the appropriate divisions of the text.
.PP
The capabilities of VDTs, e.g., multiple windows, inverse video, etc.,
when used consistently can lead to a more effective man\(hymachine interface.
Additional dialogue procedures are possible and often preferable with VDTs,
.PP
e.g.,\ using different windows for different applications. Likewise, the
transient nature of information presented on a screen may affect the selection
of information display and the manner of presentation. The terminal
capabilities available must be considered in conjunction with guidelines
presented in this Recommendation in order to produce the most effective
interface.
.PP
Many advances in the state of the art of man\(hymachine interface design
are incorporated in Recommendation\ Z.323. However, the use of graphics
capabilities have not yet been considered in any detail in these
Recommendations and must be studied further. The needs of the user moving
between different systems or different types of terminals are best facilitated
by ensuring that capabilities are used consistently and that user assistance
is an integral part of interface design. Interfaces designed according
to the
principles outlined in this Recommendation will tend to be more user friendly,
effective interfaces.
.RT
.sp 2P
.LP
\fB2\fR     \fBCommon aspects\fR
.sp 1P
.RT
.sp 1P
.LP
2.1
    \fIData display\fR
.sp 9p
.RT
.PP
Data display is the presentation of information by the system to
the user. During a dialogue the number, dimension and position of windows,
window areas and fields in the display area may be changed. Not all fields,
window areas or windows need necessarily display information at any one
time.
.bp
.PP
Visual display terminals facilitate information entry through menu
selection and form filling. Since presentation of more information at one
time might cause confusion, care must be taken to label information clearly,
to keep displays simple, to highlight information consistently and in moderation,
and to maintain a consistent information layout as far as possible.
.RT
.sp 1P
.LP
2.1.1
    \fIGeneral\fR \fIguidelines\fR
.sp 9p
.RT
.PP
The layout of output is dependent on what type of data is
presented. There are three basic types, combinations of which are
possible:
.RT
.LP
    \(em
    textual data;
.LP
    \(em
    numeric data;
.LP
    \(em
    tabular data.
.LP
    a)
    \fIGuidelines for textual data\fR :
.LP
    \(em
    text should be written using upper and lower case
letters;
.LP
    \(em
    abbreviations should not be used if confusion might
be caused;
.LP
    \(em
    plain text should be used rather than codes.
.LP
    b)
    \fIGuidelines for numeric data\fR :
.LP
    \(em
    strings of more than five numeric characters may be
presented in groups of two to four;
.LP
    \(em
     standardized formats (e.g., data and time as specified in Recommendation\
Z.316) should be used.
.LP
    c)
    \fIGuidelines for tabular data\fR :
.LP
    \(em
     in case of lengthy columns, spacing between about every five items improves
readability;
.LP
    \(em
    items which are related to each other should be placed  close together;
.LP
    \(em
     figures arranged in columns are easier to compare than figures arranged
in a row;
.LP
    \(em
    integers should be right justified;
.LP
    \(em
    numerical entries with decimals should be justified
with respect to a fixed decimal point position;
.LP
    \(em
    text and labels should be left justified;
.LP
    \(em
     if any text continues on another line, it should begin in the same column
as the text above.
.sp 1P
.LP
2.1.2
    \fIAccessible and inaccessible parts of the display area\fR
.sp 9p
.RT
.PP
VDTs provide the capability to characterize some fields of the
screen as accessible for writing by the system only, some other fields
accessible for the system and the user.
.PP
The fields used for the display of headers, parameter identities,
delimiters, etc., should be accessible for writing only by the
system (output fields). The fields used for the input of parameters should
be accessible both to the system and to the user (input fields). The system
can
highlight these fields, for example, by underlining to distinguish the
field or a default value, if appropriate. The user can access the field
to input the
desired value(s), to edit the previous input value(s), or to edit the offered
default value.
.PP
The user may attempt to write into a field reserved for the system.
This should not be allowed, an indication should be sent to the user and the
input characters should be ignored. The type of this indication depends
on the terminal facilities and may be an audible or visible signal. However,
the
terminal shall immediately recover from this situation so that the user can
proceed.
.RT
.sp 1P
.LP
2.1.3
    \fIHighlighting\fR
.sp 9p
.RT
.PP
Highlighting is used to emphasize visually a portion of a display area
to make it stand out from adjacent portions, i.e.,\ to call the viewer's
attention to it. It should be used consistently and in moderation. In
particular, care should be taken not to confuse or otherwise overload the
user by highlighting.
.bp
.PP
There are a number of areas where highlighting may be applied, such
as:
.RT
.LP
    \(em
    defaults in forms;
.LP
    \(em
    optional information entry in forms;
.LP
    \(em
    indication of system irregularities and their urgency, etc.
.PP
There are a number of possible highlighting techniques, such as:
.LP
    \(em
    different levels of luminance;
.LP
    \(em
    colour;
.LP
    \(em
    flashing;
.LP
    \(em
    underlining;
.LP
    \(em
    different character sizes or fonts;
.LP
    \(em
    small or capital letters (lower or upper case);
.LP
    \(em
    pointing with arrows, asterisk, etc.;
.LP
    \(em
    inverse video;
.LP
    \(em
    combinations of the above.
.PP
Some guidelines that should be followed in all applications of
highlighting are:
.LP
    a)
    when colour screens are used:
.LP
    \(em
    in order to reduce problems for colour\(hyblind users and
to facilitate a transition between colour and
monochromatic terminals within the same system, colour
should normally be used in combination with some other
means of distinction. Note also that some colours may have
psychological associations, perhaps depending on the
cultural tradition of a nation, e.g., red for danger,
green for proceed;
.LP
    \(em
    be consistent in the use of colour. Colour is a means
to recognize rapidly particular windows, window areas or
fields on the screen, independent of any system;
.LP
    \(em
    colour should be used for additional distinction and
emphasis. For example, colour should be used for aiding
the user in locating information and for alerting the user
to status changes. Colour should be used sparingly. It
should not be used for purely aesthetic and nonfunctional
effect as the main aim;
.LP
    \(em
    if the user is given the capability to modify the
colour of any area or object displayed on the screen, the
user should be cautioned about changing colour via any
assistance mechanism provided to the user. For example, in
the case where the user is changing adjacent areas/objects
to the same colour, a warning should be given. Where the
capability is provided, the user should be allowed to
make any modifications desired. Also, it is desirable that
secure access to this capability be provided;
.LP
    \(em
    the number of colours with specific meanings should be
limited. Associating meanings with too many colours may
confuse the user;
.LP
    \(em
    colour combinations should be chosen such that there is
sufficient contrast in hue and density wherever two
colours meet. This is particularly true in the case where
a text is displayed over a colour background;
.LP
    \(em
    colour combinations should be chosen with care, as many
combinations can be displeasing to the eye;
.LP
    b)
    use only one level of luminance in addition to the normal
level when highlighting. Variations in room lighting, specific
VDTs and user perceptions make it unlikely that more than two
levels will be universally distinguished;
.LP
    c)
    when using more than one highlighting technique, do not
highlight more than 30% of the display. If everything is
highlighted, even differently, then nothing is highlighted;
.LP
    d)
    since flashing attracts much attention, its use should be
restricted to special applications, e.g.,\ alarms. Once the user
acknowledges the perception of the flashing information, the
flashing should be stopped;
.bp
.LP
    e)
    if the user needs to read text from a flashing area,
the flashing should be slow in order to make the text readable.
An alternative would be flashing pointers, pointing to the text
area of importance;
.LP
    f
)
    in one system, or at least in each job area,
highlighting facilities should be consistently applied;
.LP
    g)
    information can be displayed with underlined characters.
However, this type of video attribute might make it difficult to
observe the cursor on terminals where the underline character is
used as the cursor.
.sp 1P
.LP
2.1.4
    \fIInformation layout\fR
.sp 9p
.RT
.PP
A user should always be able to recognize at first sight:
.RT
.LP
    \(em
    where parameter input is desired in a form;
.LP
    \(em
    where system response is expected;
.LP
    \(em
    where the system status is displayed;
.LP
    \(em
    where user guidance is expected, if requested;
.LP
    \(em
    where menus are displayed.
.PP
Therefore, the information layout, when determined by the system,
should follow common rules in such a way that information of certain categories
will be displayed in certain portions of the display area.
.PP
The information layout should be consistent in any one system.
Information, which is not necessary in certain job areas, may be
omitted.
.RT
.sp 1P
.LP
2.1.5
    \fIDescription of window areas\fR
.sp 9p
.RT
.PP
The following window areas can be distinguished in a window on the display
area:
.RT
.LP
    \(em
    \fIGeneral information window area.\fR  | This window area can contain
system identification and/or application identification, and
optionally, date, time, and other relevant information. This
window area is optional;
.LP
    \(em
    \fIStatus window area.\fR  | This window area should contain alarm
indicators of the system being controlled, trouble reporting
information from connected equipment, and message waiting
indicators. The information displayed may be restricted to the
particular application being controlled. This window area is
optional;
.LP
    \(em
    \fIWork window area.\fR  | This window area should be used for
information entry through form filling and menu\(hyitem selection.
The work window area may also be used as a graphic display and
screen editor area, and should support scrolling. This window
area is required for information entry through form filling and
menu\(hyitem selection but is optional otherwise;
.LP
    \(em
    \fIOutput and input window areas.\fR  | These two window areas
should
support scrolling and should be user controllable in size. The
input window area should be used for direct information entry.
Response to the direct information entry as well as output
outside dialogue should appear in the output window area. Input
acknowledgements may also appear directly following the command
in the input window area. The scrolling should occur in two
window areas separately, or both window areas may be combined
into one window area. These window areas are required for
direct information entry but are optional otherwise;
.LP
    \(em
    \fISpecial keys and directives information window area.\fR  | This
window area should display function key labels and specifics
about the use of directives. This window area is
optional.
.sp 1P
.LP
2.1.6
    \fIOrdering of window areas\fR
.sp 9p
.RT
.PP
The relative locations of the status, work, output, and input
window areas should be fixed for any given system.
.bp
.PP
Screen layout recomendations for window areas that span the entire
width of the window are shown in Figure\ 1/Z.323. In this case, the screen
layout will have the window areas ordered as shown with the understanding
that each window area remains optional.
.RT
.LP
.rs
.sp 13P
.ad r
\fBFigure 1/Z.323, p. \fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
2.2
    \fIInput editing\fR
.sp 9p
.RT
.PP
Editing mechanisms can be used to correct erroneous input during
data entry or to change previously entered input in order to resubmit it.
.PP
Several possibilities of editing can be distinguished, including
the following:
.RT
.LP
    \(em
    delete last character or last n characters;
.LP
    \(em
    delete or overwrite last field;
.LP
    \(em
    delete or overwrite arbitrary fields;
.LP
    \(em
    insert characters.
.PP
Editing mechanisms may be dependent on the facilities of a
terminal, such as function keys.
.sp 1P
.LP
2.3
    \fIResponse time\fR
.sp 9p
.RT
.PP
In a system operating normally, response output (see
Recommendation\ Z.317) to a command should be presented to the user within a
psychologically acceptable time limit, normally taken to be of the order
of two seconds after input. For any given type of command, this time limit
should be as uniform as possible in order to meet the expectations of the
user.
.PP
Depending on the nature of the command, two types of response output can
be distinguished:
.RT
.LP
    a)
    that which conveys the results of the execution of the
command;
.LP
    b)
    that which concerns the acceptance only of the command,
results being communicated to the user by output outside
dialogue.
.PP
Response output concerning user errors should be given to the user as soon
as possible. Although a fixed rule cannot be defined, the following
guidelines can be given:
.LP
    \(em
    syntactical errors must be discovered very early by the
system; the response time should be within the psychologically
acceptable time limit;
.LP
    \(em
    semantic errors can sometimes be discovered early, sometimes
late, depending on the type of command and on the nature of the
error; normally the feedback should be given to the user as soon
as the error is detected;
.LP
    \(em
    semantic errors in pre\(hyscheduled jobs should be indicated to
the user either immediately after the command input, if this is
possible, or at the time the result is expected.
.sp 1P
.LP
2.4
    \fIDirectives\fR
.sp 9p
.RT
.PP
The presentation of system output in the form of
guidance
output, menus, form output, waiting system reports, next page, etc., can be
controlled by means of input statements called directives. It is possible to
qualify the effect of directives either by the use of context or by the
use of additional parameters.
.bp
.PP
Directives are used to direct the system to present information rather
than to execute a command; they can also be used in the interaction between
the user and the system prior to command execution.
.PP
Directives can be given to the system by a word, e.g., HELP, by a
special character, e.g., \*Q?\*U (question mark), a
dedicated function key, or by non\(hykeyboard devices.
.PP
Directives can never cause any change in the state of the system. This
distinction from commands is made to encourage users to make full use of
such facilities without fear of altering the system unintentionally.
.PP
The subject of directives needs further study.
.RT
.sp 1P
.LP
2.5
    \fIUser guidance\fR
.sp 9p
.RT
.PP
When a user interacts with a system, there are times when more
information about the system is needed than provided by the dialogue element
in use, to assist the user in proper and efficient system operation. This
information can be provided by means of various categories of user
guidance.
.PP
Examples of different types of information that could be obtained in a
guidance output are:
.RT
.LP
    \(em
    how to obtain more specific guidance. A single guidance
output at the highest level of simplicity might be displayed
when the user enters a directive without any parameters, and the
precise nature of guidance required is unclear from the
context;
.LP
    \(em
    general principles of dialogue procedure;
.LP
    \(em
    what telecommunications services are available;
.LP
    \(em
    what jobs can be performed;
.LP
    \(em
    a description of structure and application of either classes
of commands or a single command in detail. The user must
specifically request that such output be displayed, either from
the highest level of guidance output or via the parameter on the
guidance directive;
.LP
    \(em
    how the job is performed without actually executing it;
.LP
    \(em
    what the user has done so far;
.LP
    \(em
    what kind of entry the system expects from the user,
e.g.,\ possible commands, range of a parameter value, example of
a correct parameter entry;
.LP
    \(em
    the meaning and consequence of forms, commands, menu items,
etc., which are displayed on the screen;
.LP
    \(em
    the syntax or a short explanation of a specific command or
job;
.LP
    \(em
    a short description of a specific parameter, e.g., its
default value or the permitted range of values.
.PP
In order to make the guidance as effective as possible, the
following guidelines can be given:
.LP
    \(em
    any guidance provided must be kept up\(hyto\(hydate and accurate;
.LP
    \(em
    guidance should be available in a consistent manner
throughout the system;
.LP
    \(em
    unnecessary codes and abbreviations in guidance messages
should be avoided.
.PP
A classification for user guidance based on user interface
characteristics is presented in Figure\ 2/Z.323.
.LP
.rs
.sp 12P
.ad r
\fBFigure 2/Z.323, p. \fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
2.5.1
    \fIStand\(hyalone guidance\fR
.sp 9p
.RT
.PP
A stand\(hyalone guidance facility can be used without necessarily
accessing the function for which the guidance is provided.
.RT
.sp 1P
.LP
2.5.1.1
    \fIOn\(hyline training\fR
.sp 9p
.RT
.PP
The primary purpose of on\(hyline training is to supplement or replace
other training methods such as classroom instruction, training manuals,
or
video courses. It can provide training on how to use the system (or parts of
the system) for the first time, to refresh understanding, or to learn the
system or function in more depth.
.PP
This type of information is provided as a separate function, and is
designed to facilitate the learning or educational process.
.PP
The major difference between on\(hyline training and other types of
guidance is that training usually takes place in a \*Qspecial\*U situation,
intended to encourage learning. Because of the close relationship between
on\(hyline training and other guidance facilities, it is impossible to
design or evaluate other guidance facilities without considering the training
system.
.PP
Rudimentary guidance may be perfect for a trained user who
occasionally needs a memory aid, while very elaborate on\(hyline help may be
needed for anyone with no previous training.
.RT
.sp 1P
.LP
2.5.1.2
    \fIOn\(hyline documentation\fR
.sp 9p
.RT
.PP
The primary purpose of on\(hyline documentation is to provide the user
with a comprehensive body of information about a given subject related
to the function. The major difference between on\(hyline documentation
and on\(hyline
training is that on\(hyline documentation is meant to be used as a reference by
users with a fundamental understanding of the function, hence is not a
replacement for training. Although available as a stand\(hyalone facility,
on\(hyline documentation may also be accessible during execution of the
function. In this case, to avoid confusion with other types of guidance,
the user should be
notified, either implicitly by distinct format or explicitly by a message,
that this help is also available as a stand\(hyalone on\(hyline documentation
facility.
.RT
.sp 1P
.LP
2.5.2
    \fIUnsolicited guidance\fR
.sp 9p
.RT
.PP
An unsolicited guidance facility provides user guidance when the
system determines there is a necessity. Examples of unsolicited guidance are
messages and prompts.  Messages are issued to provide information on the
current task, give status or completion messages for background tasks, or to
notify the user of error situations. Prompts are issued as a result of an
action request by the user. Messages and prompts are means through which the
system provides feedback to the user, and assists the user in completing a
dialogue with the system. They may request specific input, such as a request
to the user to key required data, or to request the user to take a specific
action, such as inserting a diskette.
.RT
.sp 1P
.LP
2.5.3
    \fISolicited guidance (on\(hyline help)\fR
.sp 9p
.RT
.PP
Solicited guidance (also called on\(hyline help) is a system's
capability to provide a user with information on how to use the system while
using it.
.PP
This help facility requires the users to solicit the presentation of help
information by means of an explicitly or implicitly stated request. The
primary purpose of the on\(hyline help facility is to provide a consistent and
easy\(hyto\(hyuse tool, that upon request, will give operational assistance
necessary so that the user can make efficient use of the system to accomplish
a work
product.
.PP
Help text written using a consistent style is easier to understand and
promotes user confidence. The following guidelines are given:
.RT
.LP
    \(em
    sentences should be complete and concisely written. Detail
should be limited to only what is needed for guidance on the
requested item;
.LP
    \(em
    sentences should be action oriented;
.LP
    \(em
    help messages should use familiar wording so that users do
not have to learn new wording for familiar concepts;
.LP
    \(em
    references to outside material may be included in the help
text, especially if the help information cannot be provided in a
concise way.
.bp
.sp 1P
.LP
2.5.3.1
    \fIOn\(hyline help by implicit request\fR
.sp 9p
.RT
.PP
This type of help facility assumes that the user, upon a specific interaction,
requests information from the system. The basic distinction
between unsolicited guidance and on\(hyline help by implicit request is
that the latter can be turned on or off by the user.
.PP
For example, the user employs information entry through form filling. If
the on\(hyline help by implicit request is activated, the movement of the
cursor to a field reserved for the entry of a parameter value causes a
message to appear in an output field reserved for implicitly requested
help on form
filling. The message describes the form in which the parameter value should
be entered and the acceptable values. This approach has the advantage that
the
form layout does not need to be cluttered with supplementary information (as
described in Recommendation\ Z.323, \(sc\ 3.4.1).
.PP
In order to make this type of help facility effective, the following guidelines
can be given:
.RT
.LP
    \(em
    implicit requests should be limited to accompanying user
actions that immediately proceed or are directly related to the
entry of information (e.g., moving the cursor to an input
field);
.LP
    \(em
    the help displayed as a result of an implicit request should
contain concise information that is of immediate use to the
user;
.LP
    \(em
    the help message needs to appear in a consistent location
which is easily consulted but does not interfere with the
information currently in progress;
.LP
    \(em
    the implicitly requested help message should disappear
automatically when the user moves on in the dialogue and the
message is no longer relevant.
.sp 1P
.LP
2.5.3.2
    \fIOn\(hyline help by explicit request\fR
.sp 9p
.RT
.PP
This type of on\(hyline help (which will be referred to as \*Qhelp\*U in
this section for brevity) facility assists the user to complete a work
activity by providing specific directions when explicitly requested by
the user. The
user indicates the item in question, and the system responds with the
information specific to the request. Help output is displayed at the user's
request by the use of directives.
.PP
For systems providing this capability, the following guidelines can be given:
.RT
.LP
    a)
    \fIGuidelines on information content and consistency\fR
.LP
    \(em
    The information in on\(hyline help should be designed to
provide opertional assistance rather than covering
training materials, or providing a tutorial;
.LP
    \(em
    the help should be available within the context of the
current dialogue. Contextual help means that within the
appropriate authority level, the user can have assistance
for items such as menus, options, parameters, commands,
objects, or actions relative to the currently displayed
information within current task of operation;
.LP
    \(em
    the type and level of detail of help information
provided should be consistent with the anticipated needs
of the user at any particular stage of a dialogue. For
instance, a \*Qhelp\*U request made prior to inputting
anything at a terminal could result in a high level
introduction to the human\(hymachine interface facilities,
whereas a \*Qhelp\*U request made instead of inputting a
parameter value could result in detailed information on
what possible values that parameter could have, and
perhaps what each value means;
.LP
    \(em
    the help facility should be designed to assist the user
in progressing from one step within the dialogue to the
next by supplying information that gives specific
directions the user should follow;
.LP
    \(em
    the help facility should be available throughout the
conduct of any dialogue. For example, if help is
available for one menu, appropriate help should be
available for all menus;
.LP
    \(em
    if the user requests help for an item that is not
defined within the help facility, the user should be
notified that no help is available for the specific item
requested and be directed to help relevant to the
context;
.LP
    \(em
    if the system cannot determine exactly what help
information is requested, it will present safe information
such as a menu of topics instead of guessing at what the
user wants;
.LP
    \(em
    the help facility should allow a user to obtain
information about dialogue elements which do not belong
to the current context;
.LP
    \(em
    the help facility should itself have help available.
For example, this \*Qhelp for help\*U could allow the user to
select additional help topics, present a list of possible
help items, or provide a brief description of the help
facility.
.bp
.LP
    b)
    \fIGuidelines on user\(hyhelp facility interaction\fR
.LP
    To provide a simple and efficient interface with the help
facility, the following guidelines are given:
.LP
    \(em
    help messages should preferably not overwrite data,
error information or user commands and vice versa. In
cases where this is unavoidable, a simple mechanism should
be provided to retrieve the original information;
.LP
    \(em
    the user interface to the help facility should be
consistent with the interface to the other tasks within
the system. For example, help menus should be
constructed like other menus, selection techniques
should operate the same, presentation style should be
consistent, and command procedures should function the
same;
.LP
    \(em
    when a hierarchy of help information is required, the
paths through the hierarchy should be short and simple;
.LP
    \(em
    it should be possible for a user to request directly
the exact level of detail required without having to step
through intermediate higher level information;
.LP
    \(em
    when possible, the help information should be displayed
so that it preserves the visual reference to the dialogue
content. Help information is most useful and least
disruptive when the user has visual reference to both at
the same time;
.LP
    \(em
    where multiple pages of help are available, it should
be possible to have any page displayed without having to
display intervening pages;
.LP
    \(em
    in the case of a long help message the user must be
provided with some means of scrolling back or forth
through the displayed text;
.LP
    \(em
    instructions for exiting the help facility should be
available on the system;
.LP
    \(em
    when the user explicitly exits the help, the user
dialogue should be restored to its original position
before the help was requested;
.LP
    \(em
    the help information should remain displayed either
until the user explicitly exits the help facility or until
the user executes a dialogue step which eliminates the
need for the help information.
.sp 1P
.LP
2.6
    \fIDefaults\fR
.sp 9p
.RT
.PP
In some applications the normal and most frequently used input can be predicted
by the system. Default values which can be considered critical in the sense
that they may create situations dangerous to the system integrity
should be avoided.
.RT
.sp 1P
.LP
2.6.1
    \fIUse of default values during data entry\fR
.sp 9p
.RT
.PP
To make the user's work easier, input of the most frequently used parameter
values may be prepared by the system. If this offer does not match
the user's desire, the possibility to overwrite the default must be open.
.PP
An offered default can be accepted by the user, either by active
selection such as pressing a dedicated function key or by passive selection,
i.e.,\ without taking specific action.
.PP
The overwriting or deletion of defaults can be done by editing
mechanisms as described in \(sc\ 2.2.
.RT
.sp 1P
.LP
2.6.2
    \fIDisplay of defaults during data entry\fR
.sp 9p
.RT
.PP
The main reason for using defaults is to simplify the user's
information entry to the system.
.PP
To achieve this, defaults should be offered by the system and may be highlighted
as described in \(sc\ 2.1.3, so that it is obvious to the user which
data entry area he has filled himself and which has been filled by the
system. The highlighting technique should be consistent in a system or
at least in a certain job area.
.RT
.sp 2P
.LP
2.7
    \fIInput error handling\fR
.sp 1P
.RT
.sp 1P
.LP
2.7.1
    \fIInput error information\fR
.sp 9p
.RT
.PP
In the event of erroneous input, some form of input error
information, normally in the form of request output (see
Recommendation\ Z.317), must be presented to the user.
.bp
.PP
Ideally, input error information would contain:
.RT
.LP
    \(em
    where the error was detected;
.LP
    \(em
    what kind of error was made;
.LP
    \(em
    how to recover from it or at least how to find a way to
recover from it.
.PP
In some cases it may be difficult to supply the user with all this information.
.PP
In many cases the input error information may be self\(hycontained, in
other cases reference may be made to other sources of information.
.PP
The length and detail of the message should be proportional to the
nature of the error; the user should not have to look at a long explanation
for a simple error.
.PP
Coded messages and intimidating jargon such as \*Qsyntax error\*U should
be avoided. Messages should be polite and should not patronize or insult
the
intelligence of the user.
.PP
When an error is detected and error information is displayed, the
field containing the error may be highlighted.
.RT
.sp 1P
.LP
2.7.2
    \fILocation of error information\fR
.sp 9p
.RT
.PP
Error information should always appear in a consistent manner on
the screen. This should be common within one system or at least within one
job area.
.RT
.sp 1P
.LP
2.7.3
    \fIMultiple errors\fR
.sp 9p
.RT
.PP
Multiple independent errors in one data entry should, if possible, be reported
together at one and the same time.
.PP
Incidences of conflicting combinations of parameters or parameter
values should be treated by the error information as a single subject.
.RT
.sp 1P
.LP
2.7.4
    \fICorrection of errors\fR
.sp 9p
.RT
.PP
Following detection of an error situation, the user should be
provided with mechanisms to correct the erroneous input. Such mechanisms
could include:
.RT
.LP
    \(em
    the system placing the cursor on the erroneous field and
requesting input;
.LP
    \(em
    the user addressing the field, e.g., by name, number or
lightpen, or cursor control keys or joystick to get to the
field(s) which needs to be changed.
.PP
The erroneous information should remain on the screen until it is  corrected.
.sp 2P
.LP
\fB3\fR     \fBDialogue procedure\fR
.sp 1P
.RT
.sp 1P
.LP
3.1
    \fIGeneral\fR
.sp 9p
.RT
.PP
In the general description of the dialogue procedure, aspects of
error correction and of help request are not included. These topics are
treated in the detailed descriptions of the specific dialogue elements.
For examples
of dialogue procedures, see Annex\ A.
.RT
.sp 1P
.LP
3.1.1
    \fIStructure\fR
.sp 9p
.RT
.PP
The dialogue procedure is depicted in Figure 3/Z.323.
.RT
.LP
.rs
.sp 7P
.ad r
\fBFigure 3/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
The dialogue is divided into three main parts:
.LP
    \(em
    prologue;
.LP
    \(em
    body;
.LP
    \(em
    epilogue.
.PP
For the procedure prologue and the procedure epilogue, refer to
Recommendation\ Z.317. The procedure body is depicted in Figure\ 4/Z.323.
.LP
.rs
.sp 27P
.ad r
\fBFigure 4/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
3.1.2
    \fIDialogue elements\fR
.sp 9p
.RT
.PP
In the CCITT MML, three different dialogue elements can be
distinguished with respect to the method of entering information into the
system via a man\(hymachine terminal:
.RT
.LP
    \(em
    direct information entry;
.LP
    \(em
    information entry through menu\(hyitem selection;
.LP
    \(em
    information entry through form filling.
.PP
Information entry can be accomplished exclusively by one of the
dialogue elements or \(em if a system supports more than one dialogue element
\(em by a combination of elements, e.g.:
.LP
    \(em
    menu\(hyitem selection and direct information entry;
.LP
    \(em
    menu\(hyitem selection and form filling.
.sp 1P
.LP
3.1.3
    \fISelection of dialogue elements\fR
.sp 9p
.RT
.PP
Choosing the right dialogue element depends very much on the nature of
the job to be performed and the experience of the user. Often there are
many different job areas that the user could deal with during his session
at the
terminal and the best method, for an inexperienced user, when selecting
a job area, and then a specific job in this area, may be to use menu selection(s).
.bp
.PP
The experienced user would probably prefer a more direct method to
reach a specific job, but will also use menu\(hyitem selection(s) when
performing jobs that are infrequently used. Therefore the availability
of both dialogue
elements is attractive.
.PP
For maintenance staff who gain access to a system via the public
switched telephone network with a simple portable terminal, it may not be
possible to use every dialogue element due to restrictions imposed by the
terminal characteristics.
.PP
Directives may be used for selecting dialogue elements. They may
be either abbreviated menu or form identities, or function keys. The
abbreviated menu or form identities need to be uniquely distinguishable from
command codes, e.g.,\ an abbreviated form identity could consist of a command
code terminated by a question mark.
.PP
If direct information entry is available besides other dialogue
elements, then direct information entry should always be possible after
output of a ready indication or a menu. This may or may not require the
use of a
directive.
.PP
It should be possible to enter an allowed command or destination
identifier even if a displayed menu does not contain it.
.RT
.sp 1P
.LP
3.1.4
    \fIStart and end of information entry\fR
.sp 9p
.RT
.PP
The system invites the start of information entry by the output
of:
.RT
.LP
    \(em
    a spontaneous menu (one that is automatically given) and/or
.LP
    \(em
    a ready indication.
.PP
The spontaneous menu given may be different depending on the
authority of the user or the terminal involved. Any menu can always be
requested by the use of a directive.
.PP
Completion of information entry always results in an Input
Acknowledgement as is shown in Figure\ 5/Z.323 or in an appropriate error
treatment.
.RT
.LP
.rs
.sp 16P
.ad r
\fBFigure 5/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.PP
As in Recommendation Z.317, an Acceptance Output may be followed by an
Interaction Request Output.
.sp 1P
.LP
3.1.5
    \fIEnd of input indication\fR
.sp 9p
.RT
.PP
In all dialogue elements the user may need to mark the end of input in
order to have the information interpreted by the system. This can be done
by some special indicators (see Recommendation\ Z.314) which contain an
implicit
end of input indication or by special function keys, e.g.,\ \*Qsend\*U.
If more than one dialogue element is provided in a system, the end of input
indication
should be consistently used within each dialogue element.
.bp
.RT
.sp 1P
.LP
3.2
    \fIDirect information entry\fR
.sp 9p
.RT
.PP
Direct information entry can apply to any area of application of
the CCITT MML.
.PP
The direct information entry, recommended for operation and
maintenance, installation and acceptance testing of SPC systems, consists of
two sub\(hyelements:
.RT
.LP
    \(em
    destination prologue;
.LP
    \(em
    interactive operating sequence.
.PP
See Figure 6/Z.323.
.PP
For both sub\(hyelements, refer to Recommendation\ Z.317.
.RT
.LP
.rs
.sp 13P
.ad r
\fBFigure 6/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
3.2.1
    \fIInformation entry\fR
.sp 9p
.RT
.PP
Direct information entry may comprise:
.RT
.LP
    \(em
    destination identifier to enable the destination of the
information entered subsequently to be changed;
.LP
    \(em
    command code to identify the type of activity to be
executed;
.LP
    \(em
    parameter values necessary to allow execution of a requested
action;
.LP
    \(em
    manual response as a part of an entering procedure requiring
hardware manipulation such as operating switches, replacing
equipment,\ etc.
.PP
These aspects are specified in Recommendations Z.315 and Z.317.
.sp 1P
.LP
3.2.2
    \fIExecution of a command\fR
.sp 9p
.RT
.PP
A request to execute a command will eventually lead to acceptance or rejection
output, refer to Recommendation\ Z.317.
.RT
.sp 1P
.LP
3.2.3
    \fIUser guidance\fR
.sp 9p
.RT
.PP
Refer to \(sc 2.5.
.RT
.sp 1P
.LP
3.2.4
    \fIGuidance output\fR
.sp 9p
.RT
.PP
Guidance output is in general related to a command and contains
information such as:
.RT
.LP
    \(em
    the complete block of parameters to be input for a specific   command;
.LP
    \(em
    that part of the block of parameters that is still to be
input;
.LP
    \(em
    the parameter next to be input;
.LP
    \(em
     the fact that the complete parameter block has been entered and a request
to execute a command can be given.
.bp
.sp 1P
.LP
3.2.5
    \fIError correction aspects\fR
.sp 9p
.RT
.PP
Input error information can be contained in guidance output or in request
output (refer to Recommendation\ Z.317 and to \(sc\ 2.7).
.RT
.sp 1P
.LP
3.3
    \fIInformation entry through menu\(hyitem selection\fR
.sp 9p
.RT
.PP
The essential advantage of menu\(hyitem selection as a way of
interaction is that it can remove memory load from the user. The items
available are laid out for inspection, and the way in which each item may be
selected is obvious.
.PP
The task of performing any transaction using a menu is thus reduced
to:
.RT
.LP
    \(em
    scanning the items;
.LP
    \(em
    finding the required item (if already known by the user),
or deciding which item to choose (if not already known by the
user);
.LP
    \(em
    selecting an item.
.PP
The use of menus is particularly appropriate for applications
where there will be many casual users or where there may be frequent
interruptions to work at the terminal, and for activities which are
infrequently performed.
.PP
Menus may be used as a means to arrive at a command code, to select a new
destination or to assemble and to execute a command with all its relevant
parameters. The system outputs a list of items (the menu output), from
which
the user can select the appropriate item. In a menu selection procedure, a
selection of items from subsequent menu outputs may be needed.
.RT
.sp 1P
.LP
3.3.1
    \fIDisplay of the menu output\fR
.sp 9p
.RT
.PP
The menu output (see Figure 7/Z.323) may contain several types
of information:
.RT
.LP
    \(em
    menu identity;
.LP
    \(em
    menu items;
.LP
    \(em
    additional information.
.LP
.rs
.sp 11P
.ad r
\fBFigure 7/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.PP
The information can be displayed in fields and/or given by
highlighting techniques.
.PP
The \fImenu identity\fR  | s displayed in a field at the head of the menu.
It identifies the menu, preferably in a concise meaningful manner to allow
an easy recognition of the nature of the menu.
.PP
A \fImenu item\fR  | s displayed in a field that contains a brief
description of the item and an optional selection identity. By inputting
such an identity, a choice can be made. The selection identity should be
displayed at the left side of this field.
.PP
The \fIadditional information\fR  | s intended to present more information
to the user in order to aid the selection of an item from the menu, e.g.,\
the text \*QEnter choice\*U.
.PP
The menu layout in the window should be consistent throughout all the menus
in a given system. Only one menu should be presented at a time, always
displayed in its entirety.
.bp
.RT
.sp 1P
.LP
3.3.2
    \fIItem selection\fR
.sp 9p
.RT
.PP
Refer to Figures 8/Z.323 and 4/Z.323.
.RT
.LP
.rs
.sp 18P
.ad r
\fBFigure 8/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.PP
The selection of an item can be done in two basic ways:
.LP
    a)
    inputting the selection identity;
.LP
    b)
    pointing at the item by using techniques such as cursor
positioning, lightpen, touch screen, function key, etc.
.PP
Selection of more than one item from one menu is not permitted.
.PP
When using a hierarchy of menus, it may be helpful for the user to be able
to return to the previous menu.
.PP
When the user notifies the system that he has made his selection, the system
confirms the input by a new menu, a form output, or an input
acknowledgement.
.RT
.sp 1P
.LP
3.3.3
    \fIUser guidance\fR
.sp 9p
.RT
.PP
During selection the user can ask for help at any moment. Besides, for
general help information the user may ask for specific help information
by inputting a specific help request.
.PP
The system reacts to the user with a clarifying text (refer to
\(sc\ 2.5).
.RT
.sp 1P
.LP
3.3.4
    \fIError correction aspects\fR
.sp 9p
.RT
.PP
The system can ask the user to correct his selection if this is not valid.
The response is given in the form of request output (refer to
\(sc\ 2.7).
.RT
.sp 1P
.LP
3.4
    \fIInformation entry through form filling\fR
.sp 9p
.RT
.PP
Form filling is a useful method of information entry when
flexibility is needed, for example when optional as well as mandatory items
of data are required for command execution or handling of data stored in
the
system.
.bp
.RT
.sp 1P
.LP
3.4.1
    \fIInformation entry\fR
.sp 9p
.RT
.PP
When this data entry procedure is to be used, the system first
outputs a form (in accordance with Figure\ 4/Z.323) that requires user input.
The form contains a list of parameters identified by parameter identities.
The parameter input fields are either empty or contain default values (see
Figure\ 9/Z.323). The form has to be filled in by entering the parameter
values required followed by an \*Qend of input indication\*U. For handling
data stored in the system, at least the key parameter values have to be
input in order to
identify the data record. For a read or a delete operation, this is sufficient.
For an add or modify operation more parameter values are required. They
may
partly be obtained by a previous read operation. Completion of the form is
indicated by an appropriate \*Qend of input indication\*U.
.PP
As many parameter values can be given as desired before an \*Qend of
input indication\*U. Parameter value input fields may be skipped if the
parameter is not relevant or the initial or existing value is appropriate.
Clarifying
text is output when a \*Qhelp request\*U is input. When the data input
by the form is not accepted by the system, a \*Qrequest output\*U is given
to indicate that
completion or correction of the data in the form is required. A sucessful
operation is followed by an \*Qinput acknowledgement\*U.
.PP
The \*Qend of input indication\*U can also be used to request a next page
if the form covers more that one screen. It can also be used to request
continuation with a new empty form of the same type after completion.
Mechanisms to control this capability are left for further study.
.RT
.LP
.rs
.sp 22P
.ad r
\fBFigure 9/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
3.4.2
    \fIForm output\fR
.sp 9p
.RT
.PP
The form output (see Figure 10/Z.323) may contain several types
of information:
.RT
.LP
    a)
    form identity;
.LP
    b)
    per parameter:
.LP
    \(em
    parameter identity,
.LP
    \(em
    parameter value input field,
.LP
    \(em
    supplementary information;
.LP
    c)
    additional information.
.bp
.LP
.rs
.sp 22P
.ad r
\fBFigure 10/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.PP
The above information can be displayed in fields and/or given by highlighting
techniques.
.PP
The \fIform identity\fR  | s displayed in a field at the head of the form.
It identifies the command, preferably in a concise meaningful manner, to
allow easy recognition of the nature of the form, and an optional identity
for
command reference.
.PP
The \fIparameter identity\fR  | is displayed in a field and contains the
parameter label and an optional parameter position which could be used as a
reference in a request output. The parameter label is a text string as
defined in Recommendation\ Z.314. The parameter position should be displayed
at the left side of this field.
.PP
The \fIparameter value input field\fR  | is an accessible field. Initially
this field is either empty and should be filled in by the user, or the
system may display in this field the default value which can be overwritten
by the
user.
.PP
The \fIsupplementary information\fR  | provides an explanation to the user,
if required, to aid input of the parameter value. It may give information
such as:
.RT
.LP
    \(em
    whether the parameter is optional;
.LP
    \(em
    in which form the value should be entered, e.g.,\ in
alphanumeric form.
.PP
The \fIadditional information\fR  | presents general information
to the user with respect to the whole form,\ e.g.,\ guidance on how to submit
the form to the system after finishing the input of parameter values.
.PP
The information applying to a particular parameter (parameter
identity, parameter value and supplementary information) should clearly be
associated with that parameter, i.e., co\(hylocated. The position of the
fields in the form should be consistent over the form. In any one area
of
application, they should be consistent from one form to another.
.PP
If punctuation is used for delimiting fields, the punctuation from the
appropriate direct information entry technique should be used.
.RT
.sp 1P
.LP
3.4.3
    \fIUser guidance\fR
.sp 9p
.RT
.PP
During inputting parameter values the user can ask for help at any moment.
Besides general help information he can ask for specific help
information by entering a specific help request. (Refer to \(sc\ 2.5.)
.bp
.RT
.sp 1P
.LP
3.4.4
    \fIError correction aspects\fR
.sp 9p
.RT
.PP
A consistency check on the set of parameter values in the form
should take place after completion. Acceptance or rejection is communicated
by \*Qinput acknowledgement\*U or \*Qrequest output\*U, see Figure\ 9/Z.323.
Validation of value ranges may take place per parameter value input so
as to identify range errors as early as possible. Request output as a result
of a per parameter
check is not shown in Figure\ 9/Z.323. The cursor and/or highlighting can be
used to indicate which value should be corrected. The user can correct the
indicated parameter values by changing the values and when complete,
re\(hyentering the form contents to the system. (Refer to \(sc\ 2.7.)
.RT
.sp 1P
.LP
3.5
    \fIDisplayed form\fR
.sp 9p
.RT
.PP
The displayed form can be used to show a form which has already
been filled in. The displayed form can only be used for reading and the
information cannot be changed by the user. It can appear as an input
acknowledgement.
.RT
.sp 2P
.LP
3.6
    \fIGuidelines for the design of menus and forms\fR
.sp 1P
.RT
.sp 1P
.LP
3.6.1
    \fIScope\fR
.sp 9p
.RT
.PP
This section deals with the human\(hymachine interface that utilizes the
advantage of the input and output facilities offered by menus and forms.
By using these guidelines, designers will get a more standardized layout
of the
various menus and forms.
.RT
.sp 1P
.LP
3.6.2
    \fIGeneral guidelines for menus and forms\fR
.sp 9p
.RT
.PP
Individual menus and forms should have an identity. Figures 7/Z.323 and\
10/Z.323.
.PP
Identities should be consistently positioned, preferably on top of the
menu or form. (Recommendation\ Z.323, \(sc\ 3.3.1 and \(sc\ 3.4.2.)
.PP
Menu and form layout in the window should be consistent throughout all
the menus and forms in a given system. (Recommendation\ Z.323, \(sc\ 3.3.1
and
\(sc\ 3.4.2.)
.PP
Each menu or form should ideally appear in its entirety, so that the user
is able to see all the items or parameters at once. If the entire menu
or form is not displayed in the window area, then an indication must be
given of where the user is in the menu or form.
.RT
.sp 2P
.LP
3.6.3
    \fIGuidelines for menus\fR
.sp 1P
.RT
.sp 1P
.LP
3.6.3.1
    \fIAppearance and organization of menus\fR
.sp 9p
.RT
.PP
A menu should give hierarchical groupings of logically related
items.
.PP
A hierarchy of menus should have the least number of levels possible considering
the last guideline of \(sc\ 3.6.2.
.PP
Menu items should have a clear and concise description of the choices available.
The selection identity should be displayed at the left side of this description.
.PP
To avoid errors, special care should be taken to organize and label
items in hierarchical menus in such a way that the scope of each item,
or the likely result of selecting it, is as clear as possible.
.RT
.sp 1P
.LP
3.6.3.2
    \fIMovement between hierarchical or multiple menus\fR
.sp 9p
.RT
.PP
If it is possible to go directly to the desired menu by combining menu\(hyitem
selection identities, then the system should prevent the bypass of
mandatory steps.
.PP
It should be possible to go backward through the hierarchy, step by
step without the necessity of entering the identity of the antecedent menu.
.PP
The option to return directly to the main (top) menu should generally be
offered.
.bp
.RT
.sp 2P
.LP
3.6.4
    \fIGuidelines for forms\fR
.sp 1P
.RT
.sp 1P
.LP
3.6.4.1
    \fIAppearance and organization of forms\fR
.sp 9p
.RT
.PP
Parameters should be organized into logically related groups. In
addition, it may be possible to organize these groups in a hierarchical
manner.
.PP
Within the primary requirement for good readability, the length of the
form should be minimized considering the last guideline of \(sc\ 3.6.2.
.PP
Parameter identities should follow the general guidelines for textual  data.
.RT
.sp 1P
.LP
3.6.4.2
    \fINavigation between input fields in forms\fR
.sp 9p
.RT
.PP
It should be possible to move the cursor between input fields by a single
operation, such as a keystroke. This means that it should be possible to
move the cursor to the next or preceeding field in a sequence, or in the
case of a form that contains logically related groupings of input fields,
it should be possible to jump forward and backwards between the groupings,
perhaps
skipping several fields.
.RT
.sp 1P
.LP
3.6.4.3
    \fIPresentation of error information about menus and forms\fR
.sp 9p
.RT
.PP
When errors are made they must be reported to the user in a manner that
is most informative, enabling the user to make the quickest recovery.
.PP
In some cases it is not advisable to report how to recover from the
error, e.g.,\ security reasons.
.PP
The location in the window for the error information should be
consistent thoughout all the menus and forms in a given system and should
clearly be associated with the menu item or the parameter concerned.
.RT
.sp 2P
.LP
\fB4\fR     \fBMonologue output\fR
.sp 1P
.RT
.PP
A monologue output is any output from the system which occurs
outside a dialogue. This includes output outside dialogue as described in
Recommendation\ Z.316, system status and alarm information, function key
labelling, date and time,\ etc. Usually, each type of monologue output
occurs in an appropriate window on the screen. The occurrence of a monologue
output may be accompanied by an audio signal or highlighting in order to
stimulate user
action, e.g.,\ on alarms. In general, it is not helpful to output information
on a VDT which is not immediately useful to the user.
.RT
.sp 1P
.LP
4.1
    \fIOutput outside dialogue\fR
.sp 9p
.RT
.PP
Output outside dialogue is a spontaneous output indicating a
certain event, e.g.,\ an alarm situation, or an output in response to a
previously entered command, e.g.,\ traffic measurement result. Output outside
dialogue should not normally disrupt a dialogue in progress. There are
several possible means of achieving this, e.g.,\ message waiting indicators.
.RT
.sp 1P
.LP
4.2
    \fISystem information\fR
.sp 9p
.RT
.PP
System information is information related to the status of the
system and may contain items such as:
.RT
.LP
    \(em
    system status indicators;
.LP
    \(em
    alarm indicators;
.LP
    \(em
    message waiting indicator.
.sp 1P
.LP
4.3
    \fIFunction key labels\fR
.sp 9p
.RT
.PP
Function key labels may be displayed in the display area to inform the
user as to what functions may be accessed via programmable function keys.
They may be displayed as characters or symbols and with various highlighting
techniques. It should be obvious to which function key each function key
label is associated.
.bp
.PP
Consistency should be applied when assigning labels to function keys so
that frequently occurring labels appear in the same position in the display
area.
.RT
.sp 2P
.LP
\fB5\fR     \fBTime\(hyout control inside dialogue\fR
.sp 1P
.RT
.PP
Subsection 5 of Z.317 applies except for the second time\(hyout in
which case the timing begins after a spontaneous menu output or ready
indication.
\v'1P'
.RT
.ce 1000
ANNEX\ A
.ce 0
.ce 1000
(to Recommendation Z.323)
.sp 9p
.RT
.ce 0
.ce 1000
\fBExamples of dialogue procedures\fR
.sp 1P
.RT
.ce 0
.LP
A.1
    \fIGeneral\fR
.sp 1P
.RT
.PP
In \(sc\ 3 of the body of this Recommendation (Dialogue procedure), a number
of dialogue elements have been described and Figure\ 4/Z.323 showing
how various inputs and outputs are related has been introduced.
.PP
The purpose of this annex is to clarify how the various elements
interact. This is done by showing in a number of examples how the interaction
between the user and the system appears to the user.
.PP
It is important to bear in mind that the examples are intended only to
illustrate some of the possibilities described in the dialogue procedure
in
\(sc\ 3 of the body of this Recommendation and that they are not to be
considered as Recommendations.
.PP
In the examples only three types of window areas are shown. These
are, from top to bottom: work window area, output window area, and input
window area.
.PP
The relative position of window areas in the examples is shown in
Figure A\(hy1/Z.323. The relative sizes of the window areas in this Figure are
not significant, nor are the lines used to delimit the windows. The actual
method of best distinguishing windows from each other is
terminal dependent.
.RT
.LP
.rs
.sp 14P
.ad r
\fBFigure A\(hy1/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.PP
It should be noted that help requests and input error handling are not
treated in the examples, i.e.,\ it is presumed that all commands and
directives are entered correctly. Each figure shows both the output from the
system and the following input made by the user. The user input is written
in italics in order to distinguish it from the system output.
.PP
Examples 1 though 5 show input of commands, and examples 6 though 8
illustrate data base input.
.bp
.RT
.sp 1P
.LP
A.2
    \fIExample\ 1\fR
.sp 9p
.RT
.ce
\fBH.T. [T1.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | c.
 {
1
The user knows the command code as well as the parameters and enters the entire command by direct information
entry.
 }     {
\fIrien\fR
\fIrien\fR
 }
    \fIrien\fR     {
< \fICOM2: PAR 1=5, PAR 2=10;\fR
 }
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T1.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 3
.ce
\fBH.T. [T2.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | c
^  | l.
 {
2
An acceptance output is displayed and the system is ready for the next input.
 }     {
\fIrien\fR
\fIrien\fR
 }
    Command executed    <
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T2.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 3
.rs
.sp 20P
.ad r
\fBFigure A\(hy2/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
A.3
    \fIExample\ 2\fR
.sp 9p
.RT
.ce
\fBH.T. [T3.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | l.
 {
1
The user knows the command code but not the parameters. He
enters a directive in the form of the command
code.
 }     {
\fIrien\fR
\fIrien\fR
 }
    \fIrien\fR    \ < \fICOM 3\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T3.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 6
.ce
\fBH.T. [T4.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | c.
 {
2
A form output is displayed. The form is filled and entered. Note that the ready indication is not displayed during form filling. The equal sign is not mandatory.
 }     {
\ \ COM 3
\ \ PAR 1 = \fI560424\fR
\ \ PAR 2 = \fIXYZ\fR
\ \ PAR 3 = \fI100\fR
\ \ PAR 4 = \fIAAAAAA\fR
 }
    \fIrien\fR    \fIrien\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T4.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 6
.ce
\fBH.T. [T5.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | l
^  | l.
 {
3
An acceptance output is displayed in the form of a result and the system is ready for the next input. Note that the output in this example is so spacious that the output window area has increased at the expense of the
work window area.
 }     {
Result
\(em
\(em
\(em
\(em
\(em
\(em
 |
 |
 |
 |
 |
\(em
 |
 |
 |
 |
 |
\(em
 |
 |
 |
 |
 |
 }
     {
\(em
 |
 |
 |
 |
 |
\(em
 |
 |
 |
 |
 |
\(em
 |
 |
 |
 |
 |
\(em
 |
 |
 |
 |
 |
 }    \ <
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T5.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 20P
.ad r
\fBFigure A\(hy3/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.sp 1P
.LP
A.4
    \fIExample\ 3\fR
.sp 9p
.RT
.ce
\fBH.T. [T6.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | l.
 {
1
A spontaneous menu output is automatically displayed. The
menu items refer to other menus on a lower and more specific level. The user
chooses the appropriate menu and enters the associated selection
identity.
 }     {
\ \ Menu
\ \ 1.\ Menu 1
\ \ 2.\ Menu 2
\ \ 3.\ Menu 3
\ \ 4.\ Menu 4
 }
    \fIrien\fR    \ < \fI1\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T6.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.ce
\fBH.T. [T7.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | l.
 {
2
A new menu output is displayed in this case the menu items
represent command codes. The user selects the wanted command code by entering the associated selection identity.
 }     {
\ \ Menu 1
\ \ 1.\ COM 1
\ \ 2.\ COM 2
\ \ 3.\ COM 3
 }
    \fIrien\fR    \ < \fI1\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T7.323], p. \fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T8.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | l.
 {
3
A form output is displayed. The form is filled and entered by the user.
 }     {
\ COM 1
\ PAR 1 = \fI1234\fR
\ PAR 2 = \fIGIGA\fR
\ PAR 3 = \fI9999\fR
\ PAR 4 = \fI500\fR
\ PAR 5 = \fIABCDE\fR
 }
    \fIrien\fR    \fIrien\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T8.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.ce
\fBH.T. [T9.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | l.
 {
4
An acceptance output is displayed together with the
spontaneous menu. The system is ready for the next input.
 }     {
\ \ Menu
\ \ 1.\ Menu 1
\ \ 2.\ Menu 2
\ \ 3.\ Menu 3
\ \ 4.\ Menu 4
 }
    \ \ Command executed    \ <
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T9.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.rs
.sp 20P
.ad r
\fBFigure A\(hy4/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
A.5
    \fIExample\ 4\fR
.sp 9p
.RT
.ce
\fBH.T. [T10.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | l.
 {
1
The user enters a directive in the form of a menu identity in order to shortcut to a certain menu.
 }     {
\fIrien\fR
\fIrien\fR
 }
    \fIrien\fR    \ < \fIMENU 3\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T10.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.ce
\fBH.T. [T11.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l.
 {
2
A menu output containing items referring to other menus is
displayed and a selection identity is entered.
 }     {
\ \ Menu 3
\ \ 1.\ Menu 31
\ \ 2.\ Menu 32
\ \ 3.\ Menu 33
 }
    \ < \fI3\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T11.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.ce
\fBH.T. [T12.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(72p) , ^  | l
^  | l.
 {
3
The selected menu is displayed. The items in the menu
represent command codes. The user recognizes the command code and then
remembers the parameters. The entire command is entered directly.
 }     {
\ \ Menu 33
\ \ 1.\ COM 1
\ \ 2.\ COM 2
\ \ 3.\ COM 3
\ \ 4.\ COM 4
 }
    \fIrien\fR     {
\ <\ \fICOM\ 2: PAR\ 1\ =\ 5, PAR\ 2\ =\ 10;\fR
 }
_
.T&
lw(72p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T12.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.ce
\fBH.T. [T13.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | l.
 {
4
An acceptance output is displayed and the system is ready for the next input.
 }     {
\fIrien\fR
\fIrien\fR
 }
    \ \ Command executed    \ <
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T13.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 19P
.ad r
\fBFigure A\(hy5/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.sp 1P
.LP
A.6
    \fIExample\ 5\fR
.sp 9p
.RT
.ce
\fBH.T. [T14.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | l.
 {
1
A spontaneous menu output is automatically displayed. The
user already knows the command code and enters it.
\fINote\fR
\ \(em\ Cursor positioning is used as a ready indication in this example in
place of the \*Q<\*U character (see
Recommendation Z.317, \(sc 3.2.2.1).
 }     {
\ \ Menu
\ \ 1.\ Menu 1
\ \ 2.\ Menu 2
\ \ 3.\ Menu 3
\ \ 4.\ Menu 4
 }
    \fIrien\fR    \ \ \fICOM 4\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T14.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.ce
\fBH.T. [T15.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | c.
 {
2
This command requires two forms to be filled in. The first
form output is displayed. The user fills in the parameters and enters the
form.
 }     {
\ \ COM 4
\ \ PAR 1 = \fI6543\fR
\ \ PAR 2 = \fIGHIJK\fR
\ \ PAR 3 = \fI333\fR
\ \ PAR 4 = \fIXXXXXXX\fR
 }
    \fIrien\fR    \fIrien\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T15.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T16.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | c.
 {
3
The second form output is displayed and the user fills in the rest of the parameters a
nd enters the form.
 }     {
\ \ COM 4
\ \ PAR 5 = \fIAEFE\fR
\ \ PAR 6 = \fILES\fR
\ \ PAR 7 = \fIDIDIT\fR
 }
    \fIrien\fR    \fIrien\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T16.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.ce
\fBH.T. [T17.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | l.
 {
4
An acceptance output is displayed. The system is ready for
the next input.
 }     {
\ \ Menu
\ \ 1.\ Menu 1
\ \ 2.\ Menu 2
\ \ 3.\ Menu 3
\ \ 4.\ Menu 4
 }
    \ \ Command executed    \fIrien\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T17.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.rs
.sp 19P
.ad r
\fBFigure A\(hy6/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
A.7
    \fIExample\ 6\fR
.sp 9p
.RT
.ce
\fBH.T. [T18.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | l.
 {
1
The user knows the data set and the action to be applied, and enters a directive in the form of a form identity.
\fINote\fR
\ \(em\ Cursor positioning is used as a ready indication in this example in
place of the \*Q<\*U character (see Recommandation Z.317, \(sc\ 3.2.2.1).
 }     {
\fIrien\fR
\fIrien\fR
\fIrien\fR
\fIrien\fR
\fIrien\fR
\fIrien\fR
 }
    \fIrien\fR    \ \ < \fIREAD\(hySET X\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T18.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 5
.ce
\fBH.T. [T19.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | c.
 {
2
A form output is displayed. The key parameter is filled and entered.
 }     {
\ \ READ\(hySET X
\ \ PAR 1 = \fI560424\fR
\ \ PAR 2 =
\ \ PAR 3 =
\ \ PAR 4 =
 }
    \fIrien\fR    \fIrien\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T19.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 5
.ce
\fBH.T. [T20.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | c.
 {
3
An acceptance output is the displayed form in the output
window area. The system is ready for the next input.
 }     {
\ \ READ\(hySET X
\ \ PAR 1 = \fI560424\fR
\ \ PAR 2 = \fIXYZ\fR
\ \ PAR 3 = \fI100\fR
\ \ PAR 4 = \fIAAAAAA\fR
 }
    \fIrien\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T20.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 19P
.ad r
\fBFigure A\(hy7/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
A.8
    \fIExample\ 7\fR
.sp 9p
.RT
.ce
\fBH.T. [T21.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | l.
 {
1
A spontaneous menu output is automatically displayed. The
menu items refer to other menus on a lower and more specific level. The user
chooses the appropriate menu and enters the associated selection
identity.
 }     {
\ \ Menu
\ \ 1.\ Menu 1
\ \ 2.\ Menu 2
\ \ 3.\ Menu 3
\ \ 4.\ Menu 4
 }
    \fIrien\fR    \ < \fI3\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T21.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.ce
\fBH.T. [T22.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | l.
 {
2
A new menu output is displayed. In this case the menu items represent command codes. The user selects the desired action by entering the
associated selection identity.
 }     {
\ \ Menu 3
\ \ 1.\ Data Set A
\ \ 2.\ Data Set B
\ \ 3.\ Data Set C
\ \ 4.\ Data Set D
 }
    \fIrien\fR    \ < \fI1\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T22.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T23.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | l.
 {
3
A new menu output is displayed. In this case the menu items represent actions. The user selects the wanted action by entering the
associated selection identity.
 }     {
\ \ Data set A
\ \ 1.\ Add
\ \ 2.\ Delete
\ \ 3.\ Change
\ \ 4.\ Read
 }
    \fIrien\fR    \ < \fI1\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T23.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 5
.ce
\fBH.T. [T24.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | l.
 {
4
A form output is displayed. The form is filled and entered by the user.
 }     {
\ ADD\(hySET A
\ PAR 1 = \fI1234\fR
\ PAR 2 = \fIGIGA\fR
\ PAR 3 = \fI9999\fR
\ PAR 4 = \fI500\fR
\ PAR 5 = \fIABCDE\fR
 }
    \fIrien\fR    \fIrien\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T24.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 5
.ce
\fBH.T. [T25.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | l.
 {
5
An acceptance output is displayed together with the
spontanteous menu. The system is ready for the next input.
 }     {
\ \ Menu
\ \ 1.\ Menu 1
\ \ 2.\ Menu 2
\ \ 3.\ Menu 3
\ \ 4.\ Menu 4
 }
    \ \ Command executed    \ <
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T25.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 19P
.ad r
\fBFigure A\(hy8/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
A.9
    \fIExample\ 8\fR
.sp 9p
.RT
.ce
\fBH.T. [T26.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | l.
 {
1
A spontaneous menu output is automatically displayed. The
user already knows the combination of data set name and action and enters
it.
 }     {
\ \ Menu
\ \ 1.\ Menu 1
\ \ 2.\ Menu 2
\ \ 3.\ Menu 3
\ \ 4.\ Menu 4
 }
    \fIrien\fR    \ < \fIADD\(hySET Y\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T26.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.ce
\fBH.T. [T27.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | c.
 {
2
This data set requires two forms to be filled in per record. The first form output is displayed. The user fills in the parameters (data
attibutes) and enters the form.
 }     {
1 of 2\
\ \ ADD\(hySET Y
\ \ PAR 1 = \fI6543\fR
\ \ PAR 2 = \fIGHIJK\fR
\ \ PAR 3 = \fI333\fR
\ \ PAR 4 = \fIXXXXXXX\fR
 }
    \fIrien\fR    \fIrien\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T27.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T28.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | c.
 {
3
The second form ouput is displayed and the user fills in the rest of the parameters and enters the form.
 }     {
2 of 2\
\ \ ADD\(hySET Y
\ \ PAR 5 = \fIAEFE\fR
\ \ PAR 6 = \fILES\fR
\ \ PAR 7 = \fIDIDIT\fR
 }
    \fIrien\fR    \fIrien\fR
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T28.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.ce
\fBH.T. [T29.323]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(150p) | lw(66p) , ^  | l
^  | l.
 {
4
An acceptance output is displayed. The system is ready for
the next input.
 }     {
\ \ Menu
\ \ 1.\ Menu 1
\ \ 2.\ Menu 2
\ \ 3.\ Menu 3
\ \ 4.\ Menu 4
 }
    \ \ Command executed    \ <
_
.T&
lw(66p) .
.TE
.nr PS 9
.RT
.ad r
\fBTable [T29.323], p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.rs
.sp 19P
.ad r
\fBFigure A\(hy9/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce 1000
ANNEX\ B
.ce 0
.ce 1000
(to Recommendation Z.323)
.sp 9p
.RT
.ce 0
.ce 1000
\fBExamples of windows\fR
.sp 1P
.RT
.ce 0
.LP
B.1
    \fIGeneral\fR
.sp 1P
.RT
.PP
In \(sc\ 2.3.4 of the body of this Recommendation a description of
windows and window areas are given. (See also Figures\ 2/Z.323 to\ 5/Z.323).
.PP
The purpose of this annex is to provide some examples of the use of
windows and window areas.
.PP
It is important to bear in mind that the examples are intended to
illustrate the use of windowing only, and that they are not to be considered
as Recommendations.
.PP
In these examples windows are outlined by double\(hyline boundaries and
window areas are outlined with a single\(hyline boundary. This method of
depicting windows and window areas is chosen as an example that can be
shown easily in
print. Actual methods used to distinguish windows will be terminal
dependent.
.RT
.sp 1P
.LP
B.2
    \fITerminal supervision\fR
.sp 9p
.RT
.PP
This window is related to an application supervising the terminal the user
is using. It may contain information about the terminal, about
terminal directives (e.g.,\ \*Qwindow state change\*U function key), about
active
connections between the terminal and applications,\ etc. The window contains
two window areas:
.RT
.LP
    \(em
    general information;
.LP
    \(em
    output.
.LP
.rs
.sp 25P
.ad r
\fBFigure B\(hy1/Z.323, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
B.3
    \fIIdentification\fR
.sp 9p
.RT
.PP
This window is related to an application managing the terminals
which are local to the site the terminal is linked to. This application
performs access connections to terminals with different applications. The
window contains three window areas:
.RT
.LP
    \(em
    general information;
.LP
    \(em
    work;
.LP
    \(em
    output.
.LP
.rs
.sp 13P
.ad r
\fBFigure B\(hy2/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.PP
In this example, at any given time, the work window area is
dedicated to menu/form input.
.sp 1P
.LP
B.4
    \fIDialogue\fR
.sp 9p
.RT
.PP
This window is related to a site operation and maintenance
application. It contains four window areas:
.RT
.LP
    \(em
    general information;
.LP
    \(em
    work;
.LP
    \(em
    input;
.LP
    \(em
    output.
.LP
.rs
.sp 13P
.ad r
\fBFigure B\(hy3/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.PP
In this example, not all window areas are simultaneously visible. Work
(menu/form) and input window areas are exclusive of each other. The user
can replace one of these displayed window areas by the other one through
the
use of function keys.
.bp
.sp 1P
.LP
B.5
    \fISystem status\fR
.sp 9p
.RT
.PP
This window is used to display alarm indicators by an application managing
exchange alarms. It contains two window areas:
.RT
.LP
    \(em
    header;
.LP
    \(em
    status.
.LP
.rs
.sp 47P
.ad r
\fBFigure B\(hy4/Z.323, p.  \fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp