SIST EN ISO 9241-15:2001

SLOVENSKI STANDARD
01-junij-2001
Ergonomske zahteve za pisarniško delo s slikovno zaslonsko opremo - 15. del:
Dialog z uporabo ukazov (ISO 9241-15:1997)
Ergonomic requirements for office work with visual display terminals (VDTs) - Part 15:
Command dialogues (ISO 9241-15:1997)
Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten - Teil 15:
Dialogführung mittels Kommandosprachen (ISO 9241-15:1997)
Exigences ergonomiques pour travail de bureau avec terminauxa écrans de visualisation
(TEV) - Partie 15: Dialogues de type langage de commande (ISO 9241-15:1997)
Ta slovenski standard je istoveten z: EN ISO 9241-15:1997
ICS:
13.180 Ergonomija Ergonomics
35.180 Terminalska in druga IT Terminal and other
periferna oprema IT peripheral equipment
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

INTERNATIONAL IS0
STANDARD 92414 5
First edition
1997-12-15
Ergonomic requirements for office work
with visual display terminals (VDTs) -
Part 15:
Command dialogues
Exigences ergonomiques pour travail de bureau avec terminaux 2 hrans
de visualisation (TEV)
Partie 15 : Dialogues de type langage de commande
Reference number
IS0 9241-I 5: 1997(E)
IS0 9241=15:1997(E)
Page
Contents
1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
..................................................................................... 1
2 Definitions
.......................................................... 3
3 Application of IS0 9241-15
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4 Structure and syntax
5 Command representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
................................................ 8
6 Input and output considerations
7 Feedback and help . 10
Annex A (informative) Sample procedure for assessing
applicability and adherence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*. 24
Annex B (informative) Bibliography
0 IS0 1997
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced
or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm, without permission in writing from the publisher.
International Organization for Standardization
Case postale 56 l CH-1211 Geneve 20 l Switzerland
Internet central @ iso.ch
x.400 c=ch; a=400net; p=iso; o=isocs; s=central
Printed in Switzerland
ii
@ IS0 IS0 9241-l 5:1997(E)
Foreword
IS0 (the International Organization for Standardization) is a worldwide
federation of national standards bodies (IS0 member bodies). The work of
preparing International Standards is normally carried out through IS0
technical committees. Each member body interested in a subject for which
a technical committee has been established has the right to be represented
on that committee. Enternational organizations, governmental and non-
governmental, in liaison with ISO, also take part in the work. IS0
collaborates closely with the International Electrotechnical Commission
(IEC) on all matters of electrotechnical standardization.
Draft International Standards adopted by the technical committees are
circulated to the member bodies for voting. Publication as an International
Standard requires approval by at least 75 % of the member bodies casting
a vote.
International Standard IS0 9241-15 was prepared by Technical Committee
lSO/TC 159, Ergonomics, Subcommittee 4, Ergonomics of human-system
interaction.
IS0 9241 consists of the following Parts, under the general title Ergonomic
requirements for office work with visual display terminals (VDTs) -
- Part I: General introduction
- Part 2: Guidance on task requirements
- Part 3: Visual display requirements
Part 4: Keyboard requirements
- Part 5: Workstation layout and postural requirements
- Part 6: Environmental requirements
- Part 7: Requirements for display with reflections
Y-- Part 8: Requirements for displayed colours
Part 9: Requirements for non-keyboard input devices
- Part IO: Dialogue principles
- Part 1 I: Guidance on usability
- Part 12: Presentation of information
- Part 13: User guidance
. . .
III
IS0 9241=15:1997(E)
- Part 14: Menu dialogues
- Part 15: Command dialogues
- Part 16: Direct manipulation dialogues
- Par? 17: Form-filling dialogues
Annexes A and B of this part of IS0 9241 are for information only.

