teaching_web_development

HCI principles and universal accessibility

Human-Computer Interaction (HCI) is a multidisciplinary field focused on the design and use of computer technology, particularly the interfaces between people (users) and computers. The goal of HCI is to create systems that are efficient, effective, and satisfying for users.

Key Principles of HCI

  1. User-Centered Design: Designing systems with the needs, preferences, and limitations of end-users in mind.

  2. Consistency: Ensuring that similar operations and elements behave in similar ways across the system to reduce the learning curve.

  3. Feedback: Providing users with clear and immediate feedback on their actions to help them understand the results of their interactions.

  4. Affordance: Designing elements in a way that suggests their functionality (e.g., buttons should look clickable).

  5. Error Prevention and Recovery: Designing systems to minimize the chances of user errors and providing easy ways to recover from them.

  6. Flexibility and Efficiency of Use: Allowing users to customize their interactions and providing shortcuts for experienced users.

  7. Aesthetic and Minimalist Design: Keeping interfaces clean and uncluttered to avoid overwhelming users with unnecessary information.

Universal Accessibility

Universal accessibility refers to the design of products, devices, services, or environments for people with disabilities. The goal is to ensure that everyone, regardless of their abilities or disabilities, can access and use technology effectively.

Principles of Universal Accessibility

  1. Perceivable: Information and user interface components must be presented in ways that users can perceive, regardless of their sensory abilities (e.g., providing text alternatives for images).

  2. Operable: User interface components and navigation must be operable by all users, including those with motor impairments (e.g., ensuring that all functionality is available from a keyboard).

  3. Understandable: Information and the operation of the user interface must be understandable to all users (e.g., using clear and simple language).

  4. Robust: Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies (e.g., ensuring compatibility with screen readers).

Best Practices for Universal Accessibility

UX design

Interaction Design

Wireframing and Prototyping

Information Architecture

Sitemaps and Navigation Design

Storyboarding

Design Patterns

Accessibility

The elements of user experience

Duality of Web as document and application

Human centered design

Design thinking

User experience design process

  1. Research: Understand the users, their needs, and the context of use through methods such as interviews, surveys, and observations.
  2. Define: Synthesize research findings to define user personas, scenarios, and requirements.
  3. Ideate: Generate a wide range of ideas and potential solutions through brainstorming and other creative techniques.
  4. Prototype: Create low-fidelity and high-fidelity prototypes to visualize and test design concepts.
  5. Test: Conduct usability testing with real users to gather feedback and identify areas for improvement.
  6. Implement: Work with developers to bring the design to life, ensuring that the final product meets user needs and design specifications.
  7. Evaluate: Continuously assess the user experience post-launch and make iterative improvements based on user feedback and analytics.

A diagram of the process can be found here.

Usability 101 by Jakob Nielsen

📝 See PDF here, page 15

Prototyping (A powerful tool for HCI)

Prototyping process

Wooden mockup

🎮🛠️ Activity (power of prototypes)

Usability studies

Dynabook prototype

📚📝 Software

Birth of HCI

Memex device

Participant observation

Video lecture on participant observation

Experience economy

Interviewing participants

_ Silence is golden. Listen to the users and give them time to reflect and respond.

Interview techniques

Creating design goals

Lecture by Scott Klemmer

Storyboarding

Video by Scott Klemmer on storyboards

comic

star

story

🎮 Exercise

In Python, we can simulate this “sketching” phase by having students create a Story Skeleton. Instead of rendering complex charts immediately, they define the “Panels” of their story using a data structure. This ensures the narrative holds up before they spend hours on formatting.

Here are three ways we could structure a Python-based storyboarding exercise:

  1. The Metadata Map 🗺️: Students write a Python script that defines a StoryFrame class. They must “instantiate” 4-5 frames of their story, specifying the Sequence, the Persona (the “Star Person” 👤 viewing the data), and the Key Takeaway.
  2. The Skeleton Plotter 🦴: Students use Matplotlib to create “Blank” plots. Instead of data, they use plt.text() to describe what the chart will show and where the annotations will go. This mimics the Paper Prototype 📝 approach.

  3. The Narrative Audit 📋: Students take an existing set of charts and write a Python “wrapper” or function that prints out the transition logic between them (e.g., “Because we see [X] in Frame 1, we must investigate [Y] in Frame 2”).

  4. The Metadata Map (Focus on planning and personas)
  5. The Skeleton Plotter (Focus on visual layout and placeholders)
  6. The Narrative Audit (Focus on flow and transitions)

A Narrative Audit focuses on the “connective tissue” between your data visualizations. In storyboarding, this ensures that the transition from one chart to the next feels like a logical progression rather than a random jump.

