Blame
|
1 | <!-- Generated from applied-computing-au vic/unit3-4/sat/C08-2026/C08-Reference-Godot by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. --> |
||||||
| 2 | # Modifying Designs with Annotations |
|||||||
| 3 | ||||||||
| 4 | *C8-2's first rungs: identify the design that needed changing (1–2) and annotate the before/after (3–4). The **why** is what lifts you higher — capture it as you go.* |
|||||||
| 5 | ||||||||
| 6 | ## Ideation vs representation |
|||||||
| 7 | ||||||||
| 8 | Brainstorming, mind maps, mood boards and sketches **generate** ideas. Mock-ups, data dictionaries, object descriptions, IPO charts and pseudocode **document** designs. C8-2 modifications happen to the representation methods — the five below. |
|||||||
| 9 | ||||||||
| 10 | ## The five design representations you can modify |
|||||||
| 11 | ||||||||
| 12 | | Method | Purpose | A modification looks like | |
|||||||
| 13 | |---|---|---| |
|||||||
| 14 | | **Mock-up / annotated diagram** | how the interface looks and works | layout, controls or navigation changed, with notes | |
|||||||
| 15 | | **Data dictionary** | every data element: name, type, size, scope, purpose | a variable's type, range or purpose revised | |
|||||||
| 16 | | **Object description** | classes/objects: properties, methods, relationships | a property added, a method split, a relationship changed | |
|||||||
| 17 | | **IPO chart** | input → process → output for one function | a step added or an output redefined | |
|||||||
| 18 | | **Pseudocode** | the planned logic | a branch or loop restructured before recoding | |
|||||||
| 19 | ||||||||
| 20 | ## What a good annotation shows |
|||||||
| 21 | ||||||||
| 22 | - The **before** and the **after**, side by side — a screenshot of only the final version is not an annotation; the change has to be visible. |
|||||||
| 23 | - **What** changed, marked directly on the design (arrow, highlight, callout). |
|||||||
| 24 | - **Why** — pinned to the specific test result or feedback that triggered it. |
|||||||
| 25 | ||||||||
| 26 | ## The change log |
|||||||
| 27 | ||||||||
| 28 | Track modifications as they happen: |
|||||||
| 29 | ||||||||
| 30 | | Date | Design element changed | Reason for change | Impact on project | Evidence | |
|||||||
| 31 | |---|---|---|---|---| |
|||||||
| 32 | | 15/03 | Added right panel for grades | Better UX — see individual results | Improved usability, clearer data display | Screenshot in OneNote | |
|||||||
| 33 | ||||||||
| 34 | **Evidence examples:** git commit, OneNote page, photo of a sketch, annotated screenshot, design file save. |
|||||||
| 35 | ||||||||
| 36 | ## The causal chain (where 7–8 lives) |
|||||||
| 37 | ||||||||
| 38 | > test result → design problem → modification → improvement |
|||||||
| 39 | ||||||||
| 40 | In the viva you will be asked for the **specific test result** that drove each change, and it has to line up with your git history, dev log and C8-1 testing table. "I changed the layout" is 3–4; "TC004 showed the update silently failing, which meant the form design hid the save state, so I added the confirmation panel — now the failure is impossible to miss" is 7–8. |
|||||||