@ IS0 IS0 9241=15:1997(E)
Introduction
IS0 9241 covers both the hardware and software ergonomic aspects of the
use of visual display terminals. The description of the individual parts of IS0
9241, their interrelationships, and a description of the expected users of the
parts is described in IS0 9241-1.
IS0 9241-15 is concerned with the ergonomic design of command dialogues.
In command dialogues, users input, by recall, either complete or abbreviated
command phrases as required by the command language syntax, and the
computer performs the actions associated with the commands and their
parameters.
IS0 9241-15 serves the following types of user of this part of IS0 9241:
a) The user-interface designer, who will apply IS0 9241-15 during the
development process.
b) The buyer, who will reference IS0 9241-15 during the product
procurement process.
c) Evaluators responsible for ensuring that products meet the
recommendations in IS0 9241-I 5.
d) Designers of user-interface development tools to be
bY
interface desig ners.
e) End-users who will gain from the potential benefits provided by this
part of IS0 9241.
The ultimate beneficiary of this part of IS0 9241 will be the end-user at the
VDT. It is the needs of these users that provide the ergonomic
recommendations in IS0 9241-15. Although it is unlikely that the end-user
will read this part of IS0 9241 or even know of its existence, its application
should provide user interfaces that are more usable, consistent and that
enable greater productivity.
In order to apply IS0 9241-15 within the overall context of the ergonomic
requirements for human-system interaction, it is suggested that users be
familiar with the following parts of 9241:
IS0 9241-I Ergonomic requirements for office work with visual display
terminals (VDTs) - Part 1: General introduction
IS0 9241-2 Ergonomic requirements for office work with visual display
terminals (VDTs) - Pan 2: Guidance on task requirements
IS0 9241-I 0 Ergonomic requirements for office work with visual display
terminals (VDTs) - Part IO: Dialogue principles
V
IS0 9241=15:1997(E) @ IS0
IS0 9241-I 3 Ergonomic requirements for office work with visual display
terminals (VDTs) -Part 13: User guidance
IS0 9241-15 consists of a number of recommendations, some of which are
conditional, concerning command dialogues. Conditional recommendations
are recommendations which should be met within the specific context for
which they are relevant (e.g. particular kinds of users, tasks, environments,
technology). These recommendations were developed primarily by reviewing
the existing relevant literature and empirical evidence, then generalizing and
formulating this work into recommendations for use by the interface designer
and/or evaluator. Sources for the individual recommendations are listed in
Annex B.
Designers and evaluators using IS0 9241-15 need to know that they are
developing an interface that will meet the recommendations provided therein.
Likewise, the buyer needs a means to determine how a product matches the
recommendations in IS0 9241-15. The elements can be tailored due to the
“if .
then” structure in IS0 9241-15. Additionally, it is not the intent of
IS0 9241-15 that every recommendation should be applied, only those that
are relevant.
The application of this part of IS0 9241 is expected to improve the overall
quality of the command language, but IS0 9241-15 (like any other standard)
will not guarantee the quality of the interface. Quality depends on specific
usability criteria as set by the user, buyer or other command-dialogue
consumer which may include specifications based on this part of IS0 9241.
It should be noted that IS0 9241-10 describes dialogue principles that are
relevant for the design of command dialogues. These principles should
provide the designer and evaluator with additional information concerning the
ergonomic rationale for the various recommendations in IS0 9241-15 and,
therefore, assist in making tradeoffs. However, it may be necessary to base
tradeoffs on other considerations as well.
VI
INTERNATIONAL STANDARD @ IS0 IS0 9241=15:1997(E)
Ergonomic requirements for office work with visual display
terminals (WITS) -
Part 15:
Command dialogues
1 Scope
This part of IS0 9241 provides recommendations for command dialogues used to accomplish typical office tasks using
visual display terminals (VDTs). Command dialogues are sequences of instructions provided by the user to the system
which, when processed, result in associated system actions. Users input (from recall, rather than selecting from a
menu) complete or abbreviated command phrases (e.g. mnemonics, letters, function keys, hot keys in the order
required by the command language syntax and the computer performs the activities initiated by the command(s) and
their associated parameters.
Interface design depends upon the task, the user, the environment, and the available technology. Consequently,
IS0 9241-15 cannot be applied without a knowledge of the design and use context of the interface and it is not
intended to be used as a prescriptive set of rules to be applied in their entirety. Rather, it assumes that the designer
has proper information available concerning task and user requirements and understands the use of available
technology (this may require consultation with a qualified ergonomics professional as well as empirical testing with real
users).
IS0 9241-15 applies to the use of command dialogues, either in conjunction with other dialogues (e.g. menus, direct
manipulation) or as the primary dialogue technique (e.g. in the case of “dumb terminals” or where high speed is
required in a particular application). In addition, this part of IS0 9241 provides recommendations for those “key”
commands (i.e. function keys and hot keys) which represent commands within a command dialogue. If the command
functions are evident from the nature of their representation (e.g. pictorial icons) and invoking these functions does not
require memory on the part of the user, this would not be considered a command dialogue according to IS0 9241-15.
Commands can be accessed through other dialogue techniques (e.g. menu options, forms, direct manipulation).
However, these methods do not require recall on the part of the user and will be excluded from this part of the standard
and will be dealt with in other parts. It also should be noted that IS0 9241-15 does not provide guidance for dialogues
which use “natural” language.
2 Definitions
For the purposes of this part of IS0 9241, the following definitions apply:
2.1 argument
Independent variable (including object) used in a command phrase to modify or direct the action of a command.
NOTE Arguments often include parameters.
2.2 command
Whole word, abbreviation, or string of words representing actions requested of the system.

@ IS0
ISO 9241=15:1997(E)
2.3 command dialogue; command language
Command set(s), phrases, structure and syntax associated with a specific interaction of a user with a computer
system by means of commands.
2.4 command dialogue structure
Logical structure of the command dialogue (and associated phrases).
2.5 command queuing (stacking)
Accumulation of a series of command phrases in order to allow their input into the system as a group rather than
require that they be entered and executed one at a time.
2.6 command phrase
Phrase including the command (words or their abbreviations) and associated separators and arguments
(parameters).
EXAMPLE: [Command word] [separator] [argument11 [separator] [argument21 [terminator]
2.7 command set
All of the commands available to the user to perform a given task in a particular application context.
2.8 command syntax
Sequential and other procedural requirements for inputting the components into command phrases.
2.9 command word (name)
Word (or name) used as a command in the command dialogue and representing actions requested from the
system.
2.10 command word abbreviation
Shortened version of a command word which is recognizable by the computer as representing the command.
NOTE Such abbreviations may be single or multiple letters of the command word.
2.11 hot keys
Keys, other than numbered function keys (i.e. Fl, F2, etc.), not normally used for data entry such as modifier keys
(e.g. Ctrl, AN), or key combinations (e.g. Ctrl/c) which execute immediately without the need for any additional
operations.
2.12 keyword
Word in a command phrase identifying a particular argument class (e.g. type font).
2.13 modifier
Argument that alters or limits the action of a command.
2.14 parameter
Value used in conjunction with a keyword to modify the action of a command or argument.
2.15 separator
String of one or more characters, or a pause (for voice), used to separate or organize elements in the command
phrase and between command phrases.

@ IS0 IS0 9241=15:1997(E)
3 Application of IS0 9241-15
3.1 Design of command dialogue
In a command dialogue, the command phrase is entered by the user in the specific syntactic arrangement “understood”
by the computer. The computer acknowledges receiving the command, indicates whether it is an acceptable command
for the current processing state, indicates whether the associated parameters are appropriate for both the command
and the current processing state, and if so, performs the requested activities and/or provides the requested outputs.
Command phrases may be entered into the computer in a number of different ways, e.g. by means of a “command
line”, a dialogue box, or by voice input.
l
Commands may be:
a) Whole words, or strings of words, separated by blanks (pauses, in the case of voice input) or other delimiters,
indicating syntax to the computer.
b) Single or multiple letter abbreviations.
Dialogue design determines the way in which a user is guided by the system to make inputs and influences the amount
of control the user has over the dialogue. Command dialogues should be designed to support the user in his/her actual
work without being bothered by additional work caused by system peculiarities as well as enabling the user to become
well-informed and to keep in control of the flow of work (see also IS0 9241-10). Such design goals have to be
considered in designing command structure and syntax, command representations, command input and output
specifications, and feedback and help mechanisms.
Application of IS0 9241-15 to design and evaluate a system or product requires that the person applying the standard
has an understanding of the intended users, their environment and their tasks.
User tasks should be listed and the
most frequent and important tasks should be explicitly identified. In applying the recommendations, it also is important
to consider general laws about human perception, identification and discrimination of information, and psychomotor
skills involved in keying in commands.
3.2 Appropriateness of command dialogue
Command dialogues are especially appropriate for one or more of the following conditions, which have been grouped
to reflect user and task issues. The applicability of command dialogues becomes greater as more conditions are met.
.
a) User characteristics
1) Users have good typing skills (if users key in the commands).
2) Users will use the system frequently.
3) Users will receive training on using the command language.
4) Users are familiar with computer technology and command languages.
b) Task characteristics
I) It is not possible to predict the choices of actions that the user may require in the dialogue.
2) Options and/or data may be entered in an arbitrary order.
3) Rapid selection or access to specific system functions is required (in an airline reservation system for example).
4) Extendibility (i.e. creation of new commands, or chains of commands, to suit new situations) is required.
3.3 Applying the recommendations
General ergonomic design objectives are provided in each major subclause of clauses 4 through 7. The individual
recommendations aimed at achieving these objectives should be applied within the specific context for which they are
relevant (e.g. particular kinds of users, tasks, environments, technology). The format for the individual
recommendations is: statement of the recommendation, example (if appropriate), and notes (if appropriate). Examples
provided for the various recommendations generally depict an implementation that embodies the recommendation.
Some examples also indicate preferred solutions.
@ IS0
IS0 9241=15:1997(E)
Individual recommendations should be evaluated for their applicability and, if judged to be applicable, should be
implemented in the relevant command dialogue unless there is evidence that to do so would cause deviation from the
design objectives or would result in an overall degradation in usability. When determining applicability, the
recommendations generally should be evaluated in the order presented in the relevant clause or subclause. In judging
met, evaluators should evaluate the product or observe
whether applicable recommendations have been
representative users of the product in the context of accomplishing the user’s tasks via the command dialogue system.
Sample procedures which support the determination of applicability and for judging whether a recommendation has
been followed are provided in Annex A.
3.4 Evaluation of products
re used in establishing
If a product is claimed to have met the applicable recommendations in IS0 9241-15, the procedt
evel of specification of
requirements for, developing, and/or evaluating the command dialogue shall be specified. The
the procedure is a matter of negotiation between the involved parties.
1 this part of IS0 9241.
Annex A provides a sample procedure that can be used to specify applicability and adherence tc
A, or develop a comparable set
Users of this International Standard can either utilize the procedures provided in Annex
of procedures tailored to their particular development and/or evaluation environment.
4 Structure and syntax
4.1 General
The command language should be designed such that users enter commands in a manner which is natural or familiar
to the user without concern for how the computer will process the commands to produce the output (i.e. the command
language should reflect the user’s needs rather than the computer process and the syntax structure should be
consistent with user expectations, task requirements and the input media).
4.2 Internal consistency
The command language should be internally consistent so commands with the same name, function in the same way
throughout the application regardless of the context. Commands that do the same thing should have the same name.
NOTE This does not exclude the use of synonyms where appropriate.
4.3 Command macros
If sequences of command words or command phrases are used frequently, users should be allowed to create and use
higher level commands (macros) for these sequences.
NOTE Macro commands should follow the same recommendations as commands.
4.4 Argument structures
Command phrases should be structured to minimize the complexity of arguments.
a) Long lists - If argument lists are long (more than 8 arguments), then additional command names should be
created, functions should be combined under single arguments, or lists should be broken into some logical
functional groupings.
Dependencies -
Dependencies between arguments of a command should not dramatically change the meaning of
the command phrase.
EXAMPLES: A dialogue uses:
Command “Quit - filename” to save data to the file named filename
Command “Cancel” to cancel without saving (instead of the more complex “Quit -c”)

