Analysis of Evaluation

The function of the cancel button is unclear.

The functionality of the cancel button was incompletely specified in the initial design phase. The cancel button was intended to provide the user with the ability to back up one step in the transaction (i.e. previous screen). The exceptions to this functionality occur during and after a financial transaction. If the user cancels the operation in the middle of the financial portion of the transaction (where the user is entering money into the system) it is presumably because he has changed his mind about completing it (because, say, he is out of change, say), and is instead returned to the main menu instead of backing up a step (with the appropriate instructions to retrieve any money or credit card put into the system). If the users cancels after a transaction is complete, backing up a step would essentially be a request to repeat the transaction, so this button is disabled at this point, and the standard error tone/warning message will be given should the user attempt to cancel after a transaction is complete and before a new one is begun.

There exists no means for the user to navigate between screens or back up to the previous screen.

Given the nature of the transactions, which are linear in nature (and therefore jumping from point to point does not make sense) as well as reasonably short, such navigation was explicitly omitted from the design by the design team in the interests of structuring the interaction between the user and machine to prevent mode errors. The lack of navigation to the previous screen is addressed by the cancel button, described above.

There is a general lack of instruction in the system.

The initial design stated that textual as well as schematic instruction appear onscreen during the steps of the transaction. Some of the options have been reworded to provide greater information to the user.

There is no timeout for the system.

This was not considered in the initial design, but has been added to the revision.

The system does not provide error solutions to the user when an error is made.

The possible errors commitable in the system are incorrect option selection, which occurs when the user makes a choice other than the one desired from a menu selection, or improper input for those transactions which require the input of numerical data (quantity of stamps, dollar amount of postage). In either case, the ability to terminate the current transaction by halting it entirely (via the quit button) or to back up a step by pressing the cancel button are always available to the user. However, the system is unable to distinguish the actual intention of the user, so no error solutions can be provided, since the machine must assume that the user's inputs are those intended. Our approach to this problem is to draw as clear a mapping between actions and the interface as possible so that the user does not make these errors in the first place.

There is a lack of feedback informing the user of system state as TURBOMail is processing information or completing a transaction or function.

This functionality was intended for the initial design, but was omitted from the specification by oversight. Pending operation messages have been added to the revision.

There is a lack of shortcuts which allow the user to perform frequently requested transactions.

The initial design addressed this problem in its discussion of design trade-offs for the system. Shortcuts in general were omitted from the design due to the relative shortness of transactions; the design team did not feel that the minimal marginal time savings afforded the user outweighed the cost of additional (possibly confusing) choices to be provided to the user. Currently, there is no ambiguity in buying stamps, since the user explicitly enters a number value on the keypad indicating the number of stamps to purchase. A single key option (to buy one stamp, or a dozen stamps) would mean that the user would have to choose between either the button array next to the screen or the keypad -- a situation with ambiguous methods for input. To eliminate this ambiguity would require a separate screen for keypad entries, which in turn lengthens by an additional screen the transaction for arbitrary numbers of stamps. Rather than sacrifice the efficiency of one transaction for another, shortcuts were omitted from the final design.

There is no option that allows the user to buy the maximum number of standard stamps, receiving change.

This was discussed in the initial design; the interview with post office personnel indicated that buying patterns are typically based on a quantity of stamps, rather than asking for the number of stamps possible from a particular amount of money.

The operation of the scale door is not fully explained.

The operation of the door is explained to the user by text instructions and a schematic or animated picture in the interface. The actual operation of the door (whether locking or not, etc.) was considered to be outside the scope of the design, since it does not deal with the transaction interface presented to the user.

The keypad mapping is inconsistent with ATM and telephone designs.

The design has been revised to use the more standard telephone layout rather than the calculator/keyboard number arrangement.

No description is given for how the package or parcel is released from the weighing pan after weighing.

Instructions are given by the system instructing the user how to remove the parcel from the system. Again, the logistics of door locking and unlocking, etc. are considered beyond the scope of the project.

The enter button is not described in the documentation.

The enter button is used to complete the entry of a quantity of stamps, as per similar keys on ATM machines.

It is not specified where the receipt comes from.

The actual layout of the various component devices of the system was not specified in the initial design. However, the screens which inform the user about the next step in the transaction should display text and schematics which instruct the user where the receipt can be found.

Is there a limit on the amount of stamps that can be purchased?

There should be no theoretical limit on the number of stamps, as long as the machine has sufficient stock in quantity (we assume that the machine is refilled regularly, and that it has a means of detecting the remaining number of stamps in the system). If the user does not enter a value for the number of stamps (or enters zero), an error will be displayed instructing him to enter the number of stamps again. If the user wishes to purchase 5000 stamps, the machine should allow him to do so. He will, however, have to pay for them.

What is the use of the clear button?

The clear button allows the user to clear a numeric value entered into the system (either a numeric quantity of stamps, or a dollar value). This button is disabled the remainder of the time.

Does the user have the option of purchasing postage labels instead of stamps?

Postage labels are returned for either postage bought as a result of a parcel weighing, or a transaction which requested a specific dollar amount of stamps. Primarily, this is to avoid having to return odd combinations of stamps, and requiring the user to mentally calculate the totals to insure that the proper amount of postage was received. A secondary function is to prevent the user from having to lick too many stamps.

Is there a screen that specifically prompts the user to choose the type of payment (i.e. cash or charge)?

Both forms of payment may be used simultaneously, although the use of a credit card will immediately be applied toward the remaining balance of the transaction. Cancelling the transaction will return both any money inserted into the system as well as the user's credit card.

Is there a mail slot for the user to place mail once the postage has been affixed?

Although this is outside the scope of the project, it was decided that the TURBOMail system would not handle the actual accepting of mail, since it would not be guaranteed that sufficient space would exist to accept all of the items in a system which is designed to fit into a wall-unit sized space. The TURBOMail system was designed to be placed in areas near mailboxes, so the mailbox would perform all of the mail repository tasks.

Why doesn't the system affix postage automatically?

This is beyond the scope of the project. In any case, this is a nontrivial task, because it requires object recognition and manipulation.

There is a potential problem with audio feedback due to noise generated.

The proper volume levels must be determined by usage tests; this, however, should not deter us from using sound in our design.

How has access to handicapped users been addressed?

It was intended in the original design to address system height, usage of Braille buttons for blind users, etc., but this requirement has been removed from the final design to allow the design greater focus on the interface itself.