Incorporating HCI into the Undergraduate Curriculum: Bloom's ... - ICEE

Session T2H

Incorporating HCI into the Undergraduate Curriculum: Bloom’s Taxonomy Meets the CC’01 Curricular Guidelines Bill Manaris and Renée McCauley College of Charleston, Computer Science Department, Charleston, SC 29424 [email protected], [email protected]

Abstract - This paper presents an outline for an upper-level Human-Computer Interaction (HCI) course. This work is being carried out in the context of an NSF-sponsored effort by 26 CS educators to incorporate HCI into the undergraduate CS curriculum. This paper presents an overview of existing approaches for incorporating HCI in the undergraduate curriculum, including several “standard” textbooks. It briefly discusses the perceived gap between the interests of the HCI community and the needs of CS educators. It then proceeds to address this issue by presenting one possible implementation of the CC’01 HCI curricular guidelines. This implementation includes a semester-long course outline, project ideas and considerations, and, most importantly, measurable course objectives based on Bloom’s taxonomy. Finally, it includes pointers for additional, forthcoming implementations of the CC’01 HCI curricular guidelines. Index Terms - Bloom’s Taxonomy, Computing Curricula 2001, Human Computer Interaction, Undergraduate CS Curriculum. INTRODUCTION

mainstream recognizes the need for deriving a good conceptual model prior to software implementation. However, when it comes to the user interface most CS educators do not know how to develop, much less teach others how to develop such a model. This is supported by a recent survey among IT employers published by IEEE Computer [3]. This survey identifies the 20 most important knowledge areas lacking among software professionals. HCI and user interfaces were listed as the second most important area (after Negotiation), where importance most exceeds current knowledge. This lack of preparation is evident in today’s software products. It is not hard to imagine the reduction in productivity across the whole socioeconomic spectrum of our nation caused by software that has usability defects – computers are now integrated in most professional and many non-professional environments. Further, the lack of preparation of software developers in terms of HCI skills demonstrates the need for incorporating HCI into the undergraduate CS curriculum in a systematic way. With this motivation we submitted a grant proposal for support of a project entitled “Incorporating HCI in to the Undergraduate Curriculum: A Community-Building Initiative,” to the National Science Foundation, Directorate for Undergraduate Education.

Since the publication of the ACM SIGCHI Curricula for Human-Computer Interaction in 1992 [1], CS educators have tried various implementations of these guidelines. These GOALS OF THIS INITIATIVE implementations have been mainly offered as elective courses or modules within other courses, such as Software The aim of this project is to build a tight, yet diversified Engineering, Graphics and Multimedia, or even the community of CS educators interested in incorporating HCI introductory sequence (CS1 and CS2). However, only 3% of into undergraduate CS curricula. It follows a special session CAC-accredited degree programs currently require an HCI at SIGCSE-2002 where a group of 40+ participants expressed course at the upper level [2]. interest in attending a workshop on this topic [4]. The technical expertise of the average end-user has This community-building initiative is being implemented decreased dramatically over the last decade or so. This is through a four-day workshop and two follow-up reflection because powerful computing platforms that cost thousands of meetings at SIGCSE symposia. Its objectives are to: dollars a few years ago are almost free today. We now find a) expose a representative group of CS educators to them in just about every house and every business. End-users significant HCI issues, educational approaches, and with minimal computer expertise are expected to use them classroom experiences; effectively and productively. Consequently, user interfaces b) disseminate implementations of the HCI core have become increasingly complex in terms of functionality requirements in ACM/IEEE Computing Curricula 2001; (features, options), usability requirements, and learnability c) facilitate opportunities for networking and team-building requirements. among CS educators; and provide the infrastructure to Today at least 50% of the code written for software applications is specific to the user interface. The CS 0-7803-8552-7/04/$20.00 © 2004 IEEE October 20 – 23, 2004, Savannah, GA 34th ASEE/IEEE Frontiers in Education Conference T2H-10

