Assignment 4 | MoodSky Interface Prototype Design

Item	Content
Course	EE308FZ Software Engineering
Assignment requirements	Assignment 4: Prototype Design
Team	MoodSky
Assignment objective	Translate user needs into a working WeChat mini program prototype and explain its interface design, interaction flow, design decisions, and team collaboration.
Prototype design tool	MoDao
Interactive prototype	MoodSky interactive prototype in MoDao
Project repository	MoodSky on GitHub
Requirements document	MoodSky Requirements
Earlier SRS	Assignment 3 SRS

Contents

1. Project Background and Design Goals

MoodSky is a WeChat mini program for university students to record feelings through weather symbols and revisit them over time. Weather is the minimum input; tags and a short note are optional. It is designed for brief moments in a student's day without requiring a complete explanation before saving.

The central journey is to leave a private record and find it again. Campus and task pages provide optional paths, while rest and cancellation remain available. Weather choices have no good or bad rank, and records are not turned into scores. “Every kind of weather can stay here” expresses the tone of the interface.

The design follows three principles: a clearly visible first action, feedback that distinguishes processing from confirmed or uncertain results, and a private scope shown alongside personal content. These principles shape the page structure, required fields, button labels, and recovery paths.

2. Project Division of Labor

2.1 Team Organization

The team has 12 members. Xiang Hong coordinates scope and integration, and Jiaqi Zhu provides shared visual and interaction materials. Page, service, data, and testing responsibilities meet at the same user journeys: saving a record, opening a review, and managing account data.

2.2 Responsibilities for This Assignment

The table lists the team members and their responsibilities in the prototype work.

Student ID	Work Description	Contribution
832401205	Xiang Hong — Coordinate prototype scope, interaction contracts, integration, the blog, and design documentation.	9%
832401207	Junhan Huang — Check campus information, support resources, favorites, corrections, and operator permissions against interface states.	8%
832401110	Jiawei Fang — Clarify account, preference, task, and account closure states for the interface.	8%
832401201	Linghan Chen — Integrate shared navigation, components, and Me interactions across the mini program.	8%
832401209	Yifan Ji — Develop weather selection, private entry editing, deletion confirmation, and save feedback.	8%
832401203	Zhifeng Dai — Develop Weather Universe, month navigation, archives, weather cards, and review entry points.	8%
832401226	Qinghan Zhang — Develop campus lists, filters, details, and feedback when location or navigation is unavailable.	8%
832401304	Qizhen Chen — Develop task interfaces, navigation, and read-only states, and review administration interactions.	9%
832401229	Jiaqi Zhu — Organize weather icons, colors, layouts, shared copy, and interaction guidelines.	8%
832401124	Xiang Yu — Check data fields, export scope, and cleanup states against the interface descriptions.	9%
832401211	Yuen Lin — Check user journeys, exceptional situations, compatibility, and interface validation.	8%
832401301	Qizhen Cai — Review privacy, account isolation, usability, and supporting evidence.	9%
Total		100%

2.3 Collaboration Across Pages

Selecting weather, saving, and reviewing a day connects the recording interface, service, and review pages. Today shows input validity and save status, the journal service handles the request, and Weather Universe displays the corresponding date, weather, and tags. Yifan Ji's recording interactions and Zhifeng Dai's review pages connect around the same private entry, which can be edited or found again after saving.

Campus and account pages connect interface and data responsibilities. Campus organizes place queries by campus and tags, with verified information defining the available content. Account and Data shows progress according to export and cleanup stages. Entry points, states, and feedback connect these contributions within the interface.

Jiaqi Zhu's weather icons, colors, buttons, and wording provide a shared visual reference. Recording and review use the same weather meanings, common navigation links the main pages, and private notes remain hidden in overviews. Together, these conventions support continuity across pages owned by different members.

3. Prototype Tools and Design Process

3.1 MoDao Prototype and WeChat Implementation

The interface and interaction prototype is organized and published in MoDao as “MoodSky | WeChat Mini Program Prototype | 20 Screens and Core Interactions.”

Open the MoodSky interactive prototype in MoDao

The MoDao project has two entry points: Mini Program Interaction Demo and 20-Screen and State Overview. The demo presents 20 screens and states through an HTML interaction component, connecting weather selection, private editing, save feedback, and review. The overview brings the layouts and their states together.

WeChat Developer Tools supports implementation and execution of the mini program in WXML, WXSS, and JavaScript. MoDao provides the browser-based interaction prototype, while the trial entry provides access inside WeChat.

Figure 1. MoodSky trial access. The QR code is marked valid before November 7.

