Alex Blank
e8d5b16acc
- Add mobile viewport detection to ToolWorkshopPage - Implement mobile list view with MobileListView component - Implement mobile detail view with MobileDetailView component - Implement mobile edit view with MobileEditView component - Add MobileFAB for creating new tool types - Fix IconName type issues in mobile components - TypeScript check passes, build succeeds
76 lines
4.3 KiB
Markdown
76 lines
4.3 KiB
Markdown
## 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:
|
|
1. Create new mobile-specific components
|
|
2. Update page components to render mobile layouts conditionally
|
|
3. Update mobile navigation
|
|
4. Test on mobile devices
|
|
|
|
Rollback: Remove conditional mobile rendering, revert to desktop-only layouts.
|