CS and Psych 6750
Human-Computer Interaction
Spring 2008

 

                        Contact Info

                                                Professor: Dr. Melody Moore Jackson
                                                Office : TSRB 332
                                                Lab: TSRB 2nd floor
                                                Office hours: by appointment


                                                phone: 404-385-7510


                                                email: melody at cc dot gatech dot edu
                                                Send Melody mail

                                                Teaching Assistant: Hyungsin Kim
                                                Human-Centered Computing Ph.D. student
                                                email: hyungsin at gatech dot edu
                                                Send Hyungsin email

 

Spring Semester 2008

bullet Class meets in Bunger-Henry 413
bullet Required Texts:
"DFAB":  Human-Computer Interaction (3rd ed.), by Alan Dix, Janet Finlay, Gregory Abowd, and Russell Beale. Prentice Hall, 2004.
Available at the GT Book Store. See also: amazon.com and other places for both new and used editions.
"DOET": The Design of Everyday Things, by Donald Norman. Currency/Doubleday, 1990.
Available at the GT Book Store. See also: amazon.com and other places for both new and used editions.
 
bullet Lecture materials, assignments, announcements, and schedule changes will be posted to this site, so please check regularly!
bullet Additional materials can be found in the HCC Education Digital Library

Announcements

Last update:  May 1, 2008

bullet

Please submit the peer and self review forms by Sunday, May 4 via email to Melody

bullet

Hyungsin has emailed grades for P4, let her know if you did not receive it.

bullet Make sure to upload on T-square to publish and share project files (on the wiki within)

 

Class Schedule (subject to updates)

Week Date Topic Reading Assignment Project
1 1-8-08

1-10-08

Introduction, Project Overview

History and Frameworks of HCI
Begin DOET

DFAB Introduction

 

CITI Training certificate due

 
2 1-15-08

1-17-08

User Centered Design Usability Principles

Human abilities - sensory and perceptual

DFAB 2,3,4

DFAB 1

   

HW1

   

Part 0 - proj description due

3 1-22-08

1-24-08

Human abilities - cognition

Requirements gathering and task analysis, IRB

DFAB 9

DFAB 6, 15

   

HW1 due

 
4 1-29-08

1-31-08

Design of Everyday Things , Tao of Pooper Scoopers, IRB applications

Design of Everyday Things con't

 

complete DOET

Hall of Fame/Shame

 

IRB applications due by Jan 31
5 2-5-08

2-7-08

DOET, Design HOF/S

Graphic design: principles and color

DFAB 5

DFAB 7

Hall of Fame/Shame nominations due

 

Part 1: Requirements due

  

6 2-12-08

2-14-08

Graphic design con't: typography

Interaction Design: CL and WIMP
Interaction Design: Direct Manipulation

DFAB 14, 16

DFAB 18

   
7 2-19-08

2-21-08

Error Handling and Help

Prototyping

DFAB 11

DFAB 8

     

 

8 2-26-08

2-28-08

Midterm Exam

Project Poster Session

DFAB 11

DFAB 8

     

Part 2: Design Alternatives due

9 3-4-08

3-6-08

User Modeling 1 - Thoughts and Actions

User Modeling 2 - Context

DFAB 12
MHP paper,
MacKenzie paper

Nardi paper

  HW2

 

 
10 3-11-08

3-13-08

Evaluation intro

Evaluation 2

DFAB 9

 

  HW 2 due

 

 
11 3-18-08

3-20-08

SPRING BREAK      
12 3-25-08

3-27-08

Evaluation 3

Prototype demos - NO CLASS MEETING

 

HW3

Schedule demo w MMJ

   

Part 3: Prototype due (schedule demo with MMJ)

13 4-1-08

4-3-08

Ethics in Research

Specialized interfaces - gesture and pen, speech

 

Belmont Report

DFAB 18

 

HW 3 due

 
14 4-8-08

4-10-08

