Final push before system formatting

AppDev/prospectiveTexFiles/chris.tex

@@ -0,0 +1,48 @@
+\section{Individual Reports}
+\subsection{Christopher Sanden}
+
+My individual contribution to \textit{Study Sprint} covered several central parts of the project, but the largest part of my work was connected to the timer, session flow, onboarding, and final delivery preparation. The commit history attributes 44 commits to me, including the first timer implementation, later task-flow integration, dashboard and session improvements, break-cycle logic, onboarding refinements, signup-confirmation deployment, test updates, and Android delivery preparation. The most relevant work is supported by the timer work notes from 21 April to 5 May and commits such as \texttt{d50301c}, \texttt{666bdc1}, \texttt{c74062c}, \texttt{b437643}, \texttt{907fa18}, \texttt{245b6db}, \texttt{2bb2ac6}, \texttt{9bb3bb1}, and \texttt{419463e}.
+
+\vspace{2mm}
+
+My first major contribution was creating the original timer feature. In commit \texttt{d50301c}, I added the first functional timer screen with duration selection, start behaviour, running timer state, and animated visual feedback. In the following iterations, I developed the timer into a more complete study-session interaction. This included countdown behaviour, measured layout handling, duration locking while a session was running, a deliberate hold-to-cancel flow, and cleanup of the internal timer structure. The timer eventually relied on several separate kinds of state, including selected duration, running state, countdown text, layout height, progress animation, and cancellation state. Separating these concerns was important because the timer later had to survive routing changes, cancellation, recovery, and integration with persistent session data.
+
+\vspace{2mm}
+
+A key part of this work was making the timer maintainable enough to become a core product feature rather than a fragile prototype. In commit \texttt{666bdc1}, I refactored the timer code by extracting repeated cleanup logic, grouping refs by responsibility, and making the render structure match the visible screen layers more closely. This was especially important because the timer used intervals, timeouts, animation refs, and cancellation flags. Keeping those responsibilities clear made the later integration work safer and easier to reason about.
+
+\vspace{2mm}
+
+The most important product-level change I made was moving the timer into the actual task workflow. In commit \texttt{c74062c}, I moved the timer from the tab navigator into the task stack and made it open from a selected task. The timer could then receive a task id, load the matching task from Supabase, display task information during the sprint, and preserve an active sprint locally through an end time. This changed the timer from a generic utility into a study-session feature tied directly to the user's planned work, which better matched the product vision.
+
+\vspace{2mm}
+
+I also extended the timer into a more durable session model. In commit \texttt{b437643}, I connected active local sprint state to database-backed sprint sessions and added task-level study-time tracking. This meant that completed, expired, or cancelled sessions could contribute elapsed time back to the relevant task instead of only changing temporary UI state. I also handled failure cases around session creation, finalisation, cancellation, and restore behaviour so the local timer state and stored session history would not drift apart.
+
+\vspace{2mm}
+
+My work also affected the dashboard and progress experience. I added support for reopening active sprints from the dashboard, showing remaining session time, displaying upcoming deadline tasks with subject and assignment context, and marking tasks as completed from dashboard cards. I also fixed a dashboard issue where upcoming tasks disappeared whenever an active sprint existed. These changes made the dashboard more useful as a daily study overview instead of only being a static landing page.
+
+\vspace{2mm}
+
+Later in the project, I worked on the focus-and-break cycle. I introduced shared session defaults in \texttt{lib/sessionDefaults.ts} so focus duration, short breaks, long breaks, and long-break frequency could be reused consistently across the timer, task details, and dashboard. I also implemented a local study-cycle model so the app could decide whether the next break should be short or long based on the current continuous study run rather than unrelated historical sessions. This made the session flow closer to a real study rhythm: focus, break, continue the same task, or return to the dashboard.
+
+\vspace{2mm}
+
+As the session flow became more connected to the rest of the app, I added a shared lifecycle helper in \texttt{lib/sessionLifecycle.ts}. This centralised how active sessions are finalised when they expire, are replaced, or are cleared from other screens. This was one of my more important reliability contributions because it reduced duplicated logic across the timer, dashboard, task details, and setup flow, and lowered the risk of the UI and database recording different versions of the same session.
+
+\vspace{2mm}
+
+I also contributed to the first-time-user and account-confirmation flow. In commit \texttt{907fa18}, I added a guided setup route that helps new users create their first subject, assignment, and task before starting a sprint. Later, in commit \texttt{9bb3bb1}, I added shared setup-completion logic in \texttt{lib/setupStatus.ts} so incomplete users are routed into setup more consistently. I also changed the first setup sprint into a short demo timer, making the first interaction easier to test and understand.
+
+\vspace{2mm}
+
+Outside the app itself, I improved the signup confirmation loop. I added a small static confirmation page under \texttt{deploy/signup-confirmation}, served through \texttt{nginx} with Docker Compose and hosted on my VPS behind the existing reverse-proxy setup. I also corrected the Caddy routing target so the page resolved correctly, and customised the Supabase confirmation email into a cleaner HTML email while keeping the required confirmation-link placeholder. This made account creation feel more complete and presentable from signup through email confirmation.
+
+\vspace{2mm}
+
+Toward the end of the project, I contributed to verification and delivery preparation. I used TypeScript checks, linting, manual runtime testing, and database inspection during timer and session work, because interaction-heavy behaviour could not be fully verified by static checks alone. I also updated the test setup and several test files in commit \texttt{419463e} so they matched the newer logic across auth, subject, assignment, and task flows. Finally, I adjusted the Android package name in \texttt{app.json} to match Google Play Console expectations and added the APK artifact for delivery.
+
+\vspace{2mm}
+
+Overall, my contribution was broad, but it was tied together by one main goal: making the app feel like a coherent study tool rather than a set of separate screens. I worked on the timer, task integration, session persistence, dashboard visibility, break-cycle behaviour, onboarding, signup confirmation, testing, and Android delivery. Strategically, this strengthened the parts of the project most closely connected to the product vision: helping users move from planning study work to actually starting and tracking focused study sessions.

