## Context The app is a single-page React application for EMBA course planning. Users select courses from elective sets, rank specializations by priority, and an optimizer allocates credits to determine which specializations are achieved. The UI has three usability gaps identified in the proposal: terse algorithm descriptions, minimal loading feedback, and hidden credit breakdowns for achieved specializations. All three changes are scoped to existing React components with no new dependencies, API changes, or data model changes. ## Goals / Non-Goals **Goals:** - Make the optimization mode descriptions clear enough that users understand the practical trade-off without needing external documentation. - Provide immediate visual feedback via skeleton placeholders when analysis is in progress. - Ensure users always see credit breakdowns for achieved specializations without requiring discovery of click-to-expand. **Non-Goals:** - Redesigning the ModeToggle layout or switching to a different control type (dropdown, radio, etc.). - Adding a global progress bar or percentage indicator for the worker. - Making non-achieved specializations expandable. - Adding animation/transition effects to the skeleton loading. ## Decisions ### Algorithm explanations approach **Decision**: Replace the single-line `
` description below the segmented control with a multi-line explanation block that describes each mode in terms of its practical behavior and when to use it. **Rationale**: Users need to understand the trade-off (breadth vs. guarantee) to make an informed choice. A slightly longer description (2-3 sentences) directly below the active button conveys this without cluttering the UI. Alternative considered: tooltips on each button — rejected because they require hover (not mobile-friendly) and hide information by default. ### Skeleton loading approach **Decision**: When `loading` is true and no `analysis` exists for a set, render skeleton placeholder rectangles in place of the course choice buttons. Replace the "analyzing..." text label with these visual placeholders. **Rationale**: Skeleton screens communicate that content is loading and will appear in-place, reducing perceived wait time. They also reserve layout space, preventing content jumps. Alternative considered: spinner overlay — rejected because it blocks interaction and doesn't communicate what's loading. **Implementation**: Render 2-3 rectangular `