Why study HCI (Human Computer Interaction)?
- More than half of the coding is devoted to the HCI
- Bad interfaces contribute to human error possibly resulting in personal. environmental, and financial damages
- User interfaces are important for the success of software
- Software developers must know how to make software that CAN be used by people.
- To the end user the user interface is the system.
- Apple won a lawsuit about several HCI patents (Samsung has used patented iPhone UI ideas without Apple's permission - this decision also affects Google's Android).
What is HCI?
HCI - a discipline concerned with the design, evaluation, and implementation of interactive computer systems for human use and with the study of major phenomena surrounding them.
HCI - is about designing computer systems that support people so that they can carry out their activities productively and safely.
HCI - is the study of people, computer technology and the ways these influence each other. We study HCI to determine how we can make computer technology usable by people.
HCI - understanding the work that people try to perform using the technology
Task analysis and user centered design - study what it is that people are trying to do.
They may not even know.
Which tasks are more important. Task that is most important is one the user may not know they’re doing. Try to make them as usable as possible.
Most users won’t understand what your program is doing, but will say “How beautiful” or “this is terrible”.
Identify who your coding for, figure out what it is they want.
Who is involved in HCI
- Computer scientists - programming languages, prototyping tools, software engineering
- Psychology - human behavior, prediction of user performance, empirical evaluations.
- Don't train people how to use the software - use observation to analyze the ease of use.
- Keystroke level model (KLM) - computerized prediction of performance
- Structure of interaction (syntax)
- Meaning of interaction (semantics)
- Space for interaction (discourse analysis)
Identify the grammar in doing things
Smartphone uses: emails, calls, calendar.
To check calendar you can identify a language, with words like swipe, tap, click, etc.
The program that has concise and simple grammar of interaction will be the best.
Artificial Intelligence (AI)
Natural language processing, speech recognition (SIRI, for example, is based on ELIZA, developed in the 1960s)
Color, font, layout, images, animation
Ubiquitous computing - the act of rendering invisible the interface metaphor so technology can be used unconsciously/effortlessly - focus on the task not on the tool.
Someone who acts on behalf of others
Interface – “Abstraction Barrier”
A shared boundary where independent systems meet and act on, or communicate with each other.
We are system A
System A interacts via the knob on the side.
Language would be:
- Pull knob
- Twist knob
- Push knob
Output (system B)
The face, long hand, short hand, second hand, date.
The watch is System B
System A doesn’t know if it functions digitally or by gears, and we really don’t care, as long as we’re able to get the correct time from it.
System A's interface:
- Steering wheel
- Shift knob
- Gas/Brake/Clutch Pedals
Other interface language examples:
- Turing Machine
- UNIX command language
System A, System B example - hand drawn diagram (rights to attach an image file unknown)
What system A knows is what it “sees” (the interface).
- Since the 1950's computer prices have dropped, # users increased, expertise of users decreased
- User interfaces 1950's cables and plugs/sockets
- 1960's - punch cards & mouse
- 1970's - teletypes & command line
- 1980's - screens, menus, GUI's
- 1990's - GUI's, mutli-modal UI's, speech input, etc.
shut-in syndrome - (Stephen Hawking would be an example - limited to one means of communication (added by notes author as an explanation of the example).
- (remaining) Presentations
- Goals of HCI
- Usability (effectiveness, efficiency, satisfaction)
- Norman's design analysis concepts (!!!)
- Affordances, constraints, conceptual models, mappings, visibility, feedback, (also, consistency - internal/external)
- Examples of usability breakdowns - analysis, and (re)design interventions.
- Nielsen's usability principles
- visibility of system status, match system and user's world, user control and freedom, consistency and standards, system helps users recognize/recover from errors (even better, prevent errors via good, constraining design), flexibility and efficiency, aesthetic and minimalist design, help and documentation.
- User interface life-cycle
- waterfall, spiral, star, Mayhew usability engineering lifecycle.
Referenced and reviewed Usability 101 article available from course readings.
- 5 Quality Components
- Usability vs. Utility
- Definition: Utility, Usability, and Useful
- Why is Usability Important
- How to Improve Usability
Design and Analysis Concepts (Author: Donald Norman)
“You Need an Engineering Degree from MIT to Work This” (Norman, D.A., The Psychopathology of Everyday Things, 1988)
- Should you push or pull a door?
- How to forward a call?
- How to program the VCR?
- Books, radios, kitchen appliances, office machines, and light switches
- Norman uses everyday objects to discuss the design of everyday things.
- Poorly designed objects provide no clues – or sometimes false clues!
- Well-designed artifacts should lead the user towards successful interaction.
- Some interfaces are layered (i.e., a GUI that is accessed via mouse/keyboard, which are fixed)
- Design analysis concepts are used to analyze both good and bad design.
Design Analysis Concepts
(Important definitions are in bold, they will be on the test!)
Affordances are the perceived properties of an artifact that determine how it could possibly be used.
gave examples of affordances associated with a magic marker (i.e., write with it, remove the cap, replace the cap, etc.).
Affordances – “to give a clue”
*Buttons – pushing
*Menus – choosing
*Pens – Writing
*Knobs – Turning
When affordances are taken into account, the user knows what to do just by looking.
Affordances are specific to your target audience.
Constraints are the physical, semantic, cultural, and logical factors that encourage proper actions and prevent erroneous ones.
Dr. Manaris gave an example of constraints showing an example with a pair of scissors with an emphasis on the handle constraint.
Conceptual Models are mental models of a system which allow users to understand the system, to predict the effects of their actions, and to interpret their results.
Two types of conceptual models (structural vs. functional)
Mappings describe the relationship between controls and their effects on a system.
*Ex: move a control to the left should move a corresponding display model to the left.
*Ex: Dr. Manaris gave example of moving mouse for display and also flying a plane.
*Ex: Dr. Manaris gave example of stove control with three burners and three buttons (which button would you pick to turn on a burner…gave examples with 3 and 4 burner configurations).
Visibility in the design of a system makes apparent to users the conceptual model of the system and the actions they are allowed to make.
Feedback from a system provides information about the effects of the user’s actions.
Goals (high-level) vs. Tasks (middle-level) vs. Actions (low-level)
*Design UI to have similar operations and use similar elements for similar tasks.
*Makes the UI easer to learn and use
*Internal (inside the interface) vs. external (among other interfaces) consistency
Nielsen’s Usability Principles
Nielson's Usability Design Principles
Visibility of system status - Designers need to always keep users informed about what is going on.
- This provides feedback - Unix command line copying file vs status bar provided by Windows
Match between system and the real world
- Speak the users language, put problems and solutions in terms of what people are used to seeing
- Translating items into user space
Facilitate user control and freedom
- Provide emergency exit for user mistakes
- Users need to feel they are in control, or frustration results
- Users should always initiate action, not system
Use consistency and standards
- User conventions -- actions mean the same thing
- CTRL + C with Windows on Word vs. Command line -> CTRL + C breaks, CTRL + C copies
- Where possible, design something so that the user can't make errors in the first place
- Eliminate error prone conditions and check for them
Recognition rather than recall
- Being able to see what is happening and using that information, how easy is a task to perform again
- Actions, objects and options are visible
Flexibility and Efficiency of Use
- Tailor frequent uses
- Accelerators - shortcuts for experienced users
Aesthetic and Minimalist Design
Link to the 7 +- 2 Rule
7 Plus Or Minus 2 rule:
- Paper by George Miller in the 1950s
- Summarized limits on our capacity for processing information
- People typically have a limitation of remember 7 plus or minus two items
- Can go down to three nested levels, practically
- More gets difficult
- Organizing into chunks makes it possible to remember more
- Menus can be organized into chunks of 7 with up to 3 sub-menu levels
- Nesting if else statements
- If/then/else statements can be nested to about 3 levels also
- After 3 levels the states become unruly and the programmer's conceptual model begins to breakdown, guideline is 3, maybe 2
Chunking: The act of creating chunks
- Organize information into meaningful chunk, and then remember information about those chunks.
User Interface Life Cycle Models:
One: Waterfall model
- Requirements analysis
- System/Software design
- Implementation and Unit Testing
- Integration and system testing
- Release and Maintenance
- No iterative development - Can't see results during the process of developments
- No concurrency between task, linear workflow
- When do end users enter the development cycle?
- System is designed over a long time
- Little or no interaction with users
- Evaluated as it is going out the door
- Lack of feedback until the end of the process.
Two: Spiral Model (the shampoo model <- This is my own name for it to help remember, it might be considered wrong on tests)
- Involve users throughout the process
- Integrate multidiscipline expertise
- Invest in iterative development
- Evaluate -> Design -> Implement -> Repeat
- Iterative refinement
- Rapid prototyping
- Give the user the steering wheel
- UI design structure might not lend itself to the development of the backend
- Not as structured as other software development
- But from the user's point of view, the user interface IS the system (they're seeing the conceptual model)
Three: Star model
- Derived from empirical studies of UI design
- No true order in the design cycle
- Ordering of activities is irrelevant
- Evaluation by users is central, follows every activity
- Combines analytical and synthetic approaches
- Supports rapid prototyping
- Incremental Development of Final Product
- Development may begin, be followed by any stage. (free form)
- Too generic to make managers happy (too creative)
Four: The Usability Engineering Lifestyle (Mayhew)
- User profile: ID user (posters in workspace as reminders of typical user)
- Task analysis: ID user tasks
- Users sometimes do things and don't realize they do them
- Platform capabilities and constraints: What do they have? How will they use it? Can it support identified tasks?
- General Design Principles: Best practices and guidelines used
- All of these feed into the 'Usability Goals'
- This leads to a "Style Guide"
Interaction Design Terms
- Design concepts/principles
- Provide general design guidance
- e.g. Norman's design analysis concepts (affordances, usability, etc)
- Usability principles
- Provide a general framework for usability assessment
- e.g. Nielsen's principles
- Usability goals
- Objective, measurable criteria for assessing the acceptability of a system
- Design should prevent user from making errors (metric: number of errors allowed)
- User experience goals
- Subjective, measurable criteria for assessing the user experience
- Design should provide a positive user experience (ask users "How do you like the system?")
Guidelines - refer to high-level, low-authority guidance (e.g. design to prevent errors)
Standards - refer to low-level, high-authority rules (e.g. dialog boxes should have OK and Cancel buttons)
Style Guides compile usability goals as standards (specific to the target audience, platform, application, etc.)
- Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?
- Efficiency: Once users have learned the design, how quickly can they perform tasks?
- Memorability: When users return to the design after a period of not using it, how easily can they reestablish proficiency?
- Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?
- Satisfaction: How pleasant is it to use the design?
(From Usability 101
Principles to support usability
A structured presentation of general principles to apply during design of an interactive system.
- Learnability - the ease with which new users can begin effective interaction and achieve maximal performance
- Predictability - determining effect of future actions based on past interaction history; operation visibility
- Synthesizability - assessing the effect of past actions (on a current state); immediate vs. eventual honesty
- Familiarity - how prior knowledge applies to new system; guessability, affordance
- Generalizability - extending specific interaction knowledge to new situations
- Consistency - likeness in input/output behavior, arising from similar situations or task objectives
- Flexibility - the multiplicity of ways the user and system exchange information
- Robustness - the support the system provides to the user in determining successful achievement and assessment of goal-directed behavior
Principles of Flexibility
- Dialogue Initiative
- freedom from system imposed constraints on input dialogue
- Avoid unnecessary constraints (e.g., modal dialogs)
- Impose necessary constraints (e.g., error checking on input boxes)
- System vs. user pre-emptiveness
- Ability of system to support user interaction for more than one task at a time
- Concurrent vs. interleaving (can move between things); multimodality (perform a different task using different modes)
- Task Migratability
- Passing responsibility for task execution between user and system (e.g., correcting spelling manually and bypassing automated dialogue box that accomplishes same thing)
- Allowing equivalent values of input and output to be substituted for each other
- Representation multiplicity (i.e., various, perhaps simultaneous views of an output); equal opportunity (e.g., if you can see it, you can use it…an example is dragging and dropping functions between UI file manager and command line and getting equal results)
- Modifiabiltiy of the user interface by user (adaptability) or system (adaptivity)
Principles of Robustness
- Ability of user to evaluate the internal state of the system from its perceivable representation. (i.e., explore current internal state of a file…e.g., “properties”)
- Browsability; defaults (i.e., providing defaults during dialogue); reachability (i.e., navigation through observable system states); persistence(i.e., “beep” vs. status line); operation visibility (i.e., overlaps with affordances and visibility)
- Ability of user to take corrective action once and error has been recognized
- Reachability; forward/backward recovery (i.e., undo/redo); commensurate effort (i.e., make actions as difficult as their “recovery” [e.g., delete file vs. undelete file])
- How the user perceives the rate of communication with the system
- Stability (i.e., consistency in response time)
- Task Conformance
- Degree to which system services support all of the user’s tasks (i.e., system functionality covers all tasks in domain)
- Task completeness (i.e., maximize efficiency of model-world metaphor [model: UI or what user perceives; world: user tasks]); task adequacy (i.e., minimize articulation & observation translation)
The User Interface as an Iceberg
Interaction Frameworks (from Chapter 2 of Norman’s book)
- The communication between the user and the system
- Sys A (articulation language, Gulf of Execution)--> UI --> Sys B
- Sys A <--(observation language, Gulf of Evaluation) UI <-- Sys B
- Donald Norman’s Interaction framework (page 48)
- User establishes the goal (i.e., high level thing you want to accomplish)
- Formulates intention (i.e., intermediate task that requires some thinking/planning)
- Specifies actions at interface (i.e., using the articulation language)
- Executes action
- Perceives system state
- Interprets system state
- Evaluates system state with respect to goal
- Some systems are harder to use than others
- Gulf of Execution – user’s formulation of actions may be different to those actions allowed by the system. As designers, we want to minimize the “Gulf”
- Gulf of Evaluation – user’s formulation of actions may be different to those actions allowed by the system. Deals with last three bullets of Norman’s Interaction Framework (i.e., perceives system state, interprets system state, and evaluates sys state w.r.t. goals).
- Norman’s model concentrates on the user’s view of the system.
- Definition: Tasks analysis is the study of the way people perform tasks with existing systems (or planned systems)
- Sources of information
- Existing documentation
- Uses of Task Analysis
- Manuals and documentation
- New systems (discovering the user’s conceptual model)
- Task Analysis is Methods of Analyzing People’s Jobs
- What people do (i.e., tasks, subtasks, activities, actions)
- What things they work with (i.e., objects they act on, physical manipulation)
- What they must know (about activities, objects,…involves relationships, constraints/preconditions, outcomes/postconditions)
- In order to clean the house
- Get the vacuum cleaner out
- Fix the appropriate attachment
- Clean the rooms
- When dust bag gets full, empty it
- Put the vacuum cleaner and tools away
- Must know about:
- Vacuum cleaners, their attachments, dust bags, cupboards, rooms, etc.
Approaches to Task Analysis
- Task Decomposition
- splitting task into (ordered) subtasks
- Knowledge based techniques
- What the user knows about the task and how it is organized
- Entity-relations based analysis
- Relationships between objects and actions and the people who perform them
- General Method
- Observe – unstructured lists of words and actions
- Organize – using notation or diagrams
- Hierarchical Task Analysis (HTA)
- Uses text and diagrams to show hierarchy
- Plans to describe order
- Lifts focus from system to use
- Suggests candidates for automation
- Uncovers user’s conceptual model
- Detailed interface design
- Taxonomies suggest menu layout
- Object/action lists suggest interface objects
- Task frequency guides default choices
- Existing task sequences guide dialogue design
- Task analysis is never complete…its flexible
Definition: A goal is a high-level objective a human wishes to accomplish
- System independent
- E.g., wake up at 6:00 AM
Definition: A task is the activities required to accomplish a goal using a particular device
- Involves planning and problem solving
- E.g., set alarm clock
Definition: An action is a low-level activity that involves no problem solving
- No control structure
- Physical low-level interaction w/device (e.g., double-click)
Example Hierarchy Description
- In order to clean the house
- Get the vacuum cleaner out
- Fix the appropriate attachment
- Clean the rooms
- Living rooms
- Empty the dust bag
- Put vacuum cleaner and attachments away
- And plans
- Plan 0 do 1-2-3-5 in that order. When dust bag full, do 4
- Plan 3 do any of 3.1., 3.2, or 3.3 in any order depending on which rooms need cleaning