Computer Science 233
Graphical User Interface Programming

Fall 2012

Dr. Stephen Bloch
office 203 Post Hall
phone 877-4483
email sbloch@adelphi.edu
Web page http://www.adelphi.edu/sbloch/
Class Web page http://www.adelphi.edu/sbloch/class/233/
office hours TTh 3:00-4:00, W 10:00-1:00, W 2:30-4:00, or by appointment

Course Description

Learn to analyze user requirements and use patterns to design a user-friendly graphical interface with appropriate control and display modalities, then prototype and implement the interface using event-driven programming, damage-and-redraw, callback/listener and model/view patterns, and GUI component libraries like Swing.

Course Learning Goals

By the end of this course, you should be able to

Note that many of these goals are really "software engineering", not specific to GUI programming.

Subject Matter

Graphical user interfaces

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 in 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: among other things, it has a more-thoroughly-standardized GUI library than either C++ or Scheme.

Patterns and Antipatterns

Software engineers face a lot of the same problems, no matter what area they're working in, and they often (after much trial and error) come up with the same solutions to these problems. Once a solution has been found successful in a number of different areas, it is called a pattern: there are books and Web sites listing them by name so software engineers can conveniently discuss them, and annual conferences to discuss them and identify new ones. Similarly, software engineers in different areas often come up with the same solution, try it, and conclude that it doesn't work. When this happens over and over, the software-patterns community identifies this tempting but ultimately unsuccessful approach as an antipattern, so future programmers don't waste their time on it.

Note that patterns and antipatterns aren't program code in any particular language, or even algorithms or data structures, but more abstract, and hence reusable in many different languages and application areas. We'll examine common patterns and antipatterns both in user interface design and in event-driven programming.

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.

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.

Texts and Software Support

The primary textbook for the interface-design part of the course is Jenifer Tidwell's Designing Interfaces, O'Reilly 2011, ISBN 1449379702. This is a very readable collection of patterns and antipatterns in user interface design. For Java coding techniques, we'll use a number of on-line tutorials written by the people at Sun Microsystems and other places).

I'll also give some reading assignments in Crookshanks's Practical Tools and Techniques for Software Development, CreateSpace 2012, ISBN 147514153X. This book isn't primarily about GUI programming, but it addresses a bunch of general software-development issues that you may not have encountered in other courses, and Chapter 7 directly addresses the Observer and MVC patterns, which we'll use extensively in this course. You're not required to buy this book~--- I'll try to have a copy on reserve in the library~--- but it's fairly inexpensive, either on paper or as an e-book.

You are responsible for everything in the reading assignments, whether or not I discuss it in a lecture.

Most course materials will be on the course Web pages at http://www.adelphi.edu/sbloch/class/233 . Online discussion will be using either Moodle or Piazza; links will be on the course Web page.

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

Homework

Homework 1
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. Turn in source code and associated documentation.
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 (yes, I really do want to know!)

Grading

Your semester grade is computed as follows:

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:

Your grade on HW2a depends on what I think of your UI spec.
Your grade on HW3a depends on what I think of your UI spec and your in-class presentation.
Your grade on HW2b and HW3b depends both on my assessment of the program you wrote, and on 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.

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

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.

Attendance policy

I expect you to be in the classroom at 12:15, and to still be in the classroom at 1:30; if you're not present, and miss some important material, it's your problem. If you must miss a class, arrive late, or leave early, please let me know as far in advance as possible. I don't explicitly grade on attendance, but consistent lateness or absence will impact the "brownie points" part of your grade.

Students with Disabilities

If you have a disability that may impact your ability to carry out assigned course work, and are not enrolled in the Learning Disabilities Program, please contact the staff in the Disability Support Services Office (DSS), University Center, Room 310, (516) 877-3145. DSS@adelphi.edu. DSS will review your concerns and determine, with you, appropriate and necessary accommodations. All information and documentation of disability is confidential.

In particular, you may choose whether, and in how much detail, to discuss your disability with the instructor.

Ethics

The Adelphi University Code of Ethics applies to this course; look it up on the Web at http://academics.adelphi.edu/policies/ethics.php.

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%. Clear cases of plagiarism will also be reported to the University.

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.

Student course evaluations

During the last two weeks of the class, you will be informed, via email and eCampus, that the University's online course evaluation form is available for your input. It will no longer be available after the beginning of final-exam week, so make sure you fill it out before then. They don't show me any of the results until after I've turned in semester grades. We really do take this stuff seriously in deciding what to do differently in future courses, so please give detailed feedback (something more specific and useful than "this course sucks!" or "this course rocks!").

Schedule

This class meets every Tuesday and Thursday at 12:15 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!

Last modified: Tue Aug 21 22:03:17 EDT 2012