Lecture 19: User Research – Part I

Learning Goals

After studying this lecture, students will be able to:

 Understand the difference between qualitative and quantitative research

 Explain qualitative research techniques in detail

 Understand the importance of user research in design

Importance of User Research in Design

The success of any design does not depend only on creativity or technical skill.
A design is successful only if it fulfills the needs of users and the organization that asked for it.

A designer must clearly understand:

 Who the users are

 What problems users face

 What tasks users perform

 What business goals the organization wants to achieve

 What technical and organizational limitations exist

Without this understanding, even a very creative design can fail.

Why Qualitative Research is Important

Questions such as:

 What do users do?

 How do they do it?

 Why do they behave in a certain way?

cannot be answered properly using numbers alone.

These questions are best answered using qualitative research, not just statistics or
demographics.
Qualitative vs Quantitative Research

Quantitative Research

 Deals with numbers and measurements

 Answers questions like:

o How many?

o How often?

o How much?

 Examples:

o Surveys

o Statistics

o Metrics

 Useful for measuring scale, trends, and frequency

Limitations of Quantitative Research

 Human behavior is complex

 Numbers cannot capture:

o Emotions

o Motivation

o Context

o Subtle behavior patterns

 Humans are not machines; their behavior changes with mood, situation, and
environment

Qualitative Research

 Deals with words, observations, and experiences

 Answers questions like:

 o What?

o How?

o Why?

 Focuses on understanding behavior in real situations

 Captures rich details and nuances

Why Qualitative Research is Better for Design

 Design depends on understanding:

o User goals

o Context of use

o Problems and frustrations

 Qualitative research helps designers understand the real experience of users

Value of Qualitative Research

Qualitative research helps designers understand:

 How existing products are used

 Problems users face with current solutions

 User behavior patterns

 The environment in which the product will be used

 Technical and business constraints

 Vocabulary and social norms of the domain

Benefits of Qualitative Research in Design Projects

Qualitative research:

 Provides strong justification for design decisions

 Creates a shared understanding among designers, engineers, and managers

 Helps management make better decisions

  Reduces guesswork

 Is:

o Faster

o Less expensive

o More flexible

o More insightful than quantitative research

Key Questions Answered by Qualitative Research

 What problems do users face with current solutions?

 How does the product fit into users’ daily lives?

 What are users trying to achieve?

 What tasks help users reach their goals?

19.1 Types of Qualitative Research

The following qualitative research techniques are commonly used:

1. Stakeholder interviews

2. Subject Matter Expert (SME) interviews

3. User and customer interviews

4. User observation / ethnographic field studies

5. Literature review

6. Product, prototype, and competitive audits

Stakeholder Interviews

Who are Stakeholders?

Stakeholders are key people in the organization commissioning the product, such as:

 Managers
  Engineers

 Sales and marketing staff

 Customer support staff

 Executives

 Business partners

Purpose of Stakeholder Interviews

Stakeholder interviews help designers understand:

 Business goals

 Technical constraints

 Budget and timeline

 Organizational expectations

How Stakeholder Interviews Should Be Conducted

 One-on-one interviews are preferred

 Duration: around 1 hour

 Conducted before user research

 Encourages honest and open discussion

Information to Gather from Stakeholders

 Product vision from each department

 Budget and schedule

 Technical limitations

 Business drivers and objectives

 Stakeholders’ assumptions about users

Understanding these issues helps designers:

  Align business and user needs

 Build internal consensus

 Increase credibility of the design team

Subject Matter Expert (SME) Interviews

Who are SMEs?

SMEs are experts in the product domain, such as:

 Consultants

 Trainers

 Former users

 Industry specialists

Key Points About SMEs

 SMEs are expert users

 They may prefer complex or advanced features

 Their perspective may not match average users

 They provide:

o Domain knowledge

o Industry standards

o Regulatory information

How Designers Should Use SMEs

 Focus on understanding problems, not just proposed solutions

 Use SMEs for guidance in complex domains

 Involve SMEs throughout the design process

User and Customer Interviews

Difference Between Users and Customers

 Users: People who actually use the product

 Customers: People who buy or approve the product

In many business systems:

 Customers ≠ Users

Customer Interviews Focus On

 Purchasing goals

 Buying decisions

 Frustrations with current products

 Installation and maintenance responsibilities

 Domain vocabulary

User Interviews Focus On

 Daily tasks

 Problems and frustrations

 Workflows

 Context of use

 User goals and motivations

Users are the primary focus of design.

User Observation

People often cannot accurately describe their own behavior.

Observation provides more reliable data than interviews alone.

Benefits of User Observation

  Reveals real behavior

 Captures unspoken actions

 Shows actual workarounds

 Provides context

Best results come from combining interviews with observation.

Literature Review

Design teams should review:

 Product documentation

 Market research

 Technical specifications

 Industry articles

 Competitive analysis

 Customer support records

Purpose:

 Build domain knowledge

 Develop interview questions

 Validate user findings

Product and Competitive Audits

Designers should:

 Review existing products and prototypes

 Analyze competitor products

 Conduct heuristic evaluations

Benefits:

 Understand strengths and weaknesses

  Identify industry standards

 Improve interview quality

Lecture 20: User Research – Part II

Learning Goals

After this lecture, students will be able to:

 Understand the user-centered design approach

 Explain ethnographic interviews

 Prepare for ethnographic field studies

20.1 User-Centered Approach

User-centered design means:

 Design is driven by real users

 User goals are more important than technology

 Systems should support users, not control them

Gould and Lewis Principles (1985)

1. Early Focus on Users and Tasks

 Study users early

 Observe users doing real work

 Involve users in design

2. Empirical Measurement

 Test designs with users

 Measure performance and reactions

3. Iterative Design

 Design → Test → Fix → Test again

  Continuous improvement

Ethnography in Design

What is Ethnography?

 Originates from anthropology

 Means “writing the culture”

 Focuses on observing people in their natural environment

Purpose of Ethnography

 Understand real work practices

 Reveal hidden behaviors

 Make implicit knowledge explicit

Ethnography and Design

 Ethnography of development

 Ethnography for development

 Ethnography within development (most common)

Stock Market Example

Ethnographic study showed that:

 New technology could disrupt communication

 Old tools supported awareness

 Design decisions must consider social interaction

20.2 Ethnography Framework

Three dimensions:
1. Distributed Coordination

 How tasks are shared

 How people coordinate work

2. Plans and Procedures

 Formal workflows

 Organizational rules

3. Awareness of Work

 How people stay informed about others’ work

Methods Supporting Ethnography

Coherence

 Integrates ethnography with software design

 Uses viewpoints and concerns

Key concerns:

 Paperwork vs computer work

 Skill and local knowledge

 Spatial and temporal organization

 Organizational memory

Contextual Design

Seven stages:

1. Contextual inquiry

2. Work modeling

3. Work redesign

4. User environment design

5. Mockups
 6. Testing

7. Implementation

Contextual Inquiry Principles

 Context: Observe users in real environment

 Partnership: Collaborative interaction

 Interpretation: Analyze meaning carefully

 Focus: Guide interview toward design needs

20.3 Preparing for Ethnographic Interviews

Persona Hypothesis

A starting guess about user types based on:

 Roles

 Behaviors

 Demographics

 Environment

Business vs Consumer Roles

 Business users: job-based roles

 Consumers: lifestyle-based roles

Behavioral Variables

 Frequency

 Motivation

 Preferences
Domain vs Technical Expertise

 Domain knowledge ≠ computer skills

 Design must support both

Environmental Variables

 Company size

 IT control

 Security levels

20.4 Putting a Plan Together

 Each variable should be covered in 4–6 interviews

 Interviews can overlap variables

 Smart planning reduces total interviews

 Results guide persona creation and design decisions

Here’s a clear, simplified, and well-structured set of notes for Lecture 21 and 22 on User
Research and User Modeling with all headings and subheadings explained in easy words:

Lecture 21: User Research Part III

Learning Goals

After this lecture, you will be able to:

 Understand how to conduct ethnographic interviews.

 Discuss other user research techniques briefly.

21.1 Conducting Ethnographic Interviews

Securing Interviews
To get access to interview participants, use:

1. Stakeholders – people involved in the project.

2. Market or usability research firms – companies that provide participants.

3. Friends and relatives – informal participants.

Interview Teams and Timings

 Usually 2 interviewees per session.

 1 hour per interview.

 6 interviews per day.

21.2 Phases of Ethnographic Interviews

Phase Focus

Early-phase Exploratory, domain knowledge, open-ended questions

Mid-phase Identify patterns, clarifying and more focused questions

Late-phase Confirm patterns, clarify roles & behaviors, closed-ended questions

 Interviews start with general/structural issues → move to specific/task-oriented issues.

 Early: broad questions; Mid: focused questions; Late: confirm and finalize observations.

21.3 Basic Interview Methods

 Conduct interviews where the action happens.

 Avoid fixed set of questions.

 Focus on goals first, tasks second.

 Avoid making the user a designer or discussing technical details.

 Encourage storytelling and show-and-tell.

 Avoid leading questions.

Types of Questions
 1. Goal-oriented – Focus on user’s goals, priorities, and time-wasters.
Examples:

o What activities waste your time?

o What makes a good/bad day?

2. System-oriented – About product usage.

Examples:

o Most common tasks?

o Favorite or annoying features?

3. Workflow-oriented – About processes and exceptions.

Examples:

o What steps do you take for a task?

o What’s a typical/atypical day?

4. Attitude-oriented – Focus on motivation and preferences.

Examples:

o Future aspirations?

o Tasks you avoid or enjoy?

21.4 Types of Qualitative Research

 Stakeholder interviews

 Subject matter expert interviews

 User/customer interviews

 Literature review

 Product/prototype audits

 Ethnographic field studies (user observation)

21.5 Other Research Techniques

1. Focus groups – Users react to a product in a group; reactions recorded.

 2. Market demographics and segments – Identify motivations, demographics,
psychographics.

3. Usability and user testing – Test product usability with real users.

21.6 Comparison of Techniques

Technique Good for Data type Advantages Disadvantages

Mostly Direct contact with Time-consuming,

Interviews Exploring issues
qualitative users may intimidate user

Studying Learning No time required Real work may differ

Quantitative
documentation procedures, rules from users from docs

Very time-
Naturalistic Understanding
Quantitative Real work insights consuming, lots of
observation user context
data

