|
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Design the data transmission procedures to minimize memory load on the user.
Interface software might provide automatic insertion into messages of standard header information, distribution lists, etc.
The computer should provide automatic queuing of outgoing messages pending confirmation of transmission, and of incoming messages pending their review and disposition.
Software might provide automatic record keeping, message logging, status displays, etc.
Design the data transmission procedures to minimize required user actions.
In some applications, software logic might prepare and transmit messages automatically, derived from data already stored in the computer.
Software logic might provide automatic reformatting of stored data for transmission, where format change is required.
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.
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.
Provide for flexible control of data transmission, so that users can decide what data should be transmitted, when, and where.
In monitoring and operation control applications, data transmission must often be event-driven.
Flexible control of message handling will help ensure that routine data transmissions will not interfere with a user's other activities.
Allow users to interrupt message preparation, review, or disposition, and then resume any of those tasks from the point of interruption.
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.
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.
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.
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.
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.
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.
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.
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.
A stored form might be used to create a routine report for transmission to a standard distribution list.
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.
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.
When transmitting data, a user should not have to convert those data from whatever format was used originally for data entry.
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.
When transmitted text must be formatted in a particular way, format control should be automatic with no extra attention required from the user.
Header/paging formats might be inserted automatically in preparing text for transmission.
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.
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.
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.
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.
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.
Allow users to incorporate an existing data file in a message, or to combine several files into a single message for transmission.
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.
Allow users to incorporate other messages in a message being prepared for transmission.
A user might wish to forward with comments a message received from someone else.
Allow users to prepare messages of any length.
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.
Allow users to save draft messages during their preparation, or upon their completion.
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.
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.
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.
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.
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.
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.
Basic header fields might include DATE, TO, FROM, COPIES, and perhaps some message identification number.
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.
When a user must specify the address for a message, provide prompting to guide the user in that process.
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.
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.
Provide computer aids so that a user can search an address directory by specifying a complete or partial name.
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.
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.
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.
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.
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.
Recognized system distribution lists need not be expanded to the names of individual addressees when a message is transmitted.
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.
Provide users with information about distribution lists on which they are included, and about those distribution lists which they are authorized to use.
Users should be able to discover the names of all people on distribution lists they are authorized to use.
Allow individuals or groups to create their own informal distribution lists for local use.
Such informal group and individual distribution lists should be expanded by the computer to show individual addressees prior to message transmission.
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.
Within a distribution list, allow users to include other distribution lists as well as individual names.
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.
Provide computer aids to permit users to modify distribution lists once created.
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.
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.
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.
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.
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.
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.
If a user wishes to reply to a received message, provide the appropriate address(es) automatically, along with a reference to that received message.
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.
An editing capability will allow users to correct errors, and to change unwanted addresses which may have been supplied automatically by the computer.
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.
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.
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.
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.
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.
Depending on the circumstances, serial recipients might or might not be allowed to annotate a forwarded message with comments.
Allow users to redistribute received messages by enlarging their address headers.
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.
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.
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.
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.
For sending messages, allow users to choose whether to transmit a displayed version or to transmit directly from computer-stored data files.
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.
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.
Many operations-monitoring tasks might benefit from automatic generation of messages to report routine events.
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.
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.
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.
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).
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.
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.
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.
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.
Provide automatic queuing of outgoing messages, in order to reduce the need for user involvement in the routine processing of data transmission.
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.
Specific requirements will vary with the application, but some queuing should be provided.
Allow users to defer the transmission of prepared messages, to be released by later action.
Prepared messages might be left in some "outbox" file for subsequent transmission when a user has finished an entire batch.
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.
Allow users to specify a date and time for transmitting prepared messages.
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.
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.
Any "registered mail" of this kind should be labeled as such for all recipients of this mail.
Allow senders to cancel a request for transmission of a message that has not yet been sent.
Allow users to print copies of transmitted messages in order to make hard-copy records.
In some applications, security constraints might make printed records inadvisable.
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.
User requirements for printed data are often unpredictable to system designers, and so a general printing capability should be provided.
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.
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.
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.
Specific information requirements will vary with the application, but some feedback should be provided.
Users might require notification only of exceptional circumstances, as in the event of transmission failure after repeated attempts.
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.
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.
Ensure that only one copy of any message will be transmitted to any individual addressee.
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.
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.
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.
In the event of transmission failure, provide automatic queuing to preserve outgoing messages.
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.
If message transmission is not successful, provide automatic storage of undelivered messages.
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.
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).
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.
When a log of data transmissions is required, maintain that log automatically, based on user specification of message types and record formats.
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.
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.
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.
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.
For receiving messages, allow users to choose the method of receipt, i.e., what device (files, display, printer) will be the local destination.
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.
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.
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.
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.
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.
When users log on to a system, notify them of any data transmissions received since their last use of the system.
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.
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.
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.
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.
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.
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.
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.
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.
Allow users to specify "filters" based on message source, type, or content, that will control what notification is provided for incoming messages.
A user might wish the arrival of all messages from a particular source to produce a special notification of some sort.
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.
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.
In some instances a recipient might be able to resolve a format problem by changing the device destination specified for a particular message.
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.
Allow users to review summary information about the type, source, and priority of queued incoming messages.
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.
Include in summary listings and at the beginning of each message some indication of message size.
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.
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.
A user might wish to scan a summary list of messages grouped by topic, or by sender, or by priority, etc.
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.
In some operational applications, user review of critical messages might be accompanied by a requirement for further actions to ensure timely response.
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.
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.
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.
Ensure that computer aids and procedures for reviewing messages are consistent with other system capabilities for general data display.
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.
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.
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.
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.
A user might want to file in a single "folder" all messages about a particular topic.
Allow users to discard unwanted messages without filing them, or even without reading them in applications where "junk mail" may be received.
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.
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.
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.
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.
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 |