This file is publicly accessible by URL. Checks A and B are fresh relative to the lesson cases, not secure exams or formal QCAA instruments. Collect an initial response before discussing a model. Reward source-based reasoning, a workable scope and a measurable criterion; do not require exact prose. Spoken responses and labelled diagrams need a captured reason and evidence. Every fictional user need is an analytic inference, not validated user research.
Card cues for Days 1–10
| Card | Defensible analysis and boundary |
|---|---|
| A | Need: find published room times before travel. Evidence: timetable is inside the hub. “Live availability” is unsupported without occupancy data and an updater. A static dated timetable might help if updates can be reliable. |
| B | Reader may ask which entrance is in use and where to start. Ground-floor temporary entrance is confirmed. Other access needs are unknown; testing with people is required before claiming usability or accessibility. |
| C | Input tool code/status → volunteer update → page display → human check. The sheet or page can go stale after a tool moves. Tool code/status matters; visitor names do not. Do not promise live data. |
| D | First version: confirmed workshop times/locations updated weekly. Defer live stock, bookings pending need/process evidence, and any translation until qualified review. Plant-care advice exceeds this brief and needs expert source checking. |
| E | Need: find a prop code before rehearsal. A code filter may be a requirement; a public comment wall is unproven and has no moderation plan. Example planned criterion: in a paper trial, a crew reader locates a named code among ten in under 20 seconds without help. This is a proposed threshold, not a result. |
| F | Static page may help before travel; paper sheet helps at the entrance. Neither supports live headset counts. A name form collects unexplained personal data and creates new handling obligations. Ask if the trial details need advance publication and who updates them. |
| G | Possible personal: a member with poor data misses a change. Social: web-only communication could split access. Economic: fewer prints may save effort, while weekly page maintenance costs time. No measured costs or outcomes. A dual paper/page update is a provisional option; observe reach and update workload. |
| H | Already approved texts and five tags support testing a simple filter. An ML tool would need suitable data, evaluation, maintenance and impact review. An incorrect suggestion could hide a relevant description or increase staff correction work. Neither option has proved useful yet. |
| I | Need: find workshop tent; constraint: no live route update/tracking; missing: coverage at the site; criterion: in a planned local or paper trial, a first-time reader finds the tent on the static map within a stated time, such as 20 seconds. Record that this is a target, not a result. |
| J | A dated, morning-updated code list with search is plausible. Requirement: find a code and see when the list was last updated. Constraint: no all-day stock assurance. Criterion: a reader finds a selected code in a small paper/web prototype under an agreed threshold. Watch whether visitors mistake “listed” for “available now”. |
Check A · Day 5
Need: before travelling or asking at the entrance, a visitor wants reliable information about whether the printed programme may be at the pickup point. Evidence: visitors ask at the entrance and the sign changes only at 10 am and 2 pm. Defensible first version: a page that shows the latest dated/timed twice-daily update and where to ask, with wording such as “Status checked at 2 pm; ask at the entrance for current availability.” Do not label the stock “live”. Limits or unknowns: no count between checks, no evidence of a continuous update process, and no guaranteed availability after the posted time; no visitor names are needed. A student can choose a narrower page that only gives pickup place and scheduled update times.
Example criterion: “In a planned paper-prototype trial, a first-time reader can point to the last update time and pickup point in 20 seconds without prompting.” The reader, task and observable condition are present; the number is a proposed threshold, not reported evidence. Possible social impact: a web-only update may leave visitors without connectivity less informed; retaining an entrance sign may help. Another defensible impact with a specified group and mechanism works.
Next moves: If a learner says “the need is a live tracker”, ask what the visitor wants to decide and where live data would come from. If they say “accurate”, ask how and when accuracy could be observed. If they write “all visitors can use it”, ask for the missing user evidence. If secure, have them compare an entrance-only sign with a dated static page and name the trade-off.
Check B · Day 10
Need: a visitor wants to find a relevant approved description by topic at the offline kiosk. Flow: input = choose one of four topics; process = match that topic to the existing tags of approved descriptions; output = display matching text descriptions; human maintenance = staff edit/check tags weekly. The first version must not upload audio, store names or record search histories because permission for those actions is absent. It should not claim a live external service: the kiosk is offline.
Provisional choice: test the four-topic filter first. The texts already have four tags and no training set, accuracy study or budget for a machine-learning recommender is provided. This is a reasoned proposal, not proof the filter works. Before changing course, ask how real visitors phrase topics or observe whether they can find descriptions in a trial. A student may propose testing both on paper if they explicitly contain scope and evidence requirements.
Example criterion: “In a planned paper/kiosk prototype trial, at least four of five first-time readers find one approved description for a named topic within 30 seconds without a hint.” This is a test specification, not an actual result or QCAA threshold. Possible impact: a fixed tag set may omit a reader's preferred term, causing missed descriptions; a person using a screen reader may need the filter's control and results announced clearly. Neither impact nor accessibility is validated here. Evidence limit: all users and data in the prompt are fictional, and no real trials, training or performance measures are supplied.
Next moves: If the learner recommends ML because it “understands everything”, ask for a training/evaluation source and a failure case. If they propose storing histories, return to the explicit permission boundary. If a criterion is only “easy to use”, ask for reader, task and threshold. If secure, ask what would change the recommendation after an observed failure of the four-topic filter.
Optional swaps · staff cues
Each cue is a plausible starting point, not a verdict on a real project. Ask for the student's evidence and uncertainty.
| Day | Swap 1 cue | Swap 2 cue |
|---|---|---|
| 1 | Need is see pairings before travel; “live” needs an update source | Need is know firing dates in advance; ask how often dates change |
| 2 | Side entrance is confirmed; test if a first-time reader finds it | Foyer desk is confirmed; include non-phone access in questions |
| 3 | Code/status update can lag a stand return | Curator approval is a gate before publication |
| 4 | Weekly hours first; defer live crowds and unchecked translations | Static map first; tracking needs purpose and consent analysis |
| 5 | Planned reader finds a named room among five in an agreed time | Planned volunteer spots a current row among six under an agreed condition |
| 6 | Page helps pre-travel if available; keep on-site paper route | Hours/place may be sufficient; justify any personal-data form |
| 7 | Watch who uses gate notice before removing it | Compare saved copying time with page-maintenance time; no cost result claimed |
| 8 | Existing genre tags favour a filter trial; question false matches | Human labels favour a filter trial; speech search needs error/maintenance evidence |
| 9 | Test Room B findability, keep printed route if connection fails | Test session-time findability; identify who updates monthly data |
| 10 | Dated Monday list, no live stock; watch misunderstanding | Static page can support planning; no location history; test coverage/use |
Assessment limit
These tasks practise selected aspects of Unit 1 Topic 1. They do not establish all eight Unit 1 objectives, students' programming competence, a validated prototype, actual user experience, or the school's required assessment programme. All checks and answers are public.