Session 24

Effective Use of Color


Software Systems

Recap Session 23: Presentation

In Exercise 34, we mined our experience to find applications of Shneiderman's guidelines for error messages. A good time was had by all, because we've all made more errors than we can remember and error messages--both good and bad--can be so memorable. We found that Shneiderman's rules really do account for what makes an error message seem good or bad, though bad rules are often characterized by the lack of particular traits, while good messages are often characterized by the presence of other particular traits. And we found that these characteristics hold even for us, who are experienced, savvy users, and not just for naive users. There must be something to what Shneiderman is telling us.

In Exercise 35, you are beginning to consider how the use of color affects the user's experience...

Summary of Exercise 35

What issues must we consider that are specific to the Web?

Here are some sample rules that students often give:

On almost all web pages, color is a secondary device, not solely responsible for conveying meaning, only meant to reinforce the meaning in a text or other element of a document.

A rule exists because not following causes a problem. What is the problem addressed by each of your rules?

A rule applies in a particular context. Narrower rules--rules that apply in fewer situations, a narrower context--will have fewer exceptions, but they will also be less generally useful. Beware of rules with no exceptions--and rules with too many!

This is yet another exercise in marshaling evidence to support a position -- and finding exceptions to our positions.

The bottom line is: if you don't think about these things, you will end up implementing your personal biases, with no other reason to think that you have done a good job.

Exercise 36


  1. To understand better the ideas of "programming in the user interface" and extreme programming.
  2. To understand better how to develop good user interfaces.
  3. To understand better how to write a good design paper.



  1. Your group of four submits a package containing your outline, your list of "best things", and your lists from Task 1.
  2. We will discuss some of your observations.

Summary of Discussion

Not yet...

Eugene Wallingford ==== ==== April 5, 2001