Focus Collect multiple Mostly Highlights Dominant characters

groups/workshops viewpoints qualitative consensus/conflict may influence group

Key idea: Use ethnographic techniques for qualitative data like usage patterns, goals, and
behaviors.

Lecture 22: User Modeling

Learning Goals

After this lecture, you will be able to:

 Understand user modeling and personas.

 Know how to use user models in design.

22.1 Why Model?

 Models help simplify complex data and understand users.

 They show key relationships between users, environment, and products.

 Example: Like physicists model atoms, designers model users.

  Personas formalize user patterns and guide design decisions.

22.2 Personas

 Personas = fictional users based on real user data.

 They represent user behaviors, goals, and motivations.

 Avoid designing for everyone; instead, focus on specific user types.

 Helps reduce cognitive overload and improve user satisfaction.

Strengths of Personas

 Define product behavior and features.

 Communicate with team and stakeholders.

 Build consensus and focus on user needs.

 Test design ideas before real user testing.

 Support marketing and strategic decisions.

Personas in User-Centered Design

 Solve these issues:

1. Elastic user – avoids vague “user” definitions.

2. Self-referential design – avoids designing based on own preferences.

3. Edge cases – avoids overfocusing on rare scenarios.

Research Basis

 Personas must be based on ethnographic interviews and observations.

 Other supporting data: stakeholder input, market research, surveys, literature.

Representation

 Personas are individuals but represent classes of users.

 They capture behaviors, goals, motivations.

 Avoid stereotypes; focus on real observed patterns.

Motivations and Goals

  Personas have goals that drive behaviors.

 Goals can’t always be asked directly; must be inferred from observations.

22.3 Types of Goals

User Goals

1. Life goals – Broad personal aspirations.

Example: “Be best at my work.”

2. Experience goals – How user wants to feel.

Example: “Feel confident using the product.”

3. End goals – Tangible outcomes of using the product.

Example: “Find best price online.”

Non-User Goals

 Customer goals – Goals of purchasers, not end users.

 Corporate goals – Goals of organization/business.

 Technical goals – Goals like efficiency, security, cost-saving.

22.4 Constructing Personas

Steps

1. Revisit persona hypothesis – Compare research with assumptions.

2. Map interview subjects to behavior variables – Identify patterns.

3. Identify significant behavior patterns – Find clusters of similar behaviors.

4. Synthesize characteristics and goals – Make bullet points from data.

5. Check for completeness – Ensure all behaviors/goals captured.

6. Develop narratives – Short 1-2 page stories for each persona.

7. Designate persona types – Classify personas.

22.5 Types of Personas

 1. Primary – Main target user for design.

2. Secondary – Needs minor adjustments to primary interface.

3. Supplemental – Satisfied by primary interface; often stakeholder-related.

4. Customer – Purchasers, not end users.

5. Served – Not users, but affected by product use.

6. Negative – Non-target users; helps avoid designing for wrong audience.

This summary simplifies your lecture content while keeping all headings, subheadings, and key
points for easy revision.

Here’s a simplified, well-organized set of notes for Lecture 23 and 24 on Human-Computer

Interaction (HCI), keeping all headings, subheadings, and explanations in easy-to-understand
wording:

Lecture 23: Requirements

Learning Goals

After studying this lecture, you will be able to:

 Understand narratives and scenarios

 Define requirements using persona-based design

We already know how to collect information about users and create user models. This helps us
see who our users are and what they want. We also know how to choose the most important
users for design. Now, we learn how to turn this knowledge into design solutions that satisfy
both users and business/technical needs.

The process uses personas and storytelling (narratives) to guide design in a way that is iterative,
repeatable, and testable. It has three major milestones:

1. Define user requirements

2. Use requirements to define interaction framework

3. Fill the framework with design details

The key tool throughout is narrative: telling stories with personas to guide design.

23.1 Narrative as a Design Tool

What is narrative?

 Narrative = storytelling, one of the oldest human activities.

 It helps communicate ideas and visualize designs creatively.

 Interaction design is about behavior over time, so narrative + simple visualization (e.g.,
whiteboard) is ideal for initial design work.

 Detailed visuals and tools are used later; early work should be flexible and simple.

Scenarios in Design

 Scenario = story describing how a user uses a product.

 Scenarios are concrete but flexible, allowing “what-if” thinking and design exploration.

 Carroll (author of Making Use) defines scenario-based design as describing how users
accomplish tasks using an environment and actors (like Accountant, Programmer).

Problems with Carroll’s approach:

1. Scenarios are too abstract; designers need detailed user understanding.

2. Focuses on tasks, not user goals. Goals should come first.

Solution: Use personas in scenarios.

 A persona = detailed user model with goals and behaviors.

 Personas make scenarios realistic and help empathize with users.

 Helps answer: “What should this product do?” and “How should it behave?”

Using Personas in Scenarios

 Persona-based scenario = narrative of persona using a product to reach goals.

 Scenarios show interaction over time, and how goals guide tasks and interface.

 Designers role-play personas to test ideas.

  Three types of persona-based scenarios exist, each with narrower focus as design
progresses.

Persona-based Scenarios vs Use Cases

Aspect Persona-Based Scenario Use Case

Define product behavior from user Describe all functional requirements,

Purpose
perspective, prioritize functions mainly system actions

Low-level user actions and system

Focus User goals, tasks, and interaction
responses

Iterative design, prioritization, interface Validation, cataloguing tasks,

Use
design completeness check

Says little about task presentation or

Limitation Needs refinement for technical specs
priority

23.2 Envisioning Solutions with Persona-Based Design

Requirement Definition Phase

 Determines what the product should do.

 Steps:

1. Creating problem and vision statements

2. Brainstorming

3. Identifying persona expectations

4. Constructing context scenarios

5. Identifying needs

Steps 3–5 are iterative: repeat until requirements are stable.

Step 1: Creating Problem and Vision Statement

 Problem statement = what is wrong, for both users and business.

 o Example: “Customer satisfaction dropped because users can’t perform tasks X, Y,
Z.”

 Vision statement = how design fixes the problem.

o Example: “New design allows users to perform X, Y, Z efficiently, improving

satisfaction and market share.”

Step 2: Brainstorming

 Purpose: get all ideas out to reduce designer bias before scenario work.

 Unconstrained brainstorming is encouraged; record all ideas, even unusual ones.

Step 3: Identifying Persona Expectations

 Expectations = persona’s mental model of the product.

 Includes:

o Desired experiences

o Expected behaviors

o Social, cultural, and cognitive influences

 Analyze research data to find verbs, actions, and priorities in user behavior.

Step 4: Constructing Context Scenarios

 Scenarios = stories showing persona activities in context.

 Answer questions like:

o Where is the product used?

o How often?

o Interruptions?

o Other products used simultaneously?

o Complexity allowed?

 Keep scenarios broad first, then refine.

Example Scenario: Salman, real-estate agent in Lahore, uses a PDA/phone to manage work and
family tasks throughout the day (checking email, making calls, managing appointments,
directions, handling interruptions).

Step 5: Identifying Needs

 Needs = objects and actions required in context; not identical to tasks.

Types of Needs:

1. Data needs = info represented (charts, emails, contacts)

2. Functional needs = actions performed on objects (call contact, create appointment)

3. Contextual needs = relationships between objects/actions (which tasks happen

together)

4. Other requirements = business, technical, customer/partner constraints (timelines,

device specs, support, regulations)

Lecture 24: Framework and Refinements

Learning Goals

After this lecture, you will be able to:

 Build an interaction framework

 Refine the product’s form and behavior

24.1 Defining the Interaction Framework

 Defines structure, flow, and behavior of the product.

 Six steps:

Step 1: Defining Form Factor and Input Methods

 Form factor = device type (web, phone, kiosk) and constraints (size, screen,
environment).

 Input methods = keyboard, mouse, touchscreen, voice, etc.

 Determine primary method for main personas.

Step 2: Defining Views

 Views = primary screens or states of the product.

 Organize data/functions based on persona needs and related tasks.

Step 3: Defining Functional and Data Elements

 Functional elements = visible actions (buttons, controls, panes).

 Data elements = items represented (appointments, emails, images).

 Must meet the needs identified in requirements phase.

Step 4: Determining Functional Groups and Hierarchy

 Group elements by task and relationship.

 Consider:

o Size of elements

o Containers for other elements

o Task sequence

o Persona mental models

 Goal: smooth workflow and coherence.

Step 5: Sketching the Interaction Framework

 Draw simple boxes for containers and groups.

 Focus on top-level organization first, not details.

 Iterate with collaborative team sketches.

Step 6: Constructing Key Path Scenarios

 Task-level scenarios for frequent user actions.

  Example: Email app → reading/sending emails.

 Includes interaction details, walkthroughs, and storyboards.

Tips:

 Pretend system is human → polite, helpful, reduces effort.

 Apply interaction principles and patterns for efficiency.

24.2 Prototyping

What is a Prototype?

 Limited representation of design, allows user interaction and testing.

 Can be paper sketches, cardboard models, software simulations, or high-fidelity software

prototypes.

Why Prototype?

 Test ideas with users and stakeholders

 Explore technical feasibility

 Reflect on design alternatives

 Decide between options

Low-Fidelity Prototyping

 Simple, cheap, fast (paper, cardboard)

 Good for concept exploration and iteration

 Not for final product use

Examples:

 Storyboards

 Sketches with simple symbols/icons

High-Fidelity Prototyping
  Closer to final product (software, plastic mockups)

 Fully interactive, user-driven

 More expensive and time-consuming

 Risks: high expectations, slower iteration

Comparison of Low vs High-Fidelity

Prototype
Advantages Disadvantages
Type

Cheap, fast, flexible, good for Limited error-checking, poor for usability
Low-fidelity
brainstorming testing

Fully interactive, realistic, marketing Expensive, time-consuming, discourages

High-fidelity
tool changes

Here’s a structured, easy-to-understand set of notes for Lectures 25 and 26 based on your
detailed text. I’ve simplified the wording while keeping all headings and essential details:

Lecture 25: Design Synthesis

Learning Goals

After this lecture, you should be able to:

 Understand the design principles in Human-Computer Interaction (HCI).

 Discuss design patterns and design imperatives.