3.2 From Scenarios to Navigation

We organize the prototype around four questions: How can someone leave a quick record? How can they find an earlier day? How can they understand a campus place? What can they choose when they want a small change of activity? The first two form the central recording and review journey; the others are optional paths that users can choose themselves.

These questions led to four main tabs: Today, Campus, Weather Universe, and Me. They describe user purposes: recording, place information, private review, and account data. Entry editing, daily details, and optional tasks use secondary pages because they continue an existing journey. This keeps the primary navigation stable while allowing more focused input and reading screens.

Within a page, the current task and state come first, followed by the main action and supplementary entry points. On Today, the date and weather choice are prominent. When a record exists, the main action becomes editing that entry. The distinction helps users understand whether they are creating a record or changing one already saved.

The selected date connects Today, the editor, and daily details. Moving from a weather choice to editing, or from the calendar to details, keeps the interaction centered on the same day through entering, saving, returning, and finding it again.

Figure 2. Four primary tabs and their secondary pages in the 0.3.0 design.

3.3 Shared Styles and Interface States

Shared weather icons, cards, buttons, tags, and input fields give the pages a consistent visual language. A warm background separates white content cards, dark text establishes hierarchy, and green marks ordinary primary actions. Supplementary copy has a lower visual emphasis, keeping the date, weather, and save action prominent.

Weather icons retain text labels and a selected appearance. Input counts and limits appear beside custom names, tags, and notes, so users can see the requirements as they type.

The pages distinguish loading, empty results, failed reads, and unknown save results. Waiting messages, empty-state explanations, and recovery actions have their own wording. An unknown save result retains the original input and operation and displays a separate retry action.

3.4 Interactive Prototype and Mini Program

The MoDao demo connects Today, weather selection, saving, private editing, Weather Universe, and daily details through clickable interactions. Tags can be selected, writing has a live count, and a saved entry can be opened from the calendar. The four main entry points also connect Campus filters, private review, and account-data pages.

The 20 screens and states cover the following areas:

Area	Count	Screens and states
Recording	7	No selection; selected and custom weather; private editor; saved result; unknown result; draft-leave confirmation; optional choices
Campus	2	Empty place list; filters
Private review	6	Recorded month; empty month; daily details; month archive; distribution and timeline; deletion confirmation
Small tasks	1	Private cloud tasks unavailable
Me and data	4	Me; Account and Data; export formats and states; closure explanation

Beyond the normal journey, unknown results and draft-leave confirmation show recovery choices, while deletion confirmation retains a cancellation path. Empty Campus results and unavailable tasks are also part of the prototype, making the feature boundaries visible alongside the main journey.

MoDao retains entered content within the current browser session and uses fixed examples for the calendar and distribution. Export and closure illustrate their flows without connecting to real account services. The mini program provides actual recording and retrieval; recorded phone feedback confirms that saved records and notes remain readable after closing and reopening it.

Figure 3. Recording and private review, including draft confirmation and retry paths.

4. Interface Design and Main Interactions

The MoDao prototype has four main entry points: Today, Campus, Weather Universe, and Me. Recording and private review form the main journey, with dedicated places for Campus and account data.

The corresponding version 0.3.0 mini program interfaces below use the same weather definitions and navigation structure. They also show the implemented input limits, state feedback, and current feature availability.

4.1 Today: Start with One Weather Choice

Today places the date above the weather card, with weather selection and the save action inside it. The visible date helps users understand which day they are recording, including when adding an earlier entry. New records can be created for today and the preceding 29 days; existing older records remain editable, with the creation limit explained on the page.

The seven choices are Sunny, Partly Cloudy, Cloudy, Rainy, Stormy, Typhoon, and Custom. Similar wind-and-rain choices are grouped under Stormy. Icons support recognition while labels explain each choice. The page also states that weather has no good or bad rank: selecting a symbol expresses a feeling rather than earning a score.

Before a selection, the button asks the user to choose weather first. Saving is enabled only when the required input is valid. Selecting Custom opens a name field for 1–20 Unicode code points, including emoji, with the limit beside it. Showing this field only when needed keeps the default screen focused while allowing a more personal expression.

When a record already exists, the page displays its weather and tags and offers “Edit this entry.” The note stays hidden until the private editor is opened. This makes the saved state recognizable and keeps longer private text out of the overview.

Figure 4. Today: private scope, seven weather choices, and the disabled save action.

Figure 5. Custom weather: the name field and its visible length limit.

4.2 Private Entries: Add Details or Cancel

