Assignment 4: Prototype Design | CodeStrike – Group 5

Item	Content
Course	EE308FZ Software Engineering
Assignment Requirements	Fourth Assignment — Prototype Design
Team Name	CodeStrike (Group 5)
Project Name	Campus Competition & Activity Community
Assignment Goal	Based on the existing Software Requirements Specification, identify user roles and core business workflows, use a specialized prototyping tool to design a clear, easy-to-use interactive prototype, and provide an online access link. Document tool selection, design iterations, testing and validation, problem solving, and team responsibilities and collaboration. Complete the project blog and presentation slides, and demonstrate the main features and page interactions through live operation.
Project Coordinator	Zhaoyan Wang (832402220)
Requirements Baseline	Software Requirements Specification (SRS) V1.0, 2026-10-15
Prototype Tool	MoDao, with HTML, CSS, and JavaScript for interactive prototyping
Online Prototype	Open the CodeStrike Interactive Web Prototype
GitHub	CodeStrike Project Repository
SRS Document	CodeStrike_Group5_SRS.docx
Prototype Design Specification	CodeStrike_Prototype_Design_Spec_V0.1.docx
Other References	Assignment 2: Team Formation and Topic Selection; Assignment 3: Requirements Analysis; Official Companion Materials for The Method of Construction: Modern Software Engineering, Fourth Edition; Chapter 12: User Experience

Contents

• 1. Team Division of Labor and Contribution Percentages

  • 1.1 Members and Initial Division of Labor
  • 1.2 Specific Division of Labor for This Assignment

• 2. Interface Prototype Design

  • 2.1 Background and Objectives
  • 2.2 Assignment Priorities and Potential Challenges
  • 2.3 Requirements and Scope
    • 2.3.1 Actors and Access Context
  • 2.4 Tools and Design Method
  • 2.5 Visual Language and Usability
    • 2.5.1 Design Rationale
  • 2.6 Information Architecture and Core Flow
  • 2.7 Interface Demonstration
  • 2.8 Interaction Specification
  • 2.9 Requirements Traceability

• 3. Design Process and Iterations

  • 3.1 From Requirements to Screens
  • 3.2 Visual Iteration and Handoff
  • 3.3 Interaction Architecture
  • 3.4 Iteration Decisions and Trade-offs

• 4. Verification and Results

  • 4.1 Browser Verification
  • 4.2 MoDao Preview Acceptance
  • 4.3 Evaluation Boundaries
  • 4.4 Verification Coverage

• 5. Team Organization, Schedule and Collaboration

  • 5.1 Plan and Execution
  • 5.2 Collaboration and Version Control
    • 5.2.1 Cross-group Handoff
  • 5.3 Discussion Records and Photos
    • 5.3.1 Online Meeting
    • 5.3.2 Offline Meeting
  • 5.4 Member Reflections and Peer Evaluation

• 6. Challenges, Solutions and Reflection

  • 6.1 Key Design Concerns
  • 6.2 Problems, Attempts and Outcomes
  • 6.3 Reflection
  • 6.4 Detailed Problem-solving Case
  • 6.5 Improvements for the Next Iteration

• 7. Grading Checklist

1. Team Division of Labor and Contribution Percentages

1.1 Members and Initial Division of Labor

The following table describes the team’s overall project responsibilities. Its percentages are planned workload allocations for the whole project. The workload allocation for Assignment 4 is reported separately in Section 1.2.

Student ID	Task Description	Contribution
832402220	Zhaoyan Wang: Project coordinator; Backend Development Group member; Documentation and Presentation Group leader. Coordinates the overall project, documentation, and presentation materials, and participates in backend development and integration.	10%
832402221	Maoping Wu: Frontend Development Group member; Product Design and Testing Group leader. Responsible for requirements analysis, product prototypes, and functional acceptance, and participates in personal profile page development.	10%
832402223	Zhengyang Wu: Product Design and Testing Group member. Responsible for requirements, test cases, and acceptance records related to the Competition Hub and competition-specific communities.	6%
832402218	Quanyan Tan: Frontend Development Group leader; Documentation and Presentation Group member. Coordinates frontend pages and components, develops competition pages, and assists with PPT visuals and presentation materials.	10%
832402215	Zihan Lin: Documentation and Presentation Group member. Organizes the requirements specification, blog, and project documentation, and assists with the project overview document (README), PPT, and version maintenance.	6%
832402216	Jianhao Liu: Frontend Development Group member. Responsible for team creation, recruitment details, and team application pages, and participates in application programming interface (API) integration and frontend self-testing.	8%
832402211	Guanxin Lai: Backend Development Group leader; Engineering Operations and Testing Group member. Responsible for API and data design, team creation and application review logic, and assists with backend deployment and integration.	10%
832402212	Yu Lei: Backend Development Group member. Responsible for user, permission, and skill profile APIs, as well as related API documentation, self-testing, and integration.	8%
832402209	Haogang Huang: Engineering Operations and Testing Group leader. Responsible for Git collaboration, environment and deployment workflows, and system and API integration testing.	8%
832402208	Haochen Huang: Engineering Operations and Testing Group member. Responsible for test environments, API and workflow testing, and defect, log, and deployment verification records.	6%
832402224	Zhiqiang Wu: Frontend Development Group member. Responsible for competition-specific community and experience-sharing pages, interaction issue resolution, and scenario test records.	6%
832402227	Zhaoyuan Zhang: Product Design and Testing Group member. Responsible for team formation and skill matching rules, application review and capacity limit test cases, and regression and acceptance records.	6%
832401308	He Huang: Backend Development Group member. Responsible for data APIs, data models, and business validation related to competitions, competition-specific communities, and experience resources.	6%
Total	13 members; responsibilities across groups are included in each person’s percentage and are not counted twice.	100%