Key Idea:
A superior design meets user goals without ignoring business or technical constraints. Design
superiority depends on:

 Interaction design principles (guidelines for useful and usable behavior and form).

 Interaction design patterns (general solutions to common design problems).

 Design imperatives (fundamental principles for guiding design).

25.1 Interaction Design Principles

Definition:
Guidelines that address behavior, form, and content to help users accomplish goals confidently
and efficiently.

Purpose:

Minimize user “work,” which includes:

 Logical work: Understanding text or structure.

 Perceptual work: Decoding visuals like shapes, colors, and layout.

 Mnemonic work: Remembering passwords, commands, or control locations.

 Physical/motor work: Keystrokes, mouse movements, gestures, navigation.

Levels of Principles:

1. Conceptual-level: Defines what the product is and its broad use.

2. Interaction-level: Defines how the product behaves.

3. Interface-level: Defines look and feel.

Principles vs Style Guides:

 Style guides: Focus on detailed appearance (buttons, spacing, colors).

 Design principles: Focus on product behavior and user experience.

Norman’s Design Principles

 Visibility, Affordance, Constraints, Mapping, Consistency, Feedback.

Nielsen’s Design Principles

 Visibility of system status.

 Match between system and real world.

 User freedom and control.

 Consistency and standards.

 Error prevention.

 Recognition rather than recall.

  Flexibility and efficiency.

 Aesthetic and minimalist design.

 Help users recognize and recover from errors.

 Help and documentation.

Simpson (1985) Principles

 Define users, anticipate environment, give control, minimize work, simplicity,

consistency, adequate feedback, help orientation, minimize memory load, follow design
conventions.

Shneiderman (1992) Principles

 Consistency, shortcuts, informative feedback, closure, error prevention, easy reversal,

user control, reduce short-term memory load.

Dumas (1988) Principles

 Put the user in control, consider skill level, consistency, hide technical complexity,
provide documentation, minimize memory load, good graphic layout.

25.2 Interaction Design Patterns

Definition:
Patterns are reusable solutions to common design problems. They:

 Capture design knowledge.

 Reduce design effort.

 Educate new designers.

 Represent near-optimal interactions.

Types of Patterns:

1. Postural patterns: Define overall product stance (conceptual).

2. Structural patterns: Manage display, grouping, and data containers. Example: Outlook
layout (navigation pane, overview pane, detail pane).

3. Behavioral patterns: Define interactions with data or widgets.

Key Points:
  Patterns are not cookie-cutter; they adapt to context.

 Relationships between objects and user goals remain consistent, even if visuals change.

25.3 Interaction Design Imperatives

Design should be:

1. Ethical: Do no harm, improve human situations.

2. Purposeful: Help users achieve goals and fit their context.

3. Pragmatic: Meet business and technical requirements.

4. Elegant: Simple, coherent, cognitively and emotionally appropriate.

Manual/Interface Guidelines:

 Ask relevant questions.

 Learn about audiences.

 Organize info for quick access.

 Put users in control.

 Use clear typography.

 Write in user-friendly language.

 Be consistent.

 Test usability and revise.

 Make information accessible.

 Give clear messages, prompt input, report status, explain errors.

Lecture 26: Behavior & Form Part I

Learning Goals

After this lecture, you should be able to:

 Understand narratives and scenarios.

 Define requirements using persona-based design.

26.1 Software Posture

 Programs, like people, have a behavioral stance (posture) that affects usability.

 Posture should reflect user goals, not designer preference.

 It influences the look, feel, and interaction style.

26.2 Postures for Desktop Applications

Four Types of Posture:

1. Sovereign Posture

 Full-screen programs dominating attention.

 Examples: Word processors, spreadsheets, email clients.

 Designed for intermediate users (long-term frequent users).

 Guidelines:

o Take full screen; optimize layout for flow.

o Muted, narrow color palette for long-term use.

o Rich visual feedback and input options.

o Document-centric apps maximize screen space.

2. Transient Posture

 Short-lived programs for a single task.

 Examples: Calculator, file explorer pop-ups.

 Guidelines:

o Bold, clear, unsubtle interface.

o Controls visible, simple, and not crowded.

o Provide memory for last-used settings.

o Keep management overhead minimal.

3. Daemonic Posture
  Programs running mostly in the background.

 Examples: Printer drivers, system services.

 Rare user interaction; interface usually transient.

 Must report status appropriately when needed.

 Often accessed via icons in status area or control panels.

4. Auxiliary Posture

 Programs supporting a sovereign application.

 Examples: Clock, taskbar, stickies, performance monitors.

 Continuous but small presence.

 Simple reporting, conservative use of pixels.

 Must respect the primary sovereign application.

Here’s a simplified, structured, and easy-to-understand set of notes for Lecture 27: Behavior &
Form Part II with all the main headings and key points explained clearly:

Lecture 27: Behavior & Form Part II

Learning Goals

After this lecture, you should be able to:

 Understand narratives and scenarios in Human-Computer Interaction (HCI).

 Define requirements using persona-based design.

27.1 Postures for the Web

Web design often involves choosing the “posture” of the interface, based on how users interact.
There are four main postures, and most websites fit into one or a combination.

Information-Oriented Sites

 Purpose: Present information clearly; limited transactions.

  Challenge: Balance sovereign attributes (for repeat users) vs transient attributes (for
first-time/infrequent users).

Key points:

 Frequent updates → attract repeat users → more sovereign stance.

 Rare updates → used occasionally → more transient stance.

Sovereign Attributes

 Best for detailed information.

 Use full-screen layout to organize content and navigation clearly.

 Must decide lowest screen resolution to support.

Transient Attributes

 Focused on ease of navigation for infrequent users.

 Allow bookmarking, remembering past actions (cookies, server-side memory).

Transactional Sites & Web Applications

 Employees: Daily use → sovereign stance.

 Consumers: Weekly/monthly use → mix of sovereign and transient.

 Good examples: [Link] uses:

o One-click ordering

o Persistent shopping cart

o Recommendations

o Search & browsing

27.2 Web Portals

 Original portals: Simple navigation → go somewhere else. Mostly transient posture.

 Environmental portals: Provide integrated content and tools → become a destination →

sovereign posture.

Elements within portals:

 Auxiliary elements: Constant access tools (status monitors, link lists).

  Transient elements: Temporary services (to-do list, package tracking).

Key challenge: Break applications into portal services with auxiliary or transient posture. Avoid
sovereign full-browser applications inside portals.

27.3 Postures for Other Platforms

Kiosks

 Usually transient: Users are often first-timers, standing, short interactions.

 Design: simple navigation, large controls, rich visuals.

 Educational/entertainment kiosks can allow slightly more complexity.

Handheld Devices

 Limited screen, input, and power.

 Satellite devices: PIM, email, browsing → auxiliary posture.

 Phones: Primary communication → transient posture, often voice-driven.

 Converged devices (like Treo): Use auxiliary functions to support transient tasks.

Appliances

 Mostly transient posture: simple interface, dials, buttons.

 Status indicators may be auxiliary (more persistent info if needed).

 Avoid clutter and too many features.

27.4 Flow and Transparency

 Flow: Deep focus and productivity, unaware of distractions (Csikszentmihalyi).

 Software should support flow, not break it.

Methods to achieve transparent interface:

1. Follow mental models: Match interface to user’s understanding.

2. Direct, don’t discuss: Act like a tool (hammer, car), not a conversational partner.

3. Keep tools close: Tools on palettes/toolbars, easily accessible.

 4. Modeless feedback: Show status without interrupting workflow (e.g., Word status bar,
jet fighter HUD).

27.5 Orchestration

 Interaction should feel invisible, focusing on user goals.

 Interface elements must work harmoniously.

 Less is more: Reduce interface clutter without reducing system power.

Design Principles for Orchestration

1. Distinguish possibility vs probability: Don’t ask users unnecessary questions (e.g., “Save
file?” repeatedly).

2. Provide comparisons: Show meaningful visual data (pie charts, percentages) instead of
raw numbers.

3. Graphical input: Allow direct manipulation (e.g., drag to reorder items, adjust graphs).

4. Reflect program status: Program should visually indicate state (busy, idle, sleeping).

5. Avoid unnecessary reporting: Don’t interrupt users with trivial updates.

6. Avoid blank slates: Provide reasonable defaults; users can adjust if needed.

7. Command vs configuration:

o Commands → direct action.

o Configuration → set up complex parameters.

o Example: Print button executes immediately; Print Setup for detailed settings.

8. Asking questions vs providing choices:

o Questions can make users feel inferior or harassed.

o Provide choices quietly (like a toolbar) instead of interrupting (like dialog boxes).

9. Hiding ejector seat levers:

o Rarely used but important functions should be hidden safely.

o Must prevent accidental use of powerful or irreversible actions.

Here’s a simplified and structured set of notes for Lecture 28 (Behavior & Form Part III) and
Lecture 29 (Evaluation – Part I) in easy-to-understand wording while keeping all key headings
and details:

Lecture 28: Behavior & Form Part III

Learning Goals:
After this lecture, you should be able to:

 Understand narratives and scenarios

 Define requirements using persona-based design

28.1 Eliminating Excise

Excise is extra work that a user must do which does not directly help achieve their goal.

Examples of Excise:

 Driving: Opening the garage, starting the car, stopping at traffic lights – these are not the
main goal (reaching the office) but are necessary steps.

 Software: Installing programs, configuring networks, making backups – extra work

imposed by the tool.

Key Idea:
Eliminating excise makes software more effective, productive, and usable. Designers should
minimize excise like a doctor removes an infection.

GUI Excise

 GUI users often do extra work moving windows, resizing, or organizing icons.

 Command-line users have their own excise: memorizing commands and setting up the
environment.

 Casual users benefit from GUIs despite extra excise because it helps them learn and
navigate.

 Expert users may find GUI “help” gets in the way.

Training Wheels

 Beginner aids (tutorials, extra guidance) are useful at first.

 Must be removable for advanced users to avoid unnecessary excise.

Pure Excise

 Tasks no one needs, e.g., telling software which COM port to use.

Visual Excise

 Overuse of visual metaphors (desktop with icons) can hinder advanced users.

 Excessive visuals on websites or apps can distract from user goals (e.g., [Link] failure
in e-commerce).

Determining Excise

 Compare actions to user goals.

 Only tasks that don’t help the user achieve their goal are excise.

28.2 Navigation and Inflection

