Commit f049b1

2026-04-27 20:07:44 lisa: Add C02 Data Collection Methods wiki page Covers the four VCE SD methods: interview, survey, observation, reports/existing data. Adapted from EDUCBA overview with project- specific framing (file-naming, save formats, common pitfalls per method, recommended 3-method mix). Uses OtterWiki folded blocks for real-world examples and fancy info/ success/warning panels for callouts. Comparison table at top serves as the dual-coding visual anchor.

/dev/null .. sd/C02/Data Collection Methods.md
@@ 0,0 1,189 @@
+	> **DRAFT** — under teacher review.
+
+	# Data Collection Methods
+
+	Hamilton College · Year 12 · 2026
+
+	For C02 you must collect data using **at least three different methods** and explain *why* you chose each one. This page covers the four methods VCE Software Development recognises — what they are, when each works best, and how to use them in your SAT project.
+
+	The C2-1 rubric rewards **specific, justified method choice** at the 9–10 band. Picking interviews "because everyone uses interviews" will not score. Picking interviews "because I needed depth on three users' workflows that a survey couldn't capture" will.
+
+	---
+
+	## The four methods at a glance
+
+	| Method | Best for | Data type | Time cost | Save raw to |
+	|---|---|---|---|---|
+	| **Interview** | Depth, motivations, follow-up questions | Mostly qualitative | High (per person) | `C02/raw/interview-<name>-<date>.md` |
+	| **Survey** | Breadth, countable patterns across many people | Mostly quantitative + some qualitative | Low (per response) | `C02/raw/survey-results.csv` |
+	| **Observation** | What people *actually* do (vs what they say) | Mostly qualitative | Medium | `C02/raw/observation-<context>-<date>.md` |
+	| **Reports / existing data** | Context, constraints, technical environment | Mixed | Low | `C02/raw/report-<topic>.md` |
+
+	A strong project usually combines: **1 method for depth** (interview), **1 for breadth** (survey), and **1 for grounding** (observation or reports).
+
+	---
+
+	## 1. Interview
+
+	::: info
+	**What it is** — A structured or semi-structured conversation between you and one person (your client, a target user, an expert). You ask predetermined questions but follow up on interesting answers.
+	:::
+
+	**When to use it.** When you need *depth* — understanding why someone does something, what frustrates them, or what they would value most. Best for the first 1–3 stakeholders, before you know enough to design a survey.
+
+	**Strengths**
+
+	- Lets you ask follow-up questions and clarify confusing answers
+	- Captures rich detail and personal context a survey can't reach
+	- Adapts on the fly — you can probe an unexpected response
+
+	**Weaknesses**
+
+	- Slow — a serious interview is 20–45 minutes per person, plus prep and writing it up
+	- Your wording, body language, and tone affect what people say (interviewer bias)
+	- Hard to keep two interviews directly comparable
+
+	**In your project**
+
+	- Capture **key points and direct quotes**, not full transcripts. A short bulleted note file is enough.
+	- After each interview, write a 2-line summary of "biggest insight" and "thing I didn't expect" — these often become your strongest poster content.
+	- Plan **2–4 interviews**, not 10. The C2-1 rubric rewards depth of analysis, not interview count.
+
+	>| ### Real-world example
+	>| A 2022 study interviewed 30 families about children's screen time during COVID-19 lockdowns. They found that excessive screen time reduced interest in face-to-face interaction and caused family conflicts — a finding a survey alone could not have surfaced because parents had to think aloud and revise their first answers.
+
+	---
+
+	## 2. Survey
+
+	::: info
+	**What it is** — A short questionnaire (Google Forms, Microsoft Forms, etc.) sent to many people. Mostly **closed-ended** questions (multiple choice, scales) so you can count results; one or two **open-ended** for texture.
+	:::
+
+	**When to use it.** When you need *breadth* — to test whether something you heard in an interview is widely true, or to count preferences across a target user group.
+
+	**Strengths**
+
+	- Cheap and fast per response
+	- Reaches many people who would never agree to an interview
+	- Quantitative results are easy to summarise on a poster ("78% of Year 9 students said…")
+
+	**Weaknesses**
+
+	- People misread or skip questions you thought were clear (ambiguity = bias)
+	- You only get answers to the questions you asked — no follow-up
+	- Self-report; what people *say* they do is often not what they *actually* do
+
+	**In your project**
+
+	- Keep it short. **5–10 questions**, max 5 minutes to complete, or response rate collapses.
+	- Mix **closed** (countable) with **1–2 open** (texture) questions.
+	- Pilot it with 1–2 people before sending widely — you will catch ambiguous wording every time.
+	- Save the **raw CSV export**, not just a summary screenshot.
+
+	>| ### Real-world example
+	>| A 2023 England-based study surveyed 7,797 school children about COVID-19 impacts. They found 1.8% of younger and 6.9% of older children experienced persistent problems including anxiety, difficulty concentrating, and sensory loss — a scale of evidence interviews alone could never produce.
+
+	---
+
+	## 3. Observation
+
+	::: info
+	**What it is** — Watching real people do the task your software will eventually replace or support. You note what works, what frustrates them, and what they do that contradicts what they told you in interview.
+	:::
+
+	**When to use it.** When you want to know what people *do*, not just what they *say* they do — these are usually different. Especially powerful for workflows people perform so often they no longer notice the friction.
+
+	**Strengths**
+
+	- Captures real behaviour in context
+	- Catches workarounds and unspoken steps people forget to mention
+	- Cuts through self-report bias — what you observe happened
+
+	**Weaknesses**
+
+	- Time-consuming; you usually need multiple sessions to spot patterns
+	- People behave differently when watched (observer effect)
+	- You can only see external behaviour, not motivation
+
+	**In your project**
+
+	- **Participant** observation: you join in (e.g. shadow a teacher running the canteen). **Non-participant**: you watch from the side (e.g. observe a library queue at lunch).
+	- Note **specific moments**, not generalities. "*At 12:47, a student gave up looking for the book and asked the librarian instead*" beats "*it took a while to find books*".
+	- Cross-check observations against interview claims. Contradictions are gold for your poster's *"explaining why"* section.
+
+	>| ### Real-world example
+	>| Michigan State University chemists (2023) observed ionic liquids and discovered a piezoelectric material existing in liquid form — previously known only in solids. They were not testing for it; they were watching, and noticed something the established theory said wasn't possible.
+
+	---
+
+	## 4. Reports / existing data
+
+	::: info
+	**What it is** — Information that already exists, collected by someone else for some other purpose. Includes school policy documents, government statistics, industry reports, your school's IT device list, academic studies, and existing software documentation.
+	:::
+
+	**When to use it.** When you need to ground your project in **real constraints** — the technical environment, the regulatory environment, or population statistics that would take you months to collect yourself.
+
+	**Strengths**
+
+	- Free or cheap; you didn't pay to collect it
+	- Often covers populations or time spans you could never access yourself
+	- Excellent for the rubric's *constraints* and *technical environment* categories — areas students often have nothing to say about
+
+	**Weaknesses**
+
+	- Was collected for someone else's question, not yours — may not exactly fit
+	- Quality varies; you must judge the source
+	- Can be out of date (especially anything pre-2023)
+
+	**In your project**
+
+	- For *technical environment*: your school's IT device list, browser stats, OS versions, network policy.
+	- For *constraints*: school policy on student data, age-appropriate design code (UK ICO), accessibility guidelines (WCAG).
+	- For *user characteristics*: ABS census data, government education statistics, your school's enrolment breakdown.
+	- Always save **the source link plus your own one-paragraph summary** — examiners want to see you read it, not just cited it.
+
+	**Sub-types worth knowing**
+
+	- **Literature review** — academic papers, textbooks, OER like this wiki
+	- **Government databases** — ABS, Department of Education, ACMA
+	- **Industry reports** — Statista, Gartner, vendor white papers
+	- **Web data** — public APIs, open datasets (data.gov.au)
+
+	---
+
+	## Choosing your mix
+
+	For C02 you must use **three or more** methods. A balanced mix:
+
+	::: success
+	**Recommended pattern**
+
+	- **1 interview** with your client or primary user → depth, motivation, must-have features
+	- **1 survey** of target users → breadth, validation of interview claims
+	- **1 observation OR report set** → grounding in real behaviour or constraints
+	:::
+
+	::: warning
+	**Avoid these traps**
+
+	- **Three interviews and nothing else** — no breadth, no constraints, no observed behaviour. Caps at 6–7 on C2-1.
+	- **A survey of one class with no interviews** — no depth, no rationale beyond "*it was easy*".
+	- **Reports only** — you've researched the area but haven't engaged with real users; the rubric's *user characteristics* section will be weak.
+	:::
+
+	The 9–10 descriptor expects you to **explain why each method was chosen for its specific job** — what data it would yield that the others wouldn't. Practise that explanation out loud before your C2-1 station defence.
+
+	---
+
+	## See also
+
+	- [Essential Terms](Essential%20Terms.md) — definitions of *qualitative*, *quantitative*, *open-ended*, *close-ended*, and the four method names
+	- [Explaining vs Describing Your Data Collection](Explaining%20vs%20Describing%20Your%20Data%20Collection.md) — the verb ladder the C2-1 rubric uses to separate 7 from 9–10
+	- [Context Diagram](Context%20Diagram.md) — once you have data, the entities you discovered go on this diagram
+	- [What Is an Entity](What%20Is%20an%20Entity.md) — your data sources may themselves be entities (e.g. a payment gateway, an LMS)
+
+	---
+
+	*Adapted for VCE SD students from EDUCBA's [Data Collection Methods](https://www.educba.com/data-collection-methods/) overview, with project-specific framing for C02.*