1.2 Specific Division of Labor for This Assignment

This section specifies the division of labor for Assignment 4: Prototype Design. The four main participants are responsible for requirements and design, prototype implementation, verification and publication, and blog writing and presentation materials. The workload allocation is 25% for each participant.

Student ID	Specific Tasks for This Assignment	Workload Percentage for This Assignment
832402220	Zhaoyan Wang: Responsible for reviewing the SRS requirements, defining the prototype scope, organizing the information architecture and core user flow, mapping requirements to UI-04, UI-05, and UI-09, and preparing the design rationale and supporting design documentation.	25%
832402218	Quanyan Tan: Responsible for the mobile prototype interfaces and interactions using HTML, CSS, and JavaScript, including visual consistency, responsive layout, Tab switching, navigation, return paths, and simulated application feedback; imports and adjusts the prototype in MoDao.	25%
832402211	Guanxin Lai: Responsible for browser and MoDao interaction checks, organizing test results and issue-resolution records, checking the prototype sharing settings and resource links, publishing the prototype, and reviewing the technical descriptions and design documents.	25%
832402221	Maoping Wu: Responsible for writing and formatting the project blog, organizing the supplied screenshots and team contributions, producing the presentation PPT, and delivering the classroom presentation and prototype demonstration.	25%

2. Interface Prototype Design

2.1 Background and Objectives

CodeStrike targets university students and addresses fragmented competition information, difficulties in finding teammates, and the limited accumulation of experience and resources. The earlier blogs established a core structure of “Competition Hub + Competition-Specific Communities”: students discover a competition and then enter its discussion, resource, and recruitment spaces, reducing repeated searches across multiple channels.

The second blog further specified H5 Web, a web client for mobile browsers, and a WeChat Mini Program as the planned student clients, alongside a separate web administration portal. Personal planning is an independent business module. This interactive prototype focuses on mobile competition discovery and public team recruitment; it does not establish that the other clients or all modules have been completed.

The design addresses three questions: Can students find a target competition? Can they locate teams publicly recruiting for that competition? After a demonstration application, can they understand the current status and return to their previous browsing position?

2.2 Assignment Priorities and Potential Challenges

The assignment focuses on translating requirements analysis into an interactive prototype that communicates user tasks and design intent. Potential challenges concern requirements interpretation, information organization, interaction design, and consistency across collaborative work.

Priority Area	Assignment Focus	Potential Challenges
Requirements interpretation and design scope	Interfaces should reflect the target users’ main tasks and remain consistent with the requirements specification.	Multiple roles and business modules can make page content and functional boundaries difficult to define, increasing the risk of missing key actions or confusing responsibilities.
Information architecture and navigation	Competition discovery, competition communities, and team recruitment require clear hierarchy and connections.	As pages and entry points increase, users may struggle to identify their location, next action, and return path; the core task flow may become fragmented.
Mobile layout and visual communication	Limited screen space must accommodate sufficient information, convenient operation, and visual appeal.	Competition status, dates, skills, and team capacity differ in importance, requiring trade-offs among information density, text hierarchy, and button placement.
Interaction states and business meaning	The prototype should communicate the meaning and results of clicks, tab changes, and applications.	Interdependent page states can lead users to confuse skill indications, application status, and admission outcomes, or mistake clickable behavior for implemented business functionality.

2.3 Requirements and Scope

The requirements reference is the Software Requirements Specification (SRS), Version 1.0 (V1.0), containing 19 functional requirements, 12 business rules, 9 user scenarios, and 67 planned acceptance criteria. These figures describe the complete requirements baseline; they do not indicate that this prototype implements every function or has passed full system acceptance. UI-04, UI-05, and UI-09 identify competition discovery, competition details and community, and team recruitment details, respectively. FR denotes a functional requirement identifier in the SRS and supports traceability between pages and requirements.

Interface	Related Requirements	Demonstrated Content	Current Boundary
UI-04 Competitions Hub	Selected public discovery capabilities in FR-04 and FR-05	Competition list, search, registration status, and detail entry points	Uses demonstration data
UI-05 Competition Detail & Community	Information organization within a competition-specific community	Overview, Discussion, Resources, and Recruitment tabs, plus the team-finding entry point	Demonstrates community structure; actual content publication and moderation are unverified
UI-09 Recruitment Detail	Selected state representations in FR-07, FR-08, FR-09, and FR-11	Team introduction, available places, skill indications, application demonstration, and Pending feedback	Not connected to a real application service or captain approval workflow