Project meetings - NO CLASS MEETING

Interfaces for Assistive Technology

 

 

 
15 4-15-08

4-17-08

Designing for the Web

Ubiquitous and pervasive computing

DFAB 21

DFAB 20

   
16 4-22-08

4-24-08

NO CLASS -usability testing

Project Presentations

        

Part 4: Evaluation  due

finals week

 

4-28-08    8:00 - 10:50 a.m.

 

FINAL EXAM      

 

nGrading

bullet nGroup project, 4 parts (45%)
n
bullet nMid-term & final exams (30% total)
bullet nHomeworks (15% total)
n
bullet nParticipation (10% total)
bullet nClass involvement, classwork, quizzes, and peer review

n

 

CS/Psych 6750 Team Project

Theme for Spring 2008:  "Innovation in Interfaces for Everyday Life"

Computer interfaces are all around us; in our homes, our cars, even on our bodies.   Your task this semester is to choose an issue to solve in your home,
school, car, or other aspects of your personal daily life.  What interface would YOU love to have at your disposal?   You and your teammates will design,
build a simple prototype (a.k.a. does not really have to work, but the interface design should be testable) and evaluate your idea.

Outline

Quick access to the sections of this document:

bullet Project Report Book
bullet Part 0 - Topic Definition
bullet Part 1 - Understanding the Problem
bullet Part 2 - Design Alternatives
bullet Part 3 - System prototype and evaluation plan
bullet Part 4 - Evaluation
bullet Project Presentation

 

Notes on the IRB Approval Process

Notes on IRB:
 
  1. Getting IRB-certified. It includes the following steps:
       1. Request CITI Username
       2. Complete CITI Training (follow emailed instructions)
       3. Submit HARDCOPY Completion Certificate to Professor (and keep a copy for yourself)
  2. Log into IRB WebWise using your GT prism account.
  3. Complete your IRB proposal using the IRB WebWise Protocols Page. Note: you will need a summary of the experiment, plus the Informed Consent, so you can cut and paste or upload the entire document, via the Web form. You may use the following Informed Consent [.doc, 32k] or the simpler Basic Consent form (from Melanie Clark) [.doc, 28k] as a template; modify either of them as required for your project.
  4. Typically you will put your professor as the Principal Investigator (PI), and list the student team members as "Students" on the protocol.
  5. Submit the protocol to the PI, who will then submit it to the Department Chair, who will then submit it to the IRB for real. Then it will be processed by the GT IRB. It can take 1-2 weeks for this last stage. You need to watch for any modifications requested by the IRB. Typically you will need to change a document and upload a new version of the document.
  6. You can begin to run your experiment once you have received IRB approval.

 

IRB questions to mailto:melanie.clark@osp.gatech.edu@osp.gatech.edu

Project Overview

This term you will undertake a group project (4 team members) to evaluate some computing-related task/problem, to develop interface design alternatives for the task/problem, to implement a prototype of your design, and to evaluate your design. This project should provide you with hands-on experience with the tasks that interface designers face every day. Ideally, the topic of the project will be a problem that matters to some "real-life" people.

Each project group will be graded as a team, that is, each person receives the same grade. Periodic team reports will be required to evaluate the contributions of each team member.  Lack of participation will precipitate an individual reduction of grade. Within the team, you must negotiate on how much and what each person will contribute. Think carefully about your team members: Where do people live and what hours do they work? Where will you meet? What skills do the different individuals bring to the group (computing, programming, design, evaluation, statistics, etc.)? I would strongly encourage you to form a heterogeneous team full of individuals with varying skills.

Project Report Portfolio

