COMP 3220 Human-Computer Interaction Semester 2 2015 - Syllabus

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 12

COMP 3220 Human-Computer Interaction

Semester 2 2015 - Syllabus


Lectures
Tuesday 2-4pm, Wednesday 2-4pm CSL1
Instructor
Dr. habil. Alexander Nikov, Room FFA UL, [email protected]
Office hours
Tuesdays, Wednesdays 10-12
Pre-requisites

COMP 1200 (Students who have COMP 1401 or INFO 1500 or equivalent should request a pre-requisite
override from department)

Course Rationale
Human-computer interaction (HCI) has become an area of great interest and concern. HCI is concerned
with the joint performance of tasks by humans and machines. It stresses the importance of good
interfaces and the relationship of interface design to effective human interaction with computers.
Specifically, we concentrate on so-called interactive systems. This course uses an integrative and cross-
disciplinary approach to bring together a broad variety of topics together in relation to the problem of
developing quality user interaction designs to provide an introduction to the field of HCI. This course is
different from a majority of CS courses like software engineering that take a systems perspective. It
focuses more on application (and less on theory) of user-centered design principles, guidelines, and
evaluation. This course provides the concepts of HCI and user interfaces, focusing on user interface
design, evaluation, and technologies. It is a fun course with interesting user interface design projects and
concepts. Unlike a majority of other CS courses, this is NOT programming intensive.
Course Description
Human-computer interaction is an interdisciplinary field that integrates theories and methodologies from
computer science, cognitive psychology, design, and many other areas. The course is intended to introduce
the student to the basic concepts of human-computer interaction. It will cover the basic theory and methods
that exist in the field. The course will unfold by examining design and evaluation. Case studies are used
throughout the readings to exemplify the methods presented and to lend a context to the issues
discussed. The students will gain principles and skills for designing and evaluating interactive systems.
Among the topics studied are the design and evaluation of effective user interaction designs, including
principles and guidelines for designing interactive systems. Additionally, much emphasis is given to the
development process for user interaction designs as an integral, but different, part of interactive software
development. User interaction development activities include requirements and task analysis, usability
specifications, design, prototyping, and evaluation. It is a goal of this course to help students realize that
user interface development is an ongoing process throughout the full product life cycle, and developing the
human-computer interface is not something to be done at the last minute, when the "rest of the system" is
finished.
During the course the students will be involved with a real problem solving/software development project.
Students will be required to gather functional requirements, identify the problem, form a solution and
present this solution.
Learning Outcomes
On completion of this course according to course goals, the student should be able to:
 understand the basics of human and computational abilities and limitations.
 understand basic theories, tools and techniques in HCI.
 understand the fundamental aspects of designing and evaluating interfaces.
 practice a variety of simple methods for evaluating the quality of a user interface.
 apply appropriate HCI techniques to design systems that are usable by people.
Specific Objectives (relative to content topics)
The major objectives of the course are:
Definition: students will be able to recognize and recall terminology, facts and principles For example,
students can define 'direct manipulation' and list some of its strengths and weaknesses as an interaction
style.
Concept Understanding: students will be able to determine the relationships between specific instances
and broader generalizations. For example, students can determine which parts of a system exhibit direct
manipulation features and can explain why a change in the system produced different properties.
Directed Application: students will be able to use concepts and principles to explain, analyze and solve
specific situations, often with the applicable concepts implicit in the setting. For example, students can
redesign part of an interface to exhibit direct manipulation style and predict the likely effects of the
change.
Realistic Problem Solving: students will be able to apply course content in coping with real life situations.
These differ from directed applications by having less structured questions and issues, no direction as to
which concepts will be applicable and a range of potentially acceptable answers. For example, students
can design an interface for real tasks and users which incorporates direct manipulation in appropriate
ways (and evaluate/defend their choices).
Required Reading
Lecture notes
PowerPoint handouts of the lecture notes will be made available to you via the course web page
Textbook
Dix A. et al., Human-Computer Interaction. Harlow, England: Prentice Hall, 2004, ISBN-10: 0130461091

Other resources
Yvonne Rogers, Helen Sharp, Jenny Preece, Interaction Design: Beyond Human Computer Interaction, 3rd E