@ IS0 IS0 9241=15:1997(E)
4.5 Syntax structure
a) Appropriateness for modality - The syntax structure of the command phrases should be appropriate for the input
modality (e.g. voice, typed input, gestures).
EXAMPLE: Voice input is used exclusively and the syntax is completely consistent with spoken language.
b) Consistency within modality - Syntax should be consistent within a given modality.
For a screen-based command dialogue, the object the action (i.e., action - object syntax) throughout
EXAMPLE:
application.
c) Consistency across modalities - Syntax should be consistent across modalities as much as possible.
EXAMPLE: Voice is used as well as typed input for commands in an application and the syntax is object - action for both
modalities.
4.6 Command separation
If the input of multiple commands is allowed, a simple and consistent method to separate commands should be used:
a) Blanks - If system constraints do not require the use of a specific separator, blanks should be used rather than
punctuation marks to separate commands.
b) Standard symbol - If system constraints require a separator other than blanks to distinguish separate stacked
commands, a simple standard symbol should be used consistently.
EXAMPLE: Using the slash (/) in the sequence of command words “SORT/FORMAT/PRINT”.
4.7 Language correspondence
Command structure (semantics and syntax) should correspond to the terminology and data organization familiar or
natural to the user.
EXAMPLE: The rules for natural language syntax (e.g. English, French) are applied in designing a query language.
4.8 Command arguments
Command arguments should be easy for the user to specify and to relate to the commands that they modify.
NOTE In some cases, it may be appropriate to represent arguments as names rather than single letters.
4.8.1 Command element linkage
The command dialogue should be structured so that the relationship between the command phrase elements is clear.
EXAMPLE: Print pages=1 -15 copies=2.
4.8.2 Argument formats
If appropriate to the task, keyword formats (parameters designated by argument identifiers that precede them) should
be used rather than positional formats (parameters designated by their sequential position in the argument string
following the command).
EXAMPLE 1 (Keyword format): change shape=round color=red size=4
EXAMPLE 2 (Positional format): change round red 4
4.8.3 Placement of optional argument
If keyword formats are not used, optional arguments should be placed at the end of the arguments list.
@ IS0
IS0 9241=15:1997(E)
4.8.4 Separation of arguments
a) Blank space - If blanks are allowed, a variable number of blanks should be allowed between command elements.
parate arguments,
b) Other separators - If system constraints require separato rs other than blanks to distinguish se
a simple standard symbol sh ould be use d consistently.
EXAMPLE: Using the comma (,) in the command phrase “print fileA,fileB,fileC”.
4.9 Quantifiers
The use of imprecise or unnecessary quantifiers should be avoided in a command dialogue.
NOTE In query languages, “few” or “many” are imprecise and users tend not to understand what these terms mean.
5 Command representation
5.1 Command names
5.1 .l General
Command names should be easily related to their function, generally stated as verbs (usually in imperative form), be
easily remembered by users, and be consistent with the user’s task requirements, experience and language usage.
5.1.2 Distinctiveness
Command names should be distinctive.
Distinctive meaning - Command names should be semantically distinct and unambiguous.
a)
distinct than add and remove (i.e., add and remove
EXAMPLE: In English, the words insert and are more semantically
typically have many different interpretations).
b) Specific meaning - Command names whose meanings are specific or constrained should be used rather than those
that are more general.
EXAMPLE: Use replace rather than change.
Visual/auditory similarity - Command names should be avoided that look or sound similar but have different
C)
meanings.
EXAMPLE: In English, store and restore should be avoided because they have different meanings but sound similar.
d) Congruent command pairs - If command operations have inverses or counterparts, congruent pairs of commands
for these operations should be provided.
EXAMPLE: read/write, open/close, yes/no.
5.1.3 User orientation
Command names should be chosen that are consistent with the user’s experience and correspond to the user’s
operational language.
NOTE If there are multiple user groups, it may be important to provide different sets of command names for these different
groups.
5.1.4 Emotional content
Words selected as command words should be emotionally neutral.
EXAMPLE: In English use “cancel” instead of “abort” and use “delete” rather than “kill”.

