Usability has become an essential requirement of interactive computer software. In response, human-computer interaction (HCI) has grown into a serious field of research, development, and application. This course uses an integrative and cross-disciplinary approach to bring together a broad variety of topics together in relation to the problem of developing quality user interaction designs to provide an introduction to the field of HCI. This course is different from a majority of CS courses like software engineering that take a systems perspective. This course focuses more on application (and less on theory) of user-centered design principles, guidelines, and evaluation. It is a fun course with interesting user interface design projects and concepts. Unlike a majority of other CS courses, this is NOT programming intensive.
Among the topics studied are the design and evaluation of effective user interaction designs, including principles and guidelines for designing the product: effective interaction design content and interaction style. Additionally, much emphasis is given to the development process for user interaction designs as an integral, but different, part of interactive software development. The development process includes management of a life cycle that must be both iterative and cost effective. User interaction development activities include requirements and task analysis, usability specifications, design, prototyping, and evaluation. It is a goal of this course to help students realize that user interface development is an ongoing process throughout the full product life cycle, and developing the human-computer interface is not something to be done at the last minute, when the "rest of the system" is finished.
This is an active learning course, meaning that you, the student, have more responsibility than usual in the learning process. A major student responsibility is to read and study the class notes applicable to each class before that class meets. It is the student's job to manage the pace of this reading so that it fits the class schedule. No fixed reading assignments will be announced. Class time will be used for highlighting course materials, questions, and discussion. The main use of class time will be for in-class activities to demonstrate techniques and principles and to practice the skills described in the class notes. Outside of the classroom, students will acquire hands-on experience in applying these skills and techniques in a semester-long team project. In this project, students will develop a usable interaction design for their own application system in a development project for a fictitious client.
Although the primary objective of HCI as a field is to study methods and techniques to develop and evaluate computer related interfaces, many of these principles also apply to the design and evaluation of "every day" things. I would like each student:
You are required to print these slides and bring them to every class in a notebook, so we can refer to them and you can use them for note-taking in class. Most of what we do in class and in your team projects will be based on these notes.
| Homework | 15% |
| Quizzes | 10% |
| User Interaction Development Project | 50% |
........Project 1: Topic, Client, and Product Concept Statement |
5% |
| ........Project 2: Systems Analysis |
10% |
........Project 3: Scenarios, Screen Design, and Early Prototype |
10% |
| ........Project 4: Usability Specifications, Hi-Fi Prototype, and Demo |
10% |
........Project 5: Formative Usability Evaluation |
10% |
| ........Project 6: Oral Project Presentation |
5% |
| Midterm | 10% |
| Final exam | 15% |
This is a team project. I will assign students to teams, trying to balance knowledge, skills, and backgrounds. All development activities, including writing the deliverables, are team activities. All team members are to participate in all development activities. Do not divide the overall process among the team members. Even though this might seem like a more efficient way to proceed, this leads to a kind of specialization that poses a barrier to each person learning the overall process. The is especially true for a person who gets the job of programming, at the price of not learning usability engineering skills.
The objective part. The first thing I assess objectively is whether all requirements are met. Mechanical aspects such as formatting, labeling, grammar, spelling, following instructions, etc. are easy to grade because they are objective. Since these mechanical aspects are just expected, I don't give positive points for those, but I do deduct points if they are wrong or missing.
The subjective part. The hard part in grading is the subjective part, which is about quality of content. I lay the reports out on a table in approximate order of overall quality. During a discussion of their relative merits, a given report may be moved up or down in the sorting as I calibrate my judgments and make adjustments. There are two components to this subjective evaluation: how well requirements are met (how well you did the job) and how well you reported it. My evaluation of these components is based on my own knowledge and experience and is necessarily somewhat relative among the project teams of the class. The "how well you met requirements" part is based on my perception of how much you put into it, how completely you pursued the assignment, and how well you understood, interpreted, and applied the material covered in class to your project.
I try to write comments on your reports about these qualitative parts, so you know what aspects of your work and writing are possible issues. Comments of this type are along the lines of: why didn't you also do such-and-such, this isn't really what I was asking for here, wording not tight, not quite a complete as it could be, a little bit rambling, grammar and spelling not the best, etc.
An example of what I mean. Here is an example from my perspective, so you can relate to what I am faced with in this part of the grading. Team A reports their findings of a client interview in a crisp, easy to digest form using summary tables and short clear descriptive paragraphs. You report your findings in a somewhat lengthy and verbose, narrative form. You cover all the important points but it is not as easy for the reader to pick them out as it is in Team A's report.
So I write on Team A's report: Nice job of clearly presenting the important points. On yours, I write: Slightly verbose; need to clarify/highlight important points. Then you come to see me and ask: Where is it verbose? I say that verbosity is a distributed thing but, as one example, here are two sentences that you could have tightened into one short one. It's your job to extrapolate that comment to the rest of the report.
The point here is that I cannot always say exactly where a specific number of points was deducted to arrive at your grade. In fact, it is usually the case that points are not deducted but your score is assigned to reflect your relative standing among all the reports, as explained in the next paragraph.
Grades are based on overall quality. Please remember that, beyond any comments I write on your report, the grades are based on *overall* perceived and relative quality. So, let's say your team got an 85 and Team X got 90 and the only apparent (noted in comments) difference between you and Team X was that you got a comment about completeness. That does NOT mean that the completeness issue was necessarily worth 5 points. The completeness comment contributes to where your report finally falls on the table, but its relative position in that sorting is what determines the numeric grade. So *that* is the answer when you come back to me and ask why you got the grade you got.
You may also ask what you can do to get a better grade. Often there is not a simple quick answer, like 'do such and such'. I am willing, however, to sit down with you and go through your report in detail and point out some aspects of the writing that could be improved. And maybe I might be able to make a general conclusion about a particular aspect of your writing to focus on.
Bottom line. If you get a grade of, for example, 80 or 85 and another team gets, say, 90 or 95, it does not mean that you did a poor job. I have to assign some number as a grade and I use it to distinguish among the project reports from all the teams. I evaluate your assignments in detail. You can be sure this is done in the fairest way possible.
Keep this in mind, especially if you get discouraged about the project workload: My experience with this course has been that the project work separates the class into two groups: those who simply cannot keep up and who drop the course before the end and those who hang in there and do a good job on the project. Students who stay in the class, stand up under the heavy workload, and carry out the team project with dedication and enthusiasm will do well in the course in the end.
Grading appeals. All assignments (homework, project, and final exam) are designed by the instructor. The homeworks and projects are graded by the instructor. If you have any questions about the grading of these items or feel that something has been graded incorrectly or unfairly, you should contact me. Regrading requests must be submitted to the instructor within three class meetings after the graded work was returned to the class. A regrade will entail a COMPLETE RE-EVALUATION OF THE ENTIRE ASSIGNMENT. This may increase or decrease your original score. The regraded score is final.
This risk of a grade reduction is not to discourage you from discussing your project grade with the instructor. This is to address the problem of students who mainly want to squeeze out more points in their scores. You need not worry about this if your desire to discuss project grading is motivated toward learning and not all about getting points.
Keep all graded work until the end of the semester. You should check the posting of your grades periodically to be sure my records reflect your correct grades. In case your grade is incorrectly recorded, you will need to bring in the graded original in order for the recorded grade to be changed.
Sometimes, despite our best efforts, some team members end up not pulling their fair share of the weight. To ensure that each team member is given a project grade reflecting individual contributions, the final project assignment is a Team Member Evaluation. Each team must INDIVIDUALLY turn in a paper copy of the Team Member Evaluation Form (print from Web) as a required deliverable to report the relative effort/contribution of each person on your project team over the whole project (including yourself).
This form is not optional. Be professional and give a careful rating. The ratings on these forms will be used as weightings, as explained at the beginning of the semester, to convert team project grades into individual student project grades. The team is given a grade for each part of the project. Each individual team member's grade for each project assignment is a weighting of the team grade, where the weighting is based on an evaluation of individual contributions, collected from each team member at the end of the semester (and moderated as necessary by the instructor).
If you have to miss class for an extended period due to a protracted illness or similar reason, I will treat your needs as a special case and I will do everything I can to help you survive.