Accounts and profiles, content moderation, the complete application lifecycle, team management, in-app notifications, personal schedules, and administrator access remain within the full product scope. Their completion in this assignment requires separate deliverables from the relevant members; they are not reported here as accepted functionality.

2.3.1 Actors and Access Context

The SRS defines four roles: Visitor, Student, Current Captain, and Administrator. The prototype description distinguishes public browsing from authenticated business operations, and student applications from captains’ admission decisions.

Role	Main Product Tasks	Relationship to This Prototype
Visitor	Browse published competition and community information	Public discovery and details form the main entry points; unauthenticated access passed MT-06
Student	Maintain a skill profile, find teams, and submit applications	Demonstrates recruitment browsing and simulated application feedback
Current Captain	Publish recruitment information, review valid applications, and manage admission and membership	Displays public recruitment details without demonstrating the complete captain workflow
Administrator	Maintain competitions and skills, moderate content, and address violations	Belongs to the separate administration portal; acceptance is not established by these three interfaces

The demonstration task follows a student who wants to enter a competition, finds a recruiting team through the competition entry point, interprets team capacity and skill indications, applies, and recognizes the Pending status. This scenario explains prototype operation; it is not presented as a finding from completed user interviews.

2.4 Tools and Design Method

We use MoDao for prototype presentation and preview, together with HTML, CSS, and JavaScript to construct the H5 Web interactive prototype, presented through HTML import and AI HTML components. HTML and CSS define page structure, layout, and visual styling; JavaScript supports search, tab switching, navigation, and example application feedback.

This combination supports both visual presentation and complete interaction flows. Competition cards, recruitment details, and status feedback can follow a consistent design, while MoDao provides a device frame, online sharing, and a preview environment for team review. Design starts with the core mobile task: page content and action relationships are established before visual hierarchy and interaction feedback are refined.

Tool or Technology	Use in This Assignment
MoDao	Prototype hosting, device frame, online sharing, and preview in the target environment
HTML / CSS	Page structure, card layouts, visual conventions, and responsive adaptation
JavaScript	Search, tab switching, internal view navigation, and example application feedback
Edge / Chromium	Browser interaction checks across multiple viewports
GitHub	Management of requirements, design documents, prototype source code, and version history

We first check layout and basic interactions in a browser, then verify presentation in MoDao, focusing on content switching, team-detail entry, application feedback, and stepwise return navigation. Identified issues lead to style or interaction adjustments and retesting, so the prototype communicates both interface design and a complete user task flow.

2.5 Visual Language and Usability

The prototype adopts a Mobile First approach and organizes information through competition and recruitment cards. UI/UX (user interface and user experience) considerations cover both information presentation and continuity of operation. Consistent headers, status badges, and bottom navigation help users identify their location. Competition names, registration status, deadlines, and membership counts appear near the relevant actions to support the next decision.

Visual Element	Specification	Design Purpose
Page background	Light gray #f5f7fa	Distinguish content cards from the page background
Primary text color	Dark blue #14213d	Establish a consistent text hierarchy
Accent color	Blue #2563eb	Highlight actions and selected states
Secondary accent	Lime green #c9f43d	Emphasize selected visual elements
Status communication	Open, Registration closed, Applications open, Pending	Explain states with text rather than relying solely on color
Mobile adaptation	Checks at widths of 320, 390, 402, and 430 px	Inspect narrow-screen layouts, bottom navigation, and horizontal overflow

Skill-overlap indications retain the earlier Rule-Based Matching design: a student matches a team’s requirements when at least one student skill tag overlaps with a required team skill. The prototype displays information and indications supporting this judgment. A mismatch does not automatically prevent an application; the Team Captain remains responsible for the final admission decision.

2.5.1 Design Rationale

Organize communities by competition. Introduction, discussion, resources, and recruitment for one competition occupy four tabs, so students retain a clear sense of the competition they are viewing. This structure follows the established product positioning and keeps recruitment associated with the relevant competition.

Provide decision information before actions. Competition cards show registration status and dates; recruitment cards show skills and available places. Students can judge whether to explore further and decide whether to apply after viewing team details. The information hierarchy progresses from discovery to background information, recruitment comparison, and action.

Use feedback to explain action results. Apply to join produces Pending feedback, indicating that an example application awaits processing. This differs from admission and should not imply that the user has become a team member. The demonstration explicitly identifies the feedback as simulated.

Preserve context on return. Returning from Team Alpha restores Recruitment, avoiding an additional tab selection. The design evaluates whether a task flow can be completed continuously, rather than merely whether an individual button initiates navigation.

Maintain consistency through shared components. Repeated cards, labels, headers, and bottom navigation retain consistent meaning and visual hierarchy. The MoDao preview uses an iPhone 17 Pro device frame, while multi-viewport checks examine other widths. The device frame alone does not establish compatibility with real devices.

2.6 Information Architecture and Core Flow

The prototype follows “discover a competition—understand it—browse recruitment—inspect a team—receive application feedback.” The diagram shows the relationships among UI-04, UI-05, and UI-09, including the four tabs and return paths.

