Issue
Article
Vol.30 No.2, April 1998
Article
Issue
Issue |
Article |
Vol.30 No.2, April 1998 |
Article |
Issue |
The Problem
The Approach Taken
Make the Course Practical
Don't Give the Students a Survey Course
Provide Representative Problems
Give the Students Concrete Examples
Is it Psychology, Computer Science, or Neither?
The January issue of the Bulletin introduced a new series of articles in which individuals with a variety of backgrounds will discuss HCI education. The first article, by Julie Jacko, looked at how HCI can fit into Industrial Engineering programs. In this issue, Marilyn Mantei-Tremaine, of the University of Toronto, discusses her goals for a single HCI course within a Computer Science curriculum. As implied by the title Marilyn also has a background in Psychology. This gives her a somewhat unique perspective on the issues.
While more universities continue to develop HCI degrees and concentrations, things have not progressed this far in most computer science departments. Most computer science students still experience HCI as a single course that is frequently designed for juniors or seniors. Marilyn provides insight gained through ten years of teaching such a course to undergraduate computer science students at the University of Toronto. She began by accepting the reality of a single course, the diverse backgrounds of her students, and fact that many of these students may eventually be designing interfaces. Through an iterative process, Marilyn developed recommendations for anyone teaching a similar course. She provides general advice (e.g., Give students concrete examples) and shares tested solutions (e.g., the memorized number sequence example).
Her focus is on the knowledge and the skills students will not gain elsewhere in their studies. Practical hands-on exercises students can relate to real-life problems are used throughout to demonstrate ideas and small projects reinforce the lessons learned. Anyone teaching an introductory HCI course to computer science students should be able to find something in this article they can apply immediately in their course.
Marilyn concludes by addressing the question of whether or not the course she describes is really computer science. I'd agree with Marilyn. This is not a traditional computer science course. It's also not a psychology course. This is a computer science course that integrates material traditionally taught in psychology classes that students need to understand when designing user interfaces. It could also serve as an introductory human-computer interaction course designed for computer science students. Marilyn does in this course what we should do in every course, she identified the knowledge and skills students need but do not currently have and designed a course to convey this information to the students. The course Marilyn describes fills the gaps for the computer science undergraduates she had in class. Similar courses, that focus on different material, could be effective introductions for students majoring in psychology, industrial design, and human-computer interaction. As Marilyn demonstrates, the key is to recognize and fill the gaps that exist in the knowledge, skills, and experiences of students, even when this involves introducing material that is not traditionally part of the curriculum.
If you'd like more information about how Marilyn teaches her course you can visit her WWW site: http://www.dgp.toronto.edu/csc428/428.html
Andrew Sears
A degree in computer science is a long difficult process. Students who elect this major work exceedingly hard, both studying difficult material and working on time-consuming assignments. A student's course of study is packed with required units covering database systems, networking, graphics, software engineering, operating systems and artificial intelligence. In addition, students need to acquire discrete math skills, a subject they have not had much exposure to before entering the university. The first two years of computer science are spent acquiring basic software and math skills, leaving little room for courses in humanities or communication. An undergraduate student's exposure to people-oriented sciences is minuscule. The lament of computer science professors is that the students cannot write effectively, a condition even more serious than the lack of psychological intuition. Much of the curriculum (usually 3 or more courses) focuses on giving students math intuition with the hope that having this intuition will help them solve computing problems. The complaint frequently voiced by CS professors is how hard this math intuition is to instill in the students.
For the last ten years I taught human-computer interaction to the University of Toronto's computer science undergraduates. It has been both an enlightening and heart-wrenching experience. I had a single one-term course in which to teach the future interface builders what we know about interface design. In our less than perfect world, the interface is often in the hands of the programmer, not the interface designer. What could I teach these programmers in their brief sojourn through my course? What did they need to know most? Knowing that only 20 percent of what I taught would be retained, what should this 20 percent be and how could I make it that 20 percent? I write the various successes and failures I have experienced to share what might work with others faced with these problems.
In this environment, giving a student what I call psychological intuition to help them solve user interface problems, is extraordinarily difficult, the more so because only one course is typically allotted for the task. The CS curriculum also interferes. Students acquire a form of thinking and problem solving that is a direct antithesis to the approaches in user interface design. Assignments in CS courses are extraordinarily structured. There is little variation in what constitutes the correct answer. Thus, the idea that assignment answers would depend on the user group investigated is very disconcerting for them. Students also have more control over how they schedule their time on their assignments and studying. There is a lot of late night hacking near the due date of assignments. In contrast, the assignments in an HCI course require multiple tasks and scheduling people at reasonable times. Finally, students have to write reasoned arguments regarding the application of their results to the user interface design in each of their assignments. With limited writing skills to begin with, this is a significant hurdle for the students. This has improved because the other computer science assignments are now requiring this form of writing practice, but it is still a significant problem.
In addition to the packed course of study and the focus on math and computer science training, computer science programs in North America have many foreign born students. Since language is the basis for understanding other humans, the students' limited English skills make teaching a psychologically based course more challenging. How can subtle meanings and detailed discriminations be expressed? In addition, psychology is primarily a western concept that is foreign to students from many countries. It is unlikely that an Oriental student has ever read a magazine article on training rats to run mazes, nor are many of the students familiar with the "pop" psychology of western magazines. (I'm still trying to determine if that is a disadvantage or an advantage for teaching HCI. There is something to be said about starting with a clean slate.)
Given the above problems, I have arrived at a set of strategies for conveying the recommended content of the ACM Curricula (1992) to my computer science students. I have not run any controlled studies on the effectiveness of these strategies. However, the students are getting better scores on test questions they had difficulty with in the past, and the department showcases more of their designs during the University open house days. Students are also enrolling in the optional class in larger numbers, and the class is now at its seating capacity of 100 students. My favorite anonymous student comment on the class is, "be prepared to do some really weird things."
In short, here are my overall recommendations.
In the following paragraphs I outline my approach in more detail and also describe several of the unexpected consequences I encountered until I adjusted and adapted each approach.
Because the students have little experience with the psychological abstractions, I give practical assignments requiring students to design and build interfaces. As students iterate through their designs, they have to perform various psychologically based measures on their users. A key point of the assignments is requiring students to describe the reasons why they conducted various tests on their users, the results from these tests and what these results suggest should be changed in the design. Finally, I require students to justify why they made the changes they did.
I give students four assignments all based on the design of a single user interface. In the first assignment, they collect user information in a form of task analysis. In the second assignment, they build human information processing models of their paper and pencil designs. In the third assignment, the design is prototyped and tried informally on users. The final assignment is a usability assessment of the prototyped design. This process follows the recommended development process for interface design today so the students learn this in passing. The focus in every assignment is on the iteration of the design and the evaluation of the user.
This approach seems relatively straightforward until one realizes that the students do not have the vaguest idea of what is going on with the user either in terms of learning, cognitive activity, motor performance or attitudes towards the interface they are using. I found that they could easily write a questionnaire that had no relationship to their design and look at a videotape of a user struggling with their interface and see no problems in the user's difficulties. I remember one student's stinging comment about the family member she had brought in for her usability study. " I didn't know my brother was so stupid!!!" It is not enough to give students assignments in evaluating users; the course requires detailed examples that the students can follow. The examples should be close to the designs that the user is working on.
My first efforts to teach this practical course that involved interaction with humans revealed that the students were more practical and pragmatic than the instructor. When it came to writing a questionnaire and testing it on their users or conducting a usability study, the students wrote profoundly about their user responses and problems, but with such lack of credibility that it became clear that a new phenomena of ghost users had occurred. These ghost users found little wrong with the interface design plans or the prototype interface. Now, students are required to submit assignments with a short paragraph describing their user including the user's name and signature. Students are also required to videotape their usability studies and submit the videotapes as part of their assignment. Furthermore, I make it clear in class that it is trivial for the instructor to determine if a computer science student has been used for the usability study. They also have to indicate why their users are representative users and know that this can be checked by viewing the videotape.
Often, the first and only course in HCI in a computer science department presents a survey of the HCI field. Students are given example after example of applications with a strong user interface component. They learn dialogue styles and see that there are many different ways to design a menu. They learn many different kinds of input devices and the user interface design process. At the end of the course, they invariably learn about CSCW. The entire course discusses designing better interfaces, but it never tackles the issues of how to do it. Students learn the many myriad approaches to HCI but they are clueless as to what these approaches accomplish. The course often leaves students with an idea that common sense readily solves interface problems and with a confidence that they are ready to tackle such designs. A survey course belittles our field.
The student assignments I use in my course are small designs. There is a tendency in computer science to assign large interfaces such as that of a word processor. Otherwise the development work looks too trivial. In the case of user interface design, this is like asking the student to build a 266 chip while learning logic design. I require the students to build a simple interface such as a ticket machine that dispenses theater tickets for one theater or an electronic bumper sticker that displays pre-stored messages. They only have to do the interface for selecting the pre-stored messages. I then relate these to similar interfaces, e.g., an automatic teller machine and a car radio. The course uses videotapes of users working with prototypes of the various interfaces and various designs (these videotapes come from the previous year's assignments). I also take representative assignments from prior years and make them available to the students. The assignments are liberally commented with the intent to illustrate what is missing from the student's work. Videotapes are also on reserve in the library along with a complete analysis of the user information that is available in the videotape.
The analogous user information or problems are designed to represent a particular problem or concept that is discussed in class. For example, I teach my students to look for information that the user may not be aware they are using to accomplish their task such as sounds or common shapes or the co-occurrence of another event with the event be observed. Examples that I give of this overlooked information are "the sound of money leaving an automatic teller machine" or "the feedback force and the sudden release of this force that occurs when depressing a radio selection button." The analogies are designed to help students transfer these concepts and solutions to their own design problems. I also give analogous problems on exams so that students get the practice needed to retain the user interface concept.
I find that computer science students have little affinity for learning about human memory, the human perceptual system or theories of how humans learn. In order to convey these concepts, I resort to class demonstrations involving student participation. The demonstrations also dispel student misconceptions about how they think. Here is a subset of demonstrations I give in class with the underlying concepts they convey.
In this demonstration, I put a single number on the blackboard or an overhead that is too long to memorize trivially, e.g., 347 901 331 7347 89. I ask the students to memorize this number by writing it down again and again on a blank sheet of paper. Once students have indicated that the number has been put to memory, I ask various students to recite the number while others listen. I use this recitation to illustrate how the design of the number (the spaces left between groups) affected their memorization and retrieval strategy. I also use it to illustrate "chunking" and discuss how humans optimize their retrieval from memory. Students are then asked to memorize a second number, e.g., 134 790 133 1734 789. Very few students notice that the second number is the first number with a "1" added. We discuss how an interface designer can, without thinking, design a set of interaction sequences that to the designer are one interaction sequence with minor variations, but to the user are distinct sequences that all require separate learning. We then discuss ways to make these sequences obvious (1) by appropriate groupings, (2) by help agents or (3) by specific indication of the sequences in the user manual.
I have generated (usually by copying from a commercial software package) a variety of very busy screen displays. I show the screen display to the students and then tell them that I will ask them to find something on the screen display, by putting the description of what is to be found on the overhead projector followed by the image of the screen display. When the students have found the object they are to raise their hands. Sometimes, I ask the students if there are three examples of the object or how many instances of the object are to be found on the screen. I show a second set of the screen displays that contain the same information but are reorganized using appropriate visual grouping cues (see Kevin Mullet and Darrell Sano's book (1995) describing how to do this). I again ask the students the search questions and measure the time to find the answers. We then enter into a discussion on what made each of the modified interface designs work better. In the process, we discuss how the visual and cognitive system recognizes natural boundaries.
Most of my students find it hard to believe that data obtained from the user may not be trustworthy. Therefore I ask the class a set of questions. I do this to demonstrate first, that the answer to the question may not be available to them and second that they are likely to make up an answer if they do not have an available answer. Questions in which the answer is not likely to be available are such items as, "What did you have for dinner last week Tuesday?" Questions in which answers are not available but likely to be given anyway are: "How many hours did you work on this assignment?" (I demonstrate afterwards that the hour figure has to be inflated by walking them back hour by hour for the time they worked on the assignment.) Finally, I have students write two sets of questions. Each question in the set has a parallel or similar question attempting to get the same information. The difference between the questions is that one will get a yes or positive response and the other will get a negative response. I have them administer these questions to their friends and report the results. The non-native English speaking students write questions in their own language but translate them for the class.
I have found that my students miss the nonverbal cues that are a part of human activities. The one way I have found to show nonverbal cues is to walk through a videotape of a usability study step by step and point out the subverbal and nonverbal user activities that exist throughout the recording. I have the students record the sighs the first time through the tape, the hair twisting the second time and the leaning back in the chair the third time. They then see the correlation with the user's problems with understanding the various parts of the interface. In a final viewing of the tape, I have the students point out other behavior that we did not record that might be on the tape.
Cognitive walkthroughs are strongly recommended for user interface design, yet few of my students can imagine how a user might use their designs. I therefore bring in devices and have the students describe in detail how the user might perform a particular task with the device, e.g., adding a set of numbers on the calculator. We have a student interact with the device based on their description. Invariably, large gaps are found in the task steps. When the class was smaller, I taught the GOMS model, not so much because the GOMS model would be a useful skill for my students, but because it forces the students to start imagining how a user might work with their interface. I believe that the GOMS model is a very effective tool for teaching psychological intuition.
I borrow heavily from Don Norman's book, The Psychology of Everyday Things, to teach my students the application of psychology principles to design. The students readily remember the derived concepts of affordance, feedback, etc. that are presented with many simple direct examples. It is the bundling of the underlying mechanisms of human learning and memory into these higher level directly applicable concepts that make the learning so much more memorable to the students.
I use the fact that exams and grades are extremely important to students. I give out old exams that focus on a particular issue I want my students to learn. I then give new exams that focus on this same issue.
Because people learn better by formulating the concepts I am teaching in their own words, I ask students to generate their own examples of a concept that is discussed in class. For example, I ask them to give examples in the various contexts in which feedback is missing in the interface. I initiate the idea generation with a suggestion of the lack of feedback on wait time when a user is put on hold.
I try to relate concepts to what they already know but add a memorable twist. When I teach the students about response bias in questionnaires, I discuss the famous English study in which male respondents had, on average, three times as many sexual partners in their lifetime than female respondents.
Students who feel empowered to change the course also find their empowerment and changes memorable. It is a dramatic eye opener to have students evaluate your course syllabus, web page and course lecture notes as part of the course assignments. I now know that a good syllabus would have a pull out bookmark with reading assignments and dates on the bookmark that could be kept in the course book, and that the two or three paragraphs describing "what this course is about" are considered irrelevant space grabbers by the students. They would also like a syllabus in which they have space for annotations. For example, it would be a good place for them to keep track of their assignment and test scores and the class average in addition to boxes for checking off what they have read.
Another way in which to make learning salient to the student is to make it immediately useful to them. I have students work out a small processing model of how much time it takes to develop programs if they do not touch type and compare this to the time it takes with touch typing skills. They then look at the hour cost of learning touch typing and realize that a week spent with a touch typing tutor will be of enormous benefit to them. I also discuss the benefits of learning to type the rote syntax of a new language prior to using it to develop a programming assignment. The touch typing model derives directly from the models used to evaluate the performance of various dialogue styles in interfaces. The programming language learning strategies come from the discussions on how users learn interfaces.
I have discussed a large variety of ideas, but have not dealt with which course content is most important to convey. I believe that the most useful goal of the HCI course is to give the computer science student some glimmerings of psychological intuition or more precisely, a start on being able to think like the user of the software. Thus, the most important elements are those that deal directly with the psychology of the user. The three elements that I emphasize most in my course are (1) the design of a questionnaire or interview that is based on what design questions the designer needs to answer (2) the development of an information processing model of a user working with the interface design being developed and (3) the recognition of verbal and non-verbal cues in a usability study of the interface design that indicated underlying problems with the interface. Each of these elements teaches the student more about psychology but by adapting the psychological concepts to design.
Emphasis on these areas comes via the exams, the requirements of the assignments and the amount of time spent on these topics in course lectures in addition to the techniques for creating saliency.
There is an oft heard complaint that the HCI course I describe is not computer science. It doesn't have enough interface development in the course. I argue that except for the drivers for special input devices and the graphics issues associated with the screen display, there is nothing unique about the user interface development on the software generation end. No special data types or algorithms are needed so that a course that focused on the interface building would not provide much for the student's education except more programming practice. Instead the HCI class needs to train the CS student in skills which are missing, interface design skills. Thus, this class should focus on iterative design and the use of information gathered from humans to perform the iterations. The interface design class most commonly taught in computer science has students work with virtual realities and write device drivers. This class should not be confused with a human-computer interaction course. Furthermore, it is not as important as the HCI course. Students often build drivers at home and work with multimedia technologies on their own. They also have enough background to be able to pick these things up on the job. In contrast, they have almost no background for tackling the human interface design.
Finally, is this course psychology? No, it would never fly in a psychology department. It doesn't have the underlying experiments that derive the theories of human behavior. It is an intense Psychology 101 with a very strong computer science twist. Just as humanities graduate students take accelerated programming courses with a focus on applications to their field, this is an accelerated psychology course applied to user interface design.
When they design visual and auditory displays, they will have some sense of how the various modalities work, generalize and acquire information and design to these constraints. When they observe users of their systems they will have some intuition on interpreting what is wrong with the interface the users are having trouble with. When they collect data from users, they will know enough not to trust or use certain data. When they go to design an interface, they will be able to lay out the user constraints on that design. When they are required to design something new, they will know how to get information from the users to help them generate new and useful design ideas. And finally, they will be able to think more like a user.
It is easy to get students to run experiments or to have them write drivers or generate a new interface design. It is not so easy to teach psychological intuition. The rewards are an improvement in our own psychological intuition and not having to look at so many ghastly designs each year.
ACM SIGCHI Curricula for Human-Computer Interaction, Report of the ACM SIGCHI Curriculum Development Group, ACM, New York, NY, 1992, 162 pages.
Mullet, K. and Sano, Designing Visual Interfaces, Prentice-Hall, Englewood Cliffs, NJ, 1995.
Norman, D.A. The Psychology of Everyday Things, Basic Books Inc., New York, NY, 1988.
Marilyn Mantei Tremaine is currently on leave from her position as Associate Professor of Computer Science at the University of Toronto. She heads a user interface design consulting company called M3 Associates which is located in Princeton, New Jersey. In addition, she is actively involved in the AlterEgo Research Project at Rutgers University. While at Toronto, Marilyn headed CAVECAT, a desktop videoconferencing research project. CAVECAT evolved into TELEPRESENCE, a project which studied the implementation of the CAVECAT system in a disperse corporate environment. Prior to coming to Toronto, Professor Tremaine was a faculty member at the Michigan Business School where she worked out the processes that needed to be taken to incorporate HCI techniques into software development and gathered data on the cost/benefit tradeoffs of user-centered design. During a leave of absence from Michigan, she worked as a Senior Research Scientist at EDS Corporation where she built the Capture Lab, a synchronous meeting support room for capturing design decisions and the design rationale of General Motors engineers.
Professor Tremaine also served on the SIGCHI board for ten years and chaired the CHI '86 Conference on Human Factors in Computing Systems and the CSCW '92 Conference on Computer Supported Cooperative Work. She was technical program chair of Graphics Interface '97 and is associate editor of 5 journals in the CSCW and HCI research area. Her current research work focuses on the development of sound as an interaction style and methods for capturing and managing the flux of information that occurs in everyday life.
Marilyn Mantei-Tremaine
M3 Associates
14 Teak Lane
Princeton, NJ 08540-4724, USA
Issue |
Article |
Vol.30 No.2, April 1998 |
Article |
Issue |