1 Subject Matter

Twenty or thirty years ago, graphics was a specialty field within computer
science, of interest only to developers of video games (at the low end)
and powerful CAD/CAM packages (at the high end). Indeed, the only programs
that did any significant graphics were programs about graphics; it
would have been considered a waste of expensive hardware resources to use it on
trivialities like the user interface. But as processors and memory became
cheaper, and humans became more expensive, it became reasonable to spend
some processor power to make the human user's time on the computer more
pleasant and more efficient. Today, nobody would seriously consider
releasing a commercial software application without a graphical user
interface, or GUI.

But a GUI, by its nature, connects two disparate worlds: it has a computer
on one side, and a human on the other. Accordingly, a good GUI must take
into consideration both technical, implementation issues and
psychological/ergonomic design issues. This course attempts to address
both.

The techniques we discuss this semester can be carried out in almost any
programming language (although some of them are easier in an
object-oriented language, or a language that allows the passing of
functions as parameters to other functions). But in the interest of
consistency and standardization, I plan to work in Java. Its syntax is
similar to that of C and C++, its object model is similar to (though
simpler than) that of C++, and it has a standardized API for both
low-level graphics (lines, circles, etc.) and predefined graphical user
interface components (buttons, menus, etc.)

2 Prerequisites

This course assumes you have taken and passed CSC 172 (or the equivalent,
i.e. a year of freshman programming courses), preferably in Java, and
CSC/MTH 156 (Discrete Structures). If you've had a year of freshman
programming in C++, you'll need to learn some Java in a hurry, but it
should be feasible. See me if you're not sure whether you're prepared for
the course.

3 Texts

The primary textbook for the semester is About Face 2.0, by Alan
Cooper and Robert Reimann, J. Wiley 2003, ISBN 0764526413.
We'll get through maybe half of the book,
but you'll probably want to look up some specific topics
yourself in the other half, and keep the book for reference in future
software projects. This book is about how to design a user interface,
not how to implement it in code, so for Java coding techniques,
we'll use a number of on-line tutorials written by the people at Sun
Microsystems.
You are responsible for everything
in the reading assignments, whether or not I discuss it in a lecture.

Some other recommended books, not specifically assigned for this course:

Borenstein, Nathaniel, Programming as if people mattered,
Princeton University Press 1991, ISBN 0691037639.

Isaacs, Ellen, and Alan Walendowski, Designing from both sides
of the screen, New Riders Publishing 2002, ISBN 0672321513.

4 Homework

An essay on good and bad qualities of a user interface
you have used or created.

Homework 2a

Design and specify the user interface for a program
assigned by the professor. Write a brief user's manual.

Homework 2b

Implement the user interface one of your fellow
students designed. You may consult with the designer to clarify
requirements, but any change to the requirements must be logged,
dated, and approved by the designer, who must update the user's manual
accordingly.

Homework 2c

Test-drive the program one of your fellow students
designed and another implemented, using the user's manual but not looking
at the source code, and write a review. Note places that the program
disagrees with the user's manual, and places that the interface seems
difficult, inefficient, or counterintuitive to you. Assign a letter
grade.

Homework 3a

Find a problem to be solved that calls for a GUI. This
may be a program you want yourself, or (better) one that a friend, another
professor, a family member, your employer, etc. wants. This project
should be larger than that in homework 2; check with me on its scale.
Design and specify the user interface, and write a brief user's manual.
Present your user interface to the class.

Homework 3b

Like homework 2b.

Homework 3c

Like homework 2c.

Homework 4

Post-mortem the whole semester: what did you learn, what
did you do well/poorly, what did your fellow students do well/poorly, what
did the professor do well/poorly (this is the first time I've taught the
course, so I really do want to know!)

5 Grading

Your semester grade is computed as follows:

10% homework 1,

30% homework 2,

40% homework 3,

10% homework 4,

10% final exam,

and modified up or down by ``brownie points''. You earn positive brownie
points by asking or answering good questions in class, by interacting well
with classmates, by coming to me for help when you need it, etc. You earn
negative brownie points by cheating, by being a pain in class, etc.
Your grade on HW2 and HW3 is computed as follows:

40% part a,

40% part b,

20% part c.

Your grade on HW2a is computed as follows:

50% my assessment of your UI spec,

20% my assessment of the program written from your UI spec,

30% another student's review of the program written from your UI spec.

Your grade on HW3a is computed as follows:

30% my assessment of your UI spec ,

20% my assessment of your in-class presentation,

20% my assessment of the program written from your UI spec,

30% another student's review of the program written from your UI spec.

Your grade on HW2b and HW3b is computed as follows:

60% my assessment of the program you wrote (including how well it
conforms to the spec, as well as program design & coding style),

40% another student's review of the program you wrote.

Your grade on HW2c and HW3c is my assessment of your review: is it careful,
detailed, correct, etc.? Is the ``letter grade'' you assigned consistent
with your comments?

The exam must be taken at the scheduled time, unless arranged in advance
or prevented by a documented medical or family emergency. If you have
three or more exams scheduled on the same date, or
a religious holiday that conflicts with an exam or assignment due date,
please notify me in writing within the first two
weeks of the semester in order to receive due consideration.
Exams not taken without one of
the above excuses will get a grade of 0.

6 Late homework policy

Homeworks 2a, 2b, 3a, and 3b must be turned in on time, as one of
your fellow students needs them to start on his/her next assignment. If
nothing is turned in by the due date, you have a zero on the assignment.
This means

Start early.

Write a sequence of versions, each adding just a little over the
previous one, so if one doesn't work out by the deadline, you can turn in
the previous (working) version.

Exceptions will be considered on an individual basis due to illness, etc.
and will be viewed more sympathetically the more advance notice you give
me.
For the sake of consistency, I'll apply the same Draconian principle to
the other homework assignments: turn it in on time or get a zero.

Programs are not abstract works of art,
they are supposed to run and solve real problems. So if I get a program
that doesn't compile or run, or a program that has little or nothing to do
with the problem I assigned, I will give it a zero, no matter how much
time you put into it. Don't bother turning in a program you haven't
tested yourself.

7 How to Learn GUI

This is not a theoretical course; it is a very practical, hands-on
course.
To learn the stuff I expect you to learn, you must spend a lot of
time on the computer trying things. Every time you read about a
new API feature, or hear me describe one in lecture, try it in
a program.
Invent new ways to use it, beyond what I or the textbook have
described. Play with it.
Although I'll assign several programs to
write and turn in, I expect you to have written, debugged, and run many more
than that by the end of the semester, since that's the only way to check
how much you really understand.

8 Ethics

All homework assignments in this course are to be done and turned in
individually. Homework assignments 2 and 3 are effectively team efforts,
but don't expect your designer to help you a lot with implementation, as
(s)he will be busy implementing somebody else's design.

Students are encouraged to help one another with mechanical and
linguistic difficulties (``how do I save this file?'', ``what's the syntax
for an inner class definition?'', etc.),
but writing, designing, coding, testing, and debugging
should be done by the one person whose name is at the top of the assignment.
It's remarkably easy for a professor to notice when three different people
have turned in nearly-identical programs or designs; if that happens, I'll
grade it once and divide the credit
among the three, so the best any of them can hope for is 33%.

All work on the final exam must be entirely the work of the one
person whose name is at the top of the page. If I have evidence that
one student copied from another on an exam, both students will be
penalized; see above.

9 Schedule

This class meets every Tuesday and Thursday from 12:15 to 1:30 PM,
except on University holidays or if I cancel class.
All dates in the schedule are tentative,
except those fixed
by the University; if some topic listed here as taking one lecture in
fact takes two lectures to cover adequately, or vice versa,
the schedule will shift.

I expect you to have read the specified chapters in the textbook
before the lecture that deals with that topic; this way I can
concentrate my time on answering questions and clarifying subtle or
difficult points in the textbook, rather than on reading
to you, which will bore both of us. Please read ahead!