Each part of the project will include a deliverable report. This report will be placed on the web in an electronic format; a paper copy will also be handed in. Each team should have a "home" page which includes: 1) a brief (paragraph) description of the problem/task; 2) the team members; 3) Links to the reports for project parts 1-4. The format of the reports for the individual parts is ultimately up to you, but there will be templates for the sections, to help your team know what to expect, and what is expected. In any case, it should be professionally prepared, concise yet expressive, grammatically sound, illustrative of your efforts and process, and easy to view and understand. A good design effort can easily be hampered by a poor communication of what was done.  Make sure to include ALL SECTIONS of documents required in order to earn the maximum points.

Part 0 - Topic Definition

This first part of the project is relatively simple. You must list the members of your team and identify the problem area that you will be working on. You also must set up your web project space  on T-Square that lists your team name, members, and provides links to all of the project deliverables.

Part 1 - Understanding the Problem

The key goal of this first substantive part of the project is to deeply understand that problem space that you are addressing, its set of pertinent users, and the issues and constraints that are involved in the problem. If the task has an existing system/interface, you should perform an interpretive evaluation of that system to help you learn more about it. Most important is to identify important characteristics of the problem that will influence your subsequent design.

In class and in the readings you will learn about different techniques for acquiring this kind of information. You are encouraged to utilize the techniques that you feel are most appropriate to the particular task you are examining. Your report and deliverable for this part should deeply examine the problem of study. Who are the potential users? What tasks do they seek to perform? What functionality should the system provide? Basically, you are setting up a set of constraints for your subsequent design. What criteria should be used to judge if your design is a success or not?

More specifically, you should develop the following items in this part, and you should communicate them through your report:

bullet An overview of what the system will do and why it's needed.
bullet A description of the important characteristics of the users of the system.
bullet A task analysis consisting of
bullet A description of the important characteristics of the tasks performed by users.
bullet A description of important characteristics of the task environment.
bullet A simple structured task analysis of the problem in one of the forms described in the textbook.
bullet An analysis of the existing system, automated or manual, including its strong points and deficiencies.
bullet A description of the larger social and technical system or context in which your design will intersect.
bullet An initial list of usability critieria, or principles, that should be used in the eventual evaluation of your design, including a high-level description of how you could measure the successful adherence to these principles.
bullet A brief description and justification of how the above information was gathered.
bullet Most important: A discussion of the implications of what you learned above.

The last item in the list above is critical. Don't just describe the target users, tasks, environment, etc. You must also tell us how these attributes should/will influence your design. Are there any implications to be made from the user profiles and other data you learned? We will be very careful to look for this information in your report.

Part 2 - Design Alternatives

The key goal of Part 2 of the project is to use the knowledge gained in Part 1, as well as that from class, to develop a set of design alternatives for your problem. This is the stage of "informed brainstorming". These multiple design alternatives should explore the potential design space for the problem.

In this part of the project you will develop mock-ups, storyboards, and sketches of at least three of your interface designs. That is, you should provide pencil-and-paper or electronic images of the interface at various stages; you do not need to build a working prototype. Your design sketches should be sufficiently detailed for a potential user to provide useful feedback about the design, however. Along with your design mock-ups, you should provide a brief narrative walk-through of how the system will work. Perhaps most importantly, you should also include your justifications for why design decisions were made, and what you consider to be the relative strengths and weaknesses of your different designs.

The design process you follow here is important. Don't do the following: The group splits up and everyone creates one design, then these are all your alternatives to be turned in. This is not how a good, creative design process should work. It should be more like a brainstorming session with all team members present. You should seek to create some fundamentally different design ideas, concepts all over the potential design space for the problem you have chosen. The key is to push the boundaries of the space of design possibilities.

Your project report should include all the explanatory material mentioned above as well as all the design sketches, drafts, storyboards, etc., that you generated. If some of your sketches are on paper, either scan or photograph the material and convert it to an appropriate electronic format. Make sure that your report adequately reflects the design process that your group undertook. The key in this part of the project is to come up with many different design ideas, not just a small set of wiggles from some basic design. You should plan on turning in at least three different designs.