@ IS0 IS0 9241=15:1997(E)
5.1.5 Command word length
If command input is typed, command words should generally not exceed seven characters.
rule when such
NOTE 1 It may be appropriate to use command words which exceed the seven-character words would be
abbreviation .g. “allocate” in
more natural than an English, “einfugen” in German).
(e
NOTE 2 See recommendations on abbreviations (5.2) for long command words.
5.1.6 Suffixes and prefixes
Command words should not incorporate unnecessary suffixes or prefixes.
EXAMPLE: In English, delete rather than deleting, deleted, or deletes.
5.2 Abbreviations
5.2.1 General
If users must type commands, they should be able to use abbreviations instead of typing complete commands.
abbreviations should be
If it is appropriate to the task to provide command abbreviations, these obvious to the user,
easily remembered, and facilitate command input.
and name may be displayed
NOTE If the command input is an abbreviation and system constraints allow, the “whole” comm
d language)
prior to, or simultaneous with, execution (especia .Ily during learning the comman
5.2.2 Abbreviation rules
a) Simple rule - If command names are shortened, they should be shortened using as simple a rule as possible. That
rule should apply to all commands and those arguments that can be abbreviated.
EXAMPLE 1: truncation (“pr” for print)
EXAMPLE 2: dropping of vowels (“prnt” for print)
task requires the user to generate and remember commands, simple truncation should be used
Truncation - If the
b)
to s
hot-ten commands.
EXAMPLE: The users are allowed to drop off characters beyond those necessary to make the command unique (e.g. “Q” for QUIT;
or in the case of both QUIT and QUERY, then “QUI” is used for QUIT and “QUE” is used for QUERY).
5.3 Function keys and hot keys
5.3.1 General
If function keys or hot keys are used for command input, their use should be obvious to users or the key assignments
should be readily accessible and these assignments should be consistent throughout the application.
NOTE Consider using function keys and hot keys for frequently used commands or when it is important to speed up command
entry.
5.3.2 Function key consistency
If function keys are used for entering commands, function key assignments for commands should be consistent across
related tasks within an application, particularly for “generic” commands like HELP.
5.3.3 Hot key consistency
If hot keys are used for entering commands, such keys should have the same meaning throughout the application.
assign ments should be the same as
NOTE If commands ca n be accessed by menu dialogues as well as typing, the hot key
the accelerators used in the menus.

