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.
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.
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.
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.
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.
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.
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:
About Face 3, by Alan Cooper, Robert Reimann, and David Cronin, 2007, ISBN 978-0-470-08411-3. A lot of good advice about the overall methodology of designing a good interface, as well as a number of patterns and antipatterns in UI design, without discussing coding details. I've used it as a textbook for this course in past years.
Krug, Steve, Don't Make Me Think, New Riders Publishing 2006, ISBN 0-321-34475-8. Mostly about how to (and how not to) design a Web site to be friendly, attractive, easily navigated, etc. rather than about technical details (which he assumes you can learn elsewhere).
Isaacs, Ellen, and Alan Walendowski, Designing from both sides of the screen, New Riders Publishing 2002, ISBN 0672321513. Specifically addresses how to resolve conflicts between the interface-design and the software-implementation parts of the job.
Olsen, Dan, Developing User Interfaces, Morgan Kaufmann 1998, ISBN 1558604189. Emphasizes the software implementation side of user interfaces.
Borenstein, Nathaniel, Programming as if people mattered, Princeton University Press 1991, ISBN 0691037639. A bit dated, but many of the principles of user-friendliness it describes are just as valid today as in 1991.
Your semester grade is computed as follows:
Your grade on HW2 and HW3 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.
For coding assignments, 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. (The Crookshanks book discusses software tools for version control, which may make this easier.)
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.
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.
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.
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.
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!").
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!