Users are assumed not to be using interfaces just for the fun of using interfaces. They are assumed to be using them because they have some other goal, writing lecture notes for CS349, creating a memo that will get a raise from their boss, etc. They want to use as little mental effort as possible managing the interface, so that they can concentrate as much effort as possible on their real goal. This leads to two important principles.
To arrange this take advantage of `learning transfer':
The main tool we have for arranging these properties is look-and-feel
The obvious goal is to have the user select the correct response as effortlessly as possible. This means that an interface should communicate its metaphor as implicitly as possible; but the communication mode must be very reliable. Misunderstanding the metaphor, and at a low level of processing where processing is effectively unlimited (ie.e, effortless) can be error-prone. Fortunately, the lowest levels of communication are the most error-free; unfortunately, they are the hardest to use effectively. They utilize users' abilities to synthesize a large number of low level cues into the holistic perception of a particular environment.
Users have strong abilities to associate collections of perceptual and motor responses to particular environments. When they do so they associate a collection of specific low-level responses with a particular environment/interface. For example, when you are driving in a car, even in the passenger seat, a traffic light changing from green to yellow automatically activates fast-twitch muscles in the thigh and calf of the right leg. The same does not occur when you are walking, where you experience the same visual stimulation in a different environment.
`The collection of features we describe as an interface's look-and-feel should define it as a specific cognitive environment.' At least this would be true in a world where each interface is completely separate from every other interface and from every non-computer environment inhabited by users. But the reality is, that environments are composed of many parts and that subcollections of parts are specifically associated with subcollections of responses. Thus, environments interpenetrate each other on many levels.
As a designer, using look-and-feel consistently and comprehensively is not easily learned, and is usually the result of a lifetime of sensitivity to all the different cognitive environments we inhabit. The next few sections are only a very brief introduction to a topic that is both important and subtle.
How do we go about decorating a house?
Exercise for the reader. Turn all these - and more - aspects of the house-decorating metaphor into the corresponding features of the user interface.
What do we want in the feel of something?
Note. Most look is programmable, but the same code is not guaranteed to have the same look on different platforms. Even more so the programmable portion of feel is not guaranteed to be the same on different platforms. (The Macintosh interface, which cares more about this than any other, handles this problem by running only on one particular set of - often over-priced - hardware. The obvious generalization for this practice would be standards for hardware. Research topic. Develop ways of having reproducible feel in instances of a user interface running on different hardware configurations.)
How to create a uniform look-and-feel
Note. It is possible to appeal simultaneously to the higher and lower nature of implementers.
What we're usually talking about when discussing `look-and-feel'.
Here's the problem.
How do you arrange for this?
In Apple's case the toolkit, at first, was just added ad hoc to the graphics model.
Note. Real benefits came from a restricted `palette'.
X, on the other hand, was done by a bunch of professors and grad students.
A new thesis topic, or more likely, grant application -
Basic motive not commercial, so little attention to look-and-feel, which are for suits (marketers).
NeWS went for a Spartan look,
and much better feel,
Essential properties of widget sets.