CHAPTER 7
design rules

answer

To demonstrate the principle of synthesizability within learnability, it was stated in this example that a visual interface to a file management system provided immediate information about the changed location of some file after a move operation performed by the user. In contrast, a command language interface requires the user to remember the directory to which a file is moved and explicitly issue commands to browse the directory to verify that the file has been moved. To be really sure that a move occurred, the user would also have to browse the original directory to determine that the file was no longer there. The fallacy in this argument is the assumption that visual file management systems always provide information about the new whereabouts of a moved file. To take a counterexample using the Macintosh instance from the text, if a file is moved from an open folder (in which the contents of the folder are revealed to the user) to a closed folder (contents not revealed), then the location of the moved file is not indicated to the user unless she remembers to open up the destination folder to reveal its contents. This is an example of eventual honesty and not immediate as the example suggests.

We could 'fix' this problem of eventual honesty for the visual system by demanding that the destination folder be an open folder (probably too restrictive, given the limited screen size) or by having the destination folder temporarily open up to reveal that the file is now located within it. This last suggestion is also a bit tricky, for we might still want to determine that the file no longer resides in the original folder, so we would have to be sure that the new folder did not obstruct the view of the old folder. In practice, this might be too difficult to guarantee in general.

answer

The discussion of consistency suggested that it can take many forms, because it is usually referred to in relation to some other feature of the interaction between user and system. Mentioned already in the text we have consistency related to the following principles:

• Familiarity - consistency with respect to prior real-world experience
• Generalizability - consistency with respect to experience with the same system or set of applications on the same platform

In addition, we could interpret some other principles as contributors to consistency:

• Affordance - consistency with understood intrinsic properties of an object, so a soft button on the screen should allow us to always 'push' on it to select some action
• Predictability - consistency of system response with user's expectation, given the user has some information about past interaction history
• Substitutivity - consistent permission from system to allow use of equivalent values for input and output
• Commensurate effort - consistency of effort with respect to doing and undoing tasks
• Response time stability - consistency of system response for similar actions

Some other principles for consistency from the text and elsewhere:

• Consistency can be relative to the form of input/output expressions relative to the user's conceptual model of the system. An example in the text involves using keys whose relative positions are similar to commands for the systems (any set of four typewriter keys that form a diagonal to indicate up, down, left and right information for an input command).
• As discussed in the exercise on colour, consistency can be with respect to social or cultural conventions (e.g., using red to indicate stop or hot, green for go, blue for cool).

answer

open-ended research

answer

The noun-verb guideline suggests that we can view all operations that the user will perform as being composed of an action (the verb) acting with one argument (the noun). In the case of moving a file (or copying, for that matter), the action (move or copy) requires more than one argument. The way the move operation is performed requires the user first to select the icon for the file to be moved and then to indicate the move operation implicitly by dragging the selected icon to the destination folder. The nouns in this dialogue are the file to be moved and the destination folder. The verb is the move operation. The natural way to express this is in the order noun-verb-noun. Strictly speaking, in order to stick with the noun-verb guideline, we would have to indicate both the target file and the destination folder before indicating the move operation. That would be consistent, relative to input expression, with most other commands on the desktop. However, some principles of direct manipulation and familiarity to the user are more important. Moving files by dragging them on the desktop is very similar to the way we can pick up any object in the physical world and move it to its new location. And the dragging operation is incremental and easily recoverable; moving to one place can be undone within the same operation since the dragging can continue until the file is released.

The file-moving example is a slightly contrived one, because some could argue that there is no violation of the noun-verb guideline (hence, moving is still consistent with respect to input expression) because the verb is 'move to destination folder'. Perhaps a better example is a command to search a file system for files matching some specification. Here, the action is to do the qualified search and the argument or noun is the set of folders or volumes of the system that you want searched. Typically, this kind of operation is defined by some dialog box that allows the user to indicate in any order the specifics of the operation (the search parameters) and the folders or volumes to search. Once this unordered dialog is complete, the user then indicates that it is OK for the system to perform the operation. This kind of form-filling dialog subscribes to neither the noun-verb or verb-noun guideline; the order is more flexible for the user than consistent.

answer

The user control guideline states that, 'The user, not the computer, initiates and controls all actions.' In the case of dialog boxes, this guideline is clearly contradicted. A dialog box can be used to indicate when an error occurs in the system. Once this error has been detected and presented to the user in the dialog box, the only action that the system allows the user is to acknowledge the error and dismiss the dialog box. The system preempts the user dialog, with good reason. The preemptive nature of the dialog box is to ensure that the user actually notices that there was an error. Presumably, the only errors that will be produced in such an intrusive manner are ones which the user must know about before proceeding, so the preemption is warranted. But sometimes dialog boxes are not used to indicate errors and they still prevent the user from performing some actions that they might otherwise wish to perform. The dialog box might be asking the user to fill in some information to specify parameters for a command. If the user does not know what to provide, then they are stuck. A lot of the time, the user can find out the information by browsing through some other part of the system, but in order to do that they must exit the dialog box (and forfeit any of the settings that they might have already entered), find out the missing information and begin again. This kind of preemption is not desirable. It is probably this kind of preemption the user control guideline is intended to prevent, but it doesn't always get applied.

answer

We use as a source of guidelines Mayhew's book Principles and Guidelines in Software and User Interface Design [230]. In general, all guidelines offer constraints on the design activity and so should be known during the requirements phase. In the following list, we will concentrate on what other stages (architectural design, detailed design, coding and unit testing, integration and testing) will be most affected by the guidelines. The numbers in parentheses indicate the page reference for the given guideline.

Architectural design

• Present functionality through a familiar metaphor. (97)
• Provide similar execution style of analogous operations in different applications. (97)
• Organize the functionality of a system to support common user tasks. (442)
• Make invisible parts and processes visible to the user. (95)

Detailed design

• Consistent dialog style for different functions. (97)
• Match menu structure to task structure. (144)
• Create logical, distinctive and mutually exclusive semantic categories with clear meanings. (150)
• Design and organize a fill-in form to support the task. (184)
• Consider voice synthesis as an output device when the user's eyes are busy, when mobility is required, or when the user has no access to a workstation or screen. (427)

Coding and unit testing

• On full-screen text menus, present menu choice lists vertically. (148)
• In a fill-in form, use white space to create a balance and symmetry and lead the eye in the appropriate direction. (186)
• Avoid frequent use of shift or control keys. (256)
• Place high-use function keys within easy reach of the home row on the keyboard. (281)

Integration and testing

• Allow full command names and emphasize them in training, even if abbreviations are allowed. (261)

answer available for tutors only

answer available for tutors only

answer

project