fix: improve member card styling with better chart layout and text hierarchy

[drifter089]

Summary

Improves the member card on the /member page with better visual hierarchy, cleaner chart presentation, and theme-aware colors.

Key Changes

• Fix text hierarchy: Teams heading larger than team names
• Remove borders from charts for cleaner look
• Equalize bar and pie chart heights using shared constant
• Add horizontal gridlines to bar chart
• Use theme-aware chart colors (--chart-1, --chart-2, etc.) instead of hardcoded status colors
• Increase pie chart size (85% outer radius)
• Improve Show button visibility with secondary variant when collapsed

Summary by CodeRabbit

• Refactor
  • Optimized goals bar chart performance with improved color rendering logic and enhanced consistency across visualizations.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
org-os	Ready	Preview, Comment	Jan 9, 2026 6:19pm

[coderabbitai]

Caution

Review failed

The pull request is closed.

📝 Walkthrough

Walkthrough

The goals bar chart color logic is refactored to use an index-based CSS-hsl color resolver function instead of progress-based status colors, simplifying the coloring mechanism across bars, legend dots, and indicators.

Changes

Cohort / File(s)	Summary
Chart color refactoring src/components/charts/goals-bar-chart.tsx	Replaced progress-dependent color logic (STATUS_COLORS, getBarColor) with index-based getChartColor(index) returning CSS-hsl colors. Updated bar fills, legend dots, and indicators to derive colors from chart index rather than entry progress metrics.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• fix: improve member card styling with better chart layout and text hierarchy #370 — Also modifies goals-bar-chart.tsx to change bar color determination logic, affecting the same color scheme implementation.

Poem

🐰 Hop hop, colors bright!
From progress hues to indexed light,
Each bar now shines in ordered way,
The chart's palette saves the day! 🌈

✨ Finishing touches

• 📝 Generate docstrings

---

📜 Recent review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0b172e7 and 792b197.

📒 Files selected for processing (1)

• src/components/charts/goals-bar-chart.tsx

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[claude]

Code Review: Member Card Styling Improvements

Summary

This PR improves the visual presentation of the GoalsBarChart component used in the member card by switching from status-based colors to theme-aware chart colors and simplifying the color logic.

---

✅ Positive Changes

1. Theme-Aware Colors
The shift from hardcoded status colors to theme-aware chart colors (--chart-1 through --chart-5) is excellent. This ensures:

• Consistent color palette across the application
• Proper dark mode support (chart colors adjust automatically)
• Better visual harmony with other components

2. Code Simplification

• Removed 13 lines of hardcoded color constants
• Simplified getBarColor to getChartColor - much cleaner
• Reduced cognitive complexity by removing progress-based color logic

3. Better Separation of Concerns
The chart now focuses purely on displaying data with consistent colors, while the legend and tooltip still show status information (via badges). This is the right approach - status indicators belong in labels/tooltips, not chart colors.

---

⚠️ Concerns & Recommendations

1. Loss of At-a-Glance Status Information

Before: Bar colors indicated goal status (green=exceeded, blue=on track, amber=behind, red=at risk)
After: Colors are just sequential (chart-1, chart-2, etc.) with no semantic meaning

Impact: Users can no longer quickly scan the chart to see which goals are struggling. They must now:

1. Look at each bar individually
2. Check the legend badge for status
3. Or hover for tooltip

Recommendation: Consider keeping status-based colors but using theme-aware status variables instead by defining colors in globals.css and using them with proper theme support. This would preserve the semantic color coding while ensuring theme consistency.

2. Tooltip Still Uses Status Colors

Notice that GoalTooltipContent (lines 231-239) still uses hardcoded status colors for the progress bar (bg-green-500, bg-blue-500, etc.).

Inconsistency: The tooltip shows status-based colors but the chart bars don't. This creates visual confusion.

Recommendation: Either:

• Update tooltip to also use theme-aware colors (if keeping current approach)
• Or revert chart bars to status-based colors

3. Legend Still References Status

The non-simple legend (lines 463-516) displays status badges alongside each goal. Since the chart no longer uses status colors, there's now a disconnect between the colored dot (sequential) and the status badge (semantic).

This isn't necessarily wrong, but could be confusing. The colored dots are now purely for identification, not status indication.

---

🐛 Potential Bugs

None identified. The code is functionally correct.

---

🎨 Code Quality

Excellent:

• Clean, readable code
• Follows project conventions
• No security issues
• No performance concerns

---

🧪 Test Coverage

Not addressed in PR:

• No new tests for the color change
• Existing tests (if any) should still pass since the component API didn't change

Recommendation: Consider adding visual regression tests (Playwright screenshots) to catch unintended color changes in the future.

---

📊 Performance

No performance impact - the change is purely visual.

---

🔒 Security

No security concerns.

---

💡 Additional Suggestions

1. Document the Design Decision
If the loss of status-based colors is intentional (e.g., user feedback said it was too noisy), consider adding a comment explaining why.

2. Consider Accessibility
With status-based colors, color-blind users could still distinguish goals by color families. With sequential colors, this distinction is lost. Ensure the legend badges and tooltips provide sufficient non-color-based information.

---

✅ Final Verdict

The PR is well-executed from a technical standpoint - cleaner code, better theme integration, and no bugs. However, the trade-off of losing status-based colors should be carefully considered from a UX perspective.

Recommendation:

• ✅ Approve if the design team confirms that status-based colors were too busy/confusing
• ⏸️ Request changes if users need at-a-glance goal status visibility

Would love to hear the reasoning behind this design decision. Was it based on user feedback, design principles, or simplification goals?

---

📝 Nitpick

The PR title says "fix:" but this is more of a "style:" or "refactor:" change (conventional commits). "fix:" implies a bug was corrected, but this is an intentional design change.