|
Introduction | | | Data Entry | | | Data Display | | | Sequence Control | | | User Guidance | | | Data Transmission | | | Data Protection | | | Table of Contents |
|
GUIDELINES FOR DESIGNING USER INTERFACE SOFTWARE
ESD-TR-86-278
|
| by Sidney L. Smith and Jane N. Mosier |
|
|
Introduction | | | Data Entry | | | Data Display | | | Sequence Control | | | User Guidance | | | Data Transmission | | | Data Protection | | | Table of Contents |
Data transmission refers to computer-mediated communication among system users, and also with other systems. Preceding sections of this report have dealt with the basic functions of using on-line information systems -- entering data into a computer, displaying data from a computer, controlling the sequence of input-output transactions, with guidance for users throughout the process. What other functions can a computer serve? One area that increasingly demands our attention is the use of computers for communication, i.e., to mediate the transmission of data from one person to another.
In considering data transmission functions, we must adopt a broad perspective. Data that are transmitted via computer may include words and pictures as well as numbers. And the procedures for data transmission may take somewhat different forms for different system applications.
Data might be transmitted by transferring a data file from one user to another, perhaps with an accompanying message to indicate that such a file transfer has been initiated. Data might be transmitted by directly linking two display terminals, so that whatever data one user keys onto a display will be displayed to another user as well. More commonly, however, data are transmitted as "messages", which involves creation of a specially-formatted file with a formal header to specify the sender, recipient, addresses, etc. In these guidelines, the word "message" is mostly used in this sense, to denote data transmitted with a formal header. But the phrase "message handling" sometimes refers more generally to user participation in data transmission.
In a designed information system, data transmission by file transfer may be largely automatic, accomplished with little user involvement. Data transmission by direct linking would presumably be rare, and achieved only under operational constraints, as when a supervisor links to a subordinate's terminal for reviewing and directing work. Thus most of the guidelines here pertain to data transmission accomplished via formatted messages.
In some applications, computer-mediated data transmission may be a discrete, task-defined activity. Perhaps a system used for planning/scheduling is later used to generate and transmit orders to implement a plan. In such a system, a user can "shift gears", first creating a plan and then transmitting that plan.
In other applications, data transmission may be a continuing, intermittent activity mixed with other tasks. As an example, air traffic controllers might use their computer facilities to exchange information (and to hand over responsibility) while they are performing other essential flight monitoring tasks.
An even broader requirement for computer-based message handling can be seen in systems whose explicit, primary purpose is to support communication (Uhlig, 1981; Smith, 1984). In such applications, computer-mediated data transmission is sometimes called "electronic mail". In conjunction with other new technology, the current development of electronic mail has brought forecasts of a "wired society" in which we become ever more dependent on computers for communication (Martin, 1978).
Effective communication is of critical importance in systems where information handling requires coordination among groups of people. This will be true whether communication is mediated by computer or by other means. Computer-based message handling may offer a potential means of improving communication efficiency, but careful design of the user interface will be needed to realize that potential.
In the interests of efficiency, much data transmission among computers is designed to be automatic, representing a programmed message exchange between one computer and another, with no direct user involvement. If a user does not participate in data transmission, then there is of course no need to include data transmission functions in user interface design. Only when the users themselves are involved in data transmission transactions will interface design guidelines be needed.
For the users of computer systems, data transmission can impose an extra dimension of complexity. A user not only must keep track of transactions with the computer, but also must initiate and monitor data exchange with other people. Users will need extra information to control data transmission, perhaps including status information about other systems, and the communication links with other systems. Users will need feedback when sending or receiving data. Users may need special computer assistance in composing, storing and retrieving messages, as well as in actual data transmission. And users will wish to control the disposition of received messages, perhaps renaming a message and storing it with other related messages, and/or sending it on to other users.
When data transmission functions can be designed as an integral part of an information system, there is a clear opportunity for the interface designer to ensure compatibility of procedures. For example, if the system provides procedures for text editing, file storage, and retrieval in support of so-called "word processing" functions, then those same procedures should serve to edit, store, and retrieve messages. Users will not have to learn a different set of commands, or select from a different assortment of menu options.
In some current applications, however, data transmission functions have been grafted onto an existing system. There is a practical advantage in buying a separate package of message handling software for use in conjunction with an already existing system. The message handling functions do not have to be designed from scratch, and they can often be added without any fundamental redesign of the existing system capabilities.
There is a potentially serious disadvantage, however, in trying to combine separately designed software packages: they will almost surely look different to a user, unless care is taken to design an integrated user interface. Differences in user interface logic can sometimes be "papered over" by the software designer, perhaps by providing a menu overlay that effectively conceals inconsistencies of control logic (Goodwin, 1983; 1984). How well the user interface design has integrated the disparate software packages should then be evaluated in operational use (Tammaro, 1983).
Whether the user interface to data transmission functions can be designed from scratch, or is designed separately and then must be integrated with other system functions, some guidelines may be needed to help the interface designer. Recent studies of computer-based message handling have been chiefly concerned with determining the functional capabilities required in data transmission (cf., Goodwin, 1980). There is already evidence, however, that the practical use of data transmission functions can be limited by deficiencies in user interface design (Goodwin, 1982).
The general objectives of user interface design in other functional areas are equally valid for data transmission functions. Procedures for data transmission should be consistent in themselves, and consistent with procedures for data entry and display. Interface design should minimize effort and memory load on the user, and permit flexibility in user control of data transmission.
Objectives
Consistency of data transmission
Minimal user actions
Minimal memory load on user
Compatibility with other information handling
Flexibility for user control of data transmission
Data transmission refers to computer-mediated communication among system users, and also with other systems.
Ensure that data transmission functions are integrated with other information handling functions within a system.
Comment
A user should be able to transmit data using the same computer system
(and procedures) used for general entry, editing, display, and other
processing of data.
Comment
A user should not have to log off from a general data processing system
and log on to some other special system in order to send or receive a
message. If data transmission facilities are in fact implemented as a
separate system, that separation should be concealed in user interface
design, so that a user can move from general information handling to
message handling without interruption.
Choose functional wording for the terms used in data transmission -- for preparing and addressing messages, for initiating and controlling message transmission and other forms of data transfer, and for receiving messages -- so that those terms will match users' work-oriented terminology.
Example
A user should be able to address messages to other people or agencies by
name, without concern for computer addresses, communication network
structure and routing.
Comment
In general, a user should not have to learn the technical details of
communication protocols, codes for computer "handshaking", data format
conversion, etc., but should be able to rely on the computer to handle
those aspects of data transmission automatically.
Reference
Ensure that procedures for preparing, sending and receiving messages, are consistent from one transaction to another, and are consistent with procedures for other information handling tasks.
Exception
Data transmission that does not involve formal messages might by-pass
standard procedures as in the direct linking of terminals, or might
require special procedures as in the transfer of data files.
Comment
Procedures should be the same for handling different kinds of messages
and for messages sent to different destinations, although procedures for
handling high-priority messages might incorporate special actions to
ensure special attention.
Comment
Users should be able to use the same procedures to enter, edit and
display messages as they use to enter, edit and display other kinds of
data. Computer-generated error messages and other forms of user
guidance should also be consistent from one kind of information handling
to another.
See also
4.0/1
Design the data transmission procedures to minimize memory load on the user.
Example
Interface software might provide automatic insertion into messages of
standard header information, distribution lists, etc.
Example
The computer should provide automatic queuing of outgoing messages
pending confirmation of transmission, and of incoming messages pending
their review and disposition.
Example
Software might provide automatic record keeping, message logging, status
displays, etc.
Design the data transmission procedures to minimize required user actions.
Example
In some applications, software logic might prepare and transmit messages
automatically, derived from data already stored in the computer.
Example
Software logic might provide automatic reformatting of stored data for
transmission, where format change is required.
Example
Interface software might provide automatic insertion into messages of
standard header information, distribution lists, etc.
Design the data transmission procedures so that both sending and receiving messages are accomplished by explicit user action.
Comment
Automatic message generation and receipt will be helpful in many
applications, but in such cases the user should be able to monitor
transmissions, and should be able to participate by establishing,
reviewing and/or changing the computer logic that controls automatic
data transmission.
See also
1.0/9
|
3.0/5
|
4.0/2
|
6.0/9
Provide for flexible control of data transmission, so that users can decide what data should be transmitted, when, and where.
Exception
In monitoring and operation control applications, data transmission must
often be event-driven.
Comment
Flexible control of message handling will help ensure that routine data
transmissions will not interfere with a user's other activities.
Reference
Allow users to interrupt message preparation, review, or disposition, and then resume any of those tasks from the point of interruption.
See also
3.3
In applications requiring general-purpose message handling, provide users with flexible capabilities for filing copies of draft messages during preparation, transmitted messages, and received messages, and organizing those message files.
Comment
For most information handling systems, it is probably desirable to
design the user interface so that users do not have to concern
themselves with the detailed structure of data files. For message
handling, however, users will often need to decide themselves whether
and where to store transmitted data, i.e., how messages should be
organized in their filing. Appropriate computer aids should be provided
for message storage and retrieval, to permit naming of message files,
grouping of files into larger "folders", and indexing the resulting file
structure.
Provide software capabilities to annotate transmitted data with appropriate highlighting to emphasize alarm/alert conditions, priority indicators, or other significant second-order information that could affect message handling.
Comment
Second-order information, i.e., data about data, will often aid the
handling and interpretation of messages. Such annotation might be
provided automatically by software logic (e.g., a computer-generated
date-time-stamp to indicate currency), or might be added by the sender
of a message to emphasize some significant feature (e.g., attention
arrows), or by the receiver of a message as an aid in filing and
retrieval.
Reference
Preparing messages for transmission involves specification of contents, format, and header information.
Ensure that procedures for composing messages are compatible with general data entry procedures, especially those for text editing.
Exception
In systems where special editing capabilities are available for special
tasks, as in some programming systems, users should be able to choose
whether a special computer editor will be used for message preparation.
Comment
A user should not have to learn procedures for entering message data
that are different from more general data entry, particularly if those
procedures might involve conflicting habits.
When required message formats will vary unpredictably, allow users to compose and transmit messages with a format of their own design.
Comment
Establishing new formats, particularly if automatic data validation must
be defined for specified fields, may require special skills. Therefore
this capability might be provided to a system administrator and not to
all system users.
Allow users to compose and transmit messages as unformatted text.
Comment
Allowing users to create arbitrary text messages (sometimes called
"chatter") will let users deal flexibly with a variety of communication
needs not anticipated by system designers.
When message formats should conform to a defined standard or are predictable in other ways, provide prestored forms to aid users in message preparation.
Example
A stored form might be used to create a routine report for transmission
to a standard distribution list.
Comment
It may also be desirable to allow users to modify stored forms for their
own purposes, and to define and store their own message forms.
See also
5.0/5
When data must be transmitted in a particular format, as in data forms or formatted text, provide computer aids to generate the necessary format automatically.
Comment
When transmitting data, a user should not have to convert those data
from whatever format was used originally for data entry.
Comment
It is not sufficient merely to provide computer checking of formats
generated by the user. Computers should help users to avoid errors, and
not just to identify errors.
Reference
See also
5.0/5
When transmitted text must be formatted in a particular way, format control should be automatic with no extra attention required from the user.
Example
Header/paging formats might be inserted automatically in preparing text
for transmission.
Example
Defined message formats might be filled automatically from stored text.
In preparing data forms for transmission, allow users to enter, review, and change data on an organized display with field labels, rather than requiring users to deal with an unlabeled string of items.
Comment
User composition and review of unlabeled data strings, especially those
requiring delimiters to mark items, will be prone to error. If such
data strings are needed for economy of transmission, they should be
generated by the computer automatically from data entered in a
form-filling dialogue.
Comment
Transmission of data from one computer to another will often be more
economical if field labels and other display formatting features are
omitted. In such cases, a format code should be included with the
message, so that forms filled by the sender can be re-created in a
display useful to the receiver.
In preparing tabular or graphic data for transmission, allow users to enter, review, and change data in customary formats, regardless of what the computer-imposed format will be for actual transmission purposes.
Example
Tabular data in messages should be prepared (and later received) in
row-column format, even though the table entries might actually be
transmitted as a coded string of data items.
Provide users with flexible means for specifying the data to be transmitted.
Comment
When preparing a message, a user may wish to specify data to be included
in the message by selecting a particular file, either all or a
designated part, or by defining a data category.
See also
5.0/7
Allow users to incorporate an existing data file in a message, or to combine several files into a single message for transmission.
Comment
It should not be necessary for a user to re-enter for transmission any
data already entered for other purposes. It should be possible to
combine stored data with new data when preparing messages for
transmission.
Reference
Allow users to incorporate other messages in a message being prepared for transmission.
Example
A user might wish to forward with comments a message received from
someone else.
Allow users to prepare messages of any length.
Comment
In particular, data transmission facilities should not limit the length
of a message to a single display screen or to some fixed number of
lines. There will usually be some implicit limit on message length
imposed by storage capacity or the amount of time it would take to
transmit a very long message. However, a user might sometimes choose to
increase storage or accept transmission delays in order to send a long
message required by a particular task.
Reference
Allow users to save draft messages during their preparation, or upon their completion.
Comment
A user should not be forced to recreate a message if its preparation is
interrupted for some reason. Users should be able to specify how to
save draft messages (i.e., in what file), just as they may decide how to
save copies of transmitted and received messages.
See also
5.0/9
Addressing messages may require user action and computer aids to specify the destinations for data transmission.
Allow users to specify the destination(s) to which data will be transmitted.
Exception
In some bus communication systems, it might be desirable to permit
content-driven communication, where potential recipients can request all
messages on particular topics, whether or not those messages are
specifically addressed to them.
Comment
Specification of message destination might be in terms of system users,
as individuals or groups, or other work stations and terminals
(including remote printers), or users of other systems. Standard
destinations may be specified as a matter of routine procedure, with
special destinations designated as needed for particular transactions.
Comment
For most applications, it is important that users be able to send a
message to multiple destinations with a single transmission action. For
multiple recipients, it will usually be helpful to show all addresses to
all recipients, so that they will know who else has received the
message. In some cases, however, it may be desirable to permit
transmission of "blind" copies.
See also
5.0/7
For addressing and identifying messages, provide a basic set of header fields that can be interpreted by all systems to which users will send messages.
Example
Basic header fields might include DATE, TO, FROM, COPIES, and perhaps
some message identification number.
Comment
In any particular system, it should be possible for users (or a system
administrator) to specify additions to the standard header fields in
order to convey more descriptive information about different types of
messages. Possible additions to the basic address fields might include
SUBJECT, KEYWORDS, and REFERENCES.
Reference
When a user must specify the address for a message, provide prompting to guide the user in that process.
Comment
Prompting might consist of a series of questions to be answered, or an
address form to be completed by the user, or reminders of command
entries that may be needed.
Provide users with a directory showing all acceptable forms of message addressing for each destination in the system, and for links to external systems.
Comment
In addition to the names of people, users may need to find addresses for
organizational groups, functional positions, other computers, data
files, work stations, and devices. The directory should include
specification of system distribution lists as well as individual
addresses.
Reference
Provide computer aids so that a user can search an address directory by specifying a complete or partial name.
Comment
Users will often remember a partial address, even if they cannot
remember its complete form.
Allow users to extract selected addresses from a directory for direct insertion into a header in order to specify the destination(s) for a message.
Comment
Direct insertion of addresses from a directory will avoid errors which a
user might make in manual transcription and entry, as well as being
faster.
Comment
Users may also wish to extract addresses from the directory in order to
build their own distribution lists, or add to a "nickname" file.
Allow users to define nicknames for formal addresses, to save those nicknames in their own files, and to specify those nicknames when addressing messages.
Comment
There are several implications to such a nickname capability. First, a
user might wish to assign nicknames to computers and other devices
(e.g., printers) as well as to people. Second, if a user defines a
nickname, the computer must check to ensure that the nickname is unique
in that user's nickname file. Third, nicknames must take precedence
over system names when a user addresses a message; i.e., the computer
must check the user's nickname file before checking the system-wide
address list. Fourth, nicknames should not be transmitted; i.e., the
computer should automatically transform nicknames into standard system
addresses when completing the address header for message transmission.
Provide formal distribution lists recognized by the system so that users can specify multiple addresses with a single distribution list name.
Example
A formal distribution list might be maintained of people who are working
on a particular project, or who are members of a particular
organizational group.
Comment
Recognized system distribution lists need not be expanded to the names
of individual addressees when a message is transmitted.
Comment
The authority to use system distribution lists may be limited in some
cases. For example, not everyone might be permitted to send messages to
a distribution list of all employees in a large organization.
Reference
Provide users with information about distribution lists on which they are included, and about those distribution lists which they are authorized to use.
Comment
Users should be able to discover the names of all people on distribution
lists they are authorized to use.
Reference
Allow individuals or groups to create their own informal distribution lists for local use.
Comment
Such informal group and individual distribution lists should be expanded
by the computer to show individual addressees prior to message
transmission.
Comment
As a procedural matter, informal distribution lists shared by a group
might be created and maintained by some designated custodian, who could
control access to such lists. Whereas any individual user's personal
distribution lists might be changed freely.
Reference
Within a distribution list, allow users to include other distribution lists as well as individual names.
Comment
In providing this capability, note that care must be taken to ensure
that computer expansion of nested lists will not cause continuous
looping, as in a case where list A includes list B which in turn
includes list A.
Reference
Provide computer aids to permit users to modify distribution lists once created.
Comment
Users might sometimes wish to modify their stored distribution lists, or
the distribution for any particular message. Appropriate review/change
procedures should be provided.
Allow users to enter a partial name when specifying addresses, if that will identify a particular destination uniquely.
Comment
If a partial name is ambiguous (i.e., it partially identifies two or
more addressees), then a list of the possible addressees might be
provided and the user asked to select the correct one.
Comment
The computer should automatically expand any partial address into its
full form when completing the header for message transmission.
Provide computer checks for address accuracy (i.e., recognized content and format) and require users to correct mistakes before initiating message transmission.
Comment
A transmitted message should always have correct address information.
In particular, a message sent to several people should have the correct
address for all of those people on all copies. If the sender has
specified a wrong address then no copies of the message should be sent
until that error has been corrected. Otherwise, a recipient might
attempt to reply using the same inaccurate addresses that were received,
and address errors could propagate within the system.
Comment
Ideally, address checking should occur as the user enters addresses,
when correction may be relatively easy. If that is not possible, and an
address error is not found until the user has moved on to some other
task, then the user should not be interrupted to correct the error.
Instead, a nonintrusive error message should be displayed, so that a
correction can be made at the user's convenience.
Comment
Sometimes an address error may not be discovered until a user has
requested message transmission and logged off the system. In such a
case, message transmission should be delayed until that user returns to
the system, receives a delayed notification of the address error, and
corrects it. That message delay is an acceptable consequence under
these circumstances, i.e., when a user leaves the system right after
making an error.
See also
1.7/1
If a user wishes to reply to a received message, provide the appropriate address(es) automatically, along with a reference to that received message.
Comment
The computer should address the reply to the sender of the original
message, include some identification of the original message (e.g., its
date, time, subject, and/or other identification), and should address
copies of the reply to other recipients of the original message.
Allow users to edit the address fields in the header of a message being prepared for transmission.
Comment
An editing capability will allow users to correct errors, and to change
unwanted addresses which may have been supplied automatically by the
computer.
Comment
Procedures for editing addresses should be the same as those for editing
message content.
Ensure that the address of any particular recipient will occur only once in a message.
Comment
Duplicate addresses may confuse users. Within the limits of reasonable
cost, computer checking should be provided to remove any address
duplication that might result from the overlap of several expanded
distribution lists, or from the cumulative listing of recipients of
messages replying to replies.
Comment
If duplicate addressing cannot reasonably be prevented, it is important
to ensure that duplicate copies of a message are not actually sent to
any recipient.
Comment
There might be a special situation in which a user wants to send
multiple copies of a message to a single recipient. In such a case, the
extra copies should be specified explicitly in message transmission,
rather than achieved indirectly by duplicating that recipient's address.
Reference
See also
5.4/4
In applications requiring coordinated review of messages by several recipients, allow the sender to specify a serial distribution so that a message will be passed from one recipient to the next.
Comment
Depending on the circumstances, serial recipients might or might not be
allowed to annotate a forwarded message with comments.
See also
5.1/11
Allow users to redistribute received messages by enlarging their address headers.
Comment
Here redistribution is considered to be forwarding a message without
editing or added comment, with only its address being changed. Where
this capability is provided, some means must be adopted to indicate that
a message has been forwarded verbatim, and to identify who added what
names to the original distribution.
See also
5.1/11
Initiating data transmission should usually be under user control, with computer aids for that process.
Allow users to initiate data transmission directly, by entering an explicit SEND command.
Comment
In some routine reporting situations it might help to initiate message
transmission automatically. More often, however, users will wish to
initiate transmission themselves. User control of initiation could
permit a user to review and edit prepared messages before sending them,
and possibly catch some mistakes before they are propagated.
Comment
In applications where message review is critical (perhaps for purposes
of security), users might be required to take some extra CONFIRM action
to release data for transmission.
When computer aids are provided for preparing, addressing, and initiating message transmission, allow users to review and change messages prior to transmission.
See also
6.4/2
For sending messages, allow users to choose whether to transmit a displayed version or to transmit directly from computer-stored data files.
Comment
Message transmission from displays will permit a user to review and edit
messages before sending them. But users might sometimes wish to
transmit a prepared message directly, without having first to display
that message for review.
See also
5.0/7
When standard messages must be transmitted, as when a computer is monitoring external events and reporting data change, provide computer aids to initiate transmission automatically.
Example
Many operations-monitoring tasks might benefit from automatic generation
of messages to report routine events.
Comment
Automatic transmission of routine messages will reduce user workload and
help ensure timely reporting. However, users should be able to monitor
automatic message initiation, and may sometimes wish to modify
initiation logic. Appropriate review/change procedures should be
provided, perhaps under control of a system administrator.
Allow users access to status information concerning the identity of other system users currently on-line, and the availability of communication with external systems.
Comment
Such information may influence a user's choice of destinations and
choice of communication methods, as well as the decision when to
initiate transmission. For example, a user might choose to link
directly with another user who is currently on-line, but might compose a
message for deferred transmission to an inactive user.
Reference
When a message is sent, the computer should append to it fields showing the sender's address, and the date and time of message creation and/or transmission.
Exception
Like other formatting recommendations, this guideline would not apply
when data transmission may be accomplished without formal messages,
i.e., transmission by direct linking (where no formal headers are
prepared) or by file transfer (where header information might be sent as
a separate message rather than incorporated in the transmitted data
file).
Comment
Recipients will generally need to know the origin of any received
message. For some messages, a simple identification of the sender may
be sufficient. In special situations, however, it may be necessary to
provide special procedures for authenticating a sender's identity.
Comment
For some applications, recipients must know when a message was created,
in order to assess the currency of its contents. For other
applications, users may need to know when a message was transmitted; its
time of creation might not be important.
Reference
See also
6.4/6
When messages will have different degrees of urgency, i.e., different implications for action by their recipients, allow the sender of a message to designate its relative priority, or else have the computer assign priority automatically.
Comment
The computer might impose limits on the priority that any particular
user can assign to messages. In a military system, for example, only
certain users might be authorized to send messages at the highest
priority levels.
See also
5.5/6
Provide automatic queuing of outgoing messages, in order to reduce the need for user involvement in the routine processing of data transmission.
Example
The computer might queue outgoing messages when communication channels
to some addressees are temporarily unavailable, and then initiate
transmission automatically when a link can be established.
Comment
Specific requirements will vary with the application, but some queuing
should be provided.
See also
5.0/4
Allow users to defer the transmission of prepared messages, to be released by later action.
Example
Prepared messages might be left in some "outbox" file for subsequent
transmission when a user has finished an entire batch.
Comment
A user might wish to defer data transmission until a batch of related
messages has been prepared, or perhaps until some specified date-time
for release.
See also
5.0/7
Allow users to specify a date and time for transmitting prepared messages.
Comment
A user should be able to cancel such a deferred transmission prior to
its specified initiation time.
Provide for message transmission with "return receipt requested" if users will require that capability.
Comment
The logic of what constitutes message "receipt" might vary from one
application to another. Where sender and receiver share a common
system, receipt might be defined as occurring when the recipient
actually requests display of an incoming message. Where sender and
receiver work with different (and perhaps dissimilar) message systems,
receipt might be defined more tenuously. For example, a message might
be considered "received" when the recipient is merely notified of its
arrival, or opens an "in-box" permitting potential access to that
message.
Comment
Any "registered mail" of this kind should be labeled as such for all
recipients of this mail.
See also
5.4/3
Allow senders to cancel a request for transmission of a message that has not yet been sent.
See also
3.3/3
|
5.0/7
|
5.4/8
Allow users to print copies of transmitted messages in order to make hard-copy records.
Exception
In some applications, security constraints might make printed records
inadvisable.
Comment
This may be regarded as a special case of message addressing, where a
message is sent to a printer as well as to other people.
Comment
User requirements for printed data are often unpredictable to system
designers, and so a general printing capability should be provided.
Reference
See also
2.7.1/11
|
6.2/7
|
6.4/7
Controlling transmission can often be handled automatically, but users may need information about that process.
Ensure that transmitted data are protected automatically with parity checks to detect and correct any errors that may occur, and buffering until acknowledgment of receipt.
Comment
The computer should check transmitted data to determine whether an error
has occurred; correct such errors automatically, if necessary by
requesting retransmission; and call to the user's attention any case in
which a detected error cannot be automatically corrected.
See also
6.4/1
Provide automatic feedback for data transmission confirming that messages have been sent or indicating transmission failures, as necessary to permit effective user participation in message handling.
Comment
Specific information requirements will vary with the application, but
some feedback should be provided.
Comment
Users might require notification only of exceptional circumstances, as
in the event of transmission failure after repeated attempts.
Comment
For the electronic equivalent of registered mail, it might be helpful to
provide the sender confirmation that a message has been successfully
transmitted, or possibly even to notify the sender when a recipient has
actually read (displayed) the message.
Allow users to specify what feedback should be provided for routine message transmission, and also to request specific feedback for particular messages.
Comment
Users may wish to specify minimal feedback (or perhaps none at all) for
routine message transmissions. On the other hand, users may wish to
request more specific feedback for transmission of critical messages, as
an electronic equivalent of registered mail.
See also
5.3/11
Ensure that only one copy of any message will be transmitted to any individual addressee.
Comment
Receiving multiple copies of the same message can be confusing to a
user, and will impose an unnecessary burden on the review and
disposition of received messages.
Comment
The problem of duplicative message transmission might arise if the same
address should appear in both the TO and COPY fields of a message
header, or appear once explicitly and again in some added distribution
list(s). Thus one way to avoid message duplication is to ensure only a
single appearance of each address in a message. If that is not
practicable, then checking logic should be provided to transmit a single
message to duplicated addresses.
Comment
If for any reason a user did want to send multiple copies of a message
to a single recipient, that should be specified explicitly in message
transmission, rather than being accomplished by duplicate addressing.
See also
5.2/17
In the event of transmission failure, provide automatic queuing to preserve outgoing messages.
Comment
Automatic queuing and retransmission of outgoing messages will reduce
the need for user attention. If transmission fails in repeated
attempts, however, then user intervention may be required, and some
notification of that problem should be given to the user. If
transmission fails because of faulty addressing, the user should be
notified immediately.
Reference
See also
5.2/14
If message transmission is not successful, provide automatic storage of undelivered messages.
Comment
Transmission failure should not cause loss or destruction of messages,
and should not disrupt the sender's work in any other way.
If message transmission is not successful, notify the sender and if possible include an explanation of the problem.
Comment
It may help a user to know whether transmission has failed because of
faulty addressing, or communication link failure, or some other reason,
in order to take appropriate corrective action.
Allow users to recall any message whose transmission has been initiated, if it has not yet been received by its addressee(s).
Comment
The intent here is to allow users to change their minds, in situations
where a message may have been sent by mistake. The difficulty of
message recall will vary with the circumstances. If a message is still
in the "out-box" (i.e., it has not yet actually been sent), then its
recall can be accomplished simply by canceling the transmission request.
If a message has been transmitted but not yet actually received (i.e.,
it still resides unread in a recipient's "in-box"), then perhaps it can
still be retrieved. If a message is recalled before its intended
recipient has seen it, that recipient need not be notified. If the
recipient has seen it, then the sender should be notified that the
message cannot be recalled. In that case, the message might be canceled
or countermanded procedurally, by sending some follow-up message. If a
message to several addressees has been seen by some recipients but not
by others, then it would be subject only to partial recall;
countermanding might be a better solution.
Reference
See also
5.3/12
When a log of data transmissions is required, maintain that log automatically, based on user specification of message types and record formats.
Comment
The objective here is to minimize routine "housekeeping" chores for the
user. Once a user has specified the appropriate logging format (i.e.,
what elements of each message should be recorded), computer aids should
generate the log automatically, either for all messages, or for
specified categories of messages, or for particular messages identified
by the user.
Comment
The same kind of aids should be available for maintaining a journal of
data transmissions, in applications where a full copy of each message is
required.
Receiving messages may require computer aids for queuing, reviewing, filing, or otherwise disposing of incoming data.
For receiving messages, allow users to specify from what sources data are needed, and/or will be accepted.
Comment
Source specification might be in terms of data files, or other users, or
external sources. Standard sources might be specified as a matter of
routine procedure, with special sources designated as needed for
particular transactions.
Comment
Computer-mediated message handling offers the potential for screening
out the electronic equivalent of "junk mail" or "crank calls". A user
might choose to be selective in specifying the people or organizations
from which messages will be received, or in specifying data categories
of interest.
See also
5.0/7
For receiving messages, allow users to choose the method of receipt, i.e., what device (files, display, printer) will be the local destination.
Comment
Device destination might be specified differently for different types of
messages, or for messages received from different sources. Transmitted
data might be received directly into computer files. Incoming messages
might be routed to an electronic display for quick review, and/or to a
printer for hard-copy reference.
Comment
If a specified receiving device is not operable, such as a printer that
is not turned on, the computer should call that to the user's attention.
Comment
When messages are received via display, provide queuing of incoming
messages so that they will not interfere with use of that display for
other information handling tasks.
See also
5.0/7
Provide default logic so that, unless otherwise specified by a user, the computer will route incoming messages automatically to a queue ("in-box"), pending subsequent review and disposition by the user.
Comment
Some computer buffering of received messages will be required for a user
who is not logged on, and also to deal with near simultaneous receipt of
multiple transmissions. The recommendation here is that the buffer
queue for incoming transmissions be enlarged as necessary to permit
indefinite retention of messages. Any queue will have limits, of
course, and the user should be warned before those limits are exceeded.
Reference
When users log on to a system, notify them of any data transmissions received since their last use of the system.
Comment
Depending on the application, a user might wish to know that some
message has been received, or how many messages, or what kinds of
messages.
Comment
If automatic notification of received messages is not feasible, allow
users to check for message arrival by requesting information from their
general data processing system, without having to access some special
message handling system for that purpose. At the least, a user should
be able to find out how many new messages have arrived.
Reference
For messages arriving while a user is logged on to a system, ensure that notification of message arrival will not interfere with that user's other information handling tasks.
Comment
An incoming message should not preempt a user's working display.
Instead, the computer might indicate message arrival by an advisory
notice in a portion of the display reserved for that purpose.
Comment
Review and disposition of received messages, like other transactions,
should generally require explicit actions by a user. When an incoming
message implies an urgent need for user attention, notify the user.
Reference
In applications where incoming messages will have different degrees of urgency, i.e., different implications for action, notify recipients of message priority and/or other pertinent information.
Comment
If incoming messages are queued so that their arrival will not interrupt
current user tasks, which is a good idea, then users should be advised
when an interruption is in fact necessary.
Comment
Notification of urgent messages might be routed to a special area of a
user's working display for immediate reference, whereas notification of
routine messages might be deferred, or perhaps routed to a printer for
more leisurely review at the user's convenience.
See also
5.3/7
Allow users to specify "filters" based on message source, type, or content, that will control what notification is provided for incoming messages.
Example
A user might wish the arrival of all messages from a particular source
to produce a special notification of some sort.
See also
5.0/7
If a message (or other data transmission) arrives in a format incompatible with system decoding and/or device capabilities, advise the intended recipient to take some appropriate action that will not destroy the message itself or any other data.
Example
If the user of an alphanumeric terminal should receive a message that
includes nondisplayable graphic symbols, then the computer might notify
the user and offer partial display of the readable portions of the
message.
Comment
In some instances a recipient might be able to resolve a format problem
by changing the device destination specified for a particular message.
Comment
Failure of message delivery should not disrupt any other work of the
intended recipient. For example, the arrival of some message with an
unrecognized format, or the attempted delivery of a graphic message at a
text-only terminal, should not cause any system failure. Such an
undeliverable message might be saved in a system file for subsequent
disposition. Or that message (or some notification) might be returned
to its sender.
See also
5.4/6
|
6.0/4
|
6.0/17
Allow users to review summary information about the type, source, and priority of queued incoming messages.
Comment
In some applications, a user might need notification only of urgent
messages, and rely on periodic review to deal with routine messages.
Summary information about queued incoming messages should help guide
message review.
Reference
Include in summary listings and at the beginning of each message some indication of message size.
Example
Message size might be calculated as number of lines, and indicated in
its header.
Provide some means for users to specify the order in which header fields are displayed in messages and in message summary listings.
Example
For different purposes, a user might wish to display messages with the
topic on the first line, or with the sender's name on the first line.
Example
A user might wish to scan a summary list of messages grouped by topic,
or by sender, or by priority, etc.
Comment
Users should be able to assign names to various stored header format
specifications of this kind, so that a particular desired header format
might be invoked by name.
Provide convenient means for user review of received messages in their incoming queue, without necessarily requiring any further disposition action, i.e., without removal from the queue.
Exception
In some operational applications, user review of critical messages might
be accompanied by a requirement for further actions to ensure timely
response.
Comment
Rapid review of queued messages will permit a user to exercise judgment
as to which require immediate attention, and/or which can be dealt with
quickly. Other messages may be left in the queue for more leisurely
disposition later.
Comment
A user with limited facilities for data storage might not be able to
accept for immediate filing all of the messages received during a
prolonged absence from the system. In such circumstances it seems clear
that the user should be able to review received messages before deciding
which to store in personal files.
Allow users to specify "filters" based on message source, type, or content, that can control the order in which received messages will be read.
Comment
The aim here is to facilitate flexible user control over the review of
incoming messages. In particular, a user should not be constrained to
read incoming messages in the order in which they are received.
See also
5.0/7
Ensure that computer aids and procedures for reviewing messages are consistent with other system capabilities for general data display.
Comment
Users should not have to learn procedures for reviewing messages that
are different from general data display, particularly if those
procedures might involve conflicting habits. Users should be able to
page or scroll through a summary list of messages, or a particular
displayed message, just as they might manipulate any other data display.
Users should be able to select items from a displayed summary list of
messages, just as they might select items from a displayed menu of
control options.
Allow users to assign their own names and other descriptors to received messages.
Comment
A user might wish to file received messages for future reference.
User-assigned labels could help identify a stored message and
distinguish it from other filed messages.
Comment
In the absence of labeling by a recipient, the computer might assign by
default whatever descriptors have been provided by the message sender.
Allow users to append notes to a received message, and ensure that such annotation will be displayed so that it will be distinct from the message itself.
Comment
In most applications, users should not be allowed to make changes in
received messages. Any such changes would simply provide too much
chance for resulting confusion. But users should be able to append,
file, and display in some distinctively separate form, their own
comments about received messages. If changes are desired in a message
itself, then its recipient might make a copy of that message (with
appropriate change of its header information) and then edit that copy.
Allow users to specify "filters" based on message source, type, or content, that will control how messages should be filed.
Example
A user might want to file in a single "folder" all messages about a
particular topic.
See also
5.0/9
Allow users to discard unwanted messages without filing them, or even without reading them in applications where "junk mail" may be received.
Comment
Discarding messages, like other user actions, should be reversible.
That is to say, a discarded message should be filed temporarily in some
"wastebasket" from which it could later be retrieved if the user has not
yet left the system.
Reference
Design change of software supporting data transmission may be needed to meet changing operational requirements.
When data transmission requirements may change, which is often the case, provide some means for users (or a system administrator) to make necessary changes to transmission functions.
Comment
Data transmission functions that may need to be changed include those
represented in these guidelines, namely, changes in message preparation
and addressing, the initiation and control of message transmission, and
the handling of received messages.
Comment
Many of the preceding guidelines in this section imply a need for design
flexibility. Much of that needed flexibility can be provided in initial
interface design. Some guidelines, however, suggest a possible need for
subsequent design change, and those guidelines are cited below.
See also
5.0/7
|
5.1/2
|
5.2/1
|
5.3/4
|
5.4/3
|
5.5/1
|
|
Introduction | | | Data Entry | | | Data Display | | | Sequence Control | | | User Guidance | | | Data Transmission | | | Data Protection | | | Table of Contents | | | Top |