\section{Architectural Design and Philosophy}

\subsection{Overview}
Study Sprint was designed around a clear hierarchical productivity model:

\begin{center}
\textbf{Subject $\rightarrow$ Assignment $\rightarrow$ Task}
\end{center}

\vspace{2mm}

This hierarchy became the foundation for how navigation and screen-level interaction was handled. The design aimed to make the application intuitive, reduce redundancy, and to make sure the interface reflected the actual the hierarchy in addition to the back-end database structure.

\vspace{2mm}

The goal for the design was to create an application that feels calm, minimal, and easy to understand. The architecture emphasizes context, structure, and progressive disclosure.

\subsection{Architectural Motivation}

The initial structure of the application that I was given treated several related entities as if they were independent. Subjects, assignments, and tasks were all exposed on the top-level I'm guessing this made basic CRUD operations easier to test while developing the back-end. In any case t his did not match the product model. This version of the code created several problems:

\begin{itemize}
    \item tasks could appear without sufficient assignment or subject context,
    \item assignments felt detached from their parent subjects,
    \item the interface duplicated information across multiple screens,
    \item the difference between assignments and tasks are nuanced
\end{itemize}

To fix this, the application was restructured so that the architecture of the interface matched the architecture of the data.

\subsection{Navigation Architecture}
The top-level navigation was simplified into three tabs, and in the final product, two tabs.

\begin{itemize}
    \item \textbf{Dashboard}
    \item \textbf{Subjects}
    \item \textbf{Timer}, now directly integrated into the Task-level
\end{itemize}

This was a deliberate decision. The application in its initial state risked becoming too flat by exposing assignments and tasks as separate top-level tabs. However, assignments and tasks are not standalone concepts.

\vspace{2mm}

The new tab structure gives each destination a distinct role:

\begin{itemize}
    \item \textbf{Dashboard} acts as an overview screen for cross-cutting information
    \item \textbf{Subjects} acts as the primary entry point into the study hierarchy
\end{itemize}

\subsection{Hierarchy-Driven Screen Design}
The screen flow follows the actual logical structure of the application:

\begin{itemize}
    \item the \textbf{Subjects} screen presents all subjects,
    \item the \textbf{Subject Details} screen acts as the hub for a single subject and its assignments,
    \item the \textbf{Assignment Details} screen acts as the hub for a single assignment and its tasks,
    \item the \textbf{Task Details} screen focuses on one task while preserving its parent context.
\end{itemize}

This means that users move deeper into the structure through meaningful parent-child relationships rather than through disconnected CRUD pages.

\subsection{Hub-Based Detail Screens}
A major architectural choice was to turn detail pages into \emph{management hubs} instead of simple read-only detail views.

\subsubsection{Subject Details as a Hub}
The subject details screen was designed to serve as the central management hub for a subject. It contains:

\begin{itemize}
    \item subject summary information,
    \item status and metadata,
    \item actions such as edit and delete,
    \item action for creating assignments,
    \item assignment sections organized by completion state.
\end{itemize}

This supports a structured flow where the users naturally move from a subject, into an assignment, and then into the tasks that make it actionable.

\subsection{Reduction of Redundancy}
One of the main architectural design principles was the removal of unnecessary duplication

\subsubsection{Removal of Top-Level Assignment and Task Navigation}
Assignments and tasks were removed from the tab bar because they did not function as top-level concepts in practice. Their meaning depends on the parent hierarchy. Keeping them as top-level tabs only worsens the contextual clarity and created repeated list views that duplicated information already available deeper in the hierarchy.

\subsubsection{Reduction of Inline Management Controls}
List screens were simplified so that entity cards primarily function as entry points rather than control panels. For example subject cards no longer contain too many management actions such as inline edit, delete, or progress-heavy UI. Those actions were moved into the corresponding hub screens.

\vspace{2mm}

This follows a simple principle: browsing screens should prioritize selection and orientation, while detail screes should prioritize management.

\subsection{Reusable Upsert-Based Form Design}
Another architectural decision was to reduce duplication in entity creation and editing workflows.

Originally, create and edit flows existed as separate screens even when they used close to identical fields, validation control, and layout. This increased maintenance overhead and produced repeated code.