Session T2H begin addressing the weak HCI preparation among CS graduates. I. HCI Knowledge Units in CC’01 The workshop content was organized around the HCI topics identified in Curricula 2001 [5]. These are as follows: • HC1. (Core) Foundations of human-computer interaction (min 6 hours). • HC2. (Core) Building a simple graphical user interface (min 2 hours). • HC3. (Elective) Human-centered software evaluation. • HC4. (Elective) Human-centered software development. • HC5. (Elective) Graphical user-interface design. • HC6. (Elective) Graphical user-interface programming. • HC7. (Elective) HCI aspects of multimedia systems. • HC8. (Elective) HCI aspects of collaboration and communication. The overall aim of the initiative is to create a community of educators able to implement these guidelines within their own curricular programs and able to support each other in this endeavor. The four-day workshop was held on the campus of the College of Charleston in Charleston, SC in May 2003. The two follow-up meetings are to help strengthen connections among members of this community. The first follow-up meeting was held March 4, 2004 in Norfolk, VA in conjunction with SIGCSE 2004. BLOOM’S TAXONOMY Bloom [6] defines six levels of educational objectives at the cognitive domain: 1) recall 2) comprehension 3) application 4) analysis 5) synthesis, and 6) evaluation. This taxonomy is very useful for refining learning objectives. In particular, for each topic or knowledge unit to be covered, an educator needs to identify the highest level of competence that students should achieve. This information has great impact if included in the course syllabus. In our experience, students become more engaged. They start asking deeper questions. They understand better what is expected of them. Also, the instructor knows better what to expect, how to teach the materials (e.g., develop assignments), and most importantly, how to assess student performance (e.g., devise test questions). I. Bloom’s Taxonomy in CS Although Bloom’s taxonomy has been used effectively for many years in various education fields, it has only recently been applied to computer science: Lister and Leaney discuss how to use it to assess student performance in an introductory

programming course [7]. Scott proposes how to apply the taxonomy to testing across the CS curriculum [8]. To the best of our knowledge, Bloom’s taxonomy has never been applied specifically to HCI. We propose one possible HCI course implementation of the CC’01 guidelines, which incorporates Bloom’s taxonomy. CURRENT APPROACHES Overall, the CS education mainstream has been slow in recognizing the importance of HCI in software development. For instance, as mentioned earlier, only 3% of CACaccredited degree programs currently require an HCI course at the upper level. There have been four significant efforts in HCI curricular guidelines: • The Software Engineering Institute (SEI) curriculum module and support materials on user interface development [9]. • The 1992 ACM SIGCHI Curricula for Human-Computer Interaction [1]. • The 1994 NSF/ARPA recommendations for HCI education [10]. • The 2001 ACM/IEEE Curricular Guidelines [5] These guidelines have been implemented in various forms, ranging from whole courses to modules within other courses, such as Software Engineering, Graphics and Multimedia, and the introductory sequence (CS1 and CS2). The following is an overview of a few recent approaches: I. Recent HCI Courses in CS Leventhal and Barnes [11] present an HCI course that integrates HCI theory with actual software development. Their topics include introduction to usability; user interface lifecycle; tools for user interface development; design and interaction styles; evaluation; cognitive phenomena; and assistive technologies. The authors discuss a sample project and alternative approaches. Reimer and Douglas [12] employ a studio-based approach in teaching user interface design. Studio-based courses have been used for many years in other design-centric fields such as architecture, product design, and studio art. This approach incorporates weekly design problems, collaboration between students and faculty, production of realistic artifacts, and weekly design critique sessions. Instead of lecturing about design guidelines, instructors surround their students with design artifacts and immerse them in a realistic design process. van der Veer and van Vliet [13] build their case on the proposition: “The user interface is the system!” Traditional software development models and current curricular guidelines (e.g., CC’01) treat the user interface as a secondary, follow-up activity in software development. They explain that, for most software projects, usability is the decisive factor for product quality. They describe a minimal, but essential HCI component for CS and SE curricula. They also provide examples of common user interface problems and illustrate

0-7803-8552-7/04/$20.00 © 2004 IEEE October 20 – 23, 2004, Savannah, GA 34th ASEE/IEEE Frontiers in Education Conference T2H-11

