Commit 0648ae

2026-06-08 09:18:19 lisa: Add C05 student wiki pages: design tools, annotation, traceability Six DRAFT pages under /sd/C05 targeting common rubric-boundary errors: - Sketch vs Mock-up (C5-1) — embeds two videos - Data Dictionary — Format is not Type (C5-1) - IPO Charts — Process Means Steps (C5-1) - VCAA Pseudocode — Not Python (C5-1) - The Annotation Verb Ladder (C5-2) - Connect the Dots — design traceability (C5-3) Pages 2-6 have video slots pending teacher selection. Home index reorganised by indicator. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

sd/C05/C05-home.md ..
@@ 6,12 6,24 @@
	---
-	## Key concepts
+	## C5-1 — Design tools
-	Short explainers for the concepts most commonly confused or under-done at each rubric band:
+	Turning the chosen idea into designs another person could build from. Each page below targets a specific point where marks are commonly lost.
	- [C04 → C05 — Choose, then Detail](/sd/C05/C04%20to%20C05%20-%20Choose%20then%20Detail) — how C05 (detail the chosen idea) differs from C04 (choose *which* idea); why C05 means "buildable", not "prettier"
+	- [Sketch vs Mock-up](/sd/C05/Sketch%20vs%20Mock-up) — why a rough sketch is not a mock-up, and what "annotated" actually means (the 3–4 / 5–6 boundary)
+	- [Data Dictionary — Format is not Type](/sd/C05/Data%20Dictionary%20-%20Format%20is%20not%20Type) — the most common data-dictionary error: the Format column is a storage/display pattern, not a synonym for data type
+	- [IPO Charts — Process Means Steps](/sd/C05/IPO%20Charts%20-%20Process%20Means%20Steps) — why the Process column must be numbered algorithm steps, not a label for the output
+	- [VCAA Pseudocode — Not Python](/sd/C05/VCAA%20Pseudocode%20Not%20Python) — write language-independent Structured English (`←`, `<>`, `ENDIF`), not Python-flavoured pseudocode
+
+	## C5-2 — Design principles & UX
+
	- [Design Principles vs UX Characteristics](/sd/C05/Design%20Principles%20vs%20UX%20Characteristics) — why these are two separate lists, why usability appearing in both is a trap, and what the slot-five validation is actually checking
+	- [The Annotation Verb Ladder](/sd/C05/The%20Annotation%20Verb%20Ladder) — climbing Identify → Describe → Document → Explain so your design-log notes don't stall at "identify" in the no-AI Annotation validation
+
+	## C5-3 — Critical & creative thinking
+
+	- [Connect the Dots](/sd/C05/Connect%20the%20Dots) — tracing one feature from mood board → mock-up → data dictionary → IPO chart → pseudocode, and linking each design choice to an SRS requirement
	## Templates and scaffolds
