Alex Blank
a905cf729e
- Restored original desktop CSS that was accidentally overwritten - Added back all mobile-specific styles - CSS file now 3945 lines (original + mobile styles) - Build passes successfully
4.3 KiB
Context
The current mobile experience for complex configuration and workspace pages is inadequate:
- Tool Workshop (desktop split-pane): List on left, detail/edit form on right. On mobile, both panels are cramped and unusable.
- Config Profiles (desktop split-pane): Same issue as Tool Workshop, plus it's completely inaccessible from mobile navigation.
- Repo Workspace: Shows file tree, editor, git toolbar, and terminal all competing for space. On mobile, nothing is usable.
Desktop layouts work well and should remain unchanged. This design focuses exclusively on mobile-first responsive alternatives.
Goals / Non-Goals
Goals:
- Make Tool Workshop and Config Profiles fully usable on mobile
- Add Config Profiles to mobile navigation (grouped under "Tools")
- Redesign Repo Workspace for mobile with clear primary/secondary view hierarchy
- Maintain desktop experience exactly as-is
- Use consistent patterns across all mobile configuration pages
Non-Goals:
- No changes to desktop layouts or navigation
- No API or database changes
- No changes to existing components' desktop behavior
- Not a full redesign of the web app (focused on these 3 pages)
Decisions
1. List→Detail Navigation Pattern
Decision: Use iOS Settings-style list→detail navigation for Tool Workshop and Config Profiles.
Rationale: Native mobile pattern users already understand. Works well for browsing and editing items. Allows full-screen forms without cramped split-panes.
Alternative considered: Bottom sheets for editing - rejected because complex forms need full-screen space.
2. Bottom Sheet for Tools Group
Decision: Tapping "Tools" in mobile nav opens a bottom sheet with "Tool Workshop" and "Config Profiles" options.
Rationale: Keeps bottom nav to 5 items (standard mobile pattern). Groups related functionality logically. Bottom sheet is fast and discoverable.
Alternative considered: Separate nav items - rejected because 6 items is too many for bottom nav.
3. Read-First Detail View
Decision: Detail view shows read-only information first, with an "Edit" button to enter edit mode.
Rationale: Prevents accidental edits. Allows quick scanning of configuration without entering edit mode. Matches mobile app patterns (view then edit).
Alternative considered: Direct edit mode - rejected because users often just want to view, not edit.
4. File Tree as Primary Repo Workspace View
Decision: Mobile Repo Workspace shows file tree first, with bottom tabs to switch to Editor, Git, or Terminal.
Rationale: File tree is the natural starting point for navigation. Bottom tabs provide quick access to other views without losing context.
Alternative considered: Tabbed interface at top - rejected because bottom tabs are more thumb-friendly on mobile.
5. Full-Screen Edit Mode
Decision: Edit forms open as full-screen pages with back navigation, not modals.
Rationale: Complex forms with many fields need maximum screen real estate. Back navigation is a clear mental model.
Alternative considered: Modal overlays - rejected because they feel cramped on mobile for long forms.
Risks / Trade-offs
Risk: Users may find the list→detail pattern slower than split-pane for quick edits.
→ Mitigation: Optimize for the most common flow (view first, edit only when needed). Add quick actions (delete, duplicate) directly in list view.
Risk: Switching between Editor, Git, and Terminal in Repo Workspace may feel disconnected.
→ Mitigation: Keep the current file/repository context across tab switches. Show repository name persistently.
Risk: Two different UX patterns (desktop split-pane vs mobile list→detail) may confuse users who switch devices.
→ Mitigation: This is standard responsive design practice. Both patterns are well-established in their respective contexts.
Trade-off: Mobile pages require more taps to accomplish the same tasks.
→ Acceptance: This is inherent to mobile form factors. The trade-off is acceptable for improved usability.
Migration Plan
No migration needed - this is purely additive UI work. Steps:
- Create new mobile-specific components
- Update page components to render mobile layouts conditionally
- Update mobile navigation
- Test on mobile devices
Rollback: Remove conditional mobile rendering, revert to desktop-only layouts.