"To use the computer as a transformation device is to use it on a trivial level. It is a completely general symbol-manipulating device and allows the writer of a program essentially to define what the machine is any way he or she chooses. That generality gives the computer a very special significance as the first modern device which allows itself to be used as a sort of do-it-yourself design kit, rather than as a single fixed-function tool."
— Harold Cohen1
• the task to be performed and the facilities the system brings to performing it (that is, what you're trying to do and what the underlying system actually does),
• the intended users' intellectual and physical characteristics, and
• the channels available for communicating with the system.
• Predictability. Although users might have the right to do lots of different things at any point, in reality, they tend to do some things a lot more than others. For example, in a messaging system, the user is much more likely to send or review a message immediately after composing it than to change his password. This is not to imply that the system should prevent users from changing their passwords at that point, but that it should make sending or reviewing the message easier to accomplish at that point than changing passwords. If one action is sufficiently likely, the designer can make it the default action, to be invoked by the simplest command (or even without explicit command).
• Type constraints. If we know what kind of parameters to expect, we can ease the task of specifying them. Default values, spelling correction, and completion are all interface mechanisms to aid in this activity.
• Clustering. While we might not generally be able to predict which command a user will invoke, certain applications find particular clusters or paths of commands.
• Concurrence with other tasks. If my routine consists of concurrently text processing and communicating (on the same equipment), then it is important that switching between these tasks be easy and inexpensive.
• Functionality. So far, we've blithely assumed that the underlying system is capable of doing whatever the task calls for. Having the desired functionality correctly implemented is crucial as, without it, all (or almost all) is lost.
• Permanence. Most character and graphic output devices exhibit an intermediate degree of permanence — that is, what is written remains on the screen until something new comes along to overwrite it. This contrasts with sound-based output, which the user needs to catch as it happens (or it's no longer there) and hardcopy output, which lasts indefinitely (or least until it's buried under something else on your desk). Another variety of indefinite information is embodied in the device's physicality. For instance, my computer doesn't need to periodically remind me which key is the shift key because it's labeled "shift."
• Capacity. Paralleling the permanence of output is capacity — how much information (in what varieties) can be shown at a given time. Capacity can be a mixed blessing, because a large capacity invites the interface designer to dilute a given communication's focus (recall our grad student from last issue who was intent on filling the screen with information).
• Bandwidth and latency. Latency refers to how long it takes before a system can respond. Bandwidth refers to how much information can be transferred in a given time period. Computers have gotten fast, limited only by interface designers' ability to invent things that take too long to do.
• Precision. On output, how precise a depiction can I create? Am I limited to letters at prespecified locations, or do I have high-density, color, bitmap graphics? Is the sound quality limited to single frequencies or symphonic? On input, can I read mouse coordinates, or am I restricted to recognizing keystrokes?
• Accuracy. How noisy are the input and output channels? Sufficient noise forces the interface designer to validate inputs and present output redundantly.