/dev/null .. sd/C05/Connect the Dots.md
@@ 0,0 1,138 @@
+	> **DRAFT** — under teacher review.
+
+	# Connect the Dots — Trace One Feature Through Every Layer
+
+	The Hamilton and Alexandra College · Year 12 · 2026
+
+	Your designs are not arbitrary choices. Every element you put on a screen should connect back to a real user need in your SRS, and every requirement should trace forward to a concrete implementation. This page shows you how to make that thinking visible — which is exactly what C5-3 Step 2 is testing.
+
+	The performance descriptor goes from "outlines connections" (annotations only) up to "documents connections across design ideas, requirements **and** detailed designs." That last level — full traceability — is the 9–10 evidence.
+
+	---
+
+	## 🎬 Watch
+
+	> [!NOTE]
+	> Video coming soon.
+
+	**🎯 Watch for:** how to follow a single design decision all the way from the mood board through to pseudocode, and why stopping at the mock-up is the most common reason students miss the top band.
+
+	---
+
+	## Three Levels of Connection
+
+	Work through these in order. Each level adds a layer on top of the last.
+
+	### Level 1 — Annotate Your Designs
+
+	Add a written reason to every significant element in your sketches and mock-ups.
+
+	A weak annotation describes: *"The button is red."*
+
+	A strong annotation justifies: *"Red delete button — follows platform convention and creates a visual stop-sign effect, reducing accidental deletion for non-technical users."*
+
+	> [!TIP]
+	> The test for a good annotation: can you name the alternative you considered and why you rejected it? If yes, you are justifying. If no, you are only describing.
+
+	Examples from a typical SAT project:
+
+	- *"Dropdown instead of text field → reduces input errors for non-technical users"*
+	- *"Red colour for delete button → follows convention, prevents accidental use"*
+
+	### Level 2 — Link to Your SRS Requirements
+
+	Map each design feature back to a requirement using the **same numbering as your SRS** (FR-1, NFR-3, etc.). This is what separates "I thought it looked good" from "this decision was required."
+
+	| Design Element | Requirement (SRS ref) | Justification |
+	|---|---|---|
+	| Search bar on home screen | FR-3: Users can search by name | Fastest path to core feature |
+	| Password strength indicator | NFR-2: Security | Guides users without explaining rules |
+	| Offline mode indicator | NFR-5: Reliability | Users need to know when data may be stale |
+
+	Build this table for your own project using your own SRS numbers. Every significant design decision should appear in it.
+
+	### Level 3 — Trace Through to Detailed Designs
+
+	This is the level most students miss. Once you have a design element annotated and linked to the SRS, you need to show that the same decision flows forward into your detailed designs: the data dictionary, the IPO chart, and the pseudocode.
+
+	The diagram below shows what that chain looks like for one feature.
+
+	```mermaid
+	flowchart TD
+	A["🖼️ Mood board<br/>Search icon included<br/>in initial style references"]
+	B["📐 Mock-up<br/>Search bar placed top-centre<br/>on home screen (Step 1)"]
+	C["📋 SRS link<br/>FR-3: Users can search<br/>by name or category"]
+	D["🗄️ Data dictionary<br/>field: search_query<br/>type: String<br/>format: max 100 chars"]
+	E["📊 IPO chart<br/>Input: search_query<br/>Process: filter records<br/>Output: filtered list"]
+	F["💻 Pseudocode<br/>IF search_query is not empty THEN<br/> results ← filterBy(search_query)<br/>ENDIF"]
+
+	A --> B
+	B --> C
+	C --> D
+	D --> E
+	E --> F
+	```
+
+	If you can draw this chain for your most important feature, you have Level 3 evidence.
+
+	---
+
+	## The Performance Ladder
+
+	| Level | What your evidence looks like |
+	|---|---|
+	| Basic | Designs exist but no written reasons |
+	| Developing | Some annotations, inconsistent |
+	| Proficient | Annotations on most elements — outlines connections |
+	| Strong | Annotations + SRS table — documents connections to requirements |
+	| Excellent | Annotations + SRS table + full trace to detailed designs — 9–10 band |
+
+	Stopping at the mock-up is the most common failure mode. A well-annotated, well-linked mock-up with no trace into the data dictionary or pseudocode caps you at the Strong level. Full traceability is what lifts the work into the top band.
+
+	---
+
+	## Common Mistakes
+
+	- **Connections implied, not documented** — you know why you made the decision, but you never wrote it down. Markers can only assess what is on the page.
+	- **No SRS reference** — annotations explain the choice but never name the requirement it satisfies. The link between design and requirements is missing.
+	- **Trace stops at the mock-up** — the design looks connected, but there is no data dictionary entry, no IPO chart, no pseudocode that picks up the same feature.
+	- **Wrong SRS numbering** — you use different identifiers in the table than you used in your SRS. Use the exact same labels (FR-3, not "Functional Requirement 3").
+
+	---
+
+	## Quick Checklist
+
+	- [ ] Annotations added to sketches and mock-ups explaining each significant design choice
+	- [ ] Each annotation names an alternative and gives a reason (justifies, not just describes)
+	- [ ] Each significant design element linked to at least one SRS requirement (FR- or NFR- number)
+	- [ ] Traceability table built: Design Element | Requirement (SRS ref) | Justification
+	- [ ] At least one feature traced all the way: mood board → mock-up → data dictionary → IPO chart → pseudocode
+	- [ ] Connections documented in writing, not just implied
+
+	---
+
+	## Check Your Understanding
+
+	1. A student writes "I used a dropdown menu because it looks cleaner." What is missing from this annotation?
+
+	>| **Answer:** The annotation describes a visual preference but does not name an alternative or link to a user need. A stronger version: "Dropdown instead of free-text field → limits input to valid options, reducing input errors for non-technical users (FR-3)." It needs the rejected alternative, the user-facing reason, and the SRS reference.
+
+	2. Your mock-up has a search bar that is fully annotated and linked to FR-3. What additional evidence do you need to reach the top performance band?
+
+	>| **Answer:** You need to trace the feature forward into your detailed designs — a data dictionary entry for the search field, an IPO chart showing search as a process, and pseudocode that implements it. Stopping at the mock-up, even a well-annotated one, caps you below the 9–10 band.
+
+	3. Why must the SRS references in your traceability table use the same numbering as your SRS document?
+
+	>| **Answer:** The marker needs to verify the link exists. If you write "FR-3" in your traceability table, they can turn to FR-3 in your SRS and confirm the connection. Inconsistent labelling breaks the chain and suggests you have not actually mapped the decisions — it looks like the connections are invented rather than documented.
+
+	---
+
+	## See also
+
+	- [Sketch vs Mock-up](/sd/C05/Sketch%20vs%20Mock-up)
+	- [Data Dictionary — Format is not Type](/sd/C05/Data%20Dictionary%20-%20Format%20is%20not%20Type)
+	- [IPO Charts — Process Means Steps](/sd/C05/IPO%20Charts%20-%20Process%20Means%20Steps)
+	- [VCAA Pseudocode — Not Python](/sd/C05/VCAA%20Pseudocode%20Not%20Python)
+	- [Plan B Contingency Table](/sd/C05/Plan%20B%20Contingency%20Table)
+
+	← Back to [C05 Home](/sd/C05/C05-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)
/dev/null .. sd/C05/Data Dictionary - Format is not Type.md
@@ 0,0 1,156 @@
+	> **DRAFT** — under teacher review.
+
+	# Data Dictionary — "Format" Is Not "Type"
+
+	The Hamilton and Alexandra College · Year 12 · 2026
+
+	The single most common data-dictionary error is writing a data **type** in the **Format** column. They are not the same thing. This page explains the difference, shows you what correct entries look like, and maps to the VCAA band descriptors.
+
+	---
+
+	## The core distinction
+
+	**Type** is the *kind* of data — what category it belongs to.
+
+	**Format** is the *storage or display pattern* — the exact shape the value takes.
+
+	These are different answers to different questions:
+
+	| Question | Column | Example answer |
+	|---|---|---|
+	| What kind of data is this? | **Type** | `Integer` |
+	| What does a valid value look like? | **Format** | `999999` (fixed 6 digits) |
+
+	If you write `Integer` in the Format column, you have answered the wrong question. A marker sees that and knows you have conflated two concepts.
+
+	---
+
+	## Format notation key
+
+	The format strings use a small set of symbols — memorise these:
+
+	| Symbol | Meaning |
+	|---|---|
+	| `9` or `N` | One digit (0–9) |
+	| `X` | One uppercase letter |
+	| `x` | One lowercase letter |
+	| `YYYY` | Four-digit year |
+	| `MM` | Two-digit month |
+	| `DD` | Two-digit day |
+	| Separator (`,` `.` `-`) | Literal separator character |
+
+	So `999999` means "exactly six digits". `Xxxxxxxxxxxxxxx` means "one uppercase letter followed by lowercase letters — the number of `x` characters shows the maximum length".
+
+	---
+
+	## Worked example — a complete data dictionary
+
+	These rows come from a client-management system. Read across each row and notice that Type and Format sit in separate columns and say different things.
+
+	| Field | Type | Size | Format | Example |
+	|---|---|---|---|---|
+	| `id` | Integer | 6 | `999999` | 201940 |
+	| `firstName` | Text | 50 | `Xxxxxxxxxxxxxxx` | Jane |
+	| `lastName` | Text | 50 | `Xxxxxxxxxxxxxxx` | Smith |
+	| `DOB` | Date/time | 8 | `YYYY-MM-DD` | 2001-07-19 |
+	| `clubMember` | Boolean | 1 | `true/false` | true |
+	| `memberYears` | Integer | 2 | `NN` | 6 |
+	| `sales` | FloatingPoint | 8 | `NN,NNN.NN` | 12,543.76 |
+
+	Notice what each Format entry tells you that the Type alone does not:
+
+	- `id` is an Integer — but the Format `999999` tells you it is always **6 digits**, not 1 or 2.
+	- `firstName` is Text — but `Xxxxxxxxxxxxxxx` tells you it starts with a **capital** and the rest are lowercase.
+	- `DOB` is Date/time — but `YYYY-MM-DD` fixes it to **ISO format**, not DD/MM/YYYY or MM-DD-YYYY.
+	- `sales` is FloatingPoint — but `NN,NNN.NN` specifies a **thousands separator** and exactly **2 decimal places**.
+
+	---
+
+	## Why Format matters
+
+	Format entries do three jobs in your design documentation:
+
+	- **Data consistency** — every value entered follows the same shape, so comparisons and sorting work correctly.
+	- **Validation** — your software can reject an entry that does not match the pattern (e.g., a date typed as `19-07-01` instead of `2001-07-19`).
+	- **Readability** — another developer reading your data dictionary can reproduce the exact storage structure without guessing.
+
+	A Format column filled with type names (`Integer`, `String`, `Boolean`) gives you none of these benefits — it duplicates the Type column and adds no information.
+
+	---
+
+	## VCAA band levels — what's required at each step
+
+	VCAA defines a data dictionary as specifying variables, arrays, and GUI objects with reference to data types, data structures, and data sources. The level descriptors build upward:
+
+	| Level | What you must include |
+	|---|---|
+	| **Level 3** | Reference to **data types** (Integer, Text, Boolean, Date/time, FloatingPoint) |
+	| **Level 5** | Data types **and data structures** (arrays, records — not just scalar variables) |
+	| **Level 7** | Data types, data structures **and data sources** (where does each value come from — user input, database, calculation?) |
+
+	You cannot skip levels. If your dictionary has no data structures, you cannot claim Level 5 or above.
+
+	---
+
+	## Common mistakes
+
+	### Mistake 1: Format = Type
+
+	> ~~`Format: Integer`~~
+
+	Write the pattern instead: `999999`, `NN`, etc. If you cannot write a pattern, leave a note and revisit — but do not copy the Type column.
+
+	### Mistake 2: Missing data sources at Level 7
+
+	> ~~(no Source column, or Source column left blank for half the rows)~~
+
+	Every field at Level 7 needs a source. "User input", "calculated from `sales` total", "retrieved from customer database" — these are all valid. Blank is not.
+
+	### Mistake 3: Vague sizes
+
+	> ~~`Size: large`~~
+
+	Size must be a number — the number of characters, bytes, or digits the field can hold. If you do not know, look at your data (the longest plausible value) and choose a round number that covers it.
+
+	### Mistake 4: Only scalar variables
+
+	A dictionary that lists only individual variables but no arrays or records cannot score Level 5 or above. If your design uses a list of items or a record structure, include it.
+
+	---
+
+	## 🎬 Watch
+
+	> [!NOTE]
+	> Video coming soon.
+
+	**🎯 Watch for:** how an experienced developer reads a Format string and immediately knows the exact shape of valid data — something the Type alone can never tell you.
+
+	---
+
+	## Check Your Understanding
+
+	1. A student writes `Text` in the Format column for a `lastName` field. What is the mistake, and what should they write instead?
+
+	>| ### Answer
+	>| `Text` is a **type**, not a format. It duplicates the Type column and adds nothing. The correct Format entry is `Xxxxxxxxxxxxxxx` — one uppercase letter followed by lowercase letters, with the number of `x` characters indicating maximum length (e.g. 15 for a 15-character maximum).
+
+	2. Your data dictionary has variables and arrays but no data sources. Which VCAA level can you reach, and which is out of reach?
+
+	>| ### Answer
+	>| You can reach **Level 5** (data types and data structures). **Level 7** is out of reach because it requires data sources as well. Add a Source column and fill it in for every row to unlock Level 7.
+
+	3. What does the Format string `NN,NNN.NN` tell you that the Type `FloatingPoint` does not?
+
+	>| ### Answer
+	>| It tells you the value uses a **thousands separator** (`,`) and is stored to exactly **two decimal places**. `FloatingPoint` alone does not specify either of these — you could have `12543.7` or `12,543.759` and both would be valid floats, but only `12,543.76` matches the format.
+
+	---
+
+	## See also
+
+	- [IPO Charts — Process Means Steps](/sd/C05/IPO%20Charts%20-%20Process%20Means%20Steps)
+	- [Sketch vs Mock-up](/sd/C05/Sketch%20vs%20Mock-up)
+	- [Ryan's Tutorials — Data Dictionary](https://ryanstutorials.net/software-design-and-development/data-dictionary.php) — AU secondary-pitched; shows a "Format for Display" column with N/X notation
+	- [C05 Resources](/sd/Resources/C05-Resources)
+
+	← Back to [C05 Home](/sd/C05/C05-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)
/dev/null .. sd/C05/IPO Charts - Process Means Steps.md
@@ 0,0 1,116 @@
+	> **DRAFT** — under teacher review.
+
+	# IPO Charts — Process Means Steps, Not the Answer
+
+	The Hamilton and Alexandra College · Year 12 · 2026
+
+	An IPO chart has three columns — Input, Process, Output — and you write one chart per functional requirement. The chart connects directly to the rest of your design work: your inputs should already appear in your context diagram or DFD, and your Process column should express the same logic as your pseudocode.
+
+	The trap that caps students at the 5–6 band is writing the Process column as an outcome instead of as steps. This page shows you exactly what that looks like, and how to fix it.
+
+	---
+
+	## The core rule
+
+	> [!TIP]
+	> **Process = the steps your algorithm performs.**
+	> If your Process cell could also be your Output cell, it is wrong.
+
+	The three columns do different jobs:
+
+	- **Input** — the data that enters the functional requirement (trace these from your context diagram / DFD).
+	- **Process** — the numbered steps or operations performed on those inputs. Think of it as pseudocode in plain English.
+	- **Output** — the result produced after the inputs are processed.
+
+	---
+
+	## Wrong vs Right — the same requirement, two ways
+
+	The functional requirement below is: *calculate a sales bonus*.
+
+	| | Input | Process | Output |
+	|---|---|---|---|
+	| **WRONG** | Sales amount, Bonus percentage | Calculate the bonus | Bonus amount |
+	| **RIGHT** | Sales amount, Bonus percentage | 1. Check if sales amount > 10,000. 2. If true, bonus = sales amount × bonus percentage. 3. If false, bonus = 0. | Bonus amount |
+
+	Notice what went wrong in the WRONG row:
+
+	- "Calculate the bonus" is just a restatement of the Output.
+	- It tells you nothing about *how* the calculation works.
+	- A marker cannot award credit for logic that isn't shown.
+
+	The RIGHT row shows the decision and the two branches. That is what earns marks in the upper bands.
+
+	---
+
+	## How the three columns connect to your other design work
+
+	```mermaid
+	flowchart LR
+	CD["Context diagram / DFD<br/>(identifies data flows)"]
+	IPO["IPO chart<br/>(Input · Process · Output)"]
+	PS["Pseudocode<br/>(same logic, formal syntax)"]
+	CD -->|"inputs come from here"| IPO
+	IPO -->|"process mirrors this"| PS
+	```
+
+	Your Process column and your pseudocode should describe the same algorithm. If they contradict each other, one of them is wrong — check both.
+
+	---
+
+	## 🎬 Watch
+
+	> [!NOTE]
+	> Video coming soon.
+
+	**🎯 Watch for:** how a complete Process column maps directly onto a pseudocode IF–THEN–ELSE structure, making it obvious that the Process column is algorithm steps, not a label for the Output.
+
+	---
+
+	## Common mistakes
+
+	### Mistake 1: Process that copies the Output
+
+	> ~~"Work out the bonus amount."~~
+
+	This is just the Output column repeated. Replace it with the numbered decision steps.
+
+	### Mistake 2: Missing the decision branches
+
+	> ~~"1. Calculate bonus using sales × bonus percentage."~~
+
+	This ignores the condition. If there is a threshold or an IF in the logic, both branches must appear in the Process column.
+
+	### Mistake 3: Inputs not traced to diagrams
+
+	Your inputs should be data flows you have already documented in a context diagram or DFD. If an input appears in your IPO chart but nowhere in your diagrams, that is a consistency problem the marker will notice.
+
+	### Mistake 4: One IPO chart for everything
+
+	Write one chart per functional requirement. Each requirement has its own inputs, its own logic and its own output — cramming multiple requirements into one chart makes the Process column vague by design.
+
+	---
+
+	## Check Your Understanding
+
+	1. A student writes Process = "display the total price". What is wrong with this, and how should they fix it?
+
+	>| **Answer:** "Display the total price" is an outcome — it names the output, not the steps. The student should replace it with numbered operations: e.g. 1. Retrieve unit price and quantity. 2. Multiply unit price × quantity to get subtotal. 3. Add GST (subtotal × 0.10). 4. Display the result. The Process column must show the *how*, not the *what*.
+
+	2. Where should the inputs listed in your IPO chart already appear in your design documentation?
+
+	>| **Answer:** In your context diagram or data flow diagram. Inputs are data flows entering the system or a process — they should already be named and labelled in those diagrams. If an input appears in the IPO chart but not in any diagram, there is a consistency error to fix.
+
+	3. You have a functional requirement with a condition: "if the score is 50 or above, the student passes; otherwise they fail." How many branches should appear in your Process column?
+
+	>| **Answer:** Two branches. 1. Check if score ≥ 50. 2. If true, result = "Pass". 3. If false, result = "Fail". Both outcomes of the condition must be shown — leaving out the false branch means the algorithm is incomplete.
+
+	---
+
+	## See also
+
+	- [VCAA Pseudocode — Not Python](/sd/C05/VCAA%20Pseudocode%20Not%20Python)
+	- [Data Dictionary — Format is not Type](/sd/C05/Data%20Dictionary%20-%20Format%20is%20not%20Type)
+	- [Connect the Dots](/sd/C05/Connect%20the%20Dots)
+
+	← Back to [C05 Home](/sd/C05/C05-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)
/dev/null .. sd/C05/Sketch vs Mock-up.md
@@ 0,0 1,133 @@
+	> **DRAFT** — under teacher review.
+
+	# Sketch vs Mock-up — They Are Not the Same Thing
+
+	The Hamilton and Alexandra College · Year 12 · 2026
+
+	A lot of marks are lost at the 3–4 / 5–6 rubric boundary — and almost always for the same reason: submitting a sketch and calling it a mock-up. This page shows exactly what each artefact is, what separates them, and what "annotated" actually means in VCE terms.
+
+	---
+
+	## What each one is
+
+	| | Sketch | Mock-up |
+	|---|---|---|
+	| **Fidelity** | Low — rough, no colour, placeholder labels | High — real colours, real fonts, real content |
+	| **Content** | Shows layout and structure only | Shows the actual interface as it will look |
+	| **Annotation** | Optional notes on layout ideas | Compulsory — every key control labelled with *what it does* AND *why it is placed there* |
+	| **Tool** | Pencil and paper, Excalidraw (lo-fi mode) | Excalidraw with UX library, Figma, Canva |
+	| **VCE purpose** | Brainstorm multiple ideas (C04 design pack) | Evidence for C05 — this is what gets assessed |
+
+	> [!NOTE]
+	> The VCAA study design defines a mock-up as **"an annotated visual representation of the user interface"**. Annotation is part of the definition — not an optional extra. A polished screen design with no annotation labels is still not a valid mock-up.
+
+	---
+
+	## The progression: sketch → mock-up
+
+	Here is one idea progressed through the three stages. Notice how much *more* each step adds.
+
+	```mermaid
+	flowchart LR
+	A["🖊️ Sketch<br/>──────────<br/>Boxes + arrows<br/>No colour<br/>No real text<br/>Shows: where things go"]
+	B["🎨 Mock-up<br/>──────────<br/>Real colours + fonts<br/>Real button labels<br/>Real nav flow<br/>Shows: what it looks like"]
+	C["🏷️ Annotated Mock-up<br/>──────────<br/>Everything in mock-up<br/>PLUS: callout on every<br/>key control → what it<br/>does + why placed there<br/>Shows: design decisions"]
+	A -->|"add fidelity"| B
+	B -->|"add annotation"| C
+	style C fill:#d4edda,stroke:#28a745
+	```
+
+	The highlighted box is what C05 requires. You need both the high-fidelity visual **and** the annotations — neither alone is enough.
+
+	---
+
+	## 🎬 Watch
+
+	### Video 1 — Wireframe vs Mockup vs Prototype
+
+	**🎯 Watch for:** The video uses three tiers — wireframe, mockup, prototype. Map them onto our two VCE artefacts: their **wireframe ≈ our sketch** (lo-fi, layout only); their **mockup ≈ our annotated mock-up** (hi-fi, visual detail). Their **prototype** (clickable, working interactions) is **beyond what C05 asks for** — do not build a prototype for this task.
+
+	{{Video|src=https://www.youtube.com/watch?v=lJipkxgMSF0}}
+
+	**✍️ While you watch:** As the video describes each tier, write one sentence in your own words matching it to either "our sketch" or "our annotated mock-up" — or "beyond C05" for the prototype tier. This mapping question comes up in the annotation validation.
+
+	---
+
+	### Video 2 — Excalidraw in practice
+
+	**🎯 Watch for:** How Excalidraw's built-in wireframing libraries (Lo-Fi Wireframing Kit, Basic UX elements) let you drop in pre-built components — buttons, input fields, nav bars — so you spend time on design decisions, not drawing rectangles.
+
+	{{Video|src=https://www.youtube.com/watch?v=CjKpg_N42Cw}}
+
+	**✍️ While you watch:** Identify at least two components in the video that appear in your own interface (e.g. a text input, a navigation bar). Note the library name they come from — you may need to cite your tool in your design log.
+
+	---
+
+	## For Level 9: completeness matters
+
+	At Level 9 the mock-ups must represent the **complete interface** — not just the main screen.
+
+	That means:
+
+	- Every screen the user can reach is mocked up (login, dashboard, data entry, confirmation, error states).
+	- Navigation between screens is shown — either as a flow diagram or as directional arrows on the mock-up set.
+	- Each screen has its own annotations.
+
+	A single polished home-screen mock-up is a Level 5–6 submission, regardless of how good it looks.
+
+	---
+
+	## Common mistakes
+
+	### Mistake 1: Submitting a sketch and labelling it a mock-up
+
+	> ~~A pencil layout with grey boxes showing "button here" and "logo here"~~
+
+	A sketch shows structure. A mock-up shows what the interface actually looks like. If it has no colour, no real fonts, and no real content, it is a sketch.
+
+	### Mistake 2: A polished screen with no annotations
+
+	> ~~A beautiful Figma screen with no callout labels~~
+
+	Without annotations, it is a screen design, not a VCE mock-up. Annotations must explain what each key control does and why it is placed where it is.
+
+	### Mistake 3: Only the main screen
+
+	> ~~One annotated home screen, nothing else~~
+
+	C05 requires the complete interface. If your solution has four screens, you need four annotated mock-ups — plus navigation between them shown somewhere.
+
+	### Mistake 4: Annotations that only describe
+
+	> ~~"This is a blue Submit button."~~
+
+	A description states what is there. An annotation explains the design decision — what the control does for the user and why it is positioned and styled that way.
+
+	---
+
+	## Check Your Understanding
+
+	1. What two things make a high-fidelity screen design a valid VCE mock-up?
+
+	>| A valid VCE mock-up must (1) be **high-fidelity** — real colours, fonts, and content — and (2) be **annotated** — every key control labelled with what it does and why it is placed there. Both are required; either alone is insufficient.
+
+	2. A student submits a single beautifully annotated home screen. They are targeting Level 9. What is missing?
+
+	>| Level 9 requires the **complete interface** — all screens the user can reach, plus navigation between them shown. A single screen, however detailed, caps the submission at around Level 5–6.
+
+	3. What is the difference between an annotation that describes and one that justifies?
+
+	>| A describing annotation says what is there: "There is a blue Submit button." A justifying annotation says what it does for the user and why the design decision was made: "The Submit button uses a high-contrast blue to draw attention as the primary action, placed bottom-right to match the natural reading flow and reduce error submissions."
+
+	---
+
+	## See also
+
+	- [Annotated Mock-up in Excalidraw](/sd/C05/Annotated%20Mock-up%20in%20Excalidraw)
+	- [C04 → C05 — Choose, then Detail](/sd/C05/C04%20to%20C05%20-%20Choose%20then%20Detail)
+	- [Data Dictionary — Format is not Type](/sd/C05/Data%20Dictionary%20-%20Format%20is%20not%20Type)
+	- [Design Principles vs UX Characteristics](/sd/C05/Design%20Principles%20vs%20UX%20Characteristics)
+
+	---
+
+	← Back to [C05 Home](/sd/C05/C05-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)
/dev/null .. sd/C05/The Annotation Verb Ladder.md
@@ 0,0 1,134 @@
+	> **DRAFT** — under teacher review.
+
+	# The Annotation Verb Ladder — Identify → Describe → Document → Explain
+
+	The Hamilton and Alexandra College · Year 12 · 2026
+
+	The C5-2 Annotation validation is a 30-minute written test under **no AI, no internet** conditions. You bring in only your printed design log / photo journal. You receive a 6-slot sheet, and each slot is locked to a rubric band by a single verb. The problem most students don't see coming: they write confident-sounding notes that secretly stay at "identify" level — and only discover this during the timed session, when it is too late.
+
+	This page teaches the ladder by showing you one concrete design-log entry rewritten up all four rungs.
+
+	---
+
+	## The four rungs
+
+	```mermaid
+	flowchart BT
+	A["**Identify** · band 3–4<br/>Name the principle/characteristic"] --> B["**Describe** · band 5–6<br/>Say HOW it is applied — appearance AND functionality"]
+	B --> C["**Document** · band 7–8<br/>Cite specific journal evidence:<br/>user-test note · constraint · iteration"]
+	C --> D["**Explain** · band 9–10<br/>Argue what breaks if you remove the choice,<br/>or the trade-off between two principles/characteristics"]
+	```
+
+	Each rung adds something the rung below does not have. You cannot skip rungs.
+
+	---
+
+	## The same entry, rewritten four times
+
+	The example entry: **high contrast on the login button** (a real design-log entry — Design Log #3, 15 April).
+
+	| Rung | Band | The annotation |
+	|------|------|----------------|
+	| **Identify** | 3–4 | "I applied contrast to my login button." |
+	| **Describe** | 5–6 | "I applied contrast (design principle) by changing the login button from light grey to a high-visibility blue (#1A73E8 on white). This affects appearance by making the button stand out from surrounding text, and affects functionality by directing user attention to the primary action on the screen." |
+	| **Document** | 7–8 | "I applied contrast as above. In Design Log #3 (15 April), I recorded that during a user test, two of three testers initially clicked the wrong element; after increasing the colour contrast ratio to 4.8:1, all three testers clicked the correct button on the first attempt. The iteration from grey to blue was a direct response to that test note." |
+	| **Explain** | 9–10 | "I applied contrast as above (Design Log #3, 15 April). If I removed the high-contrast blue and returned to grey, the button would lose its affordance (UX characteristic) — users would not perceive it as the primary interactive element, increasing error rate and reducing usability (UX characteristic). There is a trade-off: high contrast dominates the visual field, potentially reducing balance (design principle) on the page. I accepted that trade-off because the primary function of the login screen is a single action, so guiding attention outweighs distributing it evenly." |
+
+	Notice what each rung adds:
+
+	- **Describe** adds: *how* (appearance + functionality), not just the name.
+	- **Document** adds: a *specific journal entry reference* with a user-test result or iteration.
+	- **Explain** adds: *what would break* without the choice, or a *named trade-off* between two principles/characteristics.
+
+	---
+
+	## The 6-slot structure
+
+	Your annotation sheet has six slots with fixed verb targets:
+
+	| Slot | What you write | Target band |
+	|------|----------------|-------------|
+	| 1 | **Identify** a design principle visible in one journal entry | 3–4 |
+	| 2 | **Identify** a UX characteristic in a different entry | 3–4 |
+	| 3 | **Describe** how a principle is applied — appearance AND functionality | 5–6 |
+	| 4 | **Document** how a UX characteristic is applied — citing journal evidence | 7–8 |
+	| 5 | **Explain** how a *selected* principle AND UX characteristic combine in one design choice | 9–10 |
+	| 6 | **Explain** a tension between two principles or characteristics, and the trade-off you accepted | 9–10 |
+
+	> [!TIP]
+	> **Slot 5 is the hardest.** It requires ONE annotation entry that names a design principle (from the list of 7) AND a UX characteristic (from the list of 4) and shows how they interact. Writing two design principles will leave the slot empty regardless of the quality of your writing. See [Design Principles vs UX Characteristics](/sd/C05/Design%20Principles%20vs%20UX%20Characteristics).
+
+	---
+
+	## Build the design log NOW
+
+	Aim for **4 or more entries** before the validation. Every entry is a potential annotation source — you can only cite entries that exist in your printed journal.
+
+	Each entry should include:
+
+	- The date and which design artefact you were working on
+	- The design principle or UX characteristic you applied (use the exact study-design name)
+	- A before/after description (sketch, screenshot, or written description)
+	- Any user-test result, feedback, or constraint that influenced the decision
+
+	> [!NOTE]
+	> An entry that documents an iteration — something you changed in response to feedback — is more valuable than an entry describing a first-pass decision, because it gives you the "document" rung automatically.
+
+	---
+
+	## Common mistakes
+
+	### Mistake 1: Notes that stay at "identify"
+
+	> ~~"I applied contrast to make my design look better."~~
+
+	This names the principle but says nothing about how it was applied (appearance or functionality), cites no journal entry, and gives no reason. It scores at most band 4.
+
+	### Mistake 2: No journal entry reference
+
+	> ~~"I increased contrast throughout my design."~~
+
+	Generic statements without a specific entry reference do not score under the document or explain bands. The marker needs to know *which* entry — date, entry number, or both.
+
+	### Mistake 3: Describing the feature instead of the principle
+
+	> ~~"I made the button blue."~~
+
+	This describes a visual feature. An annotation must name the *principle or characteristic* the feature demonstrates and explain *why* that principle is at work — not just what the feature looks like.
+
+	---
+
+	## 🎬 Watch
+
+	> [!NOTE]
+	> Video coming soon.
+
+	**🎯 Watch for:** how the same design-log entry sounds completely different at each rung — and what one specific addition takes you from "identify" to "explain" in your annotation.
+
+	---
+
+	## Check Your Understanding
+
+	1. A student writes: "I used alignment to organise my navigation bar." Which rung is this on, and what is the single most important thing they need to add to reach the next rung?
+
+	>| **Rung: Identify (band 3–4).** To reach Describe (band 5–6), they need to say HOW alignment was applied — what changed in the appearance of the navigation bar, and how that affects functionality (e.g. "users can scan menu items in a single left-to-right sweep").
+
+	2. Slot 5 requires both a design principle and a UX characteristic in one annotation. Write the names of all 7 design principles and all 4 UX characteristics from memory — then check yourself against [Design Principles vs UX Characteristics](/sd/C05/Design%20Principles%20vs%20UX%20Characteristics).
+
+	>| **Design principles (7):** alignment, balance, contrast, space, text formatting, usability, navigation. **UX characteristics (4):** affordance, interoperability, security, usability. Note that **usability appears in both lists** — they mean different things in each context.
+
+	3. You are writing a Slot 6 "explain" annotation about a trade-off between contrast and balance. What two things must your annotation include that a "describe" annotation would not?
+
+	>| (1) A **specific journal entry reference** showing where the decision was made (date / entry number / artefact). (2) An argument about the **trade-off** — what you gain from high contrast, what you sacrifice in balance, and why you chose to accept that cost. Simply saying both principles are present is not enough.
+
+	---
+
+	## See also
+
+	- [Design Principles vs UX Characteristics](/sd/C05/Design%20Principles%20vs%20UX%20Characteristics)
+	- [Connect the Dots](/sd/C05/Connect%20the%20Dots)
+	- [C05 Resources](/sd/Resources/C05-Resources)
+
+	---
+
+	← Back to [C05 Home](/sd/C05/C05-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)
/dev/null .. sd/C05/VCAA Pseudocode Not Python.md
@@ 0,0 1,165 @@
+	> **DRAFT** — under teacher review.
+
+	# VCAA Pseudocode — Write Structured English, Not Python
+
+	The Hamilton and Alexandra College · Year 12 · 2026
+
+	If you can already code in Python, pseudocode feels like a step backwards — why write `count ← 5` when `count = 5` is right there? The answer: VCAA assessors are checking whether you can express an algorithm clearly and independently of any language. Python-flavoured pseudocode loses marks. This page maps every construct you need.
+
+	---
+
+	## 🎬 Watch
+
+	> [!NOTE]
+	> Video coming soon.
+
+	**🎯 Watch for:** how to translate a working Python method into clean VCAA pseudocode, keeping the logic identical while swapping Python syntax for language-independent Structured English.
+
+	---
+
+	## The two rules that actually matter
+
+	Before the big table, pin these two rules — they matter more than any single symbol:
+
+	1. **Be consistent.** If you open a block with `BEGIN`, close it with `END` throughout. If you use `WHILE … ENDWHILE`, don't switch to `WHILE … END_WHILE` two lines later.
+
+	2. **Write at a clear high level.** You do not need to encode every trivial detail. "Load `data.csv` into an array of records" is perfectly acceptable pseudocode when it is self-explanatory.
+
+	---
+
+	## Pseudocode ↔ Python comparison
+
+	### Program structure and basics
+
+	| Pseudocode | Python | Notes |
+	|---|---|---|
+	| `START` … `STOP` or `BEGIN` … `END` | *(not required)* | Brackets a whole program or subprogram. Pick one style and stick to it. |
+	| `count ← 5` | `count = 5` | Assignment uses a **left-arrow `←`**, not `=` or `:=`. |
+	| `// comment` or `# comment` | `# comment` | Comments work in pseudocode too — use them. |
+
+	### Selection
+
+	| Pseudocode | Python | Notes |
+	|---|---|---|
+	| `IF condition THEN`<br>&nbsp;&nbsp;`action_1`<br>`ELSE`<br>&nbsp;&nbsp;`action_2`<br>`ENDIF` | `if condition:`<br>&nbsp;&nbsp;`action_1`<br>`else:`<br>&nbsp;&nbsp;`action_2` | Must close with `ENDIF`. Chained: use `ELSE IF … THEN`. |
+	| `CASE OF variable`<br>&nbsp;&nbsp;`value1: action_1`<br>&nbsp;&nbsp;`value2 TO value3: action_2`<br>&nbsp;&nbsp;`OTHERWISE action_3`<br>`ENDCASE` | `if variable == value1:`<br>&nbsp;&nbsp;`action_1`<br>`elif value2 <= variable <= value3:`<br>&nbsp;&nbsp;`action_2`<br>`else:`<br>&nbsp;&nbsp;`action_3` | CASE has no direct Python equivalent; use it when there are many branches. |
+
+	### Iteration
+
+	| Pseudocode | Python | Notes |
+	|---|---|---|
+	| `WHILE condition DO`<br>&nbsp;&nbsp;`action_1`<br>`ENDWHILE` | `while condition:`<br>&nbsp;&nbsp;`action_1` | Pre-test loop. Must close with `ENDWHILE`. |
+	| `REPEAT`<br>&nbsp;&nbsp;`action_1`<br>`UNTIL condition` | `while True:`<br>&nbsp;&nbsp;`action_1`<br>&nbsp;&nbsp;`if condition: break` | Post-test loop — body always runs at least once. |
+	| `FOR count ← a TO b STEP 1`<br>&nbsp;&nbsp;`action_1`<br>`ENDFOR` | `for count in range(a, b+1, 1):`<br>&nbsp;&nbsp;`action_1` | Count-controlled. Must close with `ENDFOR`. |
+	| `FOREACH item IN seq`<br>&nbsp;&nbsp;`action_1`<br>`NEXT item` | `for item in seq:`<br>&nbsp;&nbsp;`action_1` | Iterates over a sequence. Close with `NEXT item`. |
+
+	### Operators
+
+	| Pseudocode | Python | Notes |
+	|---|---|---|
+	| `=` | `==` | **Equality test** in pseudocode is `=`, not `==`. |
+	| `<>` | `!=` | **Not-equals** in pseudocode is `<>`. Never use `!=` in pseudocode. |
+	| `>, <, <=, >=` | `>, <, <=, >=` | Same symbols in both. |
+	| `AND, OR, NOT` | `and, or, not` | Uppercase in pseudocode. |
+	| `+, -, *, /, ^` | `+, -, *, /, **` | Pseudocode uses `^` for exponentiation; Python uses `**`. |
+	| `MOD` or `%` | `%` | Integer remainder. |
+	| `DIV` | `//` | Integer division. |
+
+	### Subprograms (methods / functions / procedures)
+
+	| Pseudocode | Python | Notes |
+	|---|---|---|
+	| `BEGIN fun(arg1, arg2)`<br>&nbsp;&nbsp;`action_1`<br>&nbsp;&nbsp;`RETURN expression`<br>`END` | `def fun(arg1, arg2):`<br>&nbsp;&nbsp;`action_1`<br>&nbsp;&nbsp;`return expression` | `BEGIN`/`END` bracket the subprogram. `RETURN` ends a function; omit it for a procedure. |
+
+	---
+
+	## Worked example — a method inside a class
+
+	This is the Level-9 OOP pseudocode skill. You are writing a method, not a standalone program, so you use `BEGIN`/`END` rather than `START`/`STOP`.
+
+	**Scenario:** a `ScoreTracker` class has a method `is_passing` that returns whether a student's average score meets a threshold.
+
+	```
+	BEGIN is_passing(scores, threshold)
+	total ← 0
+	FOREACH score IN scores
+	total ← total + score
+	NEXT score
+	average ← total / length(scores)
+	IF average >= threshold THEN
+	RETURN True
+	ELSE
+	RETURN False
+	ENDIF
+	END
+	```
+
+	Notice:
+	- Assignment is `←` throughout — never `=` or `==`.
+	- Not-equals would be `<>` if needed (e.g. `IF count <> 0 THEN`).
+	- `FOREACH … NEXT item` closes the loop.
+	- `IF … THEN … ELSE … ENDIF` closes the selection.
+	- Indentation is consistent.
+
+	> [!TIP]
+	> You do not need to write out every getter and setter in full. If a step is clear — "retrieve the current user record from the database" — that single line is enough. Save detailed pseudocode for the logic that actually matters in your design.
+
+	---
+
+	## Common mistakes
+
+	### Mistake 1 — Using `=` or `==` for assignment
+
+	> ~~`count = 5`~~ or ~~`count == 5`~~
+
+	Correct: `count ← 5`. The left-arrow shows data flowing *into* the variable. Using `=` is Python; using `==` is a comparison, not assignment.
+
+	### Mistake 2 — Using `!=` for not-equals
+
+	> ~~`IF count != 0 THEN`~~
+
+	Correct: `IF count <> 0 THEN`. The `!=` operator belongs only in Python code.
+
+	### Mistake 3 — Python-only constructs leaking in
+
+	> ~~`for item in list:`~~ or ~~`elif`~~ or ~~`print(x)`~~
+
+	Use `FOREACH item IN list … NEXT item`, `ELSE IF … THEN`, and `OUTPUT x` instead.
+
+	### Mistake 4 — Forgetting closing keywords
+
+	Every block that opens must close. Missing `ENDIF`, `ENDWHILE`, `ENDFOR`, or `ENDCASE` is a consistency error. Markers notice immediately.
+
+	### Mistake 5 — Inconsistent block keywords
+
+	> ~~Opening with `BEGIN` but closing with `STOP`~~
+
+	Pick `BEGIN`/`END` or `START`/`STOP` and use it everywhere in the same document.
+
+	---
+
+	## Check Your Understanding
+
+	1. Rewrite this Python line as valid VCAA pseudocode: `score = score + 1`
+
+	>| **Answer:** `score ← score + 1` — assignment uses `←`, not `=`.
+
+	2. A classmate writes `IF x != 0 THEN … ENDIF`. Name the mistake and write the corrected line.
+
+	>| **Answer:** `!=` is Python syntax, not pseudocode. Correct: `IF x <> 0 THEN … ENDIF`. The not-equals operator in VCAA pseudocode is always `<>`.
+
+	3. You have a `WHILE` loop and an `IF` statement nested inside it. List the two closing keywords you need and the order they must appear.
+
+	>| **Answer:** `ENDIF` closes the inner `IF` first, then `ENDWHILE` closes the outer loop. Inner blocks always close before outer blocks.
+
+	---
+
+	## See also
+
+	- [IPO Charts — Process Means Steps](/sd/C05/IPO%20Charts%20-%20Process%20Means%20Steps)
+	- [Connect the Dots](/sd/C05/Connect%20the%20Dots)
+	- [C05 Resources](/sd/Resources/C05-Resources)
+
+	---
+
+	← Back to [C05 Home](/sd/C05/C05-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)