Information Architecture and Core Flow.

1. Competition discovery and details. Users browse or search in UI-04 Competitions Hub, select the 2026 University Innovation Challenge, and enter UI-05 to view its basic information.
2. Community content and team entry. UI-05 contains Overview, Discussion, Resources, and Recruitment, all within the same competition. Users browse public recruitment in Recruitment and select Team Alpha to open UI-09.
3. Team information and application feedback. UI-09 displays capacity, skill indications, and the captain’s public information. Apply to join produces example Pending feedback: a simulated application awaits processing, without admission or submission to a real server.
4. Stepwise return and context preservation. Returning from UI-09 restores the Recruitment tab in UI-05 so users can continue browsing teams. From UI-05, users can return to UI-04 to explore other competitions.

The four tabs and page views use state switching within HTML. Diagram arrows represent user actions, not transitions between native MoDao artboards.

2.7 Interface Demonstration

Web prototype: CodeStrike — MoDao Interactive Prototype.

Figure 1. Competition Discovery

Figure 1 — Competition Discovery. The page provides a public competition list and a search field. Examples include the 2026 University Innovation Challenge, open for registration, and the Campus Mathematical Modeling Contest, whose registration is closed. Cards directly display competition status, basic eligibility, and deadlines; users select a competition card to enter its details.

Figure 2. Competition Overview

Figure 2 — Competition Overview. The top section presents the competition name and introduction, discussion count, shared-resource count, and team-size limit. Four tabs organize the competition-specific community into Overview, Discussion, Resources, and Recruitment while preserving the competition context.

Figure 3. Recruitment Tab

Figure 3 — Recruitment Tab. Selecting Recruitment displays the public recruitment list. The Team Alpha card includes Open, Skills overlap, Python/Java skill tags, 2/4 members, and the captain’s public username. Selecting Team Alpha opens recruitment details. A skill mismatch does not automatically prohibit an application.

Figure 4. Team Alpha Recruitment Detail

Figure 4 — Team Alpha Recruitment Detail. The page clearly presents the associated competition, team introduction, occupied and available places, skill-overlap indication, application entry point, and captain’s public username. It does not disclose personal contact details for captains or members, consistent with the SRS privacy boundaries.

Figure 5. Application Feedback

Figure 5 — Application Pending Feedback. Selecting Apply to join displays Example application submitted. Status: Pending., providing an explicit result instead of leaving the action without feedback. This is a prototype state driven by simulated data, not an application created on a real server or a triggered captain-approval process.

2.8 Interaction Specification

The table relates prototype actions to interface feedback and usability concerns. Verification records are provided in Section 4.

Location	User Action	Prototype Behavior or Content	Usability Concern
UI-04	Browse the competition list	Display names, registration status, and dates	Can users distinguish open from closed registration?
UI-04	Enter a search term	Show results from demonstration data; the execution report includes empty-state checks	Can users understand a no-results page and search again?
UI-04	Select a competition	Display UI-05 competition details	Does the detail heading match the selected competition?
UI-05	Switch among four tabs	Change visible content within one competition	Does content match the selected tab?
UI-05	Select Find a Team or Recruitment	Open the public recruitment area	Can users find the team entry point?
Recruitment	Select Team Alpha	Display UI-09 team details	Are the team name, skills, and capacity consistent?
UI-09	Select Apply to join	Show example-submission and Pending messages	Could users mistake the feedback for admission or a real submission?
UI-09	Return	Restore Recruitment in UI-05	Is the previous browsing context preserved?
UI-05	Return to Discover	Display UI-04	Can users continue exploring other competitions?

Discussion and Resources currently communicate the community’s information structure. Tab switching alone does not establish posting, moderation, resource uploads, or data synchronization. Likewise, application-button feedback does not replace real checks of identity, capacity, deadlines, or approval rules.

2.9 Requirements Traceability

Requirement Concern	Observable Prototype Representation	Conclusion Supported at This Stage	Further Verification Required
Public competition discovery	List, keyword search, registration status, and detail entry	Assess discovery entry points and presentation structure	Data sources, maintenance permissions, and real query results
Competition-specific communities	Four tabs share the competition title and background	Assess community information categories	Posts, comments, moderation, and persistence
Skill-matching indications	Skills overlap and Python/Java tags	Assess whether indications are understandable	Computation using real profiles and team requirements
Team capacity	2/4 members	Assess clarity of membership counts	Full teams, concurrent admissions, and changing availability
Application status	Example Pending feedback	Assess clarity of action results	Application lifecycle, withdrawal, invalidation, and captain decisions
Information visibility	Public username without private contact details	Assess information selection on public pages	Server-side permissions and identity-dependent access

This traceability distinguishes a rule represented in the interface from a rule enforced by the system. It supports subsequent development without overstating prototype results.

3. Design Process and Iterations

3.1 From Requirements to Screens

The previous assignments established the team and topic, followed by functional requirements, business rules, pages, and acceptance criteria. This assignment maps page identifiers to those requirements and selects three interfaces that connect a complete user task for focused demonstration.

