Issue
Article
Vol.30 No.4, October 1998
Article
Issue
Issue |
Article |
Vol.30 No.4, October 1998 |
Article |
Issue |
This year, the CHI conference placed special emphasis on three application domains: education, entertainment, and health care. The education domain included everything from pre-school for children through continuing education for working professionals. HCI education was well-represented, and was the focus of a paper and a panel.
Last year, CHI 97 featured a short paper that described the experience of developing a multimedia tutorial to support continuing education in HCI (Carey, Peerenboom, and Lytwyn, 1997). This year, a follow-up paper discussed how the content and features of this system were adapted as the target audience changed (Carey, Mitchell, Peerenboom, and Lytwyn, 1998). The tutorial contains three major units: a case study, an overview of methods frequently employed in user-centered design, and a module that allows learners to play the part of a member of the design team. The paper discusses the evolution of the initial design and how a change in the target population resulted in numerous changes to the tutorial.
The CHI 98 panel, called "Famous HCI Educators Tell All", attempted to provide concrete solutions to a variety of problems faced by HCI educators (Williams & Sears, 1998). The panelists included Alan Dix (Staffordshire University), Tom Hewett (Drexel University), Jenny Preece (University of Maryland -- Baltimore County), and Marilyn Mantei Tremaine (Drexel University). Questions were solicited prior to the conference by email, during the conference using a message board, and via notecards submitted by panel attendees. During the panel, individuals who submitted questions were invited to join the panelists on stage to share the motivation behind their questions and to respond to the panelists' answers. The panelists were allowed exactly two minutes to address each question.
After the conference was over the panelists provided written responses to the questions asked during the panel. The next section presents written responses provided by the panelists. Where available, the names of the individuals who posed the questions are included.
Dix: Early on, show them some of the mistakes made in "well-designed" artifacts, both software and really-hard-ware (such as jugs). If it were so easy why doesn't everyone get it right?
Of course they still may think they wouldn't make the same mistakes.
The best lesson is the first time they give a piece of their own software to someone else to use...
Preece: On one level I think it's the same problem as for editors and designers. People think that because they speak English and have opinions about design, they can edit or design. One of the worst problems I ever had on a project was when a high ranking project director from the Department of Trade and Industry wanted to influence the design of a cover for a usability guide. He got annoyed. The graphic designer got annoyed. The final compromise was neither functionally (in terms of conveying the message) nor aesthetically pleasing. I think people who have programming skills assume that because an interface looks OK to them, it will be suitable for everyone else. They often don't know much psychology and don't understand users and their tasks well. The best way to convince them is to let them observe people struggling with their designs and hear about the problems that users encounter.
Mantei Tremaine: I have always been struck by a colleague's story about his Hawaiian friends, who are dumbfounded when mainlanders say, "I can't sing". In essence, the Hawaiians perceive everyone as able to sing as long as they have vocal chords. A similar question could be asked. How do we get the message across to Hawaiians that it is really hard to sing well? If we look at why we think singing is non-trivial, we find the answer embedded in our education and culture. Young people get critiqued in their singing quite early. Some of us get "shushed" in choir practice and all of us get exposed to examples of good singing again and again. User interfaces do not receive this attention, nor do we have interface galleries (akin to art galleries) where we can go to view award designs.
But this answer is somewhat specious as it avoids the question of what to do about the problem. Like singing, the recognition of how hard it is to build good interfaces comes with practice and feedback. I use the trick of having teams run usability studies on their fellow classmates' interfaces. Typical students have blinders to the mistakes they make, but can easily see the multiple problems generated in others' designs.
Hewett: Many folks think they can design a good UI simply because good design is invisible. The essence of a good design is that the user doesn't realize it had to be designed in the first place. This belief leads to my personal feeling that it is necessary to engage them in doing things, so they have commit to making their own design choices, so they can make their own mistakes. Having them only look at good examples of design isn't particularly helpful until they have learned to recognize bad design. It is simply too easy to look at the good design and ask, "Well, how else would you design it?" We do it to ourselves, why shouldn't others be doing it as well?
Dix: This is hard, as the most common systems they know are generic software, such as Office suite, rather than the more bespoke software they are more likely to be involved in designing. One answer, which is crucial in every kind of education, is to constantly ground any abstract, theoretical or generic advice by applying it to real examples. However, this is only part of the answer, as one always picks the examples that are "good" demonstrations of the principles! Most of the students in my department spend a year on industrial placement. Even if they do not get involved in interface design, virtually all come back with a real appreciation of the importance of effective HCI design.
Preece: I think the only way to do this is to expose them to the real world. Ideally this can happen by a co-op arrangement in which they work in the real world while studying. If this can't be done then real world projects provide some of this experience. I get my students to work in teams of two, three or four on real world problems. This may involve them in designing part of a new system, but more often than not they have to do an upgrade design.
Mantei Tremaine: Fortunately for us, Drexel has a co-op program wherein the students work 2 terms out of 4 for every year at the university. Most professors teaching HCI don't have this set of real-world experienced students.
At the University of Toronto, we ran a design course in which a local industry specified the problem. Engineers and marketing people from the company gave several of the class lectures on the technology that was to be used and the specific market that the company was interested in exploiting. Students spent the term gathering information and developing various parts of the design. At the end of the course, we held a design contest funded by the company. The design teams had to present their product as if they were presenting to management or venture capitalists. Thus, they also had to cost out the various parts involved in the design and the cost to make it.
Each team also had to prepare one of many exhibit tables that the judges, university personnel and graduate students perused. Product mock-ups, videotapes of product usage, Wizard of Oz interfaces, user manuals and poster descriptions were all part of this display. The contest awards were approximately $300 for first place and $100 each for 2 runner-ups. Because the company constrained the product design, because there were serious deadlines, because person A in the company gave a different story than person B, because what the company wanted seemed to change daily and because the product had to also have market (contest) appeal, the design process represented some of the real world aspects of putting an interface together.
Hewett: A part of this is hard to do in an academic environment simply because it isn't possible to create a realistic simulation of the "real world" along some important dimensions. E.g., it is very difficult to create design teams that are anything other than ad hoc in a 10-15 week class which preselects for some students and not others. It is even more difficult to engage significant numbers of students in individual or group projects extending over more than a few weeks. One approximation I use is to emphasize the issue of design and to not let them implement their designs. This makes many students uncomfortable as they are used to substituting coding for thought.
Dix: I've used cake recipes. Especially fun are things like "add the fruit, sugar and brandy after mixing the batter." This can be used to discuss hierarchical task breakdown and issues of order, timing, waiting for events, parallel activities, etc. Also knowledge analysis is interesting, as there are so many assumptions made.
Preece: I generally use a cooking example in which students have to work out which ingredients are needed, where they get them from, how they prepare them and the order in which they have to mixed. Often I get them to think about a small meal.
Mantei Tremaine: I try to keep my examples small so that the richness of the detail comes out. One classic example I use is that of editing videotape. I use this in part because everyone in class is familiar with the video editors, but also because the analysis shows the task complexity. I tried a microwave oven, but the young unmarried men in class do not use microwave ovens.
There is also an excellent workflow analysis of a request for a speech to be written in the German ministry that was written up by Peter Mambrey and Mike Robinson in the Group'97 Proceedings that illustrates the complexity of a simple task. Asking the students to put this ethnographic description into a task analysis is a useful exercise for them.
Dix: In a non-HCI course I was commenting on a student's screen design. I suggested an improvement in the alignment of some items to improve readability. The student said "that's really useful" (I feel valued and special) then "but why weren't we taught about that in the HCI course?" (oops).
Preece: I teach systems analysis and design to students with a CS background and others with a nursing or medical informatics background. I teach them formal modeling techniques and some HCI techniques (e.g., task analysis, contextual inquiry, usability testing, etc.) I always have a hard time getting the CS modeling types to appreciate the softer HCI approach and the softer science types to appreciate the modeling. I wouldn't say it is a failure but it is definitely a struggle to get the two groups to recognize the benefits of each approach at different stages of analysis and design. I usually think I have succeeded, but then their behavior or answers on their answers on quizzes show that I've missed again.
Mantei Tremaine: My greatest failure in teaching HCI was my casually teaching my class over a number of years without recognizing that my class interface no longer matched my user population. As East Asian immigration increased in Canada, my class became more and more East Asian. Fortunately, I had an ethnographer friend who did research in Hong Kong and Mongolia. She was able to provide me with a variety of East Asian myth systems and metaphors that I could use to convey some of the HCI concepts in my class. I also used assignments that collected information on the students' cultural perspectives on education. For example, I had teams of students redesign the course web page for specific types of students who might be interested in taking the course, e.g., Korean women, Turkish men, a mixed group of Taiwanese, etc. The language barrier in the course was nearly insurmountable. Having copious notes, speaking slowly and relating the reading to the notes to the assignments explicitly was some help. I also found that not deviating from the course structure made the Asian students more comfortable.
In short, I was guilty of not practicing what I preached.
Hewett: What I consider to be my failures are not specifically failures in teaching HCI but are more general. I find that I am least successful in engaging business majors and convincing them that psychological issues do impact the bottom line. At an individual level, if I have a student tell me at the end of the term that they didn't understand something I spent a fair amount of time on I consider it a failure on my part.
Dix: For both final year projects and also mini-projects during specific modules, our students are encouraged to find their own projects. This instantly spreads the net from your own acquaintances and contacts to that of the whole class, including friends, parents, and previous employment. The downside of this is that you may end up with "boring" projects. However, the real world is of course filled with "boring" jobs to do, so perhaps this is no bad thing! In practice, I find it possible to spice up the problem slightly by suggesting the use of a slightly different design technique, implementation technique or interface paradigm.
Mantei Tremaine: At the University of Toronto we attracted projects from companies who were eager for new design ideas generated by our students' projects. We tended toward the larger companies who benefited from deducting their time from their tax burden. The companies were also eager to have their involvement with the University of Toronto publicized. We approached this area with caution and followed university regulations in this regard. Areas that are "hot", such as mobile computing or electronic commerce, tended to have the most cachet, both with the students and with the companies. Note that we did not have students working on company projects, only generating designs based on company constraints.
I don't think I have a really good answer to Professor Konstan's question. Because classes are made up of such diverse sets of people and because classes are often large, I can understand why companies and university units do not want to have students working on real projects. As an instructor, I am nervous about the responsibility of managing the stray student. I have had design teams test out prototype interfaces with subjects driving a car at 70 miles per hour down a freeway. Members from the university registration staff called my department chair in absolute delight because the university was going to do something about the registration system interface (or so the intro to the questionnaire my students administered said). These are my big horror stories! Perhaps the only way to get real projects is to develop them on one's own. There is a movement afoot to get computer science departments to turn their first two years of coursework into an ongoing software project where teams work on various aspects of the software based on their continually improving expertise. Such projects are a perfect venue for user interface work.
I also am not sure that "real" projects are the best learning experience for students. It is like asking a student to ski before he or she can walk. I would prefer to screen off parts of the real interface in order to explain a specific principle, rather than throwing the entire complexity of a real project at a student. At Toronto we handled this by having two courses, one on HCI theory and one on design (the real projects course).
Hewett: Put the students to work digging up the projects in the first place. Give them the assignment that they are expected to propose a project of their own. While they need some structure (e.g., "Propose a personal information management program that would solve a problem you have with time or information management") to keep from foundering, you can jump start them with an appropriate book (e.g., a book on time management) and let them define the project within the constraints you create. Then the problem becomes one of not over or under constraining the project so that there is room for them to exercise some creativity.
Dix: Forget HCI, this is surely towards the heart of any academic discipline. There is a great cultural effect here with the prevalent western attitude (grossly generalizing here) being towards one's own unsubstantiated individual opinion, whereas eastern culture emphasizes authority. In an academic discipline we want that Golden Mean, a sober estimate of the value of one's own judgments and a well-reasoned critique of others.
As in all things, the best teaching is by example, on the one hand ensuring that one's own critique is well substantiated rather than simply personal opinion, on the other hand making it clear that you, as teacher and authority, are not infallible.
Preece: I get them to critique each other's critiques. I know that some people get students to send critiques to authors. This is great if the authors are receptive. It means that the students have to be careful about how they critique and how they express themselves.
Mantei Tremaine: I don't think I do this well for undergraduates. We have a set of students who have such a heavy course load that all they think of is "what does the teacher want me to think so I can get a good grade". A public university doesn't have the resources to reduce class size and engender the kind of class discussions that would encourage this type of critical thinking. So, what if I had the resources that would change this, what would I do?
I like the idea of the double-dipped paper. By this I mean the submission of the same paper twice, with the second submission following my comments. One of the key comments I would make on the paper would be that "I wanted their opinion, not what they thought I wanted". Double-dipping would apply to papers which critique the assigned course literature from different perspectives. Double-dipping also improves the student's writing. They have to read your comments!
I also endorse the concept of electronic discussion groups that would encourage the less outgoing people in class to contribute their ideas. I find that stepping in and complaining about the lack of originality and insight in the discussions tends to renew the vigor of the discussions and to lead to more critical thinking about the issues.
Hewett: By working with a few examples, in depth, to illustrate the richness and complexity of a typical article, etc.
Dix: Look at any example of an obvious (not subtle) problem in a design and pose the question "why was it designed this way?". Normally the answer lies in constraints of some sort or another: functional trade-offs, limited resources, limited time etc.
Preece: First of all, I'd want to dissuade them from giving up too easily. It's their job to fight for good design. Having said that, they will have time and budget constraints, managers who think they know best, etc. I think bringing in some good designers to "show and tell" about their projects is a start.
Mantei Tremaine: Have the students design a better interface for an automatic teller machine. I first have the students tell me all the things that are wrong with the machines and then try to correct the problems. The history of the users, the need for security, the need to be brief, etc. etc. all constrain any usability improvement they could add to the design.
Hewett: By constraining them in the projects they are allowed to do, e.g., asking them to design an ambitious project assuming a minimal budget, old fashioned underpowered equipment, and a product for use by a target audience which typically does not know or understand its own needs.
Dix: Ignoring of course my own text book and those of my co-panelists, my vote for the most fascinating and exciting book I've read recently is for the classic "Eye and Brain" by Richard Gregory (5th ed., Oxford, 1998).
Mantei Tremaine: I don't know if this question is for an HCI course or for anyone? Books are different partly because they are aimed at different audiences.
For the novitiate in HCI who wants to have a very thorough overview of the field:
Preece, J., Rogers, Y, Sharp, H., Benyon, D., Holland S. and Carey, T., Human Computer Interaction.
For the computer scientist who understands the nuts and bolts of interface design but not psychology
Eberts, R.E., User Interface Design.
For someone who wants to know what all the fuss is about and who would like some good reading
Landauer, T., The Trouble with Computers.
For a good all round upper level course in HCI
Shneiderman, B., Designing the User Interface, Third Edition.
Hewett:
Landauer, The Trouble with Computers
Ericsson & Simon, Protocol Analysis
Dix: One of Piaget's stages of child development is the move from egocentrism to an awareness of other people's perspectives. I think this change in children comes largely through experience, so I guess we may have to wait for this in adults too.
Mantei Tremaine: A quick way to do this is to have them design an interface for blind people and then to make them use it blindfolded.
I also present the "shoemaker's children" problem, going over interfaces that computer scientists have designed for themselves. The interfaces are typically so bad that it is relatively easy to point out problems that computer scientists have again and again with their own systems.
One of the other participatory demonstrations I do in class is to have the students build a keystroke level model for typing in a small program and making corrections to it. They do it for both a touch and a hunt-and-peck typist. I have them calculate the average time saving per line of code and then ask them how many lines of code they expect to type in the next year. Then I ask them how many hours it takes to learn to touch type (approximately 20). The subtle point is that they are making personal time saving decisions for themselves that are not smart. Maybe they are making interface decisions for others that have similar problems.
Hewett: Engaging them in exercises and activities where it becomes clear to them that they don't know as much about humans as they think they do.
Dix: This is doubly difficult.
First, there is a tendency (or at least I know I have a tendency) to focus on problems and errors. The outcome of good practice is often unnoticed just because it works. So, this is a reminder to point out good things as well as bad! Also, when saying something is good, one also needs to say why; just as in art, one doesn't just say "this is a good painting".
Second, good practice is worked out in process and in attitude. Students can see the results of this, but not the path to that result. Formalized methods (task analysis, empirical methods, etc.) can help avoid really bad mistakes, but aren't really what the best HCI designers do, just as real artists don't use painting-by-numbers.
This isn't a disaster, most problems don't need best practice, just good enough practice!
Mantei Tremaine: There is not enough time in an HCI course to cover a set of different practices and then go over what might be the best. I select practices to teach that either fit the resources we have available or have the best education value from my perspective. I don't teach cognitive walkthroughs to undergraduates because I don't think they understand enough about human cognition to grasp what is going on with a cognitive walkthrough. Instead, I teach usability studies. This is harder to do (students have to turn in a videotape of their subjects) because of the lab setup time and the grading time, but half the task is done for the students, that of seeing that a problem exists. Now, all they have to do is reason about why the problem occurred with the interface.
In short, I am happy to teach the student one good practice and to let him or her know that other approaches exist. The depth of focus on one method keeps the course from becoming a light survey course which disappears quickly from their long term memory (about the time the final exam is finished).
Hewett: By learning what some of the bad practices are and why they are bad.
Dix: I find that software developers are well aware of the limitations of their designs and willing to learn. Perhaps the biggest difficulty is learning to focus on the user's real needs rather than the details of a solution.
Mantei Tremaine: I have taken a three month sabbatical at a software development company. At least one hour per week of the sabbatical was used for a presentation on some user interface topic to the developers in the company. The presentation used examples that came from the developers' work. The talks were well received, and the company set up a three person user interface design team from the employees that were most interested in the HCI issues. The three people were the three top programmers and software designers in the company. It might be useful for other companies to invite HCI people on to their site to carry out similar activities. The world is too short of HCI personnel to conduct user interface work for all the software development that is done today. But, insight into the human issues can be transferred.
I realize that Mr. Wright's question was really about teaching methods, not innovation methods. This is implied above in the use of examples for the seminar. I also sat with the aforementioned user interface team and had them practice various task analysis and cognitive walkthrough techniques under my guidance.
Hewett: Engaging them in exercises and activities where it becomes clear to them that they don't know as much about humans as they think they do.
There were many questions that did not get addressed during the panel because of time constraints. Alan Dix offers these written responses to some of them:
Dix: I don't think I've ever constructed a conceptual model of anything without having some potential concrete representation in mind. Furthermore, I will assert that it is bad to suggest to students that they should do so. In this case the question doesn't arise.
Dix: If this is the attitude we would like to instill, we had better not let them read the HCI literature...
Dix: I encourage the use of multiple classifications so that interesting gaps cane be identified. I also try and encourage a "what's good, what's bad, why is it?" approach. If they think something is bad I ask them to think of reasons why it is actually good, and vice versa. One of the most fun ways of approaching this (and most successful) is to think of a deliberately bad idea and then try to justify it (e.g. the interface with a blank screen). See
http://www.soc.staffs.ac.uk/~cmtajd/teaching/res-tech/
Dix: On the one hand it is fragmenting -- instead of HCI options I now see early basic HCI courses followed by specialized courses in CSCW, VR, web design etc. This is the pattern we are seeing in the research field and is likely to continue in HCI education.
So, perhaps the question is whether there will be any core generic HCI education (or even conferences), or just specializations.
I think the answer is yes, there will be a core, because this is also evident in the research literature. On one hand we are seeing a loss of specializations, but on the other hand an increasing we see a realization of the breadth of coverage -- from washing machines to aircraft flight decks. There are key psychological and design issues for interacting with autonomous devices (whether electronic or mechanical) that transcend the ephemeral issues of the day.
Dix: Although very virtuous and proper, formal experiments are unlikely to be a core part of many practical design processes. However, CS students should certainly know about the importance of empirical data and the fact that their intuition about what will work is often not reliable. Rather than over-emphasizing an approach they are unlikely to use it is perhaps better to simply instill these values and suggest the use of `quick and dirty' empirical methods such as cooperative evaluation or expert techniques such as cognitive walkthroughs or heuristic evaluation (which CS students seem to like).
Dix: This depends rather from country to country. At present the bias against HCI in CS departments seems to be less strong than the vilification in many psychology departments. So perhaps career prospects are better within CS. In the UK information science and communication departments are not (at present) major players in HCI, but I know this is different in the US.
Dix: I guess this question is not so much `how to teach', but how to make them want to learn. If you can show them examples where the techniques really help design then they will want to learn, if you can't why should they.
I do believe that abstract concepts are worth teaching, but abstract concepts are abstractions of real things, in research and in teaching the abstractions and the real things they represent should never stray too far.
Dix: Not necessarily the most innovative and effective, but one of the things I like to do is to use physical props within the teaching environment and the students themselves: e.g. to demonstrate the fact that people communicate via objects as well as speech I get two students to carry a table round the room with one of them blindfold.
Dix: I have worked in three computing departments. One was a very traditional computing department and many of the lecturers regarded HCI as irrelevant to the real task of software engineering and programming computers. There were only HCI options in the final year and, not surprisingly, by this stage this attitude had rubbed off on the students. In both the other departments there is a mix of computer science, software engineering and information systems staff. In both of these departments there are mixture of courses available including traditional computing/software engineering courses and more business-orientated computing courses. In these environments HCI options (and on several courses core modules) were available from year 2. Across all kinds of courses the HCI options are amongst the most popular as are modules in related areas such as CSCW and virtual reality. In the early days of computing the mantra was `garbage in -- garbage out'. This is sadly true of the effect of certain classes of computing teachers.
Dix: When I was studying for my first degree (Mathematics) a fellow student `modified' the control panel of the lift in a student residence. He simply crossed over the connections from neighboring buttons. The panel looked the same, but behaved in an unexpected manner! As the building was glass-fronted you could watch people get in the lift, press a button and ascend. They would start to get out, realize they were on the wrong floor and then try again. Their actions ranged from puzzlement (those who gave up) and challenge (those who tried to work out the pattern) to anger (those who kicked the lift). As senior managers usually have offices on the top floor, one day of this should be enough to convince them that internal structure is as important as external appearance.
Dix: I've never explicitly taught about these issues (although should do), but I have known several project students looking at issues such as spelling checkers for dyslexics.
Dix: They get together fine enough in your skull.
Dix: Focus on scenarios and concrete situations -- it is hard for diverse groups to understand each other's language and abstractions, but we can find common ground in the concrete world.
Dix: Two key things to teach:
Dix: See above!
Alan Dix: A.J.Dix@soc.staffs.ac.uk
Tom Hewett: hewett@duvm.ocs.drexel.edu
Jenny Preece: preece@umbc.edu
Marilyn Mantei Tremaine: tremaine@cs.princeton.edu
Carey, T., Peerenboom, D., & Lytwyn, M. (1997). Learning About User-Centered Design: A Multimedia Case Study Tutorial. CHI 97 Extended Abstracts, New York: ACM, pp. 267-268.
Carey, T., Mitchell, S., Peerenboom, D., & Lytwyn, M. (1998). Design Evolution in a Multimedia Tutorial on User-Centered Design. CHI 98 Conference Proceedings, New York: ACM, pp. 109-116.
Williams, M. G. & Sears, A. (1998). Famous CHI Educators Tell All. CHI 98 Summary, New York: ACM, pp. 94-95.
Marian Williams is Co-Chair for CHI 99 and past Vice Chair for Operations of ACM SIGCHI. She was co-chair of the tutorials program for CHI 96 in Vancouver. She is Assistant Professor in the Computer Science Department at UMass Lowell, where she teaches a series of graduate courses in HCI; advises undergraduate, Master's, and doctoral students; leads HCI research projects; and coordinates the Graduate Certificate program in HCI.
Andrew Sears is chair of the SIGCHI Educational Resource Development Group, Student Volunteer Co-Chair for CHI 99, and the SIGCHI Bulletin's contributing editor for education. He was co-chair of the tutorials program for CHI 98 in Los Angeles. He is Assistant Professor in the School of Computer Science at DePaul University where he teaches both undergraduate and graduate HCI courses; advises HCI students (undergraduate through Ph.D.); and directs a variety of HCI research projects.
Marian G. Williams
Computer Science Department
University of Massachusetts Lowell
Lowell, MA 01854 USA
williams@cs.uml.edu
Andrew Sears
School of Computer Science
DePaul University
243 South Wabash Avenue
Chicago, IL 60604 USA
sears@cs.depaul.edu
Issue |
Article |
Vol.30 No.4, October 1998 |
Article |
Issue |