Human-computer interaction is: “concerned with the design, evaluation, and implementation of interactive computing systems for human use and with the study of major phenomena surrounding them” (ACM SIGCHI).

Other definitions:

• Optimizing user's interaction with system, environment, or product.
  • How do we bring tech. in line with user expectations?

Interaction design definition: Designing interactive products to support people in their everyday and working lives.

Usability engineering definition: Nielson doesn't really give one. It's a solid process by which you can create usable software.

• Novel interfaces/techniques.
• Design & design practices.
• Communication.
  • How medium affects the message.
• Accessibility & universal computing.
• Work efficiency.

• Computers affect most people:
  • 89% of US has access to computers. 65% are online.
  • Have to deal with businesses and gov't agencies.
• Computers are everywhere.
• Success often depends on ease of use more than power or features.

• Nielsen
  • Increase learnability.
  • Increase efficiency.
  • Increase memorability.
  • Decrease errors.
  • Increase satisfaction.
• Preece
  • Utility?
  • Effectiveness?

Preece introduces user experience goals:

• Satisfying.
• Enjoyable.
• Fun.
• Entertaining.
• Helpful.
• Motivating.
• Aesthetically pleasing.
• Supportive of creativity.
• Rewarding.
• Emotionally fulfilling.

Are these always good/desirable?

• Depends upon the application.
• E.g. emotional fulfillment in Excel.

There are places where usability may not be good:

• Security systems.
• Medicine (e.g. medicine bottles).
• Complex system operators (make it too easy → operator stupidity).

Examples of poor usability:

• Home electronics with the only controls being the remote. (Lose the remote and get hosed.)
• Scientific calculators/too much functionality in too little space.
• QWERTY for English.

• Computer performed one task at a time.
• No interaction once computation started.
• Switches, wires, punch cards, and tapes for I/O.

• Computers hit “big business.”
• More varied tasks.
• Text processing, email, etc.
• Teletype terminals.

• (Windows, Icons, Mouse, Pointer)
• Computers in the home, everyday tasks, no training.
• From multi-user to multitasking systems.
• WIMP interface allows you to do several things simultaneously.
• Has become the familiar GUI interface.

• SketchPad – 1963 – first interactive drawing program on computer.
• Hierarchy.
• Master picture with instances.
• Constraints.
• Icons.
• Copying.
• Light pen input device.
• Recursive operations.

• Invented mouse/pointer.

You are interacting with the image on the screen.

• '82 Shneiderman describes appeal of rapidly-developing graphically-based interaction.
  • Object visibility.
  • Incremental action and rapid feedback.
  • Reversibility encourages exploration.

Metaphor paradigm involves mapping the real world onto computer use.

• All use is problem-solving or learning to some extent.
• Relating computing to real-world activity is an effective learning mechanism.
  • File management on office desktop.
  • E.g. financial analysis as spreadsheets.

• Going to learn how to watch people, environment, etc.
• Learn how to take notes.

• Find a usability problem.
• Research problem.
• Create a proposal.

• What is usability in terms of design/requirements?
  • It's essentially the same thing, come at from different angles.
  • HCI from user standpoint, software engineering from developer's standpoint.
• When and where in design/build process do you use usability?
  • Everywhere.

1. Identify users
2. Identify activities/contexts.
3. Identify needs.
4. Derive requirements.
5. Derive design alternatives.
6. Build prototypes.
7. Evaluate prototypes.
8. Iterate.
9. Ship, validate, maintain.

• Need to take into account:
  • Who users are
  • What activities are being done
  • Where interaction takes place
    • Conditions may exclude or require certain interface choices, e.g. use of sound.
• Need to optimize interactions users have with a product.
  • Such that they match user activities and needs.

Who are the users?

• Those who interact directly w/ product.
• Managers of direct users.
• Receivers of the product's output.
• Purchasers of the product.
• Users of competitor's products.

• Identify user groups.
  • Make sure all are represented in your study.
  • Make sure more than one person from each group is represented in your study.
• How much to study?
  • Time.
  • Subjects.
• Random vs. non-random sampling.

Each method of learning about users will be more appropriate depending upon the context.

• Questionnaires.
  • Difficult to create in unbiased way.
  • Reach lots of people quickly.
• Interviews.
  • Time-consuming.
  • Noisy analysis.
  • Can reveal information you didn't think of.
• Focus groups.
  • Various levels of structure.
  • One person can dominate.
• Naturalistic Observation
  • Ethnomethodological.
  • Contextual inquiry.
  • Participatory design.
• Documentation.

• Users often don't know what's possible.
• Users can't tell you what they need to achieve goals.
• Instead, look at existing tasks:
  • Context
  • Information required
  • Collaboration
  • Why it's done that way
• Envisioned tasks:
  • Can be rooted in existing behavior.
  • Can be described as future scenarios.
• Based upon observation, design a system that meets user's needs in a great way.

• “Writing the culture.”
• Ethnographer takes part in the world for extended periods of time, passive observer.
  • “World” ⇒ company, society, family, etc.