IS0 9241=15:1997(E) 0 IS0
EXAMPLE: Alt/c is used for “cancel” and it is used consistently to provide that action throughout the application.
5.3.4 Consistent grou ing of modifiers
If modifier keys (e.g. Ctrl or Alt keys) are used with other keys, there should be a consistent application of the modifier
key usage.
EXAMPLE: Alt plus other letter keys is used for navigation and window manipulation and Ctrl plus other letter keys is used for data
manipulation.
5.3.5 Limited modifiers
Multiple simultaneous modifier keys should be used in hot keys only if there are more commands than can be
accommodated meaningfully by single modifier keys
EXAMPLE: In a dialogue, Alt+p (rather than Alt+Ctrl+p) is used to issue a print command.
NOTE 1 If possible, use letter keys that are mnemonic in combination with modifiers.
NOTE 2 It may be desirable to require the depression of more than one modifier key to reduce the possibility of accidentally
causing a destructive action.
6 Input and output considerations
6.1 General
Users should be in control of the dialogue at all times, be able to easily recover from errors, and not be required to input
more information than is necessary for successful task performance.
6.2 Command reuse
If the same sets of commands are used repeatedly during a work session, the system should provide a way of reusing
the commands without requiring the user to type them again.
EXAMPLE: Giving users a command history list from which they can select a previouslv used command.
6.3 Command queuing
Users should be provided with the capability to key in a series of commands (command queuing or stacking) rather
than wait for the system to execute each individual command.
NOTE Separators should be provided to separate command strings (see 4.5).
6.4 Error correction
If errors occur, re-entry, or editing, should be required only for the erroneous portion of the command and associated
parameters.
6.5 Editing
a) Prior to execution - Users should be allowed to edit commands prior to execution
b) Editing conventions - If the application has a text editor, the same text editing conventions used in the text editor
should apply to command dialogue editing.
6.6 Misspellings
If appropriate for the task and system constraints allow, the system should provide for interpretation and acceptance of
misspelled commands unless there is ambiguity as to what command was intended.

