Course Syllabus

CS 477/577 – Advanced User Interfaces
Dept. of Computer Science
Northern Arizona University
Spring 2009

Time and location: TTH 12:45-2:00 (3 credit hours), Engineering (Bldg 69), Rm. 120

Course Website:  http://www.cefns.nau.edu/~edo/Classes/CS477_WWW/

Course PreRequisite: CS 249 (Data Structures)

Course Objectives: Upon successful completion of this course, you should have an understanding of the principles of requirements acquisition, design and construction of modern graphical user interfaces, and user-centered design and usability analysis. You should also have gained understanding of and experience with event-based programming and client-server UIMS paradigms. This experience should prepare you to take a leading role on software projects centered around the design, implementation, and user testing of advanced graphical interfaces.

Instructor: Dr. Eck Doerry, Assoc. Professor
Office and email: Engineering (Bldg 69), Rm 259, Eck.Doerry@nau.edu

Although you should try hard to make it to scheduled office hours, I am also available at other times by appointment. To schedule, see me before or after class or send email. Aside from scheduling meetings, email is appropriate for short questions; longer discussions should be handled in person. If my office door is open or cracked outside of office hours, feel free to knock - I may be available (no guarantees). I enjoy talking to and helping students, so if you are having problems please find some way to let me know as soon as you can.

Course Stucture and Evaluation Methods

Programs: A number of programming projects will be assigned to provide hands-on GUI design and evaluation experience. Students should expect to learn details of GUI programming on their own, i.e., little if any lecture will be spent "teaching programming" (that ended with CS136!). Although there are certainly an infinite number of languages and systems for GUI programming, we need to settle on one that (a) is widely available, free, and has high likelihood of being maximally useful to you in the real world, and (b) is maximally portable seeing as we all use different platforms. Thus, all programming for this course is to be done in Java using the SWING package. Unless explicitly stated otherwise in the problem write-up, programming assignments must be done individually. This means absolutely no sharing of code (program printouts or handwritten code) or electronic files between students.  The only exception is when shared code is of a utility nature (e.g., a pretty-printer function) peripheral to the core assignment. In this case, the shared code must be clearly attributed to the author. The safest route is to check with me before incorporating foreign code in your work. Overview of programs:

• Program 0: Bare bones GUI in Java
• Program 1: GUI Basics. Learn about basic entities (windows, buttons, panels) and the event-model.
• Program 2: Advanced GUI. Direct manipulation techniques, learn to craft custom UI components that do what YOU want, not what Java naturally lets you do.
• Final project. Advanced development and usability testing of a GUI application.

Class participation (and quizzes): This class is not some sort of docu-drama that you sit and take in passively. I do not view teaching as a uni-directional process by which I somehow fill the golden elixir of knowledge into the empty gourds of students. Interaction -- both with the instructor and with other students -- is crucial for understanding and integrating the ideas presented in lecture. To emphasize this, a significant number of points are set aside to reward students who take an active role in the class. I may also utilize some of the participation points to credit the occassional pop-quiz.

Exams: There will be two exams during the semester. Whereas, programs allow you to develop and practice your programming skills and gain hands-on experience, exams allow you to explore the extent to which you understand the theory and principles that underlying these problems. This does not imply, however, that exams will not require you to read/write some code.

Exam 1: Feb. 24(tentatively)
Exam 2: Apr. 21 (tentatively)
Final Exam: Final Project Presentations. During final exam period in the regular classroom

Grading: The scoring distribution in this class is as follows:

Programs & Assigments = 45%
Midterm exams = 30%
Participation/Quizzes/Attendance = 5%
Final Project = 20%

Policy on Team Programming Projects: The later programming projects during the term will be executed as programming teams. It is important for all team members to contribute reliably and definitively to the productivity of the team in order for the team to succeed. To help evaluate this participation, we will be using a peer evaluation approach to gain insight into team dynamics, and to fairly distribute project points based on effort invested. In general, the peer eval system will be used to calculate an "effort factor" for each team member, which will serve to modify the scores for all team deliverables. In this way, high-performing team members will be rewarded, slackers will be penalized. On a perfectly functioning team, all members share the same score.

Policy on Graduate Student grading: Since this is a combined undergraduate/graduate class, I will grade graduate students differently in several ways. Graduate students will often have different problems to do. As an example, programming projects will consist of a core set of problems to solve or functionalities to implement; graduate students will be required to implement, in addition, certain more advanced extensions or enhancements. Graduate students will also be held to higher expectations of quality on other assignments. For example, I expect graduate technical writing to be of higher quality, with hypotheses and arguments supported with references to appropriate literature. Finally, graduate students will be assigned an overall survey paper on a topic in User Interfaces of their choice (must be approved by me), which will be due at the end of Reading Week.

Simply completing what is required is enough to earn a "C". To get an "A" or a "B" you must show exceptional (i.e. above average or outstanding, respectively) initiative and creativity.

Course Policies

Attendance:

Attendance is required. You are responsible for all material covered during the lectures whether you attend or not. If you must miss a class, be sure to get the notes from another student. After reviewing their notes and doing the assigned reading, let me know if you have specific questions ("Did I miss anything?" is not a specific question!). Late arrivals are very disruptive and are not acceptable --- plan to arrive five minutes before the start of class.

 