Compared with the interface illustrations used during requirements analysis, this stage adds clickable search, tabs, application feedback, and return paths. Design checks therefore extend from individual page content to continuity across pages.

3.2 Visual Iteration and Handoff

Initial work focused on visual consistency across mobile interfaces. We then prepared three separate HTML files for MoDao import and interaction verification. The original HTML files are managed separately from pages built with the Vue frontend framework; prototype demonstration materials and production development code are maintained independently.

Successive stages addressed visual consistency, import adaptation, and interaction continuity. Specific issues and outcomes are documented below.

3.3 Interaction Architecture

Early attempts navigated between separate HTML pages, but MoDao’s embedded components could not automatically map relative links to native artboards. Direct sharing links instead embedded another sharing page, while static hotspots could not reliably follow dynamic tabs and scrolling content.

The final approach includes UI-04, UI-05, and UI-09 in each HTML file, with JavaScript managing the active view. Each of the three files starts from a different default view but uses the same internal navigation mechanism. Returning to competition details restores Recruitment and maintains exactly one active view and one fixed bottom navigation bar.

MoDao’s outer page indicator may therefore remain at 1/3 while clickable view changes occur inside the component. These are internal HTML interactions rather than native MoDao artboard transitions.

3.4 Iteration Decisions and Trade-offs

We upgraded interactions within the existing three HTML files rather than adding a fourth business page. Each file contains the actual structure and content of all three views, starting from competition discovery, competition details, or recruitment details. A single state controller determines the active view, tab, and bottom navigation.

Approach	Issue Observed in Preview	Final Decision
Cross-file relative links (href)	Could not automatically resolve to native MoDao pages; permission errors occurred	Discontinued for internal navigation
MoDao sharing URL	Opened another sharing page inside the component	Removed sharing-URL navigation within the component
Transparent click hotspots	Coordinates could not reliably track tab and scroll states	Avoided static coordinates for dynamic navigation
View switching within one HTML page	Avoids cross-file navigation issues and preserves return context	Adopted for the current prototype demonstration

Here, href is the HTML attribute specifying a link’s destination, URL denotes a web address, and a transparent click hotspot is an invisible clickable area overlaid on an interface.

This approach suits the current three-view demonstration but duplicates view content across import files. Subsequent changes must keep content and interactions consistent across all three files. If the page count grows, the maintenance approach should be reassessed. This is a prototype-delivery trade-off; the production application architecture requires separate design.

4. Verification and Results

4.1 Browser Verification

The three HTML files were checked in Edge/Chromium at four viewports: 320×900, 390×900, 402×820, and 430×900, including round-trip navigation from different default views. Checks covered the four tabs, Find a Team, search and no-results feedback, example Pending feedback, return paths, repeated actions, a single bottom bar, horizontal overflow, and runtime JavaScript errors.

4.2 MoDao Preview Acceptance

MT-01 through MT-06 identify manual MoDao acceptance checks. Each identifier corresponds to an operation, verification result, and evidence status.

ID	Operation	Verification Result	Evidence and Status
MT-01	UI-04 → UI-05 → UI-04	Internal views support round-trip navigation	Passed manual testing
MT-02	Select Recruitment in UI-05	Displays the recruitment list containing Team Alpha	Passed manual testing
MT-03	Team Alpha → UI-09 → Recruitment	Round-trip navigation succeeds without opening the incorrect page	Passed manual testing
MT-04	Select Apply to join	Displays example Pending feedback	Figure 5 shows Pending feedback
MT-05	Run each updated HTML file	Navigation works from all three default views	All three files passed manual checks
MT-06	Open the sharing link while logged out and complete the core flow	Accessible without login or enterprise membership; discovery, details, recruitment, example Pending feedback, and stepwise return all pass	Passed browser testing on 2026-10-29 at 20:27 (Beijing time)

MT-06 was executed while the browser was logged out of MoDao. A login entry remained visible, and the prototype loaded normally. The check followed Discover → competition details → Recruitment → Team Alpha → Apply to join and observed example Pending feedback. Returning restored Recruitment and then successfully reached Discover. This check verifies sharing access and prototype interactions; it does not submit a real application.

4.3 Evaluation Boundaries

Figures 1–5 show five key states: discovery, overview, recruitment, team details, and application feedback. Interaction records supplement the navigation that static images cannot demonstrate. Task-based trials with actual students could further assess understandability. The current materials provide no formal usability-study sample size, task-success rate, or satisfaction measurements, so no corresponding quantitative conclusions are drawn.

The prototype has not verified real authentication, database writes, concurrent capacity control, captain approval, administrator moderation, or cross-device synchronization. The complete SRS’s 67 acceptance criteria remain the basis for subsequent system development and verification.

4.4 Verification Coverage

Local browser checks and manual MoDao acceptance address different concerns. Browsers help locate layout and script problems, while MoDao confirms display and operation in the actual delivery environment. Both are needed to judge whether a change supports the final demonstration.