AppDev/prospectiveTexFiles/conclusion.tex

@@ -0,0 +1,19 @@
+\section{Conclusion}
+
+The goal of \textit{Study Sprint} was to create a focused mobile application that helps students organise academic work and move more easily into structured study sessions. The final product addresses this goal by combining subjects, assignments, tasks, timed focus sessions, breaks, progress tracking, reminders, and persistence into one connected workflow.
+
+\vspace{2mm}
+
+The project shows that the value of the application lies mainly in how these parts work together. A planner alone would not solve the problem of starting focused work, and a timer alone would not help the user decide what to study. By linking study sessions directly to tasks, the app makes the transition from planning to action more concrete. This supports the original product vision, where simplicity, low friction, reliability, and realistic scope were more important than building a broad productivity platform.
+
+\vspace{2mm}
+
+During development, the application also became more coherent through several important refinements. The screen structure was aligned more closely with the hierarchy of \textit{Subject $\rightarrow$ Assignment $\rightarrow$ Task}, the timer flow was implemented around the task workflow as originally intended, and session reliability was improved through more consistent lifecycle handling. The final design also supports several usability principles, including visible system status, familiar student-oriented concepts, consistent interaction patterns, and a low-friction default path into study sessions.
+
+\vspace{2mm}
+
+There are still limitations. The project remained intentionally narrow in scope, and some behaviour, especially around timer interaction, onboarding, notifications, and break handling, depended heavily on manual verification. The product is also still best understood as a proof-of-concept rather than a production service, especially because it depends on Supabase free-tier limits and does not yet include a larger automated testing strategy, advanced analytics, calendar integration, or richer cross-device behaviour. In addition, the lack of formal time sheets and a formal ticket-tracking system weakened the precision of the process documentation, even though the group could still document work through the report, source control, communication, meetings, and development history.
+
+\vspace{2mm}
+
+Overall, \textit{Study Sprint} can be considered a successful result within the constraints of the project. It delivers a working and coherent study-support application that reflects the original vision more clearly than the early prototype. The final result is not the largest possible productivity app, but it is a focused solution that connects planning, studying, breaks, and progress in a way that is useful for the intended student user.

AppDev/prospectiveTexFiles/discussion.tex

