# Toggle Button UI/UX Considerations - December 2025
**Status**: ⚠️ PLANNED / UNDER DISCUSSION
## Problem Statement
The current ON/OFF vs AUTO/MANUAL toggle buttons in AgentHealth component have visual design issues that affect usability and clarity.
**Location**: `aggregator-web/src/components/AgentHealth.tsx` lines 358-387
## Current Implementation Issues
### 1. Visual Confusion Between Controls
- ON/OFF and AUTO/MANUAL use similar gray colors when off
- Hard to distinguish states at a glance
- No visual hierarchy between primary (ON/OFF) and secondary (AUTO/MANUAL) controls
### 2. Disabled State Ambiguity
- When subsystem is OFF, AUTO/MANUAL shows `cursor-not-allowed` and gray styling
- Gray disabled state looks too similar to enabled MANUAL state
- Users may not understand why AUTO/MANUAL is disabled
### 3. No Visual Relationship
- Doesn't communicate that AUTO/MANUAL depends on ON/OFF state
- Controls appear as equals rather than parent/child relationship
## Current Code
```tsx
// ON/OFF Toggle (lines 358-371)
// AUTO/MANUAL Toggle (lines 374-388)
```
## Proposed Solutions (ETHOS-Compliant)
### Option 1: Visual Hierarchy & Grouping
Make ON/OFF more prominent and visually group AUTO/MANUAL as subordinate.
**Benefits**:
- Clear primary vs secondary control relationship
- Better visual flow
- Maintains current functionality
**Implementation**:
```tsx
// ON/OFF - Larger, more prominent
// AUTO/MANUAL - Indented or bordered subgroup
```
### Option 2: Lucide Icon Integration
Use existing Lucide icons (no emoji) for instant state recognition.
**Benefits**:
- Icons provide immediate visual feedback
- Consistent with existing icon usage in component
- Better for color-blind users
**Implementation**:
```tsx
import { Power, Clock, User } from 'lucide-react'
// ON/OFF with Power icon
{subsystem.enabled ? 'ON' : 'OFF'}
// AUTO/MANUAL with Clock/User icons
{subsystem.auto_run ? (
<>AUTO>
) : (
<>MANUAL>
)}
```
### Option 3: Simplified Single Toggle
Remove AUTO/MANUAL entirely. ON means "enabled with auto-run", OFF means "disabled".
**Benefits**:
- Maximum simplicity
- Reduced user confusion
- Fewer clicks to manage
**Drawbacks**:
- Loses ability to enable subsystem but run manually
- May not fit all use cases
**Implementation**:
```tsx
// Single toggle - ON runs automatically, OFF is disabled
```
### Option 4: Better Disabled State
Keep current layout but improve disabled state clarity.
**Benefits**:
- Minimal change
- Clearer state communication
- Maintains all current functionality
**Implementation**:
```tsx
// When disabled, show lock icon and make it obviously inactive
{!subsystem.enabled && }
{subsystem.auto_run ? 'AUTO' : 'MANUAL'}
```
## ETHOS Compliance Considerations
✅ **"Less is more"** - Avoid over-decoration, keep it functional
✅ **"Honest tool"** - States must be immediately clear to technical users
✅ **No marketing fluff** - No gradients, shadows, or enterprise UI patterns
✅ **Color-blind accessibility** - Use icons/borders, not just color
✅ **Developer-focused** - Clear, concise, technical language
## Recommendation
Consider **Option 2 (Lucide Icons)** as it:
- Maintains current functionality
- Adds clarity without complexity
- Uses existing icon library
- Improves accessibility
- Stays minimalist
## Questions for Discussion
1. Should AUTO/MANUAL be a separate control or integrated with ON/OFF?
2. How important is the use case of "enabled but manual" vs "disabled entirely"?
3. Should we A/B test different approaches with actual users?
4. Does the current design meet accessibility standards (WCAG)?
## Related Code
- `aggregator-web/src/components/AgentHealth.tsx` lines 358-387
- Uses `cn()` utility for conditional classes
- Current colors: green (ON), blue (AUTO), gray (OFF/MANUAL/disabled)
- Button sizes: text-xs, px-3 py-1
## Next Steps
1. Decide on approach (enhance current vs simplify)
2. Get user feedback if possible
3. Implement chosen solution
4. Update documentation
5. Test with color-blind users