“Write a few words?” opens the private editor. Users may add up to five tags and 1,000 Unicode code points of text, or leave both blank. Weather, tags, and writing appear in that order, allowing a general feeling to be recorded before adding context. Optional labels and counts remain close to the inputs.

An existing entry opens through the edit action, and its main button indicates that it saves changes. Deletion appears only for an existing record and requires confirmation; cancellation keeps the record. Reading, editing, and deleting have distinct entry points and outcomes.

Reloading or changing dates displays confirmation when it would discard a draft, with an option to keep the current input. The editor requests WeChat's leave-page alert where supported and otherwise retains an inline warning identifying the unsaved content. Unsaved drafts are not guaranteed to survive closing or restarting the mini program.

During a save, repeated submissions are limited. An unknown result keeps the input and offers a retry of the original operation. Retry continues that request, while reloading fetches saved content. The actions are separate, with confirmation before discarding current input.

Figure 6. Private entry: optional tags, writing, and input limits.

4.3 Weather Universe: Find a Day Without Filling the Gaps

Weather Universe connects a calendar with weather cards, month archives, day details, distribution, and timeline views. The calendar answers which days contain records, while month navigation locates earlier periods. Cards provide an overview and daily details provide the fuller reading path. These views organize the same private records at different levels.

Unrecorded dates remain blank. The interface does not infer weather from nearby entries or treat a gap as an unfinished task. An empty month retains its date structure, navigation, and explanation, allowing the user to move elsewhere. Separate messages distinguish a successful empty result from a failed read.

Cloud card previews hide the note; users open private details to read it. This keeps browsing concise and reduces the exposure of longer personal text in an overview. Review uses the dates, weather, and tags from the editor, helping users recognize what they saved.

Figure 7. A recorded month in MoDao, using a fixed example to show the daily-detail entry point.

Figure 8. Weather Universe: an empty month with navigation and review entry points.

4.4 Campus: Understand the Information Before Acting

Campus addresses the intention to find somewhere quiet. It provides campus and tag filters and a place-query entry point. Filters narrow the browsing scope, and the list presents matching verified information. The current cloud query returns an empty list, with a corresponding explanation on the page.

Public campus information is separate from private records. A place query does not publish a user's weather or note, and place information is based on verification. No place details are currently available for display; navigation, favorites, corrections, and user-initiated location are also not enabled.

Figure 9. Campus: the empty place list returned by the cloud service.

Figure 10. Campus and tag filters expanded.

4.5 Optional Choices and Small Tasks

Today offers six choices under “Right now, I would like to…”: record something, find a quiet place, write a few words, do something small, look back, or do nothing for now. These intentions connect to existing pages without requiring users to identify the relevant feature category first.

Rest and cancellation leave the current draft unchanged and create no record. Keeping this choice alongside the others allows the user to decide whether to continue. Recording a feeling does not create an obligation to complete an activity afterward.

Tasks use a secondary page reached through “Do something small,” without adding another main tab. The current page states that private cloud tasks are not yet available and shows an empty suggestions list. Joining, completing, and skipping tasks are not enabled.

Figure 11. Tasks: private cloud tasks are not yet available; suggestions are empty.

4.6 Me and Account Data

Me explains private records and privacy, with entry points for account data and task history. Daily recording stays on Today, while data management has a stable place under Me. This arrangement keeps less frequent account controls accessible without adding them to the recording screen.

Account and Data provides JSON and Markdown export controls. JSON preserves structured fields, while Markdown is suitable for reading and keeping a personal copy. Processing, readiness, and expiry appear as separate stages after a request, distinguishing file generation from collection.

Account closure has two stages: private access stops first, followed by background cleanup. The page explains the impact and provides status and progress controls. Stopped access and completed cleanup have separate states, allowing the user to follow processing progress.

Figure 12. Me: private records, privacy information, and account entry points.

Figure 13. Account and Data: explanations of export and account closure.

5. Design Challenges and Improvements

5.1 Keeping Input Short Without Restricting Expression

The design balances the effort of a full writing form against the limits of fixed icons. Putting weather, tags, text, and additional suggestions on the first screen would also make users identify which fields were required before starting.

We divide input into two levels. Weather remains on the first screen as the minimum record. Tags and text belong to the optional editor, and Custom reveals its name field when selected. Users can finish a brief choice or continue into more detail within the same journey.

An existing record continues through the edit action, with additional tags and text belonging to the same day. Different views before and after saving distinguish creation from editing. This solution combines page hierarchy, required fields, and action meanings to reduce initial input while preserving room for detailed expression.

5.2 Explaining an Unknown Save Result

A save may reach the server even when its response does not reach the client. A general “save failed, please save again” message would leave the original request's outcome unclear and raise questions about repeated clicks.

We handle processing, confirmed results, and unknown results separately. During saving, repeated submission is limited. An unknown result retains the input and original operation for retry. Reloading has its own entry point and confirmation before discarding a draft. A confirmed version conflict moves to reloading and a further decision about the content.

Existing local controller and page regression tests cover original-operation retries, retained input, and conflicts. Recovery retains the context of the original record operation, connecting interrupted handling with the normal save journey.

This challenge brought attention to the meaning of feedback. The resulting interface separates continuing the original request from reading saved content, and button wording follows the operation state. Users can choose how to continue based on that distinction.

5.3 Making Privacy Understandable

Private entries and campus information use similar cards, which can make their different visibility scopes less apparent. Explaining privacy only on the account page would also leave it distant from the moment of writing or browsing.

Recording pages therefore keep the private scope visible. Cloud review cards hide the note, and private details provide the full reading view. Campus carries public place information separately, and the current cloud build does not aggregate private entries into public campus weather. Account and Data connects this separation with export and closure explanations.

Privacy explanations appear at entry, browsing, and confirmation points. Alongside account isolation and access restrictions, they define the boundary of private records. The design keeps card browsing concise and provides a clear entry point for reading the note throughout the recording journey.

5.4 Consistent Weather and Records Across Pages

Weather selection, private editing, and review span several pages, so a changed name or field can affect the whole recording journey. Independent definitions could show different names or categories when saving and reviewing the same record.

Today and the editor use the same seven weather definitions, with wind-and-rain variants grouped under Stormy. Saved weather, dates, and tags carry into review, and custom names remain with their records. Notes stay hidden in overviews and are read in private details, maintaining consistent selection and display behavior.

This integration shows that interface consistency includes data and action meanings. Shared weather definitions connect different members' pages, while the relationship between a date and its entry supports continuous creation, editing, and review.

6. Schedule and Progress

Stage	Work focus	Results
Requirements analysis	Define the user journeys and private scope.	Requirements and the SRS establish the main page structure.
Visual and interaction design: October 28	Organize shared styles and interaction rules.	Weather icons, shared styles, and the main page layouts are available.
Working prototype: October 30	Connect recording, private review, and account-data interfaces.	The 0.3.0 build provides the core record and review journey; Campus has an empty list and private tasks are not enabled.
Integration and review	Align page behavior, service results, and recovery states.	Local regressions cover retry and conflict paths; recorded phone feedback confirms that saved entries remain readable after reopening.
MoDao online prototype: November 1	Organize the main pages, states, and interaction paths.	A browser-accessible interaction demo and 20-screen state overview connect recording, editing, and review.
Design documentation: October 31–November 1	Explain the design process, interfaces, and interaction decisions.	Main interfaces and interaction flows are described alongside design challenges, solutions, and team responsibilities.

7. Team Discussion and Reflection

7.1 Design Discussion Topics

The main design choices concern input, cancellation, and content display. Weather is the main input, tags and writing remain optional, and custom naming adds room for expression. Saved entries have an edit action, while cancelling deletion and keeping a draft each have their own paths.

Content is organized by purpose. Private cards provide an overview and details contain the note. Campus carries public place information, and Tasks states its availability. Empty Campus results and unavailable tasks have explicit explanations, distinct from the normal recording and review journey.

Together, these choices let users complete a quick record while retaining control over adding detail, deleting content, and opening another page. Continuity and personal choice remain part of the same interaction design.

Figure 14. Team members during a project discussion.

7.2 Reflection on Collaboration

The prototype makes the links between responsibilities concrete. Shared visual materials provide a reference for icons, wording, and layout. Recording and review connect around the same day's content, Campus presentation relates to information verification, and account feedback follows data-processing stages.

Jiaqi Zhu's visual and interaction materials support consistency. The connection between Yifan Ji's and Zhifeng Dai's pages supports finding a record after saving, while Xiang Yu's work on data scope and processing states informs the account explanations. Exceptional-flow and privacy checks add details beyond normal operation, including retained input, cancellation, and the placement of private notes.

For us, the most valuable part of collaboration is connecting separate pages into complete interactions. Interface, business, and data contributions meet in save feedback, review displays, and account progress, making the team's individual work usable as a continuous journey.

8. Next Steps

The project now includes a MoDao prototype with 20 screens and states alongside the mini program implementation connecting recording, private editing, review, and account-data pages. Further interface work focuses on small-screen reading, keyboard placement, touch targets, and long content. Campus details still depend on suitable verified information, and private task operations are not yet enabled; these areas will build on the existing entry points and state explanations.