@ IS0 IS0 9241=15:1997(E)
6.7 Defaults
Defaults should be provided to minimize typing requirements and to facilitate learning.
EXAMPLE: If the disk drive is not identified it is assumed to be the currently set default drive.
NOTE 1 Arguments that have default parameter values are often referred to as optional arguments.
NOTE 2 A typical technique for making command languages less difficult to learn is to build in defaults (representing
commonly used parameters of the commands). This allows the user to learn how the commands work without needing to learn
complex functions and syntax. After users become familiar with the command’s operations using the default values, they can
experiment with altering command parameters.
6.8 Destructive commands
If a command may have unintentional or destructive consequences (e.g. deleting a file):
a) Undo - The user should be allowed to cancel the previous (last) command and its effects.
EXAMPLE: Undo command.
or:
b) Confirmation - The user should be required to confirm the intention of the command before command execution.
NOTE See IS0 9241-13 on user guidance for more information.
6.9 Customization
If system constraints allow, users should have the capability to designate and use synonyms for commands and
command macros (see 4.2) and they should be able to revert back to the default names when desired.
6.10 Echoing typed commands
a) Consistent input position - The user’s input should be displayed (echoed) in a consistent position.
EXAMPLE: Displayed on a “command line” at the bottom of the screen or displayed after the prompt on the screen.
Timing - Typed in command characters should be displayed (echoed) as the user types each character.
W
EXAMPLE: As the user types the command “print”, the letter “p” is displayed when the “p key” is depressed, followed by the “r”,
etc.
6.11 Output control
If appropriate to the task and system constraints allow, the command phrase should allow arguments for redirecting
output, interrupting output, or stopping output.
EXAMPLE 1: Users can specify commands so that output is sent to the display or printer.
EXAMPLE 2: Users can specify that the output stops if it exceeds a maximum number of queries.
6.12 Consistent output format
Commands resulting in similar or related output should present their resulting data in a consistent format (see IS0
9241-I 2).
EXAMPLE: Use of a single presentation format for lists of files, processes, directories, etc.

