Customer Milestone 2 Report of CMPE 451 Fall 2025
This is the milestone report for our group project, bounswe2025group5. We are a group of dedicated students, committed to building WasteLess, a comprehensive platform designed to empower users to track, manage, and reduce their environmental footprint through features like waste logging, community challenges, and a supportive forum. This report is written for primarly addressing the deliverables and current status of the project.
- Abdurrahman Arslan
- Serdar Bahar
- Abdülkerim Kasar
- Yusuf Onur Öksüz
- Cengiz Bilal Sarı
- Yüksel Eren Şen
- Osman Yusuf Tosun
- Emre Kılıç
- Arda Yalçındağ
- Bartu Konca
- 1. A Summary of the Customer Feedback and Reflections
- 2. List and Status of All the Project Deliverables
- 3. Evaluation of the Status of Deliverables and its Impact on the Project Plan
- 4. Evaluation of Tools and Processes Used to Manage the Team Project
- 5. The Requirements Addressed in This Milestone
- 6. Planning and Team Process
- 7. Utilized Standards
- 8. UX Design
- 9. Testing
- 10. Individual Contributions
The Milestone 2 presentation was executed successfully, adhering to the planned demonstration strategy and flow that was approved by the customer in the Milestone 1. The session concluded with a discussion where both the development team and the client expressed satisfaction with the project's current trajectory. The client validated our progress, particularly noting the effective integration of feedback from the previous milestone, though specific areas regarding user notification context and demonstration data management were highlighted for further refinement.
The client provided constructive and insightful feedback that will guide our next iterations of the project:
-
Activity Stream: During the discussion the client raised a question regarding the Activity Stream in our project, regarding the specificity of notifications. The feedback emphasized that a notification such as “User X liked your post” is insufficient for a good user experience. The client suggested that users must understand exactly which event triggered the notification (e.g., “User X liked your post P”).
-
Current State: Although our backend logs the exact event history, the frontend notification UI was not displaying the specific post reference.
-
Agreed Solution: As discussed during the demo, since our posts do not utilize headers or titles, we plan to implement a solution where the first few words of the post body are included in the notification to serve as a context indicator.
-
-
Impact Visibility Follow-up: The client inquired about the status of "Impact Visibility," a key feedback that was carried over from Milestone 1. We confirmed that the feature has been implemented across the mobile application logic. However, the full demonstration of this feature in our scenario was constrained by the specific test user chosen for the live demo.
-
Challenge Standardization & Unit Logic: The customer questioned the current lack of strict type specification within the Challenge system. Currently, when a challenge is created, specifications are text-based, and user logs are recorded as generic "amounts" without defined units. The client emphasized the need for precision here.
- Agreed Solution: We will align the Challenge system with the structured logic currently used in our "Waste Logging" feature. This involves implementing a rich, predefined unit pool for every recycling type. Furthermore, we will assign weighted "points" to these items based on their physical impacts. Consequently, the Challenge Leaderboard will be refactored to depend on these standardized points rather than raw counts, ensuring a fairer and more accurate gamification system.
-
Overall Assessment: The customer expressed satisfaction with the team’s responsiveness to previous feedback and the successful implementation of core functionalities presented in Milestone 2. The critique received was primarily focused on refining logical consistency (specifically in the Challenge domain) and enhancing User Experience (UX) regarding notifications, rather than identifying structural failures. The client validated that the project is on the correct path and that the proposed solutions for the identified issues were acceptable.
-
Enhancing Notification Granularity: The team acknowledges that context is crucial for user engagement. While our backend architecture correctly adhered to Activity Streams 2.0 standards by linking actors to objects, our frontend presentation oversimplified this data. We realized that without explicit post titles, the user experience suffers from ambiguity. We have decided to implement a text-truncation utility on the frontend that extracts a "preview snippet" from the post body. This will allow us to provide meaningful context in notifications without requiring structural changes to our post data model. Another option is to provide image preview from the image attached in the post. However; because posts do not necessarily have image attachments, this feature cannot be enforced for all notifications. In the light of this, we decided to implement an image preview for posts including image attachments.
-
Demo Data Preparation Strategy: The inquiry regarding "Impact Visibility" highlighted a flaw in our demonstration preparation rather than our development. While the feature was fully coded, we failed to showcase it effectively because we relied on a fresh user account with insufficient historical data during the live walkthrough. For the future milestone, although we have previously populated the application database with quality-rich data, we will prepare specific demo accounts pre-populated with rich, historical activity logs to ensure that statistical features and impact visualizations are immediately apparent to the audience.
-
Overall Assessment: From the team's perspective, Milestone 2 was a success that validated our development quality and architectural choices. The feedback regarding the "Challenge Standardization" is significant; we recognize that aligning the Challenge logic with the Waste Logging logic is not just a UI fix but a necessary backend refactor to ensure the integrity of our gamification system. We are confident that addressing these logical gaps will result in a highly polished final product for the next milestone.
| Deliverable | Status | Related Link |
|---|---|---|
| Requirements | Done | Requirements |
| Use Case Diagram | Done | Use Case Diagram |
| Class Diagram | Done | Class Diagram |
| Sequence Diagram | Done | Sequence Diagram |
| Project Plan | Done | RoadMap General Plan |
| Git Contribution Plan/Standards | Done | Contribution Guidelines |
| Communication Plan | Done | Communication Plan |
| Meeting Notes | Done | Lab Reports Meeting Notes Team Meeting Notes |
| Individual Contributions | Done | Individual Contributions |
| Pre-Release Of The Software | Done | 0.2.0-beta |
| (Extra) Postman Collections | Done | Postman |
To keep track of each other's progress and to plan/work on the deliverables, we had weekly meetings and lab sessions. During the weekly meetings, we shared tasks among us, discussed implementation details and planned our next steps; moreover, we went through the issues and prioritized the important issues among the open ones to move forward more efficiently. During the lab sessions, we prepared and planned the deliverables, and we also documented our discussions during these sessions. These sessions and meetings helped us get quickly organized and be aware of each other's tasks and progresses.
We have written the milestone review to reflect on our progress. It has helped us to see how different components of the project complements each other and come together to make the project feel more complete. We reflected on our deliverables and saw if we have completed them as planned, we understood the importance of adhering to standards to make communication between different parts simpler, and how testing has helped the development phase to detect problems early on.
In order to show the current status of the project, we have created the pre-release version of the application. Before this release, we finished up the remaining functionalities and added tests to detect errors and bugs early on. For the backend, we added unit tests to check if each independent part works correctly; moreover, we used Postman for End To End and Integration tests which helped multiple developers to test the functionalities in parallel before deployment. For the frontend, we used unit tests to see each component working as expected. During the demo, we presented this version of the application which worked without any bugs thanks to meticuluous testing.
In the first milestone, our instructions for building the application were not complete, and we believe we have fixed it by being more clear and addressing each step during deployment.
In the first phase of project development, i.e. the planning phase, we thought a main functionalities milestone would be fitting for the Minimum Viable Product milestone. For this milestone, we prioritized data visualization and the notifications. Adding this milestone helped us finish these before the actual milestone, leaving room for further testing. This way, we were able to deliver the final functionalities without issue.
For End to End and Integration tests, we used Postman which helped us easily tests if the endpoints work as intended together. Our Postman Collection could be visited here.
For this milestone, we were able to deliver a working product by completing the deliverables in time and as expected. Thanks to testing, our application works well and satisfies the requirements for a Minimum Viable Product. Moreover, by organizing efficiently, we delivered the product in time without delay. We also believe we were able to address the feedback given in the first milestone i.e. writing the deployment instructions more clearly, dockerizing the mobile app, updating the sequence diagrams, making the roadmap more specific etc.. Overall, our planning helped us stay on track and we mostly adhered to it.
- Postman : An API platform for building, testing, and documenting RESTful APIs. It allows developers to send HTTP requests, inspect responses, and automate API testing workflows. We continue to use postman to track our endpoints and do integration and end-to-end tests from it by reviewers.
- Figma : A collaborative web-based design tool used for UI/UX design. It enables teams to create wireframes, prototypes, and interface mockups in real time. The frontend team continue to use it for tracking design easily.
- Docker : A containerization platform that packages applications and their dependencies into lightweight containers. It ensures consistent behavior across different environments.IT IS THE MOST IMPORTANT ADDITION OF TOOL FOR THIS MILESTONE that is used to create reproducible build environments for generating Android APKs, eliminating the need for complex local setup.
- DigitalOcean : A cloud infrastructure provider offering scalable virtual machines (droplets), managed databases, and other tools for deploying and managing applications. We continue to use it for our application services (db, backend, frontend ,vector db etc.).
- Expo : A framework and platform for universal React applications. It helps you develop, build, and deploy React Native apps quickly, often without needing to touch native code. The mobile team used it for creating APK fast, but the DOCKER is used for the release of APK.
- Android-Studio : The official IDE for Android development, which includes tools to test Android apps on virtual devices called emulators.
- Cursor & Copilot : AI agents and helpers for coding that assist in code generation, debugging, and refactoring.
- Jest : A comprehensive JavaScript testing framework used for unit and integration testing. It is the standard choice for testing React Native mobile applications and provides built-in support for mocking and snapshot testing.
- Vitest : Aunit test framework powered by Vite. It is optimized for modern web development and is used for efficiently testing frontend applications, offering a faster alternative compatible with the Jest API.
We classify the status of the requirements as follows:
- ✅ Milestone 1 : Requirements that we finished at milestone 1.
- ☑️ Milestone 2: Requirements that we finished at milestone 2.
- 🔜 Milestone 3: Requirements that will be implemented in the milestone 3.
| Requirement Number | Description | Status |
|---|---|---|
| 1.1 | User Requirements | |
| 1.1.1 | Account Requirements | |
| 1.1.1.1 | Users shall be able to register for the system using an email, a username and a password. | ✅ Milestone 1 |
| 1.1.1.2 | Registered users shall be able to log in to the system with valid credentials. | ✅ Milestone 1 |
| 1.1.1.3 | Registered users shall be able to reset their passwords. | 🔜 Milestone 3 |
| 1.1.1.4 | Registered users shall be able to permanently delete their accounts... | ✅ Milestone 1 |
| 1.1.1.5 | Registered users shall be able to log out from the system. | ✅ Milestone 1 |
| 1.1.1.6 | Registered users shall be able to display their waste reduction statistics. | ☑️ Milestone 2 |
| 1.1.1.7 | Registered users shall be able to edit their profile, including username and goals. | ✅ Milestone 1 |
| 1.1.1.8 | Registered users shall be able to set and update their waste reduction goals... | ✅ Milestone 1 |
| 1.1.1.9 | Registered users shall be able to upload a profile picture up to 2MB in size. | ✅ Milestone 1 |
| 1.1.1.10 | Unregistered users shall have limited, read-only access to the application... | ✅ Milestone 1 |
| 1.1.2 | Waste Tracking Requirements | |
| 1.1.2.1 | Registered users shall be able to log their daily waste generation in grams or kilograms. | ✅ Milestone 1 |
| 1.1.2.2 | Registered users shall be able to categorize waste into at least five predefined types... | ✅ Milestone 1 |
| 1.1.2.3 | Categorized waste shall be tracked using different units based on the type... | ✅ Milestone 1 |
| 1.1.2.4 | Registered users shall be able to view historical waste data for at least the past 12 months. | ☑️ Milestone 2 |
| 1.1.2.5 | Registered users shall be able to visualize historical waste data through charts and bar graphs. | ☑️ Milestone 2 |
| 1.1.3 | Gamification and Challenge Requirements | |
| 1.1.3.1 | Registered users shall be able to join community sustainability challenges... | ✅ Milestone 1 |
| 1.1.3.2 | Registered users shall be able to earn points for logging recycling. | 🔜 Milestone 3 |
| 1.1.4 | Post Requirements | |
| 1.1.4.1 | Registered users shall be able to create and share posts containing tips... | ✅ Milestone 1 |
| 1.1.4.2 | Registered users shall be able to delete their own posts. | ✅ Milestone 1 / ☑️ Milestone 2 (web) |
| 1.1.4.3 | Moderator shall be able to see reports that are sent by users about a post. | 🔜 Milestone 3 |
| 1.1.4.4 | Moderator shall be able to delete a post if it includes inappropriate words... | 🔜 Milestone 3 |
| 1.1.4.5 | Registered users shall be able to save posts. | ✅ Milestone 1 |
| 1.1.4.6 | Registered users shall be able to like posts. | ✅ Milestone 1 |
| 1.1.4.7 | Registered users shall be able to comment on posts. | ✅ Milestone 1 |
| 1.1.4.8 | Registered users shall be able to share posts. | ✅ Milestone 1 |
| 1.1.5 | Incentive ,Reward and Feedback Requirements | |
| 1.1.5.1 | Registered users shall be able to view available badge that they receive... | 🔜 Milestone 3 |
| 1.1.5.2 | Registered users shall be able to take badges from the forum activities automatically. | 🔜 Milestone 3 |
| 1.1.5.3 | Users shall submit feedback, suggest improvements... | 🔜 Milestone 3 |
| 1.2 | System Requirements | |
| 1.2.1 | Performance and Storage | |
| 1.2.1.1 | The system shall store user data, including waste logs... for a minimum of 3 years. | ✅ Milestone 1 |
| 1.2.1.2 | The system shall process and update waste reduction analytics within 5 seconds... | ✅ Milestone 1 |
| 1.2.2 | Waste Tracking Requirements | |
| 1.2.2.1 | The system shall generate weekly and monthly visual reports summarizing waste data. | ☑️ Milestone 2 |
| 1.2.2.2 | The system shall calculate and display the percentage reduction in waste over time. | ☑️ Milestone 2 |
| 1.2.2.3 | The system shall generate graphs and charts for visualizing waste data. | ☑️ Milestone 2 |
| 1.2.3 | Gamification and Incentive Requirements | |
| 1.2.3.1 | The system shall maintain leaderboards displaying the top 10 users in each challenge... | ✅ Milestone 1 |
| 1.2.3.2 | The system shall assign achievement badges when users reach predefined milestones... | 🔜 Milestone 3 |
| 1.2.3.3 | The system shall provide a badge catalog where each badge is described. | 🔜 Milestone 3 |
| 1.2.3.4 | The system shall assign achievement badges when users are in the first three places... | 🔜 Milestone 3 |
| 1.2.4 | Notification System Requirements | |
| 1.2.4.1 | The system shall send notification to people for their progress about the goals... | ☑️ Milestone 2 |
| 1.2.4.2 | The system shall send notification to people for the update of the leaderboard situation. | 🔜 Milestone 3 |
| 1.2.4.3 | The system shall send notifications for likes and comments to their posts. | ☑️ Milestone 2 |
| 1.2.4.4 | The system shall send notifications when users they follow share a post. | ☑️ Milestone 2 |
| 1.2.5 | Post Requirements | |
| 1.2.5.1 | The system shall support text, image, and link attachments in shared posts. | ✅ Milestone 1 |
| 1.2.5.2 | The system shall include tagging and categorization features... | 🔜 Milestone 3 |
| 1.2.5.3 | System shall provide semantic search over forum page. | ☑️ Milestone 2 |
| 1.2.5.4 | The system shall display a reminder message encouraging kindness... | ☑️ Milestone 2 |
| 1.2.6 | Standardization Requirements | |
| 1.2.6.1 | The system shall model user interactions... using standardized vocabularies... | ☑️ Milestone 2 |
| 1.2.6.2 | The system shall represent user actions following the W3C Activity Streams 2.0... | ☑️ Milestone 2 |
| 1.2.7 | Localization Requirements | |
| 1.2.7.1 | The system shall provide locale support where users can switch between Turkish and English... | ✅ Milestone 1 |
| 1.2.7.2 | The system shall have a default locale set to English... | ✅ Milestone 1 |
| 2 | Non-Functional Requirements | |
| 2.1 | User Experience Requirements | |
| 2.1.1 | Performance Requirements | |
| 2.1.1.1 | The system shall provide a response time of under 2 seconds for 95% of user actions... | ✅ Milestone 1 |
| 2.1.2 | Usability and Accessibility Requirements | |
| 2.1.2.1 | The platform shall support multilingual functionality... | ✅ Milestone 1 |
| 2.1.2.2 | The system shall provide tooltips, tutorials, or onboarding guides... | ☑️ Milestone 2 |
| 2.1.2.3 | All form inputs shall include inline validation to prevent errors before submission. | ☑️ Milestone 2 |
| 2.1.2.4 | The system shall require users to confirm critical, irreversible actions... | ☑️ Milestone 2 |
| 2.1.2.5 | All non-text content (images, icons, charts) shall have meaningful text alternative... | ☑️ Milestone 2 |
| 2.1.2.6 | Minimum color contrast ratio of 4.5:1 for text... | ☑️ Milestone 2 |
| 2.1.2.7 | Interactive elements shall be fully operable via keyboard. | ☑️ Milestone 2 |
| 2.1.2.8 | Visible focus indicators for all interactive elements... | ☑️ Milestone 2 |
| 2.1.2.9 | Navigational components shall be placed consistently through web pages. | ☑️ Milestone 2 |
| 2.1.3 | Waste Tracking Requirements | |
| 2.1.3.1 | The system shall ensure waste tracking data is updated in real-time... | ☑️ Milestone 2 |
| 2.1.3.2 | The waste tracking module shall support batch data entry... | ☑️ Milestone 2 |
| 2.2 | Scalability Requirements | |
| 2.2.1 | The platform should be designed for horizontal scalability... | 🔜 Milestone 2 |
| 2.3 | Security Requirements | |
| 2.3.1 | User data shall be encrypted to prevent unauthorized access and data breaches. | ✅ Milestone 1 |
| 2.3.2 | The system shall enforce strong password policies that new passwords must be at least 8 characters long... | ☑️ Milestone 2 |
| 2.3.3 | The platform should comply with Turkish KVKK... | ✅ Milestone 1 |
| 2.3.4 | System shall ask user for KVKK approval to register. | ✅ Milestone 1 |
| 2.3.5 | During registration, the system shall only require the minimum data necessary... | ✅ Milestone 1 |
| 2.3.6 | System shall enable HTTPS access to the server... | ✅ Milestone 1 |
| 2.4 | Portability & Compatibility Requirements | |
| 2.4.1 | The platform shall function correctly on modern web browsers... | ✅ Milestone 1 |
| 2.4.2 | The platform shall be responsive and function correctly on mobile devices... | ☑️ Milestone 2 |
| 2.4.3 | The platform shall support at least one screen reader... | 🔜 Milestone 3/ ☑️ Milestone 2 (partially done) |
| 2.4.4 | The platform shall support text resizing up to 200%... | 🔜 Milestone 3 |
| 2.5 | Eco-Requirements | |
| 2.5.1 | The platform shall prioritize hosting providers with certified renewable energy usage... | 🔜 Milestone 2 |
Customer feedback is the main factor that leads us to adjust our plans, and our current implementation process is built to respond to these changes quickly. After the customer asked us to include the impact visualization feature, we updated our plan and made the necessary adjustments without disrupting the existing roadmap. We created a Main Functionalities Milestone to define the essential customer-facing features needed before handover, such as data visualization and notifications. During weekly meetings and lab sessions, we decided which issues belonged in Milestone 2 and focused first on tasks that blocked other development work. These priorities were also reflected in our Project page roadmap, allowing us to schedule blocking tasks earlier and avoid delays caused by dependencies.
We will plan our next steps based on the feedback we received but sticking with the original plan as much as possible. First, we will work on improvements that make the platform clearer for users, such as adding context to notifications and preparing demo accounts with richer data. After that, we will focus on larger structural updates like standardizing challenge units and improving the scoring system. By prioritizing work this way, we make sure we respond to real user needs and deliver meaningful improvements in a practical and focused manner.
We included details of Project Roadmap and the Board View in our Milestone 3 Plan.
In the design phase of our application, we took some of the W3C standards into consideration to achieve a standardized and more accessible web/mobile application. The research about the standards and their relevance to our project is documented in a W3C Standards Report in our repository wiki. The key standards we have followed in practice are WCAG 2.1 AA, Activity Streams 2.0, and i18n.
The Web Content Accessibility Guidelines (WCAG) is an international standard developed by the World Wide Web Consortium (W3C) to achieve a single shared standard for web content accessibility. It aims to ensure that web content is accessible for all people, especially people with disabilities. The guidelines address the needs of individuals, developers, and international governments.
In our project, we aim to conform to AA-level standards in the WCAG 2.1 guidelines document. Although we have several guidelines covered, we don't plan to achieve full coverage due to the very large range of guidelines in the document. However, we are covering the fundamental ones that are needed to have an accessible application. The full table of covered/to be covered standards in the WCAG 2.1 AA document is the following (the Requirement section refers to requirements in the SRS, and the WCAG 2.1 Standard section refers to standards in the original document):
| Requirement | WCAG 2.1 Standard |
|---|---|
| 2.1.2 Usability Requirements | |
| 2.1.2.5 All non-text content (images, icons, charts) shall have meaningful text alternative or label. | 1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose. |
| 2.1.2.6 Minimum color contrast ratio of 4.5:1 for text and 3:1 for large text/UI shall be maintained. | 1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1 and large-scale text and images of large-scale text have a contrast ratio of at least 3:1. |
| 2.1.2.7 Interactive elements shall be fully operable via keyboard. | 2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. |
| 2.1.2.8 Visible focus indicators for all interactive elements (keyboard, mouse etc.) shall be provided for all interactive elements. | 2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. |
| 2.1.2.9 Navigational components shall be placed consistently through web pages. | 3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple web pages within a set of web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. |
| 2.4 Portability & Compatibility Requirements | |
| 2.4.3 The platform shall support screen readers such as NonVisual Desktop Access (NVDA) and VoiceOver. | 4.1.2 Name, Role, Value: For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. |
| 2.4.4 The platform shall support text resizing up to 200% without loss of content or functionality. | 1.4.4 Resize Text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. |
In this section, we will go over the intended WCAG 2.1 standards one by one and explain how we achieved that standard on both web and mobile. Note that some of them are either not implemented or partially implemented. We included all of them to conduct a comprehensive analysis on WCAG 2.1 compliance of our application.
1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose.
In the frontend, the whole code is revised and added alternative texts for image elements or components that contain image somehow such as avatars in posts. Text alternatives had been already provided generally for non-text content while the code was revised (provided while writing the code), but we also enhanced the text alternatives by providing variables in the text alternatives such as user names an including translations for text alternatives. Including a text alternative for a non-text item is done by adding a alt='text alternative' or aria-label='text alternative', generally with a translation. Here is an example, text alternative for application logo:
<img
src={logo}
alt={t ? t('navbar.logoAlt', 'WasteLess application logo') : 'WasteLess application logo'}
className="h-23 w-auto"
/>In the mobile application, the code is revised and added text alternatives to non-text content, specifically for icon-based buttons. We enhanced the user interface by incorporating visible text labels alongside icons for actions like editing, deleting, saving, and reporting content. Including a text alternative for a non-text item is done by adding a Text or ThemedText component adjacent to the icon component, using translation variables to support localization. Here is an example of adding a text label to an edit button:
<TouchableOpacity
onPress={() => onEdit(post)}
style={styles.actionIcon}
>
<Ionicons name="pencil" size={20} color={editIconColor} />
<ThemedText style={[styles.actionText, { color: editIconColor }]}>
{' '}{t('edit')}
</ThemedText>
</TouchableOpacity>1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1 and large-scale text and images of large-scale text have a contrast ratio of at least 3:1.
In the frontend, just like in the text alternatives, we revised the UI manually and with assistance of AI to see if there is a contrast ratio inconsistent with our standard. Only places we detected a problem were welcome page, motivation, page, and the translation buttons. We have adjusted the color values so that the minimum contrast ratio required is achieved.
In the mobile application, we performed a review to ensure all text elements meet the minimum contrast ratio standards. To achieve this across both light and dark modes, we implemented a dynamic contrast utility and a new AccessibleText component. This system accepts the background color of an element (like a card or button) and automatically calculates the most readable foreground color (e.g., switching between black or white) to ensure the contrast ratio stays above the required threshold (4.5:1 for normal text). Here is an example of a button using this dynamic contrast logic:
<TouchableOpacity
style={[
styles.authButtonFull,
{ backgroundColor: loginBg, borderColor: themeColors.borderColor },
]}
onPress={() => setIsRegistering(false)}
>
{/* The text color is programmatically picked based on loginBg */}
<Text style={[styles.authText, { color: pickAccessibleTextColor(loginBg) }]}>
{t("backToLogIn")}
</Text>
</TouchableOpacity>2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.
In the frontend, the application is revised comprehensively and tested manually whether keyboard navigation is supported or not. According to our revision, our web application can be navigable and operable through keyboard. The frontend code is written in a way that it supports keyboard navigation inherently.
This standard is not applicable for the mobile application.
2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
In frontend, the UI is revised manually with both keyboard and mouse to check whether they have focus indicators or not. The UI of our application was fully compliant with the requirement in the revision. The focus indicators are implemented manually while the code is generally written with a Tailwind CSS class arguments, i.e. hover. Here is an example of an focus indicator achieved with a reduced opacity (90%):
default: "bg-primary text-primary-foreground hover:bg-primary/90"This standard is not applicable for the mobile application.
3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple web pages within a set of web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.
In frontend, the consistent UI elements such as the navigation bar is places consistently in every page by including it in the layout file and using layout file in all pages. Also the placement of content cards are also defined as the same in every page to have a consistent navigational items. Later, the UI is checked as in the previous accessibility features and it is found out that our UI is compliant with the standard.
In the mobile application, consistent navigation is achieved by utilizing a centralized Tab Layout that remains persistent at the bottom of all main screens, ensuring users can predictably switch between key features. We also implemented a standardized header and content structure across individual screens to maintain visual and functional consistency. A review of the user interface confirmed that navigation mechanisms are repeated identically across the application, complying with accessibility requirements for consistent identification.
4.1.2 Name, Role, Value: For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.
This standard is strictly relevant to the "Non-Text Content" standard for the frontend. Since the Assistive technologies such as VoiceOver uses alt attributes and aria-labels, having an application with meaningful labels make VoiceOver successful on our application. The VoiceOver is tested in our application and it is working by default. Although we did some work on this topic, there is still some problem such as VoiceOver not active in dialogs. The full compliance and seamless experience with VoiceOver will be finished in the final milestone.
In the mobile application, we have integrated the necessary accessibility properties into our components, ensuring that names, roles, and states can be programmatically determined. While the implementation code covers these standards, we have not yet conducted formal testing with screen readers like VoiceOver or TalkBack. Validation of the user experience with these assistive technologies is scheduled for the final milestone.
1.4.4 Resize Text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.
In the Frontend, the whole UI can be resized up to 200% with the zoom in/out feature of browsers. However, we haven't implemented a in application text resizing feature yet. It is planned to be implemented for the last milestone.
In the mobile application, text resizing is primarily supported through the operating system's accessibility settings (Dynamic Type on iOS and Font Size on Android). Our text components are designed to respond to these system-level scale factors automatically. Comprehensive testing for 200% resizing and necessary layout adjustments are planned for the final milestone.
#562: Parent issue for all accessibility features for frontend
- #573: Non-text Content
- #571: Contrast (Minimum)
- #576: Keyboard
- #637: Focus Visible
- #638: Consistent Navigation
- #704: Name, Role, Value
#558: Parent issue for all accessibility features for mobile
Activity Streams 2.0 defines a JSON data model for describing social activities, such as liking posts, following other users or any other action performed by an actor on an object.
In our project, we use this standard to structure our notifications in a consistent and semantically meaningful format. Although Activity Streams 2.0 does not define notification delivery or system side reactions, it provides a semantic model for describing actions that other subsystems can interpret.
Our project uses the Activity Streams 2.0 formatted activity data to drive internal notification behavior. This approach aligns with the intended use of Activity Streams 2.0, providing structured, semantically clear descriptions of actions.
Activity Streams 2.0 requires the inclusion of an @context field to declare the semantic vocabulary so that external processors can interpret the document correctly. The activity log produced by the system includes "@context": "https://www.w3.org/ns/activitystreams", declaring that all fields in the activity object follow the Activity Streams 2.0 vocabulary. This makes the logged activities interpretable by Activity Streams 2.0 compatible systems.
Activity Streams defines fields such as:
-
type —> the kind of activity performed
-
actor —> the entity performing the action
-
object —> the item upon which the action was performed
-
target —> an optional secondary entity
-
published —> timestamp of the activity
In our project, the notifications include all these fields:
-
The type field reflects the activity verb e.g., Like, Comment, Create.
-
The actor field contains a nested structure with type and id, describing who performed the action.
-
The object field contains a similar nested structure describing the entity that is affected.
-
The target field is includes the list of users affected by the event i.e. the users that will be notified.
-
The published field is generated using an Java's time class, which aligns with Activity Streams 2.0’s expectation for timestamp formatting.
Our model matches the Activity Streams 2.0's conceptual model for activities and ensures structural compliance.
Activity Streams 2.0 encourages the use of globally unique identifiers i.e. id's within actor, object, and target representations.
In our project, each entity that is placed into the logger and notification structure includes an id field. While the identifiers in the current system are internal identifiers rather than full IRIs, they satisfy the structural requirement. The model is extensible so that these identifiers can later be replaced with URLs if inter-service interoperability is desired.
Activity Streams 2.0 activities must be represented in a JSON format.
In our project, all activity logs and notifications are serialized as JSON objects consistent with the Activity Streams 2.0 structure. The output is loggable, parsable, and could be used directly by Activity Streams 2.0 compatible processors.
- The Issue: This issue describes the functionality of logging activites and sending notifications.
- Main PR: In this PR, the functionality of sending notifications were added.
- Last PR: Before this PR, the notifications were sent as a message. In this PR, they were changed so that they sent the relevant fields, and the message would be constructed in the frontend.
Here are some examples logs The first one is the log created when a comment has been created.
{"@context":"https://www.w3.org/ns/activitystreams","type":"Create","actor":{"type":"User","id":"Cengiz Bilal"},"object":{"type":"Comment","id":48},"target":{"type":"User","id":"CuriousBartu"},"published":"2025-11-08T13:59:49.423450Z"}
The second one is the log created when a post has been liked.
{"@context":"https://www.w3.org/ns/activitystreams","type":"Like","actor":{"type":"User","id":"Cengiz Bilal"},"object":{"type":"Post","id":46},"target":{"type":"User","id":"CuriousBartu"},"published":"2025-11-08T15:28:12.363020Z"}
Internationalization (i18n) is the design and development process that ensures an application can be adapted to various languages, regions, and cultures without engineering changes. In our design phase, we referenced the W3C Internationalization Guidelines and the BCP 47 (Best Current Practice 47) standard for language tags to build a scalable architecture.
The goal of our current implementation is to provide an infrastructure for multilingual support, specifically targeting English and Turkish. While the W3C guidelines cover a broad spectrum of requirements—including text direction (RTL/LTR), locale-specific currency formatting, and complex calendar systems—our project currently focuses on the fundamental requirements listed in our milestone report: Language/Locale Support and Content Internationalization. Advanced features such as RTL script handling and locale-aware numeric formatting will not be implemented.
In this section, we detail the specific i18n standards we adhered to during development. We prioritized the core architectural requirements needed to support a multi-language environment.
To comply with standard practices, the system must identify languages using BCP 47 language tags (e.g., "en-US", "tr-TR").
In our implementation, we utilized specific libraries to handle locale management efficiently across platforms:
-
Library Integration: For the web frontend, we integrated the
react-i18nextpackage, while the mobile application utilizes the compatiblei18nextlibrary for React Native. These libraries handle the active locale state and content loading in a centralized way. -
Fallback Mechanism: We configured the i18n initialization options to include a
fallbackLng: 'en'. This ensures that if a specific translation key is missing in the Turkish configuration, the system automatically renders the English equivalent, preventing system crashes.
Content internationalization ensures that text is not hard-coded into the UI components but is instead referenced via identifiers.
-
Resource Structure: We created dedicated JSON files for each supported language (e.g.,
en.jsonandtr.json). These files contain key-value pairs where the key acts as the structural identifier (e.g.,"navbar.home","post.create") and the value contains the actual translated text. -
Implementation in Code: Instead of hardcoding strings, our components use the translation function provided by the libraries (the
tfunction). For example, a button label is rendered programmatically using{t('button.submit')}rather than the raw string "Submit". -
Verification: To ensure reliability, we implemented unit tests that specifically verify dynamic content rendering. These tests assert that passing a specific key results in the expected string output for a given locale and verify that dynamic variables (e.g.,
{{name}}) are correctly interpolated within the text.
Internationalization is closely tied to accessibility. To satisfy WCAG 2.1 requirements alongside i18n standards, the application must communicate the current language to assistive technologies.
In our implementation, changing the application language via the i18n packages updates the context provided to screen readers. This ensures that tools like VoiceOver utilize the correct phonetic rules for the selected language (e.g., reading Turkish text with Turkish pronunciation rules rather than English ones).
NOTE: This section only covers the initialization and translation of some initial pages and components. The translation is performed throughout all development process when a text to be translated appears in the implementation.
-
#424 Initial internationalization
- Since all implementation and enhancement related issues include new language key additions after initial implementation, we only provide the initial implementation of the locales and i18n integration.
NOTE: This section only covers the initialization and translation of some initial pages and components. The translation is performed throughout all development process when a text to be translated appears in the implementation.
- #427 Initial internationalization
- #680 Unit tests covering content internationalization, verifying dynamic content
-
On a rainy afternoon, Emir is sitting in the university library working on his laptop. His external mouse stopped working after a small coffee accident, and the laptop’s touchpad has been unresponsive for weeks. He’s stuck with a keyboard-only setup, the narrow bridge between him and the digital world.
-
His friend Aylin sits beside him.
-
Aylin: “We started using this app in our dorm, WasteLess. It helps track daily waste. Want to try it?”
Emir: “Later… I can’t navigate anything right now. No mouse, no touchpad. My laptop is basically a typewriter.”
Aylin: “No problem, it’s keyboard-friendly. Even the registration works smoothly with just keys. And you may want to switch it to Turkish.” -
Curiosity wins. Emir opens WasteLess.
-
He presses Tab to go over elements. The focus ring hops to the Register button, fills the form with a username “dark_knight07”, he prefers to be anonymous in social apps, and accepts the terms and conditions.
-
Every field lights up with a clear, visible focus outline as he tabs through. Nothing jumps around unexpectedly. He sets the language to Turkish.
-
He wants to log today’s organic waste. From the main page, he presses the Tab key to navigate through the interface. Each interactive element shows a clear, visible focus outline, so he always knows where he is on the page.
-
He reaches the Goals button and presses Enter.
-
The tracking page presents a clean, minimalistic form: His Waste Impact Snapshot, 12-Month Waste Trends and previously opened Waste Goals.
-
The layout is consistent with every other page he has used so far—same spacing, same font, same button positions—so he doesn’t need to re-learn the interface.
-
Emir navigates to the previously opened ORGANIC waste goal and hits the Log button.
-
He selects Coffee grounds, 1 cup and then types "-2" to the Quantity by mistake.
-
The system prevents him from entering a non-positive number immediately.
-
Realizing he has written a wrong amount, he enters "2" instead.
-
He presses Save to submit. The page updates:
-
After logging his waste, he tabs to the left menu and opens the Challenge page. The page is already displayed in Turkish because Emir selected that earlier, and the app remembers his language preference.
-
A new challenge appears: “Plastik’siz 7 Gün”
-
The challenge card includes when it is expanded:
-
A simple, non-competitive leaderboard that shows only usernames and logs opens when the Leaderboard button is clicked.
-
Attend and Add Log buttons.
-
Emir clicks Attend.
-
After a short Attending label in an un-clickable button, the button turns to the Leave button, confirming he attended. All of the process is fully operable with the keyboard.
-
Aylin says she uses the app just as a daily waste tracker but she suggests the social side of the app as well. He navigates to the feed page and looks at posts from completely different backgrounds, goals. Especially a grandma shared a photo of herself with people she invited to the app. He likes the post and comments on it “This app really doesn’t have any limits, lets goo.”
This scenario demonstrates accessibility features that WasteLess does commit to:
Emir uses the keyboard to navigate. The visible focus outlines allow him to track his position in real time. This supports users who either prefer the keyboard or cannot rely solely on a mouse. All the interacted elements in UI have this obvious reaction for all kinds of control methods.
Every page follows the same layout structure. Users can quickly develop intuitive feelings about navigation, location of buttons etc. Also, having consistency throughout the app feels familiar, unique and very well thought of.
Challenge page shows a progress visualization to Emir but also there is numerical representation as well as a text alternative.
The challenge confirmation popup is operable entirely with Tab and Enter, ensuring no step requires precise mouse control. There is no lacking functionality for keyboard only use.
Emir can easily separate a UI element from other elements through sufficient contrast differences between the colors. Therefore, he can notice the components in the application easily and use every functionality seamlessly.
Emir types “-2,” and the system immediately flags the issue. This prevents incorrect submissions and supports users who may struggle with number formats or forms.
The scenario includes multiple design choices supporting inclusivity:
Emir switches to Turkish and sees consistent UI text, layout, and labels. Availability of different languages supports bilingual users, immigrants, and non-English speakers.
The app allows completely different user profiles to enjoy the experience. Using it solely as a tool for tracking waste and viewing logs and charts over months, using it for challenge events, using it for the social side, or any combination of these purposes is possible. Emir and Aylin use the app for different purposes from each other.
Users with all ages, races or genders can find their own motivation or goal to use this app without experiencing any difficulty or different approach related to these matters. The app does not put personal information as a basis for personas in the social side of the app. Emir hasn't even asked for such information.
The scenario is rich with ethical design elements:
Everything starts after approving the conditions. The app does not allow users to be an active user of the platform without this approval.
When he logs waste, the system stores only: category, amount and timestamp. For challenges, it's similar since only data is the amount added related to his username. No unnecessary personal data is recorded.
Emir wanted to be anonymous, so he picked up his username as “dark_knight07”. The app provides the opportunity of being anonymous and never requests the real name, age, or any sensitive data from the user.
Emir should click the attend button to participate in a challenge, and from the moment he attends, he can see the leave button to leave the challenge whenever he wants.
Data is encrypted while being transmitted via HTTPS and sensitive data is protected via hashing in the storage level. This ensures Emir’s password, waste logs, and challenge logs remain private.
Users can delete the data they provide at any time they desire. Emir can delete the posts he shared, delete his waste goals, and leave the challenge so that he is not shown in the challenge leaderboard.
Our backend testing philosophy prioritizes isolated logic verification and real-world workflow validation. We automatized the unit tests ( isolated logic tests) and also did integration and end-to-end tests manually.
-
Unit Testing: Controller Layer Tests
- Tools: Mockito.
- Methodology: We focus on testing Controllers in isolation by mocking the Service layer dependencies. Each controller has its own test class and all endpoints have tests under them.
-
Reasoning & Scenarios:
- Contract Verification: Ensures that API endpoints strictly adhere to the designed specifications regarding request/response bodies. The request and response jsons are tested and validated in tests.
-
Status Code Logic: Validates that the application returns appropriate HTTP status codes (e.g.,
200 OK,400 Bad Request,404 Not Found) under distinct logical branches, returning error for undesired cases.
-
Integration & E2E Testing: Postman Workflows
- Tools: Postman Collections and Environments.
- Methodology: We utilize comprehensive Postman collections that are shared between developers and code reviewers. These serve as our Integration and End-to-End (E2E) validation layers. It is inherently integration test since the reviewer or developer did it by log in , create , delete etc endpoints in a flow. The same copy of real db is used for these.
-
Reasoning & Scenarios:
- Full Lifecycle Validation: Unlike unit tests, these requests hit the running application, verifying the entire stack from the Controller down to the Database persistence and back.
- Workflow Simulation: We test chained user scenarios (e.g., User Registration, Login , Get Token, Create Post) to ensure state is maintained correctly across transactions.
- Quality Assurance: A feature is considered "complete" only when the developer provides a Postman collection that the reviewer can successfully execute against the test environment.
Our frontend testing philosophy focuses on verifying isolated component logic and ensuring smooth user interaction flows. We automated the unit tests and also complemented them with manual UI interaction tests during development and review.
-
Unit Testing: Component & Utility Tests
- Tools: Vitest.
- Methodology: We test components and utility functions in isolation by mocking props, hooks, or external dependencies. Each significant component has its own test file, and tests cover rendering, state transitions, and basic interaction behavior.
-
Reasoning & Scenarios:
- Rendering Verification: Ensures components render correctly under different props or states.
- Interaction Logic: Validates user actions such as button clicks, form updates, and conditional UI rendering.
- Regression Prevention Protects existing functionality from breaking after refactors or new features.
We tested backend integration of frontend manually for each implementation.
Our mobile testing focuses on keeping the React Native / Expo app stable on key user flows with lightweight automated tests.
-
Unit Tests with Jest
- Tools: Jest integrated into the Expo / React Native setup.
- Methodology: We test critical screens and view logic with mocked navigation and mock data. Tests verify that important UI elements render (buttons, forms, messages) and that basic interactions (button press, navigation call) behave as expected.
Automation in Development Workflow
-
Jest is wired into the mobile
npmscripts so tests run automatically beforenpm start, catching basic issues early. -
Obsolete and failing tests from previous semesters were removed or updated so that the suite only contains working tests aligned with the current codebase.
-
Manual E2E Checks
- For flows such as login, feed, create post, report, and notifications, we manually tested the app on emulator/devices against the real backend to confirm that the tested screens also work correctly end to end.
Abdurrahman Arslan, Group 5, Frontend Team
-
I have been primarily responsible for the frontend implementation, UI/UX design and consistency, standardization across the project. My work involves developing core features like notification system, image dailogs, challenge visualizations while ensuring API integrations and reusable component design. On top of this I maintain the ui language across the app by updating ui in detail and fixing functionalities.
-
Main contributions: For this milestone, I focused on implementing notification system, challenge visualisation and improvement over components and pages we already have. I made design changes in pages to make them share the same layout, colors and mindset. I actively participated in some feature implementation decisions and endpoint structures. In addition, I played an active role in reviewing PRs, resolving conflicts, and maintaining cross-team collaboration and design uniformity.
| Issue Explanation | Issue Link |
|---|---|
| Implemented notification system. Notification button on navbar with unread notification counter on it, popover to list notifications with unread notifications highlighted, dialog for notification object view. | https://github.com/bounswe/bounswe2025group5/issues/647 |
| Implemented visualized progress for challenges. | https://github.com/bounswe/bounswe2025group5/issues/549 |
| Implemented tests for navbar, feed page and notification system | https://github.com/bounswe/bounswe2025group5/issues/590 |
| Issue Explanation | Issue Link |
|---|
| Explanation | Link |
|---|---|
| Took the meeting notes of meeting 14 this week. | Notes |
I was a Mobile Developer with a focus on Application Accessibility. My responsibilities included ensuring the mobile application complied with WCAG 2.1 AA standards, implementing unit testing frameworks for core features, and helping out with APK generation and mobile dockerization.
My main contributions for Milestone 2 was on making the mobile application into an accessible product. I worked on accessibility violations such as non-text content and color contrast issues. I improved code coverage by writing unit tests for commenting, post creation, and waste goal interactions. In preparation for Milestone 2, I helped data population to ensure a successful demo and helped with the configuration required to build the final APK release for mobile.
- mobile/ text alternatives for non-text content #563: Identified that various UI components (icons, images) lacked descriptive text, making them inaccessible to screen readers, and fixed them by adding text alternatives.
- mobile/ enforce sufficient color contrast #564: Enforced contrast ratio in several with the required 4.5:1 standard.
- mobile/ unit tests for comments #602: Implemented unit tests using JEST covering post comment functionalities
- mobile/ apk generation for milestone 2 #710: Helped with APK generation for the mobile application
- data population before Milestone 2 #723: Contributed to data population of the application before Milestone presentation
- configurations of mobile for prod and build #729: Helped with establishing the necessary environment variables and build configurations for mobile
- #566: Added semantic labels and text alternatives to mobile image components to fix accessibility issues. (Created)
- #605: Refactored the application color theme to ensure all text meets WCAG contrast standards. (Created)
- #623: Reviewed the modal report functionality. (Reviewed)
- #626: Reviewed account deletion feature. (Reviewed)
- #651: Reviewed and contributed with a commit of notification API connection. (Reviewed)
- #677: Unit tests covering post comment, create post and waste goal functionalities. (Created)
- #716: Helped reviewing merging development code to main for Milestone 2. (Reviewed)
- #718: Reviewed .env variable integration. (Reviewed)
Note taker in Meeting 12.
Abdülkerim Kasar, Group 5, Mobile (React Native/Expo).
Group Communicator, Mobile Developer, Mobile Communicator, and Documenter.
-
Strengthened moderation and account management on mobile by adding the “Report to admins” flow for posts and comments and implementing permanent account deletion with confirmation and error handling.
Related items: #561, #624, PR #623, PR #626 -
Improved the Explore experience by refactoring navigation and refresh logic so that scroll position is preserved and infinite scrolling works smoothly without duplicate fetches.
Related items: #629, #453, PR #632 -
Enhanced forum and authentication flows before Milestone 2 by adding a mock notifications banner, integrating a real time password strength meter, fixing the “Continue as Guest” logic, and improving forum UI with profile pictures and Friends and Global feed options.
Related items: #620, #630, #628, PR #631 -
Fully integrated the mobile Notifications section with the backend and finalized its UI by connecting endpoints, adding avatars in notification bubbles, enabling navigation to related posts, and adding the “real world impact of recovered waste” texts on the login screen and other waste statistics on mobile.
Related items: #652, #653, #654, #673, PR #651, PR #661 -
Developed a comprehensive unit test suite for the mobile application in line with course guidelines (the features that I implemented or mostly took part in), covering index and authentication flows, reporting, saving posts, Explore and create post screens, notifications and the search bar.
Related items: #594, #599, #603, #604, #681, #682, #684, #685, PR #680 -
Completed final mobile bugfixes and polishing before Customer Milestone 2, including Android specific follower list issues, double loading in notifications, intermittent test failures, and contributing to APK generation and delivery for the demo.
Related items: PR #698, #710 -
As Group Communicator, maintained lab documentation and Milestone 2 reporting, including lab pages, the Milestone 2 Customer Feedback Report, and the “Status of Project Deliverables” section.
Related items: Lab 5, Lab 7, #735, #754
-
#561
Opened and implemented the “Report to admins” feature on mobile, including UI, navigation and error handling to support safe moderation in the forum. -
#629
Fixed Explore page refresh and scroll behavior, enabling infinite scrolling, correct state management and a smoother user experience. -
#652
Integrated backend notification endpoints on mobile, wiring navigation targets and preparing the Notifications screen for production use.
-
#735
Wrote the “Status of Project Deliverables” and "Unit tests" part of the Milestone 2 report, summarizing completed and pending items and how the scope evolved between milestones. -
#754
Authored the Milestone 2 Customer Feedback Report based on demo feedback and internal discussions before and after the customer session. -
#694
Coordinated and sent a detailed email to TAs about Milestone 1 feedback as Group Communicator, collecting questions from teammates and clarifying open points.
- PR #623 – “Report to admins” feature on mobile.
- PR #626 – Permanent account deletion flow on mobile.
- PR #632 – Explore page refresh fix and infinite scrolling.
- PR #631 – Mock notifications banner, password strength meter, guest flow fix, forum feed options.
- PR #651 – Notifications integration, avatars in notifications, navigation to related posts, impact messages on login.
- PR #680 – Unit tests for index and authentication, reporting, posts, Explore, create post, notifications, search bar.
- PR #698 – Final Milestone 2 bugfixes on mobile.
- PR #601 – Challenge page unit type bugfix.
- PR #661 – Visual waste reduction statistics on mobile.
- PR #677 – Unit tests written by another mobile team member.
- PR #697 – Develop to main branch pull request.
- PR #706 – Unit tests for profile page.
- PR #707 – Unit tests for edit profile page.
- Helped structure the mobile workload by opening and assigning mobile issues during and after lab hours for both MVP and Milestone 2.
- Supported infrastructure and deployment by helping the backend team obtain and use a free DigitalOcean account.
- Discussed APK status and deployment expectations with TAs and followed up to ensure the mobile app met Customer Milestone 2 requirements.
This page is a condensed summary of my main contributions between Customer Milestone 1 and Customer Milestone 2. For a detailed week by week log and time spent, please refer to my weekly contribution pages on the course wiki:
Week of 3 November
Week of 10 November
Week of 17 November
Week of 24 November
I was generally responsible for mobile development tasks, including implementing new features, fixing bugs, writing unit tests, and reviewing code for the mobile application. I also contributed to documentation, research on software standards, and repository maintenance tasks like branch cleanup and release management.
- Implementing mobile application features (waste log visualization, challenge page functionality)
- Writing unit tests for mobile application (profile page, index page, challenges page)
- Fixing bugs and improving mobile UI/UX
- Configuring mobile API connections through environment variables
- Reviewing and testing mobile-related pull requests
- Documentation of meeting notes
- Research and documentation about RESTful APIs and design criteria for smart environments
- APK generation for milestone releases
- Repository maintenance (branch cleanup, release publishing)
| # | Issues |
|---|---|
| 1 | Visualize waste log in mobile application |
| 2 | Unit tests for challenges page |
| 3 | Change challenge contribution units |
| # | Issues |
|---|---|
| 1 | APK generation for milestone 2 |
| 2 | Create . env file to address the backend modularly |
| 3 | Write planning and team process part of milestone 2 report |
| PR | Description | Role |
|---|---|---|
| #718 | API connections are configured through .env file | Created |
| #698 | Mobile milestone 2 final improvements | Created |
| #690 | Unit tests for index, challenge and profile pages | Created |
| #661 | Visual logs feature - waste log visualization with charts | Created |
| #601 | Fixed challenge unit type display | Created |
| #605 | Mobile color contrast improvements | Reviewed |
| #617 | Develop to Main merge | Reviewed |
| #631 | Mobile notifications and security | Reviewed |
| #632 | Mobile bugfixes and explore page refresh refactoring | Reviewed |
| #651 | Mobile notification API connect and other improvements | Reviewed |
| #680 | Mobile unit tests | Reviewed |
| #689 | Follow functionality | Reviewed |
| #700 | Addition of get posts to non JWT token part | Reviewed |
| #707 | Unit tests for edit profile page | Reviewed |
In some of the PRs I reviewed (#631, #632, #651, #680) I also committed changes to resolve merge conflicts or fix minor bugs to help with the development process. I also documented Meeting Notes 15, Lessons Learned & Mitigation section of the Lab 5 MVP Report and Status of Software Requirements section of the Lab 7 Demo Report.
I was generally responsible for the backend related tasks, namely adding functionality and reviewing/testing code. I also worked on deployment and migrating the server to the machine. Lastly, I was responsible for the Project Plan, opening issues related to it and setting the correct times for the issues.
- Adding functionality to the backend
- Reviewing code related to backend development
- Helping with domain and https related tasks
- Writing unit tests for the backend
- Demo presentation
- Project Plan Creation, Issue Scheduling for the Project Plan.
- Milestone 2 Documentation
| # | Issues |
|---|---|
| 1 | The issue for logging user activities |
| 2 | The issue for the follow functionality |
| 3 | The issue for the waste log history functionality |
| PR | Description |
|---|---|
| #539 | Waste Log History Visualization |
| #540 | Challenge History of Users |
| #542 | Semantic Search |
| #544 | docker-compose file updated for the Vector DB which is used for semantic search |
| #568 | Follow Functionality |
| #610 | Unit Tests for WasteGoal, WasteLog, Auth, Post, Challenge |
| #618 | Setting environment variables |
| #622 | Activity Logging Functionality |
| #645 | Develop to Main |
| #649 | isFollower endpoint |
| #650 | Develop to Main |
| #655 | Changed How Notifications are Sent to the frontend |
| #658 | Develop to Main |
| #659 | GetPost Endpoint for going to a post from a notification |
| #662 | Update the .env file |
| #665 | User Controller UnitTest |
| #666 | Profile Controller UnitTest |
| #667 | SearchController UnitTest |
| #712 | PostLikeController and CommentController UnitTest |
| #724 | docker-compose update |
| #733 | init.sql file change |
I have also written the Evaluation of the status of deliverables section in the report and the Activity Streams 2.0 part in the Utilized Standards section
Mobile developer, documenter, database populator, presenter.
-
Implementation Responsibilities: As a member of the mobile development team, my primary objective was delivering the features scheduled for the MVP release. My technical focus was on enhancing user-to-user interactions. I implemented a comprehensive User Profile architecture, which allows users to navigate to any profile by clicking a username within the app. This interface aims to enable visitors to view a user's post history, interact with content, and manage "follow/unfollow" relationships. Additionally, I integrated follower and following lists directly into the profile page to ensure seamless accessibility. Beyond individual contributions, I actively participated in quality assurance by reviewing my teammates' code and testing their implementations to ensure overall system concreteness, by giving them feedback on their work.
-
Non-Implementation Responsibilities: Outside of coding, my efforts were concentrated on the MVP demonstration strategy. I analyzed our development progress to create a cohesive presentation narrative that effectively showcased our new features. This required frequent updates to the demo scenario to align with the evolving state of our mobile and web implementations. Furthermore, I was responsible for ensuring the demonstration was immersive and realistic. I populated the database with mock data that specifically aligned with the environmental context described in our user scenarios, ensuring a consistent and convincing presentation flow.
| Task name | Issue |
|---|---|
| Implementing Follow Logic Accross the App & Implementing User Profile | #559 |
| Edit Profile Page / Testing | #596 |
| Follow Logic & User Profile Page / Testing | #699 |
| Task name | Issue |
|---|---|
| MVP Demo Scenario | #646 |
| Task name | PR |
|---|---|
| Unit test for edit_profile page | #707 |
| Unit test for user_profile page | #706 |
| Change of non-token endpoints | #700 |
| Implementing follow functionality and user profile page | #689 |
| Unit tests for index challenge and profile | #690 |
| Merging develop branch to main for release | #660 |
| Text improvements for accesibility | #566 |
- I have written the Summary of Customer Feedback and Reflection part of this report.
- I have documented the Meeting Notes 11
Backend Engineer, Devops Engineer, DB Manager, Documenter.
I was primarily responsible for the Backend Development, Database Management, DevOps and project documentation. I have implemented the backend part of the milestone 2 features as given below, I wrote unit tests for the controllers, I deployed the vector db. I worked much more for deployment for this milestone since containerization of the Mobile APK, containerization of MySQL db ( since we had used Google Cloud MySQL server before), deployment of Vector DB needs to be done by me.
I have implemented follow feature,visualization of historical data of waste log and challenge, semantic search with vector embeddings and vector db services (qdrant). I wrote unit tests for
- Implementation of follow feature for backend
- Implementation of visualization of historical data of waste log and challenge
- Implementation of semantic search with vector embeddings, deployment of vector DB (qdrant)
- Writing unit tests for the 9 different controller of the backend.
- Change to .env file for build instructions, deployment of new machine, containerization of MySql and vector DB
- Containerization of Mobile to generate APK
- Milestone 2 Documentation
| Issue Explanation | Issue Link |
|---|---|
| embedding and vector db service and endpoints for semantic search | #541 |
| follow functionality for backend | #538 |
| waste log history functionality for backend | #536 |
| Issue Explanation | Issue Link |
|---|---|
| Dockerization of mobile for apk generation for milestone 2 | #710 |
| create db at digital ocean for new machine, dockerize db , arrange configurations | #695 |
| write build instructions for app development | #664 |
| PR Explanation | PR Link |
|---|---|
| Feature/backend waste log visualization | #539 |
| Feature/backend semantic search | #542 |
| feature/(backend): docker compose for deployment of the vector db | #544 |
| feature/(backend): configuration changes for vector db | #545 |
| feature/(backend):follow | #568 |
| Unit tests for waste goal, waste log, auth, post , challenge | #610 |
| Build with environment variables | #618 |
| Feature/backend isfollower endpoint | #649 |
| update of .env application.properties and compose for build | #662 |
| Test/backend/user controller | #665 |
| profile controller tests | #666 |
| search controller tests | #667 |
| Feature/db/new deployment to new db | #696 |
| addition of endpoints for non jwt token list | #700 #715 |
| configurations of the frontend for prod and build | #724 |
| to develop, or to main merge PRs | #546 #697, and much more |
| PR Explanation | PR Link |
|---|---|
| Fixed activity logging and removed message construction | #655 |
| Fix/get post | #659 |
| Logging activities | #622 |
| Added tests for PostLike and Comment | #712 |
I have also written the The Requirements Addressed in This Milestone , Evaluation of Tools and Processes Used to Manage the Team Project and the Testing (Backend Part) of the report.
I am mainly responsible for architectural design of the frontend for the web app, reviewing the implementations in terms of our code structure and reliability, implementing the code and the decisions that need frontend integrations. Also I played a role for the decision making process for our devops implementation.
I led the architectural design of the frontend and ensured that all implementations aligned with our code structure, reliability standards, and component organization. I tried to review and give feedback for most of the implementations to sustain an organized implemenation for frontend. I implemented several core features that required frontend integrations, including the statistics components introduced after Milestone 1 feedback, and improved accessibility through keyboard navigation support. I also created the initial testing setup using Vitest, providing configurations and an example test file that established the foundation for all future frontend tests. Additionally, I contributed to our DevOps decisions and configured the frontend for proper deployment using a global .env approach, ensuring seamless integration with our infrastructure.
- Initial test tool implementation where I showed the procedure for our frontend developers for them to follow. The implementation included the initial configurations and an example unit test file. issue
- Implemented the statistics related components after our feedback from customer after milestone 1. The components showed the process of one person or the impact created by the community. issue
- To ensure accessibility, I checked the keyboard navigation support for our app and implemented where it is deficient. issue
- Decided the final coverage of the testing for our frontend application and discussed it with our team. Made a research about several tools and considering the packages, architectures we use in the implementation; decided to go with these tools. issue
- Wrote the testing for frontend in this report issue
| Task name | PR |
|---|---|
| Created the initial vitest configuration with one example test implementation for the team | PR |
| Fixed the related bug with a meeting with Arda and explained the client.ts's behaviour. Corrected some implementations there and gave suggestions in my review. | PR |
| Created statistics related components and made improvements for goals page | PR |
| Implemented the unit tests for my implementations | PR |
| Fixed the delete account api since it was changed by backend | PR |
| Adjusted the frontend configuration for the global .env handling and correct deployment | PR |
| Reviewed the challenge process visualization implementation by Arslan. | PR |
| Reviewed and merged the notification implementation | PR |
| Reviewed the test implementation and gave feedback | PR PR |
| After the meeting Arslan, reviewed and gave feedback-suggestions for the implementation | PR |
| Guided and gave feedback for accesibility implementation | PR |
| Reviewed and gave feedback about the implementation of the tests | PR PR |
| Reviewed the dockerization of the app and made necessary changes in the VM | PR |
I am part of the frontend team, and I am responsible for the development of the frontend side of the project. Additionally, I am responsible for attending weekly and non-routine meetings, being part of the project planning, conducting necessary research, and writing reports and documentation.
For milestone 2, my main contribution was the development of the frontend. In particular, I implemented the follow feature and the profile modal. The implementation of the follow feature included developing the client-side API for follow endpoints, adding follow/unfollow buttons, showing follower/following counts, and displaying follower and following lists on the profile page. To allow users to view other users’ profile pages, the profile modal was implemented; it is similar to the profile page and opens when users click other users’ names in various locations such as posts or comments. Additionally, I implemented some accessibility features, such as ensuring contrast ratios and providing text alternatives for non-text content. Furthermore, I implemented strong password enforcement, wrote unit tests for the parts I developed, and fixed several bugs. I also reviewed my teammates’ work, discussed it with them, reviewed and tested their PRs, and merged them. Aside from my tasks in the frontend team, I proactively discussed important decisions for our project, attended all meetings and labs, and collaborated with my teammates about the project throughout the process.
- #636: Implementation of follow feature and profile modal in the frontend.
- #590: Parent issue for all unit tests in frontend for milestone 2. I have also opened sub-issues for unit tests I have implemented.
- #562: Parent issue for accessibility implementations. I have also opened sub-issues for some of the accessibility features.
- #646: Written a demo scenario with Yusuf Onur Öksüz for the milestone 2 demo presentation.
- #723: Populated data for the application for the the milestone 2 demo presentation.
- #547: Taken notes during a weekly meeting and documented it on our wiki.
- #572: Implementation of ensuring desired contrast ratios and new language toggle button.
- #574: Implementation of text alternatives for non-text content.
- #633: Implementation of strong password enforcement in register page.
- #639: Fix of leaderboards UI bug.
- #656: Fix of used email/username bug.
- #678: Implementation of follow feature and profile modal.
- #683: Implementation of unit tests for challenge components and challenge page.
- #692: Implementation of unit tests for language toggle button.
- #721: Implementation of kindness remainder while creating a post or commenting to a post.
- #728: Fix of invalid credentials in login page bug.
- #545: Reviewed and merged configuration changes for vector Database.
- #575: Commented on the PR with a detailed review.
- #668: Commented on the PR with a detailed review and requested changes.
- #675: Reviewed the PR, requested changes, and merged it when it is finished.
- #687: Reviewed and merged the PR on notifications - profile dialog integration.
- #722: Reviewed and merged the PR on profile pictures not showing on avatars bug.
- #730: Reviewed and merged the PR on UI makeover.
- #732: Reviewed and merged the PR on notifications messages.
I have written the UX Design and Utilized Standards part in the Milestone 2 Report.
