What's the situation?
On the Dashboard's "Who's Around" section, adjacent 15-minute time slots are merged into larger blocks for readability. For example, if a user is available from 17:00 to 18:00, that appears as a single "5:00 PM - 6:00 PM" row instead of four separate 15-minute entries.
The merging logic (groupAdjacentSlots in ScheduleSummary.tsx) groups consecutive slots that share the same set of available users. This works well for compactness, but it does not account for per-slot slot_status differences.
What's the problem?
When a user marks some slots as "available" and adjacent slots as "tentative", the merged group flattens those distinctions. All users in the merged block display a single status color (whichever the lookup returns for one representative slot), even though some of their constituent slots may have a different status.
Example: a user has 17:00-17:15 as available (green) and 17:15-17:30 as tentative (amber). If both slots end up in the same merged group, the avatar ring shows one color for the whole block rather than reflecting the per-slot difference.
Proposed improvement
When building merged groups, break the group boundary not only when the set of users changes, but also when any user's slot_status changes between adjacent slots. This would produce slightly more rows on the Dashboard but would preserve the visual distinction between available and tentative time.
Implementation sketch
In groupAdjacentSlots, the current merge condition checks whether consecutive slots have the same user set. Extend this to also compare the slot_status for each user:
// Current: merge if same users
sameUsers(prev.users, curr.users)
// Proposed: merge if same users AND same per-user slot_status
sameUsers(prev.users, curr.users) && sameSlotStatuses(prev, curr)
Where sameSlotStatuses checks that for every user in the set, their slot_status in the current slot matches their slot_status in the previous slot.
Trade-offs
- Pro: Accurate per-slot-status colors on Dashboard, consistent with what users set on the Availability page.
- Con: More rows when a user has a mixed available/tentative block, which can make the Dashboard busier. In practice this is uncommon since users tend to set contiguous blocks to the same status.
Priority
Low. The current behavior is functional and readable. The visual inaccuracy only matters when a user intentionally mixes available and tentative slots in adjacent time windows, which is an edge case.
What's the situation?
On the Dashboard's "Who's Around" section, adjacent 15-minute time slots are merged into larger blocks for readability. For example, if a user is available from 17:00 to 18:00, that appears as a single "5:00 PM - 6:00 PM" row instead of four separate 15-minute entries.
The merging logic (
groupAdjacentSlotsinScheduleSummary.tsx) groups consecutive slots that share the same set of available users. This works well for compactness, but it does not account for per-slotslot_statusdifferences.What's the problem?
When a user marks some slots as "available" and adjacent slots as "tentative", the merged group flattens those distinctions. All users in the merged block display a single status color (whichever the lookup returns for one representative slot), even though some of their constituent slots may have a different status.
Example: a user has 17:00-17:15 as available (green) and 17:15-17:30 as tentative (amber). If both slots end up in the same merged group, the avatar ring shows one color for the whole block rather than reflecting the per-slot difference.
Proposed improvement
When building merged groups, break the group boundary not only when the set of users changes, but also when any user's
slot_statuschanges between adjacent slots. This would produce slightly more rows on the Dashboard but would preserve the visual distinction between available and tentative time.Implementation sketch
In
groupAdjacentSlots, the current merge condition checks whether consecutive slots have the same user set. Extend this to also compare theslot_statusfor each user:Where
sameSlotStatuseschecks that for every user in the set, theirslot_statusin the current slot matches theirslot_statusin the previous slot.Trade-offs
Priority
Low. The current behavior is functional and readable. The visual inaccuracy only matters when a user intentionally mixes available and tentative slots in adjacent time windows, which is an edge case.