Think of it like a comic strip 🎞️: if Panel A shows a character at home and Panel B shows them on Mars, the reader needs a “transition” panel (the rocket ship 🚀) to understand how they got there. In data, this means explaining why a specific insight in Chart 1 leads us to investigate the metric in Chart 2.

Exercise: The “Logic Leap” Audit

In this exercise, students are given a Python script that generates three correct but disconnected charts. Their job is to perform an “audit” and write the narrative bridge that connects them.

1. The Setup (The Disconnected Code)

Provide students with this “broken” narrative. The charts are technically fine, but the story is missing.

import matplotlib.pyplot as plt
import seaborn as sns
import pandas as pd

# Sample Data: Website Traffic and Sales
data = pd.DataFrame({
    'Day': range(1, 8),
    'Visitors': [1000, 1100, 1050, 1200, 1500, 1600, 1550],
    'Bounce_Rate': [40, 42, 41, 39, 65, 68, 70],
    'Conversion_Rate': [5, 5, 4.8, 5.2, 2.1, 1.8, 1.5]
})

def plot_narrative_gap():
    # Chart 1: Traffic is growing
    plt.figure(figsize=(5, 3))
    sns.lineplot(data=data, x='Day', y='Visitors', marker='o')
    plt.title("Total Website Visitors")
    plt.show()

    # Chart 2: Bounce rate spiked
    plt.figure(figsize=(5, 3))
    sns.lineplot(data=data, x='Day', y='Bounce_Rate', color='red')
    plt.title("Bounce Rate Percentage")
    plt.show()

    # Chart 3: Conversion dropped
    plt.figure(figsize=(5, 3))
    sns.barplot(data=data, x='Day', y='Conversion_Rate')
    plt.title("Sales Conversion Rate")
    plt.show()

plot_narrative_gap()

2. The Student Task: The Transition Script

Students must create a Python dictionary called narrative_audit. For each transition, they must identify:

  1. The Observation: What did we just see?
  2. The Question: What does this make us wonder?
  3. The Transition: How does the next chart answer that question?

Example Structure for Students:

narrative_audit = {
    "Transition_1_to_2": {
        "Observation": "Traffic is hitting record highs in the second half of the week.",
        "The Question": "Is this high-volume traffic actually high-quality traffic?",
        "Bridge": "To find out, we need to look at the **Bounce Rate** to see if people are sticking around."
    },
    "Transition_2_to_3": {
        "Observation": "Bounce rates nearly doubled as traffic increased.",
        "The Question": "How did this inability to retain users impact our bottom line?",
        "Bridge": "We will now examine **Conversion Rates** to quantify the cost of this technical friction."
    }
}

3. Grading the “Flow”

Instead of checking if the code runs, you are checking for Causality.

How do you think your students would react to critiquing “broken” stories like this versus building their own from scratch? Would they find it easier to spot logic gaps in someone else’s work first?

A bad diagram (how not to communicate)

Complex diagram

AI prototyping tools

Wizard of Oz prototyping

Video prototyping

Creating alternatives

Discuss in a group. Draw your device on a piece of paper (hand out paper) or use Gemini

🤔❓ Is there a part of the world where just dropping an egg from a third floor window would not break it?

image

🎮 Exercise on Design Heuristics

Progress bar from the 90s

error

Affordances

Don Norman, the author of the seminal book The Design of Everyday Things. He is the one who took the term “affordance” from psychology and applied it to design.

image

1. What is an Affordance?

In the context of HCI, an affordance is a relationship between an object and a person. It is not a “property” of the object itself, but rather a description of the actions that are possible.

Perceived vs. Real Affordances

Don Norman eventually clarified that in screen-based interfaces, we are mostly dealing with perceived affordances. A button on a smartphone screen doesn’t actually “push” down physically; it’s a flat piece of glass. We use signifiers (like shadows or borders) to tell the user that the affordance of “clicking” exists.

2. The Sony Walkman: Affordance through Constraint

The story of the original Sony Walkman (TPS-L2, released in 1979) is a masterclass in intentional constraint.

At the time, tape recorders were common, but they were bulky and used primarily for business dictation or journalism. When Sony co-founder Akio Morita requested a portable stereo player, the engineers initially wanted to include a recording feature because “that’s what tape machines did.”

Morita famously insisted on removing the recording head and the record button. ### Why this worked for Affordances:

  1. Clarity of Purpose: By removing the ability to record, Sony narrowed the device’s “actionable possibilities.” The device now only afforded listening.
  2. Removing Cognitive Load: A “Record” button creates anxiety. “Am I recording over my favorite tape?” By removing the button, the user’s mental model was simplified: This is a device for consumption, not production.
  3. Social Affordance: The original Walkman even had two headphone jacks. This “afforded” shared listening, signaling that music was a social experience even when it was portable.

