ISO 9241-15:1997
(Main)Ergonomic requirements for office work with visual display terminals (VDTs) — Part 15: Command dialogues
Ergonomic requirements for office work with visual display terminals (VDTs) — Part 15: Command dialogues
Exigences ergonomiques pour travail de bureau avec terminaux à écrans de visualisation (TEV) — Partie 15: Dialogues de type langage de commande
La présente partie de l'ISO 9241 fournit des recommandations pour les dialogues de type langage de commande utilisés dans les tâches de bureau classiques. Les dialogues de type langage de commande sont des séquences d'instructions fournies par l'utilisateur au système, qui, après traitement, déclenchent les actions correspondantes du système. Les utilisateurs entrent (de mémoire, plutôt que par sélection dans un menu) des expressions de commande complètes ou abrégées (par exemple, des mnémoniques, des lettres, des touches de fonction, des touches directes) dans l'ordre requis par la syntaxe du langage de commande, et l'ordinateur exécute les actions lancées par la (les) commande(s) et ses (leurs) paramètres associés. La conception de l'interface dépend de la tâche, de l'utilisateur, de l'environnement et de la technologie disponible. Par conséquent, l'ISO 9241-15 ne peut s'appliquer sans une connaissance du contexte de conception et d'utilisation de l'interface, et n'est pas faite pour être utilisée comme une série de règles obligatoires à appliquer dans leur intégralité. Elle suppose plutôt que le concepteur dispose des informations appropriées concernant les exigences de l'utilisateur et des tâches, et qu'il comprend l'utilisation des technologies disponibles (cela peut nécessiter une consultation auprès de professionnels qualifiés en ergonomie ainsi que les évaluations empiriques avec de vrais utilisateurs). L'ISO 9241-15 concerne l'utilisation des dialogues de type langage de commande, soit en liaison avec d'autres dialogues (de type menu ou manipulation directe), soit comme principale technique de dialogue (dans le cas, par exemple, de terminaux "non intelligents", ou lorsqu'une application particulière requiert une grande rapidité d'interaction). Elle émet en outre des recommandations pour les commandes par touches (touches de fonction et combinaisons de touches) qui représentent des commandes complètes dans un dialogue de type langage de commande.
General Information
Buy Standard
Standards Content (Sample)
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)
---------------------- Page: 1 ----------------------
IS0 9241=15:1997(E)
Page
Contents
1
1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
..................................................................................... 1
2 Definitions
.......................................................... 3
3 Application of IS0 9241-15
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4 Structure and syntax
6
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
---------------------- Page: 2 ----------------------
@ 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
---------------------- Page: 3 ----------------------
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.
---------------------- Page: 4 ----------------------
@ 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
---------------------- Page: 5 ----------------------
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
---------------------- Page: 6 ----------------------
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.
---------------------- Page: 7 ----------------------
@ 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.
---------------------- Page: 8 ----------------------
@ 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
4
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.
3
---------------------- Page: 9 ----------------------
@ 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”)
---------------------- Page: 10 ----------------------
@ 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.
5
---------------------- Page: 11 ----------------------
@ 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”.
---------------------- Page: 12 ----------------------
@ 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.
---------------------- Page: 13 ----------------------
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
...
NORME
IS0
INTERNATIONALE
9241-15
Premihe edition
1997-l 2-l 5
Exigences ergonomiques pour travail de
bureau avec terminaux 31 krans de
visualisation (TEV) -
Partie 15:
Dialogues de type langage de commande
Ergonomic requirements for office work with visual display terminals
(VDTs) -
Part 15: Command dialogues
Numkro de ritfbrence
IS0 9241-15:1997(F)
---------------------- Page: 1 ----------------------
IS0 9241=15:1997(F)
Page
Sommaire
1
1 Domaine d’application .
1
2 Definitions .
........................................................ 3
3 Application de IWO 9241-15
4
4 Structure et syntaxe .
................................................. 7
5 Representation des commandes
6 Aspects relatifs aux modes d’entree et de sortie. . 9
11
7 Feed-back et aide .
Annexe A (informative) Exemple de procedure d’evaluation
..................................................... 13
de I’applicabilite et de I’adhesion
Annexe B (informative) Bibliographie . 28
0 IS0 1997
Droits de reproduction reserves. Sauf prescription differente, aucune partie de cette publi-
cation ne peut etre reproduite ni utilisee sous quelque forme que ce soit et par aucun pro-
cede, electronique ou mecanique, y compris la photocopie et les microfilms, sans I’accord
ecrit de I’editeur.
Organisation internationale de normalisation
Case postale 56 l CH-1211 Geneve 20 l Suisse
central @ iso.ch
Internet
x.400 c=ch; a=400net; p=iso; o=isocs; s=central
lmprime en Suisse
ii
---------------------- Page: 2 ----------------------
@ IS0 IS0 9241-l 5:1997(F)
Avant-propos
L’ISO (Organisation internationale de normalisation) est une federation
mondiale d’organismes nationaux de normalisation (comite membres de
I’ISO). L’elaboration des Normes internationales est en general confiee aux
comites techniques de I’ISO. Chaque comite membre interesse par une
etude a le droit de faire partie du comite technique tree a cet effet. Les
organisations internationales, gouvernementales et non gouvernementales,
en liaison avec I’ISO participent egalement aux travaux. L’ISO collabore
etroitement avec la Commission electrotechnique internationale (CEI) en
ce qui concerne la normalisation electrotechnique.
Les projets de Normes internationales adopt& par les comites techniques
sont soumis aux comites membres pour vote. Leur publication comme
normes internationales requiert I’approbation de 75 % au moins des
comites membres votants.
La Norme internationale IS0 9241-E a ete elaboree par le comite
technique lSO/TC 159, Ergonomie, sous-comite SC 4, Ergonomie de
/‘interaction homme-systeme.
L’ISO 9241 comprend les parties suivantes, presentees sous le titre
general Exigences ergonomiques pour travail de bureau avec terminaux a
ecrans de visualisation (TEV) :
- Partie I : Introduction g&&ale
- Partie 2 : Guide general concernant /es exigences des taches
- Pariie 3 : Exigences relatives aux ecrans de visualisation
- Partie 4 : Exigences relatives aux claviers
- Partie 5 : Exigences relatives a I’amenagement du poste de travail et
aux postures
- Partie 6 : Exigences relatives a I’environnement
- Partie 7 : Exigences d’affichage concernant les reflexions
- Partie 8 : Exigences relatives aux couleurs affichees
- Partie 9 : Exigences relatives aux dispositifs d/entree autres que les
cla viers
- Partie IO : Principes de dialogue
- Partie I I : Lignes directrices concernant I’utilisabilite
. . .
III
---------------------- Page: 3 ----------------------
IS0 9241=15:1997(F) @ IS0
- Pat-tie 12 : Prksentation de I’information
- Patiie 13 : Lignes directrices pour I’utilisateur
- Partie 14 : Dialogues de type menu
-
Partie 15 : Dialogues de type langage de commande
- Pariie 16 : Dialogues de type manipulation directe
-
Partie 17 : Dialogues de type remplissage de formulaires
Les annexes A et B de la prksente partie de I’ISO 9241 sont don&es
uniquement h titre d’information.
iv
---------------------- Page: 4 ----------------------
@ IS0 IS0 9241=15:1997(F)
Introduction
L’ISO 9241 traite des aspects ergonomiques du materiel et du logiciel en
ce qui concerne I’utilisation de terminaux a ecrans de visualisation. La
description des differentes parties de I’ISO 9241, de leur articulation et des
differents utilisateurs auxquels elles s’adressent fait I’objet de I’ISO 9241-I.
L’ISO 9241-15 concerne la conception ergonomique des dialogues de type
langage de commande. Dans les dialogues de ce type, les utilisateurs
entrent de memoire des expressions de commandes completes ou
abregees respectant la syntaxe du langage de commande, et I’ordinateur
execute les actions correspondant aux commandes et a leurs parametres.
L’ISO 9241-I 5 s’adresse aux types d’utilisateurs suivants :
a) Le concepteur de I’interface utilisateur, qui appliquera la presente
partie de I’ISO 9241 durant le processus de developpement.
b) L’acheteur, qui se referera a la presente partie de I’ISO 9241 pendant
le processus d’acquisition du produit.
c) Les responsables de I’evaluation qui doivent s’assurer que les
produits sont conformes aux recommandations de la presente partie de
I’ISO 9241;
d) Les concepteurs d’outils d’elaboration d’interface utilisateur destines
aux concepteurs d’interfaces.
e) Les utilisateurs finals qui beneficieront des avantages potentiels
fournis par la presente partie de I’ISO 9241.
Le beneficiaire final de la presente partie de I’ISO 9241sera I’utilisateur final
du TEV. Ce sont les besoins de cet utilisateur qui ont dicte les exigences
ergonomiques de I’ISO 9241-15. Bien qu’il soit peu probable que
I’utilisateur final lise la presente partie de I’ISO 9241, ou meme qu’il en
connaisse I’existence, son application devrait fournir des interfaces
utilisateur plus faciles a utiliser, plus coherentes et apportant une meilleure
productivite.
Pour appliquer I’ISO 9241-15 dans le contexte global des exigences
ergonomiques de I’interaction homme-systeme, les utilisateurs sont invites
a lire les parties suivantes de I’ISO 9241 :
IS0 9241-1, Exigences ergonomiques pour travail de bureau avec
terminaux 21 6crans de visualisation (TEV) - Partie 1 :
Introduction g&n&ale
---------------------- Page: 5 ----------------------
IS0 9241=15:1997(F) @ IS0
IS0 9241-2,
Exigences ergonomiques pour travail de bureau avec
terminaux a ecrans de visualisation (TEV) - Partie 2 :
Guide general concernant les exigences des taches
IS0 9241-10, Exigences ergonomiques pour travail de bureau avec
terminaux a ecrans de visualisation (TEV) - Partie IO :
Principes de dialogue
IS0 9241-13, Exigences ergonomiques pour travail de bureau avec
terminaux a ecrans de visualisation (TEV) - Partie 13 :
Lignes directrices pour I’utilisa teur
L’ISO 9241-15 consiste en un certain nombre de recommandations, dont
certaines sont conditionnelles, concernant les dialogues de type langage
Les recommandations conditionnelles sont des
de commande.
recommandations qui ne devraient etre satisfaites que dans le contexte
specifique qui leur est applicable (par exemple, types particuliers
d’utilisateurs, de taches, d’environnements, de technologie). Ces
recommandations ont d’abord ete elaborees en examinant de la
documentation appropriee existante ainsi que les resultats empiriques et,
ensuite, en generalisant et en formulant ce travail en recommandations
destinees a I’utilisateur et/au a I’evaluateur de I’interface. Les references
justifiant les recommandations individuelles sont donnees a I’annexe B.
Les concepteurs et les evaluateurs qui utilisent I’ISO 9241-15 doivent etre
conscients qu’ils developpent une interface devant respecter les
recommandations de cette partie. De meme, I’acheteur doit disposer d’un
moyen de determiner si un produit respecte ces recommandations. Les
elements d’evaluation peuvent etre adapt& grace a la structure “si--alors”
de I’ISO 9241-15. Enfin, I’ISO 9241-I 5 n’exige pas que soient appliquees
toutes les recommandations, mais seulement celles qui sont pertinentes.
L’application de la presente partie de I’ISO 9241 devrait conduire a
I’amelioration de la qualite globale du langage de commande, mais, comme
autre norme, I’ISO 9241-I 5 ne saurait garantir la qualite de I’interface.
toute
La qualite depend de criteres specifiques d’utilisabilite etablis par
I’utilisateur, I’acheteur ou toute autre personne concernee par des
dialogues de type langage de commande, criteres qui peuvent inclure des
specifications fondees sur la presente partie de I’ISO 9241.
II convient de noter que I’ISO 9241-10 decrit des principes de dialogue
applicables pour la conception de dialogues de type langage de
commande. Ces principes devraient fournir au concepteur et a I’evaluateur
des informations complementaires sur les fondements ergonomiques qui
sont a la base des recommandations de I’ISO 9241-15, et devraient done
les aider dans leurs choix techniques. Cependant, il sera sans doute
necessaire, pour operer des choix techniques, de prendre egalement en
compte d’autres considerations.
vi
---------------------- Page: 6 ----------------------
NORME INTERNATIONALE o Is0 IS0 9241=15:1997(F)
Exigences ergonomiques pour travail de bureau avec terminaux &
krans de visualisation (TEV) -
Partie 15:
Dialogues de type langage de commande
1 Domaine d’application
La presente partie de I’ISO 9241 fournit des recommandations pour les dialogues de type langage de commande
utilises dans les taches de bureau classiques. Les dialogues de type langage de commande sont des sequences
d’instructions fournies par I’utilisateur au systeme, qui, apres traitement, declenchent les actions correspondantes
du systeme. Les utilisateurs entrent (de memoire, plutot que par selection dans un menu) des expressions de
commande completes ou abregees (par exemple, des mnemoniques, des lettres, des touches de fonction, des
touches directes) dans I’ordre requis par la syntaxe du langage de commande, et I’ordinateur execute les actions
Ian&es par la (les) commande(s) et ses (leurs) parametres associes.
La conception de l’interface depend de la t&he, de I’utilisateur, de I’environnement et de la technologie disponible.
Par consequent, I’ISO 9241-15 ne peut s’appliquer sans une connaissance du contexte de conception et
d’utilisation de I’interface, et n’est pas faite pour etre utilisee comme une serie de regles obligatoires a appliquer
dans leur integralite. Elle suppose plutot que le concepteur dispose des informations appropriees concernant les
exigences de I’utilisateur et des taches, et qu’il comprend I’utilisation des technologies disponibles (cela peut
necessiter une consultation aupres de professionnels qualifies en ergonomie ainsi que les evaluations empiriques
avec de vrais utilisateurs).
L’ISO 9241-15 concerne I’utilisation des dialogues de type langage de commande, soit en liaison avec d’autres
dialogues (de type menu ou manipulation directe), soit comme principale technique de dialogue (dans le cas, par
ou lorsqu’une application particuliere requiert une grande rapidite
exemple, de terminaux “non intelligents”,
d’interaction). Elle emet en outre des recommandations pour les commandes par touches (touches de fonction et
combinaisons de touches) qui representent des commandes completes dans un dialogue de type langage de
commande. Si la fonction d’une commande appara’it comme evidente du fait de sa representation (icbnes
graphiques par exemple) et que I’appel de cette fonction ne requiert aucun effort de memoire de la part de
I’utilisateur, alors la presente partie de I’ISO 9241 ne la considere pas comme un dialogue de type langage de
commande. Les commandes peuvent aussi etre appelees par d’autres techniques de dialogue (options de menu,
formulaires ou manipulation directe). Neanmoins, ces methodes ne demandant Pas d’effort de memoire de la part
mais ailleurs. II convient de noter aussi que
de I’utilisateur ne seront pas traitees dans la presente partie,
I’ISO 9241-I 5 ne fournit pas de guidage pour les dialogues en langage “natureI”=
2 Definitions
Pour les besoins de la presente partie de I’ISO 9241, les definitions suivantes s’appliquent.
---------------------- Page: 7 ----------------------
@ IS0
IS0 9241=15:1997(F)
2.1 argument
de commande pour modifier ou
Variable independante (y compris un objet) utilisee dans une expression
selectionner I’action d’une commande.
NOTE Les arguments component souvent des paramktres.
2.2 commande
Mot entier, abreviation ou chaTne de mots representant des actions requises par le systeme.
2.3 dialogue de type langage de commande
Jeu(x) de commandes, expressions, structure et syntaxe associes a une interaction specifique entre un utilisateur
et un systeme informatique au moyen de commandes.
2.4 structure de dialogue de type langage de commande
Structure logique du dialogue de type langage de commande (et des expressions associees).
2.5 mise en file d’attente de commandes (empilage)
Accumulation d’une serie d’expressions de commande en vue de les entrer regroupees dans le systeme, plutot que
I’une apres I’autre.
2.6 expression de commande
Phrase comportant la commande elle-meme (des mots ou leur abreviation) ainsi que les separateurs et arguments
(parametres) associes.
EXEMPLE : [Mot de commande] [separateur] [argument I] [separateur] [argument 2 [caractere-de-fin].
2.7 jeu de commandes
Ensemble des commandes disponibles permettant a I’utilisateur d’executer une t&he donnee dans un contexte
applicatif patticulier.
2.8 syntaxe de commande
Ensemble des conditions de sequence et de procedure qui regissent I’introduction des composants dans une
expression de commande complete.
2.9 mot de commande (nom)
Mot (ou nom) servant de commande dans le dialogue de type langage de commande. Ce mot represente I’action
requise du systeme.
2.10 abreviation de mot de commande
Version abregee d’un mot de commande reconnue par I’ordinateur comme representant la commande.
NOTE Cette abr6viation peut 6tre constitube d’une seule ou de plusieurs Iettres du mot de commande.
2.11 touches directes
Touches, autres que les touches de fonction numerotees (par exemple Fl, F2, etc.) ; les touches directes ne sont
normalement pas utilisees pour I’entree de donnees, comme c’est le cas pour les touches de modification (par
exemple Ctrl, Alt) ou les combinaisons de touches (par exemple Ctrlk) qui provoquent I’execution immediate sans
necessiter d’autres operations.
2.12 mot cl6
Mot d’une expression de commande identifiant une classe particuliere d’arguments (par exemple police de
caracteres).
2.13 modificateur
Argument qui modifie ou limite l’action d’une commande.
---------------------- Page: 8 ----------------------
@ IS0
IS0 9241=15:1997(F)
2.14 paramgtre
Valeur utilisee en conjonction avec un mot cle pour modifier I’action d’une commande ou d’un argument.
2.15 separateur
Chaine d’un ou plusieurs caracteres, ou pause dans le cas d’entree vocale, servant a &parer ou organiser les
elements d’une expression de commande ou a &parer les expressions de commande.
3 Application de IWO 9241-15
3.1 Conception du dialogue de type langage de commande
Dans un dialogue de type langage de commande (comme defini dans I’ISO 9241.15), I’expression de commande
est entree par I’utilisateur dans une combinaison syntaxique specifique que “comprend” I’ordinateur. Celui-ci accuse
reception de la commande, indique si elle est acceptable dans I’etat actuel d’avancement du traitement, si les
parametres associes conviennent a la commande et a I’etat actuel d’avancement du traitement, et, dans
I’affirmative, execute les actions requises et/au fournit les sorties demandees. Les expressions de commande
peuvent etre entrees dans I’ordinateur de plusieurs facons differentes, par exemple, au moyen d’une “ligne de
commande”, d’une boite de dialogue ou par entree vocale.
Les commandes peuvent etre :
a) des mots entiers, ou des chaines de mots, &pares par des blancs (des pauses en cas d’entree vocale) ou
d’autres delimiteurs indiquant la syntaxe a I’ordinateur ;
b) des abreviations d’une seule ou de plusieurs lettres.
La conception du dialogue determine la facon dont I’utilisateur est guide par le systeme pour effectuer des entrees
et decide du degre de controle que detient I’utilisateur sur le deroulement du dialogue. II convient que les dialogues
de type langage de commande aident I’utilisateur dans son travail effectif, sans lui imposer un travail
supplementaire du a des particularites du systeme, et le tiennent informe et maitre du deroulement du travail (voir
aussi I’ISO 9241-10). On doit prendre ces objectifs en consideration lors de la conception de la structure et de la
syntaxe des commandes, des representations des commandes, des specifications des entrees et sorties de
commandes ainsi que des mecanismes de feed-back et d’aide.
La personne chargee de I’application de I’ISO 9241-15 pour la conception et I’evaluation d’un systeme ou d’un
produit doit etre au fait des preoccupations des utilisateurs finaux, de leur environnement et de leurs taches. II
convient de recenser les taches des utilisateurs et d’identifier clairement les plus frequentes et les plus importantes.
L’application de ces recommandations doit aussi tenir compte des lois generales qui regissent la perception
humaine, I’identification et la discrimination de I’information ainsi que des lois de psychomotricite a respecter pour la
frappe des commandes au clavier.
3.2 Pertinence des dialogues de type langage de commande
Le recours a des dialogues de type langage de commande se justifie tout specialement dans une ou plusieurs des
conditions suivantes, classees entre besoins de I’utilisateur et caracteristiques des taches. Plus le nombre de
conditions remplies est important, plus I’applicabilite est grande.
a) Caracteristiques des utilisateurs
1) Les utilisateurs ont un bon niveau de dactylographie (s’ils doivent taper les commandes).
2) Les utilisateurs vont utiliser le systeme frequemment.
3) Les utilisateurs vont etre form& a I’utilisation du langage de commande.
4) Les utilisateurs sont familiarises avec les ordinateurs et les langages de commande.
3
---------------------- Page: 9 ----------------------
IS0 9241=15:1997(F)
b) Caracteristiques des taches
1) Le choix des actions que demandera I’utilisateur dans le dialogue est imprevisible.
2) Les options et/au les donnees peuvent etre entrees dans un ordre arbitraire.
3) Une selection ou un acces aux fonctions specifiques du systeme est requis (dans un systeme de
reservation aerienne par exemple).
commandes ou d’encha’inement de commandes
Les possibilites d’extension (creation de nouvelles
4)
repondant a de nouvelles situations) sont requises.
3.3 Application des recommandations
Chaque paragraphe des articles 4 a 7 enonce des objectifs generaux de conception ergonomique. II convient que
les recommandations particulieres visant a atteindre ces objectifs soient appliquees dans le contexte particulier
pour lequel elles sont pertinentes (par exemple, types particuliers d’utilisateurs, de taches, d’environnements, de
technologies). Chaque recommandation particuliere se presente sous la forme l . formulation de la recommandation,
exemple (si necessaire), et notes (si necessaire). Les exemples decrivent le plus souvent une mise en ceuvre dans
laquelle la recommandation a ete appliquee. Certains exemples indiquent aussi les solutions recommandees.
II convient d’evaluer les recommandations particulieres en fonction de leur applicabilite et, si elles sont jugees
applicables, de les mettre en oeuvre dans un dialogue de type langage de commande pertinent, a moins qu’il se
soit avere que cette mise en application risque de provoquer une deviation des objectifs de conception ou une
degradation globale de I’utilisabilite. Lors de la determination de leur applicabilite, les recommandations devraient
en regle generale etre evaluees dans I’ordre presente dans la section ou sous-section correspondante. Pour verifier
si les recommandations applicables ont bien ete respectees, il convient d’evaluer le produit et d’observer des
utilisateurs representatifs dans le contexte reel de I’accomplissement de leurs taches avec le systeme de dialogue
de type langage de commande. L’annexe A fournit des exemples de procedures de determination de I’applicabilite
et d’evaluation de la bonne application des recommandations.
3.4 Evaluation des produits
Lorsqu’un produit est presente comme conforme aux recommandations applicables de I’ISO 9241-15, la procedure
utilisee pour I’etablissement des exigences, pour le developpement et/au pour I’evaluation des dialogues de type
langage de commande doit etre specifiee. Le niveau de specification de la procedure fait I’objet d’une negotiation
entre les parties concernees.
L’annexe A fournit un exemple de procedure permettant de specifier I’applicabilite et la conformite a la presente
par-tie de I’ISO 9241. Les utilisateurs de la presente Norme internationale peuvent soit utiliser les procedures de
I’annexe A, soit developper un ensemble de procedures comparables adaptees a leur propre environnement de
developpement et/au d’evaluation.
4 Structure et syntaxe
4.1 GhWalit6s
II convient que le langage de commande soit concu de telle sorte que le mode d’entree des commandes soit nature1
ou familier a I’utilisateur, sans souci de la facon dont I’ordinateur traitera les commandes pour produire le resultat
demand& II convient done que le langage de commande reflete les besoins de I’utilisateur et non le traitement
informatique, et que la structure de la syntaxe soit conforme aux attentes de I’utilisateur, aux exigences de taches et
aux moyens d’entree.
---------------------- Page: 10 ----------------------
@ IS0
IS0 9241-l 5:1997(F)
4.2 Coh6rence interne
II convient que le langage de commande presente une coherence interne de telle sorte que les commandes de
meme nom fonctionnent de la meme facon dans I’ensemble de I’application, quel que soit le contexte. Les
commandes qui font la meme chose devraient porter le meme nom.
NOTE Ceci n’exclut pas I’utilisation de synonymes, le cas echeant.
4.3 Macros de commandes
Si des sequences de mots de commandes ou des expressions de commandes sont frequemment utilisees, il
convient de donner aux utilisateurs le moyen de creer et d’utiliser pour ces sequences des commandes de niveau
superieur (macros).
NOTE II convient que les macros de commandes respectent les memes recommandations que les commandes.
4.4 Structure des arguments
II convient que la structure des expressions de commande vise a reduire la complexite des arguments.
a) Listes longues - Si les listes d’arguments sont longues (plus de 8 arguments), il convient de creer des noms de
commande supplementaires, combiner des fonctions sous un seul parametre, ou de les &parer en groupes de
fonctions logiques.
b) Dependances - II convient que les dependances entre arguments d’une commande ne modifient pas
fondamentalement la signification de I’expression de commande.
EXEMPLES : Utiliser :
- la commande “Quitter - nom-de-fichier” pour enregistrer les donnees dans un fichier nomme nom-de-fichier ;
- la commande “Annuler” pour sortir sans enregistrer (de preference a “Quitter -cl’).
4.5 Structure de la syntaxe
II convient d’adapter la structure syntaxique des expressions de commande au
a) Adaptation au mode d’entree -
mode d’entree (par exemple, entree vocale, entree clavier, gestes).
EXEMPLE : Si I’entree vocale est exclusivement utilisee, la syntaxe sera en coherence parfaite avec le langage park.
b) Homogeneite pour un meme mode d’entree - II convient que la syntaxe demeure homogene pour I’ensemble des
commandes destinees a un meme mode d’entree.
EXEMPLE : Pour un dialogue de type langage de commande, I’objet est place a la suite de I’action (c’est-a-dire syntaxe
action-objet) tout au long de I’application.
c) Homogeneite pour I’ensemble des modes d’entree - II convient que la syntaxe soit homogene autant que
possible.
pour specifier les commandes dans une application et la
EXEMPLE: L’entree vocale ainsi que I’entree clavier sont utilisees
syntaxe en vigueur est action-objet quel que soit le mode d’entree.
5
---------------------- Page: 11 ----------------------
0 IS0
IS0 9241=15:1997(F)
4.6 Sbparation des commandes
Si I’entree de commandes multiples est autorisee, il convient d’adopter une methode simple et homogene de
separation des commandes :
a) Blancs - Si les contraintes du systeme n’exigent pas I’emploi d’un separateur specifique, il est preferable de
choisir pour &parer les commandes des blancs plutot que des marques de ponctuation.
Si les contraintes du systeme requierent des separateurs autres que des blancs pour
b) Symbole standard -
il convient d’utiliser un symbole standard simple, de facon
distinguer differentes commandes empilees,
coherente.
EXEMPLE : Utilisation de la barre oblique (/) dans les mots de commande “TRIER/METTRE EN PAGE/IMPRIMER”.
4.7 Correspondance avec le langage
II convient que la structure des commandes (semantique et syntaxe) corresponde a une terminologie et a une
organisation de donnees familieres ou naturelles a I’utilisateur.
EXEMPLE : Les lois de la syntaxe du langage nature1 (le francais, I’anglais, par exemple) sont appliquees dans la conception
d’un langage de requete.
4.8 Arguments des commandes
II convient que les arguments des commandes soient faciles a specifier et a relier aux commandes qu’ils modifient.
NOTE Dans certains cas, il peut etre judicieux de rep&enter les arguments par des noms plutot que par de simples Iettres.
4.8.1 Liaison des Mments de commandes
II convient de structurer le dialogue de type langage de commande de telle sorte que la relation entre les elements
de I’expression de commande apparaisse clairement.
EXEMPLE : lmprimer pages = l-15 exemplaires = 2.
4.8.2 Formats des arguments
S’ils sont adapt& a la t&he, il est preferable d’utiliser des formats de type mot cle (parametres designes par des
arguments les identifiant et places devant) plutot que des formats de position (parametres design& par leur
position en sequence dans la chaine d’arguments qui suivent la commande).
EXEMPLE 1 : (Format de type mot cle) : modifier forme = ronde; couleur = rouge; taille = 4.
EXEMPLE 2 : (Format de position) : modifier rond rouge 4.
4.8.3 Position des arguments optionnels
Si les formats de type mot-cle ne sont pas utilises, il convient de placer les arguments optionnels en fin de liste
d’arguments.
4.8.4 Skparation des arguments
a) Espace blanc - Si les blancs sont autorises, ii convient d’accepter un nombre variable de blancs entre les
elements de la commande.
b) Autres separateurs - Si les contraintes du systeme requierent des separateurs autres que des blancs pour
distinguer les divers arguments, il convient d’utiliser un symbole standard simple, de facon coherente.
EXEMPLE : Utilisation de la virgule (,) dans I’expression de commande “imprimer fichier A, fichier B, fichier C”.
---------------------- Page: 12 ----------------------
@ IS0
IS0 9241=15:1997(F)
4.9 Quantificateurs
II convient d’eviter dans un dialogue de type langage de commande I’emploi de quantificateurs imp&is ou inutiles.
NOTE Dans les langages de requetes, “peu” ou “beaucoup” sont des termes imp&is, et les utilisateurs ne comprennent pas
leur sens.
5 Reprbentation des commandes
5.1 Noms de commandes
5.1 .l G&&alit&
II convient que le nom d’une commande soit en rapport avec sa fonction, le plus souvent un verbe (generalement a
I’imperatif), aise a memoriser et adapte aux exigences de taches de I’utilisateur, a son experience et a son
utilisation du langage.
5.1.2 Caracthe distinctif
II convient que les noms des commandes soient distinctifs.
II convient de choisir des noms de commandes semantiquement distincts et sans
a) Signification distinctive -
ambigu’ite.
EXEMPLE : En francais, les mots “inserer” et “supprimer” sont plus distincts sur le plan semantique que “ajouter” et “retirer”
(“ajouter” et “retirer” peuvent avoir plusieurs interpretations).
b) Signification specifique - II convient de choisir des noms de commandes dont la signification est specifique ou
restreinte, de preference a des noms de sens plus general.
EXEMPLE : Preferer “remplacer” a “changer”.
c) Similitude visuelle/auditive - II convient d’eviter les noms de commande d’apparence visuelle ou auditive trop
similaire bien que de sens different.
EXEMPLE : En anglais, on evite “store” et “restore” parce qu’ils se ressemblent malgre une signification differente.
Si deux commandes representent des actions inverses ou symetriques, il
d) Paires de commandes assorties -
convient de leur donner des noms de commandes coherents.
EXEMPLE : Lirekrire, ouvrir/fermer, oui/non.
5.1.3 Adaptation & I’utilisateur
II convient de choisir des noms de commandes correspondant a I’experience des utilisateurs ainsi qu’a leur langage
professionnel.
de fournir des jeux de
NOTE Si les groupes d’utilisateurs sont varies, il peut se reveler important noms de commandes
differents adapt& aux differents groupes.
5.1.4 Contenu 6motionnel
Les mots choisis comme mots de commande doivent etre exempts de tout contenu emotionnel.
EXEMPLE : En francais, mieux vaut utiliser “supprimer” que “tuer”.
5.1.5 Longueur du mot de commande
Si la commande est entree au clavier, il convient que les mots de commande ne depassent pas sept caracteres.
7
--------------------
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.