@@ -0,0 +1,106 @@
+\section{Discussion}
+
+The development of Study Sprint shows both the strengths and limitations of building a small productivity application around one tightly scoped user problem. The project did not aim to compete with broad commercial productivity platforms on feature count. Instead, it aimed to reduce the gap between planning study work and actually starting it. In that sense, the most important question is not whether the app includes many features, but whether the implemented features support one coherent and dependable study flow.
+
+\vspace{2mm}
+
+Overall, the final result suggests that the project moved substantially closer to that goal over time. The strongest improvement was not the addition of one isolated feature, but the gradual alignment between planning structure, timer behaviour, session persistence, progress visibility, and onboarding. Earlier versions of the app already contained the core building blocks, but later revisions made those parts reflect the original product direction more clearly and work more convincingly as one product rather than as loosely connected components.
+
+\subsection{Strength of the Hierarchy-Driven Product Model}
+
+One of the clearest lessons from the project was that the application's underlying hierarchy mattered more than first assumed. The conceptual model of \textit{Subject $\rightarrow$ Assignment $\rightarrow$ Task} was not only a database relationship but also an important usability principle. When assignments and tasks were exposed too much as standalone top-level concepts, the app became flatter, more repetitive, and less clear. Important context was lost, and the user could more easily lose track of what a specific task belonged to.
+
+\vspace{2mm}
+
+Restructuring the app around that hierarchy improved both navigation and meaning. Subjects became the natural entry point into academic content, while assignments and tasks became progressively deeper parts of the same flow. This made the product feel more intentional and better aligned with its actual purpose. In discussion terms, this supports the broader argument that architectural clarity in a small application is not only a technical concern but also a user-experience concern.
+
+\subsection{Why Task-Linked Study Sessions Were Important}
+
+Another important outcome was that the final implementation came to reflect one of the project's original intentions more accurately: the timer was always meant to support concrete study tasks rather than function as a detached utility. This reflects one of the central ideas behind the project, namely that planning and focused work should support each other directly. A generic timer can measure time, but it does not necessarily help the user decide what to work on. By contrast, a task-linked sprint flow makes the act of starting a session more concrete and meaningful in the context of study work.
+
+\vspace{2mm}
+
+This also strengthens the product's unique value relative to broader productivity tools. Study Sprint does not attempt to replace general-purpose planners or offer advanced analytics. Its strength lies instead in the connection between defining study structure and beginning focused work quickly. From that perspective, the later timer-related revisions should not be understood as a change in product direction, but as a process of bringing the implementation into better alignment with the intended identity of the app.
+
+\subsection{Reliability as a Central Product Requirement}
+
+Reliability also became one of the most important concerns during development. This was especially visible in the timer and session lifecycle. Once the app began storing active sessions, supporting break cycles, and recovering state across screens, inconsistencies between local state and stored session data became a real product risk. A timer-based application quickly loses credibility if it cannot be trusted to reflect the user's actual study activity.
+
+\vspace{2mm}
+
+For that reason, the later work on shared session finalisation, active-session recovery, and break-cycle logic was highly significant. These changes may seem less visible than larger UI changes, but they directly support one of the most important, critical product attributes identified earlier in the report: reliability. In practical terms, this means that some of the most valuable work in the project was not the addition of new features, but the correction of weak interactions between existing features.
+
+\subsection{Tradeoffs in Persistence and Scope}
+
+The chosen persistence model also represents a clear tradeoff. Supabase was used for durable user data such as subjects, assignments, tasks, and recorded sessions, while local device storage was used for temporary or device-specific state, such as active-session recovery, study-cycle continuity, and notification identifiers. This was a pragmatic and appropriate design for the scope of the project.
+
+\vspace{2mm}
+
+The benefit of this split is that it keeps the app practical without introducing unnecessary backend complexity. At the same time, it also creates a boundary that must be handled carefully. When one part of the app depends on local control state and another part depends on backend records, consistency problems can arise if the transition between them is not carefully managed. The later reliability fixes suggest that this tradeoff was acceptable, but only when paired with more explicit lifecycle handling.
+
+\subsection{Usability, Onboarding, and Low-Friction Design}
+
+The project also highlights that usability problems in small applications often arise from friction rather than from missing functionality. In this case, several later revisions focused on making the main study flow easier to enter: guided setup was strengthened, default sprint durations were made easier to accept immediately, and help flows were adjusted so that the intended rhythm of focus and breaks became easier to understand.
+
+\vspace{2mm}
+
+These changes support the original product vision well. The main goal of the app was not to maximise customisation or feature depth, but to help users move quickly from intention to action. The discussion that follows from this is that a low-friction default path can be more valuable than a more flexible but slower interaction model, especially in a study-orientated application where hesitation and setup overhead directly work against the product's purpose.
+
+\vspace{2mm}
+
+The claim that the application has a low-friction and intuitive design can also be supported through Nielsen's usability heuristics. Nielsen's heuristics are broad principles for interaction design and are commonly used to evaluate whether an interface is likely to be understandable, predictable, and usable \cite{nielsenheuristics}. Study Sprint was never formally tested through a complete heuristic evaluation with several reviewers, but several of the final design decisions align closely with these principles.
+
+\vspace{2mm}
+
+First, the app supports \textit{visibility of system status} by showing the active timer state, study session progress, completion ratios, and recent activity. This helps users understand what is currently happening and what progress has been made. Second, the app follows \textit{match between system and the real world} by organising academic work through familiar student concepts such as subjects, assignments, and tasks. Third, \textit{user control and freedom} are both supported through options such as cancelling active sessions, editing created entities, and ease of navigation.
+
+\vspace{2mm}
+
+The design also follows \textit{consistency and standards} by reusing cards, pills, action buttons, spacing, and upsert-based forms across similar screens. \textit{Recognition rather than recall} is supported by keeping the parent context visible as users move through the hierarchy, for example, by showing subject and assignment context on deeper task screens. The default sprint flow also supports \textit{flexibility and efficiency of use} because users can start quickly with a sensible default duration while still having the option to choose alternative durations when needed.
+
+\vspace{2mm}
+
+The app follows \textit{aesthetic and minimalist design} by reducing top-level navigation, removing redundant assignment and task tabs, and limiting progress indicators to screens where they provide useful context. Help and documentation are supported through onboarding and lightweight help flows that explain the intended study rhythm without requiring the user to read a large manual. Together, these design choices support the argument that the interface was intentionally shaped to be understandable and low-friction, although a full user test would still be needed to validate this with real users.
+
+\subsection{Limitations of the Project}
+
+Despite the strengths of the final result, the project also has clear limitations. First, the scope remained relatively narrow. This was intentional and appropriate, but it still means that the product does not attempt to cover many surrounding needs that broader productivity platforms address, such as advanced analytics, collaboration, calendar integration, or richer cross-device notification infrastructure. This area would likely be the projects next development path, given a bigger development window.
+
+\vspace{2mm}
+
+Second, the development process remained strongly iterative until late in the project. That was useful for improving the product, but it also meant that some parts of the application changed several times before reaching a more stable form. In report terms, this suggests that the project succeeded more as a process of refinement than as a case of implementing a fully settled design from the start.
+
+\vspace{2mm}
+
+Third, the testing picture appears mixed. The report includes structured tests for important CRUD and guard behaviour, together with repeated use of linting, TypeScript checks, manual testing, and development-build verification. Even so, not all important qualities of the app were verified in the same way. Interaction-heavy behaviour such as timer flow, break handling, onboarding transitions, and notification timing depended heavily on manual validation. This is understandable for the project scope, but it still represents a limitation compared to a larger and more thoroughly automated testing strategy.
+
+\vspace{2mm}
+
+Fourth, the current state of the project is dependent on Supabase and their free-tier rate limits. One obvious concern is the rate of emails being limited to 2 per hour, meaning that within any given hourly timeframe, only two new accounts can be registered due to the requirement of a confirmed email address before a user can log in. This is also an area of expansion for the project; however, the group decided to forego the cost of a subscription, given that the app, in its current state, is used as a proof-of-concept rather than an actual avenue of business.
+
+\subsection{Documentation Lapses}
+
+A further limitation was that the group did not maintain formal time sheets throughout the project. The requirement for time sheets was discovered late, after a vast majority of the product development had been completed. As a result, the group cannot provide a detailed and reliable hour-by-hour record of the work process.
+
+\vspace{2mm}
+
+This weakens the documentation of workload distribution and makes it harder to evaluate the exact amount of time spent. However, the group has still documented the development process through the method section, collaboration description, implementation history, testing section, and final product outcome. The work was also supported by regular communication, meetings, source control activity, and shared report writing. Member contributions can be roughly estimated given the git commit history of each member, although this does not provide a realistic estimate of time spent. Group members also wrote daily work summary notes to document the work that had been carried out and the current state of the development branch at the time of writing. This makes it possible to determine workload distribution based on additions to the codebase. Hourly distribution, however, is difficult to estimate given only work notes and commit history. 
+
+\vspace{2mm}
+
+The group also did not keep any formal ticket list using a Scrum based system. The reasoning was that the app had such limited scope that deploying a full-scale ticket tracking system was deemed to add more complexity to the project than it would alleviate. Given that the planned features for the app were meant to be few but of high quality, the group had no issues staying on top of what each member was working on at any given time, nor did it introduce difficulties in keeping track of future work. With the added benefit of writing work summary notes, the group can also reliably prove the work and contributions of each member. In short; the lack of a full-scale ticket tracking system did not hinder the project in any capacity.
+\clearpage
+
+A further limitation was that the group did not maintain formal time sheets throughout the project. The requirement for time sheets was discovered late, after a vast majority of the product development had been completed. As a result, the group cannot provide a detailed and reliable hour-by-hour record of the work process.
+
+\vspace{2mm}
+
+This weakens the documentation of workload distribution and makes it harder to evaluate the exact amount of time spent. However, the group has still documented the development process through the method section, collaboration description, implementation history, testing section, and final product outcome. The work was also supported by regular communication, meetings, source control activity, and shared report writing. Member contributions can be roughly estimated given the git commit history of each member, although this does not provide a realistic estimate of time spent. Group members also wrote daily work summary notes to document the work that had been carried out and the current state of the development branch at the time of writing. This makes it possible to determine workload distribution based on additions to the codebase. Hourly distribution, however, is difficult to estimate given only work notes and commit history.
+
+\subsection{Overall Evaluation}
+
+Taken as a whole, Study Sprint appears successful primarily because the project stayed disciplined about its central problem. The strongest parts of the final application are those where structure, study sessions, breaks, reminders, and progress all reinforce the same user goal. The weaker parts are not signs that the project lacked ambition, but reminders that even a small mobile product becomes complex once reliability, persistence, and user flow are treated seriously.
+
+\vspace{2mm}
+
+The most important discussion outcome is therefore that the project demonstrates the value of coherence over breadth. Study Sprint became stronger when the team removed redundancy, tightened the hierarchy, linked sessions to real tasks, and refined the timer lifecycle until it better supported dependable use. That does not mean the application is complete in every sense, but it does mean that the final result reflects its stated product vision more clearly than the earlier prototype versions did.