Session T2H how these problems would be easily eliminated if a more integrated approach were followed. II. A Perceived Gap between HCI and CS Miller [14] discusses why HCI remains in the periphery of most CS programs. Traditional CS focuses on mathematical problem solving, well-specified problems, axioms, and verifiable algorithms. On the other hand, HCI focuses on psychology, ill-defined problems, guidelines, and usercentered design and evaluation. Miller proposes to bridge this gap through HCI modules that apply a theory, derive detailed predictions, and verify those predictions against empirical data. He presents a sample module based on the Keystrokelevel model. Another way to bridge this perceived gap is through the approach used by Leventhal and Barnes; again this involves building a course outline around a software development project. This is especially appropriate for departments without a strong HCI orientation. Since CS is intimately associated with software artifacts, incorporating software development into an HCI course seems, at least, reasonable. After all, in the real world, CS graduates involved in HCI projects will most probably be expected to contribute to software development. So, it is important for CS students to understand HCI theory, but also know how to apply it in building software artifacts. ONE POSSIBLE IMPLEMENTATION Clearly, there are many possible ways to incorporate HCI into the undergraduate CS curriculum following the CC’01 guidelines. There are several factors to consider, including student preparation, learning objectives, and various curriculum constraints. One possible implementation is presented in this section. Other possible implementations are currently being refined by Scott Grissom [15], Tom Horton [16], Craig Miller [17], Ben Schafer [18], Christine Shannon [19], Michael Wainer [20], Charles Welty [21], and John Wright [22]. These will be formally disseminated in the near future. I. Software Development in HCI Courses As mentioned in the previous section, it seems reasonable to incorporate some programming into HCI courses developed for traditional CS students. For such courses, teaching materials may be structured according to four software development phases, namely Analysis, Design, Implementation, and Evaluation. Since, evaluation should ideally follow every phase of user interface development (UID), this creates an apparent “Catch-22”: In order for students to be able to evaluate UID artifacts, Evaluation should be taught early on. However, doing so pushes Implementation to the end of the semester, without sufficient time to develop a software artifact. Our approach has been to loosely structure course materials around a software project and present needed topics in a “just-in-time” fashion. Depending on the selected project, sometimes this may involve iterative refinement

among Evaluation, Design, and Implementation topics, as necessitated by project phases. Finally, we expect students to evaluate each other’s work though cognitive walkthrough sessions and demos; we have found this to be very motivational and instructional. In terms of selecting a project, one possibility is to have a sizable software artifact where the students implement only the UI layer. Another possibility is to select a very small application and ask student to develop the complete artifact. One advantage of the latter is that, if the students build for technology’s sake, as sometimes happens, this will be clearly obvious to the instructor and their classmates. On the other hand, if students follow the proper methodology, they will learn valuable HCI concepts, while producing a fully functional system, whose usability will be easy to evaluate, due to the small task set. II. One Possible Course Outline Table 1 presents an outline for a project-based HCI course at the junior/senior level. This course covers the core knowledge units HC1 (6 hours) and HC2 (2 hours). Additionally, it covers the elective knowledge units HC3 (approx. 6 hours), HC4 (approx. 12 hours), HC5 (approx. 5 hours), HC6 (approx. 8 hours), and HC7 (approx. 2 hours). We assume that students have no previous experience with building GUIs. Therefore, we try to introduce GUI building as soon as possible, so that students may gain enough experience to carry out the implementation phase of the project. One possible drawback of this is that it pushes paper prototyping later into the semester. However, if students already have some experience with building GUIs prior to this course, paper prototyping could be covered as early as the fifth week. This course originated from the SEI materials [9], and has evolved through the 1992 ACM/SIGCHI guidelines [1], and CC’01 [5]. It has been taught approximately once per year since 1995. It has mostly been offered as a junior/senior undergraduate course, sometimes co-listed as a graduate course. Graduate students are expected to do additional readings and homework. III. Student Assignments In terms of student assignments, during the lifecycle of this course, homework expectations have ranged from very little programming to a semester-long project. Projects have ranged from written reports, to simple GUI applications (e.g., calculators), to GUI wrappers for command-line applications, to student-selected innovative multimedia applications, to a GUI UIMS for natural language interfaces, to a speech user interface for motor-impaired users. IV. Textbooks In terms of textbooks, during the lifecycle of this course, we have used/consulted several textbooks. A small subset is listed below. We feel that these textbooks best suit our target audience and learning objectives. Of course, there are


Session T2H numerous other possibilities. (Parenthesized abbreviations are used in Table 1.) (aJGPP) (DtUI) (DUI) (HCI.a) (HCI.b) (ID)

Culwin “A Java GUI Programmer’s Primer” Shneiderman “Designing the User Interface” Hix and Hartson “Developing User Interfaces” Dix et al. “Human-Computer Interaction” Preece et al. “Human-Computer Interaction” Preece et al. “Interaction Design”

