Improved responsiveness on mobile phone

2026-04-10 13:41:26 +02:00
parent 0db31e91ab
commit 0711e40c66
16 changed files with 494 additions and 26 deletions
@@ -0,0 +1,90 @@
+# Feature Specification: Mobile-Responsive UI
+
+**Feature Branch**: `006-mobile-responsive-ui`  
+**Created**: 2026-04-10  
+**Status**: Draft  
+**Input**: User description: "I want the frontend to be usable in phone (small screen): Fix the nav bar on top, button on the right need horizontal scroll to be accessed. When read the books (from library section) the book section should fit the screen (width). The login section should be closer to the top of the screen"
+
+## User Scenarios & Testing *(mandatory)*
+
+### User Story 1 - Sticky Navbar with Scrollable Links (Priority: P1)
+
+On a phone, the user opens the app. The navbar stays visible at the top as they scroll. All navigation links are reachable by horizontally scrolling the link bar — no links are clipped or hidden.
+
+**Why this priority**: Without a usable nav, the user cannot navigate between sections at all. This is the most fundamental usability blocker on mobile.
+
+**Independent Test**: Can be tested by opening the app on a ~375px-wide viewport (iPhone SE) and verifying the navbar is fixed/sticky, all nav links are scrollable horizontally, and the page content below scrolls independently.
+
+**Acceptance Scenarios**:
+
+1. **Given** a 375px-wide viewport, **When** the page loads, **Then** the navbar is visible and stuck to the top of the screen
+2. **Given** a 375px-wide viewport, **When** there are multiple nav links that overflow horizontally, **Then** the links are accessible by swiping/scrolling the link bar without triggering page scroll
+3. **Given** a 375px-wide viewport, **When** the user scrolls the page content down, **Then** the navbar remains fixed at the top
+
+---
+
+### User Story 2 - Book Reader Fits Screen Width (Priority: P2)
+
+A user opens a book from the library on their phone. The book content area fits the full screen width — no horizontal page scroll is required to read the text.
+
+**Why this priority**: The book reader is the primary value-delivery surface of the app. If it overflows the screen, the app is unusable for its main purpose.
+
+**Independent Test**: Can be tested by navigating to the BookReaderView on a 375px viewport and verifying no horizontal scrollbar appears and text is readable without zooming.
+
+**Acceptance Scenarios**:
+
+1. **Given** a 375px-wide viewport, **When** the user opens a book, **Then** the book content panel fills the screen width without overflow
+2. **Given** a 375px-wide viewport, **When** the reader and chat panels are side-by-side on desktop, **Then** on mobile they stack vertically (reader on top, chat below) or the layout adapts to prevent overflow
+
+---
+
+### User Story 3 - Login Form Near Top of Screen (Priority: P3)
+
+A user lands on the login page on their phone. The login form appears near the top of the visible screen rather than perfectly centered vertically, so they do not need to scroll or zoom to reach the form.
+
+**Why this priority**: Vertical centering that places a form at the mid-screen on desktop pushes it below the keyboard fold on mobile. Fixing this improves first-contact UX.
+
+**Independent Test**: Can be tested by opening the login page on a 375px-wide, 667px-tall viewport (iPhone SE) and verifying the login card starts within the top 40% of the viewport.
+
+**Acceptance Scenarios**:
+
+1. **Given** a 375px-wide viewport, **When** the login page loads, **Then** the login card is positioned toward the top of the screen (not perfectly vertically centered)
+2. **Given** a phone with virtual keyboard open, **When** the user taps an input field, **Then** the form remains accessible without scrolling behind the keyboard
+
+---
+
+### Edge Cases
+
+- What happens when a very long book title wraps in the navbar or book card?
+- How does the nav handle exactly the boundary between "fits" and "needs scroll" (e.g., 3 vs 4 links)?
+- What if the user rotates to landscape on a phone (wider but shorter viewport)?
+
+## Requirements *(mandatory)*
+
+### Functional Requirements
+
+- **FR-001**: The navbar MUST be sticky/fixed at the top of the viewport on all screen sizes
+- **FR-002**: The navbar link area MUST be horizontally scrollable on small screens to access all navigation links
+- **FR-003**: Horizontal page-level scroll MUST NOT occur due to navbar overflow
+- **FR-004**: The book reader content area MUST NOT exceed the viewport width on screens ≤ 768px
+- **FR-005**: The login card MUST be positioned toward the top of the viewport (not vertically centered) on screens ≤ 768px
+
+### Key Entities *(include if feature involves data)*
+
+- N/A — this is a pure frontend CSS/layout change with no data model impact
+
+## Success Criteria *(mandatory)*
+
+### Measurable Outcomes
+
+- **SC-001**: On a 375px-wide viewport, the navbar is visible and fixed; all links are reachable by horizontal scroll within the navbar
+- **SC-002**: On a 375px-wide viewport, the BookReaderView shows content without a horizontal scrollbar at the page level
+- **SC-003**: On a 375px-wide viewport, the login card top edge is within the top 150px of the viewport
+
+## Assumptions
+
+- Target breakpoint for "small screen / phone" is ≤ 768px width
+- No hamburger menu is required — horizontal scroll on the link bar is acceptable per user request
+- The existing Vue 3 + plain CSS stack is retained (no CSS framework added)
+- Desktop layout is unchanged
+- No backend changes required