RFC: Sidebar Navigation Restructure

Date: 2026-03-26 Status: Open for feedback

Problem

The sidebar navigation has 14 items across 3 sections, and it’s not clear what belongs in “Settings” versus the main nav. The Settings section has 7 items that mix program-wide configuration with entity-specific configuration:

Current sidebar:

Main Nav
├── Home
├── Residents
├── Didactics
├── Rotations
└── Jeopardy

Call
├── Schedules
└── Fairness

Settings (7 items!)
├── Program
├── Academic Years
├── Sites
├── Call Types        ← call-specific, not program-wide
├── Call Constraints  ← call-specific, not program-wide
├── Users
└── Jeopardy         ← jeopardy-specific, not program-wide

The core confusion: “Call Types” and “Call Constraints” are call-specific config but live in Settings. “Jeopardy” appears in both the main nav and Settings. “Users” is actively managed but sits next to rarely-changed items like “Sites.”

Guiding Principle

The restructure is based on scope — distinguishing between:

• Program-wide configuration — facts about the program that rarely change (academic years, sites, program name/timezone). These are broad and affect everything.
• Entity-specific management — config tied to specific domains (call types, jeopardy settings). These should live near the entities they configure.

Option A: Colocate Config With Its Domain

Move entity-specific configuration into each domain’s collapsible section. Settings shrinks to only program-wide items.

Main Nav
├── Home
├── Residents
├── Didactics
├── Rotations
└── Jeopardy
    ├── Schedule
    └── Settings

Call
├── Schedules
├── Fairness
├── Types
└── Constraints

────────────────
Settings (program-wide only)
├── Program
├── Academic Years
├── Sites
└── Users

Pros: - Config lives right next to the thing it configures — intuitive - Settings section becomes small and clearly scoped - Scales well as new domains are added (each domain owns its own config) - Follows the “scope” principle cleanly

Cons: - Some domain sections get longer (Call goes from 2 → 4 items) - May need visual distinction between “use” and “configure” sub-items within a section - “Users” in Settings is debatable — it’s actively managed, not really a “program fact”

Option B: Colocate Config + Promote Users

Same as Option A, but also promotes “Users” out of Settings to a top-level nav item. Settings becomes purely “program facts” — things you set up once.

Main Nav
├── Home
├── Residents
├── Didactics
├── Rotations
├── Jeopardy
│   ├── Schedule
│   └── Settings
├── Users
│
├── Call
│   ├── Schedules
│   ├── Fairness
│   ├── Types
│   └── Constraints

────────────────
Program Config
├── General
├── Academic Years
└── Sites

Pros: - Settings/Program Config is very small (3 items) and clearly scoped to “program facts” - “Users” gets the prominence it deserves as an actively-managed feature - Renamed to “Program Config” makes the scope immediately obvious - Cleanest separation of concerns

Cons: - One more top-level item (Users) - Renaming “Settings” to “Program Config” is a change users need to learn

Questions for the Team

1. Which option do you prefer — A or B? Or a mix?
2. Does “Users” feel like a “program fact” or an actively-managed feature?
3. Should we rename “Settings” to “Program Config” to clarify its scope?
4. Any items that feel like they’re in the wrong place in either proposal?

Please share your thoughts — we’ll finalize the design based on feedback.