Navigation is essential for usability. Poor navigation is often the main frustration in software.

Navigation is usually excise:

 Users rarely aim to “navigate” as their goal; it’s extra work.

Types of Navigation:

1. Between multiple windows/screens: Causes disorientation; productivity drops.

2. Between panes within a window:

o Adjacent panes reduce navigation needs.

o Too many panes or poorly arranged panes increase excise.

 o Tabbed panes are useful for optional supporting panes.

3. Between tools and menus:

o Frequently used tools should be grouped and easily accessible.

o Example: Adobe Photoshop requires better tool placement.

4. Within information:

o Scrolling, linking, zooming, panning.

o Should be minimized; overuse confuses users.

Improving Navigation:

1. Reduce number of places:

o Minimize windows, screens, dialogs, panes, and controls.

2. Provide signposts:

o Persistent objects like menus, toolbars, and tabs guide users.

3. Provide overviews:

o Graphical (Navigator palette in Photoshop) or textual (breadcrumbs).

4. Map controls to functions:

o Control’s effect should be clear and intuitive.

5. Inflect the interface:

o Frequently used functions → easy to reach

o Rarely used functions → deeper in interface

o Apply commensurate effort principle: effort must match value to user

Principle of commensurate effort:

 Users tolerate complexity if the reward/value is worth it.

 Advanced features can require effort; common tasks should remain simple.

Lecture 29: Evaluation – Part I

Learning Goals:
After this lecture, you should be able to:

 Understand what evaluation is in HCI

 Understand different evaluation paradigms and techniques

What to Evaluate?

 Evaluate software, websites, toys, devices – anything interactive.

 Some aspects need controlled lab evaluation (e.g., task completion).

 Others need natural environment evaluation (e.g., children using a toy).

Example Principles (Gould, 1984 Olympic Message System):

1. Focus on users and their tasks

2. Observe, measure, and analyze performance

3. Design lucratively

Why Evaluate?

 Designers should not assume all users are like them.

 Guidelines alone do not guarantee usability.

 Evaluation ensures the product meets user needs and expectations.

Benefits of User Testing (Tognazzini):

1. Fix problems before release

2. Focus on real problems

3. Engineers code instead of debating

4. Faster time to market

5. Solid first release for sales

When to Evaluate?
  New products: Early evaluation with mockups to understand users’ needs.

 Upgrades: Focus on improving existing functionality.

 Formative evaluation: During development to check design meets user needs.

 Summative evaluation: After development to check product success.

29.1 Evaluation Paradigms and Techniques

Evaluation Paradigm: Set of beliefs + techniques guiding evaluation.

Techniques: Sometimes called methods; include user studies, observation, testing, expert
reviews.

Core Evaluation Paradigms:

Role of Who Feedback to

Paradigm Location When Used Data Type Philosophy
Users Controls Design

User-
Quick & Natural Minimal Lab or Early, fast Usually Notes,
centered,
Dirty behavior control natural feedback quantitative sketches
practical

Test
Quantitative Performance Applied
Usability Perform Strong prototypes,
Lab & reports, usability
Testing set tasks control measure
qualitative specs engineering
performance

Field Natural Study real- Qualitative, Insights, Practical,

Observational Natural
Studies behavior world usage artifacts user quotes ethnographic

Users Theoretical,
Experts Early design Expert Suggested
Predictive not Lab heuristic-
predict issues review analysis fixes
involved based

Techniques for Evaluation:

1. Observing users: Notes, video, audio, interaction logs.

2. Asking users: Interviews, questionnaires (opinions, preferences).

 3. Asking experts: Heuristic reviews, expert predictions.

4. Testing users’ performance: Measure errors, time, success.

5. Modeling user tasks: Predict how interface affects performance.

✅ Summary:

 Excise = extra work for the user → reduce it.

 Navigation = major excise → improve via fewer screens, signposts, overviews, mapping,
and inflection.

 Evaluation = crucial to check usability and user experience.

 Core paradigms: Quick & Dirty, Usability Testing, Field Studies, Predictive.

 Use observations, user feedback, expert reviews, performance testing, and modeling.

Here’s a simplified, well-organized set of notes for Lecture 30 and 31 in easy-to-understand

language, keeping all the main headings and details:

Lecture 30: Evaluation – Part II

Learning Goals:
After studying this lecture, you should be able to:

 Understand the DECIDE evaluation framework in Human-Computer Interaction (HCI).

30.1 DECIDE: A Framework to Guide Evaluation

Well-planned evaluations need clear goals and appropriate questions. The DECIDE framework
helps guide evaluations, especially for beginners. It involves six steps:

1. Determine the overall goals

2. Explore the specific questions

3. Choose evaluation paradigms and techniques

4. Identify practical issues

 5. Decide how to deal with ethical issues

6. Evaluate, interpret, and present data

1. Determine the Goals

 Identify high-level goals and who wants the evaluation.

 Different evaluations have different goals:

o Understanding user needs

o Choosing a design metaphor

o Improving interface consistency

o Studying technology’s impact on work

o Enhancing existing product usability

Example goals:

 Check if evaluators understood users’ needs

 Identify the best metaphor for the design

 Ensure interface consistency

 See how technology affects work practices

 Improve product usability

 Goal influences evaluation approach:

o Engineering interface → quantitative measurements → usability testing

o Observing children → field study

2. Explore the Questions

 Break goals into specific questions.

 Example: Why do customers prefer paper tickets over e-tickets?

o Attitude toward e-tickets?

o Access to computers?
 o Security concerns?

o User interface issues?

 Questions can be further broken down: navigation, terminology, feedback, response

time

3. Choose Evaluation Paradigm and Techniques

 Decide how to answer the questions.

 Consider practical and ethical issues:

o Cost

o Time

o Equipment

o Expertise

4. Identify Practical Issues

Users

 Involve appropriate users.

 Screen users based on:

o Skill level, age, gender, culture, personality

 Task length: 10–120 minutes; offer breaks for >20 min tasks

 Make users comfortable, explain the system is being tested, not them

Facilities and Equipment

 Decide on: cameras, recording, spare batteries, etc.

 Avoid making users uncomfortable

Schedule and Budget

 Plan within available time and resources

Expertise
  Ensure the evaluation team has the necessary knowledge

 Statistical analysis or video review may require experts

5. Ethical Issues

 Follow ethical codes (e.g., ACM).

 Protect privacy and confidentiality

 Use informed consent forms

 Guidelines:

o Explain study goals and time

o Protect sensitive information

o Allow users to stop anytime

o Pay users if possible

o Avoid revealing identity in quotes

 Special case: online studies → extra caution about privacy and consent

6. Evaluate, Interpret, and Present Data

 Decide what data to collect, how to analyze, how to present.

 Key evaluation questions:

o Reliability: consistent results under same conditions

o Validity: measures what it should measure

o Bias: are results distorted?

o Scope: generalizability of results

o Ecological validity: do results reflect real-world usage?

 Example: Lab experiments → low ecological validity

 Hawthorne effect: participants change behavior when being observed

Lecture 31: Evaluation – Part VII (Usability Testing)

Learning Goals:

 Understand how to perform evaluation using usability testing.

What is Usability Testing?

Every usability test shares these 5 key characteristics:

1. Primary goal: Improve product usability

2. Participants: Real users

3. Tasks: Participants perform real tasks

4. Observation: Record what users do and say

5. Analysis: Diagnose problems and recommend changes

Goal: Improve Product Usability

 Focus on improving product and design process

 Specific concerns may vary:

o Menu navigation

o Novice vs expert users

o Installation or maintenance tasks

Participants Represent Real Users

 Must match actual user group

 QA experts are not real users

 Avoid over- or under-experienced participants

Participants Do Real Tasks

 Tasks must match real usage

  Focus on tasks likely to reveal usability problems

Observe and Record Participants

 Observe one participant at a time

 Collect performance and comments

 Distinguish from:

o Focus groups: opinions, not behavior

o Surveys: attitudes, not actions

o Beta tests: real-world use but limited usability data

Analyze Data and Recommend Changes

 Combine quantitative and qualitative data

 Diagnose usability problems

 Suggest improvements

Results Used to Change Product and Process

 Usability testing must lead to improvements

 Helps change attitudes toward users

 Helps improve design and development process

What is Not Required for Usability Testing?

 One-way mirrors, videotape, formal lab, software are not mandatory

 Usability testing can be done with minimal resources

When is Usability Testing Appropriate?

 Can be done iteratively: predesign → early design → development

  Small-scale tests are fine as long as critical factors are followed

Testing All Types of Products and Interfaces

 Works for:

o Consumer electronics (TVs, phones)

o Medical devices (monitors, workstations)

o Engineering tools (oscilloscopes)

o Software (databases, spreadsheets, email)

o Other (voice systems, navigation systems)

 Also works for non-computer products: bicycles, forms, manuals

Testing Different Parts of the Product

 Hardware: installation, operation, maintenance

 Software: navigation, fields, error recovery

 Documentation: tutorials, manuals, online help

Testing Techniques

Co-Discovery

 Two participants work together

 Talk while solving tasks → richer insights

 More expensive, harder to observe

Active Intervention

 Tester actively asks questions during tasks

 Useful for prototypes and early design

 Avoid biasing participants

Additional Benefits

1. Change attitudes about users: Watching users inspires design changes

2. Improve design process: Usability tests reveal deeper process issues

Comparison: Usability Testing vs Beta Testing

 Beta testing: late in development, limited feedback, no observation

 Usability testing: early and iterative, observes real behavior, provides actionable insights

Here’s a simplified, well-organized set of notes for Lecture 32 & 33 in easy-to-understand

wording, keeping all headings and details intact:

Lecture 32: Evaluation IV – Web Navigation

Learning Goals

After studying this lecture, you should be able to:

 Understand the significance of navigation on websites.

32.1 Scene from a Mall

 Imagine going to a mall to buy a chainsaw.

 You look at department signs to find the right area.

 You may start in Tools or Lawn & Garden depending on intuition.

 Once in the right aisle, you look at products; if you guessed wrong, you go to another
aisle.

 Decision-making depends on:

o Familiarity with the store

o Trust in store organization

o How much time you have

o Sociability (ask for help or not)

  Eventually, you may ask someone for directions if lost.

Takeaway: Physical navigation involves signs, hierarchy, and scanning skills.

