[Gantt Chart] - Improvements

[chpy04]

Overview

As a centralized view of the timelines of every project on Finishline, the Gantt Chart is one of the core pages of the application. It is relevant for nearly everyone on the site, from leadership to members to judges. While the current Gantt Chart functions with a good design, there are a series of improvements that need to be made in order to improve the user experience. These improvements can be broken down into 4 main sections:

• Speed
• View Windows
• Bugs
• Mobile Friendly

Stakeholders

Product Stakeholder: @naishahmistry
Software Stakeholder: @chpy04 @walker-sean
Reference Users: @chpy04

User Story

• As a member, I want to be able to quickly navigate through the gantt chart, opening and closing projects without lag, so that I can quickly find and open relevant projects.
• As a lead / head, I want to be able to change and move timelines quickly without lag, so that I can iterate and modify timelines without my experience being worsened by speed
• As a general viewer, I want to be able to select from a list of time ranges to view the gantt chart in, so that I can see the level of detail that I want, whether that be an overall view of the whole year or a week-by-week view of a specific work package
• As a general viewer, I want to be able to set filters that actually filter the projects that show up, the projects should not have massive spaces between then, and the filters should save between refreshes and be shareable with a URL, so that I can set up a view of the Gantt Chart that makes sense for my role and not have to touch the filters every time I go to the page.
• As a general viewer, I want to be able to view and navigate the Gantt Chart from my phone, so that I can see project timelines on the go

Success Metrics

The primary success metric of this epic would be increased use of the Gantt Chart across the club. If users are able to easily navigate and view content on the Gantt Chart, they should spend a higher percentage of time on the page compared to other pages.

Rollout Plan

For the most part, this feature should be rolled out continuously with incremental merges into Develop. Larger related tasks, such as speed improvement,s may be broken into mini-feature branches to span multiple tickets, but for the most part, there shouldn't be any branches with more than 5 sub-tickets. All improvements should be completed by the end of the spring semester of 2026, so that engineers can use the updated Gantt Chart when planning timelines for the 2027 competition season.

Out of Scope

Improving the readability of the retrospective Gantt Chart is something that could be done after the other items in this epic, but would likely require design and input from the product team, so for now it is out of scope. In addition, the design of the Gantt Chart (how it looks and what information is displayed) does not need to be changed for this ticket, so those kinds of improvements are out of scope.

Background / Context

We already have a Gantt Chart, but it is very slow and annoying to use, so people aren't clicking around it as much as would be useful, and editting the Gantt Chart is essentially never used right now. While the editting is in part because of a lack of advertisement of the feature, it is also extremely frustrating to use because of the speed concerns, so we would like to make it more usable first and then advertise it. This epic also helps to address speed concerns that have surrounded finishline. With this page being one of the more visitted ones, increasing its speed will help substantially with not only the user experience but also the overall public perception of finishline.

Acceptance Criteria & Mock-ups

Speed Improvement

Overall, the acceptance criteria for the speed improvements on the Gantt Chart is that after the initial page load, users should not experience any lag or loading times for anything other than when they change filters or hit a post endpoint to change something. Clicking to drop down projects should have a single smooth animation without delay, scrolling left / right or up / down should be fluid without buffering, and the speed of specific projects should be independent of the number of projects on the screen. In terms of editting, when a user clicks to edit / create a project, there should be no noticable buffering time to pull up the new view. Changing the length or start date of objects in the Gantt Chart should have no delay, and it should be snap the chart to the location where the mouse actually drags it too. While the technical implementations speed improvements will be largely up to the discression of the lead working on the project, there are some specific requirements:

• filtering should be done on the backend instead of the frontend, so when a user changes filters it should make a new request that returns only the data that is relevant for that filter
• There should be as little re-rendering as possible, and specifically opening / editting one project should not cause re-renders of other projects
• By default filters should apply only to the latest car, to prevent it from loading every project
• The Gantt Chart should still use the same abstraction across projects, work packages, and tasks to display "Gantt Tasks" (Although it is recommended that the name of the abstraction be changed to something other than task not that tasks are objects on the Gantt Chart)
  To verify that the speed improvements are working ass expected, the first step for this epic should be creating much more extensive seed data to stress test the system. An external package should at least be considered for this use case, although it may be the case that the editting capabilities make it so it is easier to code custom components.

View Windows

The user should be able to select from a dropdown to change the time window they are looking at. Currently, the time window is hard coded to show roughly 6 months of time. The drop down options should be the following:

• "Week" which shows two weeks across the screen on a normal application window and highlights day numbers at the top
• "Month" which shows two months across the screen on a normal application window and highlights week numbers at the top
• "Half Year" which shows eight months across the screen on a normal application window and highlights week numbers at the top (slightly wider range than the current implementation)
• "Year" which shows 18 months across the screen on a normal application window and highlights months at the top
  Across all views, each element should take up a proportional amount of time on the chart, although there should be a minimum screen width that each element takes up even if it is shorter than that on the timeline. While the dropdowns should be hard coded, the implementation should aim to abstract as much of the time window as possible such that adding different time frames in the future is a relatively easy task. the full functionality for viewing and editting should be available on every view.

Bugs

There are a series of miscanlenious bugs currently on the Gantt Chart that should be fixed in the development of this epic (it is recommended that these are tackled after the speed issues and view windows are resolved as they might be fixed in re-writing the code regardless).

• Filtering by sub-team should show projects for that subteam (right now shows nothing)
• Filtering should show all the applicable projects stacked directly on top of each other, instead of leaving spaces where the filtered out projects were
• Editting the length or start date of a Gantt Element should put it where the user releases the mouse but currently there seems to be a one off bug
• if a work package depends on two other work packages, it should not show up twice

Mobile

The mobile portion of this epic will be based on the mobile epic, and encompasses all mobile designs related to the Gantt Chart Page

Tickets

• #
• #