Task 3: Minor A3 - Simpsons House Frontend Customisation (Student Package)
Assessment details
- Subject: Year 10 Digital Technologies
- Assessment type: SwiftUI frontend customisation practical
- Weighting: 15%
- Raw mark total: 50 marks
- Timing: Term 3, Weeks 1-6
- Final checkpoint: Term 3 Week 6
- Major project connection: This task is a formal frontend milestone for the Simpsons House iOS app.
Purpose
This task assesses your ability to read an existing SwiftUI app, identify safe customisation points, improve the frontend, preserve safe device-control behaviour, test app states and explain your design decisions.
Repository reference: https://github.com/roanvtkc/simpsons-house
Task scenario
You have a working Simpsons House iOS app in Swift Playgrounds. The app controls a smart home model and communicates status to the user. Your job is to improve the frontend so the app is clearer, more usable and more intentional.
This is not a task to rebuild MQTT, hardware or device-control logic. Your assessed focus is the user interface: layout, visual hierarchy, state communication, accessibility, testing and explanation.
Current app structure
| App area | Current role | Safe customisation ideas |
|---|---|---|
ContentView.swift |
Main NavigationStack, ScrollView, and vertical screen layout. |
Adjust spacing, background, section order and overall screen structure. |
HeroSectionView.swift |
Top banner with app icon, title and subtitle. | Change icon, title, subtitle, gradient, badge or card styling. |
ConnectionStatusCard.swift |
Shows connection information and access to logs/info. | Improve status wording, colour, visual hierarchy and help text. |
DeviceControlsSection.swift |
Shows device controls when the app is connected. | Change grid layout, section heading, active badge and spacing. |
DeviceCard.swift |
Reusable cards for light and front door controls. | Style active/offline states, icons, labels, borders, shadows and badges. |
GarageDoorCard.swift |
Garage door control with open and close buttons. | Improve button states, warning colours, icon treatment and layout. |
ConnectionPromptView.swift |
Shown when the app is offline. | Make the offline message clearer and more useful. |
Required submission components
Submit one organised evidence package that includes:
- Frontend audit
- before screenshot
- notes on what works well
- notes on what needs improvement
- Design direction
- at least two possible layout/design ideas
- selected direction and justification
- criteria for what a successful frontend should do
- Customised SwiftUI app evidence
- final screenshots
- changed-code evidence from relevant SwiftUI files
- annotations explaining what you changed and why
- State and safety evidence
- explanation of connected/offline states
- explanation of active/inactive device states where possible
- confirmation that core device-control actions were not broken
- Testing and reflection
- test log with expected vs actual results
- accessibility/readability check
- reflection explaining improvements and remaining limitations
Safe customisation rules
You may customise:
- colours, spacing, fonts and visual hierarchy
- hero section layout and text
- card layout and card styling
- active/offline badges and labels
- icon choices and state indicators
- section order and grouping
- offline help text
- accessibility/readability improvements
Do not change these unless your teacher approves it:
- MQTT topics
- device action function calls
- broker/server connection details
- hardware behaviour
- security-sensitive settings
- code you cannot explain
Minimum technical requirements
Your submission must show:
- at least 3 visible frontend improvements
- at least 2 SwiftUI files changed or intentionally customised
- at least 1 state-aware interface improvement, such as connected/offline or on/off styling
- before and after evidence
- test evidence for at least 4 checks
- a reflection that explains user experience impact
Checkpoints
| Checkpoint | Evidence required | Teacher authentication focus |
|---|---|---|
| Checkpoint 1: Current app audit | before screenshot and frontend notes | confirms student understands the starting app |
| Checkpoint 2: Design directions | two layout/design options and selected direction | confirms planning before implementation |
| Checkpoint 3: Code changes | changed SwiftUI files and annotations | confirms authentic implementation |
| Checkpoint 4: State testing | expected vs actual results for app states | confirms validation and safe behaviour |
| Checkpoint 5: Final package | screenshots, code evidence, test log, reflection | confirms final submission is complete |
Testing log template
| Test number | App state or feature tested | Expected result | Actual result | Fix or note |
|---|---|---|---|---|
| 1 | Offline prompt | |||
| 2 | Connected device controls | |||
| 3 | Active/inactive card styling | |||
| 4 | Readability/accessibility |
Design idea examples
| Direction | What it could involve | What to test |
|---|---|---|
| Dashboard | grouped cards, stronger status area, quick scan layout | user can quickly see house status |
| Themed control panel | Simpsons-inspired palette, icon badges, playful hero section | theme is readable and not distracting |
| Safety-first interface | strong connected/offline indicators, warnings, clear labels | user understands current state before pressing controls |
| Minimal app shell | cleaner spacing, fewer distractions, clearer hierarchy | controls are easier to find and read |
Academic integrity
You may use the provided Simpsons House codebase and teacher examples, but your frontend customisation, annotations, testing log and reflection must be your own. Do not copy another student's design or submit unmodified starter code.
Command terms
- Analyse: identify strengths, issues and improvement opportunities.
- Customise: change the frontend for a clear purpose.
- Preserve: keep safe device-control behaviour working.
- Validate: compare expected and actual behaviour.
- Justify: explain why your design decision improves the app.
Curriculum links
- DS10-1 (WA10DIGDS1): Understand how software helps manage and control data in networked digital systems.
- DI10-2 (WA10DIGDI2): Design and prototype the UX/UI of a digital system.
- DI10-3 (WA10DIGDI3): Represent state or interaction logic clearly.
- DI10-4 (WA10DIGDI4): Validate programs by comparing output against test cases.
- DI10-5 (WA10DIGDI5): Implement, modify and debug programs in a general-purpose programming language.
- DSN10-1 (WA10DIGDTDE1): Design alternatives considering functionality, accessibility, usability and aesthetics.
- PI10-1 (WA10DIGDTPI1): Select, justify, implement and test technologies to produce a prototype.
- EV10-1 (WA10DIGDTEV1): Evaluate the design process and solution against criteria.
- PM10-1 (WA10DIGDTPM1): Manage project work using an agile and organised process.
Marking summary
| Criterion | Marks |
|---|---|
| Frontend audit, design direction and rationale | 10 |
| SwiftUI implementation quality | 10 |
| State-aware interface and safe behaviour | 10 |
| Testing, debugging and accessibility | 10 |
| Evidence package, documentation and reflection | 10 |
| Total | 50 |
Grade guidance
| Raw mark out of 50 | Percentage | Indicative grade |
|---|---|---|
| 37.5-50 | 75.00-100.00% | A |
| 32.5-37 | 65.00-74.99% | B |
| 25-32 | 50.00-64.99% | C |
| 17.5-24.5 | 35.00-49.99% | D |
| 0.5-17 | 0.01-34.99% | E |
| 0 | 0.00% | NA |
Weighted mark conversion
This minor assessment is worth 15% of the course mark.
| Raw mark | Weighted mark |
|---|---|
| 50 | 15.0 |
| 45 | 13.5 |
| 40 | 12.0 |
| 35 | 10.5 |
| 30 | 9.0 |
| 25 | 7.5 |
| 20 | 6.0 |
| 15 | 4.5 |
| 10 | 3.0 |
| 5 | 1.5 |
| 0 | 0.0 |
Submission checklist
- I included a before screenshot.
- I identified frontend strengths and improvement opportunities.
- I included at least two design/layout ideas.
- I selected and justified one design direction.
- I submitted final screenshots.
- I included changed-code evidence from SwiftUI files.
- I explained connected/offline or active/inactive state communication.
- I tested the app and recorded expected vs actual results.
- I checked readability/accessibility.
- I explained how my customisation improves the frontend.
- I did not break the core Simpsons House control actions.