(tDoET) Norman “The Design of Everyday Things” (UIDfP) Spolsky “User Interface Design for Programmers” (UCWD) McCracken and Wolfe “User-Centered Website Development” Currently, we use ID and supplements from the above list and elsewhere. In the future, we might require ID together with UIDfP. Another possibility is the new edition of DtUI by itself. Finally, UCWD could be used by itself in a lower-level

TABLE I ONE OF MANY POSSIBLE PROJECT-BASED HCI COURSE IMPLEMENTATIONS OF CC’01 USING BLOOM’S TAXONOMY TO INDICATE STUDENT COMPETENCE: RECALL [1], COMPREHENSION [2], APPLICATION [3], ANALYSIS [4]; SYNTHESIS [5]; EVALUATION [6]. OUTLINE IDENTIFIES SEMESTER TIMELINE, CC’01 TOPIC COVERAGE, ASSESSABLE LEARNING OBJECTIVES, SAMPLE IN-CLASS ACTIVITIES, SAMPLE PROJECT PHASES, AND READING ASSIGNMENTS {BRACKETS DENOTE POSSIBLE ADDITIONAL REFERENCES FOR THE INSTRUCTOR}. Week

CC’01 Assessable Learning Objectives [Bloom’s level of competence]

Activities

Reading

Aug 26

HC1

HCI and ID definitions [2] Rationale for learning HCI [2] UI history and evolution [2] UIs as abstraction barriers [4] Abstraction components in UIs of everyday things [4]

Recognize UIs as abstraction barriers (e.g., instructor’s watch, automobile) Interact with Norman’s refrigerator (DoET) When designers ignore consumers: BMW iDrive, Konica camera/MP3 player Innovative UIs: Dasher, TextArc

ID: Ch 1 {UIDfP: Ch 1} {UCWD: Ch 1}

Sep 2

HC1

Usability terminology [2] Norman’s design analysis concepts [4] Measurable human factors [2] Nielsen’s usability principles [4] Interaction frameworks [4] Study of bad UIs [4]

Analyze 1996 Eagle Vision TSi AutoStick® UI and subsequent refinement Homework #1: Pick a freeware alarm-clock program; identify usability issues

Handouts {UIDfP: Ch 2-4} {tDoET: Ch 1} {HCI.a: Ch 3}

Sep 9

HC3

Cognition and usability (e.g., mental models, standards vs. guidelines, HCI guidelines) [4] Interaction styles and paradigms [3]

Homework #1: Presentations (HTML)

ID: Ch 2, 3 {DUI: Ch 2} {UCWD: Ch 2, 9}

HC5 Sep 16

HC5 HC7

Metaphors (e.g., simple vs. composite, design guidelines, etc.) [3] Refine a composite metaphor Design of command-line interfaces [5] Design a simple command-line interface Natural language interfaces [2] Test #1

{UIDfP: Ch 5, 6} {DtUI: Ch 8}

Sep 23

HC6

Comparison of prototyping languages and IDEs (e.g., Visual Basic, NetBeans, V C++, Gnome, Python, Tcl/tk) [3] Event control model [3] Basics of a GUI prototyping language and IDE [3]

Homework #2: Develop a GUI prototype with IDE of choice

Handouts

HC2 Sep 30

HC2 HC6

Basics of a GUI prototyping language and IDE [3] GUI modularization techniques (e.g., presentation-translationapplication layers, Model-View-Controller, etc.) [5]

Demos of IDE and sample GUIs

Handouts

Oct 6

HC4

Interaction design process, UI lifecycle, Mayhew usability lifecycle [3]

Homework #2: Demos View Tandy Trower video: “Creating a Well-Designed User Interface”

ID: Ch 6 {UIDfP: Ch 12}

Oct 12

HC4

User needs and requirements [5] Scenario-based usability methods [5]

Homework #3a: Identify user needs for a Zen alarm clock; develop scenarios for different user profiles

ID: Ch 7 {UIDfP: Ch 7, 9-11} {UCWD: Ch 3}

Oct 21

HC4

Paper prototyping [5]

View Nielsen-Norman-Group video: “Paper Prototyping: A How-To Training” Develop paper prototype of Zen alarm clock

ID: Ch 8 {UCWD: Ch 7} Handouts

Oct 28

HC4

Task analysis (HTA) [6]

Homework #3b: perform task analysis; refine paper prototype of Zen alarm clock

ID: Ch 7 {HCI.a: Ch 7}

Nov 4

HC6

