Falcons — Assignment 4: Interface Prototype Design

Contents

• Deliverables at a Glance

1. Team Organization and Progress
2. Project Division of Labor
3. Interface Prototype Design
4. Difficulties and Solutions
5. Team Collaboration
6. Team Photo and Feelings
7. References

Deliverables at a Glance

1. Team Organization and Progress

1.1 Organization

Falcons has 13 members and one team leader, organised into six functional groups: Project Management, Product Requirements, Frontend Development, Backend Development, Algorithm, and Testing. For this assignment, the product and frontend groups built the interactive prototype, the backend and algorithm groups supplied the business rules shown in the screens, and the testing group ran the walkthrough.

1.2 Roles

1.3 Progress Schedule

The assignment follows a one-week cycle; specific dates are adjusted according to the course arrangement.

2. Project Division of Labor

All 13 members share an equal estimated contribution for this assignment — about 7.7% each, totaling 100%. The ratio is an estimate and will be adjusted by the team performance assessment.

3. Interface Prototype Design

3.1 Tool and Links

• Design tool: MoDao (墨刀) — a specialised prototyping tool. Share link: Sports Buddy prototype
• Interactive demo: the 12 screens are embedded in the MoDao project as interactive HTML pages, so the flow can be opened and demonstrated directly during the defence.
• Prototype pages: assignment4/prototype

3.2 Design Concepts

The prototype follows the product vision: "buddy up, easily, well and precisely".

1. Buddy up, easily — the home page supports one-sentence search (e.g. "Basketball at Qishan campus tonight, beginners OK") and returns ranked activities, so finding a game takes seconds.
2. Buddy up, well — check-in, mutual reviews and a credit score make reliable people stand out and reduce no-shows.
3. Buddy up, precisely — matching considers sport, campus/time, skill level, distance and the organiser's reliability, and explains why an activity matches.

Visual design principles:

• Mobile-first: a 390 × 844 phone frame is the primary canvas; the layout also adapts to 320 px, 768 px and 1280 px without horizontal overflow.
• Warm, energetic palette: orange as the action colour, dark text on a light background, with clear hierarchy.
• Low cognitive load: one primary action per screen, clear status (full / joined / checked in), and explicit feedback after every action.

3.3 Design Process

1. Requirement mapping — the 12 screens were derived from the SRS (M1–M5) and the 41 use cases.
2. Information architecture — login → discovery → activity list → activity detail (participant / organizer) → create → check-in → manage → my activities → me → profile → reviews.
3. Screen production — each screen was produced with the assigned owner, then reviewed against the requirement it serves.
4. Interaction wiring — buttons, tabs, forms, modals and page transitions were linked into a continuous flow.
5. Business-rule states — full capacity, credit score below 60, late cancellation, check-in code/location and permission differences were added as visible states.
6. Review and regression — the testing group walked through the flow against the SRS; defects were fixed and re-verified.

3.4 Interface Overview (12 screens)

Main flow: Login → Discovery → Activity list → Detail → Sign up → Check-in → Review.

3.5 Requirements Alignment

3.6 Prototype Checklist

• All 12 screens reachable and clickable
• Main flow works end to end
• Business-rule states visible (capacity, credit, cancellation, check-in)
• Responsive at 320 / 768 / 1280 px without horizontal overflow
• Consistent colour, typography and components
• Real-browser verification (108 checks) and end-to-end flow (21 steps)
• Non-posed team discussion photo
• Public prototype link (MoDao)

4. Difficulties and Solutions

4.1 Difficulty 1 — Screen layout collapsed because of a CSS class mismatch

• Difficulty: in the interactive prototype, the class name used in CSS (.proto-screen) differed from the class name in the HTML (screen). The display: none rule therefore never applied, and all 12 screens were laid out at the same time.
• Attempts and result: the team inspected the computed layout, traced the selector mismatch and unified the class name to .screen. Solved.
• Gain: we learned to verify rendered layout (not just source code) and to keep a single naming convention between design and implementation.