Electronic Device usage:

All cell phones, PDAs, music players and other electronic devices must be turned off (or in silent mode) during lecture, and may not be used at any time. Laptops or workstations (if present) are allowed for note-taking only during lectures; no surfing or other use is allowed. I devote 100% of my attention to providing a high quality lecture; please respect this by devoting 100% of your attention to listening and participating.

Homework Submission and Format:

All homework must be submitted in hardcopy. For details on formatting and submission requirements. See Formatting Guidelines on the class website. In particular, make sure you always have a cover sheet with the required information on it!

Late work:

No late work will be accepted. Unless otherwise noted, all assigned work is due at the beginning of class on the date they are due! Programming assignments will usually be collected electronically. If your program is incomplete or won't compile, you should still upload it, prefaced by a detailed explanation of exactly what works and what doesn't, where you think you went wrong, and any other information that might help me give you partial credit.

 

Grade Challenges:

Although I try hard to grade as accurately and fairly as I can, mistakes do occur.  If you feel that I owe you some points, or would like to discuss an evaluation, I encourage you to stop by office hours.  To avoid loss of context, any grade disputes must be brought to my attention no later than 5 business days after the assignment was returned.

Make-ups:

No make-ups are given for pop-quizzes or programming assignments.. Make-up exams will be given only in the case of a documented emergency or with approval from me at least 24 hours prior to the exam. Make-up exams are usually more difficult than the original exam.

Academic Dishonesty:

Cheating will not be tolerated and may result in immediate failure in the course. Serious incidents of academic dishonesty will be brought to the attention of the university and may result in expulsion. All work in this class is meant to be an individual effort by the person receiving the grade. Any variation from this is considered cheating and all parties involved (giving or receiving) will be sanctioned.

Additional clarification on cheating: Sometimes students are not clear on what is or is not cheating in regards to programming: the programs you turn in for grading should have been written and typed in by you without referencing another’s work (you may refer to books, of course --- but you may not copy large sections of code from any book, the internet, or any other medium). It is often helpful to work with others to clarify the problem to be solved and discuss possible solutions; this is acceptable and even encouraged. But you should never at any time give another student a copy of your code or accept code from another student, either physically or electronically. Some examples of cheating include but are not limited to:

• Turning in someone else's code (perhaps with minor modifications) as your own.
• Turning in fabricated output for a non-functional program (or editing output from a partially-functional program) in an effort to fool the grader into thinking the program works as specified.
• Using fragments (e.g. functions/methods) from another's code in your code, passing them off as you own. Occassionally, it is acceptable to use a peripheral utility code written by someone else but you should always (a) clearly document the source of the code fragment and (b) check with me first.

University Policies

You should familiarize yourself with the following university policies, which are available at the Engineering Sciences Front Desk:

• NAU Policy Statements. This course is subject to University policies on Safe Environment, Students With Disabilities, Academic Integrity, etc. See: http://www2.nau.edu/academicadmin/UCCPolicy/plcystmt.html
• NAU Classroom Management Statement (also online at: http://www4.nau.edu/stulife/handbookmanagement.htm)
• Building Evacuation Policy
• NAU Class Policy Statement (also online at: http://jan.ucc.nau.edu/academicadmin/policy1.html)
• Engineering Sciences Code of Ethics (also online at: http://jan.ucc.nau.edu/~blutz/academic_affairs/Professional_Ethics-Code_of_Conduct.doc)

Vital Skills and other Hints for success in CS477/577

Be active, not passive.

One of the skills you should develop is an ability to read difficult material on your own - you will exercise this skill in the present course. Try to read at least lightly through the material in the assigned reading before the related lecture. You are expected to read the material more thoroughly before (and preferably well before) any exams. Also read introductory sections, summaries, and chapter notes, and skim exercises and problems to gain an idea of what's going on and where to find material!

Avoid hacking.

Writing a program can be a funny thing. Some people are very fast programmers, others are quite slow. One common complaint I hear is that someone spent XX hours on a program and still couldn’t finish. Others might spend only a couple of hours.  This disparity emphasizes the difference between programming and merely “hacking”.  It is important to make sure you understand what has to be done, the concepts associated with the assignment, and that you have a plan or outline for your program – before you write a single line of code. All of this will help to decrease the time you spend in front of the computer wondering why something doesn’t work.

Strive for elegance.

Because of the course emphasis upon programming in an actual language, and because of the overall purposes of our program and the pedagogical placement of this course within the program, I emphasize good style including modularization (e.g., class design), pretty-printing, and appropriate commenting in my evaluation of your programs. Unpleasantness like global variables, inefficiency, and just plain ugly code will be penalized. In short, it is important for you to learn to produce clean, efficient, and easily-maintainable code, not just code that works.

Don't procrastinate.

Don't delay programming assignments until the last minute. Unlike writing a paper for an english class (which is done when you want it to be), a program is a living thing, full of errors that must be corrected before it is done. How long this takes is completely unpredictable. So be sure to leave yourself enough time --- time to think carefully about the design before you program, and time to resolve whatever problems do arise. Remember, whatever can go wrong will and at the least opportune time. My willingness to help you with your assignment outside of office hours greatly diminishes in the hours immediately before it is due.