32.2 Web Navigation

 Similar to navigating a mall, users navigate websites to find something.

 Users decide whether to search first or browse first:

o Search-dominant users: look for search box first

o Link-dominant users: browse links first, search if frustrated

 Browsing process:

o Start at Home page, find main sections

o Click subsections to get closer to desired content

o Click individual links to explore details

 If unsuccessful, users leave the site.

Web vs. Physical Navigation:

 No sense of scale: Hard to know how big a website is.

 No sense of direction: No physical left/right or up/down; only hierarchy levels.

 No sense of location: Must remember conceptual hierarchy, use Back button,

bookmarks, or Home page for orientation.

Key point: Navigation is critical, as it substitutes for physical cues missing on the Web.

Purposes of Navigation

1. Helps users find what they’re looking for.

2. Shows users where they are.

3. Provides grounding and confidence.

4. Reveals site content and hierarchy.

5. Implicitly teaches users how to use the site.

 6. Builds trust in the site’s credibility.

Web Navigation Conventions

 Derived from physical spaces (streets, stores, books).

 Standard placement helps users locate elements quickly.

 Examples of conventions:

o Street signs at corners → Page names in consistent spots

o Grocery store aisle signs → Section headings in navigation

o Table of contents in books → Main navigation on Home page

Persistent (Global) Navigation

 Appears on every page of a site.

 Provides consistent orientation and guidance.

 Key elements to include:

1. Site ID (logo)

2. Sections/primary navigation

3. Secondary navigation (subsections)

4. Utilities (Help, Site Map, Shopping Cart, Contact Us)

5. Local/low-level navigation

Exceptions:

 Home page: May not use persistent navigation.

 Form pages: Minimal navigation to reduce distraction.

Site ID

 Like a building name—identifies the whole site.

 Usually in upper left corner.

  Must be recognizable at any size.

Sections

 Primary links to main sections (top-level hierarchy).

 May include secondary navigation (subsections).

Utilities

 Important tools outside content hierarchy: Help, Site Map, Contact Us, Shopping Cart.

 Limit to 4-5 items to avoid clutter.

Low-Level Navigation

 Often ignored in web design.

 Users spend time on lower-level pages, so consistent navigation is vital.

 Requires sample pages for all levels before designing layout.

Page Names

 Serve as street signs of the Web.

 Must be:

1. Present on every page

2. Positioned to frame content

3. Prominent (size, color, typeface)

4. Match the link clicked to maintain trust

“You Are Here” Indicators

 Show current location in the site hierarchy.

 Must be visible and distinct, using color, bold, or other cues.

Breadcrumbs

 Show path from Home page to current page.

 Helps retrace steps (like Hansel & Gretel crumbs).

 Different from “You Are Here”: one shows hierarchy, the other shows path taken.

Lecture 33: Evaluation V – Tabs and Trunk Test

Learning Goals

After studying this lecture, you should be able to:

 Understand the use of tabs.

 Conduct the trunk test for website navigation.

Use of Tabs

 Tabs act like physical dividers in binders or file folders.

 Common for large websites:

o Self-evident

o Hard to miss

o Visually appealing

o Suggest physical separation of sections

Why Amazon is Good Example

 Drawn correctly: Active tab visually pops forward.

 Fast loading: Minimal graphics

 Color coded: Sections have distinct colors (not only cue, helps usability)

 Tab selected on entry: Immediate clarity for users

Trunk Test

 A method to test web navigation:

1. Pick a random page from a site.

2. Blur or squint vision to avoid reading in detail.

3. Identify:

o Site ID

o Page name

o Sections/subsections

o Local navigation options

o “You are here” indicators

o Search option

 Purpose: Test if navigation is intuitive even when user lands mid-site.

Key Insight

 Websites must design for users arriving anywhere, not just the Home page.

 Navigation clarity is tested by quick recognition, not detailed study.

Here’s a simplified, well-organized set of notes for Lecture 32 & 33 in easy-to-understand

wording, keeping all headings and details intact:

Lecture 32: Evaluation IV – Web Navigation

Learning Goals

After studying this lecture, you should be able to:

 Understand the significance of navigation on websites.

32.1 Scene from a Mall

  Imagine going to a mall to buy a chainsaw.

 You look at department signs to find the right area.

 You may start in Tools or Lawn & Garden depending on intuition.

 Once in the right aisle, you look at products; if you guessed wrong, you go to another
aisle.

 Decision-making depends on:

o Familiarity with the store

o Trust in store organization

o How much time you have

o Sociability (ask for help or not)

 Eventually, you may ask someone for directions if lost.

Takeaway: Physical navigation involves signs, hierarchy, and scanning skills.

32.2 Web Navigation

 Similar to navigating a mall, users navigate websites to find something.

 Users decide whether to search first or browse first:

o Search-dominant users: look for search box first

o Link-dominant users: browse links first, search if frustrated

 Browsing process:

o Start at Home page, find main sections

o Click subsections to get closer to desired content

o Click individual links to explore details

 If unsuccessful, users leave the site.

Web vs. Physical Navigation:

 No sense of scale: Hard to know how big a website is.

 No sense of direction: No physical left/right or up/down; only hierarchy levels.

  No sense of location: Must remember conceptual hierarchy, use Back button,
bookmarks, or Home page for orientation.

Key point: Navigation is critical, as it substitutes for physical cues missing on the Web.

Purposes of Navigation

1. Helps users find what they’re looking for.

2. Shows users where they are.

3. Provides grounding and confidence.

4. Reveals site content and hierarchy.

5. Implicitly teaches users how to use the site.

6. Builds trust in the site’s credibility.

Web Navigation Conventions

 Derived from physical spaces (streets, stores, books).

 Standard placement helps users locate elements quickly.

 Examples of conventions:

o Street signs at corners → Page names in consistent spots

o Grocery store aisle signs → Section headings in navigation

o Table of contents in books → Main navigation on Home page

Persistent (Global) Navigation

 Appears on every page of a site.

 Provides consistent orientation and guidance.

 Key elements to include:

1. Site ID (logo)

2. Sections/primary navigation
 3. Secondary navigation (subsections)

4. Utilities (Help, Site Map, Shopping Cart, Contact Us)

5. Local/low-level navigation

Exceptions:

 Home page: May not use persistent navigation.

 Form pages: Minimal navigation to reduce distraction.

Site ID

 Like a building name—identifies the whole site.

 Usually in upper left corner.

 Must be recognizable at any size.

Sections

 Primary links to main sections (top-level hierarchy).

 May include secondary navigation (subsections).

Utilities

 Important tools outside content hierarchy: Help, Site Map, Contact Us, Shopping Cart.

 Limit to 4-5 items to avoid clutter.

Low-Level Navigation

 Often ignored in web design.

 Users spend time on lower-level pages, so consistent navigation is vital.

 Requires sample pages for all levels before designing layout.

Page Names
  Serve as street signs of the Web.

 Must be:

1. Present on every page

2. Positioned to frame content

3. Prominent (size, color, typeface)

4. Match the link clicked to maintain trust

“You Are Here” Indicators

 Show current location in the site hierarchy.

 Must be visible and distinct, using color, bold, or other cues.

Breadcrumbs

 Show path from Home page to current page.

 Helps retrace steps (like Hansel & Gretel crumbs).

 Different from “You Are Here”: one shows hierarchy, the other shows path taken.

Lecture 33: Evaluation V – Tabs and Trunk Test

Learning Goals

After studying this lecture, you should be able to:

 Understand the use of tabs.

 Conduct the trunk test for website navigation.

Use of Tabs

 Tabs act like physical dividers in binders or file folders.

 Common for large websites:

o Self-evident
 o Hard to miss

o Visually appealing

o Suggest physical separation of sections

Why Amazon is Good Example

 Drawn correctly: Active tab visually pops forward.

 Fast loading: Minimal graphics

 Color coded: Sections have distinct colors (not only cue, helps usability)

 Tab selected on entry: Immediate clarity for users

Trunk Test

 A method to test web navigation:

1. Pick a random page from a site.

2. Blur or squint vision to avoid reading in detail.

3. Identify:

o Site ID

o Page name

o Sections/subsections

o Local navigation options

o “You are here” indicators

o Search option

 Purpose: Test if navigation is intuitive even when user lands mid-site.

Key Insight

 Websites must design for users arriving anywhere, not just the Home page.

 Navigation clarity is tested by quick recognition, not detailed study.

These notes cover all headings, subheadings, and main details from Lectures 32 & 33 in simple,
easy-to-understand language.

If you want, I can make a super-condensed diagram/flow of web navigation elements that
visually shows Site ID → Sections → Local navigation → Breadcrumbs → Utilities for easier
memorization.

Do you want me to make that?

Here’s a super-condensed visual flow of web navigation elements for easy memorization:

Web Navigation Structure (Flow)

[Site ID / Logo]

[Sections / Primary Navigation]

[Subsections / Secondary Navigation]

[Local / Low-Level Navigation]

["You Are Here" Indicator / Breadcrumbs]

[Utilities]
(Search, Help, Site Map, Shopping Cart, Contact)

Key points to remember:

1. Site ID: Top left, identifies the site.

2. Sections: Main site areas, always visible.

3. Subsections: Under sections, secondary links.

4. Local navigation: Helps in current page/section.

5. “You Are Here” / Breadcrumbs: Shows hierarchy or path.

6. Utilities: Extra functions, usually 4–5 max.

Extra Tips:

 Tabs: Highlight active section; must pop visually.

 Page Name: Each page should have a clear name matching the link clicked.

 Trunk Test: Blindfolded test → should immediately recognize all navigation elements.

Here’s a simplified, complete set of notes for Lectures 34 & 35 in clear, easy-to-understand
language, keeping all headings and details:

Lecture 34: Evaluation – Part VI (Heuristic Evaluation)

Learning Goals

After this lecture, you should be able to:

 Perform heuristic evaluations to identify usability issues on a website.

Common Usability Issues

1. Fonts

o Fonts are unclear or not readable.

2. Color

o Dim colors make text or elements hard to see.

 3. Browser Title

o Always contains the word “Home” → confusing.

o Invalid characters in browser titles.

4. Banner Ads

o Take up too much space.

5. Navigation Highlights

o Highlighted tab shows “Home” → user knows current page.

o Absence of highlight → confuses user about the current section.

6. Version Numbers