Teams
Students will team up in groups of 2-4 for their assignments. The assignments are a considerable amount
of work and require a team to help manipulate the equipment or perform a portion of the human subject
interactions. Teams are also the standard fashion in which user interface design is carried out, i.e.,
through feedback from another colleague.
1. Students will need to find their own team members. A portion of the time in tutorials can be used to talk
with other students and build a team.
2. Students can break with a team (i.e., divorce) but they and their team members must all come to the
instructor together and give good reasons for why they are breaking up the team. Otherwise a team
will be considered in place for the entire term.
3. Students can join new teams (i.e., remarry), but they must join a team that is compatible (i.e., a team
that is working on the same interface design). There is no need to tell your tutor about the new
team membership. This will become obvious by the new names on the assignment.
4.  Teams can consist of no more than four students. A team can choose to continue with only two
members but no single membered teams will be permitted. The assignment is simply too much
work.
5.  Note: You will often have to work with other people throughout your life who you feel are not carrying
their share of the load or doing the work at the level you desire. Now is a good time to get practice
in dealing with these people, negotiating compromises and making the best of the situation.
Course Outline (subject of change)
Week Lecture Topic Reading Tutorial Topic
Assignment Project Status
Week Introduction to Human-Computer Interaction. Chapters 1 & 2  
1 Semester project and student teams pages 1-47, 54-
102
Week Task-centred system design: task-centered Chapter 7 Task-centred
2 process, development of task examples, pages 260-291 designHand out
evaluation of designs through a task-centered Assignments
walk-through
Week User-centred design and prototyping: Chapter 5 Assist with
3 assumptions, participatory design, methods for pages 179-221 Assignment 1
involving the user, prototyping, low fidelity
prototypes, medium fidelity
Week  prototypes, wizard of Oz examples   Assist with
4 Assignment 1
Week Methods for evaluation of interfaces with users: Chapter 11  Assist with
5 goals of evaluation, approaches, ethics, pages 406-441 Assignment 1
introspection, extracting the conceptual model,
direct observation, constructive interaction,
interviews and questionnaires, continuous
evaluation via user feedback and field studies,
choosing an evaluation method
Week Psychology of everyday things: psychopathology Chapter 1 Assignment 1 due
6 of pages 48-51
Week  everyday things, examples, concepts for   Return and discuss
7 designing everyday things Assignment 1
Assist with
Assignment 2
Week Beyond screen design: characteristics of good Chapter 6 Applying psychology
8 representations, information visualization, Tufte’s pages  223-259 of everyday things
guidelines, visual variables, metaphors, direct Assist with
manipulation Assignment 2
Week Graphical screen design: graphical design Chapter 3 Assignment 2 due
9 concepts, components of visible language, pages 103-139 Assist with
graphical design by grids Assignment 3
Week Design principles and usability heuristics: design Chapter 4 Return and discuss
10 principles, principles to support usability, golden pages 141-177 Assignment 2Assist
rules and heuristics, HCI patterns with Assignment 3
Week  HCI design standards: process-oriented   Assignment 3 due
11 standards, product-oriented standards, strengths
and limitations of HCI Standards
Week Past and future of HCI: the past, present and Chapter 16 Return and discuss
12 future, perceptual interfaces, context-awareness pages 593-610 Assignment 3
and perception
Teaching methodology
 A project-intensive methodology for teaching HCI is applied. To stress that the class work involved in this
course directly complements the project work, the approach of project-intensive teaching is to go step by
step through the process of preparing for the course, teaching the individual classes, and coordinating
with the project pretty much as outlined in the syllabus. We will describe the activities needed at each
step, along with support materials, assignments, and we provide annotations and discussions of specific
points.
Students will team up in groups of 2-4 for their project. Students will need to find their own team
members. The project is a considerable amount of work and requires a team to help manipulate the
equipment or perform a portion of the human subject interactions. Teams are also the standard fashion in
which user interface design is carried out, i.e., through feedback from another colleague.
In fact, we will NOT be concerned with implementing a piece of software in this class. We will be
concerned with creating and testing DESIGNS of human-computer systems through low and medium
fidelity mockups.
Assessment
Method of Evaluation Percentage of Grade Due Date
Assignment 1    
Tasks and requirements 20 week 6
Assignment 2     
Low-fidelity prototype and walkthrough 20 week 9
Assignment 3     
Computer prototype 20 week 11
Final Exam   Students must get a
One 2-hours written paper  40 passing grade on final to
Covers entire course - all lectures, readings and pass the course
tutorials

Overview | Projects 2015
 
Assignments Report Form Percentage of Due
Grade Date
Assignment 1      
Tasks and requirements   20 Feb 23
Description, Short description  
Assignment 2  Word template    
Low-fidelity prototype and walkthrough 20 Mar 16
Structure, Interaction, Presentation, Internet
Assignment 3     
Hi-fidelity prototype 20 Apr 11
Usability testing
Late assignments: one day  -10%
Submit assignments in Myelearning
FINAL PRESENTATION: Prepare 20-25 PowerPoint slides (15 min presentation) sumarrizing
assignments 1 and 2 (total 10-12 slides) and details on assignment 3 showing short the computer
prototype, results of usability testing, HCI/usability problems allocated and how they can be solved.
FINAL PROJECT: Submitting Assignment 3 (deadline Apr 11) students should submit together in
one Word document all assignments (A1-A3) in Myelearning (example name 5-hci-short-project-title.doc).
Lo-fi prototype files (zipped) and hi-fi prototype files (zipped) or WWW links should be submitted with
names starting with project number. Powerpoint files should be also uploaded in Myelearning.