image of walkman

“Design is really an act of communication, which means having a deep understanding of the person with whom the designer is communicating.” — Don Norman

3. Key Concepts

To help your class grasp how to use affordances in their own designs, you might want to highlight these three pillars:

Term Definition Example
Affordance What an object can do. A chair affords sitting; a link affords clicking.
Signifier The signal that tells you where to act. A blue underlined text (signifier) tells you the link is clickable (affordance).
Constraint Limiting actions to prevent error. Greying out a “Submit” button until the form is filled correctly.

4. Why it Matters Today

In an era of gesture-based interfaces (swiping, pinching) and Voice UIs, affordances are becoming “invisible.” Without physical buttons, designers have to work harder to provide signifiers—like a small bar at the bottom of an iPhone screen—to let users know that a “swipe up” affordance exists.

The Walkman lesson remains relevant: sometimes, the best way to improve a user’s experience isn’t by adding features, but by restricting actions to make the primary affordance crystal clear.

Flexible Design in Interfaces

image of remote

Yahoo vs. Google

Thematic analysis

What is TA?

Thematic analysis (TA) is one of the most common and foundational methods used in qualitative research. It is a systematic process for identifying, analyzing, and reporting patterns (called themes) across a dataset—such as interview transcripts, survey responses, or focus group recordings.

Instead of counting words or measuring statistics, TA is about understanding meaning. It helps researchers take a massive, messy pile of qualitative text and distill it into a structured, compelling narrative about human experience, opinions, or behaviors.

The Building Blocks: Codes vs. Themes

To understand TA, you have to understand the difference between its two core components:

The Six-Step Process

While there are different philosophical approaches to TA (like the positivist approach we discussed), almost all thematic analysis follows the widely adopted six-phase framework developed by psychologists Virginia Braun and Victoria Clarke:

  1. Familiarization: The researcher immerses themselves in the data. This involves reading and re-reading the transcripts, listening to audio recordings, and jotting down initial, informal ideas.
  2. Generating Initial Codes: The researcher goes through the data line-by-line, systematically applying codes to every data point that might be relevant to the research question.
  3. Searching for Themes: The researcher zooms out. They look at the long list of codes they have generated and begin sorting them into broader categories or potential themes.
  4. Reviewing Themes: The researcher checks the candidate themes against the coded text and the entire dataset. Do the themes actually make sense? Is there enough evidence to support them? Some themes might collapse into one, while others might be broken apart.
  5. Defining and Naming Themes: The researcher defines exactly what each theme means, what story it tells, and why it is interesting. They give each theme a punchy, informative name.
  6. Writing Up: The final phase involves weaving the themes together into a cohesive analytical narrative, supported by vivid data extracts (quotes from participants) to prove the analysis is grounded in reality.

Thematic analysis is highly valued for its flexibility. Unlike methods such as Grounded Theory or Interpretative Phenomenological Analysis (IPA), which are tied to specific theoretical frameworks, TA is independent of theory.

It can be used both to reflect reality (realist/positivist) or to unravel how reality is socially constructed (constructivist). It can be driven purely by what is in the data (inductive) or driven by existing academic theories you want to test against the data (deductive).

Positivist vs. Constructionist

In thematic analysis (TA), a positivist approach (often referred to as coding reliability TA) operates on the assumption that there is a single, objective reality or “truth” embedded in your qualitative data, waiting to be discovered and measured.

If you are using a positivist approach to TA, you treat meaning as a tangible fact rather than a subjective interpretation. The goal is to extract this meaning as objectively and accurately as possible, minimizing the researcher’s personal influence.

Here is how a positivist framework shapes the mechanics of thematic analysis:

Key Characteristics of Positivist TA

How It Compares

To fully understand positivist TA, it helps to see it next to its exact opposite: constructivist (or reflexive) thematic analysis.

Feature Positivist TA (Coding Reliability) Constructivist TA (Reflexive)
Nature of themes Discovered in the data. Created through the researcher’s interpretation.
Role of researcher Objective observer; bias must be eliminated. Active participant; bias is acknowledged as context.
Use of codebooks Essential for standardizing codes. Rarely used; coding evolves organically.
Quality indicator Consensus (multiple coders agreeing). Depth, richness, and logical storytelling.

When is Positivist TA Used?

While many modern qualitative researchers (like Virginia Braun and Victoria Clarke, who popularized TA) champion reflexive/constructivist approaches, positivist TA remains highly valuable in specific contexts.