Verification Dimension	Coverage	Existing Evidence	Additional Records or Archiving
Default entry	Each HTML file starts from its designated view	Codex execution report and MT-05	Retain filenames and versions
Complete flow	Discovery, details, recruitment, application feedback, and stepwise return	Browser report and MT-01 through MT-04	Review alongside Figures 1–5 and prototype operation
Content switching	Four tabs and Find a Team	Browser records; MT-02 covers Recruitment	All four tabs share one competition context
Search	Keyword results and empty states	Browser check records	Archive actual search terms and results
Repeated actions	Repeated switching, return, and re-entry	Browser check records	Confirm no duplicate bottom bars or overlapping views
Responsive layout	Four viewport configurations	Browser check records	Retain viewport information from the existing report
Scripts and layout	No runtime errors or horizontal overflow; a single bottom bar	Browser check records	Retain reports and issue-resolution records
External access	Open the sharing link while logged out and complete the core flow	MT-06 passed	Checked on 2026-10-29 at 20:27 (Beijing time)

5. Team Organization, Schedule and Collaboration

5.1 Plan and Execution

The earlier project plan defines M0 as team formation and topic selection, M1 as requirements confirmation, M2 as design and task breakdown, M3 as the core version, M4 as refinement and verification, and M5 as final delivery. This prototype design builds on requirements confirmation and provides interface and workflow references for implementation.

Work Stage	Tasks at This Stage	Execution Status
Requirements and page mapping	Select core tasks from the SRS and map them to pages	UI-04, UI-05, and UI-09 selected for demonstration
Prototype production	Unify visual design and prepare import materials	Three HTML files prepared, with visual refinement and import adaptation completed
Target-environment debugging	Check layout and navigation in MoDao	Changed to internal view switching in response to preview issues
Interaction verification	Round-trip navigation, tabs, search, application feedback, and multiple viewports	Browser checks and manual preview completed
Material integration	Blog, images, contribution table, and collaboration records	Blog organized; some collaboration materials remain to be supplied
Publication and demonstration	Logged-out access, PPT/PDF, classroom rehearsal, and submission	Logged-out access passed; PPT/PDF, rehearsal, and submission remain pending

5.2 Collaboration and Version Control

The team allocates tasks through a communication group, maintains materials collaboratively on GitHub, and relies on workgroup leads to synchronize progress and review results. The workflow is: SRS constraints → design revisions → Codex-assisted implementation → browser checks → manual MoDao preview → diagnosis and regression checks → version commits and archiving.

Prototype work takes place on the GitHub feature branch feature/assignment4-prototype. Changes to three HTML files and one verification script were committed on 28 October 2026, with the milestone tag a4-prototype-freeze-20261028 identifying the corresponding deliverables. The feature branch isolates prototype changes; main is the project’s primary branch, and the two have not been merged. The commit record and milestone tag are available in the repository.

5.2.1 Cross-group Handoff

Building on the established workgroups, handoffs cover requirements explanations, design deliverables, interaction checks, and documentation. Product design and testing address business meaning; frontend work addresses pages and interactions; backend work helps examine future implementation constraints; engineering and testing address execution and retesting; documentation and presentation consolidate consistent results into the blog and presentation. Individual ownership remains subject to the actual records in the table above.

Each handoff should include page identifiers, a change description, the current version, and unresolved issues. For example, a change to UI-09 application feedback should also explain that Pending is simulated, return navigation must restore Recruitment, and certain real business validations remain outside this demonstration. This reduces discrepancies among the interface, test report, and blog.

5.3 Discussion Records and Photos

Two meetings coordinated the frontend approach. The online meeting addressed the overall framework and subsequent direction, while the in-person meeting examined concrete page construction and interaction implementation.

5.3.1 Online Meeting

Time and platform: 21 October 2026, 20:00, Tencent Meeting.

Meeting leads: Zhaoyan Wang and Quanyan Tan.

Participants: All 13 CodeStrike members.

Discussion topics: The overall frontend framework, page hierarchy, major modules, and navigation of the H5 Web student client, including connections among the Competition Hub, competition-specific communities, and team recruitment. Using the existing SRS, the discussion examined how core user tasks appear in the interface and how page structure aligns with business rules.

Subsequent direction: Progress from requirements mapping and core workflows to page design, frontend implementation, and interaction verification. Prioritize continuity among competition discovery, details, recruitment information, and application feedback, while continually cross-checking interfaces, requirements documents, and presentation materials.

Figure 6. Online Team Discussion

5.3.2 Offline Meeting

Time and location: 24 October 2026, 21:00, fifth-floor activity room, Building 1.

Meeting leads: Maoping Wu and Guanxin Lai.

Participants: Maoping Wu, Guanxin Lai, Zihan Lin, Jianhao Liu, Zhengyang Wu, Quanyan Tan, Zhiqiang Wu, and Zhaoyuan Zhang.

Discussion topics: Concrete frontend construction based on the overall framework, including competition cards, recruitment cards, headers, bottom navigation, and tab-content organization, together with the roles of HTML, CSS, and JavaScript in structure, styling, and interaction. The discussion also addressed mobile information hierarchy, reusable components, and adaptation to different screen widths.

Implementation concerns: Page entry points, tab switching, example Pending feedback, and preservation of context on return across discovery, competition details, public recruitment, and team details. These concerns connect individual pages into a complete flow. The discussion also considered browser and MoDao preview behavior for subsequent demonstrations and included the relevant interactions in planned checks.