THE UNIVERSITY OF THE WEST INDIES


FACULTY OF SCIENCE AND TECHNOLOGY
DEPARTMENT OF COMPUTING AND
INFORMATION TECHNOLOGY
COMP 3220 Human-Computer Interaction
Project Report
Project Title:

Student(s) Name(s):

Student(s) ID No.:

Date :…./…./2016
Advisors: Dr. Alexander Nikov

Mr. Steffan Bodhoo

1
1. Assignment 1: Tasks and Requirements
1.1 Identify Current State and Scope
Example Interface Design Constraints for Check-Ease

PC, laptop, tablet (and clones).

Modems with baud rates as low as 14400.

VGA monitors. Minimum resolution is 1024 x 768.

Color and monochrome displays.

Microsoft Windows XP compliance or better..

1.2 Develop User Profiles


User Profile Form
Application:

Potential Users:

Hardware Experience:

Software and Interface Experience:

Experience with Similar Applications:

Task Experience:

Frequency of Use:

Key Interface Design Requirements that Profile Suggests:

A persona is the profile of a fictional user that represents the intended audience(s) for this product. A persona should
share characteristics with real people, but should not directly describe any real person. Taken together, the personas
you define should represents wide a variety of characteristics as possible. For this concept tube effective, your team
will use these personas throughout the design and evaluation process to provide a point of reference.
Your team will define a minimum of two personas. This section summarizes your team's personas and their
characteristics. For example, a product for sixth graders could present personas for:
o User A, an 11-year-old power-user
o Teacher, who is relatively competent in the use of computers.
Create the detailed description for each of the personas. Uniquely identify each persona, either
with a descriptive label or with a name. If you wish, invent a picture of each persona. For each
persona, describe their relevant personal characteristics and their general goals with respect to
this product. Be sure that the characteristics that distinguish personas from one another are
clear.

1.3 Gather Tasks Data


Once you have identified who your users are, you need to gather data from them. The data you
are gathering includes verifying your user profiles, as well as getting details on their current and
future task flows. To provide the critical data needed for interface design, task descriptions must
be built by talking to and observing users who do the work the system is targeted to support, not
from talking to managers, marketing representatives, trainers, and so on.

1.4 Document the Current Tasks


Create a list of names of tasks as follows:

Absolutely must include:

Should include:

Could include:

Exclude:

Select 3-6 most important tasks from them.

1.4.1 Describe each task


For each user task, document the following information:

 The actual task performed

 Tasks that precede, follow, or interrupt the task (task flow)

 Which users perform task

 Task products and where they go

 Common task performance problems, errors

 Users' complaints about how the task is performed today and their ideas about how task
performance could be improved
 Characteristics of the work environment where the task is performed (for example, small,
cluttered, dirty workspace that would make mouse use difficult)

 Add 1-3 screenshots for each task

1.4.2 Document the Current Tasks


Task Detail Table
Task Task Frequency Display Input Comments
# Requirements Requirements

1.5 Document Problems and Opportunities


Example
Problems and Opportunities List for Current Task of Paying Bills

Can't find calculator, must add/subtract in head or with paper and pencil.

Current balance might not be up to date, have to stop and calculate.

Error prone relies on correct calculations.

Tedious to calculate and recalculate the running balance.

Handwriting is bad, people may read wrong amounts on checks.

Redundancy - write check and then repeat all the information in check register.

Would be nice to have tracking of what has been spent for different categories (such as food, medical, and so on).

More work to get an updated balance.

1.6 Describe Future Tasks


Select 1-5 future tasks if any

Similar to documenting current tasks (1.4)

1.7 List of requirements


From the task examples, extract the major system requirements and prioritize them into: a)
absolutely must include; b) should include; c) could include; and d) exclude.

1.8 Develop use case scenarios and system scenarios


Example

Use Case Scenario: Paying Bills with Printed System Scenario: Paying Bills with Printed
Checks Checks
1. Enter bills (payee name and amount due) on a 1. System shows data for each bill: payee, due date,
worksheet. and amount due; system shows current balance in
checking account.
2. View the new balance (current balance less each
payment amount). 2. System recalculates the balance as each bill is
entered, if the bill is to be paid.

3. Show changed amount if user changes amount to


3. Decide if there are enough funds to pay the bills. pay. Mark as unselected if user chooses not to pay a
bill.
a. If yes (80% of the time), go to step 4.