4.2 Difficulty 2 — The mobile top bar covered the screens

• Difficulty: the media query that hides the top bar on phones was written before the base .proto-chrome { display: flex } rule, so it was overridden; at 390 px the bar occupied about 130 px.
• Attempts and result: the rule order was corrected and the media query moved to the end of the stylesheet; the bar now hides correctly. Solved.
• Gain: CSS cascade order matters; responsive rules must be verified at real device widths.

4.3 Difficulty 3 — A fixed floating button appeared on every screen

• Difficulty: the floating action button used position: fixed, so it floated above all 12 screens instead of only its own screen.
• Attempts and result: the button was scoped under .screen.is-active, so it is only visible on the active screen. Solved.
• Gain: global positioning must be scoped when multiple screens share one page.

4.4 Difficulty 4 — Feedback messages and navigation parameters were lost

• Difficulty: success/error messages were cleared by the router before being rendered, so login feedback never appeared. In the web app, the login token was not persisted (causing a 401 on the next request) and route parameters were dropped (requests went to /activities/NaN).
• Attempts and result: a flashPending flag was introduced so messages survive navigation; the token is now written to storage on login; route parsing was corrected to pass activityId / userId. Solved and verified in a real browser.
• Gain: state that must survive navigation needs an explicit lifecycle, and route parameters need dedicated tests.

4.5 Difficulty 5 — Small-screen overflow of the class diagram

• Difficulty: the class-diagram page overflowed horizontally by 12 px at 390 px because a grid column had a fixed minimum of 360 px.
• Attempts and result: the generator was changed to minmax(min(360px, 100%), 1fr) and a max-width media query was added, then the diagram was regenerated; the SVG diff was zero. Solved.
• Gain: layout constraints must be tested at the narrowest supported width.

4.6 Gains

• Built an automated regression suite: 188 Node checks and 108 real-browser checks (via the DevTools Protocol and headless Edge), covering titles, rendering, undefined/NaN, overflow and console errors.
• Added an end-to-end user journey test (21 steps: login → discover → sign up → check in → review).
• Learned to do root-cause analysis instead of patching symptoms, and to keep the prototype, the web app and the share package generated from one source.

5. Team Collaboration

• Repository and folders: all deliverables live in the shared GitHub repository under fixed folders (assignment4/prototype, assignment4/slides, assignment4/evidence, assignment4/testing).
• Work log: every change is recorded in WORKLOG.md (date, member, type, files, summary, assignment), which makes contributions traceable.
• Task allocation: each screen and each document has one owner and one reviewer; the lead tracks the critical path.
• Communication: daily coordination in the team chat group; issues that affect several groups are decided in the group.
• Review and integration: the testing group walked through the prototype against the SRS, produced a defect list, and the owners fixed and re-verified each item; the final share package was regenerated from the same source.

6. Team Photo and Feelings

6.1 Team Photo

Figure 15. team reviewing the prototype flow together.

Figure 16. Non-posed photo of the team discussing the prototype.

6.2 Team Feelings and Evaluations

Overall evaluation: the team completed the prototype design with a clear division of labour, transparent progress tracking through the GitHub work log, and a test-driven review loop. The 12-screen interactive prototype covers the full user journey and maps to the SRS modules M1–M5. The prototype and the web app were verified with 188 automated checks, 108 real-browser checks and a 21-step end-to-end flow; every defect found in review was fixed and re-verified. Communication was direct and help was offered without being asked. The remaining work before the defence is to finalise the presentation, add the non-posed team photo, and confirm that the public MoDao prototype link opens and navigates correctly.

7. References

1. Zou Xin. The Method of Construction.
2. GB/T 8567-2006 Computer Software Documentation Guide.
3. Team repository: Falcons-FZU-MU-SE-GROUP12/SportsBuddy
4. Assignment 4 requirements: Fourth assignment — Prototype design