Formalizing interaction design (e.g., state transition diagrams) [6] Homework #3: Presentations (HTML) {aJGPP: Ch 1} Homework #4: Develop STD for Zen alarm clock {HCI.a: Ch 8}

Nov 11

HC5

Design of selection spaces (e.g., GUI menus, web interfaces) [6] Homework #4: Presentations (HTML) Design patterns for web interfaces [3] Homework #5: Implement Zen alarm clock with IDE of choice

Handouts {UIDfP: Ch 14-17} {DtUI: Ch 7} {UCWD: Ch 4-6}

Nov 18

HC3

Human-centered evaluation [4]

Test #2

ID: Ch 10 {UCWD: Ch 8}

Nov 25

HC3

Predictive modeling techniques (e.g., GOMS, Keystroke-level model, Fitt’s law) [4]

Homework #5: Demos Homework #6: Evaluate two Zen alarm clocks

ID: Ch 14 {UIDfP: Ch 13}

Putting it all together

Homework #6: Presentations Partner/Course evaluations

Dec 2


Session T2H web development course, as it is the only HCI textbook, that we know of, specifically targeted for CS students (as opposed to, say, IT or HCI students). V. Programming Languages In terms of development, programming languages and environments we have used, over the lifecycle of this course, include in chronological order HTML, XForms, SUIT, Java, Tcl/tk and Expect, and Visual Basic. Another option we are considering for our next offering is Python with the GLADE GTK+ UI builder. In terms of platforms, we have used Sun workstations, Silicon Graphics workstations, and Wintel PC platforms. Selecting a platform-independent language is obviously a better choice. Possibilities include Java, Python, and Tcl/tk. However, sometimes this may not work smoothly, especially if the language is not mature enough. For instance, Java’s change of event model (circa version 1.01) happened during one offering of this course, and after students and instructor had made a considerable investment in the outgoing event model. VI. Students as Teacher-Scholars Finally, in accordance with the teacher-scholar model, we usually invite better students to enroll in a follow-up independent-study course to participate in on-going research activities. If done well, this introduces a feedback loop between teaching and research: Research materials are introduced in the classroom educating students in the state-ofthe-art; good students get involved in advancing the state-ofthe-art; new results are incorporated in lectures and assignments in future course offerings. In this model, students are viewed as apprentice scholars who eventually mature enough to contribute to journal publications and possibly coauthor grant proposals. CONCLUSION This paper presented one possible implementation of the HCI curricular guidelines included in CC’01. This implementation employs Bloom’s taxonomy to identify levels of student competence for each of the learning objectives. We provide additional pointers to other possible implementations of such courses. This work is been carried out in the context of an NSF-sponsored effort by 26 CS educators to incorporate HCI into the undergraduate CS curriculum. We hope the materials from this NSF project, including the course outlines reported herein, may help the CS community as they begin to incorporate HCI into their curricula, in accordance with the CC’01 curricular guidelines. ACKNOWLEDGMENT

helped shape the workshop objectives. Robert Aiken, Sally Fincher, and Blaise Liffick provided general advice and feedback on the curriculum. Sarah Douglas, Arthur Kirkpatrick, Laura Leventhal, and Craig Miller served as workshop instructors. Michael Wainer contributed materials on communicating UI design to software developers and possible implementations of Model-View-Controller. Christopher Andrews, Julie Barnes, Dennis Bouvier, Douglas Dankel II, Charles E. Frank, Robert Franks, Mary Granger, Scott Grissom, Thomas Horton, Hubert Johnson, Myungsook Klassen, Aparna Mahadev, David R. Naugler, Kris Powers, Dean Sanders, J. Ben Schafer, Nan C. Schaller, Christine Shannon, Michael Wainer, Charles Welty, and John Wright contributed through discussions at the workshop and the first reflection meeting. REFERENCES [1]

Hewett, T.T., ed., ACM SIGCHI Curricula for Human-Computer Interaction. ACM Press: New York, 1992. http://sigchi.org/cdg/

[2]

McCauley, R., and Manaris, B., Survey of Departments Offering CACAccredited Programs, 2002. www.cs.cofc.edu/~mccauley/survey/

[3]

Lethbridge, T.C. “What Knowledge is Important to a Software Professional?” IEEE Computer Vol. 33, No. 5, May 2000, pp. 44–50.

[4]