b. If no (20% of the time), mark the bills not to be


paid (80%) or change payment amounts (20%), then
go to step 4.

4. Tell system to pay the bills.


4. System enters bill as an entry in the checking
account register and recalculates the current
balance.

5. Displays options for printing checks.


5. Set printing options for checks.
6. None.
6. Put check stock in printer.
7. System prints checks.
7. Print checks.
8. None.
8. Look at checks.
9. Alert user about printing status. Allow user to
9. Reprint checks if there is a problem (problem with enter which checks to reprint if necessary.
checks 30% of the time).
10. Show updated checking account register.
10. View updated checking account register (viewed
11. See separate scenario for running reports.
50% of the time).

11. Run reports (50% of the time). Note: see


separate scenario for detail on running reports.

2 Assignment 2: Low-fidelity prototype


The objective of this part of the project is for you to design and implement a low-fidelity mockup of your proposed
system, based on team discussions that led to the completion of the proposal and your tutor feedback.
1) Build a low-fidelity prototype of your new design using prototyping tool, as you deem appropriate for
investigating and validating high-level decision options that your team is considering. Remember that your
prototype should not be overly detailed, in particular as you want to focus on the "big picture" at this stage. Your
deliverables are a set of 4-10 screens that explain the operation of your low-fidelity prototype. This should be
sufficient to illustrate the "working flow" of your system and explain how each task will be carried out.
2) UI evaluation by a cognitive walkthrough, which involves going through the operation of an interface, asking, at
each point:
 what actions the user needs to make
 how the interface supports these actions
 what assumptions are made about the user's knowledge and background related to the
system
Here the user's problem-solving process is simulated at each step in the dialogue to see
whether the desired/expected outcome occurs. In this case, you must describe in detail several
main tasks defined in assignment 1 that a user might want to perform with your system so that
the evaluation can "walk through" the appropriate operations.

2.1 Low-fidelity prototype


Develop web and mobile low-fidelity prototype(s) of designs (4-10 screens) that you believe will
satisfy the major requirements.

1. Choose major user objects


 Identify objects from analysis documents in Assignment1
 Identify object attributes
 Identify user actions on task objects
2. Select metaphors and representations
3. Create a high level interface design (lo-fi prototype)
 Select/adapt a style
 Define navigation structure (tree)
 Identify main windows and related user actions
 Identify home bases and launching pads
 Identify how user access main windows
 Assign user actions for main windows
 Evaluate and revise the high level design (lo-fi prototype)
2.2 Task Centered Walkthrough and Discussion
Discuss the prototypes with your team and (ideally) potential users. You should be concerned
here with how the general interface representation fits the users' view of their tasks. For the
prototype designs that seem promising, use the tasks from Assignment 1 to perform a task-
centred walkthrough of your prototype. Shortly list the usability problems allocated by the
walkthrough using the scenarios.

Description of Step Does the user have the Is it believable that they Comments
knowledge/training to would do it? That is, are (including
do this step? they motivated? possible solutions)

Results of Walkthrough and Discussions

3 Assignment 3: High-fidelity prototype


In assignment 3 you have to give users a clearer sense of the look and feel of your application. This means that your
lo-fi prototypes will evolve to a second hi-fi version able to perform some type of information processing. In
addition to implementing your hi-fi prototype, you have to prepare and conduct usability testing in Usability Lab.
For this assignment, your team must implement a hi-fi prototype that allows users to evaluate the "look and feel" of
your system. Keep in mind that your prototype does not need to be functionally complete. It should be sufficient to
give a reasonable (albeit imprecise) impression of the intended interaction to candidate users.
During usability test quantitative measurement (e.g., number of mistakes users make before invoking a specific
function, as instructed) can be made.
3.1 High-fidelity prototype
Develop high-fidelity prototype of lo-fi prototype. Conduct design reviews (walk through the user
tasks and use scenarios). Revise prototype.

3.2 Usability testing of prototype in Usability Lab


Conduct usability test. Describe short the usability problems allocated and solutions.

3.2.1 Prepare before usability testing


 Tasks to be solved during usability testing
 Post-test Heuristic Evaluation Questionnaire (e.g. heuristic evaluation cf. usability evaluation tools
Interactive Heuristic Evaluation Toolkit).
3.2.2 Summary of Usability Testing Results
Problem Solution Comments

3.2.3 Usability Heuristic Testing Results


Scale:

1. Strongly Disagree
2. Disagree
3. Neutral
4. Agree
5. Strongly Agree

# Heuristic User 1 User2

References
Mention books, articles, web sites, worksheets, project documents, or people who are sources of information about
the application domain, etc. Give links to documents as appropriate. Alphabetize by last name of author.

You might also like