Jan. 18, 2005
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.)
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.
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.
Olsen, Dan, Developing User Interfaces, Morgan Kaufmann 1998, ISBN 1558604189.
Your semester grade is computed as follows:
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.
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.
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.
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.
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!