Session 24

Effective Use of Color

810:171

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

Note: This is probably a better rule than "Don't use colors that
clash." since it tells designers what to do, rather than what not
to do!

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

Goals

To understand better the ideas of "programming in the user interface"
and extreme programming.

To understand better how to develop good user interfaces.

To understand better how to write a good design paper.

Tasks

For this task, you will work with your partner from Homework 4.

Briefly review and discuss each other's critiques.

Make a list of things that you liked better about your version of
Homework 4 than about the one you critiqued.

Then make a list of things that you liked better about the version
of Homework 4 you critiqued than about your own. Be sure to comment
on both the content and the form of the papers (75-80% content,
20-25% form).

For this task, your team will work with the rest of your team from
Exercises 34 and 35.

Construct a list of "the best things we saw in someone else's paper".
Again, your comments should reveal elements of both form and content.

Then construct a list of comments and questions that you have about
the idea of extreme programming, based on your reading, your writing
for Homework 4, and your review of someone elseUs Homework 4. Your
comments and questions can deal both with extreme programming as a
methodology and with the possibility of supporting extreme programming
with software tools.

Would you want to use any of the tools that you designed or that you read
about? Why or why not?

Results

Your group of four submits a package containing your outline, your list of
"best things", and your lists from Task 1.