0% found this document useful (0 votes)
2 views2 pages

Project Report Final

The Design Decisions Report outlines key visual identity and UX choices for the Task Board Project, including a soft-UI aesthetic and improved typography for better user focus. It details architectural decisions like dropdown-first navigation and modular component patterns to enhance maintainability and performance. Additionally, it discusses backend assumptions such as session management, audit trails, and content sanitization to ensure a secure and efficient system.

Uploaded by

Amaan Khan
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views2 pages

Project Report Final

The Design Decisions Report outlines key visual identity and UX choices for the Task Board Project, including a soft-UI aesthetic and improved typography for better user focus. It details architectural decisions like dropdown-first navigation and modular component patterns to enhance maintainability and performance. Additionally, it discusses backend assumptions such as session management, audit trails, and content sanitization to ensure a secure and efficient system.

Uploaded by

Amaan Khan
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Design Decisions Report

Task Board Project Refinement

COP290 Assignment 2
[Link]

March 22, 2026

1 Visual Identity and UX Decisions

1.1 Soft-UI Aesthetic


To improve user focus and minimize cognitive load, we adopted a consistent soft-rounded
aesthetic (approx. 12px-16px border-radius) across the entire application. This applies to:

• Kanban columns and task cards.

• Modals, dropdowns, and input fields.

• Profile avatars and badge elements.

1.2 Typography and Contrast


• Visual Hierarchy: Project headings were centered and enlarged to provide clear context
on the Board view.

• Legibility: Comment systems were updated with explicit font colors (#172b4d) to ensure
typed text is perfectly visible against both light and dark background variations.

• Information Density: Column widths were reduced to allow for better horizontal scan-
ning and to prioritize information density on the task cards.

2 Architectural and UI Structural Decisions

2.1 Dropdown-First Navigation


We moved away from disruptive full-screen modals for frequent actions. Both Create Task
and Manage Team were converted into slick, top-bar dropdowns. This keeps the user in the
context of their board while performing project management tasks.

2.2 Description Box Clarity


The task description field was redesigned as a distinct, light-blue bounded rectangle (#e6f0ff).
This separates user-generated content from system metadata, making it easier to parse long-
form requirements.

1
3 Technical Refinement Decisions

3.1 Modular Component Pattern


As the ProjectBoard and ProjectsDashboard grew, we made the decision to extract lengthy
inline JSX into over 14 independent components. This:

• Improves code maintainability by keeping files under 400 lines.

• Enhances performance by isolating React re-renders to specific sub-trees (e.g., just the
notifications dropdown or a single task card).

3.2 Data Sanitization and Parsing


• Audit Logging: We implemented custom audit trail logic for specific transitions like
TASK_CLOSED and TASK_REOPENED to ensure accountability.

• Regex-Based Markdown: To avoid heavy external libraries, a custom Regex pipeline


was built to handle Bold, Italic, and User Mentions (@username) in the collaboration feed.

4 Backend and Architectural Assumptions

While the assignment provided a strong functional foundation, we made several key architectural
decisions and assumptions to ensure the system is production-ready:

4.1 Session Management and Token Rotation


Beyond basic JWT authentication, we implemented a Refresh Token mechanism. This
allows for shorter-lived access tokens (improving security) while maintaining a seamless user
experience through silent token rotation.

4.2 Decoupled Audit Trails


Instead of deriving task history through expensive database joins or frontend-only logic, we
implemented a dedicated AuditLog entity. Every critical state change (Status, Assignee,
Closure) is recorded as a discrete event, serving as an immutable source of truth for the Activity
Timeline.

4.3 Granular Permission Middleware


We assumed a member-only visibility model. Global Admins have universal access, but
within projects, a custom middleware layer performs role-checks (Member/Viewer) before al-
lowing access to boards, ensuring data isolation.

4.4 Rich Content Sanitization


For the collaboration system, we assumed a strict sanitization-first policy. All comment
data is processed through a custom filter that strips unsafe HTML while allowing our Regex-
based markdown parser to safely render bold, italic, and user-mention tokens.

You might also like