o Should not be on the main page → users don’t care.

7. Breadcrumbs

o Format does not follow standard conventions.

8. Misleading Links

o Example: “Sign up now” link → looks like free report but takes user to online
store.

9. Horizontal Scrolling

o Avoid horizontal scrolling → indicates poor layout.

Lecture 35: Evaluation – Part VII (Strategic Usability & Web Nature)

Learning Goals

After this lecture, you should be able to:

 Understand the strategic nature of usability.

 Understand the nature of the Web as a medium.

35.1 Relationship Between Evaluation and Usability

 Evaluation uncovers interface problems → improves usability.

  Key questions to ask:

1. Do you understand the users?

2. Do you understand the medium?

3. Do you understand the technologies?

4. Do you have commitment?

Technologies

 Know technological constraints and possibilities.

 Understand what can be implemented with current tech.

 Good system design = understanding technology limitations & potential.

Users

 Know user goals, behaviors, and needs.

 Use personas to understand users.

 Design systems that satisfy user needs.

Commitment

 Usable systems need commitment at all organizational levels.

Medium

 Know the medium (Web) to build usable systems.

Nature of the Web

 The Web = a super medium combining:

o Print

o Video
 o Audio

o Software applications

 This diversity makes Web design challenging.

Five Planes of User Experience

These planes form a conceptual framework to design & evaluate user experience:

1. Strategy Plane

o Defines goals of users & organization.

o Example: Users want books → site wants to sell books.

2. Scope Plane

o Defines features and content of the site.

o Software → functional specs; Information → content requirements.

3. Structure Plane

o Defines behavior and organization of the site.

o Software → interaction design; Information → information architecture.

4. Skeleton Plane

o Layout & arrangement of elements.

o Includes:

 Information design: Clear presentation of content.

 Interface design: For software interaction.

 Navigation design: For browsing information.

5. Surface Plane

o Visual appearance of the site.

o Everything users see and interact with.

Bottom-to-Top Approach:

 Strategy → Scope → Structure → Skeleton → Surface.

  Each plane builds on the previous to deliver full user experience.

Software vs. Information Focus

 Web combines software functionality + hypertext information:

o Software → tasks, process completion

o Information → content distribution, meaning

Example:

 Checkout page: Software = buttons & tasks, Hypertext = information layout.

 Both sides influence Skeleton & Surface planes.

Elements of User Experience

 Planes break into elements:

o Strategy → user & business goals

o Scope → features / content

o Structure → interaction / info architecture

o Skeleton → interface, navigation, information design

o Surface → visual design

 Elements work together to define user experience.

 Some problems straddle multiple elements → need combined solution.

Content

 Content is most important:

o Users value valuable content above everything else.

o Good content + good design = excellent Web experience.

Key Takeaways
 1. Heuristic evaluation = check site for usability issues.

2. Usability depends on users, technology, medium, and commitment.

3. Web = super medium, combining software & information space.

4. Five planes = Strategy → Scope → Structure → Skeleton → Surface.

5. Content + navigation + interface + visual design = complete user experience.

Here’s a detailed and simplified version of Lecture 36: Behavior & Form – Part IV in easy-to-
understand notes while keeping all headings and key points:

Lecture 36: Behavior & Form – Part IV

Learning Goals:
After studying this lecture, you should be able to:

 Understand the significance of Undo.

 Discuss File and Save systems.

36.1 Understanding Undo

 Undo is a facility that lets users reverse a previous action.

 It is extremely valuable because humans make mistakes; computers don’t.

 Undo should be designed according to the user’s mental model, not the
implementation model of the program.

Users and Undo:

 Humans make mistakes as part of normal behavior (hiccups, sneezes, typos).

 Treating these as “errors” harms software design.

 Users don’t usually think they make mistakes; they see their actions as reasonable.

 Undo helps users explore software without fear of permanent mistakes.

 Psychologically, it reassures users, giving confidence to experiment.

Designing Undo:
  Undo supports trustworthiness, not a specific task.

 Users may see Undo differently:

o Beginner: Panic button.

o Experienced: Data recovery tool.

o Logical user: Stack of actions reversed in order.

 Undo should avoid signaling user failure; it should support exploration.

 Undo works best as global, affecting all actions, but can be complicated with embedded
objects (e.g., spreadsheet in Word).

36.2 Types and Variants of Undo

 Software usually just calls everything Undo, causing a lack of innovation.

 There are several variants:

36.3 Incremental and Procedural Actions

 Incremental actions: Actions with data changes (typing, cutting, pasting). Undo reverses
the data.

 Procedural actions: Actions without data change (paragraph reformatting, rotation).

Undo reverses the procedure.

Blind and Explanatory Undo:

 Blind undo: No info about what will be undone.

 Explanatory undo: Shows the action that will be undone (e.g., "Undo Typing 'design'").

Single and Multiple Undo:

 Single undo: Reverses only the last action; simple but limited.

o Limitation: Missed errors cannot be fully recovered if actions happen in

sequence.

 Multiple undo: Reverses several actions in reverse order (LIFO).

o Limitation: Can become complex if some actions should not be undone.

Redo:
  Redo undoes the undo, useful when too many undo steps are taken.

Group Multiple Undo (e.g., Microsoft Word):

 Shows a list of past actions; selecting one undoes all actions up to that point.

 Visual cues indicate how many actions will be undone.

36.5 Other Models for Undo-Like Behavior

 Compare function: Undo/Redo can act as comparison (what-if) tool.

 Category-specific Undo: Undo specific types of actions (e.g., format-undo, drawing tool
undo).

 Deleted Data Buffers: Stores all deleted text/data in a separate buffer for recovery.

 Milestoning: Creates snapshots of the entire document; can revert to any snapshot.

 Freezing: Locks current data from changes; new data can be added.

 Undo-Proof Operations: Some actions cannot be undone (sending email, turning off
computer without saving).

36.6 Rethinking Files and Save

 File systems are confusing to users, especially beginners.

 Users often do not understand memory vs. disk storage.

 Save Changes dialog: Usually confusing, asks users to save changes only when closing,
giving unnecessary fear/confusion.

 Proper saving should allow users to reject changes as they make them, not just at
closing.

Problems with Save As:

 Lets users name a file and choose a directory but often requires prior knowledge of file
system.

 Users often store all files in default directory.

 Renaming files in-use is often blocked, leading to confusion.

36.7 Archiving

 No clear function for making copies; usually done via Save As.

 Users often misunderstand how to create archival copies.

 Mistakes in Save As can overwrite original work, causing data loss.

36.8 Implementation Model vs Mental Model

 Implementation model: The program has copies of files in memory and disk.

 User’s mental model: Users see one document that belongs to them.

 The mismatch causes confusion. Users expect a journal-like behavior, not “two copies.”

36.9 Dispensing with the Implementation Model of the File System

 Hide the file system from users; allow users to work according to their mental model.

 Users can manage documents without thinking about memory/disk copies.

 Benefits: Easier for beginners, simplifies program interface design.

36.10 Designing a Unified File Presentation Model

 Treat documents as single instances, not separate memory and disk copies.

 File system manages storage but is hidden from the user.

 Programs should indicate if a file cannot be changed due to another program using it
(e.g., color coding, symbols).

 Users should understand multiple program instances intuitively (e.g., via Start menu
hints).

Here’s a simplified, structured set of notes for Lecture 37: Behavior & Form – Part V, keeping
all headings and main points for easy understanding and exam revision:

Lecture 37: Behavior & Form – Part V

Learning Goals

After this lecture, you will be able to:

 Discuss Unified Document Management

 Understand considerate and smart software

37.1 Unified Document Management

 Standard file management dialogs (Save As, Save Changes, Open File) are confusing and
sometimes inadequate.

 Unified Document Management organizes documents based on the user’s mental

model instead of the computer’s implementation model.

Key Functions in Unified Document Management

1. Automatically saving the document

o User interface no longer shows separate disk/memory copies.

o Save function occurs automatically during editing and at close.

o Should save after user pauses typing to avoid interruptions.

o Manual save (Ctrl+S) can remain optional.

2. Creating a copy (Snapshot Copy)

o Creates an independent copy of the document.

o Automatically named (e.g., “Copy of Alpha”).

o No dialog boxes; action should be quiet and efficient.

3. Creating a milestone/milestoned copy

o Managed by the program, lightweight versioning.

o Milestone dialog lists copies with time, length, etc.

4. Naming and renaming the document

o Editable directly on the title bar.

5. Placing and repositioning the document

o Program automatically places files in a reasonable location.

 o User can move them via a simplified dialog if desired.

6. Specifying the stored format

o Format (Word, ASCII, Rich Text) is a document property, not tied to save
function.

o Use a Document Properties dialog or Export dialog for rare format changes.

7. Reversing some changes

o Use Undo instead of the file system.

8. Abandoning all changes

o Explicit “Abandon Changes” function.

o Protected by warnings and potentially undoable.

37.2 Creating a Milestone Copy

 Milestones are like snapshots, managed by the program.

 Selecting a milestone automatically activates that version of the document.

 File menu updated for unified model:

o New, Open, Close (auto-save)

o Rename/Move

o Make Snapshot Copy

o Print

o Make Milestone

o Abandon Changes

o Document Properties

o Exit

 File menu could be renamed to Document or named after document type (e.g., Sheet,
Invoice).

37.3 Are Disks and File Systems a Feature?

  From user view: disks aren’t necessary.

 From hardware view: disks are cheaper, non-volatile, portable.

 Disks are slower, less reliable, and add complexity.

 If RAM or solid-state memory were cheaper, disks wouldn’t be needed.

37.4 Time for Change

 Arguments for keeping file-based applications:

1. Existing software is file-based.

2. Users are accustomed to it.

 Neither is a valid reason.

 Users may initially resist change but will adopt better-designed systems.

37.5 Making Software Considerate

 Humans treat interactive software like sentient beings (Clifford Nass & Byron Reeves).

 Considerate software: behaves like a helpful, polite human.

 Avoids frustrating, obstructive, or rude behavior.

Characteristics of Considerate Software

1. Takes an interest

2. Is deferential

3. Is forthcoming

4. Uses common sense

5. Anticipates needs

6. Is conscientious

7. Doesn’t burden users with its problems

8. Keeps users informed

9. Is perceptive
 10. Is self-confident

11. Doesn’t ask too many questions