\vspace{2mm}

To improve this, the application moved toward an \textbf{upsert-based form architecture}. In this pattern, a single screen handles both creation and editing:

\begin{itemize}
    \item if no id is present, the form works in create mode,
    \item if an id is present, the form loads existing data and works in edit mode
\end{itemize}

This was implemented for core entity forms such as subjects, assignments, and tasks. The benefit is that validation, styling, and layout remain consistent while avoiding unnecessary duplication of screen logic.

\subsection{Shared Utility Extraction}
As the design progressed, common patterns were extracted into globally shared utility modules.

\subsubsection{Date Formatting}
Date and timestamp rendering was centralized in a shared formatting utility. This replaced raw database timestamps with user-friendly display values and ensured consistency across subject, assignment, and task screens.

\subsubsection{Subject Color System}
A dedicated subject color utility was introduced to centralize:

\begin{itemize}
    \item the available subject color palette,
    \item the type definition for valid subject colors,
    \item the mapping between a subject color key and its visual values,
    \item helper logic for retrieving the correct visual accent set.
\end{itemize}

This avoided repeated color logic and ensured that subject styling remained consistent across the hierarchy.

\subsection{Design Philosophy}
The architectural design was strongly influenced by a clear philosophy. The UI was intentionally shaped by the following principles.

\subsubsection{Calm over visual noise}
The interface was designed to feel calm and discreet. The goal was not to make everything look awesome, but to make structure understandable and interaction obvious. This led to a restrained card-based UI, reduced redundancy, and fewer competing visual accents.

\subsubsection{Hierarchy over flatness}
The interface should communicate the real structure of the application. The design preserves parent-child relationships instead of flattening all the entities. This improves orientation and helps the user understand where they are in the study workflow.

\subsubsection{Context over abstraction}
The deeper the user moves into the hierarchy, the more important context becomes. For this reason assignment screens display subject context, and task screens display subject context, and task screens display both subject and assignment context. This prevents the user from losing track of where a specific item belongs.

\subsubsection{Consistency over novelty}
The design favors repeated, understandable patterns over excessive variation. Pills, card, spacing, and stable action buttons are reused deliberately so that the application feels predictable. Primary actions continue to use the app-level accent, while subject colors are used for contextual identity.

\subsubsection{Identity through controlled color}
Subjects were given user-selectable accent colors from a predefined palette. This creates a stronger sense of identity without overwhelming the interface. The subject color is inherited by related assignment and task screens, visually reinforcing the branch structure of the hierarchy.

\vspace{2mm}

This color is not used for everything. A key design rule was maintained:

\begin{itemize}
    \item \textbf{app accent color} = primary actions,
    \item \textbf{subject color} = contextual identity.
\end{itemize}

This distinction keeps the interaction language stable while still giving each subject a recognizable visual signature.

\subsection{Card-Based Interface Design}
The design used a consistent card-based layout. Cards were used to group related information and actions. This supports readability and imporoves structure.

Each card is designed to:
\begin{itemize}
    \item present on conceptual unit,
    \item reduce visual clutter,
    \item support quick scanning,
    \item separate context from action.
\end{itemize}

Subject cards emphasize browing and selection. Detail cards emphasize context and management. This distinction was important in making the UI feel more intentional.

\subsubsection{Progress Representation}
Progress indicators were intentionally limited to screens where they carry structural meaning. Rather than showing progress everywhere, progress was only shown on screens such as subject and assignment details.

Progress is represented using both:

\begin{itemize}
    \item a visual progress bar,
    \item a numeric completion ratio such as \texttt{x / y},
    \item remaining assignments/tasks text.
\end{itemize}

This makes progress easier to interpret than a bar alone and avoids ambiguity.

\subsection{Outcome}
The final architecture now emphasizes:
\begin{itemize}
    \item clear hierarchy,
    \item reduced redundancy,
    \item stronger contextual awareness,
    \item reusable form patterns,
    \item shared utility logic,
    \item cleaner, calmer interaction design.
\end{itemize}

As a result, the interface now accurately reflects the study workflow and provides an overall better foundation for usability and maintainability.