Michael Chisholm
CS552
Spring '98

1. The device model must allow users to reason about the device.
(Use words people can easily understand and icons that represent familiar objects.)

• Explanation: The "device" that the user interface designer is trying to model is the software the user is interfacing with, including the user interface itself. If the device model is too complex or too abstract, the user will not be able to infer procedures for doing things from the model.
• Example: A "tree" model for a directory or menu structure is a fine and natural one for computer scientists, but the average user may not be adept at reasoning about trees. So trying to explain to a user what a tree is when explaining how a menu or directory structure works is probably not the best thing to do. An example of a better approach for a directory structure might be to portray it as a desktop with folders lying on top of it and within other folders, since folders and desktops are familiar everyday things that more people will be able to reason about.
• Exceptions: None - the user will be able to do very little if he has no usable device model. Of course, the model you choose will depend on who the anticipated users of your software are. It's probably a safe assumption that users of Emacs have experience with trees, but not users of MS Word.

2. An incomplete or superficial device model is okay, as long as it allows users to effectively use the device.
(Don't worry if your interface doesn't reflect the way the software is actually implemented, as long as it isn't misleading.)

• Explanation: Since the users may not be able to understand the true implementation details and concepts behind the software they are using, it may be necessary to simplify the model, and/or make it more concrete by translating it into another model that uses everyday objects and language that the users can understand. And this is okay - the goal of this is make your software as easy to learn to use as possible.
• Example: Using the above example, directory and menu information is of course not stored inside a computer in "folders" or on any "desktop". It is stored hierarchically, in a tree structure. So the folder/desktop model is a superficial model, in that operations on folders have analogous operations on tree structures, but it is not the "true" model.
• Exceptions: Would an incomplete or superficial device model ever be okay, that didn't allow users to effectively operate the device? Again, unless you don't care how usable or easy to learn your software is, you always want a device model to have the quality that it allows users to use the device (the software) effectively.

  Would an incomplete or superficial user interface ever be a bad thing, even if it allows the users to effectively use the device? In this case, the answer is yes. More advanced users might get frustrated with overly simplified models. Someone capable of understanding the underlying structure of the software may actually find it awkward, or may find it takes longer to get things done (consider experienced Unix users, who are very fast and efficient using simple command-line based interfaces and would find most point-and-click interfaces too constraining, vs Macintosh users who are used to pointing and clicking and would probably find the Unix command-line interface utterly baffling). And more adventurous users might find that upon delving deeper into the software that an incomplete model hinders their ability to learn to use other parts of the software. For example, consider the 'wizard', a common tool used in modern software to lead novice users through the steps needed to do some particular task. Many wizards have the effect of just leading the user by the nose through a maze of procedures. At the end, the user may have the feeling that they haven't learned anything at all about how the steps fit together, how the software actually works, or about why they were led to do the things they were led to do.

3. A device model is not always necessary.

• Explanation: If the user is only doing a small number of simple tasks, then there may be no need for inference (e.g. memorization might be adequate). Also, if the device is simple enough, then the user maybe be able to construct his own device model sufficient for inference.
• Example: If a user only needs to print an order, say, when it pops up on his screen, then it is probably enough to know that you first go to the "File" menu and click, then go to "Print" and click, and then wait for the printout to magically come out of the printer. No model of the device is needed to perform this operation.
• Exceptions: Not every task requires a device model to learn, as shown in the above example, therefore the statement is always true. But for less simple interfaces where the user may not be able to create his/her own model, learning to do a task may end up being an exercise in memorization rather than understanding, and may leave users ultimately dissatisfied with the software.