AppDev/prospectiveTexFiles/introduction.tex

@@ -0,0 +1,95 @@
+\section{Introduction}
+
+This report presents the development of \textit{Study Sprint}, a mobile productivity application designed to help students organise academic work and turn that structure into focused study sessions. The core idea behind the application is to reduce the gap between intending to study and actually starting. Instead of treating planning, timing and progress as separate concerns, Study Sprint connects subjects, assignments, tasks, timed focus sessions, breaks and visible progress into one lightweight workflow.
+
+\vspace{2mm}
+
+The motivation for the project came from a common frustration with existing study and productivity applications. Many such applications are either too broad, too feature-heavy or too abstract for students who simply want to organise what they need to study and begin working with as little friction as possible. In many cases, users are forced through unnecessary setup, presented with too many unrelated features, or given timer tools that are disconnected from the work they are supposed to support. Study Sprint was developed as a response to that problem.
+
+\vspace{2mm}
+
+The project therefore focused on a small but coherent feature set. The goal was not to create the most advanced productivity application, but to create one that is easy to understand, fast to use and reliable in practice. This meant prioritising a clear study hierarchy, low-friction navigation, task-linked study sessions, break handling and progress visibility over broader functionality that would have increased the complexity without adding equal value to the intended user.
+
+\vspace{2mm}
+
+The conceptual background for the app was also influenced by the Pomodoro technique, where focused work intervals are separated by short breaks. This was relevant because the project aimed to support concentration, reduce study friction, and make it easier for users to turn vague study intentions into concrete work sessions. Recent review literature also suggests that structured Pomodoro-style intervals can improve focus, reduce fatigue, and support sustained task performance in demanding learning contexts \cite{pomodoro_scoping_review}.
+
+\vspace{2mm}
+
+From a development perspective, the project followed an iterative approach. Early prototypes were used to explore structure, interaction and timer behaviour before the application was gradually refined through implementation, testing and revision. Several parts of the application, especially the timer flow and session handling, changed significantly over time as practical issues were discovered and resolved. This process helped move the product from a simple prototype toward a more complete and reliable study tool.
+\clearpage
+
+
+\subsection{Product Vision}
+
+The complete project vision is included in Appendix~\ref{appendix:projectvision}. The following section summarises the most important parts of that vision and shows how they shaped the direction of the product.
+
+\subsection{Target customer}
+
+The primary target group for Study Sprint is students in higher education who want a simple and structured way to organise study work, start focused work sessions and keep track of their progress \cite{projectvision}.
+
+\vspace{2mm}
+
+A secondary target group includes other learners, such as upper secondary students, as well as users who rely on timed work sessions for productivity in non-academic contexts. Even so, the application is mainly designed around student needs, since that is the clearest and most relevant use case for the project.
+
+\subsubsection{Customer needs}
+
+Study Sprint is intended to address a small set of practical needs that repeatedly appear in student work:
+
+\begin{itemize}
+    \item better focus during study sessions through timed work periods and breaks,
+    \item simple planning and organisation through subjects, assignments, and tasks,
+    \item motivation through visible progress and recorded study activity,
+    \item low friction, so users can understand the app quickly and begin studying without unnecessary setup.
+\end{itemize}
+
+These needs are closely related. A study timer becomes more useful when it is connected to real tasks, and planning becomes more meaningful when it leads directly into focused work.
+
+\subsubsection{Critical Product Attributes}
+
+The most important product attribute for Study Sprint is simplicity. The application should be intuitive enough that a user can understand the main study flow almost immediately. A user should be
+able to move from creating structure to starting a study session without confusion or unnecessary decision-making.
+
+\vspace{2mm}
+
+Reliability is also critical. Since the application depends heavily on timed study sessions and progress tracking, it must handle active sessions, completion, cancellation, breaks, and saved
+progress in a dependable way. If the timer flow feels unstable or if recorded study activity becomes inconsistent, the application quickly loses its usefulness.
+
+\vspace{2mm}
+
+A third important attribute is a clear and focused user interface. The design does not need to be visually complex, but it should feel complete, deliberate, and easy to navigate. Since the app is
+intended to reduce procrastination rather than add friction, fast and understandable interaction is especially important.
+
+\vspace{2mm}
+
+Finally, scope control is an important product attribute in itself. A smaller and more polished application is more valuable for this project than a broader solution with too many unfinished or
+weakly integrated features. A successful version of Study Sprint therefore includes structured planning, task-linked study sessions, break handling, progress visibility, and persistence, while
+avoiding feature expansion that would dilute the product's main purpose.
+
+\subsubsection{Unique Seeling Points}
+
+Study Sprint enters a crowded space of Pomodoro apps, study planners, habit trackers, and general productivity tools such as Forest, Focus To-Do, and Todoist. These applications often provide useful
+functionality, but many of them are either too broad, too feature-heavy, or too focused on premium features and generalized productivity workflows \cite{projectvision}.
+
+\vspace{2mm}
+
+Compared to these alternatives, Study Sprint aims to be more focused and more student-oriented. Rather than trying to include every possible productivity feature, it combines only the features most relevant to the intended workflow: subject structure, assignments, tasks, timed focus sessions, breaks, and visible progress.
+
+\vspace{2mm}
+
+The main unique selling point of Study Sprint is therefore not feature quantity, but feature connection. The application links planning and studying more directly than a simple timer app, while
+remaining much lighter and more focused than broader productivity platforms. This makes it easier for a student to decide what to study, begin working quickly, and see meaningful progress afterward.
+
+\subsubsection{Target Time-frame and Budget}
+
+The target time-frame for Study Sprint was the duration of the project period, ending in early May. Because this work was carried out alongside other courses, assignments, and exams, the project had
+to be planned with a strong focus on the effort-to-value ratio rather than feature ambition.
+
+\clearpage
+
+For that reason, the team aimed to establish a working prototype early and then use the remaining time on refinement, reliability, usability, and report work. A realistic development path was to
+first define the product structure and screen flow, then implement the core planning hierarchy, timer functionality, session persistence, break flow, and progress tracking, before focusing on testing and polish \cite{projectvision}.
+
+\vspace{2mm}
+
+The financial budget for the project was expected to be minimal. The application was developed using free or low-cost tools and frameworks, with time being the main practical constraint. This made it especially important to avoid unnecessary complexity and to concentrate on the parts of the application that contributed most directly to the intended study experience.

AppDev/prospectiveTexFiles/method.tex

@@ -0,0 +1,71 @@
+\section{Method}
+
+The development of \textit{Study Sprint} followed a practical and iterative project method. Rather than treating the application as a fixed specification that could be implemented in one pass, the team worked from a product vision, built early versions of the core functionality, and then refined the solution as weaknesses became clearer through use, testing, and discussion.
+
+\vspace{2mm}
+
+This approach fit the nature of the project well. The main challenge was not only to implement isolated features, but to shape a small mobile product that felt coherent, reliable, and easy to use in practice. Because of that, the method had to support both technical implementation and repeated revision of structure, flow, and scope.
+
+\subsection{Vision-Driven and Scope-Conscious Development}
+
+The project vision functioned as the main strategic starting point for the work. It defined the target users, the most important customer needs, and the product attributes that mattered most for success. In particular, simplicity, reliability, low friction, and realistic scope were treated as guiding constraints throughout the project \cite{projectvision}.
+
+\vspace{2mm}
+
+This had a direct effect on development priorities. Features that supported the core study flow were given precedence, while ideas that would broaden the product without strengthening its main purpose were deprioritized or excluded. That is also why the report separates requirements into must-have, should-have, could-have, and will-not-have categories. This prioritization made it easier to protect the project from feature growth and to keep effort focused on the parts of the application that contributed most directly to the intended user experience.
+
+\subsection{Iterative Prototyping and Refinement}
+
+The practical development process was iterative. Early work focused on establishing the underlying structure of the app, including navigation, CRUD support for subjects, assignments, and tasks, and the first timer-related flows. These early versions were useful for confirming that the main ideas were technically possible, but they also revealed architectural and usability problems that were not obvious at the planning stage.
+
+\vspace{2mm}
+
+One clear example was the relationship between the app's conceptual data model and its screen structure. The intended hierarchy was always \textit{Subject $\rightarrow$ Assignment $\rightarrow$ Task}, but earlier versions exposed assignments and tasks too much as top-level concepts. As the app was used and reviewed, this was recognized as a source of redundancy, weak context, and unnecessary navigation complexity. The architecture was therefore revised so that the interface reflected the actual hierarchy more clearly.
+
+\vspace{2mm}
+
+The same pattern appeared in the timer and session logic. Initial timer behaviour was gradually replaced by a more complete session model with focus sessions, breaks, persistence, and safer finalization rules. Several parts of the timer flow changed more than once as practical issues were discovered, especially around routing, active-session recovery, break handling, and reliability. In that sense, prototyping was not only used to create a first version, but also as a way to expose where the product model was still too weak or too rough.
+
+\subsection{Incremental Delivery of Core Features}
+
+The implementation was carried out in layers rather than as one large build phase. A basic feature foundation was established first, followed by increasingly product-specific refinement.
+
+\vspace{2mm}
+
+At an early stage, the work concentrated on basic entity management and data flow, such as creating, editing, viewing, and deleting subjects, assignments, and tasks. After that, the project moved further toward the product's intended identity by adding progress tracking, local reminders, more structured navigation, and task-linked study sessions. Later work focused more strongly on reducing friction in the main study flow, improving onboarding, and making the timer and break cycle more robust.
+
+\vspace{2mm}
+
+This incremental method helped reduce risk. A simple but working baseline could be established first, after which the team could decide which refinements actually improved the product and which ideas were unnecessary within the project's time constraints.
+
+\subsection{Testing, Verification, and Revision}
+
+Testing in this project was not treated as something that only happened at the end. Instead, verification and revision were interwoven with development. When new functionality was added, the result was checked, weaknesses were identified, and the implementation was adjusted before the project moved further.
+
+\vspace{2mm}
+
+The notes show two main forms of verification. The first was manual testing of the app's actual behaviour, especially in flows where user interaction and timing mattered. This was particularly important for the timer, break handling, onboarding flow, routing, and notification behaviour. The second was technical verification through static checks such as linting and TypeScript compilation, which helped detect invalid code, inconsistent types, and integration mistakes before further changes were added.
+
+\vspace{2mm}
+
+This combination was necessary because the project contains both logic-heavy and interaction-heavy features. Static checks can confirm that the codebase is structurally valid, but they cannot on their own confirm that a timed session flow feels correct or that screen transitions behave as intended. Manual testing was therefore especially important whenever reliability, usability, or flow clarity were central concerns. For native-dependent functionality such as notifications, a development build was also used instead of relying only on Expo Go, since that gave more realistic behaviour during testing.
+
+\subsection{Collaboration and Work Organization}
+
+The work was organized as a collaborative group project with regular meetings, shared responsibility, and ongoing task distribution. According to the project vision and group contract, the group planned to meet weekly to review progress, divide work, and discuss problems as they appeared. Discord functioned as the main communication channel between meetings, making it easier to adjust responsibilities when needed.
+
+\vspace{2mm}
+
+Because the project remained relatively limited in scope, with a small team and a fairly small number of central features, the group did not use a heavier Scrum-oriented project management setup with dedicated ticket tools such as Taiga. In practice, many tasks were easier to define, discuss, and reprioritize through regular meetings and direct communication than through maintaining a formal backlog with only a few active items. This reduced unnecessary administrative overhead and made the work organization more appropriate for the actual scale of the project.
+
+\vspace{2mm}
+
+Version control and shared documentation were important parts of the method. GitHub was used to manage source code and changes over time, while notes and work reports were used to document completed work, encountered problems, and follow-up decisions. This created a lightweight but useful development trail that supported both collaboration and report writing.
+
+\subsection{Why This Method Was Appropriate}
+
+An important reason for choosing this style of method was that \textit{Study Sprint} is a product where usability, flow, and reliability matter at least as much as raw feature count. A more rigid process could have described the intended system early, but it would have been less useful for improving the real experience of moving from planning work to starting a study session.
+
+\vspace{2mm}
+
+The iterative and scope-conscious method therefore matched the project well. It allowed the team to begin with a workable prototype, identify weaknesses through repeated review and testing, and gradually move the application toward a more coherent and dependable final form without losing control of scope.

AppDev/prospectiveTexFiles/solution.tex

@@ -0,0 +1,84 @@
+\section{Solution}
+
+The final solution developed for \textit{Study Sprint} is a mobile productivity application that combines lightweight planning, task-based study sessions, breaks, and visible progress in one workflow. The purpose of the solution was to help students move more easily from deciding what to study to actually starting focused work.
+
+\vspace{2mm}
+
+Rather than functioning only as a timer or only as a planning tool, the application connects the two. A user can create academic structure, choose a concrete task, begin a timed study sprint, continue through short or long breaks, and return to an overview that shows both recent activity and broader progress.
+
+\vspace{2mm}
+
+This product direction was influenced by the Pomodoro technique, where work is divided into focused intervals separated by breaks. That background was relevant because the goal of the project was not simply to count time, but to support a more sustainable and actionable study rhythm. Review literature on Pomodoro-style study intervals suggests that structured work-and-break cycles can improve focus, reduce fatigue, and support sustained performance in demanding learning situations \cite{pomodoro_scoping_review}. For that reason, the final app was built around the idea that planning and focused study should be tightly connected rather than treated as separate tools.
+
+\subsection{Main Components of the Solution}
+
+The solution consists of four closely connected parts:
+
+\begin{itemize}
+    \item a planning system for subjects, assignments, and tasks,
+    \item a task-linked timer flow with focus sessions and breaks,
+    \item a dashboard for overview, progress, and quick actions,
+    \item persistent storage and supporting logic for user data, active sessions, and reminders.
+\end{itemize}
+
+These parts are intended to support one continuous study flow. The user should be able to define what to work on, start working without unnecessary setup, continue through breaks when appropriate, and return to a screen that still gives a clear sense of what has been done and what remains.
+
+\subsection{Planning and Study Structure}
+
+The planning part of the solution gives the user a structured way to organize academic work through subjects, assignments, and tasks. This allows larger and more abstract study obligations to be broken down into smaller actionable units. In practice, this matters because focused work sessions are easier to begin when the user is working from a clearly defined task rather than from a vague intention such as ``study more'' or ``work on the course''.
+
+\vspace{2mm}
+
+This means that the planning system is not only included for bookkeeping. It plays a direct role in the app's main purpose by making it easier to convert study plans into concrete sprint starts.
+
+\subsection{Task-Linked Sprint and Break Flow}
+
+The most central part of the solution is the timer flow. In the final app, a sprint is started from a task, not from a detached timer utility. This ties focused work directly to a chosen piece of study content and makes the session feel like part of the planning workflow rather than a separate feature beside it.
+
+\vspace{2mm}
+
+The timer supports focus sessions as well as short and long breaks. In the final version of the app, the default timing model follows a familiar Pomodoro-style rhythm:
+
+\begin{itemize}
+    \item a default focus session of 25 minutes,
+    \item a default short break of 5 minutes,
+    \item a default long break of 15 minutes after four completed focus sessions.
+\end{itemize}
+
+These default values were chosen because they match the common Pomodoro model closely enough to feel familiar, while still fitting the project's broader goal of low-friction study support. The point was not to claim that one exact timing pattern is universally optimal, but to provide a sensible default that helps the user begin immediately without having to configure the session first.
+
+\vspace{2mm}
+
+At the same time, the app was not designed as a rigid timer. The solution still allows alternative session durations when needed. This was important because flexibility matters in real study situations, but the default path was intentionally kept simple so that customization would not become a barrier to getting started.
+
+\subsection{Dashboard, Progress, and Guided Flow}
+
+The dashboard acts as the application's overview and next-action screen. Instead of functioning only as a static home page, it gives the user a way to resume an active session, start a sprint from relevant tasks, and review recent study activity. This makes the dashboard part of the working flow rather than only a summary screen.
+
+\vspace{2mm}
+
+The solution also includes visible progress indicators and recent-activity summaries so that study effort is easier to interpret over time. This supports motivation and orientation by showing not only what the user planned, but also what they have actually completed or spent time on.
+
+\vspace{2mm}
+
+To reduce friction further, the app also includes guided setup and lightweight help flows. These parts of the solution are especially important for first-time users, since they make the main structure and intended study rhythm easier to understand before the app contains much user-created content.
+
+\subsection{Persistence and Supporting Functionality}
+
+The solution uses Supabase as the main backend for stored user data such as subjects, assignments, tasks, and recorded session information. This provides persistence beyond a single app instance and gives the app a clearer basis for authenticated, user-specific data.
+
+\vspace{2mm}
+
+At the same time, local storage is used for state that is more device- and interaction-specific, such as active-session recovery, study-cycle continuity, and some reminder-related information. This division is useful because not all app state serves the same role. Some data belongs to the durable academic structure, while other data belongs to the immediate behaviour of the app on the device.
+
+\vspace{2mm}
+
+The solution also includes local assignment reminders through notifications. This extends the application beyond passive planning by helping users notice approaching deadlines without requiring a more complex push-notification infrastructure.
+
+\subsection{Why This Solution Fits the Product Goal}
+
+The final solution fits the goals of the project because it remains focused on a small set of connected features rather than trying to become a broad productivity platform. Planning, sprint starts, breaks, reminders, and progress tracking all support the same main objective: helping students begin meaningful study work with less friction and maintain that work through a clearer rhythm of effort and recovery.
+
+\vspace{2mm}
+
+In that sense, the main strength of \textit{Study Sprint} is not feature quantity, but feature connection. A timer alone does not help the user decide what to study, and a planner alone does not help the user begin. The solution developed here is intended to bridge that gap in a lightweight and student-oriented way.