cs349 - s10 - Lecture 17

CS349 - Implementing User Interfaces - Spring 2010

Public Service Annoucements

  1. Mid-term: 17 June, 2010, MC4059.

Lecture 17 - Users II

Exploiting What Users Know

Two user interface design objectives

1. Consistency.

Exploit the skills users already have with computers.

2. Congruence.

Much meaning is created by analogy, often called metaphor in the user interface community.

What English scholars call `not mixing your metaphors' lies very close to what is meant by congruence.

Congruence exists at high and low levels.

At the basis of these objectives

  1. What do users know?
  2. How do users learn beyond what they know?


Ways of changing knowledge = `learning'

Techniques of learning

  1. Trial-and-error: putting on a nut, riding a bicycle
  2. Practice = rehearsel: using a hammer, playing the piano.
  3. How-to-do it descriptions: cookbook recipes
  4. Modification of examples: making html pages
  5. Solving a problem: and remembering that we did it.

All these take time.


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.

  1. The less learning users have to do the better.
  2. The less thinking user have to do the better.

To arrange this take advantage of `learning transfer':

  1. within an interface
  2. between one interface and another
  3. between an interface and life

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 aa 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.

Doing the best thing 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

  1. UI architect
  2. User interface toolkit
  3. Widely understood metaphor

Note. It is possible to appeal simultaneously to the higher and lower nature of implementers.

User Interface Toolkits - A history

What we're usually talking about when discussing `look-and-feel'.

Here's the problem.

How do you arrange for this?

  1. Model for inter-application cut-and-paste. (Clipboard, scrapbook).
  2. Common look-and-feel, which means using a common set of rules and operations.

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,

Widget Sets

Essential properties of widget sets.

Return to: