top of page
Case Study:
Sesh
January-April 2022
Sesh is an online study habit tracker created to address student engagement during a pandemic. The application creates both an ideal focus environment while collecting data to create a competitive environment to encourage motivation. As a web application, it is accessible by everyone!
This project was created for our Introduction to Software Engineering course using the Agile and Scrum Methodology.
Skills
-
Leadership
-
Software Development
-
Full Stack Development
-
Version Control
-
Web Development
Tools
-
MongoDB
-
Express
-
React.js
-
Node.js
-
GitHub
-
Figma
-
Netlify
Roles
Roles
-
Me (Project Manager)
-
Connor Syron (Scrum Master)
-
Ethan Fiore (Developer)
-
Neha Kallamvalli (Developer)
Question
How to increase virtual student engagement?
Product Vision Statement
FOR students and educators WHO have a need to create a motivational study environment that can track study habits. THE Sesh is a web-based application THAT provides habit tracking statistics such as leaderboards and study streaks that allows users to view their overall progress and see where possible improvements can be made. UNLIKE other study applications OURS combines habit tracking and leaderboards to create a “game like” experience.
Proposed Solution
Due to the consequences of the global pandemic that we are currently experiencing, we noticed that it is difficult to find virtual study environments. While addressing that problem, we also wanted to build this habit tracker to motivate students to persistently keep up with their goals.
We want to create a fun atmosphere that mirrors a gaming environment that inspires students to persevere and accomplish their ambitions while engaging in healthy competition with their peers. Having an application that includes a leaderboard and a point system may further help with keeping students incentivized.
Planning
Prior to development, we followed the Agile and Scrum Methodology to create an outline of industry practices. We planned our Sprints, Product Backlog, System Architecture Model, and User Stories.
Brand Guidelines
After our pre-planning, we wanted to develop a brand for our concept. Thus, "Sesh" was created with the following brand guidelines.
Branding Guidelines
Colors
Components
Branding Guidelines
1/4
Wireframes
For a website, wireframes are necessary in the planning process to envision the direction of the final product. For Sesh, we wanted to create a simple layout that is clean and minimal.
Process
Although given division of roles, we all contributed to the code base. We began with Frontend development of Sesh since most of us were unfamiliar with Backend work. The first few pages were created at first were the Homepage, About Us, and Login/Register page.
As the Project Manager, I helped organize features to build and assigned our priorities. We met every week to discuss goals and complete the associated documentation for our project.
General Development Process
Concerning our general development of our project, we first assigned tasks based on each team member's strengths and knowledge. As Project Manager and a student, I opened the opportunity for members to take on tasks that they wanted to learn also. This was a safe space to learn, experiment, and make mistakes. Thus, if members wanted to try Backend or Frontend CSS for example, they were open to take on the task.
Many of us worked together in pair programming sessions to learn and debug. Considering the different levels of web development knowledge we had, it helped to actively work and meet together in working sessions.
Challenges + Conclusions
One of the biggest challenges we had throughout the development process was lack of time and knowledge. As students with full time schedules, organizing meeting times and personal schedules was difficult. We used when2meet as a tool to help mitigate this, however, it's understandable to have conflicting schedules.
As the final deadline drew near, we had to reassess the final features we would have in our product. We cutback on several features to focus on what would address the problem question. For the excess features, we planned them to be post-release updates.
Overall, following the Agile and Scrum Methodology created a good structure for our development life cycle. It was flexible for everyone and was open to change and revisions. Creating this project was a good "low-risk" environment to practice software development. In addition, helped solidify the processes outside of the classroom setting. If I were to redo this project again with the same team, I would like to have shorter sprints every 2 weeks to have more frequent big meetings.
Final Products
Pre-Process
Problem
Introduction
Conclusions
Final Products
Process
bottom of page