Manaris, B., Douglas, S., Leventhal, L., Tremaine, M., and Wills, C.E., “Incorporating Human-Computer Interaction into the Undergraduate Computer Science Curriculum”, Proceedings of the 33th ACM Technical Symposium on Computer Science Education (SIGCSE-02), Northern Kentucky, Feb. 2002, pp. 211-212.

[5]

Engel, G., Roberts, E., eds., ACM-IEEE Computing Curricula 2001, Dec. 2001. www.computer.org/education/cc2001/final/

[6]

Bloom, B.S., ed., Taxonomy of Educational Objectives: Handbook 1: Cognitive Domain, Longmans, Green and Company, 1956.

[7]

Lister, R. and J. Leaney. “Introductory Programming, CriterionReferencing, and Bloom,” in Proceedings of the Thirty-Fourth SIGCSE Technical Symposium on Computer Science Education, Reno, Nevada, USA, February 19-22, 2003, pp. 143-147.

[8]

Scott, T. “Bloom’s Taxonomy Applied to Testing in Computer Science Classes,” in Proceedings of the Twelfth Annual CCSC Rocky Mountain Conference, J.G. Meineke (editor), Silver City, New Mexico, October 17-18, 2003, pp. 267-274.

[9]

Perlman, G., User Interface Development, SEI Curriculum Module SEICM-17-1.1, Nov. 1989. ftp://ftp.cis.ohio-state.edu/pub/hci/SEI/module.txt

[10] Strong, G., ed., New Directions in HCI Education, Research, and Practice, NSF/ARPA Report, Feb. 1994. www.sei.cmu.edu/community/hci/directions/TitlePage.html [11] Leventhal, L. and Barnes, J., “Two for One: Squeezing HumanComputer Interaction and Software Engineering into a Core Computer Science Course”, Computer Science Education Vol. 13, No. 3, special issue on Human-Computer Interaction, September 2003, pp. 177-190. [12] Reimer, Y.J. and Douglas, S., “Teaching HCI Design With the Studio Approach”, Computer Science Education Vol. 13, No. 3, special issue on Human-Computer Interaction, September 2003, pp. 191-205.

This work has been supported by NSF (DUE-0226080) and [13] van der Veer, G. and van Vliet, H., “A Plea for a Poor Man’s HCI the College of Charleston. Christopher Andrews, Douglas Component in Software Engineering and Computer Science Curricula; Dankel II, Scott Grissom, Dean Sanders, and Michael Wainer After all: The Human-Computer Interface is the System”, Computer Science Education Vol. 13, No. 3, special issue on Human-Computer provided feedback on this paper. Gary Strong provided early Interaction, September 2003, pp. 207-225. guidance regarding the placement of Evaluation in an HCI course involving software development. Sarah Douglas 0-7803-8552-7/04/$20.00 © 2004 IEEE October 20 – 23, 2004, Savannah, GA 34th ASEE/IEEE Frontiers in Education Conference T2H-14

Session T2H [14] Miller, C.S., “Relating Theory to Actual Results in Computer Science and Human-Computer Interaction”, Computer Science Education Vol. 13, No. 3, special issue on Human-Computer Interaction, September 2003, pp. 227-240. [15] Scott Grissom, “CS380 Usability Design”, course materials, March 2004. http://www.csis.gvsu.edu/~grissom/380/ [16] Tom Horton, “CS305: Usability Engineering”, course materials, March 2004. http://www.cs.virginia.edu/~horton/cs305/ [17] Craig Miller, “HCI 360 Evaluation for Human-Computer Interaction”, course materials, March 2004. http://facweb.cs.depaul.edu/cmiller/hci360/syllabus.html

[19] Christine Shannon, “FRS141 Designing Websites as though Users Mattered”, course materials, March 2004. http://web.centre.edu/shannon/frs141/ [20] Michael Wainer, “CS 484: User Interface Design and Development”, course materials, March 2004. http://www.cs.siu.edu/~wainer/484S04/484S04OL.html [21] Charles Welty, “COS386 Graphical User Interface Design”, course materials, March 2004. http://www.cs.usm.maine.edu/~welty/cos368/368fall2003/ [22] John Wright, “CS260/IT260 Human-Computer Interaction”, course materials, March 2004. http://faculty.juniata.edu/wrightj

[18] Ben Schafer, “CS 810:112 User Interface Design, Implementation, and Evaluation”, course materials, March 2004. http://www.cs.uni.edu/~schafer/courses/112/
