# Plan: Full UI/UX Cleanup & Simplification

## Context

The OutputTypeTable was refactored from cramped 18-column inline editing to an expandable form row — a dramatic UX improvement. The same pattern should be applied to all other admin tables that suffer from the same problem. Additionally, several pages have UX inconsistencies (mixed editing patterns, tiny inputs, confusing controls) that need cleanup.

**Principle**: Tables are for **viewing** data. Editing happens in **expandable rows** or **modals** — never in cramped inline cells.

## Affected Files

| File | Change | Priority |
|------|--------|----------|
| `frontend/src/components/admin/RenderTemplateTable.tsx` | Expandable edit row (11 cramped columns) | HIGH |
| `frontend/src/components/admin/PricingTierTable.tsx` | Expandable edit row (6 columns, mixed add/edit) | HIGH |
| `frontend/src/components/admin/GlobalRenderPositionsPanel.tsx` | Expandable edit row (8 columns, tiny inputs) | MEDIUM |
| `frontend/src/pages/WorkerManagement.tsx` | Larger touch targets, better scale controls | MEDIUM |
| `frontend/src/pages/Billing.tsx` | Fix status dropdown disguised as badge | MEDIUM |
| `frontend/src/pages/OrderDetail.tsx` | Cleaner line table, material override UX | LOW |

## Tasks (in order)

### [x] Task 1: RenderTemplateTable — expandable edit row

- **File**: `frontend/src/components/admin/RenderTemplateTable.tsx`
- **What**: Same pattern as OutputTypeTable refactor:
  1. Display row ALWAYS shows (no conditional switching)
  2. Edit form opens as a new `<tr>` below with `colSpan` spanning all columns
  3. Grid form inside with labeled fields, grouped logically:
     - Row 1: Name, Category, Output Types (multi-select)
     - Row 2: Collection name, Material Replace, Lighting Only, Shadow Catcher, Camera Orbit
     - Row 3: .blend File (upload/download/re-upload with proper spacing)
     - Row 4: Active toggle + Save/Cancel buttons
  4. "Add new" form also uses the expandable pattern (button at top opens a full-width form row)
  5. Use `React.Fragment` for dual-row rendering
- **Acceptance gate**: Edit mode shows a well-organized form below the display row; .blend file upload has proper spacing; no horizontal overflow
- **Dependencies**: None
- **Risk**: The .blend file upload flow (upload vs clone) is complex — needs careful preservation

### [x] Task 2: PricingTierTable — expandable edit row

- **File**: `frontend/src/components/admin/PricingTierTable.tsx`
- **What**: Replace inline cell editing with expandable form row:
  1. Display row always visible with read-only values
  2. Edit form as expandable row below with grid layout:
     - Row 1: Category Key (select), Quality Level (input), Price per Item (number input)
     - Row 2: Description (textarea, full width)
     - Row 3: Active toggle + Save/Cancel
  3. "Add Tier" button opens the same expandable form at the top
  4. Consistent visual: accent left border on edit row
- **Acceptance gate**: No inline cell editing; form has proper labels; description gets full width
- **Dependencies**: None
- **Risk**: Low — simple table with few fields

### [x] Task 3: GlobalRenderPositionsPanel — expandable edit row

- **File**: `frontend/src/components/admin/GlobalRenderPositionsPanel.tsx`
- **What**: Replace inline cell editing with expandable form row:
  1. Display row keeps compact view (Name, X°, Y°, Z°, Focal, Default, Order)
  2. Edit form as expandable row:
     - Row 1: Name (wide), Is Default (checkbox with label)
     - Row 2: Rotation X°, Rotation Y°, Rotation Z° (number inputs with proper width)
     - Row 3: Focal Length mm, Sensor Width mm, Sort Order
     - Row 4: Save/Cancel buttons
  3. "Add Position" opens same expandable form
  4. Wider number inputs (`w-24` instead of `w-16`) for comfortable editing
- **Acceptance gate**: Rotation inputs are comfortable to edit; no cramped cells; proper labels
- **Dependencies**: None
- **Risk**: Low — straightforward table

### [x] Task 4: WorkerManagement — better scale controls

- **File**: `frontend/src/pages/WorkerManagement.tsx`
- **What**: Improve the concurrency/scale controls:
  1. Replace tiny `w-6` number displays with `w-12` minimum
  2. Make up/down buttons larger (`p-2` instead of default, `rounded-lg`)
  3. Add proper labels above each control ("Min Concurrency", "Max Concurrency")
  4. Group the scale controls in a card with clear section header
  5. Make the "Save" button more prominent (full-width at bottom of card)
- **Acceptance gate**: Controls are easy to click; labels are clear; no overflow on mobile
- **Dependencies**: None
- **Risk**: Low — cosmetic changes only

### [x] Task 5: Billing — fix status dropdown UX

- **File**: `frontend/src/pages/Billing.tsx`
- **What**: Fix the status dropdown that looks like a badge:
  1. Replace the `<select>` styled as a badge with an explicit dropdown button that opens a small popover/menu
  2. OR: keep the select but add a visible dropdown arrow indicator and border on hover to signal interactivity
  3. Make action buttons (download, delete) slightly larger with visible borders
  4. Add tooltips to icon-only action buttons
- **Acceptance gate**: Users can tell the status is interactive (not just a badge); action buttons are easy to click
- **Dependencies**: None
- **Risk**: Low — UI-only changes

### [x] Task 6: OrderDetail — cleaner material override UX

- **File**: `frontend/src/pages/OrderDetail.tsx`
- **What**: Polish the per-line material override dropdown:
  1. Move the material override dropdown from inside the "Output Type" column to its own column or a cleaner inline position
  2. Only show the dropdown on hover or when the line has an override set (reduce visual noise)
  3. The batch override dropdown above the table should be more visually prominent — card-style with label, not just inline text + select
- **Acceptance gate**: Material override is discoverable but not visually noisy; batch override is clearly labeled
- **Dependencies**: None
- **Risk**: Low — visual adjustment

## Migration Check

**No** — all changes are frontend-only.

## Order Recommendation

Tasks 1-3 can be done in parallel (independent admin components).
Tasks 4-6 can be done in parallel (independent pages).

Recommended execution: Tasks 1-3 first (highest impact), then 4-6.

## Risks / Open Questions

1. **RenderTemplateTable .blend upload**: The file upload flow (choose file → upload → or clone from existing) is complex. The expandable form needs to preserve this exact functionality without breaking the upload mutation.

2. **Consistency with OutputTypeTable**: The expandable form pattern should look identical across all admin tables — same grid spacing, same accent border, same Save/Cancel button placement. Consider extracting a shared `ExpandableEditRow` wrapper if patterns diverge.

3. **Add-new forms**: Some tables have "Add" as a button that opens a modal-like form at the top, others have an inline row. Standardize: "Add" button at the top → opens expandable form row at the top of the table body (same pattern as edit).