@ IS0
IS0 9241=15:1997(E)
7 Feedback and help
7.1 General
Feedback and help should provide users with information allowing them to control the dialogue, recognize and recover
from errors, and determine their next course of action.
7.2 Command processing
a) Completion - The system should indicate that the command processing has been completed by displaying the
output resulting from the command and/or a prompt for the next command.
NOTE is recommended that this feedback be provided within 2 s.
b) Intermediate feedback - If the command processing is expected to continue for a longer period (more than 5 s),
visual feedback indicating that the process is continuing should be provided to the user . Also see IS0 9241-13.
EXAMPLE 1: Hourglass with sand (time) running out.
EXAMPLE 2: Repeatedly displaying a message: “working”.
NOTE It may be appropriate to provide such information earlier.
c) Processing status - If appropriate to the task and system constraints allow, users should be provided with feedback
concerning the relative amount of time remaining to complete the process.
EXAMPLE: A status bar is shown indicating the amount of processing completed by the amount of green shown within the bar
area.
7.3 Error feedback
Error feedback should be provided after the full command (including associated parameters) has been entered rather
than as soon as the error is discovered by the system.
EXAMPLE: The user misspells the command “print” by pressing the “t” key rather than “r” key and the system indicates the mistake
after the entire command has been entered (and not before).
7.4 Error highlighting
If the feedback on a command entry error is provided on the command line and there is an input error, the
unacceptable portion of the command should be highlighted (in the context of the full command or a logical portion
thereof).
EXAMPLE: The error portion might be highlighted by using reverse video or different color.
7.5 Command information
If appropriate to the task, the user should be provided on request with information on:
a) Commands available and their meaning.
b) Appropriate syntax structure.
c) Required and optional arguments-available (especially if the number is large).
d) Command entry history.
7.6 Performance aids
Performance aids should be provided depicting command characteristics (e.g. name, function, syntax, parameters,
abbreviation, hot key, function key assignment).
0 IS0 IS0 9241=15:1997(E)
EXAMPLE: Using a keyboard template to depict function key assignments for commands or using a Quick Refe rence Card to list
all available commands and associated information.
7.7 Long argument lists
If a command has a long list of arguments and associated parameters, the use of additional dialogue techniques
should be considered.
EXAMPLE: For a command language with numerous arguments, the user can access a dialogue box that has a list with parameter
values that can be selected for each command argument.

