Most Gantt charts look correct.
- Tasks are scheduled.
- Dependencies are respected.
- Timelines appear clean.
And yet, projects still slip and teams still burn out.
After building and integrating scheduling tools in real-world systems, I kept seeing the same pattern:
Gantt charts are very good at modeling tasks —
but surprisingly bad at modeling people.
This post shares why that happens, and how I approached rebuilding a Gantt chart to be resource-aware in version 1.9.0.
The real problem: tasks don’t consume time, people do
Traditional Gantt charts answer one question extremely well:
When does this task happen?
But they struggle with a more important one:
Who is being used, how much, and at the same time?
In reality:
- A single person often works on multiple tasks concurrently
- Each task consumes only part of their capacity
- Overload accumulates gradually, not discretely
When this information is hidden, schedules look correct right up until they fail.
Shifting perspective: introducing Resource View
In v1.9.0, the chart supports two explicit modes:
- Task View — rows represent tasks (classic Gantt)
- Resource View — rows represent resources (people, machines, workstations)
viewMode: 'task' | 'resource'
In Resource View:
- Each row corresponds to a resource
- Multiple task bars may overlap in the same time window
- Layout is calculated dynamically rather than blindly stacked
This shift doesn’t just change the UI — it changes how scheduling problems are understood.
Making resource allocation explicit
To support resource-first planning, the Task model was extended with allocation data:
resources: [
{ resourceId: 'devA', percent: 50 },
{ resourceId: 'devB', percent: 30 }
]
Design decisions behind this model:
- Allocation is explicit (10–100%)
- Multiple resources per task are supported
- Backward compatibility is preserved (defaults to 100%)
Once allocation is first-class data, the system can reason about capacity instead of assumptions.
Visualizing load instead of hiding it
Numbers alone don’t help if they’re buried in dialogs.
So allocation is visualized directly on the timeline:
- Task bar height scales with allocation percentage
- Percent labels are visible inline
- Tooltips expose detailed allocation context
This makes resource pressure visible without any clicks.
Detecting overload when it actually happens
The most important feature added in v1.9.0 is overload detection.
Within the same time window:
- Same resource
- Multiple tasks
- Accumulated allocation exceeds 100%
The chart highlights overload visually at the exact point it occurs.
This is where a Gantt chart stops being a passive timeline and starts acting as a decision-support tool.
Interaction parity across views
Resource View is not a read-only visualization.
All core interactions remain available:
- Dragging tasks
- Resizing timelines
- Time-based adjustments
If a view affects planning decisions, it should support planning actions.
Architecture and performance considerations
To keep this scalable and maintainable:
- Resource layout logic was extracted into independent composables
- Rendering optimizations were expanded using memoization
- Scroll debouncing was reintroduced to balance responsiveness and performance
- Theme scoping was fixed at the component level to avoid global side effects
The goal was to add capability without adding architectural debt.
Closing thoughts
Good scheduling tools shouldn’t just tell us when work happens.
They should help answer a harder question:
Is this plan actually feasible for the people involved?
Making resource usage visible changes how teams reason about schedules.
v1.9.0 is a step toward more honest planning tools.
If you’re building planning, scheduling, or resource-heavy systems,
I’d love to hear how you approach resource modeling in practice.
Demo Video
Top comments (0)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.