Figure 7. Offline Team Discussion

5.4 Member Reflections and Peer Evaluation

Member	Reflection	Peer Evaluation
Zhaoyan Wang	Defining the prototype scope showed me that requirements must be translated into specific pages and actions. A clear scope also helps members understand their deliverables.	Quanyan Tan connected interfaces and interactions, making the design tangible. Page implementation also helped the team assess workflow continuity.
Quanyan Tan	Prototyping requires attention to appearance, click feedback, and coherent return paths. Completing individual pages is insufficient without smooth round-trip navigation.	Guanxin Lai’s verification and issue records supported refinement. This feedback helps distinguish visual defects from interaction problems.
Guanxin Lai	Local execution and target-platform preview require separate checks because the delivery environment affects experience. Results must correspond to specific actions to establish whether a fix works.	Zhaoyan Wang mapped requirements to pages, clarifying the test scope and reducing mistaken assumptions about unimplemented functions.
Maoping Wu	Preparing the blog and presentation increased my attention to consistency among design rationale, process records, and reported results. Explaining design decisions is more valuable than simply listing features.	The other three contributors handled design, implementation, and verification, supplying the substance for the blog and presentation. Clear responsibilities helped me organize the article and speaking sequence.
Zhengyang Wu	The hierarchy of competition information directly affects whether users can find their target. Registration status, eligibility, and dates should support quick comparison.	Zhaoyan Wang’s requirements-to-page mapping clarified the prototype scope and emphasized competition discovery as a core task.
Zihan Lin	Screenshots need accurate explanations so readers understand page purposes and interactions. Matching text to images avoids discrepancies between descriptions and actual interfaces.	Maoping Wu coordinated the blog and presentation materials, maintaining consistent reporting and making progress easier to understand.
Jianhao Liu	Recruitment interfaces should explain team information, remaining places, and application entry points together. Clear capacity and application states reduce misunderstandings during team formation.	Quanyan Tan’s work on page connections provides a reference for recruitment-module development. Preserving context on return supports continued browsing.
Yu Lei	Information selected for public pages is closely related to later identity and permission design. Interface privacy boundaries must also be enforced on the server.	Zhaoyan Wang emphasized requirements boundaries, connecting interface decisions to business constraints and distinguishing public display from authenticated operations.
Haogang Huang	Sharing permissions and runtime environments determine whether deliverables are accessible. Opening the link and completing the core flow should be checked separately.	Guanxin Lai’s publication and link checks demonstrated attention to delivery details and provided evidence for archiving and later review.
Haochen Huang	Complete round trips and repeated actions expose issues that isolated page inspection may miss. Testing should also verify state consistency after switching and returning.	Guanxin Lai organized results and issue records for follow-up. Linking issues to operation steps makes retesting easier.
Zhiqiang Wu	Grouping discussion, resources, and recruitment under one competition preserves browsing context. Clear categories make the relationship between community content and recruitment more apparent.	Quanyan Tan maintained consistent interfaces and interactions. Stable entry points and labels help users develop predictable operating habits.
Zhaoyuan Zhang	Skill indications, pending applications, and admission must remain distinct to avoid misleading users. Status messages should explain the current result without equating application with acceptance.	Zhaoyan Wang clarified business workflows, guiding status representation and later acceptance, and informing subsequent application-lifecycle design.
He Huang	Membership counts, skills, and status wording must remain consistent with future data rules. Demonstration data should support understanding rather than merely fill the interface.	Maoping Wu organized interfaces and flows into the blog and presentation, facilitating discussion and helping workgroups share an understanding of the design.

6. Challenges, Solutions and Reflection

6.1 Key Design Concerns

The central concern is a continuous flow connecting competition discovery, community browsing, and team application. Pages should retain clear competition context, recruitment information should support comparison, and application buttons should provide explicit feedback. Skill indications, public usernames, and personal contact information should also be presented consistently with the earlier requirements.

Compatibility with the delivery environment is equally important. Display, navigation, and scrolling in MoDao-embedded HTML require actual checks; local static screenshots alone cannot establish completion.

6.2 Problems, Attempts and Outcomes

Actual MoDao preview revealed issues involving import dimensions, fixed-navigation backgrounds, navigation, dynamic hotspots, and sharing permissions. The table records causes, attempted solutions, and current outcomes.

