Chapter 5

The Design Process

5.1 Can you think of any instances in which the 'noun--verb' guideline for operations, as suggested in the Apple human interface guidelines for the Desktop Interface, would be violated? Suggest other abstract guidelines or principles besides consistency that support your example. (Hint: Think about moving files around on the Desktop.)

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 dialogue 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 dialogue is complete, the user then indicates that it is OK for the system to perform the operation. This kind of form-filling dialogue subscribes to neither the noun--verb or verb--noun guideline; the order is more flexible for the user than consistent.

5.2 Can you think of any instances in which the user control guideline suggested by Apple is not followed? (Hint: Think about the use of dialogue boxes.)

answer

The user control guideline states that, 'The user, not the computer, initiates and controls all actions.' In the case of dialogue boxes, this guideline is clearly contradicted. A dialogue 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 dialogue box, the only action that the system allows the user is to acknowledge the error and dismiss the dialogue box. The system preempts the user dialogue, with good reason. The preemptive nature of the dialogue 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 dialogue 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 dialogue 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 dialogue 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.

5.3 Find a book on guidelines. List the guidelines that are provided and classify them in terms of the activity in the software life cycle to which they would most likely apply.

answer

We use as a source of guidelines Mayhew's book Principles and Guidelines in Software and User Interface Design [154]. 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 dialogue 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)

Worked exercises

• Look up and report back guidelines for the use of colour. Be able to state the empirical psychological evidence which supports the guidelines. Do the guidelines conflict with any other known guidelines? Which principles of interaction do they support? [page 197]

• Starting with some of the principles outlined in Chapter 4, provide a usability specification for an electronic meetings diary or calendar. First identify some of the tasks that wouId be performed by a user trying to keep track of future meetings, and then complete the usability specification assuming that the electronic system will be replacing a paper-based system. What assumptions do you have to make about the user and the electronic diary in order to create a reasonable usability specification? [page 203]

• What is the distinction between a process-oriented and a structure-oriented design rationale technique? Would you classify psychological design rationale as process or structure oriented? Why? [page 219]

HCI 2e home page || changes and additions || resources || search || contents || authors || ordering
feedback to feedback@hcibook.com http://www.hcibook.com/hcibook/	designed and hosted by hiraeth mixed media webmaster@hiraeth.com