12. Takes responsibility

13. Knows when to bend the rules

Detailed Characteristics

 Takes an interest: Remembers user preferences and work habits.

 Deferential: Follows user instructions without unnecessary judgment.

 Forthcoming: Provides useful extra info proactively.

 Uses common sense: Puts appropriate functions in appropriate places.

 Anticipates needs: Prepares for likely actions, e.g., preloading links.

 Conscientious: Understands the broader task context.

 Doesn’t burden: Avoids whining, unnecessary messages, interruptions.

 Keeps informed: Provides relevant updates, not trivial ones.

 Perceptive: Notices patterns, predicts future needs.

 Self-confident: Doesn’t second-guess or over-confirm user commands.

 Minimal questioning: Avoids excessive dialogs or unnecessary choices.

 Fails gracefully: Protects user data and recovers from errors.

 Bends rules: Supports flexible, human-like handling of exceptions.

 Takes responsibility: Acts responsibly, coordinating with hardware and other processes.

37.6 Considerate Software Is Possible

 Considerate behavior is not harder to implement than rude software.

 Requires careful design and envisioning human-like interactions.

37.7 Making Software Smarter

 Most programs only act when user commands; CPU idle cycles are wasted.
  Smart software: uses idle time to assist users proactively.

 Users think; computers do repetitive work.

37.8 Putting Idle Cycles to Work

 Programs can predict likely user actions.

 Idle CPU cycles can process tasks (e.g., searching, preloading data).

 Avoids wasting time during modal dialogs or pauses.

37.9 Giving Software a Memory

 Memory = tracking user actions over multiple sessions.

 Software should remember past behavior to reduce repeated tasks.

 Reduces psychological friction and excise (effort spent managing the program).

37.10 Task Coherence

 Users perform tasks in predictable patterns.

 Software can use previous behaviors to anticipate future actions.

 Remembering defaults and past choices simplifies workflow.

37.11 Actions to Remember

 File locations: remembers directories per file type.

 Deduced information: warns of unusual changes (e.g., file size anomaly).

 Multi-session undo: keeps undo history across sessions.

 Past data entries: auto-fills recurring fields, reduces typing errors.

 Foreign application activities: tracks file movement, printing, or sharing.

 Patterns: recognizes repetitive sequences and automates them (e.g., formatting

shortcuts).
Rule of thumb:

If it’s worth the user entering, it’s worth the program remembering.

Here’s a simplified, well-organized set of notes for Lecture 38 and 39 on Behavior & Form
(Human-Computer Interaction), keeping all key headings and explanations in easy-to-
understand wording:

Lecture 38 – Behavior & Form – Part VI

Learning Goal:

 Understand the principles of visual interface design.

38.1 Designing Look and Feel

GUIs vs. Command-Line Interfaces

 Graphical User Interfaces (GUIs) are generally considered easier to use than command-
line interfaces.

 But many GUIs are still frustrating because visual design is not fully understood or
applied.

Visual Art vs. Visual Design

 Visual Art: Focuses on self-expression and aesthetics. Few constraints. Value comes from
uniqueness.

 Visual Design: Focuses on communicating information effectively. Designers consider

user goals and software behavior.

Graphic Design vs. Visual Interface Design

 Graphic Designers: Good at color, typography, layout, and aesthetics; less familiar with
software behavior.

 Visual Interface Designers: Focus on organization, interaction, and communication of

software behavior.

 Visual Information Designers: Focus on content and navigation, especially for websites.

Industrial Design
  Increasingly important for physical interactive devices.

 Must balance visual appeal with ergonomics and user behavior.

38.2 Principles of Visual Interface Design

 Goal: Make interfaces easy and pleasurable to use, leveraging the brain's pattern
recognition.

Key Principles:

1. Avoid visual noise and clutter

o Too many elements or overly decorative designs distract users.

o Use simple shapes, minimal colors, consistent typography.

o Test by removing elements—keep only what communicates clearly.

2. Use contrast and layering

o Dimensional contrast: Raised buttons, indented text fields.

o Tonal contrast: Hue, saturation, or brightness differences to group elements.

o Spatial contrast: Group related elements by position, size, shape, orientation.

o Figure and ground: Ensure focus (figure) stands out against the background
(ground).

o Squint test: Squint to see which elements stand out and group correctly.

Lecture 39 – Behavior & Form – Part VII

Learning Goal:

 Understand principles of visual interface and information design.

39.1 Provide Visual Structure and Flow

 Interfaces have hierarchical structure: elements → groups → panes → screens.

 Organize by position, alignment, color, texture, size, shape.

Alignment and Grids

  Align elements horizontally and vertically.

 Use grids for consistent layout across controls and screens.

 Follow user's logical scanning path (top-to-bottom, left-to-right in Western cultures).

Symmetry and Balance

 Vertical or diagonal symmetry gives visual balance.

 Asymmetrical balance requires careful weight distribution of elements.

Spatial Harmony and White Space

 Maintain proportions and white space to avoid cramped designs.

 Golden ratio can guide pleasing layout, though screen ratios are not always ideal.

Cohesive and Contextual Imagery

 Icons and illustrations should match user expectations and cultural context.

 Use consistent visual language (size, position, style) for all similar elements.

Functional Icons

 Represent both object and action when possible.

 Keep icons simple, consistent, and reusable.

Visualizing Behaviors

 Show the effect of actions visually (e.g., Preview dialogs).

 Combine text and visuals for clarity.

Integrate Style and Function

 Style must complement function, not interfere with usability.

 Branding: Visual and behavioral aspects reinforce brand identity.

39.2 Principles of Visual Information Design

 Goal: Present data clearly, supporting user goals (Edward Tufte).

Seven Principles of Good Information Design

1. Enforce visual comparisons: Compare variables or before/after scenarios visually.

 2. Show causality: Display cause-effect relationships clearly.

3. Show multiple variables: Allow multiple related data points without clutter.

4. Integrate text, graphics, data: Avoid separate legends or keys; combine for clarity.

5. Ensure quality, relevance, integrity: Only show data that supports user goals.

6. Show changes spatially, not just over time: Easier to understand when shown
adjacently.

7. Don't de-quantify data: Show numeric values alongside visualizations.

39.3 Use of Text and Color

Text

 Text is processed visually; use short, easily recognized words.

 Avoid ALL CAPS; use high contrast and readable fonts.

 Keep labels concise; avoid unnecessary reading.

Color

 Enhances attention, navigation, and relationships.

 Avoid:

o Too many colors (confuses users)

o Complementary colors (cause visual vibration)

o Excessive saturation (garish)

o Poor contrast

o Ignoring color blindness (especially red-green)

39.4 Consistency and Standards

 Consistency ensures familiarity and predictability across software modules.

 Benefits: Easier learning, fewer errors, reduced training costs, faster development.

 Risks: Standards only as good as they are; they may limit innovation.
  Guidelines should evolve with technology and user needs.

 When to violate standards: Only if a new approach is clearly better for users.

 Consistency should balance branding, usability, and context-specific goals.

Here’s a concise, easy-to-revise summary of Lecture 42 (Communicating with Users) in a

structured, memory-friendly format:

Lecture 42: Communicating with Users

Learning Goals

After this lecture, you should be able to:

 Discuss how to eliminate error messages.

 Learn how to remove notifiers and confirmation messages.

42.1 Eliminating Errors

Why Error Messages Are Problematic

 Users hate error messages; they want to avoid mistakes, not read about them.

 Traditional error messages reflect programmer thinking, not human needs.

 Many “errors” are program inflexibility, not user mistakes.

 Error messages stop user flow, create frustration, and don’t prevent real mistakes.

Causes

 Early computing treated humans like CPUs.

 Software demands rigid input and reacts with modal dialogs.

 Programs often reject valid-but-unexpected input, e.g., out-of-sequence entries.

Principles

 Users are more important than the program.

 Programs must adapt to human behavior and reconcile confusing input.

  Example: If a user enters a missing customer number, the program could track it and
continue instead of halting.

Making Errors Impossible

 Bounded input: Let users select from valid options instead of typing.

 Smart defaults: Program can auto-fill or remember previous choices.

 Program handles ambiguity: e.g., automatically select common area codes.

 Goal: prevent errors rather than report them.

Error Messages as Last Resort

If you must use an error box:

 Be polite – never blame the user.

 Be illuminating – explain the problem clearly.

 Be helpful – suggest or implement solutions.

 Always protect the user and maintain flow.

42.2 Positive Feedback

 People learn better from positive feedback than negative.

 Users want encouragement, not punishment.

 Computers should reward correct actions or acknowledge them.

 Negative feedback from software feels humiliating and should be minimized.

42.3 – 42.4 Alerts and Confirmations

Alerts

 Alerts notify users of program actions.

 Common issue: stop the proceedings unnecessarily.

 Better: provide feedback in context, visually or through main interface.

 Example: Show status inline, don’t pop up a separate dialog.

Confirmations

 Confirmations ask users for approval when the program is unsure.

 Problems:

o Reflect programmer uncertainty, not user goals.

o Become routine; users ignore them (“The dialog that cried wolf”).

 Proper use: Only appear in truly critical situations.

42.5 Eliminating Confirmations

 Axiom: “Do, don’t ask.” Let the program act confidently.

 Make all actions reversible (Undo, Recycle Bin, suspense directories).

 Provide rich visual feedback to prevent unnecessary errors.

 Example: Instead of confirming a file deletion, use Recycle Bin + visible undo feedback.

42.6 Replacing Dialogs: Rich Modeless Feedback

 Modeless feedback: Always visible, doesn’t interrupt user flow.

 Utilizes high-res displays and audio to provide context and status.

 Reduces need for error, alert, and confirmation dialogs.

42.7 Rich Visual Modeless Feedback (RVMF)

 Rich: Gives detailed information about objects/processes.

 Visual: Uses pixels/graphics to communicate naturally.

 Modeless: No extra dialog box, always displayed in main interface.

 Example: File manager shows object details (size, type, author, modification date, disk
usage pie chart) on selection – eliminates need for separate “Properties” dialog.

✅ Key Takeaways
 1. Prevent errors rather than report them.

2. Use positive feedback instead of punishment.

3. Eliminate alerts and confirmations where possible.

4. Provide rich, modeless visual feedback in the main interface.

5. Treat users as humans, not modules of code.