• Observe everything taking place: Activities, environments, interactions, practices, etc.
• Hidden assumption: We don't always know what we know or do, make the implicit explicit.
  • Not limited to any particular scope.
  • Gather info on all observations.
• Noisy, but very rich and detailed data.

• Two types: Participant observation and Contextual inquiry.
• Participatory Observation
  • “Going native”
  • Ethnographer part of culture.
  • May be difficult to relate back.
  • May influence outcome.
  • Tries not to make judgements about why events happen.
• Contextual inquiry
  • Ethnographer less embedded in the culture.
  • Apprentice relationship to actor.
  • Some observation followed by questions to the actor to clarify meaning.
  • Tends to get more focused data.
  • Prone to rationalizations and tall tales.
    • When have to explain/vocalize, actor may come up with a story.

• Problems with ethnography.
  • Data is very disorganized.
    • Difficult to know what to do with it.
    • Needs further refinement before it can be applied.
      • Use cases
      • Scenarios
      • Task analysis
      • Workflow models
  • Ethnogaphy often good starting point, but rarely self-sufficient.

• Subject knowledge/consent.
  • Public vs. private places.
  • If the observee has expectation of privacy, you must have consent.
• Medium
  • Notebook
  • Audio tape
  • Video/photographs
    • Puts people less at ease. (⇒ modifies behavior to some extent)
• Transcription
  • Within 24 hours.
  • Cleaned up version of notes.

• Discuss ethical concerns.
• Role of IRB.
• Principles and origins of Belmont report.
• Principle of informed consent & considerations surrounding.
• Responsibilities to participants before, during, after study.

• Nuremberg doctor trials.
• Milgram obedience experiments.
• Thalidomide study.
• Untreated syphilis study.
• Human radiation experiments.

• Nazi physicians charged conducting inhuman experiments on civilians and prisoners.
• High altitude experiments:
  • 40% participants died.
• Parachuting into cold water.
  • 30% died.
• Wound, burns, amputation, chemical and biological agent exposure.
  • Mortality of 25%, many disabled or scarred for life.
• Code of ethics developed in aftermath.
  1. Informed consent.
  2. Anticipated results should justify experiment.
  3. Human experiments should be based upon animal results.
  4. Physical and mental suffering and injury should be avoided.
  5. There should be no expectation of death or disabling injury.
  6. Degree of risk should be weighed by potential benefit.
  7. Proper preparation & precautions should be taken.
  8. Only qualified scientists should conduct medical research.
  9. Subject has right to end experiment at any time.
  10. Scientist must be prepared to end experiment if subject at risk.
• Code did not have much effect.

• Designed to answer question “Could it be that Eichmann and hist milion accomplices in the Holocaust were just following orders?”
• Subject was “teacher,” learner was an actor paid by researcher, following a script.
• Subject asked to administer electrical shocks when learner was wrong.
• Psychologists said 1 in 1,000 would administer maximum shock (thus obeying supervisor).
• In reality, 63.75% administered the maximum shock.
• “I observed a mature and initially poised businessman enter the lab smiling and confident. Within 20 minutes he was reduced to a twitching, stuttering wreck, who was rapidly approaching a point of nervous collapse.” S. Milgram in Obedience to Authority.

• Respect for persons.
• Beneficence.
• Justice.

• IRB has authority to approve, require modification, or disapprove all research activities.
• Purpose: Review research and determine if the rights and welfare of human participants involved in research are adequately protected.
• Safeguard mechanism.

• Informed consent is a process of information exchange that takes place between the prospective investigator, before, during, and after study.
• Comprehension: Investigators responsible for ascertaining that the participant has comprehended the information.
• Voluntariness: Agreement to participate in the research constitutes a valid consent only if voluntarily given.
  • Must not be coerced through any means, including incentive.

• Investigators bear ultimate ethical responsibility for their work with human participants.
• Other responsibilities include:
  • Compliance with laws.
  • Assuming fiscal management.
  • Supervising/training of students, post docs, and residents.
  • Complying with terms and conditions of sponsor's award.
  • Submission of all technical, progress, invention, and financial reports on timely basis.

• Groups of 4-5
• Four phases:
  • Proposal (2/7)
  • Prototype 1 (2/21)
  • Evaluation plan (2/28)
  • Final system & evaluation (3/16)

Identify a real usability need, for a real population.

• Describe the problem (current breakdown and the ideal situation).
• Document the problem (how you know there is a problem to begin with).
• Who are your users.
• Ideas about a solution.

• Build a presentation for a design gallery.

Based upon feedback from prototype and problem you identified:

• Write a convincing and realistic evaluation plan to see if you have reached all/some of your objectives.
• Perform said evaluations on your fellow students.

• Just like prototype presentation, but you add in your final design, how it evolved, etc.

• Subject is usually an expert in UI, etc.
• Think-Aloud protocol is part of cognitive walkthrough:
  • User describes verbally what he's thinking while performing tasks.
    • What they believe is happening.
    • Why they take an action.
    • What they are trying to do.
  • Researcher takes notes about task and actions.
  • Makes less assumptions about why things are happening.