We will utilize one full class day as a poster session near the end of this part of the project. Each group will post their design ideas on a poster in class. Everyone will then circulate and interact with the designers. The idea here is that each group can use this opportunity to get feedback about their design ideas as they narrow their design space and head into Part 3 of the project.

Part 3 - System Prototype and Evaluation Plan

In part 3 of the project, your group will implement a detailed prototype of your interface. You can use any prototyping tools that you would like to assist this process (e.g., VB, Hypercard, Director, clay, paper, 3D printer, plastic, etc.). You should be able to get much of the interface functionality working, but clearly you will not be able to implement all back-end application functionality.

Additionally, you must provide a set of initial usability specifications for your system and a plan for an evaluation of it. To develop usability specifications, consider the objectives of your design. For example, if you are working on a calendar manager, you might specify time limits in which you expect a user to be able to schedule or modify an appointment, or a maximum number of errors that you expect to occur. Basically, you should list a set of criteria by which your interface can be evaluated.

Further, this part of the project should include an initial evaluation plan for the system. What kinds of benchmark tasks would you have users perform to help evaluate the interface? What kind of subjective questionnaire would you deploy to have a user critique the interface? You will need to actually carry out some of this evaluation in Part 4, so you should do your best to set it up now. The key here is not to do some exhaustive description of a usability evaluation plan, but to motivate why the particular plan you propose is appropriate for this interface.

Note that developing an initial evaluation plan is also a good way to figure out how much of the interface you need to develop. You should be able to build and connect enough of the application functionality to be able to conduct an initial usability evaluation with the benchmark tasks as you are proposing here.

Your write-up for this part should include a description of your system prototype. You can include screen dumps to help explain it and text to describe how a user would interact with it. Discuss the implementation challenges you faced. Were there aspects that you wanted to build but were unable to do so? The key component to include in your project report is a justification of why you settled on the design that you chose. What's special about this particular design with respect your problem?

The report for this part also must include the usability specifications that you established and a description of the evaluation that you are planning. This need not be too detailed here as the actual evaluation will occur in Part 4. We will try to give you helpful feedback about your plan here to assist with the testing in Part 4.

After this part is complete, each group will demo their system for the professor outside of class time. 

Part 4 - Evaluation

In the final part of the project, your group will conduct an evaluation of the prototype developed in part 3. You should utilize the evaluation measures that you identified in that part as well. We expect that your evaluation will involve sample users interacting with your system. These users will likely be your client(s) and maybe other students from class or other people who would fit your target user population. Give the users a few simple benchmark tasks and have them interact with your interface. Closely study what occurs. Deploy a questionnaire to get their subjective feedback about the interface and interaction.

Your write-up for this part should include the following components:

bullet A description of the evaluation techniques, tasks and users involved in your study
bullet Design rationale for the evaluation tasks and materials you employed
bullet Description of the results of the study (data presentation)
bullet A discussion of the results
bullet The implications that you make from the results with respect to your design
bullet A description of how the prototype design could be improved in light of the implications

The key to this part of the project is not to simply describe your evaluation methodology but to rise above that and describe what you learned from it. Explain why you chose the benchmark tasks that you did. Why did you ask users what you asked? What conclusions can you draw from the studies? What aspects of your design "worked" and what failed to meet your specifications? If you had more time to work on the design, what would you now change and improve? Remember, no designer ever gets a system "just right." We will reward teams who honestly and carefully assess their design and who clearly provide a plan for its improvement.

Project Presentation

Last week of classes
The design project will culminate in a session in which each group presents their system to the class and to their clients. Each group will be expected to give a professional 10 minute summary and walk-through of their design and prototype with 3 minutes for questions. It is important that you do a good job communicating all your efforts for the semester. You want to make sure that your objectives in the project are discussed, your system is clearly presented, and that your design process is communicated. Also describe what you learned from your usability study. Practice your presentation!  To be fair to all teams, presentations will be timed and kept to a strict schedule.  Ten minutes is not long -- plan accordingly.