e
CS 477: Advanced User Interfaces
Home
Class Info
Assignments Content  

Course Syllabus

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

Time and location: TTH 4:00-5:15 (3 credit hours), Engineering (Bldg 69), Rm. 314

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

Course PreRequisite: CS 386 (Software Engineering)

Textbook (Required):
  • Designing the User Interface, by Ben Shneiderman, Addison-Wesley
  • Possible course reading packets, TBA
Recommended Texts:
  • Handbook of Usability Testing, by Jeff Rubin; John Wiley and Sons (buy on Amazon.com)

Course Description: Exploration of theory and practice in design and construction of modern graphical user interfaces, including event models, client-server interaction, and interface design and usability evaluation.

Course Objectives: Upon successful completion of this course, you should have an understanding of the principles of user-centered requirements acquisition, design and construction of modern graphical user interfaces, and experience in applied usability analysis. 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. Specific learning goals include:

  1. Theoretical Foundations of Human-Computer Interaction, Principles of Design
  2. Applied interface design: models, guidelines, heuristics
  3. Expertise in graphical interface software programming
  4. Expertise in design and execution of effective usability testing regimes
  5. Design and effective use of a modern usability testing facility

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

Office hours:

15:00-16:00 T-TH
9:30-10:30 W

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: Several programming projects will be assigned to provide hands-on GUI design and evaluation experience. Programming of user interfaces is qualitatively different than programming in general, and is a critical skill in today's user-oriented software marketplace. Students should expect to learn details of GUI programming on their own, i.e., little lecture will be spent "teaching programming" (that ended with CS136!). There are many languages, tools, and IDEs for GUI programming, and -- in principle --- I have no particular preference as to which you decide to use for your projects. The overall requirement, however, is that your system is able to provide a compiled application for me to run and test; this must be a one-click launch process, with no compiling, downloading of libraries, etc. needed to make your application work! Those of you accustomed to using Java might want to consider the SWING package. On the other hand, we are going to lean our development towards to hot topic of mobile computing this term, so spending the time early on to learn Xcode/iOS or Android programming could be a good investment.

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. A simple project to get a first taste for GUI programming.
  • Project Phase 1: Create a first cut at an application that you are committed to developing.
  • Project Phase 2: Advanced GUI. Apply what you've learned to re-design your project based on your user studies
  • Project Final Deliverable. Usability testing and final development/refinement of your GUI application.

Class participation (and quizzes): This class is not some sort of docu-drama that you sit and take in passively. Interaction -- both with the instructor and with other students -- is crucial for understanding and integrating the sometimes abstract 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 quizzes on the reading material.

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: February 23 (tentatively)
Exam 2: April 26 (tentatively)
Final Exam: Final Project Presentations. During final exam period in the regular classroom
: Wed. May 9, 3pm

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 peer eval score. See the overview of peer evaluation works for more details.

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.

Grading Scale: 90-100% = A, 80-89% = B, 70-79% = C, 60-69% = D, under 60% = F

Simply completing what is required is enough to earn a "C". To get an "A" or a "B" you must show additional (i.e. above average or outstanding, respectively) analytic insight, clarity of presentation, and creativity. For more detail on what is expected for each grade level, refer to the ASEE's Guidelines for Engineering Grading; for written documents, this Written Presentation Evaluation Rubric may also help you better understand what is expected.


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 in some way. 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 severe sanctions, including failure in the course. Serious incidents of academic dishonesty will be brought to the attention of the university and may result in expulsion. With the exception of group projects, 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 utility code written by someone else but you should always clearly document the source of the code fragment and this code should be peripheral to the core of the programming assignment. If in doubt, please check with me first.

University Policies

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

  • NAU Policy Statements. This course is subject to University policies on Safe Environment, Students With Disabilities, Academic Integrity, etc.
  • NAU Classroom Management Statement
  • Building Evacuation Policy
  • NAU Class Policy Statement
  • Engineering Sciences Code of Ethics

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.
Some people are very fast programmers, others are quite slow. User interface programming is quite different than more "input-output-oriented" programming you have done in lower-division courses. Careful planning and design is the hallmark of software engineering, separating this organized process from more chaotic "hacking" approaches. Carefully planning ahead before you start programming is even more important in GUI programming than in other areas. The event-based nature of GUI software makes it non-linear at heart, and absolutely requires careful thinking about code factoring and event-handling before you get started. One common complaint I hear is that someone spent XX hours on a program and still couldn’t finish; others might spend only a day or two.  In CS477, this disparity almost always turns on the quality of the concept and the design underlying the code. 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, or realizing that you need to refactor your entire project two hours before it's due.
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 (somehow) works.
Don't procrastinate.
Don't delay programming assignments until the last few days before they are due. As I said above, GUI programming is unlike most other programming you may have done before. There are entire new frameworks to learn, unexpected and frustrating bugs are not uncommon, and just getting everything to work the way you want it to will take an unusual amount of time. In GUI programming, the rule is "80% of coding takes 20% of the total time; the last 20% of code take 80% of time". This emphasizes the slippery, detail-oriented nature of GUI programs: you might get a rough prototype quickly, but then will need tons of time to iron out the details. Be sure to leave yourself enough time --- time to think carefully about the design before you program... and time to resolve the inevitable detailed bugs or fine-tuning needed to create a GUI that really works.