IS0 9241-15:1997(E)
Annex
(informative)
licability a
Sample procedure f
A.1 Introduction
Annex A provides an example of a procedure for determining whether the applicable recommendations in IS0 9241-l 5
have been met. It should be noted that the procedure described below is provided as guidance and is not a rigid
process to be used as a substitute for this part of lS0 9241 itself. This procedure provides a two-stage process for
1) determining which recommendations are relevant, and
2) whether those relevant recommendations have been adhered to.
Interface design depends upon the task, the user, the environmenf, and the available technology. Consequent/y,
IS0 9241-15 cannot be applied without a knowledge of the design and use context of the interface and it is not
intended to be used as a prescriptive set of rules to be app/ied in their entirety. Rather, it assumes that the designer
has proper information available concerning task and user requirements and understands the use of available
technology (this could require consultation with a qualified ergonomics professional as well as empiricab testing with
real users).
and critical tasks, and their
The evaluation procedure shou Id be based on a n analysis of typical users, their typical
typical usage environments. Co Imma nd dialogu e evaluations general1 y fall in to the two fo llowing categories:
When users and user tas ks are known , evaluators evaluate the product or observe representative us ers of
nd critical user tasks in a typical u sage environment
the product in the context of accomplish ing typical a
user tasks are not known, evaluators evaluate all of the commands used in the
When s pecific users and
product being evaluated.
Determination of whether a product meets a given recommendation should be based on the set of commands
encountered during the evaluation described above. Command dialogues that can be shown to be better than ones
that meet the recommendations described in this part of ISQ 9241 would also be accepted as meeting the
recommendations of this part of IS0 9241 m
Users of IS0 9241-E could demonstrate how they meet the standard by listing the commands evaluated (e.g. all
commands or a task-derived sub-set of commands); the method used to judge applicability (as described in A.3 below);
the method used to judge adherence (as described in A.4, below); and the results.
A.2 Applicability
The applicability of a recommendation is based on two factors:
- Whether the conditional statement, if included as part of the provision, is true. A particular recommendation is
(or is not) applicable when the conditional if-statement is (or is not) true For example, if blanks are not allowed,
recommendation 4.8.4 a) would not be applicable.
- The design environment. A particular recommendation may not be applicable because of user, task,
environment and technology constraints such as unknown user community, variations in tasks, noisy office,
screen resolution, or lack of a pointing device. However, if the design environment did involve user
characteristics, tasks, or technology features addressed by a particular recommendation, that recommendation
would be applicable. For example, if command input was allowed by means of unlabelled function keys or hot
keys, conditional recommendations in 5.3 should be evaluated to determine their applicability.
@ IS0 IS0 9241=15:1997(E)
The methods which are appropriate to determine applicability of a particular recommendation are:
a) system documentation analysis
b) documented evidence
c) observation
d) analytical evaluation
e) empirical evaluation
The following clause A.3 describes each of the applicability methods in more detail.
A.3 Description of applicability methods
A.3.1 System documentation analysis
System documentation analysis refers to the analysis of any documents which may describe the general and specific
properties of the command language. Such documents may include design documents containing system and user
requirements, manuals, user guides, etc. For example according to system requirements for a particular application,
only the alphanumeric keyboard will be used for command entry.
A.3.2 Documented evidence
Documented evidence refers to any relevant documented information about the task requirements or characteristics,
flow of work, user skills, user aptitudes, existing user conventions or biases, test data from the design of similar
systems, etc. Such information may be used to determine whether a given requirement or recommendation is
applicable. For example, task analysis data may have indicated that users would frequently input the same sequences
of commands.
A.3.3 Observation
Observation means simply to examine or inspect the command dialogue for the presence of a particular observable
property, e.g. command parameters are used. Observations can be made by anyone who has the necessary skill to
systematically check the command dialogue and determine if it has the particular properties associated with the
applicability of given conditional recommendations. Due to their obvious nature, such observations readily can be
confirmed by another person.
A.3.4 Analytical evaluation
Analytical evaluation pertains to “informed” judgments concerning the properties of a command language by a relevant
expert (i.e. of those properties). This method is typically used for the evaluation of properties which can be judged only
in the context of other information or knowledge. In addition, analytical evaluation may be appropriate when the system
exists only in terms of design documents, user populations are not available for empirical evaluation, or time and
resources are constrained. Analytical evaluation can be used to determine whether a particular recommendation is
applicable, e.g. to determine if a command may have unintentional or destructive consequences.
Analytical evaluation can be performed by any suitably qualified person who has the necessary skill and experience to
judge the relevant property of the command language. Where these properties concern the application of ergonomic
principles, the expert needs to possess appropriate skills in software ergonomics. If the properties concern the work
environment, system characteristic, or other aspects of the design, the judge needs to be an expert in the particular
relevant domain.
A.3.5 Empirical evaluation
Empirical evaluation refers to the application of test procedures using representative end users to determine the
applicability of a recom
...