• Very widely used.
• Yields good results with few people.
• Potential problems:
  • Can be awkward for participant.
  • Can modify way user performs tasks.

• What if thinking aloud will be too disruptive?
• Can use post-event protocol.
  • User performs session, then watches video and describes what she was thinking.
  • Sometimes difficult to recall.
  • Opens up door of interpretation/rationalization.

• Subject asked to keep journal of daily activities.
  • Record actions, reasons, and other observations.
• Not always subjective.
• Prevents researcher from having to be everywhere 24/7.

• 3 types:
  • Structured:
    • Well-defined agenda.
    • Efficient.
    • Require training.
  • Unstructured:
    • No agenda.
    • Let subject go in whatever direction they need to go.
    • Difficult to not influence direction.
    • Inefficient.
    • Less training.
  • Semi-structured:
    • Good balance of training/efficiency.
    • Often appropriate.

• Predetermine data of interest - know why you are asking questions, don't waste time.
• Guidelines:
  • Stay concrete (specific).
    • “So when the new guy joined the team and hadn't gotten his email account set up yet, what happened then?” vs. “What generally happens here when someone new joins the team?”
  • Signs to look for:
    • Interviewee waves hand and looks up at ceiling ⇒ generalization coming.
    • Use of passive voice, “generally”, “usually”, “should”, “might”

• General Criteria
  • Make questions clear and specific.
  • Ask some closed questions with a range of answers.
    • Sometimes also have a no opinion option, or other answer option.
  • Do test run with two or three people.
• Likert Scale
  • Usually odd # of points: 5, 7 point scale; agree to disagree.
  • Could also use words for each level.
  • Sometimes need to use black & white answer questions to get a normalization range.
• Other Typical Questions
  • Rank importance of each of these items…
  • List the four most important tasks that you perform (open question).
  • List the pieces of information you need to have before making a decision about X, in order of importance.
  • Are there any other points you would like to make?

• Scandanavian history.
  • Scandanavia has fairly strong labor unions.
  • Workers involved in all decisions.
• Emphasis on social and organizational aspects.
• Based on study, model-building, and analysis of new and potential future systems.
• User is a part of the team.
  • Immediate feedback.
  • Sanity checking.
  • Much tighter feedback cycle.

• Gather data:
  • Surveys/questionnaires.
  • Interviews.
  • Etc.

• List what task is about.
• Add progressive layers of detail as you go.
• Know in advance how much detail is enough.
• Can add linked outlines for specific subtasks.
• Good for sequential tasks.
• Does not support parallel tasks well.
• Does not support branching well.

• Describe tasks in sentences.
• More effective for communicating general idea of task.
• Scenarios: “informal narrative description”
  • Focus on tasks/activities, not system (technology) use.
• Use Cases
  • Focus on user-system interaction, not tasks.
  • How to do a task using the system, not what tasks to do.

• Graphical notation & decomposition of tasks.
• Goals – what the user wants to achieve.
• Tasks – do these to achieve the goals.
• Looping, conditionals integrated.
• See slides for example hierarchy.
• Types of Plans:
  • Fixed sequence
  • Optional tasks
  • Waiting events
  • Cycles
  • Time-sharing
  • Discretionary

• Objects/people with links to related objects.
  • Stress relationship between objects and actions.
• Close to the type of thing you would say to a DB designer or programmer.
• More difficult for user to understand.
• No way to represent knowledge, ideas, motivation, etc.
• Lends itself better in specifying to a developer what he needs to create.

• Many types.
  • Decisions
  • Actions
  • Information flow
• Combines ERD with sequential flow, branching, parallel tasks.
• Tracks something being moved around.
• Visually appealing, easy to understand.
• More abstract than HTA.
• Much quicker overview of system.

• What is usability engineering/HCI/user-centered design?
  • Define
  • Describe process/target problems
  • Arguments for UE/HCI/UCD/UE/HCI/UCD in historical context
• Basics of human subjects research
  • Some history/background
  • Importance of Milgram experiments
  • Basics of Belmont report
• Studying Users
  • Describe methods discussed in class
  • Argue pros & cons of each, different variations
  • Propose an approach to studying a given hypothetical place/situation, and argue why
  • How to organize and analyze data

A prototype is a simplification of a system.

In interaction design, it could be:

• Screet sketches
• Storyboard
• Slide show
• Video simulation
• Lump of wood (Physical mock up)
• Software with limited functionality

Put many ideas out there. By making prototypes, you can evaluate many options effectively.

Facilitates evaluation:

• Stakeholders can see, hold, interact with.
• Team members can communicate more effectively.
• Test ideas yourself.
• Encourages reflection.
• Answer questions, support designers in choosing among alternatives.

• Work flow, task design
• Screen layouts and information display
• Difficult, controversial, critical areas

All prototypes involve compromises. For software prototyping there may be a slow response, stetchy icons, limited functionality, etc.

• Rough prototype of system.
• Uses medium unlike the final medium.
• Quick, cheap, easily changed.
• Encourages high level criticism; problems with conceptual models and fundamental usability or functionality issues.
• Users unafraid to suggest major changes.