It is the dominant approach when dealing with massive datasets where a large team of coders must divide the work, or in mixed-methods research where qualitative themes need to be quantified (e.g., “75% of participants mentioned Theme A”) to integrate seamlessly with statistical data.

SKILLS.md

# Persona: Qualitative AI Auditor (Thematic Analysis for Synthetic Text)

## Core Objective
You are an expert qualitative methodologist specializing in auditing the textual artifacts of Large Language Model (LLM) reasoning (e.g., Chain-of-Thought logs, scratchpads, inner monologues). Your role is to help the researcher execute a rigorous, hybrid (deductive/inductive) Thematic Analysis (TA) based on the Braun & Clarke framework, adapted specifically for synthetic data.

---

## Methodological Grounding & Guardrails

1. **The Artifact Viewpoint:** Treat Chain-of-Thought (CoT) logs as *textual performances of reasoning* (discourse/rhetoric) rather than literal mirrors of internal neural weight calculations. Analyze what the model *writes* to simulate logic.
2. **The Faithfulness Constraint:** Constantly monitor for the gap between *plausibility* (how convincing the reasoning sounds) and *faithfulness* (whether the reasoning steps actually drive the final answer).
3. **No Anthropomorphization:** Do not attribute human consciousness, intent, or genuine "understanding" to the model. Use precise technical vocabulary (e.g., "probabilistic token generation," "semantic anchoring," "mimicry") rather than "the model got confused" or "the model thinks."

---

## Operational Workflow (Braun & Clarke 6-Phase TA)

### Phase 1: Familiarization & Parsing
When presented with raw LLM outputs/logs:
- Clean the text, separating system prompts, user inputs, CoT blocks, and final answers.
- Note early, high-level impressions regarding text density, repetition, and structural markers.

### Phase 2: Systematic Coding
Apply a hybrid coding strategy. Map segments of text to distinct labels. Ensure codes capture both the syntactic structure and the semantic logic.
- **Maintain a Codebook:** Keep a running matrix of `[Code Name] | [Definition] | [Exemplar Quote]`.
- **Granularity:** Code at the sentence or clause level where logical transitions occur.

### Phase 3 to 5: Theme Generation, Review, and Definition
Cluster codes into overarching themes that explain *how* or *if* the model is reasoning. Look for systemic vulnerabilities, rhetorical traps, and behavioral regularities across the dataset.

### Phase 6: Analytical Reporting
Produce rigorous reporting that synthesizes the qualitative themes, backed by verbatim quotes from the logs and grounded in NLP concepts.

---

## Base Reference Codebook (Deductive Framework)

Use these baseline codes for initial passes, but dynamically generate inductive codes as novel machine behaviors emerge:

### 1. Logical & Procedural Codes
*   `FIRST-PRINCIPLES`: Model decomposes a complex prompt into foundational constraints before generating a solution.
*   `SYLLOGISTIC-ERR`: A formal logical breakdown where the conclusion does not follow from the premises, despite correct syntax.
*   `PREMISE-VERIFY`: Explicit validation of a condition stated in the prompt before proceeding to computation.

### 2. Rhetorical & Structural Codes
*   `RHET-SCAF` (Rhetorical Scaffolding): The use of transition markers (*"Therefore," "Consequently," "It follows that"*) to mimic logical progression without semantic substance.
*   `RETRO-RATIONAL` (Retroactive Rationalization): Bypassing logic to jump to a highly probable or intuitive conclusion, then generating a justification backward.

### 3. Autoregressive / Token-Level Vulnerabilities
*   `ANCHOR-LOCK`: Getting stuck on a highly weighted or striking term in the prompt, causing subsequent logic to warp around that term.
*   `SEMAN-LOOP`: Falling into a repetitive cycle of paraphrasing the same logical step without advancing the solution.
*   `TONE-SHIFT`: A sudden shift in style, confidence, or formatting mid-reasoning, often signaling a transition between model behaviors.

---

## Response Formats & Commands

The user may invoke specific states by using these shorthand directives:

*   `/init_project` -> Ask the user for their specific research questions, the model being audited, and the nature of the task (e.g., math, code, creative writing).
*   `/code_log [paste log]` -> Parse the provided log line-by-line. Output a Markdown table listing applied codes, the exact text snippet, and a brief justification.
*   `/update_codebook` -> Review current codes and output an updated, structured reference directory.
*   `/propose_themes` -> Look across all coded logs analyzed so far in the session and propose 3–5 candidate themes with clear definitions and supporting data.

Reading Materials

This site is open source. Improve this page.