Here’s a simplified and structured set of notes for Lecture 43: Information Retrieval, keeping all
the main headings and explanations in easy-to-understand language:

Lecture 43: Information Retrieval

Learning Goals

After studying this lecture, you should be able to:

 Discuss how humans and computers communicate.

 Learn how to retrieve information effectively from a computer system.

43.1 Audible Feedback

Purpose of Audible Feedback

 In data-entry jobs, clerks often type without looking at the screen.

 They need feedback to know if their input is correct.

 Feedback can be auditory (sounds) or visual (on-screen messages).

Negative Audible Feedback (User Failure)

 Traditionally, computers beep loudly when something goes wrong.

 This is negative feedback, which announces the user’s error to everyone nearby.

 Problems with negative feedback:

o Alarming and disturbing (like a fire alarm).

o Humans dislike being publicly informed of mistakes.

 o Success is often silent, which is not motivating.

 People prefer silence over annoying sounds for errors.

Positive Audible Feedback (User Success)

 In everyday life, sound often indicates success:

o Door click = door is latched.

o Gas stove hissing and igniting = working properly.

o Keyboard click = key pressed correctly.

 Positive feedback should be subtle and pleasant:

o Keyboard clicks, cheerful tones when input is correct, soft “plonk” for actions like
drag and drop.

 Effectiveness:

o Humans prefer being quietly informed of success.

o Silence can indicate failure without insulting the user.

 Games and modern operating systems (like Mac OS 9) use positive audible feedback
well.

Key idea: Small, consistent sounds can guide users and improve software experience.

43.2 Other Communication with Users

Communicating Identity

1. Program Name

o Displayed in the title bar.

o Also shows on the taskbar’s launch button (may be truncated if too long).

o Should be goal-directed: name + active document for clarity.

2. Program Icon

o 32x32 px icon for desktop; 16x16 px for title bar/taskbar.

o Must be easily recognizable, even in small size.

o Icon design is important for brand identity.

 3. Ancillary Windows

o About/Identity box: identifies the program, authors, version, and publisher.

o Should also explain program scope and functionality.

o Can include contact info or technical support.

4. Splash Screens

o Displayed when a program loads.

o Should appear immediately and disappear automatically or on user action.

o Good for branding and guiding first-time users to tutorials or resources.

o Shareware splash screens can remind users about payment without annoying
them.

Online Help

 Like printed manuals, used as reference for intermediate users.

 Should focus on scope, power, and effect of commands, not just definitions.

 Features of effective online help:

o Index: searchable, contains synonyms, maps to user’s goals.

o Shortcuts: list of commands for quick reference.

o Overview: explains overall effect and purpose of tools.

o Modeless and interactive help: ToolTips, step-by-step instructions integrated

with interface.

Wizards

 Step-by-step dialogs that guide users through tasks.

 Good for rare or complex actions (installation, configuration).

 Often overused for normal tasks; can reduce user agency.

 Better approach: automatic functions that complete tasks, allowing user to adjust later.

Intelligent Agents

 Examples: Clippy in Microsoft Office.

 Animated characters that try to help users.

  Problems:

o Raise user expectations for intelligence.

o Distracting and annoying if they fail to deliver useful help.

43.3 Improving Data Retrieval

Storage and Retrieval Systems

 Storage system: physical method to save items.

 Retrieval system: logical method to find items.

 Problem: digital storage often ignores efficient retrieval methods.

Physical World Retrieval

1. By Location

o Items are found where they are stored (e.g., spoons in kitchen drawer).

o Works for small scale, but not large collections.

2. Indexed Retrieval

o Example: Library using Dewey Decimal system.

o Books have unique numbers; index cards (author, subject, title) link users to
books.

o Retrieval is separate from storage.

o Index helps find items without memorizing storage locations.

Digital World Retrieval

 Computers often lack real retrieval systems; users must remember file names and
locations.

 Three retrieval methods:

1. Positional retrieval: find by storage location.

2. Identity retrieval: find by name.

3. Associative/attribute-based retrieval: find by content or characteristics.

Attribute-Based Retrieval
  Finds documents by content or attributes (e.g., keywords, type, creation date, author).

 Examples of useful attributes:

o Program that created the document.

o Document type (text, table, graphics).

o Last edited, viewed, printed, faxed, or emailed.

o Frequently edited or frequently viewed documents.

 Benefits:

o User doesn’t need to remember file name/location.

o Allows grouping documents by multiple attributes.

o Can automatically track attributes for smarter retrieval.

 Example: Enfish Corporation products create dynamic indices across local systems, LAN,
and the Web.

Key Idea: Computers can provide advanced, human-friendly retrieval if we separate storage
from retrieval and use attribute-based indexing.

✅ Summary:

 Audible feedback: Use positive sounds for success, silence for failure.

 User communication: Name, icon, splash screens, About/Identity box, online help,
wizards, intelligent agents.

 Data retrieval: Move beyond file-name memory; implement attribute-based retrieval for
efficiency and usability.

Here’s a simplified, well-organized version of your notes for Lectures 44–45 in easy wording,
with headings, subheadings, and details preserved:

Lecture 44: Emerging Paradigms

Learning Goals

After this lecture, you will be able to:

 Understand the role of information architecture.

  Understand the importance of accessibility.

1. Metadata

 A website is a collection of interconnected systems with complex dependencies.

 A single link can be part of structure, organization, labeling, navigation, and searching.

 Studying these systems independently is useful, but how they interact is also crucial.

Metadata helps in understanding these systems:

 Traditional definition: "data about data."

 More detailed: Metadata describes data elements, structures, ownership, location,

context, quality, and condition.

 Uses: Improves navigation and retrieval of content like documents, images, videos, and
software.

Example of HTML metadata tag:

<meta name="keywords" content="information architecture, content management, knowledge

management, user experience">

 Modern websites use metadata-driven models: Instead of deciding where to place

content, we describe it and let software manage placement and retrieval.

2. Controlled Vocabularies

 A controlled vocabulary is a defined list of words used to describe concepts consistently.

Types of controlled vocabularies:

1. Synonym rings: List of equivalent terms.

2. Authority files: List of preferred terms.

3. Classification schemes: Terms organized hierarchically (broader/narrower).

4. Associative relationships: Related terms (e.g., “see also”).

Example: Yahoo! uses classification schemes for search categories.

3. Thesauri

 A thesaurus is a controlled vocabulary linking synonyms, antonyms, hierarchical terms,

and related concepts.

 Unlike traditional thesauri, digital thesauri help map many terms to one preferred
concept for easier retrieval.

Three main relationships in a thesaurus:

1. Equivalence: Synonym management.

2. Hierarchical: Categorizing terms into broader/narrower groups.

3. Associative: Connecting related terms.

4. Accessibility

 Accessibility means making systems usable by as many people as possible, especially

people with disabilities.

 Related to Universal Design, but Universal Design often focuses specifically on products
for people with disabilities.

 Disability rights advocate for equal access to social, political, and economic life,
including web access.

Legislation examples:

 UK: Disability Discrimination Act 1995

 US: Americans with Disabilities Act 1990

 Canada (Ontario): Ontarians with Disabilities Act 2001

Web Accessibility

Importance:

 Internet allows people with disabilities to access information, shopping,

communication, and entertainment independently.

 For example:

o Blind users can use screen readers to access news online.

 o Motor-disabled users can use eye-tracking software or adaptive keyboards.

o Deaf users benefit from captioned videos.

Problems:

 Many websites still rely on graphics or mouse-only interactions, making them

inaccessible.

Solutions for Web Accessibility

1. Commitment and Accountability

o Awareness: Developers must understand accessibility.

o Leadership: Organizations must support accessibility.

o Policies & Procedures: Set internal standards and monitor compliance.

2. Training and Technical Support

o Developers need training on accessible web design.

o Technical support can include workshops, forums, consultants, or online

resources like WebAIM.

Conclusion:

 Web accessibility provides freedom and independence for people with disabilities.

 Only with commitment, accountability, training, and support can its full potential be
realized.

Lecture 45: Conclusion – Emerging Interaction Paradigms

Learning Goals

After this lecture, you will be able to:

 Understand new and emerging interaction paradigms.

1. Ubiquitous Computing (Ubicomp)

 Integrates computing into the environment, rather than using distinct devices.
  Also called pervasive computing, calm technology, or things that think.

 Goal: Enable natural and casual interaction with information.

 Origin: Mark Weiser, Xerox PARC, 1988.

 Examples: “Tabs,” “Pads,” “Boards” – small devices embedded in everyday life.

Key Idea:

 Invisible computing that is everywhere, not tied to a personal device.

2. Wearable Computing

 Computers worn on the body, like clothing or accessories.

 Applications: health monitoring, military, behavioral modeling, media development.

 Features:

o Constancy: Always on and interacting with the user.

o Multi-tasking: Works alongside other activities.

History Highlights:

 1961: Edward Thorp & Claude Shannon created a roulette-prediction wearable

computer.

 1981: Steve Mann built backpack-mounted computers for photography.

 1993–2001: Development of augmented-reality wearables and wristwatch computers.

Challenges:

 Micro-management and surveillance concerns.

 Commercial success has been limited.

3. Tangible Bits

 Goal: Combine physical environment (atoms) with digital information (bits).

 Introduces Tangible User Interfaces (TUIs).

Examples:
 1. ClearBoard: Turns walls into active collaboration surfaces.

2. Bricks: Physical handles to manipulate virtual objects.

3. Marble Answering Machine: Uses marbles to represent and play messages.

Key Concepts:

1. Interactive surfaces: All physical surfaces become interfaces.

2. Coupling bits and atoms: Everyday objects interact with digital information.

3. Ambient media: Use sound, light, air, or water for peripheral feedback.

4. Attentive Environments

 Environments that are user- and context-aware.

 Example: IBM BlueEyes – gives computers perception like humans:

o Recognizes user actions, physical and emotional states.

o Can trigger devices based on user attention (e.g., turning on a TV with eye
contact).

Goal:

 Computers become partners, sensing and responding intelligently.

Summary of Emerging Paradigms

Paradigm Key Idea

Ubiquitous Computing Computing integrated invisibly into the environment.

Wearable Computing Computers worn on the body, supporting hands-free interaction.

Tangible Bits Physical objects act as interfaces for digital information.

Attentive Environments Systems aware of user context and respond accordingly.