Problem and Impact	Cause and Attempted Solution	Current Outcome	Lesson Learned
HTML imported at a default desktop width of 1920 px, preventing the expected mobile layout	The component dimensions differed from the mobile artboard; adjusted HTML-component width so responsive rules applied at mobile width, then aligned the artboard	Mobile layout displays correctly	Imported component dimensions must correspond to target-device width
Competition dates remained visible around navigation edges, disrupting visual continuity	The bottom-navigation wrapper, .bottom-wrap, had a transparent background; assigned the page background using background: var(--canvas)	Fixed in local multi-viewport tests and MoDao preview	Fixed navigation requires checks of background coverage and scrolling
Team Alpha’s relative link produced a permission error, interrupting team-detail access	HTML href could not automatically map to native MoDao pages; discontinued cross-file navigation after investigation	Internal navigation now uses view-state control within one HTML page	HTML links do not automatically map to native MoDao pages
Replacing the link with a MoDao sharing URL embedded one web page inside another	The embedded component opened another MoDao sharing page; removed sharing-URL internal navigation	Sharing URLs are no longer used for internal navigation	Public-access entry points and internal component navigation require separate designs
Transparent hotspots could not reliably follow dynamic tabs and scrolling	HTML state and static MoDao hotspot coordinates were not synchronized; adopted JavaScript state switching inside one HTML page	Core round-trip checks passed; return navigation restores Recruitment context	Dynamic-content navigation must remain consistent with interaction state
Public sharing was previously restricted to enterprise members, preventing teacher access	Adjusted sharing settings and generated a new shareable link	New link generated; logged-out access and the core flow passed checks on 2026-10-29	Target-platform preview and external public access require separate verification

6.3 Reflection

This work showed that correct page display is only one aspect of a usable prototype. A complete interaction also requires feedback after clicks, retained position on return, and consistent behavior across target platforms and screen widths.

Observing an actual issue, locating its layout or navigation mechanism, and retesting in MoDao provides stronger evidence of an effective fix than static inspection alone. The team should retain records of the verification steps and results, and review key interactions in the target prototype environment to ensure that the implementation matches the intended behavior.

These reflections concern the design stage as a whole. Individual reflections and peer evaluations are collected in Section 5.4.

6.4 Detailed Problem-solving Case

Observed problem. Discovery and detail pages displayed correctly in the local browser, but selecting Team Alpha through a cross-file link produced a permission error in MoDao preview. Users could not continue from public recruitment to team details, interrupting the core demonstration flow.

Attempts. We first examined the relative link, then tried a MoDao sharing URL. The embedded environment opened another sharing page, producing nested web pages. We next considered transparent hotspots, but dynamic tabs and scrolling changed content positions, preventing static hotspots from consistently matching the actual buttons.

Final adjustment. We placed all three views within the same HTML page and used JavaScript to manage visibility. The three import files and their default entry points were retained, while cross-file navigation was removed. Returning from team details restores Recruitment and keeps users within the original competition context.

Resolution status. MT-01, MT-03, and MT-05 document manual confirmation of round-trip navigation and updates to all three files. MT-06 verified logged-out access on 29 October 2026: the sharing link opened without login or enterprise membership, and the core flow, example Pending feedback, and stepwise return worked correctly.

Lessons learned. Diagnosis should begin in the actual delivery environment and distinguish permission messages, link resolution, and view-switching mechanisms. A visible error can have several causes. Fixes should be retested along the original failing path, rather than merely checking that a new page opens.

6.5 Improvements for the Next Iteration

In the next development stage, we plan to use Python FastAPI to build the backend services and PostgreSQL for data storage, covering user accounts, competitions, team management, applications, communities, and personal planning. We will adopt a RESTful API architecture and use Swagger/OpenAPI and Postman for API documentation and testing. The frontend and backend teams will jointly define API endpoints, request/response data formats, authentication, and permission rules to ensure consistent integration across the H5 client, WeChat Mini Program, and administration portal.

7. Grading Checklist

The table maps this assignment’s grading requirements to completion status and the relevant sections for reference.

Grading Requirement	Completion Status	Relevant Location
Contents, assignment information, and online prototype link	Contents, assignment details, and prototype entry provided; logged-out access passed MT-06	Opening table and contents; 2.7; MT-06 in 4.2
Markdown formatting	Heading hierarchy, contents, tables, images, and links completed	Throughout
Analysis of priorities and potential challenges	Analysis addresses requirements, information architecture, mobile layout, interaction states, and collaboration	2.2
Assignment-specific responsibilities and workload shares	Four main contributors listed at 25% each, totaling 100%	1.2
Specialized prototyping tool and explanation	MoDao used for presentation; supporting technologies and design method explained	Opening table; 2.4
Design process and outcomes, requirements alignment, user experience, ease of use, and appearance	Includes requirements-to-page mapping, visual conventions, core flow, five prototype screenshots, interaction design, iterations, and verification	2.3–2.9; 3.1–3.4; 4.1–4.4
Accurate, clear writing, design concepts, and prototype introduction	Objectives, page purposes, workflows, rationale, and scope explained	2.1; 2.5.1; 2.6–2.9
Description of difficulties	Six actual MoDao preview issues and their impacts documented	6.2; 6.4
Attempted solutions and resolution status	Causes, attempts, current outcomes, and outstanding verification distinguished	6.2; 6.4
Learning and reflection	Lessons address layout adaptation, interaction compatibility, verification, and collaboration	6.2–6.5
Prototype development process, candid discussion photos, member reflections, and peer evaluation	Includes process records, two meetings, online and in-person discussion images, and reflections and evaluations for all 13 members	Section 3; 5.3; 5.4
Plan execution, responsibilities, and workload shares	Stage tasks, execution status, and contribution percentages listed; actual stage dates and other records remain to be completed	1.2; 5.1; 5.2